プロジェクトＸ（バツ） 〜敗北者たち〜

　キャスター　：見てください、このドキュメントの量。（と、後の台を指差す。台の上には、様々な厚さのバインダーや箱が山積みとなっている。）

　アシスタント：すごい量ですね〜。

　キャスター　：これは、ある会社の統合システム開発で作成されたドキュメントの、ほんの一部なんです。

　アシスタント：これで、一部なんですか？全体量は、はかりしれませんえぇ。

　キャスター　：そして、（と、手に持った２冊のバインダーを見せて）これらのドキュメントの元となったのが、この２冊のドキュメントなんです。

　アシスタント：（後ろを振り向き）これだけのドキュメントを作る基となったのが、（キャスターの２冊のバンダーを見ながら）これだけのドキュメントなんですか？

　キャスター　：そうなんですよ、だからこそこ、この２冊に書かれている事は、非常に重要な意味をもってくるのです。だからこそ、ここに書かれている事に誤りや漏れがあったら、（後ろの台を指さす）あのドキュメントは、意味がなくなるのです。

　キャスター　：（カメラ目線で）今回の「プロジェクトＸ（バツ）　〜敗北者たち〜」は通信販売会社・Ｄ社の「統合システム開発プロジェクト」を取り上げます。
　
　1998年10月5日、大手情報インテグレーション会社・ＹＩ本社の２階にある食堂は、定時後であるのに人で混雑していた。
　溯る事、三ヶ月前。通信販売会社Ｄ社の統合システムを、アウトソーシングも含めてＹＩ社が受託に成功。
　即刻、Ｄ社の上級ＳＥとＹＩ社の上級ＳＥが新しい「統合システム」の要件定義と基本設計に着手し、9月末に完成・承認された。
　そしてまさに今、10月から本格開発に着手する、その開発の決起会であった。。
　Ｄ社システム企画部長が「社の将来をかけた統合システム再構築をＹＩ社と共に構築でき、うれしく思う」と挨拶した。
　ＹＩ社プロジェクト・マネージャー・Ｔ氏の挨拶、彼は最後にこう結んだ。
　「このプロジェクトに参加した者全員が、このプロジェクトを忘れず、後々まで語り継げるものにする。」と。
　
　10月からＹＩ社に派遣されてきたＨは、感動した。
　彼は、「オリンポス」と呼ばれるその統合システム、その中に複数あるサブシステムの一つ「アルテミス」のリーダーを任される予定だった。
　
　「オリンポス」、Ｄ社の業務のかなりの部分を網羅する、巨大システムだ
　それは複数の「独立」したサブシステムが連携して稼動するコンセプトで設計されていた。
　サブシステム間はＩ／Ｆトランザクションと呼ばれるファイル（及び通信）によってお互いにデータ交換する。
　この為、各サブシステムは「自分の欲しいデータ」だけを意識でき、独立性を持つ。
　これによって各サブシステムは並行して開発ができ、開発期間の短縮に繋がると期待された。
　競合先よりも新しいサービスを短期間で提供し、競合先が打ち出してきたサービスには短期間で対抗サービスの開始しなければならない。
　その為には、システム開発期間の短縮は必須条件だった。
　
　「オリンポス」は、様々なサブシステムの集合体である。
　「顧客」「販売記録」「在庫」等々の全データを、整合性を持った形で記録し、各システムへ提供する役割をになう、集中データ管理サブシステム「ゼウス」。
　大量のデータをオンライン処理する為、「見た目の派手さ」であるＧＵＩを切り捨てたメインフレームの単機能オンラインシステム「ヘラ」。
　逆に、ＧＵＩを積極的に採用した、ＵＮＩＸ上で稼動させる高機能オンラインシステム「アルテミス」。
　情報系システムへデータを提供する「アテナ」。
　顧客への発送及び倉庫間の発送追跡管理システム「ヘルメス」。
　その他にも、コンピューター制御の「自動倉庫（システム）」へ商品入出荷情報を提供する「ポセイドン」等々。
　それらが、同時かつ並行に開発が開始された。
　
　1999年4月、仕事はピークに向かって忙しくなっていた。
　当然、プロジェクトメンバーも増えている。
　Ｈは開発拠点となったビルのベランダから、近くの公園を眺めていた。
　桜が満開だった。
　「来年の今頃は・・・。」
　隣にいた、同じフロアで開発しているサブシステム「ヘラ」のリーダー、Ｎに話し掛けた。
　「のんびりと、あの桜の下でみんなと花見をしたいねぇ。」
　「来年の今頃は、今のメンバーのうち、何人残っているやら・・・。」
　Ｎは苦笑しながら答えた。
　「それに、来年の今頃も忙しかったらとんでもない事態だぜ、なにしろ2000年2月から、実質的な本番稼動開始なんだから。」
　
　1999年8月オンラインシステム「ヘラ」のプロトタイプ・レビューで、それは発覚した。
　事の発端は、オペレーター女性の何気ない一言だった。
　「お客さんの購買履歴一覧は、どの画面で照会できますか？」
　設計者が答えた。
　「この画面です、最新の３回分まで表示できます。」
　「それより以前の購買履歴は？」
　「照会できません。」
　チーフ・オペレーターが、慌てた。
　「それは困ります、今のシステムと同じように、全ての顧客について、全ての購買履歴を照会できるようにしてください。」
　設計者は、困った顔をして答えた。
　「今回のシステムはデータ量を押さえる為に、履歴は３世代しか保持していません。それより昔のデータが無いのです。」
　チーフ・オペレーターは、断言した。
　「全ての履歴が、業務上不可欠です。」
　「し、しかし・・・」
　設計者は困惑した。
　日々増加するデータ量、これはメインフレームの機械（ハードディスク）コストを引き上げていた。
　ＰＣに接続されたハードディスクとメインフレームのハードディスクとは、１バイト当りの単価が雲泥の差があるのだ。
　この為、「いつ使うかも解らないような履歴情報」はバッサリ切り捨てる事が基本方針として打ち出されていた。
　「この場では回答できないので、持ち帰って検討します。」
　レビューに立ち会っていたＤ社システム担当者が、回答した。
　「全ての顧客について、全ての購買履歴が照会できる事は、必須です。」
　チーフ・オペレーターが、念を押すように言った。
　
　全ての購買履歴情報が必要、これはすぐに集中データ管理サブシステム「ゼウス」担当者に伝えられた。
　概要設計、そう、設計の初期段階なら容易に対応できたであろう問題ではあったが、すでにシステム構築は進みすぎていた。
　ここまで進んでしまっては、ＤＢ設計は容易に変えられない、安易な対応は、根底からデータの持ち方が崩れかねなかった。
　すでに「ゼウス」は「オリンポス」の中で最大のシステムとなっていた。
　ゼウス担当のＹは、「現在の設計」を大きく変えないで済む対応に頭を悩ませた。
　たとえ方針が決まったとしても、「ゼウス」内での影響調査だけでかなりの時間が必要だ。
　それなくても、課題は山の様にある。
　Ｙは夏休みが無くなった事を悟った。
　だが、これは始まりでしかなかった。
　
　1999年9月、各サブシステムを繋げる「総合テスト」が開始された。
　サブシステム内での不具合も少なからず発生した。
　だが、それ以上に「サブシステム間の不具合」が多発した。
　曰く、「どのサブシステムも作っていないデータがある。」
　曰く、「Ｉ／Ｆトランザクションの内容が、お互いの思っていた内容と違う」
　さらには、様々な要件変更に「現行設計を極力変更しない対応」を取った為、処理が非常に重くなっていた。
　まだ本番稼動していないのに、幾多の仕様変更ロジックが追加されて「つぎはぎだらけの」プログラムが増加していった。
　確かにサブシステム内では整合性ある処理をしていたが、サブシステム間では矛盾だらけだったのだ。
　Ｄ社の各サブシステム担当者の見解の相違や、各サブシステムが独自で開発を進めた弊害だった。
　「独立したサブシステム」、だが実体は「各サブシステムが自分の都合の良いように作った代物」だった。
　
　そして、実作業担当者へのレビューを行なう都度、仕様変更が発生した。
　「当初、承認していただいた仕様で開発を続けたい。」ＹＩ社の申し入れに対して、Ｄ社マネージャーは答えた。
　「開発を続けるのは良いが、こちらの求める仕様を満たさないシステムは納品を受け付けない。」
　
　作業は、減るどころか増加する一方だった。
　

