「動くコード」が書けても現場で詰む理由

2026年5月25日 01:00

その中で、何度も見てきた場面があります。

新しく入ってきた人が、課題はスラスラ解く。個人開発のポートフォリオも、ちゃんと動く。技術力は十分ある。

なのに、現場のコードをレビューに出すと、先輩から「これ、本番で大丈夫?」と返ってくる。本人はキョトンとしている。だって、動いてるから。

正直なところ、この「動いてるのに、なぜかOKが出ない」の正体に、僕自身もしばらく気づけませんでした。

「動く」と「壊れにくい」は、まったく別のスキルです

一般に、コードが書けるかどうかは「思った通りに動かせるか」で語られがちです。

でも現場で本当に問われるのは、その先なんですよね。

動くコードを書く力と、壊れにくいコードを書く力は、地続きに見えて、実はまったく別のスキルです。

動くコードは、想定どおりの入力が、想定どおりの順番で来たときに正しく動きます。

壊れにくいコードは、想定していない入力が来たとき、深夜に呼び出されないように書かれています。

個人開発で前者はいくらでも鍛えられます。でも後者は、誰かが使うものを作って、それが壊れて、自分で直す経験を通してしか身につきにくい。ここに、現場で詰まる人と詰まらない人の分かれ目があります。

恥ずかしい話を一つ。

昔、僕が書いた処理が、リリース後にちゃんと動いていました。数週間は。

ところが、ある日たまたま「空のデータ」が流れてきた瞬間に、まるごと止まりました。テストでは綺麗なデータしか流していなかったので、誰も気づかなかったんです。

このとき痛感したのが、自分は「動くコード」しか書いていなかったということでした。

正常系しか見ていなかった。空のとき、想定外が来たとき、同時にアクセスが来たとき。そういう「行儀の悪い現実」を、コードが受け止める設計になっていなかった。

実装が動いた瞬間ではなく、運用して初めて気づくこと。これが本当に多いんですよね。

じゃあどう鍛えるか。難しい設計論の前に、僕が新人によく言うのはシンプルな3つの「もし」です。

ひとつ、もし、ここに想定外の値が来たら? 空、null、マイナス、超巨大な数。一行ごとに「変な値が来たら何が起きる?」と問う。

ふたつ、もし、途中で失敗したら? 通信が切れたら。保存に失敗したら。中途半端な状態で止まったとき、データが壊れないか。

みっつ、もし、半年後の自分が読んだら? 意図がコメントや名前から読み取れるか。読み取れないコードは、未来の誰かが壊します。

この3つを通すだけで、コードの「壊れにくさ」はぐっと上がります。派手さはありませんが、現場で効くのはこの地味さなんです。

動くコードが書けることと、壊れにくいコードが書けることは別のスキルでした。前者は一人でも鍛えられますが、後者は「誰かが使うものを、想定外も含めて受け止める」設計を意識することで育っていきます。3つの「もし」は、その第一歩です。

この「壊れにくさを設計できる力」は、地味なわりに市場ではかなり高く評価されます。採用に関わってきた立場から言っても、ここを語れる人は強い。逆に、今の現場が正常系を回すだけで、想定外を考える経験を積めない環境だとしたら、それは自分の伸びにとってもったいないかもしれません。

もっと設計や運用にしっかり向き合える場所で、自分の市場価値を確かめてみたい人には、こういう選択肢もあります。今すぐ動かなくても、どんな現場が評価されるのかを知るだけで、明日のコードの書き方が変わります。

動くだけのコードから、壊れにくいコードへ。その一歩が、あなたの評価を静かに押し上げてくれるはずです。