知識マップを作る
どの塊があり、何が何に依存するかを見てから学ぶ順を決める
私は [目的] のために [分野／スキル] を学びます。まず知識マップだけを示してください。解説はまだ不要です：1）4〜7 のモジュールに分解し、各々が解く問題を一文で；2）モジュール間の依存を表で示す（B の前に A が必要）；3）成果の 80% を決める 20% はどこか、後回しでよいものはどれか；4）私の目的に沿った最短ルートと、そのルートが捨てるものを示す。
使い方
地図の段階では解説させない。解説が始まった瞬間に教科書になり、構造が見えなくなる。
向いている場面
- 独学を始めたばかりで、どんなブロックがあるのか、自分が今どこに立っているのかも分からないとき
- 始めてはやめるを繰り返している（講座を三つ買って一つも終えていない）。進みが見える構造が欲しいとき
向いていない場面
- 次の作業がすでに具体的にあるとき（今週この API にキャッシュを足す）。地図を描くのは先延ばしになる
- 領域の変化が非常に速いとき（あるフロントエンドフレームワークの内部実装）。地図は三か月で古くなり、誰も知らせてくれない
例
入力
領域：分散システム。目標：社内のシャーディング／パーティショニング案をレビューできるようになる。
得られるもの
モジュールは五から六個まで（レプリケーション、パーティショニング、整合性モデル、合意、障害検出、可観測性）。依存表には「合意を学ぶ前に複製ログを理解する」といった厳密な順序を書く。20% は CAP の実際のトレードオフ、レプリケーション遅延の見え方、パーティションキーの選択に置く。最短経路は何を捨てるか（Paxos の証明を読まない、Raft を実装しない）を明示し、捨てた結果レビューで答えられなくなる質問の種類も示す。
よくある誤用
- 知識の地図を五枚集めて一枚も歩かない。地図が与える安心感が学習そのものを置き換えてしまう
- 地図を受け取った後で「ついでに各モジュールを説明して」と頼む。三百字の偽の教科書が返り、深さはすべて錯覚になる
こう変えると効く
- 「週五時間、八週間」と足す。同じ地図が時間目盛りの付いた経路になり、どこを削るべきかが見える
- 「面接用の経路」と「実務で手を動かす経路」を並べ、分岐点を示させる。目標がまだ定まらない段階に向く