ありがたいことに最近案件をいただいて、久しぶりに問題集を解いてみました。初学者向けとのことだったので、初心者向けの教本を選びました。そこで改めて感じたのが、読む力と書く力はやはり別だということです。普段の実務や改善では読んで判断する時間が多くても、いざ自分で基礎から書こうとすると、感覚の鈍りはかなり正直に出ます。
一番印象に残ったのは、知っているはずの処理で一瞬手が止まることでした。問題文を読めば、やるべきことは分かる。既存コードを見れば、意図も追える。でも、空のエディタに向かった瞬間に、以前より書き出しが遅い。これは能力がゼロになったというより、書く感覚は使わないと鈍る、という当たり前を改めて見せられた感じに近いです。
例えば SQL なら、`INSERT` 文を一度書いて、それを似た場面で流用することは実務では普通にあります。ただ、それに寄りすぎると「この形で正しかったか」を身体で覚えている感覚は薄れます。Java でも同じで、読めるしレビューもできるけれど、基礎構文をゼロから整えて書く速度は触っている量に素直に比例する。今回そこを再確認しました。
つまり今回の話は、「全く書けなくなった」という告白ではなく、「書く感覚は放っておくと鈍る」というかなり実務的な話です。そして、その鈍りは補助ツールが強くなる時代ほど見えにくいからこそ、意識して見直した方がいいと感じました。
この記事の要点
- コードが読めることと、自分で書けることは別です。実務では、読む力だけでは足りません。
- コピペや使い回しに寄りすぎると、文法も読解も少しずつ鈍ります。
- AI 時代ほど、書く量が減るぶん「自分の手で組み立てられるか」が問われやすくなります。
- 補助ツールが強くなるほど、考える量まで外に預けないことが重要になります。
- 感覚を戻すには、テンプレの流用だけで終わらせず、定期的にゼロから書き直す時間が必要です。
- 最終的に必要なのは、人がロジックを生み出し、形にする力です。
読めることと、書けることは別物
ここは厳密に分けて考えた方がいいです。コードを読める人は多いです。処理の流れも分かるし、何をしているかも大体追える。でも、いざ自分で同じものを書こうとすると、以前より時間がかかることがある。これが今回あらためて見えた差でした。
実務は、既存コードの理解だけで終わりません。自分で組み立てる、書き出す、崩れた文法を直す、その場で処理を成立させるところまで必要です。読む力だけで現場が回るわけではなく、最後は自分で書けるかが問われます。
しかも厄介なのは、読める人ほど「まだ感覚は残っている」と思いやすいことです。見れば理解できるから、手も動く気がしてしまう。でも実際には、理解できることと再現できることの間に差があります。空の状態から立ち上げられるかどうかで、その差はかなり見えます。
使い回しは便利だけど、感覚を削る
SQL は特にそうでした。`INSERT` 文を一度書いて、それを使い回していれば一応進みます。テーブル名だけ変えて、似た処理を流す。実務では珍しくないやり方です。でも、その楽さに寄りすぎると、基礎の感覚が消えます。
見れば分かる。コピペすれば動く。でも何も見ずに書こうとすると曖昧になる。この状態は危ないです。なぜなら、少し仕様がズレた瞬間に対応できなくなるからです。
使い回しは悪ではありません。問題は、それだけで済ませ続けることです。似た形を貼り替えるだけの作業が増えると、自分で文を組み立てる筋力が落ちる。すると、ほんの少し違う要件や少し変わった制約に対しても、立ち上がりが鈍くなります。
補助が強い時代ほど、考える量は手放せない
今後さらに、書く量そのものは減っていくと思います。バイブコーディングを回し、エージェントを使い、試作速度はますます上がるはずです。それ自体は良いことです。ただ、その流れの中で「自分は何を考えているのか」まで薄くなると危ない。
`AGENTS.md` を使おうが `.claude` を使おうが、最終的には人が描かなければ意味がない。何を作るのか。どこを直すのか。どのロジックを採用するのか。そこを人が決めていないなら、速く動いても中身は弱いままです。
革命が起きても、土台は人のコード
この2年ほどで、コーディングにはかなり大きな革命が起きました。書く速度も、試作の速さも、明らかに変わったと思います。でも、その革命も人が書いたコードで成り立っています。革命も衰退も、人が巻き起こしていくものです。
だからこそ、業界が変わるほど、自分に問い直さないといけない。本当に必要なのは何か。読む力だけで満足していないか。書く感覚を失ったまま、分かった気になっていないか。ここは一度きちんと見た方がいいです。
感覚を戻すには、あえて自分で書く時間がいる
今回の件で、自分の中では対処もかなりはっきりしました。テンプレを流用するだけで終わらせず、定期的にゼロから書く時間を作ることです。短くてもいいから、SQL を何も見ずに一回書く。Java の基本構文を自分の手で組み立て直す。こういう地味な時間が、多分一番効きます。
AI を使うなという話ではありません。むしろ使った方がいい。ただ、その前後で「自分ならどう書くか」「なぜこの文法になるのか」を一回言葉にしてから手を動かす。そこを挟まないと、便利さだけが残って、自分の筋力は戻りません。
実務で必要なのは、全部を暗記することではありません。必要な時に基礎へ戻れること、ズレを自分で直せること、そして似た処理でも文法を再構成できることです。今回の記事で言いたかったのは、そこです。
仕事になるのは、最後に書ける人
今回の案件で改めて思ったのはここです。読めても書けなければ、仕事にはならない。テストに通ることと、実務で自信を持って組み立てられることは別でした。そして、その差は補助が強い時代ほど見えにくくなります。
AI 時代でも、最終的に必要なのはロジックを生み出し、自分の手で形にできる人です。補助が強くなるほど、逆にそこはごまかしにくくなる。変わりゆく業界の中で、本当に必要なものは何なのか。今一度、自分自身に問い直してみる価値はあると思っています。
読む力がある人ほど、この問いは重いはずです。自分はまだ基礎から書けるのか。何もないところから立ち上げられるのか。その確認を避けないことが、これからのプログラマーには必要だと思っています。
よくある質問
コードが読めれば実務では十分ではないのですか？
十分ではありません。実務ではゼロから組み立てる、文法を思い出す、処理を正確に書く力が必要です。読めるだけでは仕事として完結しません。
AI やコピペで書く量が減ると何が起きますか？
使い回しに寄りすぎると、文法や組み立ての感覚が鈍ります。見れば分かるのに、自分で書こうとすると手が止まる状態になりやすいです。
これからのプログラマーに必要なのは何ですか？
最終的には人がロジックを描き、何を作るかを決める力です。補助ツールを使っても、書ける感覚を失わないことが重要です。