プロジェクトのトラブルを未然に防ぐ方法【プロジェクトマネジメントの基礎】
プロジェクトにはトラブルがつきものです。やっかいなことに、トラブルの発生確率はプロジェクトの難易度とともに高まります。
プロジェクト・マネジャーはトラブルが発生しないよう、発生したとしても被害が大きくならないよう、事前に準備をしておくことが大切です。
今回はプロジェクトのトラブルを未然に防ぐ方法を解説していきます。
予測不可能なことの種類
プロジェクトのトラブルは予測不可能な事態から発生します。
プロジェクトマネジメントのガイドラインであるPMBOK第７版では、予測不可能さを以下のように分類しています。
曖昧さや複雑さは、作業内容を調べることや、内容を具体化していくことで解消することができます。
しかし、変動性やリスクについては完全に解消することは難しく、事前に起きうる現象を予測し、対応する必要があります。
プロジェクトには様々な不確かさがあります。たとえば、屋外でのイベントを企画しているとします。イベント当日に天気が晴れかどうかはその日になってみないとわかりません。しかし、その不確かさを把握し、事前に対策を講じなければ、プロジェクトが失敗してしまうこともあります。
PMBOK第７版の不確かさパフォーマンス領域では、不確かさをはじめ、以下の予測不可能な状態に注目しています。
- 不確かさ
- 曖昧さ
- 複雑さ
- 変動性
- リスク
ここからは、これらの対処法を見ていきます。
不確かさ
PMBOKでは予測不可能な状態を包括して「不確かさ」と呼んでいます。不確かさに対応するために、PMBOKでは以下の対策を紹介しています[1]PMBOK第７版、119頁。。
- 情報を収集する
- 複数の計画・設計・代替案を用意する
- 回復力を養う
曖昧さ
曖昧さには、概念的な曖昧さと状況的な曖昧さがあります。
概念的な曖昧さへの対処法
概念的な曖昧さは理解の欠如により発生します。
たとえばあるプロジェクト・メンバーが「来週にはデザインのモックアップを作ります」という報告をしたとします。この短い報告の中にも「来週というのは具体的にいつを指すのか」「モックアップとはどのような成果物ができるのか」という曖昧さがあります。
報告したプロジェクト・メンバーは「来週金曜日くらいにデザインの設計図を提出しよう」と考えているかもしれませんが、「来週の水曜日にはデザイン案ができるだろう」と捉えるステークホルダーもいるかもしれません。
このようなトラブルを回避するためにも、言葉の定義を明確にし、共通のルールなどを設ける必要があります。
状況的な曖昧さ
状況的な曖昧さは状況に応じて成果が変化することにより発生します。
たとえばデザイン案を２つ用意した場合、採用されたデザインでその後のプロジェクトは多かれ少なかれ変化します。その変化が当初予定されていた計画に合致していれば問題はありませんが、計画から外れてしまっては、その後の進行でトラブルが発生してしまうこともあるでしょう。
こうした問題には、以下の対処法があります。
- 反復
- 実験
- プロトタイプ
プロジェクトは段階的詳細化という特性があるので、プロジェクトの開始直後に立てた計画では、進行とともに現状にそぐわない部分もでてきます。
そのため、計画は一度作成したら終わりにするのではなく、反復し、計画を見直すと状況的な曖昧さを軽減することができます。
また、実験をしたり、プロトタイプを作成することにより、状況的な曖昧さを小さくすることができます。
複雑さ
複雑さとは、人間やシステムの振る舞いや、曖昧さのためにマネジメントが困難なプログラムやプロジェクト、環境を指します[2]PMBOK第７版、120頁。。
PMBOKではこの複雑さの対処法をシステムベース、再構成、プロセスベースという３つに分けて解説しています。
システムベース
システムベースの対処法には、「デカップリング」と「シミュレーション」があります。
デカップリング（切り離し）
デカップリングとは、組み合わされていたもの（カップリング）を切り離すことです。つまり、システムの一部を切り離し、対処しやすい規模にすることで、複雑さに対処します。
シミュレーション
シミュレーション、つまり類似のデータやモデルを用いることでも、複雑さに対処することができます。たとえば、ある商業施設にこれまでになかったお店を出店するとします。そのお店の売上を考えるのは難しいことです。しかし、出店する場所の近くのお店のデータや、似ているお店の消費者の習慣を想定することで、新しいお店の売上を予測することができるかもしれません。
このように類似するデータやモデルを用いることで、一見複雑で対処できそうにない問題に取り組むのがシミュレーションです。
再構成
再構成とは、複雑さを感じているものごとを構築し直すことを意味しています。
たとえば、ブレインストーミングなどで様々な意見を取り入れたり、お互いの悪い影響を打ち消すような構成要素を組み合わせたりして、システムを作り変えていきます。
プロセスベース
プロジェクトの進め方（プロセス）を工夫することにより、複雑さに対処することもできます。
たとえば、反復型や漸進型の開発アプローチを採用することにより、複雑なものごとを徐々に解決することができます。また、何か問題が発生した時に、その機能を制限することで安全に使い続けられるようにする「フェールソフト」を採り入れることも大切です。
さらに、プロジェクトが複雑になる原因に制限の多さも挙げられます。「定期的に報告する」「○○の承認の前に××の部署に確認を取る」など、プロジェクトの進め方に関する制限はステークホルダーに拠ることが多いので、この制限を少しでも緩和・削減するためにも、ステークホルダーのエンゲージメントを高めることも重要です。
ステークホルダーと良好な関係を築くことによって、不信からくる制限などを取り払うことができます。
変動性
変動性には、たとえば為替の変動などが挙げられます。為替変動により、海外から仕入れた材料のコストが増大してしまった場合、何も準備をしていなければ、予算オーバーになりかねません。
そのため、変動性にもあらかじめ準備しておかなければなりません。
変動性が高い環境、つまり急激で予測不可能な変化が発生する環境には、代替案分析や予備を設けることで対応します。
代替案分析については、下記の記事をご参照ください。
https://ssaits.jp/promapedia/method/alternative-analysis.htm...リスク
リスクとは、発生するかどうかが定かではないイベントや状況のことです。たとえばプロジェクト・メンバーの入院や突然の災害などがリスクとして挙げられます。
「リスク」という言葉は負のイメージがありますが、プロジェクトにプラスの影響を与えるリスクもあります。
しかし、プロジェクト・マネジャーとして準備しなければならないのは、主にマイナスの影響を与えるリスクです。
プロジェクト中に発生するリスクを想定し、事前に準備することでプラスのリスクの効果を高め、マイナスのリスクの影響を軽減することをリスク・マネジメントと呼びます。
リスク・マネジメントは以下のように進めていきます。
- リスクの特定
- 分析
- 計画
ここからは、これらの内容を解説していきます。
リスクの特定
リスクの特定では、プロジェクトで発生する可能性のあるリスクを洗い出していきます。
洗い出しの方法は様々ありますが、たとえばデルファイ法で専門家の意見を聞いたり、プロジェクト・チームで話し合ったりする方法があります。
リスクの洗い出しが上手くいかない場合は、「どのようなリスクがあるのか？」と考えるのではなく、「プロジェクトが失敗したとすると、どのような原因が考えられるか？」という発想にするとアイデアが出やすいかもしれません。
このような手法を事前検死と呼びます。
このようにして洗い出したリスクはリスク登録簿としてまとめておくと、管理がしやすくなります。
| リスクの事象 | リスクが発生する原因 | 発生する確率 | 優先度 | リスクの対策 |
|---|---|---|---|---|
| 開発が予定していた期日をすぎても完了しない | 把握していない仕様の発見 プログラマーの力量不足 | 高 | 高 | あらかじめ仕様について話し合いの場を持つとともに、X月X日に中間報告を行い、進捗を確認し、スケジュール遅れが発生しそうな場合は対策をとる。 |
| 開発の途中で仕様変更が入る | ステークホルダーの仕様に対する理解不足 | 中 | 中 | あらかじめステークホルダーに対して仕様の説明をするとともに、プロトタイプを作成し、実際に動くアプリケーションで挙動を確認してもらう。 |
| アサインしていたプログラマーが長期間稼働できなくなる | 不測の事故や病気 | 低 | 低 | 他のプログラマーの候補者をリスト化しておき、このリスクが発生した時点で、連絡をとるようにする。 |
リスク登録簿については、下記のページもご参照ください。
分析
洗い出されたすべてのリスクに対応することは予算や資源の都合上、容易ではありません。
そのため、リスクの内容を分析し、影響度や発生確率を査定し、影響度や発生確率の高いリスクから重点的に対応します。
リスクの発生確率を見積ることは容易ではありませんが、過去のデータやシミュレーションなどにより、おおよその数値を算出していきます。
厳密に「何％」と出す必要はなく、発生確率を「高」「中」「低」などに段階分けするだけでも良いでしょう。
リスクの影響度はディシジョン・ツリー分析やWhat-ifシナリオ分析などを使って見積ります。
発生確率と影響度が見積れたら、発生確率・影響度マトリックスを使い、発生確率と影響度の高いリスクに対応していきます。
発生確率・影響度マトリックスについては、下記のページもご参照ください。
計画
重点的に対応しなければならないリスクが判別できたら、あとはそのリスクが発生した際にどのような対応をするかを協議し、その対応内容をまとめていきます。
対応内容はリスク登録簿に追記していく形にすると、管理がしやすくなります。
さいごに
今回はプロジェクトのトラブルを未然に防ぐ方法を紹介しました。
「遅延しているソフトウェアプロジェクトに新規に要員を追加しても、想定通りには改善されず、むしろますますスケジュールを遅延させてしまう」というブルックスの法則が示すように、プロジェクトでトラブルが発生し、スケジュール遅延が起きると、再び当初のスケジュールに戻すことは容易ではありません。
そのため、プロジェクトではトラブルをあらかじめ想定し、発生しないように対応したり、発生したとしても影響が広がらないように準備をしたりする必要があります。
もしトラブルが発生しても、場当たり的な対応では、余計にプロジェクトは混乱してしまいます。
影響度が高く、予想もしていなかったトラブルが発生した場合は、主要なステークホルダーを集めて協議し、プロジェクトを立て直す十分な期間を設けて対応していくことが大切です。