これまでさまざまな開発現場で多数のプロジェクトのテストマネジメントを担当してきましたが、その中で最も多く遭遇した問題の一つが、
- プロジェクトリスクとプロダクトリスクが整理されないまま議論が進む
という状況でした。
2つが混ざると、
「どこから手をつけるべきか」「何を優先して対策すべきか」が曖昧になり、結果的に後半で苦しくなることが多いです。
この記事では、この2種類のリスクの違いと、実務でどう見分ければいいのかを、できるだけシンプルに紹介します。
リスクの違い
2つのリスクの違いは以下の通り。
- プロジェクトリスク：作り方（プロセス）に潜むリスク
- プロダクトリスク：作ったもの（成果物）に潜むリスク
もっと短く言うと、
「進め方の問題」ならプロジェクトリスク、
「できるものの問題」ならプロダクトリスク。」
これだけで、かなり分類しやすくなります。
プロジェクトリスクとは
プロジェクトを進める活動そのものに影響するリスクです。
例
- スケジュールが厳しく、品質活動に割く時間が足りない
- 仕様が曖昧・頻繁に変わる
- メンバー間で認識に差がある
- リーダー変更で意思決定が揺れる
- テスト方針がなく、属人的な進め方になっている
いずれも プロダクトそのものの欠陥ではなく「進め方の問題」 です。
プロダクトリスクとは
プロダクトの品質に直接影響するリスクです。
例
- 基本フローで誤実装の可能性がある
- データ整合性が崩れる恐れがある
- UIの一貫性が保たれず誤操作が起きやすい
- 負荷に耐えられない可能性
- 重要機能に十分なテストが行われていない
こちらはプロダクトが世に出た時にユーザー影響として現れるものです。
なぜ混同しやすいのか
たとえば「リリース後に障害が多発した」という現象があった場合、
表面上は「品質問題」に見えます。
しかし実際には、
- テスト計画がなかった（プロジェクトリスク）
- 重要機能の特定が漏れていた（プロダクトリスク）
と、両方が原因であることが多いです。
つまり、
プロダクトに症状が出ても、原因がプロジェクト側にあることは珍しくない。
だから混ざりやすいのです。
見分け方の問いかけ
分類に迷ったら、次の問いかけでほぼ判断できます。
① これはプロダクトが壊れるリスクか？
YES → プロダクトリスク
② これは進め方の問題か？
YES → プロジェクトリスク
シンプルな判定例
- 「ユーザー影響が出るか？」
- YES → プロダクトリスク
- NO → プロセスの問題ならプロジェクトリスク
“セットで見つける” ことが大事
リスクは多くの場合、
プロジェクト側とプロダクト側の両方に存在しています。
例）テスト方針がない
- プロジェクトリスク：計画不備で進め方が危うい
- プロダクトリスク：重要機能のテストが網羅されない可能性
どちらか一方だけを見ると、どうしても抜け落ちます。
実例：意思決定が揺れたプロジェクト
過去に担当したプロジェクトで、途中でリーダーが交代したことがありました。
プロジェクトリスク
- 意思決定の軸が変わり、優先順位の基準が揺れる
- 仕様の解釈がずれ、チーム内の認識に差が出る
- テスト計画が曖昧になり、テストの粒度がばらつく
プロダクトリスク
- 基本フローのテスト不足による障害が連発
- 仕様変更の取り込み漏れによる不具合
- リリース後の手戻りで次フェーズも遅延
影響はプロダクト、原因はプロジェクトという構図がよくあります。
まとめ
- プロジェクトリスクは「作り方」の問題
- プロダクトリスクは「できるもの」の問題
- 実務では両方セットで存在することが多い
- 判定は「ユーザー影響」か「進め方の問題」かで判断できる
- 見分けるだけで議論が揃い、対策も明確になる
プロジェクトの問題が“どちら側のリスクなのか”を整理できると、
リスクの把握も対策も圧倒的に進めやすくなります。