コードを書き続けることを、そんなに簡単に“卒業”しなくていい理由
最近『スタッフエンジニアの道』などの本を読みつつ、自分のエンジニアとしてのキャリアをよく考えるようになりました。
その中で、過去に見聞きしてモヤモヤしていたことを改めて思い出しました。
それは、一部の人の発言からにじむ「いつまでもコードばかり書いていてもダメで、いつかは卒業するもの」「上流に行かないと成長しない」といった空気です。
一方で、X（旧Twitter）を眺めていると、
「上級エンジニアほど、結局コードの細部に強い」という話もよく目にします。
じゃあ実際のところ、プログラミング経験の“厚さ”って、どこまで意識したほうがいいのか？
自分の体験とここ数年のモヤモヤをベースに、いったん整理してみました。
なぜ「厚いプログラミング経験」は軽視されがちなのか
「プログラミングは誰でもできる」「いつまでもコードを書いていると作業者になってしまう」。
エンジニアのキャリアの話になると、そんな言葉がたまに出てきます。
もちろん、ビジネスや上流工程の理解はとても大事です。
ただ、その裏で 「厚いプログラミング経験」を積むことの価値が、軽く扱われすぎていると感じる場面が増えてきました。
- 「とりあえずコードを書いたことがある」ことで、中身がわかったつもりになってしまう
- 少しの実装経験を足がかりに、早めにPMや上流側に行くほうが格好良い、という空気
- 薄い実装経験は、ソフトスキルや問題解決力でカバーできるはず、という期待
- 今は生成AIが出てきているから、コードを書く力は重要ではなくなっているという認識
こうした前提に立つと、「厚くコードを書く時間」を意識的に確保するインセンティブが弱くなってしまいます。
しかし実際には、設計や品質、レビュー、意思決定の質は、かなりの部分が「どれだけコードと向き合ってきたか」によって左右されます。
経験の厚さが設計と品質にもたらす具体的な影響
テスト容易性を意識した設計ができるか
十分な実装経験があると、自然と「これはテストしづらい設計だな」「ここは関心事をもう少し分けたほうが良いな」といった感覚が育ってきます。
逆に、薄い経験のままだと、保守性や拡張性、テスト容易性が低い設計になっていても、その違和感に気づきにくいまま進んでしまいがちです。
- 関数やクラスの責務が大きすぎる
- 依存関係が密結合で、テストを書くのに過剰なモックが必要
- 「不要なstaticメソッド／グローバルな状態」に頼ってしまう
こうした設計は、小さな修正のうちは問題になりにくいものの、変更が積み重なるほどテストもコードも苦しくなっていきます。
厚い経験があるほど、「今この設計を選ぶと、半年後・1年後にどんなツケが回ってくるか」をイメージしやすくなります。
デザインパターンやアーキテクチャの差を肌感覚で理解できるか
本や記事を通じて、デザインパターンやアーキテクチャの名前を知ること自体は簡単です。
ただし、実際のプロダクトに何度も適用し、その結果を観察した経験がないと、表面的な理解に留まりがちです。
- 「Tell, don’t ask を守ると何が嬉しいのか」
- 「Facadeで隠蔽したほうがいい境界はどこか」
- 「Strategyパターンで切り出すべき処理を、if文の羅列で済ませたときの拡張性の違い」
こういったポイントは、実プロダクトの中で何度も試行錯誤しないと、自分の判断基準として定着しません。
「なんとなく良さそうだから」ではなく、「前にこういう失敗をしたから、今回はこっちにする」という語れる理由が少しずつ増えていきます。
厚い経験は、「どの場面でどのパターンを選ぶべきか」というナレッジを、自分の中に蓄積していくプロセスそのものだと言えます。
良いコード・悪いコードがプロジェクトに与える長期的影響の見積もり
短期的には動くコードでも、長期的には負債になるコードがあります。
逆に、初期コストは少し高くても、長くプロジェクトを支えてくれる設計もあります。
実際に、
- 自分が書いたコードが数ヶ月〜数年後にどうなっていたか
- 自分がメンテする立場として、他人のコードにどう感じたか
を何度も経験していると、
- 「この妥協は今は許容して良い／良くない」
- 「ここは手戻りが大きいので、最初からしっかり設計しておくべき」
といった現実的な判断ができるようになっていきます。
「薄い経験」のまま上流だけを担うことのリスク
実装経験が薄いまま、設計やPMだけを担うようになると、いくつかのリスクが見えてきます。
レビューや設計レビューで重要なポイントを見落とす
コードレビューや設計レビューの場で、
- 「一見きれいに見えるけれど、実はテストがほぼ書けない構造」
- 「変更の影響範囲が読みにくい依存関係」
といったポイントを見抜くには、やはりそれなりの実装経験が必要です。
経験が薄いままだと、「命名」や「コメント量」など、表面的にわかりやすい部分だけを見てOKを出してしまいがちです。
開発者との会話で、無自覚に無理筋な要求をしてしまう
コードに対する感覚がないと、見積もりや実現性の感覚もずれやすくなります。
- 「この程度なら数日でできますよね？」と軽く言ってしまう
- 実は設計ごと見直さないといけない変更を、簡単な修正だと誤解してしまう
こうしたギャップは、開発者側の不信感やモチベーション低下に繋がりかねません。
「なんとなく良さそう」な選択肢を採りがちになる
技術選定やアーキテクチャの議論でも、実装経験が薄いと、
- ドキュメント上のメリットだけを見て判断してしまう
- 具体的な運用や移行のコストを過小評価してしまう
といった判断ミスが起きやすくなります。
厚い経験をどう積み上げるか（個人のキャリア戦略）
フェーズとして「腰を据えてコードを書く時期」を意図的に持つ
必ずしもずっとプレイヤーでいる必要はありませんが、キャリアのどこかのフェーズで、
数年単位で腰を据えてコードを書き続ける期間を意識的に持つことは大きな意味があります。
- 新規開発〜運用・保守までを一通り経験する
- バグ修正やリファクタリングを何度も行う
- テストコードを書き、設計との関係を自分の中で整理する
こうした経験の積み重ねが、後々の設計・レビュー・技術選定の判断軸になります。
「実装→テスト→振り返り」のサイクルを何度も回す
コードを書くこと自体よりも、
- 実装する
- テストを書く・動かす
- 時間を置いてから、設計や読みやすさを振り返る
- 適切なリファクタリングを行う
というサイクルを何度も回すことが重要です。
ここで得た「こうしておけばよかった」「この設計は成功だった」という学びが、経験の厚みそのものになります。
組織としてできること
早期に「上流専任」にしすぎない
若手〜中堅の段階で、早々に実装から完全に離してしまうと、経験の厚みを積む機会を奪ってしまうことになります。
設計や要件定義に関わりつつも、一定量は自分の手でコードを書く機会を設けるほうが、長期的には組織にとってもプラスです。
レビューや設計の場に十分な実装経験者をアサインする
コードレビューや設計レビューの場には、必ず十分な実装経験を持つメンバーを含めるようにします。
表面的な綺麗さだけでなく、テスト容易性や変更容易性など、本質的な観点から議論できるようになります。
キャリアパスの中で「厚さ」を評価軸に含める
評価やキャリアパスの説明の中で、
- どの程度の規模・期間のプロジェクトで
- どのくらいコードと向き合ってきたか
といった「厚み」を、明示的な評価軸の一つとして扱うのも有効です。
そうすることで、「早くコードから離れること」だけがゴールではない、というメッセージを組織として発信できます。
まとめ
- プログラミング経験の厚さは、単なる年数ではなく、「どれだけコードと真剣に向き合ってきたか」の総量。
- 設計・品質・レビュー・技術選定の質は、その厚みによって大きく左右される。
- 個人としては、意図的に「厚く経験を積むフェーズ」を作り、実装→テスト→振り返りのサイクルを何度も回すことが大切。
- 組織としては、厚い経験を正しく評価し、それを活かせる場やロール設計を用意する必要がある。
生成AIや抽象度の高いツールが増えていく時代だからこそ、
「コードとしっかり向き合った経験」を持つエンジニアの価値は、むしろこれから高まっていくのではないかと感じています。
Discussion