PMBOK適用のSW開発におけるリスクマネジメントの実際

どうやってSW開発プロジェクトでリスクマネジメントを行っていくのか。PMBOKでは具体的な実践内容については述べられていないので、PMBOKの内容を踏まえて自分なりにリスクマネジメントをしていかないといけない。
実際にはPMBOKだけではなく、一般的な品質保証とかリスク管理とかの知識を総合して対応が必要だと思っているが、なんとなしにやっている所もがあるので、ちょっと自分なりにまとめてみよう。

１．そもそもPMBOKでのリスク管理とは

個人的には割と統合マネジメントに近い物があると思っているのだが、冷静に纏めてみよう。
最近ドキュメントの方をみていないのでちょっと忘れている。
カテゴリ的には以下のフローでマネジメントをする事になる。

リスク・マネジメント計画
リスク特定
定性的リスク分析
定量的リスク分析
リスク対応計画
リスク・監視・コントロール

知識エリア	立上げプロセス	計画	実行	監視・管理	終結
リスク管理	-	①リスク・マネジメント計画　②リスク特定　③定性的リスク分析　④定量的リスク分析　⑤リスク対応計画	-	⑥リスク・監視・コントロール	-

最後のリスク・監視・コントロール以外は全てが計画プロセスにわりあたっているというのが特徴的である。
これだと計画時にミスると、リスク管理に失敗するというように見える。が、実際にはPJのライフサイクルを通して、新たなリスクが出てくるので、計画プロセスも監視コントロールプロセスも常時実行していかないといけない。

PJライフサイクルを通して、リスク特定⇒分析⇒対応計画⇒監視・コントロールを行う事が重要。

リスク・マネジメント計画

まず、PJでリスクマネジメントにどのように取り組むかを計画する。

リスク特定

リスクをリスク登録簿へあげつらう。ここでリスク自体が漏れてしまうと、後々問題になるので超重要。
なお、リスクとは、脅威と好機の両方が対象であることに注意。

定性的リスク分析

リスク特定で上がった各リスクに対して、発生確率と影響度を評価し、各リスクの対応優先度決めを行う。

定量的リスク分析

定性的リスク分析で、高優先度になったリスクに対して、プロジェクトに与える影響がどの程度になるのか数値で、定量的に分析を行う。分析の仕方にはいろいろなツールがある。

インタビュー
確率分布
感度分析
トルネード
期待金額価値分析（EMV)
モデル化とシミュレーション
専門家の判断

リスク対応計画

特定した脅威、好機のリスク項目に対して、それぞれどう対応するかを決める。

脅威に対して

回避	脅威を完全に取り除く
転嫁	第3者に脅威対応を渡す
軽減	発生確率、影響度を受容可能な値にまで下げる
受容	受け入れる

好機に対して

活用	好機を確実に発生させるようにする
共有	好機を第三者と共有する
強化	発生確率と影響度を増加させる
受容	対策せずに受け入れる

リスク・監視・コントロール

リスク登録簿にあげつらったリスクの状況の追跡とその監視。
また、それ以外の新しいリスクが無いかリスク特定を行う。（実際にはここになると計画プロセスのリスク特定の作業に戻っている。）

２．具体的にどうやってリスクマネジメントするか

　ここからはPMBOKを習得した上で、実務でどうやるかという点。

プロジェクトの最初に特定したリスクに関しては、常時監視しておき、新たなリスクの目が出ないか、リスクが顕在化していないか、顕在化していれば対策を実行という事をする必要がある。

次に、プロジェクトを進めている内に新たなリスクが出てくるので、それを検知する必要がある。SW開発においては、いろんなところでリスクを検知するアンテナを張っておく必要がある。
SW開発のプロセス的に見ていくと以下のような感じか。

開発フェーズ	主なリスク特定の観点
企画、計画	最初のリスク特定フェーズ
要求分析	要求漏れが出ないか。要求分析の範囲に問題が無いか
基本設計	大きな勘違いや検討漏れが無いか
詳細設計	設計漏れが無いか。ノウハウ的なものがないか。協調が出来てるか
実装	コーディングルールが守られてるか。設計通りか。
テスト	テスト設計する技量があるか
リリース	次工程への連絡漏れが無いか

ちょっと書き出していくともっと大量にあるのだが、止まらなくなるからちょっとやめておこう。しかし、これをリスク特定の為の観点集みたいに纏めると便利そうである。

PMBOKの知識エリア別に見ていくとどうだろう

知識エリア	主なリスク特定の観点
統合	変更管理されていない物がないか
スコープ	やらなくてよいことをやって時間ロスしてないか。
タイム	メンバが時間を使えているか。スケジュール通りにいく見通しがあるか
コスト	お金、工数がものすごいかかる見通しになってないか
品質	成果物が所望のものになってるか
リソース	技術力が足りてるか
コミュニケーション	メンバ間で勘違いないか
リスク	-
調達	外部のコントロールが出来てるか
ステークホルダ	隠れたステークホルダによるツルの一声みたいなのがないか

３．実務を通して難しいと感じる点、問題点

前節で上げたように、複数の開発フェーズ、知識エリアでいろんなリスク特定の観点があるが、PMが一人で出来る事には限界がある。
チームメンバがそれぞれリスク検知してそれの対処をしてくれると助かるんだが、そんなことが出来る人ばかりならば、そもそもPMは要らないというもどかしさ。
また、SW開発はOSSや外部モジュール等の流用資産を使わないと開発が出来ない程に巨大化してきているが、それらのSWがちゃんと動くのかという評価が出来るわけでもないので、そこのリスクをどうやって解消したらよいのかが難しい。購入品ならなんとかなるが、OSSとなると自己責任。みんなどうしてるんだろう。
OSSのコードはあるから静的、動的解析やテストでの品質確保は出来るが、いざ問題が発生したり、設計変更、機能追加が必要になった場合、とたんに対処できる人が居ないというリソース管理上のリスクが顕在化することになる。うーん。

また、ステークホルダにおけるリスク要素がある場合、そのリスク情報自体を共有する事が出来ないという問題がある。
上司や関係者に対して、「あなたのその行動がリスクです。」なんて言った日にはプロジェクトが崩壊する。