このエントリーをはてなブックマークに追加LINEで送る

11.7. リスク管理プロセス

ハッピィ・エンジニアリング表紙

 リスク管理プロセスは、プロジェクト計画段階から終結に至るまで継続的かつ段階的に行わなければならないプロセスである。継続的に行わないと、どこかの工程で現われるリスクを見落とすことになる。また、システムの機能が明確になり、作業内容が詳細化されていくに従い、プロジェクトの初期段階で抽出したリスクも詳細化され変化していく。段階的に行わないと、当初想定していたリスクが形を変えたことを見過し、問題へと発展する可能性がある。

 

メリットのないリスクを避ける

 プロジェクト計画段階において、最も重要となるのが、リスクを取るメリットのないものを避けることである。

 

 たとえば、リスクを取るメリットのないものとして典型的な例は、大規模開発を避けることである。システム開発は規模が大きくなればなるほど、難易度が増していく。

 

 FP(ファンクションポイント;Function Point)当たりに必要なドキュメントの記述量は、FPが増加するに従い達成が困難になっているという現実がある。つまり、大規模開発では、FPあたりに必要なドキュメントの作成が事実上できないということを意味する。*1

 

 実際には、多くの内容が、定期的な会議、質問票、メール、口頭などの手段を用いて、補われているのである。システムの実現に関わる全ての内容をドキュメントに残すことができないという現実は、大規模開発の難しさを象徴している。また、大規模開発に失敗した場合の業務への影響の大きさは計り知れない。

 

 つまり、「4.6. 速い、安い、うまい」の「部品化、再利用」に記述したように、ビッグバン型の開発は避けるべきだというのが正しい考え方になる。業務ごとの依存関係を分析した上で、的確なシステム分割を行い、システムごとの依存関係を減らし、さらに、各システムを連携するために必要なインタフェースを厳格に定義する。このような考え方で、大規模開発によるリスクを未然に回避することが可能になる。

 

リスク管理の体制

 前述したように、開発プロジェクトのリスクは、ユーザ企業側の大きなリスクである。リスクが顕在化したときに、ユーザ企業側がプロジェクトの意思決定を迅速に行わないと、手遅れの状態を生む可能性は十分にある。さらに、ユーザ企業側がプロジェクトにリスクをもたらす場合も非常に多い。仕様が大きく膨らんだり、仕様の確定や意思決定が遅れたりすることにより、プロジェクトが破綻に一歩近づいていく。プロジェクトのリスクは、ユーザ企業とSIベンダが共有可能でなければならない。つまり、プロジェクトの利害関係者全員がリスク管理計画に参加する必要がある。そして、個々のリスクを両者が理解し、的確かつ合理的判断の下に処理していかなければならない。

 

リスクの抽出と分析

 最初に行うことが、リスクの抽出である。リスクを抽出する上では、過去のプロジェクトにおけるリスク管理の結果を流用することが可能である。システム開発において、「一つとして同じプロジェクトは存在しない」のだが、プロジェクトにおけるリスクや失敗の要因は驚くほど似通っている。

 

 しかし、過去のプロジェクトの結果だけでは十分ではない。さらに、プロジェクトの利害関係者や各チームによるブレインストーミングが必要となる。ブレインストーミングにおいては、抽出したリスクが問題になったときや、その解決責任までを想定して考えることで、抽出されるリスクの量や品質が下がってしまう。このようなことが無いように、リスクの抽出段階においては、

 

  • マイナス思考で考えること
  • 安易な考えを否定し、水をさすこと
  • 自分が解決責任を負わない立場のものであっても指摘すること
  • 解決策まで考えないこと

 

を前提に置き行うべきである。

 

 さらに、工程が進み、プロジェクトの内容が明確になり、作業が詳細化されていく過程で、リスクが変化したり、さらに詳細化されたりする。そのため、各工程の初期段階、中盤、終盤においてもリスクの抽出と分析が必要である。プロジェクトの初期段階におけるリスク分析のみで、リスク管理を終わらせないようにすべきである。

 

 プロジェクトのリスクは、

 

  • スケジュール
  • プロジェクト体制
  • 失敗要因

 

のような観点で行うのが適切である。

 

 さらに、抽出したリスクは、

 

  • 不確定要素
  • コスト損失
  • 納期遅延

 

