システム開発プロジェクトにおけるリスクマネジメントの重要性
改めて言うまでもないが、システム開発プロジェクトはQ(品質)C(コスト)D(納期)のマネジメントが重要であることは誰も否定しないであろう。QCDのマネジメントで表面化する事象(品質が悪い、コストが想定以上にかかる、納期が遅れる等々)は結果である。その起こり得る事象に対してリスクマネジメントを行う訳であるが、リスクが顕在化する前には、必ず予兆がある。今回は開発プロジェクトで実践しているリスクマネジメントの流れを振返り、予兆にフォーカスしたリスクマネジメントの勘所をご紹介しよう。
リスクマネジメントの流れ
PMBOK※1でも整理されているが、リスクマネジメントの主要な作業は、「リスクの抽出」、「リスクの定量化」、「対策の検討」の3つである。リスクを抽出した後、リスクの発生確率(問題化する確率)×リスクの影響範囲×リスクの影響度でインパクトを算出し、リスクの発生時期(リスクが問題化すると予想される時期)を明確にする。発生時期を明確にすることで、緊急度の高いリスクから対策を打つことができる。そして、リスクの発生時期とインパクトの大きさを考慮してリスクに優先度をつけ、優先度の高いものから対策を検討する。検討した対策は、誰が責任を持って対策を実施するのか、いつまでに行うのかを明確にする。また、対策を打つことで、二次的なリスクが発生する可能性があるので、それも考慮に入れて対策を検討するというのが大筋のリスクマネジメントの流れである。
※1 PMBOK
アメリカの非営利団体PMI(Project Management Institute)(日本にはPMI日本支部がある)が策定した、モダンプロジェクトマネジメントの知識体系。「A Guide to the Project Management Body of Knowledge」という書籍にまとめられており、事実上の標準として世界中で広く受け入れられている。
稼動に対するリスクと予兆管理
上記は、ある意味教科書的な内容であるが、リスク抽出において実際のプロジェクトでは、「稼動に対するリスク」にフォーカスしてマネジメントしている。即ち、稼動＝納期が間に合わないということは、エンドユーザ、取引先など社内外への影響も大きく、遅延した時間分プロジェクト作業工数もかかる＝コスト増となり、まさに「失敗プロジェクト」の烙印が押されてしまう。そのような状況に陥らないためにも稼動に対するリスクマネジメントは非常に重要であると言えよう。
稼働に対するリスクは、予定していたこと(テスト、機器搬入、移行、教育等々)が期日に終わらないということに集約される。そのリスクは、外部要因リスクと内部要因リスクに分けられる。内部要因リスクはプロジェクト内部で発生するものであり、リスク回避に対する対応策を実施することでコントロール可能である。内部要因の中で、可能性が高い、または影響度の大きいリスクに対しては、リスク回避策が失敗した時に備えてコンティンジェンシプランを検討しておく必要がある。また、プロジェクト外で発生する外部要因(外部接続先の不備、新社屋の完成が遅れる等)リスクはコントロールが出来ない要素であるため、コンティンジェンシプランを策定し、稼働に対するリスクを回避する。 以下に稼動に関するリスクに関し、予兆にフォーカスした実践的なマネジメントの勘所をご紹介しよう。
1)内部リスク要因の抽出
製造・テスト工程における内部要因リスク抽出例を示す。この工程の内部リスク要因は設計や仕様変更などの上流段階での不備・検討不十分な観点と、性能やインフラなどの非機能要件的な観点が挙げられることが多い。また、リソース(要員)のアサインは要注意である。上流段階での的確な要員配置を誤ると、後続工程で問題が大きくなり想定以上の要員が必要になるケースも多い。例えば、要件定義フェーズである業務知識が求められるタスクに取り敢えず未経験者を投入して何とか済ませようとしたとする。その結果、曖昧な要件が未確定のまま設計段階に移ってしまう可能性がある。そして、設計者・開発者が「おそらくこういうことだ」と要件を勝手に解釈して仕様を作ってしまい、テスト段階でユーザから「これでは使えない」とクレームがつき、設計し直しになり、スケジュール見直し・工数(コスト)大幅超過となったケースは少なくないのではなかろうか。要件定義フェーズで業務知識を持った人材、非機能要件を取り纏める人材、PMOのような管理・調整や作業品質をマネジメントする人材など、計画的な人材投入を怠ってはいけない1つの例である。最初は小さく始めようと思いがちだが、過去の失敗の経験からは、最初の段階こそ人材の投入を絞るべきではない。
2)予兆管理のポイント
次に、抽出されたリスクに対して、リスクを細分化し、リスク回避策・監視指標を設定する。そして、そのリスクの予兆を設定・監視する。この例では「性能が出ない」というリスクに対しリスクを細分化し、どんな予兆があるのかを整理しているが、総じて言えることは、予兆は「現場」にあるということだ。開発担当から性能に関する問合せが頻発、性能試験の結果報告の遅延、性能の認識違い、性能に関する工程の先送り、設計に立ち戻った見直しなど、進捗報告資料などだけで判断せずに、現場を肌で感じることが予兆管理のポイントである。例えば現場で纏めている資料やメモ、メールのやり取り、開発現場の雰囲気(活気があるか)、会話の内容(ギスギスしていないか)、タバコ部屋での担当者のぼやき(そうは言っても実際はね･･･)などからも予兆を感じることができる。現場・現物主義、現場100回である。
3)予兆管理フレーム
以下の表は稼動に対するリスクの予兆管理の一例である。予兆をリスク顕在化の先行指標として捉え、その予兆が表れているのかを信号形式で表現し、リスクマネジメントの一環でモニタリングすることでリスクに対する感度を上げていくことを実直に繰り返す。ここでのポイントは、予兆の監視をどの位の頻度で何を確認資料として見ていくかということである。大規模プロジェクトで開発期間も長く、開発手法がウォーターフォール型であれば、表１のような細かい管理が出来る。しかし、管理のための管理にならないように、メリハリをつけてプロジェクト内でのリスク優先度と合わせてサイクル管理すべきであろう。また、アジャイル開発や短納期プロジェクトの場合は、ここまで管理出来ないのが実態である。その場合は、WBSのテーラリングと同様に、監視すべきリスク・予兆を絞り、関係者で合意を得た上でマネジメントすることになる。
以上、サンプルを用いて述べてきたが、稼動に対するリスクが顕在化する前にその予兆を監視し、いかに早く傾向を察知して先回りした策を打てるかが重要であり、それがリスクマネジメントの本質であると言えよう。私が今まで携わってきたプロジェクトで予兆管理を実践して「失敗プロジェクト」の烙印を押される確率は明確に下がっているということが、予兆管理の有効性を示す何よりの証と考えている。