読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

Kindleで翔泳社新刊「レガシーソフトウェア改善ガイド」含め、50%ポイント還元中(12/8まで)

Kindle book

表題通りAmazon Kindleで大規模セールになっているようだが、新刊「レガシーソフトウェア改善ガイド」も対象になっている点に注目。さっそく購入。

レガシーソフトウェア改善ガイド (Object Oriented Selection)

レガシーソフトウェア改善ガイド (Object Oriented Selection)

この本のスコープは欲張りなもので、放置されたレガシーコードベースを、あなたの組織に価値をもたらす保守が可能で十分に機能するソフトウェアへと変身させるのに必要なことを、すべて伝授しようというのです。
レガシーソフトウェア改善ガイド (Object Oriented Selection) この本について、より引用

なかなか興味深そう。旧著レガシーコード改善ガイド (Object Oriented SELECTION)に比べるともう少し戦略的な事が書かれていそうな印象。技術面だと

ただし、この本に技術的な内容がないというのでは、まったくありません。本書は、Jenkins,Findbugs,PMD,Kibana,Gradle,Vagrant,Ansible,Fabricなどといった、広範囲なツールを扱います。数多くのリファクタリングパターンを詳細に取り上げ、モノリスからマイクロサービスにいたるさまざまなアーキテクチャにおける関連メソッドを論じ、コードをリライトするときにデータベースを扱う戦略も見ていきます。
レガシーソフトウェア改善ガイド (Object Oriented Selection) この本について、より引用

というカバー範囲になっている模様。

その他のオススメ本は以下記事などを参照いただきたい。

Kindleで「熊とワルツを」他のデマルコ本、「ソフトウェア要求」などが50%オフセール中

book Kindle

観測の範囲で、ポイント還元により「熊とワルツを」他のデマルコ本、「ソフトウェア要求」などがAmazon Kindleで50%オフセール中の模様。先日書いたDIAの記事に興味があれば「熊とワルツを」を購入するチャンスかも。

デマルコ関連

熊とワルツを リスクを愉しむプロジェクト管理

熊とワルツを リスクを愉しむプロジェクト管理

実は今読んでいるところ。ソフトウェア開発におけるリスク管理に関する名著。最近はどのソフトウェア開発プロジェクトもリスク管理はやる流れになっていると思うけれど、形骸化しがちでもある。というわけで見直すきっかけによいのでは無いかと思っている。

デッドライン

デッドライン

あまり技術書になじみの無い若い方によくオススメしている本。PMのやり方に不満がある時などに読むといいと思っている。

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

プロジェクトあるあるな失敗パターンについて書かれた本。中堅以上の方にオススメ。

こちらはデマルコさんではなくヨードンさんの書いた名著。

プログラミングの心理学 【25周年記念版】

プログラミングの心理学 【25周年記念版】

パーフェクトソフトウエア

パーフェクトソフトウエア

こちらはデマルコさんではなくワインバーグさんの書いた名著。

オススメ高額技術書関連

ソフトウェア要求 第3版

ソフトウェア要求 第3版

要求定義関連の古典ですが、第三版ではアップデートされてアジャイル開発プロセスもフォローされている。

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 下 完全なプログラミングを目指して

Code Complete 第2版 下 完全なプログラミングを目指して

さすがにいまどき読むのはコスパが悪いという評判もあるけど、一冊持っておくならセールのタイミングに買いたい。

ソフトウェア見積り 人月の暗黙知を解き明かす

ソフトウェア見積り 人月の暗黙知を解き明かす

こちらも名著なのだけれども、今でも皆が読むべきだと思っている鉄板本

その他

90年代MicrosoftWindowsNT開発に関するドキュメンタリー。非常に示唆が多く、大好きな本のひとつ

上記以外にもいろいろセールになっているので、ちょっと調べてみると良いと思う

DIA(デンバー国際空港)の自動手荷物処理システム

Project Management

有名なソフトウェア開発の失敗事例(トム・デマルコの「熊とワルツを」では「ろくでもないソフトウェア開発の象徴」とも呼ばれる)である DIA(デンバー国際空港)の自動手荷物処理システムについて、勉強がてら整理してみる記事。名前は知ってたけれど、ちゃんと考えてみたのはこれが初めて。この事例はIT 技術者として押えておきたいと思ったところ。メメント・モリ

主要な情報源

DIA(デンバー国際空港)の自動手荷物処理システム

