- IPA過去問リンク：平成19年度春 -

  1. プロジェクトの概要

1.1 プロジェクトの概要

　これから、私が経験したプロジェクトについて述べる。そのプロジェクトは、Ａ市の基幹情報システムだ。

　Ａ市は人口約５万人程度の地方自治体である。

　我々は、関東の本社を置く従業員600人程度の会社である。主に地方自治体業務に特化したシステムの販売をしている。今回、ハードウェアのリースアップに伴うシステムの再構築プロジェクトを受託した。

　プロジェクト期間は約１年、ピーク時の要因は１０名で、総開発工数が１００人月。このプロジェクトに、私はプロジェクトマネージャとして参画した。

1.2 関係者との交渉が必要になった問題とその背景

　プロジェクトが立ち上がり、要件定義から外部設計まえは、ほぼ計画通りに進められた。その後開発フェーズに入ってからも、大きな問題もなく順調である。プロジェクトメンバの誰もが、このまま順調に完了するものだと思い始めた矢先、結合テストフェーズに入って問題が発生した。これまで、チームリーダとして頑張ってきたＹ君が体調を崩し、プロジェクトから離脱せざるを得なくなったのである。

　結合テストからシステムテストを経て、本番稼働までの工程に置けるＹ君の役割は重要で、彼が離脱するということは、すなわち、運用開始日が守れないことを意味する。もう少しわかっていれば、あるいは、突然ではなく予兆があれば運用開始日に間に合わせることも可能だったと思うが、残り２ヶ月という現時点では、運用開始日を守ることはほぼ不可能であった。

  1. 交渉による問題解決について

2.1 問題を解決するための手順

　プロジェクトの遂行中に問題が発生することは多い。その為、発生頻度が高く、発生した時の影響度が大きいものに対しては、それをリスクとしてとらえ、対応策を計画に加味している。しかし、今回のように主要メンバの病気やけがによる離脱というリスクに対して、計画段階でリスクヘッジするのは非常に難しい。

　一般的に、明確なリスクヘッジを計画に加味していないケースは、プロジェクト関係者と状況の認識を合わせた後、問題の本質を理解し、解決策として選択肢や優先順位を立案する。そして、それらを関係者に提示して交渉を進めていく。

　そこで私は、Ｙ君の離脱が決定したとき、緊急会議の開催を決定し、プロジェクト主要メンバと、顧客側のプロジェクトマネージャ、プロジェクトオーナ、利用部門の代表者に参画を打診した。

　その会議の中で、最初にＹ君の予定していた作業の量・質を説明し、今後のプロジェクトへの影響を説明した。ひとまず、状況の認識をあわせ、問題の本質、すなわちプロジェクトへの影響というものを、関係者全員で共有する必要があったからである。

　続いて、この会議に先立って用意していた複数の対応策を発表し、その中から最適な解決策を話し合おうと考えた。

2.2 合意に至った解決策

（１）交渉時の双方の主張

　Ｙ君の作業量、２人月分を現有メンバの人数で割り振ったら、運用開始日の遅れは１ヶ月になる。弊社としては現有メンバの人数で作業を割り振る方法（以下Ａ案）がコストの増加も最小に抑えることができるので望ましい。一方、仮に運用開始日を守る計画の場合、大幅なコスト増（Ａ案の３倍）になってしまうので、その場合は、Ａ市にも何らかのコスト負担を依頼したいと考えている。

　しかし、Ａ市にとって、いずれの選択も拒否された。運用開始日の遵守はもとより、契約金額の変更も不可能で、当初の契約通りプロジェクトを進めてくれとの一点張りであった。

（２）説得した内容

　このまま平行線で議論が進まず緊急会議を終えてしまうと、ますます窮地に追い込まれる。Ａ市のプロジェクトオーナや利用部門の責任者にそうそう何度も招集をかけることはできない。そこで私は、交渉が難航することを予想して準備していたリスク管理表を提示して説得を試みた。

　私が主張したのは、今回のプロジェクト計画を立案する段階から、リスクマネジメントはしっかりとしていたという事実がある。合意した計画にＡ市も弊社も落ち度はなかったという点だ。ひとまず、その部分に理解を示してもらわないと交渉にならない。片方にのみ落ち度があったというなら、そちらが全責任を負うべきだからである。

　そのリスク管理表では、主要メンバの不測の事態による離脱という項目があり、その場合は、双方協議の上対策を施すとしている。当時の議事録にも、主要メンバの病気やケガ、退職等による離脱の場合、それを見越して余力を持った要員計画を立てるのは、コスト面から難しいという記録が残っている。これらを会議の場で説明するとＡ市のプロジェクトオーナやり威容部門の責任者も態度が柔和してきた。

（３）合意に至った解決策

　その後、システム開発プロジェクトに置けるリスクの存在を、注文建築やビル建築にたとえて説明したりもした。

　その結果以下の解決策で合意した。

①運用開始日は遵守する（Ａ市の主張） ②コストの増分に対する追加費用負担はＡ市と弊社で折半する（双方の譲歩）

　双方に非がないことを、双方ども認識した結果、円満解決になった。

  1. 私の評価と今後

3.1 私の評価

　その後、プロジェクトは順調に進み、当初の予定通り、運用開始日を守ることができた。Ｙ君の代わりに急遽アサインしたＺ君も、計画通りの引き継ぎ期間、生産性で応えてくれた。その結果をみるだけでも、今回の不測の事態に対する問題解決は成功だったと考えている。

　さらに、ともすれば、対策費用（追加費用）の全額負担を強いられる今回のようなケースにおいて、顧客満足度を低下させることなく、コスト雑煮も最小限に抑えられ赤字プロジェクトにならなかった事実からも、あの会議の場での説得・交渉は効果的だったと考えている。

3.2 今後の課題

　今回、顧客に納得してもらったのは、計画段階でメンバの離脱に対して話をしていたからである。それが無ければ、交渉にもならなかったであろう。「今回はたまたま自分の知っているリスクが顕在化しただけでだったのかもしれない」と考えると、とても怖くなる。その為、今後は自分の想定できるリスクは多くないと仮定して、これから、社内に蓄積されている諸先輩方々のプロジェクト事例を研究して、プロジェクトに存在する「リスク」について情報収集していかなければならないと考えている。