の三つに分類しておく。

 

 たとえば、スケジュールでは、日程的な要素の他に、各工程やそれぞれの作業におけるリスクを抽出する。プロジェクト体制では、それぞれの役割や相互に依存する関係、チームや利害関係者間のインタフェースや関与レベルといった観点でリスクを抽出する。さらに、どのような事象が発生することで、プロジェクトが破綻していくか、というシナリオを描く。

 

 これらの観点でリスクを抽出したら、それぞれの要素ごとに分類を行う。たとえば、以下のような軸によって分類することが可能である。

 

  • 企業運営や企業戦略
  • プロジェクトスコープ、変更
  • コスト
  • スケジュール
  • プロジェクトメンバの離職、異動
  • 利害関係者の関与

 

 企業運営や企業戦略上のリスクは、ユーザ企業側が行うべきものである。経営陣、企画部門、ユーザ部門によるリスクの抽出が行われない限り、これらのリスクは明確化されない。

 

 プロジェクトスコープや変更は、特に大きなリスクとして捉えることができる。スコープを管理できずに要求が膨らみ、処理しきれずに失敗するプロジェクトや、テスト工程での要件の追加や変更をやみくもに受け入れることで失敗するプロジェクトは後を立たない。ユーザ企業側が合理的な判断を行うにおいて、これらのリスクが十分に抽出され、結果としてどのような影響を与えるかを明確にしておく必要がある。

 

 コストは、プロジェクトの成否に大きな影響を与える。しかし、無尽蔵にコストをかけるわけにはいかない。日本の業務システム開発では、費用が固定された受発注により、ユーザ企業側がコストに対するリスクを負担することが少ないが、その変わりに運用や保守におけるコストを増大させる結果を招いている。コストに関するリスクを取らざるを得ないのが元請けとなるSIベンダである。費用が固定のまま発注を受けているが、業務委託している技術者の残業代まで負担しなければならず、プロジェクトスコープの拡大や納期の遅れが即座にコストに影響する。

 

 スケジュールは、プロジェクトスコープや変更という要素に左右されるが、ここでは個々の作業工数や所要時間の見積りが妥当性を持っているかどうかという観点が重要である。プロジェクトのスケジュールは、たいていの場合、希望的観測に基づいているが、その反面、毎度のようにプロジェクトには「想定外の事象」が発生し、スケジュールの維持は困難なものとなっている。プロジェクトスコープを明確化した上で、それが作業として計画されていること、適切に見積られていることが重要である。

 

 利害関係者の離職や異動もプロジェクトにおける大きなリスクの一つである。ユーザ企業においては、プロジェクトのキーマンの異動による影響が大きい。過去において行われた意思決定を覆すような事態が発生する場合も少なくない。開発側は、連鎖する下請けによって構成されているため、メンバの離職は日常的である。開発側では、「いかに早く新人メンバが他のメンバと同等の生産性を発揮できるようになるか」が重要なポイントである。

 

 利害関係者の関与という問題は、プロジェクトに致命傷を与えることが多い。特に意思決定者が十分に関与し、意思決定プロセスが守られることが必要不可欠である。プロジェクトの利害関係者は、たいていの場合、その利害が対立する傾向にある。それぞれの利害関係者が同じゴールを目指して協業するためには、意思決定者とプロジェクトマネージャの協力により、意思決定プロセスが遵守されることが一番重要である。

 

 抽出されたリスクが、これらの観点により分類されたら、それぞれのリスクに名称を付け、採番する。そして、それぞれのリスクに対して、強度(そのリスクが現実の問題になったときに、プロジェクトに与える影響)、可能性(そのリスクが現実の問題となる可能性)を評価する。だいたい、3〜5段階の評価をすれば十分である。さらに、リスクの発生時期を明確にし、その上で、リスクが現実の問題に変わったときに、どの位の損失が発生するかを定量化する必要がある。プロジェクトの問題は、コスト、納期、品質のいずれかである。しかし、ここでは、コスト(金額)か納期(日数)のいずれかに統一して、影響の大きさを比較できるようにしておく必要がある。問題が品質に影響する場合は、品質指標を満足させるまでに必要となるコストや時間に換算する。

 

 最後に、リスクを現実の問題に変えてしまう、問題の発生要因を明確にしておく。なぜならば、リスクを軽減する上では、問題の発生要因への積極的な働きかけが必要になるからである。たとえば、「仕様が大きく膨らむ」ことがリスクであれば、それは「ユーザ企業側の意思決定者」が問題の発生要因となり、意思決定者に対して、仕様の拡大がどれだけプロジェクトに危機的な状況を生むのかを説明し、合理的な解決を求める必要がある。

 