さてどのような事件だったのか、上記の情報源から改めて整理してみたい。

  • 新空港の着工は1988年
  • システム開発の着手は1991年
  • 当初の開港予定日は1993年10月31日だった
  • しかし、予定日には自動手荷物処理システムは完成できず開港が出来なかった。空港設備はシステムを前提に構成されており、システム無しの乗客受け入れは不可能だった
  • 結局1995年にやっと部分開港にこぎつけた。遅延コストは1ヶ月につき3300万ドル必要となった。また動かない自動手荷物システムのバックアップシステムを構築するために5千万ドルが必要となった
  • 2005年にシステムは完全に廃止、マニュアルの搬送方法に切り替えられた。それまで一度も正常に稼働したことはなかったという。また運用を停止しても、リース料は25年の契約が切れるまで残ることとなる
  • 開発当時、自動手荷物処理システムは既に他の空港で実用化され稼働していた。しかしDIAは他の空港に比べて規模が大きかったため、システムの規模は既存の同種のものより10倍以上複雑で、要求される処理スピードも高かった
  • 開発基盤はOS/2オブジェクト指向技法で設計されること、とされていた。空港全体の情報システムとしては独立して稼動し、各航空会社の予約システムとは連携していた
  • 開港予定日が政治的な理由で先に決定されていた。最初から開発期間が大きく不足していた。請負会社は開発期間として当初与えられた期間(2年)の倍が必要と主張していた。また先行する類似システムの試験導入に成功していたミュンヘン当局はDIAに対して2年のテスト期間と6ヶ月の24時間運転による調整をアドバイスしていたが、DIAはこれに従わなかった
  • そもそも、受託会社も無理なスケジュールと考えていたため入札には応札しておらず、ベストエフォート・ベースで契約していた。また早い段階から再三納期に間に合いそうにないと告げており、かつ新たな変更が加わるごとに遅延は拡大していった

整理するだけでお腹が痛くなる事案である。

各種の論評

  • 1994年 Scientific American での論評

ソフトウェア工学の規律は、情報化時代の社会の要求を満たすために必要な成熟した工学の規律より数年、いや、おそらく数十年は遅れている

プロジェクトが失敗した原因は、DIA のリスク管理の方法にあるのではない。リスク管理の努力がまったくなされなかったことにある。

現在の視点で考えてみる

上記がトラブルのあらましなのだけれども、自分がもしこのプロジェクトにアサインされたら、という前提でいろいろ考えてみた。もちろん「必要な開発期間の半分しかスケジュールが与えられない」という無理ゲーなので逃げるが勝ちな気がするけれど、それでは思考トレーニングにもならないのでやる前提で。

まずはパイロット調査

そもそも全体規模が巨大かつ、性能要件が厳しいというシロモノなので完成できるかどうかもわからない。というわけで何はともあれ金をドブに捨てるとしてもパイロット調査を計画するのが最優先だと思う。時間とカネはさておいて、完成可能かどうかの検証が一番大事。

  • パイロット版システムを作成する計画を立案して、リスクが高そうな要件の実現可能性を評価する
  • パイロット版システムをイチから構築する時間が無いので、出来れば稼動しているシステムを買ってきて改良して作る。時間はカネで買う
  • コストはいったん度外視。無理ゲーである時点でそんなことは気にしてはいられない
    • 作成したプロトタイプはそのまま本番システムに流用可能です、とか何とかいってとにかく上層部を説き伏せる
  • 動くシステムによって、プロジェクトが完了できるかどうかを見極める。

これを実施したうえで、そもそも現時点の地球の科学力では完成できないレベルの要件があったら、交渉する。もしくは逃げる。

システムを分割する

完成できる見通しが立ったと仮定して次にやるのはシステムの分割だろう。一枚岩の巨大システムを作るのはリスクが高すぎるので、業務観点と技術要素観点で複数のサブシステムに分解しないとどうにもならない。失敗が発生したとしても全部が倒れないような分割はすべきだと思う。

  • 美しい設計とか、深い分析をしている暇は無いので仮説をたててザックリと分ける
  • 技術的負債になることはいったんは厭わない
  • とにかく分割統治可能にする

といっても、当時も似たような議論はしていそう。

デッドラインはいったん忘れてスケジュールを立てる

