第３回　最初の大規模プロジェクト（その１：プロジェクト計画の顧客承認まで）

筆者が最初に担当した大規模プロジェクトは以前から「問題のＩＴシステム」として有名でしたので、リーダーを引き受ける時に「誰もそんなに成功を期待していないので思い切った方法でやれ」と上司に励まされて説得されました。噂で悪い情報が伝わってきていたので或る程度の予備知識はありましたが、最初に自分の目で全ての問題を確認するために、このＩＴシステムの過去に発生した主な問題を調査しました。既にバージョンアップを数回繰り返していたので過去の情報は少なかったのですが、幸いにも直近のバージョンのプロジェクト完了報告書が残されていました。この報告書から詳細なスケジュール、費用、開発規模、バグ数、試験項目数、使用マシン時間数、工程毎の工数などが実数値として判明でき、発生した問題を把握できました。この報告書を作成した人に感謝感激しながら、このプロジェクトの問題の原因と今後の課題を分析しました。更に、今までに本ＩＴシステムに携わってきた主要メンバ全員に、過去の問題点および対策案・改善点をヒアリングして、このＩＴシステムの新バージョン構築のプロジェクト計画を自分なりに立案しました。ヒアリングした殆どのメンバから「途中で逃げださないで品質が安定するまで責任を全うして欲しい」と懇願され、私はこのＩＴシステムを最初から担当しているメンバの本当の苦労を知りました。その時、私は自信はありませんでしたが、このＩＴシステムの品質を出来る限り早期に安定しようと決意しました。先ず、自分の目で全てを確認し、全ての判断をし、自分への責任を明確にしました。不退転の決意をメンバおよび自分に示したつもりでした。そして、私一人でプロジェクト計画の主要項目を以下のように決めました。

サービス開始は２年半後（必須条件）、予算は３，０００人月以内（目標）
全作業の作業手順を標準化（協力会社複数社の作業手順を統一化）
予算管理・進捗管理・品質管理の統一化・数値化（見える化）
開発効率化ツールの開発（現行システムから試験環境・試験データの活用）
単体試験の机上レビュー徹底化（単体試験ではマシン確認無し）
お客様との打合せ議事録・承認・レビューの方法の明確化（口頭約束禁止）

これらを計画書として文書化して、お客様の責任者に本プロジェクトの進め方について説明しました。今までの経緯から、なかなか信用されませんでしたが、何回も詳細資料を提出して丁寧に説明を繰り返した結果、（１）項以外については、３ケ月を要してお客様に納得して頂きました。納得して頂いた経緯は以下の通りです。

（２）、（３）、（４）の項目は、お客様にすんなり承認して頂きましたが、（５）「単体試験の机上レビュー徹底」については、お客様の多くの担当者から抵抗されました。「品質は机上レビューで向上し、マシンでは確認する」という考え方になかなか理解が得られず、筆者が過去に成功体験したプロジェクトのデータを詳細に示して訴えました。お客様の多くの担当者は過去の本プロジェクトの経緯から机上レビューを信用していませんでしたが、幸いにもお客様の責任者が理解を示してくれたので了解されました。しかし、当方の方法をやや強引に決めたために、失敗は許されないというプレッシャーが重くのしかかりました。

（６）「お客様との打合せ議事録・承認・レビューの方法の明確化」については、やはりお客様の担当者から「設計や決めるのに時間が掛かって困る」という抵抗を受けました。そこで私は説得材料として、過去は９つのサブシステムを別々に設計したために、作業の標準化が進まずかつお互い調整しなかったのでインタフェース・バグが多数発生し、現行システムでもインタフェース・バグが終息していないことを示すデータを提示しました。（当時、現行システムはシステム・ダウンを頻発し、品質が問題になっていた）。また設計時間が長引く課題に対しては、机上レビュー手法で単体試験期間を短縮するという対策「単体試験の机上レビュー徹底」や「総合試験の効率化策」を示して説得し、数回の激論を経て３ケ月後にご了解を頂きました。しかしこの時点では、提案の(１)予算３，０００人月については、未だ「過去の実績から判断して２，０００人月が妥当」と評価され、３，０００人月の工数は否定されました。

筆者は３，０００人月という工数の中に、リスク対策分（要求仕様の膨張・開発環境の不備・要員の交代・不慮の問題など）を１５％から２０％位見込んでいました。当時は、リスク対策分として、１０％位のアローワンスを見込むのがリーダーの常識だったようです。しかし、本プロジェクトは悪評高い問題プロジェクトだったので、通常プロジェクトの約２倍のアローワンスを考えていました。このアローワンスを隠して３，０００人月をお客様に納得して頂くのは難問でした。交渉頻度を多くして、お客様の初回評価の２，０００人月からの積上げを、少しずつ狙う作戦（長期戦）をとりました。

９つのサブシステム毎にプログラム難易度・品質の達成目標と実現手法を説明しながら、品質を向上するためには３,０００人月が必要だという根拠を、順を追って詳細資料を提出して粘り強く説得しました。次第に、お客様も当方の情熱を理解して、お客様の購買部門や上層部の方を説得するためのヒントを与えてくださるようになりました。当方も、数ケ月後にはお客様の会社内での立場を理解してそれに合わせた資料を作成・説明することが重要なことに気が付きました。ようやく上手く交渉が進みそうな見通しがたった矢先に、お客様内の人事異動で本プロジェクト担当の責任者の方が交代しました。新しい責任者の方に、ご挨拶に伺った時に「前任者から工数交渉の経緯は聞いたが、私は私のやり方で判断するよ」と言われて、工数交渉は白紙に戻ってしまいました。今度は最初から新しい責任者の方の考え方と判断のポイントを探りながら説明資料を作成したので、前任者の方よりも早く交渉は進みました。結局、前任者の方よりも更に詳細な資料を作成して説明することにはなりましたが、前任者の方と最初の工数交渉を開始してから１年経過した頃、ようやく新任者の方に約３，０００人月の予算で納得して頂きました。まさにお客様も呆れるほどの「粘りの交渉」でした。

これで筆者が立案したプロジェクト計画がようやく全面的に合意されました。計画ではもう設計工程の最終段階を迎えているはずでしたが、実際の進捗は要求仕様が決定されずに暗礁に乗り上げていました。お客様の要求は「やるべきことは全部実現せよ。工数は増やしたはずだ」ということでした。当方は「サービス開始と品質を厳守するには実現機能を絞るべき。期間的に品質確保が困難になる」と主張し、対立していました。お客様の責任者と筆者の１対１で、最終調整をしました。お客様には優先度の要求仕様をより詳細に説明して頂き、細かい冗長な部分を割切って頂きました。割切った冗長な部分を集めれば結構な工数削減になりました。運用条件を割切れば要求機能を低下せずに予想以上に試験工数を縮小できることを改めて再確認しました。当方からは、品質向上の手法と作業効率化方法を丁寧に説明して、お客様の品質向上への協力をお願いしました。結局、要求仕様については優先度の高い項目は大項目レベルでは全て実現し、品質向上については総合試験へのお客様の作業協力（現行システム機能範囲のデグレード試験を分担）を取りつけて決着しました。勿論、３，０００人月にはリスク対策分を含んでいましたので、この決着は想定したリスク範囲内でした。