リスク対策

 リスク管理は、最悪の事態が発生した場合に必要となる莫大なコストを軽減するための保険である。問題を発生させない、あるいは問題発生の影響を限りなく小さなものにするためには、それ相応のコストを必要とする。そのコストを算出するためには、リスクの回避策や危機対策を行うことが必要不可欠である。

 

 現実のプロジェクトでは、リスクに対する危機対策は一般的に行われている。しかし、危機対策が行なわれるタイミングが問題である。これらは、あくまでも事前に計画されるべきもので、リスクが現実の問題となってからでは手遅れになる可能性が高い。さらに、リスクが発生したときの対策だけでは不十分である。リスクが現実の問題となる前に、それを回避したり、軽減したりするための方策を検討し、不必要なコストをかけずに解決できることが重要である。業務システム開発においては、いかに失敗要因を減らしていくか、が成功への鍵を握っているのである。抽出したリスクのうち、回避可能なものは積極的に回避するようにしておきたい。前述したように、取るべきではないリスクは事前に回避するべきである。

 

 続いて重要になるのが、リスクに対する代替案の提示である。代替案によってリスクが回避できたり、リスクが問題となった場合の対処に必要な時間やコストを削減することができたりする。解決策を検討する上では、やり方を変えることでリスクを低下させる手段を講じることが重要である。

 

 リスクの移転を検討することも重要だ。プロジェクト範囲の一部をアウトソーシングすることでリスクを移転するのが一般的な方法である。たとえば、本番環境のサーバ構築や設定作業をアウトソーシングすることで、その作業に必要なリソース割り当てや、スケジュールの管理コストなどの手間や、構築の責任をアウトソーシング先に移転することができる。

 

 回避、代替案、移転の対策を講じた後に残ったリスクには、危機対策を検討する必要がある。危機対策には、

 

  • リスクがどのような事象として発生するのか
  • どのようなタイミングで
  • 誰が
  • どのような手段で
  • いつまでに
  • どの位のコストをかけて

 

解決するのかを、明確にしなければならない。迅速な問題処理をするためには、十分に検討された危機管理計画を文書化し、プロジェクト計画書に含めておく必要がある。

 

 これらのリスク対策手段を検討する上では、

 

  • リスクが問題となった場合にプロジェクトに与える影響の低下
  • リスクが問題となる確率の低下

 

という二つの観点が必要となる。

 

リスクの監視

 継続して行わなければならないのが、リスクの監視である。採番された個々のリスクのうち、回避策により回避できたもの、代替案によりリスクではなくなったもの、リスクを移転させたもの以外は全てを監視しなければならない。さらに、前述したように、各工程でのリスクの見直しや詳細化までを含め、十分に監視しておく必要がある。

 

 リスクの監視は、プロジェクトにおいて一般的に行なわれる課題管理と同様のステータスを付けて管理する必要がある。リスクを監視する上では、危機管理対策に明記した作業プロセスに従って進捗していることを管理しなければならない。その上で、全てのリスク項目のステータスが完了に至ることが重要である。そのリスクが「完了」したかどうかは、以下の観点から判断することができる。

 

  • リスクの発生タイミングを過ぎても、リスクが問題とならなかった
  • 問題の発生を事前に防止できた
  • 問題となったが、危機対策を実施し、処理が完了した

 

 実際のプロジェクトでは、リスクが問題へと変化した場合、プロジェクトのその場その場の状況に応じた解決策が必要となる場合も少なくない。当初の計画通りの解決が望めない場合には、すみやかに現実的な解決策を策定しなおす必要がある。また、リスク管理の結果に至るまでの過程を記録しておくことで、将来のプロジェクトにおける再利用が可能になる。

 

 リスクを監視する上で重要なことは、リスクが問題となる前に、適切なタイミングでリスク事象を発生させる要因に対する働きかけをすることである。いかにコストをかけずに、問題を小さくしていくか、ということを常に念頭に置き、プロジェクトに発生する様々な変化に対応していかなければならない。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

11.7. リスク管理プロセス ハッピィ・エンジニアリング関連ページ

11.1. リスク管理とは
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
11.2. 現実のリスク管理
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
11.3. 文化的な背景
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
11.4. リスク管理への間違った意識
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
11.5. リスク管理を根付かせる
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
11.6. リスク管理のメリット
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング