はじめに

この記事は、こんな人に向けて書いています。

講座や本でインプットした「つもり」なのに、いざ実務で手が止まる

学んだことが、3ヶ月後にはきれいさっぱり抜けている

アウトプットが大事なのは知ってる。けど続いたことがない

先に結論を言います。私がやったのは、たった一つです。

概念理解 → ハンズオン → 実務適用 → 記事化。この学習サイクルの一番最後に、Qiitaへの記事化を「固定の工程」として組み込んだ。本当にこれだけなんです。

それだけで、学んだことの定着率が体感で別物になりました。ありがたいことに、ある月のQiita月間ユーザーランキングで2位になれたこともあります。とはいえ今日の本題はランキングの話ではありません。「なぜ書くと学べるのか」——その正体を、自分の恥ずかしい失敗込みで分解してみます。

ところで、ひとつだけ聞かせてください。
最近インプットしたあの技術、あなたはいま、誰かに「説明」できますか？

インプットだけしていた頃の私

動画講座を1.5倍速で流し見して、技術書にマーカーを引いて、「あー完全に理解した」とつぶやく。あの頃の私の勉強は、これで完結していました。

Udemyの講座を見終わると、進捗バーが100%になる。あの達成感、たまらないですよね。でも——次の週に実務で似たような課題に当たると、手がまったく動かない。「見たことはあるのに、書けない」。この現象に、当時の私は何度も打ちのめされました。

知識には「見たことがある」と「使える」の間に、深くて広い谷があります。インプットだけしていた頃の私は、その谷の存在にすら気づいていなかったんです。

転機：async/awaitを、私は「分かったつもり」だった

決定的だったのは、自分で書いた非同期処理のコードを、解説記事にまとめようとしたときでした。

当時の私はWebアプリを開発していて、複数の外部APIからデータを取ってくる処理を書いていました。await を並べれば、ちゃんと動く。実際、問題なく動いていました。でも、なぜか遅い。3件取得するだけで3秒近くかかる。「ああ、await で1件ずつ順番に待ってるからか」——そこまでは、すぐに分かりました。

問題はその先です。記事に「JavaScriptはシングルスレッドなのに非同期処理ができる」と書こうとして、指が止まりました。

待ってほしい。シングルスレッド、つまり一度に1つのことしかできないはずなのに、なぜ"待っている間に別の処理"が進むんだ？　そもそも await は、結局なにを「待って」いるんだ？　async/await は、それこそ毎日書いていました。書けていた、はずなんです。でも、その裏側で何が起きているかを自分の言葉で説明しようとした瞬間、一文字も進まなくなった。

そこで初めて、腰を据えて調べ直しました。コールスタック、Web API、タスクキュー、そしてイベントループ。バラバラだった点が、ようやく一本の線でつながった。await は「待つ」のではなく、「いったん関数の実行を中断して、制御をイベントループに返している」だけ——これが腹に落ちた瞬間、正直ちょっと鳥肌が立ちました[^1]。

ここで私は、身も蓋もない事実に気づきました。読んで分かった気になっていた知識のほとんどは、書こうとした瞬間に崩れる。動かせることと、説明できることは、まったくの別物だったんです。

あなたにも、「毎日使っているのに、いざ説明しようとしたら急に自信がなくなった」コードや概念は、ありませんか。

「書くと学べる」の正体を分解する

精神論で終わらせたくないので、なぜ書くと学べるのかを3つに分解します。

1. アウトプットは"理解の穴"を可視化する

インプットは、穴があっても進めてしまうんですよね。動画は私が分かっていなくても再生を続けるし、本は黙ってページがめくれる。でも文章は違う。穴があると、そこで手が止まる。

書けない一文は、自分が分かっていない一点と、ほぼ正確に一致します。だから私はこれを逆手に取りました。書いていて詰まったところ「だけ」を調べ直す。最初から完璧に調べようとしない。これが負荷設計として、とても効率的でした。

