大規模,複雑,厳しい納期――。昨年秋に完全統合したJAL/JASの情報システム。成功を収めたプロジェクトの裏に,見積もり精度の高さがあった。プロジェクト・マネージャ(PM)を務めた岡村正司氏に,どのように見積もったのかを聞いた。(聞き手は本誌 池上俊也)

JAL/JAS統合とはどんなプロジェクトだったんでしょうか。

岡村:昨年10月に完全統合しましたが,日本航空(JAL)と日本エアシステム(JAS)の約160のシステムを,JAL側のシステムに片寄せするものでした。工数は全体で1万2000人月,規模は8000万ステップと,とんでもなくデカいものです。IBMが手掛けてきた案件の中でも世界最大級でした。

 時間の制約も厳しい。2002年初頭に始まったプロジェクトは,2年間で中核部分をすべて統合しなければならない。失敗は許されませんでした。

岡村さんがPMとして招かれたときの様子を聞かせてください。

岡村:大変なところに来たと思いましたよ(笑)。連休を米国で過ごしていたら,呼び戻された。着任して現場を見ると,終わっているはずの要件定義が進んでいない。当初プロジェクト全体で4000人月と見積もっていたようですが,着任時点でそれを使い果たしていました。要員計画もスケジュールもできていません。この先どれだけ工数がかかるか,誰にも分からないという状況でした。

1500人月かけDFDとE-R図を作成

着任して何をしたのですか。

岡村:見積もりの準備として,現行システムを調査しました。統合プロジェクトは保守開発の一種。保守開発では現行システムの把握が基本です。ところがいい資料がない。そこでDFD(Data Flow Diagram)とE-R(Entity-Relationship)図を作成しました。

 苦労したのはシステムの中身が複雑だったことです。現場に行って担当者にヒアリングを繰り返し,どういうデータがどのように流れているのか明らかにしました。お客さんの担当を決めて,メンバー全員でワーっと聞きました。すべて調査するのに1500人月かかりました。

画面や帳票から現状を調査するプロジェクトも多いようですが。

岡村:それはダメなPMがやることです。現状調査はシステムの機能やデータなど内部から探っていく「インサイド・アウト」が鉄則です。楽ができるからと言って「アウトサイド・イン」で調査すると,機能やデータが漏れたり,誤解したりする原因になります。

DFDとE-R図を基に修正が必要な部分を確定し,その工数を見積もったわけですね。

岡村:そうです。修正が必要な範囲を特定する作業にも苦労しました。2社が統合すると航空会社コードが変わるのですが,それが使われているシステムは全部修正しなければなりません。これが66システムもありました。

 その他の機能はDFDやE-R図のエンティティをたどって該当個所を特定し,変更が必要かどうかを確認していきました。その結果,数十万本のプログラムのうち,1万数千本が対象となった。案件の数にして約2000のプロジェクトを走らせることになったのです。

1万2000人月という数字はどうやって算出したんですか。

岡村:かなり特殊なプロジェクトですからね。セオリー通りにはいきません。例えば,案件ごとに修正の度合いがバラバラなので,FPやステップ数当たりの生産性を機械的に当てはめることができないのです。結局,他の方法を探しました。

具体的には何をしたのですか。

岡村:過去に手掛けた大規模プロジェクトの中から,使えそうなデータを探しました。持ってきたのはある一つの案件の「工程別の工数比率」です。工程別の工数比率はプロジェクトの性格によって変わります。大規模プロジェクトでは,小規模プロジェクトよりも要件定義とテストの比率が大きくなる。そういう傾向があることは知っていたのですが,どの程度大きく見積もればよいかが分からなかったので,過去の案件の実績データからこのプロジェクトにふさわしい工数比率を推定しようと考えたのです。これが分からないまま見積もると,テストの工数が足りなくなる恐れがあります。