プロジェクトをやってきてもっとも思うことが、
「プロジェクト成功のコツを何かひとつ」といわれたら、
「先読み」と答えるということです。
プロジェクトマネジメントとしては、ＰＭＢＯＫでも「リスクマネジメント」として一つの項目になっています。
今回は、プロジェクトマネジメントでも重要な位置をしめるリスクについてお話します。
リスクマネジメントとは
プロジェクトは先読みが重要と先ほど書きました。
語源としても、「プロジェクト＝pro+ject」(pro)前に＋(ject)投げ込む、
ということで、先々までの見通しをたてることを意味していると思います。
語源はおいておいても、リスクの先読みがプロジェクト成功のカギであることは、数十のプロジェクトマネジメントの経験と知り合いのＰＭがみんな口をそろえて言っています。
では、リスクとは何か、課題と何が違うのかということですが、課題はプロジェクトとしては解決すが必須のものです。
既にプロジェクトに影響を与える問題になっているか、今やっておかないとあとあと問題になるかは別としても解決が必要なので、担当をアサインして対応していく必要があります。
一方、リスクとは、望ましくない事象、あるいは望ましくない結果が顕在化してしまうと、プロジェクトが混乱する可能性があるものをいいます。
言い換えれば、発生するかしないかわからないけど（不確実性）、発生したら対応しないとプロジェクトに影響（損失）がある、というものです。
それを考えると、「発生確率が高い」リスク、「損失が大きい」リスクに対しては、なんらかの手を打っておいた方が良いということで、このなんらかの手を打てるか打てないかが、プロジェクト成功に大きく効いてくるのです。
リスクへの対応は、おもに４つの手段があるといわれます。
リスク対応手段としては
回避(avoidance)
リスクの原因を除去することです。
例えば「インターネットへの顧客情報漏洩回避のため、顧客情報は外部から物理的に遮断したサーバーに格納する」など。
軽減(mitigation)
損失の発生率を低下させることです。
例えば「新技術使用時は、事前に技術適用検証して問題の有無を確認しておく」など。
転移(transfer)
他社とリスクを共有することです。
例えば「リスク発生時にはお客様から追加で費用をもらえる調整をしておく」「保険加入」など。
受容(accepte)
リスクが顕在化しても,その影響が小さいと想定されるため、損害の負担を受容するリスク対応のことです。
例えば「ボールペンはなくしても影響はすくないので特に対策を行わない」など。
プロジェクトマネージャは、リスクマネジメントに対して常に意識しておくべきです。プロジェクトが動き出すとき、プロジェクト計画を作成するとき、プロジェクトのある工程から次の工程に移る前の事前準備タイミングには、特に注意して、リスク管理をしておくべきです。
リスク項目一覧とその対応
リスクになる項目はたくさんありますが、特に気をつけている内容を列挙してみました。
- プロジェクト特性、特殊な要件がないかどうか
- プロジェクト予算、お客様が予算不足にならないか
- 要件・仕様の明確さ、あいまいで変更発生の可能性、特に多発の可能性はないか
- プロジェクトのスコープ・範囲が適正になっているか、目標を達成できるか、過剰品質になっていないか
- 性能などの非機能要件が明確になっているか、お客様がサービスレベルを明確に定義してくれているか
- スケジュールと作業内容が妥当か、期間的に無理なスケジュールになっていないか
- 作業量は見積れているか、コスト見積りは妥当と考えられるか その根拠は明確か
- プロジェクトの体制として必要な経験者（管理、業務、技術）がアサインされているか、確保可能か
- 未経験の技術要素がないか、リリース直後の最の技術や製品などの利用予定はないか
- お客様のステークフォルダがプロジェクトに十分に時間をさける状態か
- プロジェクトの契約条件、完了基準がお客様と合意できているか、文書化され承認確認ができるか
- コミュニケーションは良好か、プロジェクト内の人間関係がぎくしゃくしていたりしないか
このあたりのリスクを頭に入れながら、必要に応じてリスクに対して具体的な調整も行います。
特に影響が大きそうな下記リスクへの対応の考え方を整理しました。
リスクへの対応は、納期・品質・コストへの影響もあるため、ステークフォルダーとの合意形成も重要になります。
納期（短納期、規模、難易度からみて納期が厳しいリスク）
納期の延長：スケジュールを伸ばします。
スコープの縮小：開発対象の機能を減らします。または、段階的立上げにします。
要員山積みの変更：並行稼働のタスクを設けます、必要に応じてコストも調整します。
資源アサイン（必要な要員が集まらないリスク）
調達先の開拓：新規調達先の開拓したり、既存のビジネスパートナーと調整します。
他業務からのアサイン変更：プロジェクトの重要度、優先度を考慮して他部署から要員を調達します。
その他から調達：派遣、ネット募集等での要員確保を行います。
スキル（開発する業務や利用する技術に対して、スキル不足のリスク）
利用技術変更：既存のスキルで対応可能な構成や製品、開発言語等に変更します。
教育・検証：必要なスキルに対しての事前教育、事前検証（フィージビリティスタディ）を実施します。
スキル保有者の追加アサイン/アサイン変更：外部のスキルのある企業に支援を依頼して、プロジェクトに参加してもらいます。
コスト（開発規模と必要な要員に対してコスト不足のリスク）
スコープの縮小：開発対象の機能を減らします。
品質レベル合意：品質レベルを下げます。テストレベル/範囲の調整と紙面での合意を行います。
投資判断：プロジェクトの将来の価値を踏まえて、投資判断を仰ぎます。
協力会社との調整・活用：パートナー会社に不利益にならない範囲でのコスト調整を行います。
コミュニケーション（人間関係リスク）
情報伝達のツール活用、コミュニケーション運用の定義：コミュニケーションを円滑にするためのツールを適用、会議体を明確にします。
人間関係の場合はアサイン変更：可能な範囲でのチームアサインの変更を検討します。
上記の６つのリスクへの対応は、リスクがリスクではなく課題になった後でも対策は類似のものになると考えられます。
上記のことが、発生可能性が高いにしてもリスクである場合には、可能性に向けて調整準備をしておくことで対応が早くなると思いますが、実際にリスクから課題になった場合には迅速な対応が求められます。
納期・品質・コスト面で課題が発生して、対応しないとプロジェクトが立ち上がらないと判断した場合には、断固としてステークフォルダーと調整し、プロジェクト成功のために対策を打つ必要があります。
課題・問題の場合、調整がきかないのであれば撤退すら辞さない態度がプロジェクトマネージャーとしては重要です。
プロジェクトが失敗すると結局、困るのはお客様なのです。
ステークフォルダー間では、リスクを共有し、円滑なプロジェクト運営のために一丸となってプロジェクトを推進していきたいものです。
プロジェクトの悩み事へのご支援
これまでの経験やノウハウをもとに、プロジェクトに対するコンサル、ご支援/ＰＭＯ、プロジェクトマネージャの育成などを実施しております。
本記事をお読みいただきご興味のある方、ご支援・ご相談などは、遠慮なく下記よりご連絡いただけると幸いです。
