はじめに
「わかった気がするのに、いざ説明しようとすると詰まる」状態に、何度も遭遇してきた。
資格は取れているのに、面談で深掘りされると答えが出ない。 新人エンジニアに教える機会で、応用方向の質問が来ると言葉が出ない。 読んだ本の内容を、1ヶ月後に同僚に説明しようとすると、要点が再構築できない。
知識が手元にあるつもりで、実は浅いところを撫でていただけ、という現象。 心理学では「説明深度の錯覚」と呼ばれている。 人は自分が「どれくらい説明できるか」を、実態より一段か二段、過大評価する。
この錯覚を破るのに有効だと言われているのが、ファインマンテクニックだ。 物理学者リチャード・ファインマンが取っていたとされる学習法で、要は「知らない人に教えるつもりで書いてみる」というそれだけの話だ。 名前を聞くと大層に聞こえるが、本質はシンプルで、だからこそ仰々しいフレームワークに乗せると形骸化しやすい。
この記事は、自分が「行き詰まり時 × 概念整理が必要な時」に、選択的に発動するための実行フローをまとめたものだ。 新しい学習システムを導入する話ではなく、既にやっている学習プロセスのなかに、低コストで挟み込むための手順として書いている。
設計方針
最初に、自分がフローを組むときに置いた3つの方針を書いておく。 ここを共有しないと、なぜ手順が「これで止まっているのか」が伝わりにくいからだ。
| 方針 | 理由 |
|---|---|
| 既存の学習プロセスに溶け込ませる | 独立したフレームワーク化は形骸化する |
| 「行き詰まり時」と「理解を深めたい時」だけ発動する | 全トピックに義務化しない |
| 最小ステップで始める | 完璧なプロセスより、続くプロセス |
過去に「専用テンプレートでファインマンテクニックを毎日やる」という運用を試して、3週間で止めた経験がある。 その反省として、毎回は使わない・専用枠を作らない・テンプレートを軽くする、を最初から組み込んでいる。
フロー全体像
Step 0: 初期スキャン (10-15分・前提知識ゼロのときだけ)
↓
Step 1: 概念を1つ選ぶ
↓
Step 2: 教材を見ずに、12歳に説明を書く
↓
Step 3: 詰まった箇所をギャップとして特定し、教材で埋める
↓
Step 4: 説明を書き直す
↓
(Step 2-4を1〜2回繰り返す)
↓
Step 5: Before/After を記録する通しで30〜60分。 それ以上かかるなら、Step 1の概念粒度が大きすぎる。
Step 0: 初期スキャン
そのトピックを完全にゼロから始める時だけ、10〜15分で概要に触れる。
完全な白紙状態では、Step 2の「説明を書く」が機能しない。 書く骨格そのものが頭の中にないからだ。 最低限のスキーマ、つまり「このトピックは大まかに何の話か」を先に作る。
ここでやることは、概要記事・入門動画・公式ドキュメントの冒頭を流し読みする、それだけだ。 詳細な理解もメモも要らない。 完了基準は「このトピックは〇〇についてのもの」と1文で言える状態。 ある程度知っているトピックなら、このステップは飛ばす。
Step 1: 概念を1つ選ぶ
説明対象を1つに絞る。
選び方は「なんとなくわかるが、説明しろと言われたら困るもの」。 完全にわからないものは、まだStep 0のフェーズだ。 逆に、すでに人に説明できているものは、ここで取り上げる必要がない。
粒度も大事だ。 「AWS全体」ではなく「IAMロール」、「JavaScript全体」ではなく「Promiseチェーンの動作」、というレベルまで降りる。 大きすぎると、Step 2で書ききれずに止まる。
Step 2: 教材を見ずに、12歳に説明を書く
ここが本丸だ。
専門用語を避けて、12歳でもわかるように説明を書く。 紙でもMarkdownでもいい。 最大の制約は「教材・ドキュメントを開かない」ことだ。 参照を許すと、自分が言葉として持っているのか、本に持たせているだけなのかが判別できなくなる。
書く量は5〜10行で十分。 コツは3つだ。
- 「つまり〇〇ということ」「例えば〇〇みたいなもの」というフレーズを意識する
- 身近なものへのアナロジーを1つ入れてみる
- 書けない部分は「？」「ここがわからない」と正直に書く
書けないこと自体が成果だ。 書けない箇所はすなわち、自分の理解が曖昧な箇所だ。 ここを可視化することがファインマンテクニックの目的なので、書けないまま放置でいい。
Step 3: ギャップを特定し、教材で埋める
Step 2で書いた説明を読み返し、詰まった箇所と曖昧な箇所を列挙する。
ギャップの典型パターンはいくつかある。
- 主語が浅い (「誰が」が抜けている)
- 「どうやって」が書けていない (動作がブラックボックスになっている)
- 具体例が出てこない
- 因果関係が言えていない (「だからこうなる」が欠落)
列挙したら、教材・ドキュメントに戻ってそれぞれ調べる。 ここでの教材は、Step 0で読んだ概要記事よりも一段深い、章単位のリファレンスがいい。
AIアシスタントを併用する場合、ここで「この説明のどこが曖昧か」を問いかけるのが効く。 ただし、答えそのものを書かせない。 書かせた瞬間、自分の言葉ではなくAIの言葉に置き換わってしまい、Step 2の意味が消える。 あくまで「気づかせる」役回りに留めてもらうのが良い。
Step 4: 説明を書き直す
ギャップを埋めた知識で、Step 2の説明を書き直す。
判断基準は「12歳が読んでも意味がわかるか」。 シンプル化を意識する。 冗長な部分を削り、1文に1概念を心がける。 書き直すことで、自分が今度こそ自分の言葉で言えるようになっているかを確認する。
反復の打ち切り基準
Step 2〜4のサイクルは、基本的に1〜2回で終える。
| 反復回数 | 判断 |
|---|---|
| 1回目 | 最初の説明 → ギャップ発見 → 改訂 |
| 2回目 | 改訂版を読み直し、まだ曖昧な箇所があれば再度改訂 |
| 3回目以降 | 通常は不要。収束しないなら、概念の粒度が大きすぎる |
収束基準は「この説明を人に見せても恥ずかしくない」と感じられたら終了。 完璧を目指さない。 完璧を目指した瞬間、ファインマンテクニックは「永遠に終わらない作業」に変わって、二度と発動しなくなる。
Step 5: Before/After を記録する
最後に、ギャップと修正内容をBefore/After形式で記録する。
| # | ギャップ | Before | After |
|---|---|---|---|
| 1 |
これは復習資料にもなるし、後でブログ記事を書くときの種にもなる。 記録しないと、ファインマンテクニックの効果を後から振り返ることができない。 やるたびにこの表が積み上がっていく状態を目指す。
いつ使い、いつ使わないか
ファインマンテクニックは強力だが、毎回使うものではない。 発動条件と非発動条件をはっきりさせておく。
発動するのは次のいずれかだ。
- 学習中に「わかった気がするが説明できない」と感じたとき
- 複数の概念の関係性が曖昧で整理したいとき (例: AWS IAMの4概念)
- ブログ記事や発表資料を書く前に、理解度を確認したいとき
- 復習サイクルの中で、特定概念の理解を再点検したいとき
逆に、次の場面では使わない。
- 手続き的知識(コマンドの叩き方、ショートカットなど) → ハンズオンの方が早い
- すでに十分理解しているトピック → 時間の無駄
- 短時間で結果を出したいとき → 30〜60分かかる前提
ファシリテーター役のAIプロンプト
AIアシスタントを併用する場合、用途は「進行役 (ファシリテーター)」に固定するのが良い。 教師役にした瞬間、ユーザーは受動的になり、ファインマンテクニックの効果が消える。 自分で書いて詰まることが、この手法の核心だからだ。
自分が使っているプロンプトの骨子はこんな感じだ。
あなたはファインマンテクニックの進行役 (ファシリテーター) です。
私が概念を「12歳にもわかるように説明する」プロセスを支援してください。
重要な制約:
- あなたが概念を直接説明しないでください。説明を書くのは私の仕事です
- 私の説明の正誤判定をすぐにしないでください。まず「問いかけ」で気づかせてください
- 1ステップずつ進めてください。先のステップに勝手に進まないでください
- 「よく書けています」等の評価は不要です
進行手順:
Step 0: 私が「全く知らない」と言ったら、概要1文 + 参考資料1〜2個だけ提示
Step 1: 概念粒度を確認。大きすぎたら絞らせる
Step 2: 私が説明を書くのを待つ。書き終わるまで介入しない
Step 3: 私の説明を読んで、ギャップに気づかせる質問を2〜3個する
(例: 「〇〇の部分、もう少し具体的に言うとどういうこと?」)
質問は一度に2-3個まで。私が答えてから次の質問へ
Step 4: ギャップを踏まえた書き直しを促す
Step 5: Before/After 表を一緒に整理する
合図:
- 「教えて」 → ファシリテーター解除、直接説明 OK
- 「次のステップ」 → 次へ
- 「まとめて」 → 進捗を Before/After 形式で整理ポイントは、AIに答えを書かせないこと、評価コメントを抑えること、ステップごとに止めることの3点だ。 このプロンプト自体を最初に貼って、概念名と現在の理解度を伝えれば、進行役として動いてくれる。
「教えて」という脱出ハッチを用意しているのは、自力で詰まり続けると単に苦痛になって続かないからだ。 ただし、これを使った箇所は理解が浅い証拠なので、後日改めてファインマンテクニックの対象に戻す。
形骸化させないための運用
過去に専用テンプレートで毎日運用しようとして失敗した話を冒頭で書いた。 今回のフローでは、形骸化を防ぐためにいくつか制約を入れている。
- 義務化しない。トリガー条件に該当する時だけ発動する
- テンプレートを最小化する。説明 → ギャップ → 改訂の3点だけでも成立する
- 既存プロセスの「実行方法」として位置付ける。新フレームワークとして独立させない
- 反復は2回まで、所要時間は30〜60分の枠内で完結させる
ファインマンテクニックは、毎日使う道具ではなく、行き詰まったときに引き出せる手段として置いておくのが、自分には合っている。
おわりに
「12歳に説明する」は子供だましの手法に聞こえるが、実際にやってみると驚くほど書けない。 書けないところに、自分の理解の境界線がはっきり出る。 この境界線を見るために、紙とペンを開けば、それでこの手法は機能する。 専用ツールも、専用テンプレートも、本質的には要らない。
自分にとってこの手法の価値は、「わからないことが分からない」状態を、「わからないことが具体的に列挙された」状態に変えることだ。 そこから先は、ふだんの学習に戻れる。 だからフローは軽くしてある。 重くした瞬間に発動しなくなる、というのが過去の自分から学んだことだ。
参考書籍
- ウルトララーニング 超自習法 (スコット・H・ヤング、ダイヤモンド社、2020)
変更履歴
- 2026-05-04: 初版公開