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

Ｃ社ダウンサイジングにおけるリスク管理

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


----------------------------------------------------------------------
（設問ア）
----------------------------------------------------------------------
1.プロジェクトの概要とリスク管理計画
----------------------------------------------------------------------
1.1.Ｃ社生産管理システムのダウンサイジング
----
　Ｃ社はシリコンウェハーを製造するメーカである。工
場は基本的に２４時間３６５日稼働であり、システムに
ついても信頼性確保の観点からホストシステムに構築さ
れていた。

　一方、二重化等の技術によりＰＣサーバを用いたシス
テムでも十分な信頼を確保する事が可能になってきた事、
Ｃ社内におけるシステム費用削減の方針から、ホスト計
算機の保守限界のタイミングで、ダウンサイジングを行
う事が計画された。

　システムインテグレータであるＮ社に勤務する私は、
Ｃ社ダウンサイジングの受注後、基本計画工程より、
ＰＭとして参画する事となった。

----
1.2.リスク管理計画
----
　ダウンサイジングの進め方については、ミドルソフト
ウェアを開発する事により、ホストで構築されたＣＯＢ
ＯＬプログラムをほぼそのまま稼働させるというもので
ある。プロジェクトのリスクは大きく以下の２点にある
と私は認識した。

a.ホストの保守限界までに開発が完了しない。
b.ミドルソフトウェアの開発が必要な機能を充足できな
　い。または、性能を保証する事ができない。

　私はリスク管理を以下のように行った。

a.プロジェクトスタート時点、および設計・製作等の各
　工程に入る前に想定されるリスクを全て洗い出し、評
　価を行う。
b.各工程の実行過程では、新たに発生したリスクは無い
　か、発生確率・影響等の変化は無いかフォローを行う。


----------------------------------------------------------------------
（設問イ）
----------------------------------------------------------------------
2.プロジェクト開始時点におけるリスク管理
----------------------------------------------------------------------
2.1.リスク管理の視点
----
　リスクが現実のものとなった場合、納期・品質・コス
トに与える影響は大きく、リスクを管理する事は、納期・
品質・コストを管理する事と同様に重要である。
　従って私はまず、基本計画策定時点において、想定さ
れるリスクを洗い出し、洗い出したリスクについて、以
下の視点で分析を行い、可能な限りの対策を取る事とし
た。

a.リスク回避
　顧客との協議、前提事項の見直しにより、リスクを発
生させる要因をプロジェクトのスコープから外す事はで
きないか。

b.リスクファイナンス
　リスクが現実のものとなった場合にコストをかける事
で解決することはできないか。

c.リスクコトロール
　想定されるリスクを発生させないように、プロトタイ
プの採用など、開発工程の工夫・品質管理の徹底はどの
ように行うべきか。

----
2.2.実際のプロジェクトにおけるリスク管理
----
a.リスク回避
　今回のプロジェクトでは当初、本番機・バックアップ
機によるホットスタンバイ構成を予定していた。しかし
ながら、ホットスタンバイは環境設定・検証、および運
用設計に相当の工数がかかることから、ホットスタンバ
イの必要性について、再度顧客と協議を行った。その結
果、３０分程度の停止であれば、ＦＡシステムおよび人
間系での運用の工夫により、操業停止に至る事は無いと
の事であった。
　これにより、バックアップ機はコールドスタンバイで
要件を満たせる事が明らかとなった。

b.リスクファイナンス
　これは先に述べたミドルソフトウェアの性能が十分で
無いというリスクに対して採った対策である。具体的に
はサーバには十分な拡張性を確保し、性能問題が発生し
た場合には、ＣＰＵ・メモリ等の追加が可能な状態にし
ておいた。また、Ｎ社内において、最悪の事態となった
場合のプロジェクトの収益の見通しについて、説明・承
認を得る事であった。

c.リスクコントロール
　これも同じくミドルソフトウェアについて、性能予測・
実現するための制約等に対する見極めを行うためにプロ
トタイピングの開発工程を設けることとした。
　一方、プロジェクトの工期が満足出来ない場合に備え、
ダウンサイジング後のサーバについては、既存ホスト計
算機と同一のメーカを採用する事とした。これは、既存
ホストの延命を図る事を目的としており、メーカ営業と
折衝の結果、最大で６ヶ月の延命は可能であるとの約束
を取り付ける事ができた。


----------------------------------------------------------------------
3.各工程でのリスク管理
----------------------------------------------------------------------
3.1.実行過程でのリスク管理の方法
----
　先に述べたような視点でリスクを洗い出し、可能な限
りの対策を採った後にプロジェクトは進行していった。
しかし、リスクは常に変わり得るものであり、新たなリ
スクは発生していないか、発生の確率・発生時の影響に
変化は無いか、管理していかなければならない。

　私はプロジェクトメンバーと定期的に開催していたミ
ーティングで上記のフォローを行った。特に、未解決の
リスクは減少しているか、各々のリスクの発生確率は下
がっているか、下がっていないならばその原因は何か、
という分析を行い、プロジェクトメンバーを指導した。

----
3.2.実際のプロジェクトにおいて発生したリスク
----
　前述の通り、ミドルソフトウェアの開発については、
当初よりプロジェクトのコアとなる事が予測出来ていた
ので、慎重に進める事で特に問題となる事は無かった。
　しかし、現実のものとなったリスクは思いもよらない
ところに潜んでいた。それは、協力会社メンバの体調不
良による入院という事である。確かに私はＰＭとして、
メンバの健康状態・メンタルな部分についてのケアが不
足していた。これにより、プロジェクトは１ヶ月の遅れ
が見込まれたが、残りのメンバの努力により、半月遅れ
での本番にこぎつける事ができた。


----------------------------------------------------------------------
（設問ウ）
----------------------------------------------------------------------
4.リスク管理技法の評価と改善点
----------------------------------------------------------------------
4.1.リスク管理技法の評価
----
　私は今回のプロジェクトではじめて、回避するという
視点でリスク管理を行った。これまでにも問題のあるプ
ロジェクトを立て直すために、途中工程において機能カ
ットを行った経験はあったが、スタート時点においてス
コープから外した事は無かった。リスクの芽を摘む事は
可能な限り早い方がプロジェクトに与える影響は少ない
事は明らかであり、今回の私の対応には満足している。

　しかし、一方でのプロジェクトメンバへのケアが不足
していた点については、反省しなければならないと考え
ている。また、様々な理由により要員交代は発生すると
いうリスク管理が必要である事も十分に認識できた。

----
4.2.これから行うリスク管理において改善すべき点
----
　今回はプロジェクトので発生し得るリスクを自分なり
に洗い出し、メンバや社内有識者とのレビューを行い、
リスク管理のベースラインとした。しかしながら、この
方法は各人の経験をベースとするものであり、漏れが発
生する危険性がある。
　従って私はリスク管理のポイント、および評価基準に
ついて、チェックシートを準備したいと考えている。