第5章 01：言語からではなく、問題から始めよ#

僕はプログラマーではない。コンピュータサイエンスの授業を受けたこともない。スタックとヒープの違いも説明できない。でも2年前、ウェブサイトが必要だった——写真を展示するシンプルなポートフォリオサイト——それに2000ドル払って誰かに作ってもらいたくはなかった。

だから自分で作った。2週間にわたって合計約18時間かかった。美しくはない。コードをプロが見たら、たぶん顔をしかめるだろう。でも動く。読み込みは速い。写真が表示される。連絡フォームもある。必要なことをやってくれている。

僕はコーディングを学んだのではない。たまたまコードを必要とする特定の問題を解決する方法を学んだのだ。この区別——問題ファーストかスキルファーストか——が、しきい値を越える速度をまるごと変える。

2つの学び方：体系的学習 vs. 需要駆動型学習#

ほとんどの正規の学習は体系的だ。最初から始めて、中間を通り、最後に到達する。第1章の次に第2章。基礎の次に応用。理論の次に実践。

体系的学習には本物の強みがある。徹底的で、しっかりした土台を築き、重要な概念を見落とさない。プロフェッショナルを目指すなら——外科医、構造エンジニア、旅客機パイロット——体系的学習は不可欠だ。命が包括的な知識にかかっている。

しかしあなたはプロを目指しているわけではない。20時間で能力のしきい値を越えようとしている。その目標に対して、体系的学習はたいてい最も遅いルートだ。

代替案は需要駆動型学習（demand-driven learning）だ。「何を最初に学ぶべきか？」ではなく「何を達成する必要があるか？」と問う。そして答えから逆算する。達成に必要なことだけ学ぶ。それ以外はすべて後回し。

需要駆動型学習はショートカットではない。方向が違うのだ。 体系的学習は地図全体を歩く。需要駆動型学習は、今いる場所から行くべき場所まで直線を引く。

何かを学ぶ前に、まず問題を定義する#

需要駆動型アプローチは、省略不可能な一つのステップから始まる：問題を定義すること。明確に。具体的に。文章にして。

「写真を学びたい」ではダメだ。それは領域であって問題ではない。

「もっと良い写真を撮りたい」もダメだ。それは漠然とした願望であって問題ではない。

こう言ってみよう：「自分のオンラインストア用に、スマホカメラとアパートの窓からの自然光を使って、明るくて露出の正しい商品写真を撮りたい。」

これが問題だ。境界がある。ツール（スマホカメラ）、被写体（商品）、照明条件（自然光、アパートの窓）、品質基準（明るい、露出が正しい）が指定されている。これらの境界が、何を学ぶべきか——そして決定的に重要なこととして——何を無視すべきかを正確に教えてくれる。

この問題を定義すれば、写真の知識の枝全体をすぐに排除できる：スタジオストロボ、風景構図、ポートレートのポージング、夜景撮影、フィルム現像、レンズ選びについて学ぶ必要はない。すべて興味深い。しかしどれも今は関係ない。

問題定義テンプレート#

学ぼうとしているスキルについて、このテンプレートを埋める：

どんな具体的な成果が必要か？（具体的に。「動くウェブサイト」は「ウェブ開発を学ぶ」より良い。）
どんなツールや制約があるか？（予算、機材、時間、既存の知識。）
「完了」はどういう状態か？（問題が解決されたとどう判断するか？）
何が明示的にスコープ外か？（意図的にやらないことは何か？）

4番目の質問が最も重要だ。スコープは20時間学習者の敵だ。学習リストに追加するトピックの一つひとつが、集中力を薄め、タイムラインを延ばし、しきい値を越える前に停滞する確率を上げる。

「やらないこと」の境界を定義せよ。スピードはそこから生まれる。

トマスとスプレッドシートの話#

トマスは小さな造園業を営んでいた。顧客、請求書、スケジュールを紙のノートで管理していた。機能はするが遅い。誰がいくら払っていないか見失う。土曜の朝をダブルブッキングしてしまう。もっと良いシステムが欲しかった。

友人がスプレッドシートを学ぶよう勧めた。トマスはオンラインでExcelコースを調べた。47レッスンで、ピボットテーブル、VLOOKUP、条件付き書式、マクロ、チャート、データ検証、キーボードショートカットをカバーしていた。コースは12時間。

トマスに12時間の余裕はなかった。ビジネスがある。そしてピボットテーブルは必要ない。必要なのは3つ：

