第2章 全体視点で始める——箇条書きが仕事の出発点
なぜ「箇条書きから始める」のか
仕事の多くは、詳細から入ることで失敗します。コードを書き始めてから設計の欠陥に気づく。文章を書き始めてから構成が崩れていることに気づく。実装してから要件が違っていたことに気づく。
これらは共通して「全体を確認する前に部分に入った」ことが原因です。
箇条書きは、全体を一覧する最もシンプルな道具です。階層構造で書き出すことで、「何が上位概念で、何が下位概念か」「何が抜けているか」「どの順序で進めるべきか」が視覚的に確認できます。AIと協働する場合も同様です。まず全体の箇条書きを作り、AIと合意してから詳細に入る——この順序が、手戻りを最小化します。
トップダウン設計・ボトムアップ実装
全体視点で始めるとは、「トップダウンで設計し、ボトムアップで実装する」ことです。
トップダウン設計では、目的・全体構造・優先順位を先に決めます。本書であれば、副題・章構成・各章のメッセージを先に確定させます。この段階での箇条書きは粗くて構いません。「何を言いたいか」の地図を持つことが目的です。
ボトムアップ実装では、確定した構造に従って詳細を埋めていきます。章の文章を書く、コードを実装する、検証を行う——これらはすべて、全体設計の枠内で行われます。
AIはボトムアップの実装が得意です。だからこそ、人間がトップダウンの設計を担う価値があります。
CBFにおける箇条書きの役割
CBFフレームワークでは、箇条書きは2つの場面で使われます。
リスクリスト：6つの観測軸から変化の兆候を箇条書きで書き出し、発生確率・影響度・緊急度でスコアリングします。何に備えるべきかの全体像を一覧します。
ユースケースリスト：リスクに対応する「確かに役に立つ問い」を箇条書きで書き出し、検証の優先順位をつけます。何を先に実証すべきかの地図になります。
どちらも、詳細な実装に入る前の「全体の確認」です。この習慣が、AI/ITを全体最適の道具として使いこなすための基礎になります。
→ 次章: 第3章 リスクリストで不確実性に備える