リスク管理 – プロジェクトの“未知の未知”を炙り出す実践ワークショップ手順

“未知の未知”とは何か

プロジェクトを進めていると、こんなことはないでしょうか。

• 想定していなかった利害関係者から急に横やりが入る
• 法規制や社内ルールの制約に、リリース直前で初めて気づく
• 外部サービスの仕様変更など、前提条件が突然崩れる

こうした「誰も気づいていなかった問題」は、よく「未知の未知（unknown unknowns）」と呼ばれます。

リスク管理では、対象を次のように分けて考えることがあります。

• 既知の既知：
  みんなが知っていて、リスクとしても認識していること
• 既知の未知：
  「たぶん問題になるかもしれない」と分かっているリスク
• 未知の既知：
  誰かは知っているが、プロジェクト全体に共有されていないこと
• 未知の未知：
  誰も意識していない、想定外のリスクや前提

通常のリスク洗い出しでは、「既知の既知」「既知の未知」を主に扱います。一方で大炎上を引き起こすのは、多くの場合この「未知の未知」です。

本記事では、「未知の未知」を完全になくすことはできない前提に立ちつつ、それでも事前に“炙り出しやすくする”ためのワークショップ手順を解説していきます。

“未知の未知”を炙り出すワークショップの全体像

“未知の未知”ワークショップは、特別なフレームワーク名が付いた高度な手法というよりも、次のような目的を持った「場づくり」のことだと捉えるとイメージしやすくなります。

• 今は言語化されていない不安やモヤモヤを、参加者から引き出す
• 普段は見落としがちな視点（ユーザー、運用、法務、現場担当者など）を意識して議論する
• 「こんなこと言ったら怒られるかも」を出しやすくする心理的安全性の高い場を作る

どんなタイミングで実施するか

たとえば、以下のようなタイミングで行うと効果的です。

• 要件定義フェーズの終盤（仕様が固まりつつある時期）
• 基本設計〜詳細設計の境目
• 大きなマイルストーン前（リリース前、外部公開前など）
• 過去に似たプロジェクトで大きな炎上があった場合の再発防止策として

期待するアウトプット

ワークショップの成果として、最低限次のようなアウトプットを目指します。

• 「これまで出ていなかった新しい懸念点・リスク・前提」がリストアップされていること
• それらに簡単なカテゴリや優先度が付いていること
• 次の一歩（調査、検討、対策検討など）が決まっていること

この全体像を参加者と共有したうえで、具体的な手順に入っていきます。

事前準備：目的設定・参加者・インプット整理

“未知の未知”ワークショップを成功させるには、当日よりもむしろ「事前準備」が重要です。

目的とテーマを一言で言語化する

曖昧な目的のままだと、話題が散らばってしまい、結局何も決まらなかった…ということになりがちです。
次のように「一言で言えるテーマ」に落とし込んでおきます。

• 例：
  • 「本番リリースまでに潜む想定外のリスクを洗い出す」
  • 「運用フェーズで起こりうるトラブルのタネを見つける」
  • 「ユーザー体験を損なう落とし穴を事前に発見する」

参加者の選び方

“未知の未知”を炙り出すには、多様な視点が必要です。可能であれば次のようなメンバーをバランス良く入れましょう。

• PM / PL（ファシリテーターを兼ねることが多い）
• 開発メンバー（設計・実装担当）
• テスト・品質保証担当
• 運用・保守担当
• ビジネス側（企画、営業、カスタマーサポート）
• 必要に応じて、法務・セキュリティ・インフラ担当 など

「プロジェクトの外から冷静にツッコミを入れてくれる人」を1名入れるのも有効です。

用意しておく資料

当日、参加者がイメージしやすいよう、次のような資料を用意しておきます。

• プロジェクトのゴール・スコープ（簡単な1〜2枚の説明資料）
• 現時点のWBSやマイルストーン一覧
• 主要なステークホルダー一覧
• 過去プロジェクトの振り返り資料（トラブル事例などがあればベスト）

