----------------------------------------------------------------------

（プロジェクト全体に波及する問題の早期発見について）

----------------------------------------------------------------------


----------------------------------------------------------------------
（設問ア）
----------------------------------------------------------------------
１．私が携わったプロジェクトの概要
----------------------------------------------------------------------
１．１プロジェクトの概要
----
　Ａ社は静岡に本社を置き、東北から九州まで支店・営
業所をもつ商社である。特に石油、ガス、化学品などの
エネルギー事業に力を入れており、石油事業に関しては
全国に約３００の直営サービスステーションを展開して
いる。今回この石油事業について、元売から提供されて
いるＰＯＳシステムがリニューアルされることとなり、
現行ＰＯＳの保守期限内に新ＰＯＳに対応したＡ社後方
勘定系の改善を行うこととなった。なおＰＯＳシステム
自体の開発は元売と契約した大手ＰＯＳメーカが担当し、
当社の開発範囲は主に以下の３点である。

・新ＰＯＳフォーマットデータを現行勘定系に取り込む。
　（集信系）
・新ＰＯＳフォーマットに合わせ配信データを加工する。
　（配信系）
・Ａ社独自カードに対し新たな機能を追加する
 （独自機能系）

　私はソフトウェアベンダＢ社に勤務しており、当プロ
ジェクトのプロジェクトマネージャとして、特に納期・
品質・費用の責任者として参画した。

----
１．２プロジェクト立ち上げ時に抱えていた問題
----
　Ａ社独自機能とは現状Ａ社本部で行っているマスタメ
ンテや請求明細などの照会機能をＰＯＳ側に移管し、サ
ービスステーションから操作可能とする機能である。し
かし契約時にＡ社の戦略的な理由により範囲が明確にな
っておらず、最小限の機能と最大限の機能では全体開発
工数より２０％の幅があると想定された。

　また納期に関して、ＰＯＳ切り替えは元売の方針であ
りＡ社の都合で変更することはできない。繁忙期である
冬場を避けるためフィールドテスト店への導入は１年後
の６月第２週と定められた。

----------------------------------------------------------------------
（設問イ）
----------------------------------------------------------------------
２．プロジェクト推進管理について
----------------------------------------------------------------------
２．１プロジェクト全体に波及する恐れのある問題点。
----
　要求分析工程で機能が確定しなかったため、次の概要
設計でヒアリングをおこなうこととなるが、ＳＥのヒア
リング能力が不足している場合、下流工程では吸収しき
れない追加案件が発生する可能性がある。この問題は単
に独自機能サブシステムだけで閉じているものではない。
なぜならば先に納期に関する制約が確認されているため、
機能追加が発生した場合、他のサブシステムからの支援
を検討しなければならないからである。

　このような状況が発生した場合、他のサブシステムの
品質・進捗に悪影響を与えることは必然であり、事前対
策を講じる必要があった。

----
２．２私の講じた事前対策
----
(1)契約締結時に追加した項目
　要求分析時に未確定な機能が存在したため、私は安全
係数を盛り込んだ契約にすることとした。安全係数は最
大の変動値である１．２を適用することとしＡ社に了解
を得た。

　一般的には安全係数に発生確率を加味して算出するが、
「いかなる理由であれ契約時の費用を超えることは許さ
れない」というＡ社の強い意向により、今回は発生確率
１．０が認められた。

(2)要員追加に関する対策
　Ａ社が発生確率１．０を認めた背景には、新ＰＯＳと
は直接関係のない石油システム改善に充てる思惑があっ
たものと想定された。このため私は以下のような事前対
策を講じた。

・追加工数が発生した場合、石油システム経験者２名を
　当プロジェクトに最優先で引き当てられるよう社内調
　整を行った。

・スケジュール面について、クリティカルパス上に位置
　する集信系を前に、現行からの修正が少ない機能、単
　純な出力処理を後ろに配置した。

　この方法であれば追加工数が発覚した時点で経験者を
配置し、現行からの修正が少ない機能から取り掛からせ
ることにより、教育にかかるオーバーヘッドを最小限に
抑えられると考えた。また追加工数が発生しなかった場
合、要員２名の費用を計上する必要がないことも利点で
あった。

----
２．３問題発生の兆候を検出するための手続き
----
　前述の事前対策を行うことにより、要件追加が発生し
た場合も遅れの兆候をとらえることができればプロジェ
クト全体に波及する問題にはならない。

　私は今回の独自仕様のように不確定要素が多い時こそ
確定された計画が正しく運営されていることが重要とと
らえ、以下のような手続きを組み込んだ。

・各メンバは製造完了と同時に実績工数をガントチャー
　トに記入する。
・各チームリーダは計画値と実績値を比較し、現時点で
　乖離が無いか確認する。
・週一回進捗会議を開き、進捗状況を私に報告させる。

　この方法であればメンバは実績値の記入だけで済み、
作業に集中することができる。また遅延が発生した場合
も私に報告が来る仕組みとなっていた。

----
２．４問題の検出
----
　プロジェクトも７ヶ月が経過し、結合テストに入った
ころで追加要件に伴う遅れがみられ始めた。このため私
は作業の山崩しを行い、何名を配置すれば遅れを挽回す
ることができるかシュミレーションを行った。この結果
当初の予定通り２名追加すれば対応可能と判断し、これ
までの状況をプロジェクト最高責任者である私の上司に
報告し、要員追加申請を行った。直ちに経験者２名が配
属され、変更点の少ない機能から作業をさせるよう指示
した。

　これらの対策の結果、結合テスト完了までに遅延を挽
回し、ＰＯＳ受入テストを行うことができた。


----------------------------------------------------------------------
（設問ウ）
----------------------------------------------------------------------
３．評価と改善点
----------------------------------------------------------------------
３．１私の評価
----
　一度遅延が発生すると以降計画通りとしても遅れを取
り戻すことはできない。従って遅延の発生をリスクと捉
え予防策を多く持っておくことが重要である。最終的な
追加案件はパーキンソンの法則にあるように安全係数を
すべて使い切るまで挙げられたが、事前対策の範囲内で
あったため、プロジェクトの責任範囲である納期・品質・
費用が守られたと社内外から高く評価されている。

----
３．２今後の改善点
----
　？？？
（時間が迫っていたので何を書いたかあまり覚えていな
　い。「事前対策が重要と再認識した。今回の事例をプ
　ロジェクト報告書にまとめ、プロジェクトの社内標準
　に反映したい」ということを書いたはず）

　　　　　　　　　　　　　　　　　　　　　以　　上