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

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

主要な情報源

デンバー国際空港 - Wikipedia 簡単な言及のみ
Software's Chronic Crisis; Scientific American; September 1994 1994年の Scientific American に掲載された Software's Chronic Crisisという記事(英語)
Software Runaways: Monumental Software Disasters 多くのページを本事件の分析に当てているそうだが、残念ながら翻訳は無し。もちろん私も未読
熊とワルツを　リスクを愉しむプロジェクト管理「第3章デンバー国際空港再考」という章に詳しい。なお該当章はAmazonの「なか身検索」である程度読めるので興味があればチェックしてみるとよい
ソフトウェア・テスト PRESS 総集編「Software Test Press Vol.2 特集2 テスト管理の極意」に言及あり
"ソフトウェア危機の例"(PDF) 東京情報大学玉置教授が公開している文書で、当時の経緯などが日本語で読める
http://www.nytimes.com/2005/08/27/us/denver-airport-saw-the-future-it-didnt-work.html 2005年システム廃止を報じるNYTimesの記事(英語)
航空事情第225号 (2005/6/13) (2005年6月13日発行) | 航空事情 - メルマ！ 2005年システム廃止を報じる航空系メルマガ(日本語)の記事
Denver Airport Baggage System Case Study – Why Do Projects Fail? ケーススタディ(英語)

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 での論評

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

2003年トム・デマルコの考察 ( 熊とワルツを　リスクを愉しむプロジェクト管理 )
- 開発プロセスの問題というより、リスク管理の失敗のほうが重大な原因だったという評価

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

現在の視点で考えてみる

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

まずはパイロット調査

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

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

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

システムを分割する

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

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

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

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

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

デッドラインを無視することを利害関係者が受け入れない可能性は高い。その場合は外向きには遅延管理しながら、内部的には引き直したスケジュールで管理したほうがよさそうな印象
ただし、注意しないと新しいスケジュールに合わせてメンバーが個人余裕を持ち出す可能性がある（夏休み症候群）ので、CCPMなどを取り入れたバッファマネジメントをするのが良さそう
- 参考：NTTデータはどうやってCCPMを導入したのか？
- この資料にあるように、従来見積もりの50%以内の時間で終わるタスクが多ければ、かなり巻ける可能性はある

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

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