資料は「読み込ませる」のではなく、議論するための地図として使える程度で十分です。

当日の進め方①：オープニングと場づくり

ワークショップ当日の前半では、参加者が「遠慮せずに本音を出せる状態」になるよう場を整えます。

ゴールとルールの共有

最初の5〜10分で、以下をシンプルに伝えます。

• 今日のゴール
• どの範囲の“未知の未知”を扱うか（例：リリースまで／運用開始直後まで 等）
• 進行の流れ（ステップ）
• ルール
  • 人や組織を責める発言はしない
  • 「こんなこと言っても…」と思うことほど歓迎する
  • 他人の意見をすぐに否定しない

軽いアイスブレイク

いきなり「リスクを出してください」と言われても、なかなか口は開きません。
5分ほどでできる簡単なアイスブレイクを挟みます。

例：

• 「過去のプロジェクトで一番ヒヤッとした瞬間」を1人30秒で共有
• 「もしこのプロジェクトが最悪の結末を迎えるとしたら、どんな見出しになるか？」を各自一言で考える

笑いが起こるくらいの軽さでよく、完璧な答えは要りません。「ここでは少しくらいネガティブな話をしてもいいんだ」と感じてもらうことが目的です。

当日の進め方②：発散フェーズ（未知を増やす）

ここからが“未知の未知”を炙り出す本番です。いきなり全体議論にせず、まずは個人で静かに考える時間 → グループで共有という流れを取ると、意見が出やすくなります。

個人で書き出す（サイレントワーク）

10〜15分ほど、各自で付箋やオンラインボードに書き出してもらいます。
このとき、次のような問いを提示すると発想が広がります。

• 「もし◯◯が起きたら、プロジェクトはどうなるだろう？」
  • 例：主要メンバーの長期離脱 / 重要システムの大障害 / 法改正 など
• 「今はうまくいっている前提のうち、崩れたら致命的なものは何か？」
• 「ユーザーや現場の人から、後で『なぜ教えてくれなかった』と言われそうなことは？」

このフェーズでは、質より量を重視します。
ファシリテーターは「判断はあとでやるので、とにかく思いついたものを全部出してください」と繰り返し伝えましょう。

グループ内でシェア＆軽い質問

次に、3〜5人程度のグループ内で、自分の付箋を順番に読み上げていきます。

• 似ているものは近くにまとめる
• よく分からないものは、書いた人に軽く質問して意味を確認する
• 否定ではなく「それが起きたとしたら、何が困りますか？」と深掘る

ここまでで、「自分一人では思いつかなかった視点の懸念」がいくつも出てくるはずです。

当日の進め方③：収束フェーズ（整理と優先度付け）

発散したままだと、「いっぱい付箋は出たけど、結局何をすればいいの？」となってしまいます。
ここからは整理と優先度付けを行い、「次にやること」に結びつけていきます。

カテゴリ分けをする

まずは全体でボードを眺めながら、ざっくりとカテゴリ分けをします。例としては次のような切り口があります。

• 要件・仕様に関するもの
• 技術・品質に関するもの
• スケジュール・リソースに関するもの
• 運用・保守に関するもの
• ステークホルダー・コミュニケーションに関するもの
• 外部要因（法規制、外部サービス、災害など）

カテゴリ分けの目的は、「どの辺りの視点に抜け漏れが多いか」を見える化することです。

重要度の高いものを絞り込む

すべてに手を出すのは現実的ではないので、優先度付けを行います。
簡易的には、各自にシールやオンラインの投票機能を渡し、「特に気になるものに3票まで投票してください」といった方法がよく使われます。

可能であれば、次の3つの観点で評価するとバランスが取りやすくなります。

• 影響度：発生したときのダメージの大きさ
• 発生可能性：どの程度起こりそうか
• 検知のしにくさ：気づきにくいものかどうか

