プロジェクトリスクとは？種類、例、リスク記述

プロジェクトリスクとは？

プロジェクトリスク とは、発生した場合に1つ以上のプロジェクト目標にプラスまたはマイナスの影響を与える、不確実な事象または状態です。PMIはPMBOKガイドでこの定義を用いています。重要な考え方は、不確実性（起こるかもしれないし起こらないかもしれない）、未来（まだ起きていない）、そしてプロジェクトが達成しようとしていることへの影響です。

この3つの考え方は、判定に役立ちます。確実なことであれば、それはリスクではなく、計画に織り込むべき事実です。すでに起きたことであれば、それは 課題です。スコープ、時間、コスト、品質、期待される便益に影響しないのであれば、プロジェクトリスクとして追跡する価値はありません。

• リスクが影響しうる目標： スコープ、スケジュール、コスト、品質、便益、安全、評判、ステークホルダーの満足度。
• リスクではないもの： 確実なこと（「オフィス移転は3月」）、現在の問題（「サーバーがダウンしている」）、漠然とした懸念（「人員配置」）。
• 重要な理由： プロジェクトは有期的で独自のものなので、常に不確実性を伴います。早めに名前を付けておけば、選択肢がまだ安価なうちに対応する時間が得られます。

最新版の PMBOKガイド （第8版、2025年11月発行）でも、リスクはパフォーマンス領域の1つとして維持されており、まだ発生していないリスクと、すでに発生した課題とを引き続き区別しています。

脅威と好機

「リスク」と聞くと、多くの人は悪いことを思い浮かべます。しかしプロジェクトマネジメントでは、リスクはどちらの方向にも働きます。

チームが偶然に好機を見つけることはめったにありません。リスクワークショップで「計画より良くなりうることは何か、どうすればその可能性を高められるか？」と直接問いかけましょう。典型的な好機には、他のプロジェクトの成果の再利用、価格の下落、早期の承認、サプライヤーの前倒しでの完了などがあります。

リスクの3つの要素：原因、事象、影響

うまく記述されたリスクには3つの要素があります。これらを分けることで、チームがリスクの理由をリスクそのものやその結果と混同するのを防げます。

簡単なテンプレートを使えば、3つの要素を1つの文にまとめられます： 原因 [原因]により、 リスク： [事象]が起こるおそれがあり、 影響 [影響]につながる。

プロジェクトのリスク記述の書き方

リスク記述とは、次に記入する文のことです： リスク登録簿。うまく書けば、評価、責任者の割り当て、対応策の策定がはるかに容易になります。

1. 原因から始める。 制約条件、前提条件、依存関係など、不確実性を生み出す事実や状態を記述します。
2. 不確実な事象を1つ記述する。 「かもしれない」を使います。事象が2つある場合は、2つのリスクに分けましょう。
3. 目標への影響を記述する。 遅延日数、コスト、失われるスコープ、影響を受ける品質など、できるだけ測定可能にします。
4. 課題や確実なことでないか確認する。 すでに起きている、または確実に起きるのであれば、別の方法で扱います。
5. 誰かが行動できるか確認する。 良い記述からは、誰が責任者になるべきか、どのような対応策がありうるかが見えてきます。

プロジェクトのリスクの種類

リスクを種類別にまとめると、特定作業がすべての領域を網羅しているか確認でき、プロジェクト間でリスクを比較するのにも役立ちます。公式の一覧は1つではないので、自組織に合ったカテゴリーを使いましょう。下表は一般的な例です。

多くの組織は、カテゴリーをリスク・ブレイクダウン・ストラクチャー（RBS）に落とし込んでいます。これはリスクの発生源を階層化したもので、次に似ています： WBS（ワーク・ブレークダウン・ストラクチャー）。ワークショップでこれを順にたどると、抜け漏れをすばやく見つけられます。

個別リスクとプロジェクト全体のリスク

PMIは、 個別のプロジェクトリスク（登録簿に記載された特定の事象）と、 プロジェクト全体のリスク（あらゆる不確実性がプロジェクト全体に与える影響）を区別しています。単独で重大なリスクが1つもなくても、多数の中程度のリスク、野心的な目標、複雑さのために、プロジェクト全体としては非常にリスクが高いことがあります。全体のリスクは通常、スポンサーや役員会のレベルで議論され、次のような手法で見積ることができます： モンテカルロ・シミュレーション.

既知のリスクと未知のリスク

• 既知のリスク は、すでに特定・分析されたリスクです。これらには対応策を計画し、通常はその期待コストをコンティンジェンシー予備でカバーします。この予備が含まれるのはコストの ベースライン.
• 未知のリスク は、事前に特定できないリスクです。組織はこれをベースラインの外に保持するマネジメント予備でカバーし、ガバナンスを通じて解放することがよくあります。
• 創発的リスク は、プロジェクトが進むにつれて初めて見えてくるリスクです。そのため、特定作業は全期間を通じて続ける必要があります。

プロジェクトリスク、ビジネスリスク、オペレーショナルリスク

プロジェクトリスク は、合意したスコープを期限内、予算内、品質どおりに届けるという、プロジェクト自体の目標に影響します。 ビジネスリスク は、組織全体の目標に影響します。たとえば、新製品が発売後に売れるかどうかです。 オペレーショナルリスク は、引き渡し後の日常的な事業運営に存在するリスクで、システム障害などです。3つは互いに関連しています。プロジェクトはビジネスリスクを減らすために存在することが多く、プロジェクト中の手抜きが後にオペレーショナルリスクを生むこともあります。

