- AI時代における最も逆説的な実践は、いつ速度を落とすべきかを知ることであり、実行が安価になるほど、その前段階の意思決定がより重要になる
- Daniel Kahnemanの**System 1（速いパターンマッチング）とSystem 2（遅い分析的思考）**のフレームワークを、AI時代のソフトウェア開発に適用
- 誤った要件や設計上の前提は、AIによってより速く伝播するため、実行前の遅い段階は費用対効果が最大化される
- AIは実行だけでなく、事前レビュー・プレモーテム・エッジケース探索といった熟考の段階を加速するためにも活用できる
- 「AIを使えばいいじゃないか？」という新たな速度圧力の文化に対応するには、遅い段階を明示的に可視化し、タイムボックスを設ける戦略が必要
2つの思考の速度
- Daniel Kahnemanの Thinking, Fast and Slow で提示された2つの思考モードを、AI時代の開発に当てはめる
- System 1: 速く、自動的で、パターンマッチングに基づく思考
- System 2: 遅く、意図的で、分析的な思考
- Andrej KarpathyはDwarkesh Patelとの対話の中で、LLMを幽霊や精霊にたとえ、人間のテキストの統計的蒸留物として、単語が入力されるとパターンがマッチし、単語が出力される、本質的にSystem 1的な存在だと述べた
- AIは大規模な高速パターンマッチングに優れているが、何を作るべきか、なぜ重要なのか、正しい問題を解いているのかを判断する作業は、依然として人間の判断の領域
- 逆説的な要点: AIは遅い段階の重要性を下げたのではなく、むしろ高めた
- 実行が安価で速くなるほど、レバレッジは実行前の意思決定へと移る
- 誤った要件、誤解された問題、欠陥のある設計前提は、AIが構築するあらゆるものに伝播し、今ではより速く伝播する
- System 1が強力になるほど、System 2を誤って行うコストは増大する
速度の幻想
- 学界に古くからある冗談に「図書館なら数時間で済むことが、実験室では数週間かかる」というものがあり、ソフトウェア版では**「数週間のコーディングで数時間の企画を節約できる」**となる
- 実際のポイントはその逆で、急いで始めると根本的な誤りを発見し、その後に痛みを伴うやり直しが続く
- ソフトウェアエンジニアリングでは、ミスはできるだけ要件や設計の段階で早く見つけるべきだという明確な直観がある
- ボックス図は簡単に変更できるが、誤解された要件はより難しく、根本的に欠陥のあるデプロイアーキテクチャは書き直しのレベルになる
- AIの問題は、これまでになく速い速度で技術的負債を生み出せること
- 実行前の判断に欠陥があれば、AIはその欠陥を完全な機能コードのように見える形で忠実に実装する
- 誤解された要件に基づいて数千行のコードを生成し、間違った問題に対する優雅な解決策を喜んで構築してしまう
- 速度の幻想とは、前進しているように感じながら、実際にはさらに深い穴を掘っている状態
- 速度を放棄するのではなく、意図的に配置することが答えであり、AIの速度は正しい方向が確認された後にのみ発揮されるべき
遅さが効果を発揮する瞬間
- 意図的な遅さが効果を発揮する地点は大きく変わっていない
- 要件は文書上の言葉であるうちは変更コストが安く、実際のユーザーに提供するデプロイ済みコードになると高くつく
- 設計判断は図の段階では修正しやすいが、本番システムでは難しい
- AIはこの根本的な物理法則を変えたのではなく、正しく行えたときのレバレッジを増幅した
- Thinking Firstプロトコル: AIに作業を渡す前に、自分が本当に望んでいることを明確にする時間を投資することが、最も安くミスを捕捉できる地点
- AIは実行の加速だけでなく、熟考そのものを加速するためにも使えるという興味深い逆説がある
- コーディング前の要件明確化: 10分かけて解決すべき問題、成功基準、制約条件を書き出し、AIにその内容をレビューさせてから生成する
- プレモーテム（Pre-mortem）の実行: 設計を確定する前に、AIに「このアプローチでは何がうまくいかない可能性があるか？」と問い、見落としていたリスクを洗い出す
- 問題の反転（Invert）: AIに「このプロジェクトを失敗させる要因は何か？」と尋ね、隠れた前提を露出させる
- 捨てる前提のプロトタイプを構築: AIで数時間のうちに作り、ステークホルダーに見せて、投資前に理解度を検証する — 遅さのために速度を投資する
- 簡易な社内ツールを構築: 実製品にコストをかける前に、AIで粗いバージョンを先に作り、本当に必要なものと不要なものを見極める
- エッジケースの早期抽出: 実装を始める前に、AIに設計のエッジケースや故障モードを生成させ、図の段階で対処する
新たな文化的逆風
- 「AIを使えばいいじゃないか？」は新しい形の速度圧力であり、生産性の見かけと実際のスループットを混同するため、特に危険
- AIは数秒でコードを生成できるが、コード生成と正しい問題解決は同じではない
- 対応戦略:
- 今どの段階にいるのかを明示的に共有する: 遅い段階にいるなら、要件の明確化、エッジケースの検討、正しい問題を解いているかの確認をしていると説明する
- ステークホルダーの参加を促す: 今ならステークホルダーの入力を反映するコストは安く、後になるほど高くつく
- 作業過程を共有する: 要件文書、設計スケッチ、プレモーテムの成果物など、遅い段階のアウトプットを可視化して進んでいることを示す
- 遅い段階にタイムボックスを設ける: 「コードを書く前に2日間の要件明確化」のように明確な境界を設け、意図的な遅さが無制限ではなく計画的なものだと感じられるようにする
- 学んだ内容を共有する: 発見したエッジケースや、誤りだと判明した前提などを簡潔に更新し、遅い段階を価値の見える流れへと変える
- クイックウィンを実演する: 捨てる前提のプロトタイプやモックアップを早い段階で作り、素早く動けることを示して、遅く慎重な作業への信頼を確保する
- BasecampのShape Up手法にあるヒルチャート（Hill Chart）の概念に近い
- 上り坂: 不確実性が高く、仕事の実体を発見していく遅い段階
- 下り坂: 進む道筋が明確で、実行するだけの速い段階
- これは遅延の言い訳ではなく、良い仕事が実際に行われる方法の説明であり、長期的に最も速くリリースするチームは、しばしば適切な瞬間に速度を落とすチームである
実践方法
- 次のAI支援タスクの前に試すこと:
- 10分かけて、本当に解決しようとしている問題を書き出し、成功の姿とスコープ外のものを定義する
- 構築を始める前に、AIにアプローチのプレモーテムを実行させる
- 作業がかなり大規模なら、捨てる前提のプロトタイプを先に構築して方向性を検証する
結論
- 速度と遅さは対立するものではなく、異なる段階のための道具である
- AIはその両方に有効である: 方向が明確なときの高速な実行、不明確なときの加速された熟考
- 重要な能力は、今どの段階にいるのかを把握し、適切なテンポを適用すること
4件のコメント
ゆっくり速く、という言葉がありますよね
大学院時代に教授によく言われた言葉ですが、
久しぶりにPTSDがよみがえります。
私は軍隊で聞いたんです
私は楽譜で読みました
allegro non troppo（速いが、慌てずに）