内田和成先生の『論点思考』を、AI駆動開発の実務へ翻訳

Transcript

1. 内田和成先生の『論点思考』を、AI駆動開発の実務へ翻訳 論点思考を、 テックリードの思考OSにする 依頼された問題を速く解くのではなく、 本当に解く価値のある問いを見つけ、更新し続ける。 書いた人：武藤 雅裕
2. WHY NOW AIがHowを高速化するほど、Issue Definitionの価値が上がる 従来 AI CODING AGENT時代 Problem ↓ Solution Issue ↓ 高速実装 → 解き方そのものが、成果を左右していた。 Actionから始めない。最上流に「何を解くべきか」を置く。 問いが違えば、間違ったものを猛烈な速度で 作る。
3. THINKING OS 仕事の入口を「Issue → Structure → Hypothesis → Action → Learn」に統一する 01 Issue 本当に解くべき 論点は何か 02 → Structure 大・中・小論点へ 分解する 03 → Hypothesis 原因と答えの 仮説を置く 04 → 学習の結果を、最初のIssueへ戻す Action 最小の検証・ 実装を行う 05 → Learn 結果から論点を 再設定する
4. CUSTOMER HEARING 「RAGを入れたい」を、そのまま論点にしない 本当の論点候補 観察事実・依頼 「RAGを 導入したい」 → • 必要な情報を探すのに時間がかかるのか？ • 回答品質が担当者によって違うのか？ • 問い合わせ対応コストが高いのか？ • 知識が属人化しているのか？ • そもそもRAGが必要なのか？ これは解くべき問題ではなく、 顧客から提示された解決案。 論点が変われば、解決策空間が変わる。 FAQ／検索／RAG／Knowledge Graph／教育／UI／業務プロセス
5. PROBING ヒアリングは「要望 → 要件」ではなく「発言 → 真の論点」へ 進める 発言 → 背景 → 現象 → 困っている人 → 困りごと → 原因仮説 → 真の論点 プロービングの問い REFRAME なぜ自動化したいのですか？ 誰が、どこで困っていますか？ 検索と回答作成、どちらが遅いですか？ 問い合わせ自体を減らせませんか？ AIを使わなくても解決できますか？ 「生成AIで問い合わせ対応を自動化したい」 ↓ 新人が履歴を探せず、 熟練者への質問が集中している
6. AI CODING AGENT Coding Agentには、実装前に論点と検証順序を考えさせる Issue → Context → Hypothesis → Constraint → Alternative → Decision → Implementation → Verification Agentへの思考指示 EXAMPLE 1 現象と論点を分離 2 原因仮説を複数提示 3 大・中・小論点に構造化 4 仮説ごとの検証方法を提示 Observation p95 latency が3秒超 5 効果・容易性で優先順位化 6 最小の検証を実行 制約 まず実装しない 7 確認済み原因だけ修正 8 テストで効果を確認 APIレスポンスが遅い
7. TECH LEAD REVIEW テックリードは「正しく解く人」から「正しい問題を選ぶ人」へ 変わる Why なぜ、これをやるのか？ Who 誰の問題なのか？ What 真の論点は何か？ Structure 論点はどう分解されるか ？ Alternative 別の論点・解決策はないか？ Priority 今、解くべきなのか？ How どう解決するか？ Verify 解決したと、どう判断するか？ 最重要ルール：Howに飛びつかない。 REVIEW SHIFT このDB設計は正しいか？ Neo4jかPostgreSQLか？ RAGかAgentか？ ↓ そもそも、何を解決する 設計なのか？
8. PRIORITIZE & LEARN 良いテックリードは、論点を選び、試し、更新し続ける 論点の3軸トリアージ Impact ISSUE EVOLUTION 効果は大きいか Issues Feasibility 実行できるか Evidence 検証しやすいか → Hypothesis → Experiment → Observation → Issues 問題を解く能力より、より良い問題へ更新し続ける能力。 TECH LEAD PRINCIPLE 依頼された問題を解くのではなく、本当に解く価値のある論点を見つけ、構造化し、仮説検 証によって更新し、最も効果の高いものだけを実行する。