そもそも着手の段階で開発スケジュールが本来必要な期間の半分しか許容されていないので、当初の開港予定日が守れる可能性は100%無いだろう。というわけで、いったんデッドラインは無視してスケジュールを再考し、そこからどれだけ前倒し出来るかをコントロールしたほうがマシな気がする。

  • デッドラインを無視することを利害関係者が受け入れない可能性は高い。その場合は外向きには遅延管理しながら、内部的には引き直したスケジュールで管理したほうがよさそうな印象
  • ただし、注意しないと新しいスケジュールに合わせてメンバーが個人余裕を持ち出す可能性がある(夏休み症候群)ので、CCPMなどを取り入れたバッファマネジメントをするのが良さそう

達成不可能なスケジュールを前提として、プロジェクトメンバーに強いプレッシャーをかけても生産性は低くなるだけである。むしろ達成可能なスケジュールに対して、どれくらい元のデッドラインに戻せるかに対して努力したほうが成果も見えやすいし、モチベーションは上がりそう

とまあ、いろいろ考えてはみたのだけれども、実際にはもっと難しいものなのだと思う。とはいえ、いろいろとアイデアを考えたりするのは訓練としてはなかなか良い印象。皆さんはどのようなアイデアを持たれるのだろうか。

熊とワルツを リスクを愉しむプロジェクト管理

熊とワルツを リスクを愉しむプロジェクト管理

Software Runaways: Monumental Software Disasters

Software Runaways: Monumental Software Disasters

情報システムの障害状況ウォッチ(2016年前半)

Project Management

SEC Journal46号で2016年前半の情報システム障害状況まとめが公開されたので読んでみる記事。2015年度の分については以下のエントリを参照。生々しい話を読むと、自分がトラブルを引き起こす確率が減るんじゃないかと思っている。

SEC Journal最新号の入手はこちらから。

Zombies

情報システムの障害状況ウォッチ(2016年前半)

詳細はSEC Journalを確認いただくとして、掲載されているトラブル事例を例年通りニュース記事などとザックリ照らし合わせてみた。例によって調べているとお腹が痛くなる事案ばかり。

障害とは違うけれども気になる2016年前半の事件

情報システムの本番障害ではないが、マイナンバーの件[1606]以外にも今年はいくつかの大きな開発トラブル(システム開発の中止や賠償)の話も目についた。このあたりも詳細続報は報道されることは無いけれども気になるところ。

なぜ、システム開発は必ずモメるのか?

なぜ、システム開発は必ずモメるのか?

失敗学のすすめ (講談社文庫)

失敗学のすすめ (講談社文庫)

ITエンジニアと法的要件の考慮

Project Management Professional Engineer

XP祭り2016で発表された「巷にはびこる間違ったUX論へのヘイトをぶつける集い」という発表をめぐる一連の議論を読みながら考えた事。ちなみにUXについては門外漢であるし、そこについての意見は無い。ただ、この中で出てくる「UXデザイナーは法律の考慮も行うべきなのか」については異論を唱えたいところ。

rosetta

なお一言断っておくと、「巷にはびこる間違ったUX論へのヘイトをぶつける集い」講演者の@takigawa401は知人である。だからと言って擁護するような意図は無いし、多分そういう内容になっていない。
また、もともとの議論はUXデザイナーに関するものなのだけれど、本記事ではより広義な事を書いているつもりなので記事タイトルは意図して「ITエンジニアは〜」というビッグワードを使っている。

プロフェッショナルを名乗るのであれば法規の遵守は第一の要件である

まあこの一言に尽きるのだけど・・・

2016年の現在においては、ユーザーニーズだけでなく(このブログで取り扱っているように)既存の各種法律や慣習もユーザーニーズと同様に機能使用や情報の構造に影響を与えるファクターとして存在しています。確かに16年前ではユーザーニーズを検討しておけば十分だったと思います。しかし現在ではITサービスの社会的需要の拡大により、サービスと既存法制との接点も十分に検討すべき課題として挙がっていると個人的には考えています。このような状況の中で、あくまでUXデザイナーの業務はUXだけに限るのか、よりよいサービス(の仕様書)を作るためにUXだけでなく法律や慣習まで業務範囲に含めていく必要があるのか、その辺りUX界隈の人たちがどのように考えているのか興味があります。

もちろん業務を行う上で、法律や商習慣の知識はあった方がいいでしょうし、その方が物事は早く進みます。ですが、UXデザインはそれ自体が非常に大変で専門的な役割であり、だからこそUXデザイナーはUXデザインに注力すべきでしょう。専門外のところまでフォローしようと思ったら、1日24時間どころか72時間あっても全然足らなくなってしまう。法律や商習慣、業務の細かな内容の確認は、それぞれのスペシャリストに任すべきです。だからこそ我々はチームを組み、協業して製品やサービスを開発するのです。