名前、住所、電話番号の入った顧客リスト。
誰が支払い済みで誰が未払いかを示す請求書トラッカー。
どの仕事がどの日に入っているかを示す週間スケジュール。

だからコースを受ける代わりに、空白のスプレッドシートを開いてセルA1に最初の顧客の名前を打ち込んだ。B1に住所、C1に電話番号。ヘッダーを追加し、顧客を追加していった。20分で顧客リストができた。

請求書トラッカーには1つだけ知る必要があった：列の数値を自動的に合計する方法。「Excelで列を合計する方法」と検索し、90秒の動画を見て、適用した。完了。

スケジュールには、セルに色をつける方法を知る必要があった。「Excelでセルに色をつける方法」と検索し、30秒で答えを見つけ、適用した。

合計学習時間：約2時間、3日間にわたって。トマスはピボットテーブルを学ばなかった。VLOOKUPも学ばなかった。マクロも学ばなかった。問題が必要としたことだけを、正確に学んだ。

6ヶ月後、彼のスプレッドシートシステムはまだ稼働していた。いくつかの列を追加した。日付でソートする方法を覚えた。スクロールしてもヘッダー行が表示されたままになるように固定する方法を学んだ。これらの追加はすべて、特定のニーズから来ていた——「どの請求書が期限切れか確認したい」——カリキュラムからではなく。

トマスはExcelを学んだのではない。問題を解決するのに十分なExcelを学んだのだ。 問題が学習を駆動した。問題が解決されたら学習は止まった。結果は、毎日ビジネスに役立つ実用的なシステムだった。

ミニマム・ナレッジ・パス#

問題が定義されたら、次のステップはミニマム・ナレッジ・パス（minimum knowledge path）の特定だ——今いる場所から問題が解決される場所までの最短の学習ライン。

包括的なカリキュラムではない。ターゲットを絞ったシーケンスだ。

ステップ1：サブ問題をリストアップする#

メインの問題をより小さなピースに分解する。ウェブサイトの例で：

ドメイン名を取得する
構築するプラットフォームを選ぶ
基本的なページレイアウトを作る
ページに写真を追加する
お問い合わせフォームを追加する
モバイルでまともに見えるようにする
公開して他の人が見られるようにする

ステップ2：各サブ問題に対して、必要最小限の知識を特定する#

学べるすべてではなく、最小限だけ。「基本的なページレイアウトを作る」の場合：

見出しの追加方法
セクションの追加方法
要素を横に並べる方法
背景色の追加方法

以上。CSSグリッド理論ではない。レスポンシブデザインの原則でもない。アクセシビリティ基準でもない。それらは重要だ——しかし最初のプロジェクトの3時間目にではない。

ステップ3：ジャスト・イン・タイムで学ぶ#

すべてのサブ問題を事前に学ぶな。それぞれに到達したときに学ぶ。写真を追加する準備ができたら、「[プラットフォーム名]で画像を追加する方法」と検索する。お問い合わせフォームを追加する準備ができたら、「シンプルなお問い合わせフォーム [プラットフォーム名]」と検索する。

ジャスト・イン・タイム学習（just-in-time learning）は需要駆動型学習者の主要モードだ。将来の使用のために知識を備蓄しない。必要な瞬間に知識を取得する。このアプローチが効率的なのは、学びと応用の間のギャップを排除するからだ。学んで、使って、定着する。

ミニマム・ナレッジ・パスの地図#

描いてほしい。文字通り。紙の上でもドキュメントでも：

問題：[あなたの具体的な問題]
    │
    ├── サブ問題1：[説明]
    │   └── 学ぶ：[具体的に検索/読むこと]
    │
    ├── サブ問題2：[説明]
    │   └── 学ぶ：[具体的に検索/読むこと]
    │
    ├── サブ問題3：[説明]
    │   └── 学ぶ：[具体的に検索/読むこと]
    │
    └── サブ問題N：[説明]
        └── 学ぶ：[具体的に検索/読むこと]

この地図が学習プランだ。トピック別ではなく、ニーズ別に整理されている。順番に進めていけば、各ステップが問題解決に測定可能な形で近づく。

学習スコープのコントロール：「学びすぎない」という規律#

需要駆動型学習で最も難しいのは、学習そのものではない。必要以上に学びたいという誘惑に抗うことだ。

プロジェクトに取り組んでいると、面白いものにぶつかる。知らなかった機能。強力に見えるテクニック。より深い理解を約束するラビットホール。誘惑は強い：「これは役に立つかもしれない。ちょっと探ってみよう。」

