今日のフォーカス
問題解決の真のスキルは「速く解く」ことではなく「正しい問いを設定する」ことだ。第一原理で前提を解体し、リスクの非対称性を識別し、不完全な情報でも構造化して判断できる力を鍛える。
第一原理思考
「なぜこの方法を使っているか」を根本から問い直す。フレームワークは手段であり、それが解こうとしている本質的問題に立ち返ることで状況適合的な判断が生まれる。
リスクの非対称性
「影響の深刻度 × 発生確率」だけでなく「回復可能かどうか」で優先度が決まる。同じ「バグ」でも医療データ消失とUI崩れは桁が違う。
不完全情報下の優先度設計
情報の価値 = (この情報が変わると意思決定が変わる確率) × (情報を得るコスト)。「何を調べるか」より「何を調べるべきかを決める問い」を先に設計する。
チームは毎回スクラムフレームワークを使っている。あるシニアエンジニアが「この規模のチームでスクラムは形式過ぎる。もっと軽量なアプローチに変えたい」と提案してきた。
- スクラムを「第一原理」で分解せよ。スクラムが解こうとしている本質的な問題は何か？（3点以内）
- 現状の自チームに対して、それらの本質的問題が「どの程度当てはまるか」を評価する問いを3つ作れ
- スクラムをやめて別の方法にするとしたら考えられる選択肢（2〜3案）と、その判断基準を述べよ
- 「受け入れる場合」「受け入れない場合」それぞれの判断軸を1つずつ挙げよ
思考プロセスのガイド
「スクラムとは〇〇なフレームワークで…」ではなく「なぜこれが生まれたか・何を解くために存在するか」から考える
「スクラムかどうか」という二項対立ではなく「スクラムの何を・どの程度維持するか」の連続的選択として捉える
「形式的会議による時間・モチベーション損失」vs「チームの習熟度・文化変動リスク」を評価する
変更提案が「スクラムは形式的」という感覚か、具体的な問題点の特定と代替案の効果検証方法まで含むかを確認する
模範解答を見る
問1: スクラムが解こうとしている本質的問題
- 不確実性の管理: 要件が変わり続ける中で、短いサイクルで方向修正できるようにする
- チームの同期と透明性: 誰が何をしているかを可視化し、ボトルネックを早期発見する
- 継続的改善: プロセス自体を定期的に見直し、チームが自律的に進化できるようにする
問2: 評価の問いの例
- 「現在のチームで、要件が週次以上で変化する頻度はどのくらいか？」（不確実性の程度）
- 「スタンドアップで誰かの仕事がブロックされていることが発見され、その日中に解消された事例が先月何件あったか？」（同期の効果）
- 「レトロで出たアクションアイテムのうち、翌スプリントで実際に変化したものは何割か？」（改善機能の実態）
問3: 選択肢と判断基準
A: カンバン（軽量化）
スプリント区切りをなくし、WIP制限でフローを管理。判断基準: 機能の優先度が頻繁に変わり、タイムボックスが足かせになっている場合
B: スクラムのサブセット
レトロと計画だけ残し、デイリーを非同期テキストに変更。判断基準: 形式はコストだが、方向統一の機能は価値がある場合
C: ミルストーンベース自律管理
マイルストーンと1on1のみ。判断基準: チームの自律性と経験値が高く、外部からの検査・適応の仕組みが別途ある場合
問4: 判断軸
受け入れる場合: 「現行プロセスのどのセレモニーが問題で、その問題が計量できる形で示せるとき」
受け入れない場合: 「変更の目的が曖昧で『スクラムは形式的』という感覚論のみで、代替案の効果検証方法が示されていないとき」
実践への応用
- スタートアップCTO: スケールに合わせてプロセスを定期見直す。「今のチームサイズ・フェーズに適したプロセスか」を半年ごとに問い直す
- グローバルチーム: 非同期コミュニケーションが多い多国籍チームでは、スクラムのリアルタイム同期型前提が合わないケースが多い
- 起業家視点: 初期0→1フェーズでスクラムをそのまま導入するのは過設計。第一原理で「今解くべき問題」を特定してから最小限のプロセスを設計する
自己評価を記入する
大型アップデートのリリースを3週間後に控え、QAチームが「本番同等の環境で未検証のエッジケースが15件ある。全部テストするにはあと2週間かかる」と報告してきた。
追加情報: 顧客病院10件に対してリリース日を告知済み / 競合他社が1ヶ月後に類似機能をリリース予定 / エッジケース内訳: UI表示崩れ10件・データ書き込みエラーの可能性（低頻度）3件・緊急アラート機能の誤発報可能性2件
- リスクを「影響の深刻度 × 発生確率」の2軸で整理し、最も対処すべきリスクを特定せよ
- 「予定通りリリース」「全件テスト後リリース」以外の第3の選択肢を1つ提案せよ
- 「3週間後リリース（未テスト15件あり）」を選んだとして、顧客病院担当者への説明メッセージを3文以内で書け
- この意思決定でもっとも避けるべき認知バイアスを1つ挙げ、理由を説明せよ
思考プロセスのガイド
UI崩れ・データエラー・アラート誤発報は全く異なる種類のリスク。最初のステップは分類
「発生確率が低い」≠「試さなくていい」。医療系では患者への直接的影響がある種類は絶対回避
「全部やる vs 全部やらない」ではなく「重要度でリリースを分割できないか」を常に問う
「告知済み」「競合が先に出す」という情報が判断を歪めていないかメタ認知する
模範解答を見る
問1: リスクの整理
| リスク種別 | 件数 | 影響の深刻度 | 優先度 |
|---|---|---|---|
| 緊急アラート誤発報 | 2件 | 最大（患者安全・医療事故リスク） | 最高 |
| データ書き込みエラー | 3件 | 高（カルテデータ破損・法的責任） | 高 |
| UI表示崩れ | 10件 | 低（業務効率の低下のみ） | 低 |
最も対処すべき: 緊急アラート誤発報の2件。医療事故に直結する可能性があり、回復不可能なダメージを与えうる。これだけはリリース前に必ず検証が必要。
問2: 第3の選択肢
段階的リリース（Staged Rollout）: 3週間後に予定通りリリースするが、緊急アラートとデータ書き込みに関するエッジケースのみを2週間で優先テストし、残りのUI崩れは既知バグとして後続パッチで対応する。顧客には「重要機能は検証済み・軽微な表示問題は後続パッチで対応」と透明に開示。
問3: 顧客への説明文
「今回のリリースは主要機能すべて動作確認済みですが、軽微な表示上の問題が一部残っており、4週間以内にパッチを提供予定です。安全性・データ整合性に関する機能は全件検証済みであり、患者様の情報に影響はありません。ご不便をおかけしますが、予定通り3週間後のリリースで進めさせていただきます。」
問4: 避けるべき認知バイアス
正常性バイアス（Normalcy Bias）: 「今まで大きな問題はなかったから今回も大丈夫だろう」という過去の成功体験に基づく楽観。特に医療系では、過去に問題がなかったことは「このエッジケースが安全」の根拠にならない。
次点: スケジュール優先バイアス（Deadline Pressure）——競合情報とコミットメント済み日程のプレッシャーが重なり「遅れること」を最大のリスクと誤認しやすい
実践への応用
- ヘルスケア・フィンテック・インフラ系: 「回復可能かどうか」をリリース判断の第一基準として社内共有化する
- CTO判断: リスク分類表を使って「どのバグが本当に問題か」を対話で構造化できる
- グローバル展開: 米国・EU市場ではHIPAA/MDR等の「既知バグの開示義務」が法律で定められているケースがある
自己評価を記入する
CEOから「来月のボードミーティングで、インドネシア・タイ・ベトナムの3カ国候補からどの国から入るか最終決定をしたい。2週間で調査して結論を出してほしい」と言われた。
現在のリソース: 事業開発担当2名（日本語のみ）/ 1年前の一般的市場調査レポート（英語）/ 東南アジアのコネクション: タイに1社（元同僚のスタートアップ）
- 「2週間で出せる意思決定の質」と「理想的な意思決定に必要な情報」のギャップを言語化せよ
- 2週間でどの情報を収集するか優先順位をつけよ（3つまで、理由も述べること）
- 「インドネシア・タイ・ベトナム」の比較軸を設計せよ（5軸以上、決済SaaS特化軸を含めること）
- ボードへの提案を「まだ決定できない場合」「ある程度根拠があって決定できる場合」の両シナリオで骨格を書け
思考プロセスのガイド
支払いインフラ・規制・競合・顧客の支払い習慣など。何を調べるべきかを先に設計する
「全部調べる」方向に走ると2週間で中途半端になる。優先度なき網羅は意思決定を遅らせる
GDP・人口など全体的な指標より「この文脈で3カ国が違う理由になる軸」を選ぶ
「確定的な答え」か「調査継続」の二択でなく、「現状の仮説とその検証方法」として提示する
模範解答を見る
問1: ギャップの言語化
分かっていること
- 3カ国の一般的な市場規模・GDP（1年前のデータ）
- タイに接触できるコネクションが1件
分かっていないこと（ギャップ）
- 各国の決済規制・ライセンス取得要件
- 決済インフラ成熟度（QRコード普及率・銀行口座保有率）
- 競合の市場支配度と自社ICPの存在感
- 現地でのPoC顧客獲得の可能性
2週間で出せる結論: 「どの国から入るべきか」の確定的な答えではなく、「どの国が最も低コスト・低リスクでPoC（概念実証）できるか」の仮説。
問2: 優先収集情報の順位
理由: 参入できない国に時間をかけても無意味。規制の壁が最大の「行けない理由」になりうる
理由: 2次情報（レポート）より現地の生の声の方が「実際どうか」を速く掴める。タイの状況と他国との比較仮説が得られる
理由: 決済SaaSの普及可能性を規定する基礎データ。無料で入手可能かつ比較可能
問3: 比較軸（決済SaaS特化）
問4: ボードへの提示骨格
「まだ決定できない場合」
「現時点では規制調査とインフラデータの収集が完了していないため、誤った優先順位で参入すると6〜12ヶ月を無駄にするリスクがあります。追加4週間で規制調査と現地インタビューを完了させ、次のボードでファイナル決定をお願いしたい。現段階ではタイが最も初期PoC先として合理的な仮説を持っていますが、その根拠と検証方法を共有します。」
「ある程度根拠があって決定できる場合」
「調査の結果、タイを最初の参入国として推奨します。根拠は3点：①規制のハードルが3カ国中最も明確で取得可能、②デジタル決済インフラ成熟度がインドネシアより高く学習コストが低い、③既存コネクションを通じてPoC顧客候補が2社確認済み。ベトナムとインドネシアは年内再評価を計画します。」
実践への応用
- 意思決定設計の原則: 「今の情報でどこまで言えるか」を明示することが、ボードや投資家との信頼構築に直結する。「分からない」を開示できるリーダーは弱いのではなく、知的誠実性が高い
- グローバル事業開発: 東南アジア展開では「人口規模」より「規制のしやすさ」と「コネクション密度」が初期参入成功の決定要因になることが多い
- 起業家視点: 「すべての情報が揃ってから動く」はスタートアップには致命的。「この仮説で動いて、どこで仮説を修正するか」を設計することが競争優位になる
自己評価を記入する
今日のまとめ
「問題解決・意思決定」の本質は「解く前に問いを疑う」こと。第一原理で前提を解体し、リスクの非対称性を見極め、不完全な情報でも「どこまで言えるか」を正直に設計できる力が、真のThinking力だ。
次回への接続
明日: EQ-B（対人スキル・関係管理）
今日の「利害関係者への説明設計」（Q2: 顧客への説明文、Q3: ボードへの提示）は、EQ-Bの「共感を持ちながら誠実に情報を伝える」スキルと直結する。「何を言うか」に加えて「誰に・どう・いつ言うか」を明日深掘りする。