インプット段階で「念のため全部押さえておく」のは、実はコスパが悪い。アウトプットで詰まった箇所こそ「自分にとって本当に必要な穴」なので、そこを埋める学習は費用対効果が段違いに高いです。

2. 「説明できる」は、理解できている証明になる

自分が理解しているかどうかって、自分では驚くほど判定できません。判定するいちばん確実な方法は、知らない人に説明してみることです。いわゆるファインマン・テクニックですね。記事を書くという行為は、これを強制的にやらされる仕組みそのものでした。

専門用語でごまかせない。曖昧なまま「など」で逃げると、自分で読み返して気持ち悪い。この「気持ち悪さ」が、理解を一段深く掘らせてくれます。

3. インプットの質まで勝手に上がる

不思議なもので、「あとで書く」と決めてインプットすると、読み方が変わります。受け身で眺めるのではなく、「これはどう説明する？」「ここの理屈は？」と能動的にツッコミながら読むようになる。

ちなみに最近の私のインプットの主役は、公式ドキュメントとAIとの対話です。英語の動画講座を何本も挫折してきた私が言うのもなんですが、「分からない箇所をその場で何度でも質問できる」対話型の学習は、受け身の動画より圧倒的に手が早い。

ただしAIの回答は鵜呑みにしません。最後は必ず公式ドキュメントで裏を取る。これは「記事として世に出す」前提があると、自然に身につく習慣でした。間違ったことを書くのが、純粋に怖いので。

私の学習サイクル：記事化を"最終工程"に固定する

言葉で説明するより図のほうが早いので、貼ります。

肝は、記事化が「おまけ」でも「気が向いたら」でもなく、サイクルの固定工程になっていることです。学んで、手を動かして、使ってみたら、最後に必ず書く。書くと穴が見つかる。穴を埋めるために概念へ戻る。この一周で、知識が「使える」側の谷へ渡っていきます。

実務がまだない人は、「実務適用」を個人開発・Kaggle・写経や模写に置き換えてください。サイクルは何ら変わりません。むしろ学び始めの時期ほど、このループの効きが速いと感じます。

アウトプットが「機会」を連れてきた

正直に言うと、最初は完全に自分のためだけの記事でした。誰かに読まれることなんて期待していなかった。でも続けているうちに、思ってもみなかった副作用が出てきたんです。

書いた記事がきっかけで、社外の人から声をかけてもらえる
ハッカソンで、自分の引き出しからスッと手が動く（オープンデータのハッカソンで優勝できたときも、書いて整理してきた蓄積が確実に効いていました）
そして、ある月にはQiitaの月間ランキングで2位に届いた

アウトプットは「払って消える支出」ではなく、ストックされて勝手に複利で効いてくる「資産」でした。これは続けてみて初めて分かった感覚です。

それでも続かない人へ：私がやめた3つのこと

偉そうに書いていますが、私だって何度も挫折しています。続けられるようになったのは、むしろ「やめたこと」が3つあったからでした。

完璧に理解してから書く、をやめた（これが一番大きい。完璧主義は最大の敵でした）
バズりを狙う、をやめた（自分の理解のため、と割り切る）
長く書こうとする、をやめた（詰まった1点だけでも、立派に記事になる）

ビフォーアフターにすると、私の変化はこれだけです。

- 完璧に理解してから、長くて立派な記事を書く（そして9割は下書きフォルダで眠ったまま死ぬ）
+ 詰まった1点を、その日のうちに短く書いて公開する

今日から試せる3ステップ

明日から、ではなく今日から試せる形にしておきます。

直近で学んだ技術を、何か一つ選ぶ
それを「何も知らない後輩に説明する」つもりで、500字だけ書いてみる
途中で手が止まる一文が出てきたら——おめでとうございます。そこが、あなたの伸びしろです

たった500字で構いません。大事なのは、止まった場所を見つけることなので。

おわりに

「書くと学べる」は気合いや根性の話ではなく、理解の穴が可視化されるという、わりと身も蓋もないメカニズムの話でした。もし学びが定着しないと悩んでいるなら、インプットを増やす前に、いちど"出す"側に回ってみてほしいです。