もちろん法的要件の適格性を最終的に確認するのは専門家の役割であるとは思うのだけれども、「UXデザイナーはUXデザインに注力すべきでしょう」という点には同意しかねるのである。職業プロフェッショナルを名乗るのであれば、当然のように法的要件および政治的・文化的要件に配慮すべきである。UXデザイナーに限った話ではなく。

これは職業倫理の問題なのだけれども、ちょっと長いが「ソフトウェア・エンジニアリングのための倫理ならびに専門職実務綱領(日本語訳)」の序文が素晴らしいのでこれを引用して説明したい。

コンピュータは商取引,産業,行政,医療,教育,娯楽,社会全体において中心的な役割を果たしており,その役割はますます増大しつつある。ソフトウェア・エンジニアはソフトウェア・システムの分析,仕様決定,設計,開発,保証,メンテナンス,テストに,直接的な参加あるいは教育を通じて貢献している。ソフトウェア・エンジニアは,ソフトウェア・システムの開発に対して果たすその役割ゆえに,
・自らが善いことをするのか,害をもたらすのか,
・他者が善いことをするのを可能にするのか,害をもたらすことを可能にするのか,あるいは,
・他者が善いことをするよう影響を与えるのか,害をもたらすよう影響を与えるのか,
を決定づける,重大な機会に直面する。自らの取組みが善いことのために利用されることを可能な限り確実なものにするために,ソフトウェア・エンジニアはソフトウェア・エンジニアリングを有益で尊敬に値する専門職の仕事とするよう最大限の努力を投じなければならない。こうした責務に従い,ソフトウェア・エンジニアは以下の倫理ならびに専門職実務綱領を遵守すべきである。
(中略)
倫理的な対立状況では,詳細な規則を盲目的に信頼するよりもむしろ,基本的な原則について注意深く考えることによって,それに最もよく取り組むことが可能となる。そうした原則とは,ソフトウェア・エンジニアに以下のようなことをするよう促すものである:
・誰が自分達の仕事に影響を受けるのかについて広い視点で考え,
・自分達ソフトウェア・エンジニアが他の人々を,当然払うべき尊敬の念をもって扱っているかどうかについて考察し,
・社会の人々が自分達の決定を,もしその内容がきちんと知らされるならば,どのように思うのかについて考え,
・最も権限・権力のない人達が,自分達の決定によってどのように影響を受けるのかについて検討し,
・自分達の行動がソフトウェア・エンジニアとしての理想的な専門家の仕事であると判断されるに値するものであるかどうかを考える。
これらのすべての判断において,社会の人々の健康,安全,福利への関心・配慮が最も重要である。すなわち「公共の利益」こそが,この綱領の中心に存在するものである。

類似のものとしてはITに限定しないエンジニア全般のものとして「技術士倫理要綱」、ソフトウェア開発については「認定情報技術者 倫理要綱」もあるのだけれども基本的には似たようなことが書かれている。要は「専門外なので知りません」とは言うべきではないのである。

ただ、もちろんこれは姿勢の話であって、最終的には専門家に頼らざるをえないとは思う。それでも取り扱う領域において、配慮すべき論点についてのリサーチは行うべきだし、それをすることが本来の職務の妨げになることは無いだろう。

翔泳社さんの技術書がKindleでセール中の模様

book Kindle

定点観測結果。久しぶりに割と翔泳社さんの大型技術書が50%前後オフのセールになっている模様。
これですね。10/2まで。

めぼしい、既読を中心におすすめのものをピックアップ。

組織パターン

組織パターン

  • いわゆるソフトウェア開発組織改善のタネ本。よくある悩みがパターン化されているので、よく読み返してるな。

エッセンシャル スクラム

エッセンシャル スクラム

  • すいません、実は未読です。

実践ドメイン駆動設計

実践ドメイン駆動設計

  • すいません、実は積読です。

旧書の類

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

  • 最近DDDの話題が盛り返している印象もありますが、原典として。

レガシーコード改善ガイド

レガシーコード改善ガイド

  • いつ果てるともないレガシーとの戦い方。

エンタープライズアプリケーションアーキテクチャパターン

エンタープライズアプリケーションアーキテクチャパターン

  • 再読しているのだけれども、こちらも名著の類ですね。

