ブレスト＆決定力向上塾

【実践ワーク】チームで不確実性を特定し、意思決定の精度を高めるワークショップ

ソフトウェア開発の現場では、技術の変化、顧客ニーズの変動、プロジェクトの複雑性など、様々な不確実性が常に存在します。これらの不確実性を見過ごすと、計画の遅延、手戻り、品質問題、ひいてはプロジェクトの失敗に繋がる可能性があります。

不確実性を完全に排除することは難しいですが、それをチームで特定し、その影響を評価することで、より情報に基づいた意思決定やリスクを考慮した計画立案が可能となります。本記事では、チームで不確実性に対して建設的に向き合い、意思決定の精度を高めるための実践ワークショップをご紹介します。

不確実性特定・評価ワークショップの目的と期待効果

このワークショップは、チームが抱える様々な不確実性を顕在化させ、それに対する共通認識を醸成することを目的としています。期待される効果は以下の通りです。

• チームメンバー間で、潜在的なリスクや未知の要素に対する認識のずれを解消できます。
• 不確実性の「見える化」により、どの不確実性が最も重要か、または対処が必要かをチームで議論できます。
• 評価された不確実性を考慮した、より現実的で堅牢な計画を立てることができます。
• 不確実性への対策を事前に検討することで、問題発生時の対応力を向上させます。
• チーム全体の不確実性に対するリテラシーと対応能力が向上します。

ワークショップの準備

ワークショップを効果的に実施するためには、以下の準備が必要です。

• 参加者: チームメンバー全員。関係部署のキーパーソンが参加できると、より広範な不確実性を特定できます。
• 時間: 90分から120分程度。不確実性の量やチームの人数によります。
• 場所: 物理的な会議室またはオンライン会議ツール。
• ツール:
  • 付箋とペン（物理またはデジタルツール - 例: Miro, Mural）。
  • ホワイトボードや模造紙（物理またはデジタルボード）。
  • 不確実性マップのテンプレート（物理またはデジタル）。
  • 必要に応じてタイマー。

ワークショップの手順

以下のステップでワークショップを進めます。

ステップ1: 不確実性のリストアップ（個人ワーク＆共有）

まず、チームメンバー一人ひとりが、現在のプロジェクトや業務において「不確かだと感じていること」「懸念していること」「未知の要素」を付箋に書き出します。

• 「〜かどうか分からない」
• 「〜がどのように影響するか不明」
• 「〜が間に合うか懸念がある」
• 「〜に関する情報が不足している」

といった具体的な表現で記述することを促します。個人ワークの時間を設けることで、他のメンバーの意見に引きずられることなく、自身の懸念を自由に表現できるようにします。

その後、一人ずつ書き出した付箋を共有し、ホワイトボードやデジタルボードに貼り付けていきます。この段階では、内容の重複を気にせず、出てきた不確実性をすべて可視化することを優先します。

ステップ2: 各不確実性の内容理解と明確化（チームワーク）

リストアップされた不確実性について、チームで一つずつ内容を確認し、明確化します。曖昧な表現のものは具体的にどのような状態か、なぜそれが不確実なのかを掘り下げて議論します。必要に応じて、関連する不確実性をグループ化したり、表現をより分かりやすく修正したりします。

このプロセスを通じて、チーム全員がそれぞれの不確実性について同じ理解を持つことが重要です。

ステップ3: 不確実性の評価 - 不確実性マップの作成（チームワーク）

明確化された各不確実性を、以下の2つの軸で評価します。

1. Impact (影響度): その不確実性が現実になった場合、プロジェクトやチームにどれほど大きな影響を与えるか？（例：軽微、中程度、甚大）
2. Likelihood / Probability (可能性/蓋然性): その不確実性が現実になる可能性はどれくらいあるか？（例：低い、中程度、高い）

評価は、チームで議論しながら行います。評価基準を事前に決めておくとスムーズです（例：影響度はコスト、期間、品質、顧客満足度などの観点から、可能性は過去の経験や現在の情報から判断）。

評価結果を縦軸に「Impact」、横軸に「Likelihood」を取ったマトリクス（不確実性マップ、またはインパクト/可能性マトリクスとも呼ばれます）上にマッピングしていきます。各付箋を対応する位置に貼り付けます。