やめておこう。まだだ。

始めたばかりの段階では、あらゆる脇道が完了への脅威だ。あらゆる寄り道がタイムラインを延ばす。「ちょっと見るだけ」が30分のブラウジングになり、ゴールに1ミリも近づかない。

これは反知性主義ではない。戦略だ。探索の時間はあとでやってくる——しきい値を越えた後、プロジェクトが完了した後、動く成果物を手にした後。能力のある位置からの探索は生産的だ。ゼロの位置からの探索は気晴らしだ。

スタート時点では、知識が増えるほど気が散る。 自分に必要なものを正確に知り、それ以外を無視する学習者は、数日でプロジェクトを完成させる。面白い糸をすべて追いかける学習者は、数ヶ月後もまだ「学習中」で、見せるものは何もない。

スコープコントロールの3つのルール#

関連性テスト： 何かを学ぶ前に問う：「これは定義した問題の解決に直接役立つか？」答えがノーなら、ブックマークして先に進む。
タイマールール： 何かを15分以上調べていて、まだ応用していないと気づいたら、止まる。需要駆動のパスを外れている。
「あとで」リスト： 探索したい面白いことのリストを持っておく——プロジェクト完了後のために。このリストが好奇心の行き場を作り、進捗を脱線させない。

プロジェクトは学習の容器#

需要駆動型アプローチがこれほどうまく機能する理由がある：学習をプロジェクトの中に包んでいるからだ。

プロジェクトには始まりと終わりがある。定義された成果物がある。締め切りを作る——実際のものでも自分で設定したものでも——それが前進させてくれる。そしてゴールラインで手に触れるものをくれる：知識だけでなく、結果を。

結果は思っている以上に重要だ。応用のない知識は脆い。学んで、良い気分になって、使わなかったから忘れる。プロジェクトは応用を強制する。取得した知識のすべてが即座に実践に投入される。応用された知識は定着する。

プロジェクトはモチベーションも提供する。「コーディングを学んでいる」は抽象的で終わりがない。「ポートフォリオウェブサイトを作っている」は具体的で有限だ。進捗が見える。測れる。誰かに見せられる。

プロジェクトの選び方#

需要駆動型アプローチを使うなら、おそらくすでにプロジェクトがある——このプロセス全体を始動させた問題がそれだ。しかし明確な問題が紐づいていないスキルにこのアプローチを適用する場合、プロジェクトの作り方はこうだ：

小さくする。 10〜20時間の作業で完了できるもの。
具体的にする。 「巣箱を作る」は「木工を学ぶ」より良い。
自分にとって意味のあるものにする。 結果が自分にとって重要なら、フラストレーションを乗り越えやすい。
見せられるものにする。 他の人に見せられるもの——ウェブサイト、料理、歌、写真、家具。

プロジェクトが容器だ。学んだすべてがそこに入る。プロジェクトが完了したとき、しきい値を越えている——スキルをマスターしたからではなく、スキルを使って本物の何かを作ったからだ。

需要駆動型学習ループ#

完全なサイクルはこうだ：

問題を定義する。 具体的に。境界を設定。書き留める。
サブ問題に分解する。 小さく、順序立てて、具体的に。
各サブ問題に対して、最小限を学ぶ。 検索、読む、見る——そのステップを試みるのにぎりぎり足りるだけ。
そのステップを試みる。 完璧に理解するまで待たない。不完全な理解で始める。
行き詰まったら、具体的なエラーやギャップを検索する。 「CSSってどう使うの？」ではなく「なぜ画像が中央に寄らないのか？」
次のサブ問題に移る。 繰り返す。
すべてのサブ問題が解決されたら、プロジェクト完了。 しきい値を越えた。

このループが速いのは、学びの1分ごとに実行の1分が結びついているからだ。理論と応用の間にギャップがない。仮想的な将来の使用のための知識の備蓄がない。あるのは：問題、学ぶ、やる、次の問題。

言いたいことを言うために、言語全体を理解する必要はない。 その文から始める。それに必要な文法を学ぶ。口に出す。次の文に進む。

僕はプログラマーではない。でもウェブサイトが必要だった。それだけで始められた。それだけで完成した。そして——具体的な問題、定義されたスコープ、最短のパス——それはあなたにも十分だ。

今夜、問題を定義しよう。書き留めよう。サブ問題をリストアップしよう。明日、最初の1つに取りかかろう。必要なスキルは、すでに抱えている問題の中に隠れている。

第5章 01： 言語からではなく、問題から始めよ#