他に、情報処理技術者試験対策本もセールになっている模様。
受験予定の方はチェックしてみると良いかもしれない。

久しぶりにKindleで20%オフの大規模セールで技術書が買い時かも

book Kindle

昨日くらいから、Kindleで割と大規模にポイント還元が始まっている模様。20%ポイント還元。最近こういったセールの頻度が下がっている印象もあるので、要チェック。個人的な観測では「みんなではじめるデザイン批評」が初めてセール対象になったような気がしてて、購入するか迷っている。

値引きが大きいもの

C#実践開発手法 デザインパターンとSOLID原則によるアジャイルなコーディング

C#実践開発手法 デザインパターンとSOLID原則によるアジャイルなコーディング

残念ながら未読。気にはいるのだけれど・・・
ポイント還元も考慮すると実質半額。

プログラミングの心理学 【25周年記念版】

プログラミングの心理学 【25周年記念版】

名著のひとつ。とりあえず「なか見検索」ができるので内容を確認すると良い。
ポイント還元も考慮すると実質半額以下。

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 上 完全なプログラミングを目指して

こちらも名著のひとつ。上巻だけだけどポイント還元も考慮すると実質半額以下。
とはいえ、世の中にはこういった意見もあるのでご注意。

とにかく長すぎる。名著ではあるのだと思うが、時間に余裕があるか「俺はあの Code Complete を読破したんだぞ!」という満足感を得たいのでもなければ、もはやわざわざこの本を読まなくてもいいと思う。重要なトピックごとに、もっと深く掘り下げていてこれほど長くはない本がある。特に、良いコードを書くための知識については「リーダブルコード」のほうが良いと思う。

その他めぼしいもの

みんなではじめるデザイン批評

みんなではじめるデザイン批評

  • 作者: アーロン・イリザリー(Aaron Irizarry);アダム・コナー(Adam Connor)
  • 出版社/メーカー: ビー・エヌ・エヌ新社
  • 発売日: 2016/07/26
  • メディア: Kindle
  • この商品を含むブログを見る
未読。最近出た本。冒頭にも書いたけれど、初めてここまで値段が下がった気がする。
この記事を読んで、購入するか迷っているところ。

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

既読。良い本なのだけれども、あまり真新しい事は書かれていない。
他の話題の自己啓発本を読んでいるようであれば、手に取る必要はないかも。
ただ、非常に読みやすいのでこの手の本を読んだ事がなければお勧め。

未読。気になっているのだけれども読む時間が作れない。

こちらも未読。

サーチ・インサイド・ユアセルフ ― 仕事と人生を飛躍させるグーグルのマインドフルネス実践法

サーチ・インサイド・ユアセルフ ― 仕事と人生を飛躍させるグーグルのマインドフルネス実践法

既読。興味深いのだけれども、タイトル通り瞑想に関する本なので注意。
かなり意識高くないと、ひとりで実践は難しい印象。

既読。これも技術の本ではないのだけれどいろいろ参考にしている。良書。

How Google Works

How Google Works

既読。Googleがすごいってことはわかる。しかし真似できないよ、という感想。

テストから見えてくるグーグルのソフトウェア開発

テストから見えてくるグーグルのソフトウェア開発

既読。個人的には、本書をテストの本ではなく組織改革の本だと思っている。
学ぶ事の多いお勧めの一冊。

エンタープライズアプリケーションアーキテクチャパターン

エンタープライズアプリケーションアーキテクチャパターン

いま実は再読している。高額なので購入のチャンスかも。
ただ、翔泳社の木曜セールでもっと割引される日が来るかもしれない。

ソフトウェアシステムアーキテクチャ構築の原理 第2版

ソフトウェアシステムアーキテクチャ構築の原理 第2版

既読。アーキテクトの教科書としておすすめ。高額なので購入のチャンスかも。

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

既読。難しいけれど得るものが多い良書。高額なので購入のチャンスかも。
ただ、翔泳社の木曜セールでもっと割引される日が来るかもしれない。

実践ドメイン駆動設計

実践ドメイン駆動設計

積ん読中。まずい。高額なので購入のチャンスかも。
ただ、翔泳社の木曜セールでもっと割引される日が来るかもしれない。

既読。エンタープライズアジャイルといった事を検討しているSIer所属の人におすすめ。
こちらも高額なので購入チャンスなのだけど、翔泳社の木曜セールでさらに割り引かれる可能性はある。

他にもいろいろセール対象になっているみたいなので検討している本があればチェックしてみるのがよいかと。