ステップ4: 評価結果の共有と議論（チームワーク）

不確実性マップが完成したら、チーム全員で全体像を眺め、議論します。特に、マップの右上（影響度が高く、可能性も高い）に位置する不確実性に注目します。これらの不確実性は、優先的に検討・対処すべきものです。

なぜその位置にマッピングされたのか、チームで意見交換を行い、評価に対する認識のずれがないかを確認します。異なる意見が出た場合は、その根拠を共有し、チームとしての合意点を見つけます。

ステップ5: 今後のアクション検討（チームワーク）

重要度が高いと特定された不確実性について、具体的な次のアクションを検討します。アクションの例としては以下のものが考えられます。

• 情報収集/調査: 不確実性の内容や可能性を明らかにするための調査や技術検証。
• 実験/プロトタイプ: 不確実性を低減するための小規模な試み。
• リスク対策: 不確実性が現実になった場合の被害を抑えるための予防策やコンティンジェンシープラン。
• 計画への反映: 不確実性を考慮したバッファの確保や計画の変更。
• 監視: 不確実性の状況を継続的に確認するための体制構築。

それぞれの不確実性に対して、誰が、いつまでに、何をするかを具体的に決定します。

効果を出すためのポイント

• 心理的安全性の確保: どんな小さな懸念でも自由に発言できる雰囲気を作ることが最も重要です。不確実性を挙げること自体がネガティブなことではない、という認識を共有します。
• 具体的な記述: 曖昧な「何か問題が起こりそう」ではなく、「〇〇のライブラリが現在のシステム構成と互換性がない可能性がある」のように具体的に記述することを促します。
• 評価基準の合意: ImpactとLikelihoodの評価軸について、チームである程度の基準を合わせることで、議論の質が高まります。
• アウトプットの活用: ワークショップで特定された不確実性とそのアクションは、単なるリストで終わらせず、プロジェクト計画やバックログに反映し、定期的にレビューすることが重要です。

具体的なシナリオ例：新規技術導入プロジェクト

あるソフトウェア開発チームが、これまでの技術スタックとは異なる新しいフレームワークをコア部分に導入するプロジェクトを進めているとします。この技術は情報が少なく、チームメンバーも経験がありません。

このチームが不確実性ワークショップを実施すると、以下のような不確実性がリストアップされる可能性があります。

• 新しいフレームワークの学習コストが想定より高い可能性がある。
• 新しいフレームワークと既存システムとの連携で未知の互換性問題が発生する可能性がある。
• 新しいフレームワークに関する日本語の情報やコミュニティサポートが少ない可能性がある。
• 特定の機能が新しいフレームワークで実装困難である可能性がある。
• 将来的なフレームワークのアップデートで互換性が失われる可能性がある。

これらの不確実性をImpactとLikelihoodで評価し、不確実性マップを作成します。例えば、「既存システムとの互換性問題」が「高インパクト」「高可能性」にマッピングされた場合、これを最優先で対処すべき不確実性と特定できます。

アクションとして、「既存システムとの連携部分に焦点を当てた小規模な概念実証（PoC）を最初のスプリントで行う」「フレームワークの公式ドキュメントやソースコードを早期に読み込むタスクを計画に追加する」といった具体的な対応策を検討・実行に移すことができます。

結論

不確実性特定・評価ワークショップは、チームが直面する見えないリスクを可視化し、共有するための強力なツールです。不確実性はプロジェクトの成功を脅かす要因となり得ますが、それにチームで体系的に向き合うことで、より適切な意思決定を行い、計画の精度を高めることが可能です。

本ワークショップをチームの定期的なプラクティスとして取り入れることで、不確実性に対するチームのレジリエンスを高め、変化に強い組織文化を醸成することに繋がるでしょう。特定された不確実性に対するアクションを確実に実行し、その効果を振り返るサイクルを回していくことを推奨します。

不確実性マップ テンプレート例

| | Likelihood: 低い | Likelihood: 中程度 | Likelihood: 高い | | :-------- | :--------------- | :----------------- | :--------------- | | Impact: 甚大 | | | | | Impact: 中程度 | | | | | Impact: 軽微 | | | |

※ 各セルに、対応する不確実性を書き出した付箋を貼り付けます。特に右上（高インパクト、高可能性）のセルに注目します。