試験対策ガイドでは、さらに 投機的リスク（利益にも損失にもつながりうる）と、 純粋リスク（火災や盗難など、損失にしかつながらない）を区別しています。純粋リスクは保険によって転嫁されることがよくあります。

業界別のプロジェクトリスクの例

実際のリスク記述はプロジェクトに固有のものです。以下の例は、さまざまな状況で脅威と好機がどのように表れるかを示しています。

よくあるプロジェクトリスクと早期警告サイン

ほぼすべてのプロジェクトに現れるリスクがあります。その早期警告サイン、つまり トリガーを知っておけば、課題になる前に行動できます。

責任者が何に注意すべきかわかるように、各リスクの横にトリガーを記録しましょう。 ステークホルダー・マネジメント のガイドでは、人に関わるリスクの多くをより詳しく取り上げています。

記録すべきリスクの属性

リスク記述だけでは、リスクを管理するには不十分です。ほとんどのチームは、各リスクについて次の属性を記録しています。

当サイトの無料の リスク登録簿テンプレート には、主要な属性と、発生確率 x 影響度の自動スコアが含まれています。

リスク、課題、前提条件、制約条件の違い

これらの用語はよく混同されます。それぞれ扱い方が異なるため、区別しておく価値があります。

前提条件は、リスクの最良の発生源の1つです。それぞれの前提条件について、誤りだと判明したらどうなるかを問いましょう。答えが深刻なら、リスクとして記録します。 RAIDログ はリスク、前提条件、課題、依存関係をまとめて管理でき、小規模なプロジェクトに適しています。詳しくは RAIDログテンプレート.

プロジェクトのリスクを特定する方法

リスクの特定は、立ち上げ時に始まり終結まで続くチーム活動として行うのが最も効果的です。

1. プロジェクト文書をレビューする。 次を読む： プロジェクト憲章、スコープ、スケジュール、予算、前提条件、制約条件を読み、何が違った形で進みうるかを問いかけます。
2. 前提条件を検証する。 それぞれについて、どの程度確信があるか、誤っていたらどうなるかを問います。
3. 作業を順にたどる。 作業分解構成図とスケジュール、特にクリティカルパスと外部との依存関係を順に確認します。
4. リスクワークショップを開催する。 チーム、スポンサー、ユーザー、主要サプライヤーを集め、カテゴリー別に脅威と好機をブレインストーミングします。
5. 過去の経験を活かす。 必ず確認： 教訓 や、類似プロジェクトのリスク登録簿を確認します。
6. 専門家に尋ねる。 方法は次のとおりです： 専門家の判断 （技術、法務、安全、商務の分野について）。
7. 体系的な手法を使う。 チェックリスト、リスク・ブレイクダウン・ストラクチャー、SWOT分析、根本原因分析ツール（例： 特性要因図（フィッシュボーン図） ）は、チームが明らかなこと以外にも目を向けるのに役立ちます。
8. 記録し、割り当てる。 各リスクを原因、事象、影響の形で記述し、登録簿に記録して責任者を指名します。

特定は、分析、対応計画、監視を含むより広いプロセスの最初のステップです。

リスクに関する用語

対応策を講じたら、各リスクを再評価して何が残っているかを確認しましょう。

アジャイルプロジェクトにおけるプロジェクトリスク

アジャイルの働き方は、その設計上、多くのリスクを低減します。短いイテレーション、頻繁なデモ、優先順位付けされたバックログによって問題が早期に表面化し、方向転換した場合に失われる作業量も限られます。それでも、リスクへの注意は必要です。

• 別の会議だけでなく、スプリントプランニング、デイリースタンドアップ、レトロスペクティブでもリスクを提起する。
• 技術的なリスクの高いものには早めに取り組む。たとえば、初期の次の中でタイムボックスを設けたスパイクを行う： スプリント.
• リスクを低減する作業をバックログに追加し、機能と並べて優先順位を付ける。
• 明確な 完了の定義 を使って品質リスクを低減する。
• 複数のスプリントにまたがるリスクや他のチームに依存するリスクについては、簡易なリスク一覧やボードを維持する。

プロジェクトリスクを記述する際のよくある間違い

• リスクではなくカテゴリーを書くこと。 「人員リスク」は評価も責任者の割り当てもできませんが、「リード開発者が第2四半期に退職するかもしれない」ならできます。
• 課題をリスクとして記録すること。 すでに起きているなら、課題ログに移して今すぐ対応しましょう。
• 確実なことを列挙すること。 わかっている祝日は計画上の事実であり、リスクではありません。
• 1つの記述に複数の事象を混ぜること。 それぞれを評価し責任者を割り当てられるように、分けましょう。
• 好機を無視すること。 脅威しかない登録簿では、より早く、より安く終える方法を見逃します。
• リスクを一度だけ特定すること。 新しいリスクはどのフェーズでも現れます。各ステージゲートや重要な変化があったときに一覧を見直しましょう。
• 責任者がいない。 責任者が指名されていないリスクは、ほとんど管理されません。

このトピックの無料テンプレート

すべてのテンプレートを見る

よくある質問