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

（業務仕様の変更を考慮したプロジェクトの運営方法について）

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

　
----------------------------------------------------------------------
（設問ア）
----------------------------------------------------------------------
１．１　プロジェクト概要
----------------------------------------------------------------------
　私が管理したプロジェクトは、銀行業の投資信託の販
売支援システムである。銀行内にはＬＡＮが構成され、
外部とは専用線で外部情報ベンダと投資信託に関する各
種マーケット情報を授受している。ＬＡＮの内部には本
部・営業店からクライアントが２００台設置され、サー
バは顧客情報を持つＤＢサーバとクライアントからの要
求を受け付けるＡＰＬサーバが稼動している。

　このシステムの開発規模は約１００人月で開発費用は
１億２千万円である。なお、このシステムの設計はＤＯ
Ａ手法で行い、見積りはＦＰ法とした。開発手法はパッ
ケージを使用した開発を行った。メンバーは総勢９名で
内訳は、ＰＭ１名・ＡＥ２名・ＤＢ１名・ＮＷ１名・Ｐ
Ｇ４名で構成し、私はＰＭを担当した。

----------------------------------------------------------------------
１．２　変更の可能性のある業務仕様とその理由
----------------------------------------------------------------------
　私が所属するＡ銀行は１年後にＢ銀行との経営統合を
受け、システム統合をする予定である。投資信託システ
ムではＢ銀行の顧客をＡ銀行のＤＢに移行することとな
った。マスタスケジュールでは設計３ヶ月・開発９ヶ月
・ユーザ検証・切替移行１ヶ月の１２ヶ月で計画され現
在は設計着手段階である。当初の設計方針は経営方針に
従い、新銀行への円滑な移行の為、システム変更は極力
実施せずに顧客ＤＢ移行を進めることとなっていた。し
かし、以下の背景により、両銀行で並存しているコード
体系を統一せねばならぬ可能性があったのである。
　○統合後の組織整理により、両コード並存で運営でき
るユーザ側の事務体制が保証できない可能性があった。
　○統合後には大規模な店舗統廃合があるのではないか
と噂されており、現在の仕様ではコード並存下での統廃
合を実施すると顧客ＤＢの整合性が保証できなくなる。
このような状況のもと、私はコード洗替の変更可能性を
見据えつつプロジェクト運営をすることとなった。

----------------------------------------------------------------------
（設問イ）仕様変更に際して検討した事項と実施事項
----------------------------------------------------------------------
２．１　検討した事項
----------------------------------------------------------------------
２．１．１　基本方針
----
　プロジェクト管理は計画段階より予測される事柄につ
いて事前に対策をとることが重要だと考える。そこで私
は仕様変更の発生について、以下の施策を検討した。

----
２．１．２　契約条項の追加
----
　顧客ＤＢのコード統一は対象範囲や洗替方法によって
は大規模な対応となり、３ヶ月の設計フェーズに完了で
きない可能性もある。その場合には別契約として対応す
るよう顧客を取り決める必要がある、私は契約条項の追
加を検討するよう契約担当者に指示をした。

----
２．１．３　仕様変更管理計画の立案
----
　仕様変更が発生した場合、変更可否や変更作業の管理
や変更情報の配布を的確に進めなければいけない。私は
仕様変更の管理計画の立案に着手し、以下の施策を検討
した。
　○ユーザやプロジェクト支援部門を含めた仕様変更委
員会を設立し、仕様変更の可否を多面的に判断する
　○変更仕様書やテスト結果のレビュー体制や進捗管理
に関するルールの策定
　○仕様変更による作業手戻りを最少限とすべく他チー
ムへの情報配布ルールの明確化

----
２．１．４　設計スケジュールの変更
----
　設計フェーズの作業項目の洗い出し・作業順序を踏ま
え、プロジェクトネットワーク図を作成するのだが、コ
ード体系に関連する作業は設計フェーズが予定通り完了
できる範囲内で後ろ倒しにシフトとするよう指示した。
また設計方針もコード内容に依存しないシステム移行処
理を指示した。

----------------------------------------------------------------------
２．２　プロジェクト実行における実施作業
----------------------------------------------------------------------
２．２．１　仕様変更要望の発生
----
　上記のとおり、仕様変更に対応できるよう計画を立案
し、実行段階に差し掛かり設計作業が開始された。案の
上、設計フェーズの着手から１ヶ月後にファンドコード
と担当者コードを統一して顧客ＤＢを統合してほしい要
望がユーザよりあがってきた。

----
２．２．２　変更管理計画の実施
----
　そこで私は変更管理計画に基づき変更手続きに着手し
た。変更管理委員会を召集し変更可否を検討した。シス
テム未対応の場合の顧客への影響度や手作業での体力見
積及びシステム対応費用をデシジョンツリー等のツール
を活用し検討した。その結果、以下の結論となった
　○担当者コードは顧客宛還元帳票にも使用し、かつ行
内の人事システムとも連動している為、洗替を実施
　○ファンドコードの洗替は影響範囲が大きく、洗替対
応はせず、しかし実績統計上では分別管理する要件があ
るので、システム内部で枝番を付加し分別する

----
２．２．３　契約内容の変更
----
　このように担当者コードの洗替が新たに発生した為、
作業範囲の変更を顧客と調整した。その結果、以下の
合意を得ることができた。
　○コード洗替に係る費用は当初契約と別契約として、
設計フェーズは委任契約、開発フェーズは出来高払い契
約とする
　○当初契約内容のうち、半期末作業分は１２ヶ月後の
リリースが必須ではない為、開発着手を延期とする

----
２．２．４　開発体制の増強
----
　統一コードの仕様は顧客ＤＢの構築に大きな影響を及
ぼすので、メンバには有識者を集め品質維持とスケジュ
ールを維持できるように努めた。

----------------------------------------------------------------------
（設問ウ）　評価と改善
----------------------------------------------------------------------
３．１　評価
----------------------------------------------------------------------
　このように仕様変更について対応した結果、設計は３
ヶ月でコード洗替分も含め完了することができた。また
設計以降の開発も順調に推移し、１２ヶ月後のリリース
も無事迎えることができ、顧客へのサービスも継続して
提供できるようになっている。
　更に、新銀行立ち上げ直後に大規模な店舗統廃合が正
式に決定されたが、事前に統一コード対応を実施してい
たので大きな混乱もなくシステムは安定している。もし
店舗統廃合時に対応していたら、スキルのある要員の確
保が非常に困難となっており、プロジェクトの運営に大
変苦慮したであろう。

----------------------------------------------------------------------
３．２　改善点
----------------------------------------------------------------------
　改善する事項といえば、担当者コードの洗替とファン
ドコードの枝番対応にコストが非常のかかったことであ
る。特に枝番は顧客ＤＢの設計思想になかったものであ
ったので、対応範囲も相当に大きく、その為に当初計画
の１．３倍もコストを費やしてしまった。幸いなことに
一括請負形式でなかったので、プロジェクトでは赤字と
はならなかったが、今後はシステム統合という特別な事
情下で追加契約が締結できることは難しい。有識者を集
め期限内の作業完了をだけのことはしたが、費用管理に
おいてはプロジェクトマネジメントツールを用いたＥＶ
分析を適宜活用し、早期に費用差異を認識し的確な対処
を徹底するべきだと感じている。


　　　　　　　　　　　　　　　　　　　　以　上