「影響度が大きく、検知しにくいもの」は、“未知の未知”になりやすい領域です。

ワークで使える具体的なツール・例題

ここからは、「明日から使える」レベルの具体的な手法や例題を紹介します。

プレモータム（事前の失敗レビュー）

プレモータム（Premortem）は、「プロジェクトがすでに大失敗した」という前提で、その原因を考えるワークです。

手順の例：

1. ファシリテーターが宣言する
   • 「1年後、このプロジェクトは最悪の形で失敗しました」
2. 参加者は、その失敗理由をできるだけ具体的に書き出す
   • 例：「リリース直後にクレームが殺到」「運用部門が引き継ぎを拒否」など
3. 書き出された原因を整理し、「今からできる予防策は何か？」を検討する

「失敗してしまった」と仮定することで、普段は口に出しにくい懸念が出やすくなるのが特徴です。

ユーザージャーニーを使った落とし穴探し

システム開発では、ユーザーや現場担当者の「利用の流れ（ジャーニー）」を簡単な図にして、各ステップで起こりうるトラブルを考えるのも有効です。

• ユーザーが最初に接点を持つところから、利用終了までの流れをざっくり書く
• 各ステップに対して、「ここで困るとしたら何が起きるか？」を付箋で貼る
• 「誰が・どんな場面で・何に困るか」を具体化していく

抽象的な「未知の未知」が、「この場面でこういう問い合わせが殺到するかもしれない」といったレベルまで落ちてくると、対策を考えやすくなります。

「あり得ない前提」をあえて置いてみる

• 「このプロジェクトの予算が半分になるとしたら？」
• 「主要メンバーが同時に長期離脱したら？」
• 「主要な外部サービスが突然終了したら？」

一見、非現実的に見える前提を置くことで、「そこまでは起きないとしても、似たようなことが起きたら？」と発想が広がります。

ワークショップ後のアクションへのつなげ方

“未知の未知”を炙り出しただけで終わってしまうと、単なる「怖い話大会」になってしまいます。
ワークショップ後に何をするかまで決めておくことが重要です。

リスク登録・前提管理に反映する

洗い出された内容を整理し、次のような形に落とし込みます。

• リスク登録簿（リスク一覧表）
• 前提条件リスト（どの前提が危ういのかを明文化）
• タスク化（調査・検証・打ち手検討など）

ここで大事なのは、「全部をいきなり完全に管理しよう」としないことです。
重要度の高いものから順に、リスク管理プロセスに乗せていけば十分です。

結果の共有とフォローアップ

ワークショップに参加できなかったメンバーにも、結果を共有しましょう。

• どんな懸念が出てきたか
• そのうち、どれを重点的に対応するか
• 追加で意見があれば歓迎する旨を伝える

また、1〜2か月後に「その後どうなったか」を軽く振り返る時間を取ると、ワークショップで出た気づきが継続的な学びにつながります。

まとめ

“未知の未知”は、どれだけ計画を綿密に立てても、完全にゼロにはできません。
しかし、次のような取り組みを行うことで、「想定外」を減らし、「起きても対応できる状態」に近づけることはできます。

• 多様なメンバーが参加する“未知の未知”ワークショップを設計する
• 個人での静かな書き出し → グループ共有 → 全体での整理という流れで進める
• プレモータムやユーザージャーニーなどのツールを活用して、具体的な場面をイメージしながら議論する
• 出てきた懸念を、リスク・前提・タスクとしてプロジェクト計画に組み込む

マネジメント初学者にとっても、このワークショップは難しい専門知識を必要としない「実践しやすい一手」です。
まずは小さな範囲・短い時間からでもかまいません。次のプロジェクトで、1時間だけでも“未知の未知”を炙り出す場を作ってみてください。そこで得られた気づきが、大きなトラブルを未然に防ぐきっかけになるはずです。