　アシスタント：この開発に参加した方々にスタジオにおいで頂く予定でしたが、守秘義務によりお話する事はできない、との事でどなたも出席していただけませんでした。

　キャスター　：残念ですねぇ。こういった話こそ、次回に役立つ情報が多く隠されているものなのですが・・・。

　アシスタント：では、プロジェクトのその後の物語です。
　
　1999年12月、深夜の会議室。
　「できません」
　「ゼウス」のＹが、ＹＩ社担当者に向かって断言した。
　「しかし、出来ない事が無い要件変更だとは思えないが。」
　ＹＩ社担当者・Ｓが言った。
　「この要件変更も必須だ、検討して結果を明日の夜に報告してくれ。」
　そう言い残して、Ｓは席を立った。
　
　1999年初旬は「解決すべき問題」に向かって、一致協力し意見を出し合っていた雰囲気が、この頃の会議からは完全に消えていた。
　打ち合わせで交わす言葉も「きつく」なり、「出来ない」「無理」「時間が無い」「要員がいない」といった単語が増えていった。
　担当者は、自分の仕事だけを考え、リーダーは自分のサブシステムだけを考えていた。
　「自分の身は、自分で守るしか無い。」
　各サブシステム間の協調関係は無くなっていた。
　
　Ｈはメンバーが増えた為、新たに開発拠点となったビルのベランダから、外を眺めていた。
　「正月は・・・。」
　同じく、引っ越してきた「ヘラ」のリーダー、Ｎに話し掛けた。
　「休めるのかい？。」
　「３１、１は休みたい・・・。」
　Ｎは疲れきった顔で答えた。
　彼のサブシステムは、ユーザーからの仕様変更が大量に発生し、スケジュールが大幅に遅延していた。
　ＹＩ社からは、彼の責任を追求する動きすらある。
　彼は、スケジュールの遅れを取り戻すべく週に２〜３日は徹夜し、土日も出勤していた。「だが、３０日は、何時に終わるか解らん・・・、まぁ徹夜かもしれない。」
　翌週Ｎは過労で倒れた。
　だが、倒れたのはＮが最初でなければ、最後でもなかった。
　そして、Ｎがこのプロジェクトに復帰する事はなかった。彼は「健康上の理由」により、自分の所属する会社を辞めていったのだ。
　Ｎだけでは無い、このプロジェクトが嫌で会社を辞めたり、突然引っ越しして行方不明になったメンバーは、少なくなかった。
　あまりの勤務の過酷さ・仕事内容のずさんさに、ＹＩ社との今後の取引きを諦めてまで、撤退したソフト会社も出始めた。
　
　1999年12月、連日徹夜して、休日出勤してでも当初のスケジュール通りに本番稼動できない事は、担当者間では公然の秘密だった。
　ＹＩ社がいつ、Ｄ社に「間に合わない」と話を切り出すか、それが最大の問題だった。
　それは、猫の首に鈴を付けるネズミの話と同じで、ＹＩ社の誰もが他人に押しつけたかった。
　
　2000年1月、会議室は重い空気に包まれていた。
　毎週の様に発生する、各サブシステムのリーダーの緊急招集。
　毎回、進捗の遅れを追求され、対応策を求められる場。
　だが、今回は違っていた、
　憔悴しきったプロジェクト・マネージャー・Ｔが、言った。
　「ユーザーの承認が取れました。本番稼動開始日を延期します。」
　重い空気の中で、安堵の息がもれた。
　「今後、テストで発生する不具合を全て解決し、要件変更を全て取り込んだ上で、本番開始を4月1日とします。」
　そして、再び、沈黙。
　これから「テストで発生する不具合」がどれだけ発生するか解らない。
　ましてや、先送りする予定で今まで検討すらしていなかった「要件変更」を取り込むのは、正気のさたじゃないとＨは思った。
　「地獄が、長引いた。」
　
　2000年2月、衝撃的なニュースが走った。
　通信販売会社Ｄ社が同業他社と合併するのだ。
　ＹＩ社プロジェクト・マネージャー・Ｔ氏は「オリンポスは、合併後のメインシステムとなる。4月の本番稼動目指して、ラストスパートをかけてほしい。」
　と激を飛ばした。
　確かに、2000年1月に発生していた不具合のかなりの部分が解決していた。
　だが、それ以上に「新たな」不具合が発生していた。
　その直後、本番稼動を6月に再延期する事が決定した。
　理由は「業務に耐え得る信頼性が確保できない」だった。
　
　2000年4月。
　Ｈは開発拠点となったビルのベランダから、近くの公園を眺めていた。
　桜が満開だった。
　Ｈは、疲れ切っていた。
　作業効率は、最低の状態だった。
　１年前、Ｎと交わした会話を思い出す。
　「来年の今頃も忙しかったらとんでもない事態だぜ、なにしろ2000年2月から、実質的な本番稼動開始なんだから。」
　だが、Ｎはもうプロジェクトにはいない。
　開発当初は穏和だったＹも、今では別人の様に「短気」だった。
　そして、プロジェクトはボロボロの状態だった。
　
　2000年6月、居酒屋は満員だった。
　そこでは、「オリンポス」プロジェクトの打ち上げが開かれていた。
　結局、「オリンポス」システムは本番稼動しなかった。
　「独立性が高い、使える一部のサブシステムをとりあえず稼動」させ、残りは少数で開発継続していく事になった。
　「使える一部のサブシステム」、それはオリンポスから見ると、メインの機能ではなかった。
　事実上「オリンポス」は「開発中止」になった事を、全員が理解していた。
　「少数で開発継続」の実体は、残務整理だった。
　
　Ｈは、決起大会でのＹＩ社プロジェクト・マネージャー・Ｔ氏の挨拶を思い出していた。
　「このプロジェクトに参加した者全員が、このプロジェクトを忘れず、後々まで語り継げるものにする。」
　少なくても、あの時点から今まで参加したメンバーは、このプロジェクトを忘れないだろう。
　そして、後々まで語り継ぐに違いない。
　この、「動くことの無かった巨大システム」の話を。
　
　＜＜＜エンディング・テーマ＞＞＞