はじめに
「最近、コードを書く時間がめっきり減った。」
リーダーやテックリードになった人なら、一度はこの感覚を覚えたことがあるはずです。
レビュー、設計判断、チーム間の調整、技術選定。気づけば一日の大半が、コードエディタではなく、ドキュメントやミーティングに費やされている。
本記事は、シニアエンジニア〜テックリード、あるいは「最近コードを書く時間が減ってきた」と感じ始めたエンジニアに向けて書いています。
この変化に対して、「自分は現場から離れてしまっているのではないか」という不安を感じる人は少なくありません。
手を動かしていた頃のほうが、明確にアウトプットが見えていた。PRを出せば仕事をした実感があった。それがなくなると、自分の貢献が曖昧に感じられるようになります。
ですが、この変化には構造的な理由があります。
コードを書かなくなったのではなく、扱う対象のレイヤーが変わったのです。
本記事では、エンジニアが経験を重ねるなかで「書く仕事」から「決める仕事」へとレイヤーが移行していく構造を整理し、その移行をどう意識的に進めるかを考えます。
思想だけでなく、擬似コードや図解、具体的な事例を通じて、実務の解像度で捉えていきます。
第1章：コードを書く時間が減るメカニズム ── 役割の移行は自然な構造変化である
エンジニアのキャリアには、いくつかの役割レイヤーがあります。
ジュニアの頃は、与えられたタスクを正確に実装することが求められます。時間の大半はコーディングに使われ、それが成果そのものでした。
シニアになると、自分の実装だけでなく、設計方針やレビューに時間を割くようになります。「どう書くか」だけでなく、「なぜこう書くのか」を説明する場面が増えます。
テックリードやマネージャーになると、さらにレイヤーが上がります。技術選定、アーキテクチャ判断、チーム間の認識合わせ、スケジュール調整。コードを書く時間は物理的に圧縮されていきます。
この変化を、役割ごとの時間配分として可視化すると、次のようになります。
ここで注目すべきは、どのレイヤーでも「何もしていない時間」は存在しないという点です。
コーディングの比率が減った分、設計判断や組織調整の比率が増えている。つまり、仕事の中身が入れ替わっているだけで、価値を出す対象が変わっています。
「コードを書く＝価値を出す」という等式は、ジュニアの段階では成り立ちます。ですが、レイヤーが上がるにつれて、「正しい判断を下す＝価値を出す」へと、等式そのものが書き換わっていきます。
この書き換わりに気づけるかどうかが、レイヤーの移行をスムーズに進められるかどうかの最初の分岐点です。
第2章：意思決定とは何か ── コードで見る「判断の抽象度」の違い
「意思決定に時間を使う」と言っても、その中身は抽象的に聞こえがちです。
ここでは、エンジニアにとって馴染み深い「コード」を使って、判断の抽象度がどう変わるのかを見てみます。
まず、実装レベルの判断です。
たとえば、キャッシュ戦略をどう組むか。これは条件分岐として書き下ろせる判断です。
text【擬似コード①：実装レベルの判断 ── キャッシュ戦略】 function getUser(userId): cached = cache.get(userId) if cached AND cached.age < TTL: return cached.data // キャッシュが有効 → そのまま返す if cached AND cached.age >= TTL: data = db.fetch(userId) cache.set(userId, data, TTL) // 期限切れ → 再取得して更新 return data data = db.fetch(userId) cache.set(userId, data, TTL) // キャッシュなし → 取得して格納 return data
この判断は「TTLの値をいくつにするか」「キャッシュの有無でどう分岐するか」という、比較的明確な条件の組み合わせで構成されています。正解・不正解が検証しやすく、テストコードでカバーできます。
次に、設計レベルの判断です。
たとえば、ユーザー管理機能をモジュールとしてどう分割するか。
text【擬似コード②：設計レベルの判断 ── モジュール分割の方針】 // 方針A：機能単位で分割 modules: - UserRegistration // 登録処理 - UserAuthentication // 認証処理 - UserProfile // プロフィール管理 - UserNotification // 通知管理 // 方針B：ドメイン境界で分割 modules: - Identity // 登録 + 認証（「誰であるか」を担う） - Engagement // プロフィール + 通知（「関係性」を担う） // この判断は if文では書けない。 // 判断の根拠になるのは： // - 今後の変更頻度はどこが高いか // - チーム構成はどうなっているか // - 外部連携の境界はどこに引くべきか // - 2年後のプロダクト方針はどう見えているか
方針Aと方針Bの間に、技術的な正解はありません。
どちらが正しいかは、チーム構成、プロダクトの方向性、変更頻度の見込み、外部連携の設計など、コードの外側にある情報によって決まります。
この二つの擬似コードが示しているのは、判断の抽象度には明確なレイヤーがあるということです。
レイヤーが上がるほど、「正解がテストで検証できない」領域に入っていきます。
そして、CTOやテックリードが日々向き合っているのは、まさにこの上位レイヤーの判断です。
コードを書く時間が減るのは、扱う判断のレイヤーが上がったからであり、判断そのものが消えたわけではありません。むしろ、一つひとつの判断が持つ影響範囲が大きくなるからこそ、慎重に時間をかける必要があるのです。
第3章：「決める仕事」の解像度を上げる ── 意思決定の実務プロセス
意思決定と聞くと、経験豊富なリーダーが直感的に「こうだ」と決断する姿を思い浮かべるかもしれません。
ですが、実務における意思決定は、一瞬のひらめきではなく、プロセスです。
具体的な事例で見てみます。
新規プロジェクトの立ち上げ時、フレームワークの選定を任されたとします。候補はいくつかあるが、チーム内でも意見が割れている。クライアントからは早期に方針を固めてほしいと言われている。
このとき、テックリードが踏むべきプロセスは、おおよそ次のような流れになります。
BtoB向けの業務管理システムを新規で構築する案件で、フレームワークの候補が3つに絞られたとします。チームは5名、フロントエンドとバックエンドの両方を担当する構成です。
テックリードはまず、制約を洗い出します。
クライアントの既存システムはRDBを前提としており、APIの形式にも要件がある。チームメンバーのうち3名はフレームワークXの経験があるが、フレームワークYは未経験。納期は6ヶ月。運用フェーズではクライアント側のエンジニアも関わる予定で、学習コストの低さも選定基準に入る。
次に、選択肢ごとのトレードオフを言語化します。
フレームワークXはチームの習熟度が高く、立ち上がりが早い。ただし、今回の要件で求められるリアルタイム処理には標準では対応しておらず、追加のライブラリ選定が必要になる。フレームワークYはリアルタイム処理に強いが、チームの学習コストがかかり、納期に対するリスクがある。フレームワークZは両方の要件をカバーするが、コミュニティが小さく、長期運用での情報量に不安が残る。
最終的に、テックリードはフレームワークXを選定します。理由は、チームの習熟度と納期を優先し、リアルタイム処理部分は追加ライブラリで補う方針が現実的だと判断したからです。
ここで重要なのは、「Xが最も優れているから選んだ」のではないという点です。
制約の中で、最もリスクが低く、説明可能な選択をした。 これが、実務における意思決定の実態です。
そして、「なぜYやZを選ばなかったのか」を記録しておくことで、後から方針を見直す際にも、判断の経緯をたどれるようになります。
この一連のプロセスは、コードを書く作業とはまったく異なる時間の使い方です。しかし、ここでの判断が実装フェーズ全体の方向性を決めます。
だからこそ、CTOやテックリードはこの工程に時間をかけるのです。
逆に、このプロセスを省略した場合に何が起きるかも触れておきます。
あるプロジェクトで、テックリードが技術選定の判断理由を明文化せずに進めたケースがありました。選定時点では関係者の間で口頭の合意が取れており、問題はないように見えていました。
しかし半年後、メンバーの入れ替わりや要件の追加が重なったタイミングで、「なぜこの技術を選んだのか」が誰にも説明できない状態に陥りました。結果として、本来不要だったはずの再選定の議論に2スプリント分の時間が費やされ、開発ロードマップ全体に遅延が波及しました。
判断そのものは当時として妥当だったかもしれません。ですが、「なぜそう決めたか」を残さなかったことが、数ヶ月後に実工数として跳ね返ってきたのです。
先ほどのフロー図の⑤「決定し、根拠を記録する」は、まさにこのリスクを防ぐためのステップです。意思決定の質とは、判断の正しさだけでなく、その判断を組織の資産として残せるかどうかも含みます。
第4章：レイヤーを移行するための戦略 ── コードを手放す恐怖とどう向き合うか
レイヤーが上がることの構造は理解できたとしても、実際にコードを書く時間を減らしていくことには、心理的な抵抗が伴います。
「手を動かしていないと、貢献していない気がする。」
この感覚は、エンジニアとしてコードを書いてきた時間が長いほど、根深いものになります。なぜなら、それまでのキャリアでは、「手を動かすこと」と「成果を出すこと」がほぼ同義だったからです。
この感覚を乗り越えるための一つの視点は、レビューの観点の変化に目を向けることです。
コードレビューは、テックリードの日常業務の中でも大きな割合を占めます。ですが、レイヤーが上がるにつれて、レビューで見るべき観点も変わっていきます。
text【擬似コード③：レビュー観点の変化】 // ── シニアエンジニアのレビュー ── // 「実装の正しさ」を見る review(pullRequest): check: 命名規則は統一されているか check: エッジケースは処理されているか check: パフォーマンスに問題はないか check: テストは十分にカバーしているか → 焦点は「このコードは正しく動くか」 // ── テックリードのレビュー ── // 「設計意図との整合性」を見る review(pullRequest): check: この実装は、合意した設計方針と整合しているか check: モジュール間の依存関係は意図通りか check: この変更が他チームの作業に影響を与えないか check: 半年後の拡張計画を考慮した構造になっているか → 焦点は「このコードは正しい方向に向かっているか」
→ 焦点は「このコードは正しい方向に向かっているか」
同じ「レビュー」という行為でも、見ている対象のレイヤーが異なります。
シニアエンジニアのレビューは、コードの内側を見ています。テックリードのレビューは、コードの外側、つまり設計方針やプロダクトの方向性との整合を見ています。
この観点の違いは、「手を動かしていない」のではなく、「手を動かす方向を定めている」ことの表れです。
もう一つ、テックリードが「書かない時間」で何をしているかを、ある1週間のカレンダーで見てみます。
text【テックリードのある1週間】 月曜 09:00 スプリントプランニング（チームの作業優先度を調整） 11:00 アーキテクチャレビュー（新機能の設計方針をレビュー） 14:00 クライアントとの技術仕様すり合わせ 16:00 コードレビュー × 3本 火曜 09:00 チームの技術課題の整理（技術的負債の優先度付け） 11:00 他チームとのAPI仕様調整 14:00 1on1 × 2名（メンバーの技術的な壁打ち） 16:00 自分の設計ドキュメント作成 水曜 09:00 障害対応の振り返りミーティング 11:00 技術選定の調査・比較資料作成 14:00 コードレビュー × 2本 16:00 プロダクトマネージャーとのロードマップ議論 木曜 09:00 設計判断の意思決定ドキュメント作成 11:00 新メンバーのオンボーディング設計 14:00 実装（リファクタリングの設計検証） 16:00 チーム全体の進捗確認・ブロッカー解消 金曜 09:00 週次の技術レポート作成 11:00 コードレビュー × 2本 14:00 来スプリントの設計準備 16:00 個人の技術キャッチアップ（論文・ブログ・OSS）
1週間のうち、純粋にコードを書いている時間は木曜の午後の一部程度です。
しかし、この1週間の中で下された判断や調整が、チーム全体の実装方針を決め、手戻りを防ぎ、プロダクトの方向性を守っています。
レイヤーの移行とは、「手を動かすこと」をやめることではなく、「手を動かす対象」を変えることです。
では、コードを書く力はもう必要ないのか。そうではありません。
コードを書ける人が設計判断をするのと、書けない人が設計判断をするのでは、判断の精度がまったく異なります。実装の手触りを知っているからこそ、設計の妥当性を肌感覚で評価できる。メンバーの技術的な困りごとを、抽象的なアドバイスではなく、具体的な選択肢として提示できる。
コードを書く力は、レイヤーが上がっても判断の土台として機能し続けます。
だからこそ、完全に手を離すのではなく、意識的に書く時間を確保しながら、判断のレイヤーを上げていくことが、現実的な戦略になります。
では、「意識的に書く時間を確保する」とは、具体的にどういうことか。
現実的なラインとして、次のようなプラクティスが挙げられます。
一つ目は、月に1つは自分がオーナーのPRを持つこと。大きな機能である必要はありません。小さなリファクタリングでも、自分の手でコードを書き、レビューを受ける側に回ることで、実装の手触りを維持できます。
二つ目は、技術的に最もリスクが高い部分だけは自分で触ること。新しいインフラ構成の初期実装、外部APIとの接続部分、パフォーマンスのボトルネックになり得る箇所。こうしたリスクの高い領域を自分で検証することで、設計判断の精度を裏側から担保できます。
三つ目は、検証コードやPoCは自分で書くこと。技術選定やアーキテクチャ判断の前段階で、小さなプロトタイプを自分の手で動かしてみる。ドキュメントやベンチマーク記事を読むだけでは得られない、実装レベルの感触が判断の根拠になります。
いずれも「フルタイムで実装に戻る」ことではありません。判断の質を支えるために、必要最小限のコードを自分の手で書き続けるという姿勢です。
おわりに：書くことと決めることは、対立しない
CTOやテックリードがコードを書く時間が減るのは、怠けているからでも、現場から逃げているからでもありません。
扱う判断のレイヤーが上がり、一つの判断が持つ影響範囲が大きくなるにつれて、そこに時間を使うことが、チームやプロダクトにとって最も価値のある貢献になるからです。
ただし、意思決定の質は、実装の理解に裏打ちされて初めて高まります。
コードを書かなくなったとしても、「書ける」という土台は残り続ける。むしろ、その土台があるからこそ、設計判断や技術選定の精度が保たれます。
書くことと決めること。この二つは対立するものではなく、キャリアの中で比重が変わっていくだけです。
大切なのは、その比重の変化を「衰退」と捉えるのではなく、役割のレイヤーが移行しているのだと意識的に理解することです。
「なぜ自分はコードを書く時間が減ったのか」に対して、焦りではなく構造として答えられるようになったとき、エンジニアとしてのキャリアは、次のレイヤーに進んでいます。
意思決定の質を上げ続けること。そして、その判断を支える実装力を錆びさせないこと。
この二つを持ち続ける人が、技術組織の中で信頼され、レイヤーを上げ続けていくのだと思います。