元エンジニアが語る「コードを書くだけの自分」が物足りなくなって、テクニカルディレクターを選ぶまでのリアルな5年間

1年目〜2年目：「とにかく実装が楽しい」だけで走り切った時期

新卒でフロントエンドエンジニアとして入社した頃は、とにかくコードを書くのが楽しくて仕方ありませんでした。jQueryで動きをつけて、SassでCSSを整理して、WordPressテーマを組んで…。
気づけば終電、でも「プロダクトが動く」ことがうれしくて、要件の背景やビジネスゴールは正直あまり見えていませんでした。
ディレクターとクライアントが何を話しているかも「自分には関係ない領域」と感じていて、打ち合わせ資料を見るよりVS Codeを開いていたい、そんな2年間でした。

3年目前半：Git運用と公開作業を任されて見えた「裏側」

転機のひとつは、社内でGit運用と本番公開を任されるようになったことです。
リポジトリ設計やブランチ運用、レビューの順番、リリース手順…どれか一つでも崩れると、公開日に事故る。そのプレッシャーの中で、「コードを書くだけ」ではプロジェクトは完結しないと痛感しました。
同時に、ドメイン・サーバ移管やSSL更新など、インフラ寄りのタスクにも関わり始め、クライアントの「ビジネスの止まらなさ」が技術より優先される場面を体験したのも大きかったです。

3年目後半：見積もり・要件定義に少しずつ混ざり始めたステップ

そのうち、ディレクターから「この要件って、どのくらい工数かかりそう？」と聞かれるようになりました。
最初は感覚で「1日くらいですかね」と答えて、実際は3日かかる…という失敗も多発。ここから、
・作業を細かく分解して積み上げる
・「リスク」と「確認待ち時間」も工数に含める
といった考え方を学びました。
要件定義の打ち合わせメモを自分なりにテンプレ化し、「誰が・いつまでに・何を決めるか」を整理しておくと、後工程（自分自身のコーディングも含む）が劇的に楽になることにも気づきました。

4年目：初めてのクライアント打ち合わせでやらかした話

4年目、ついにクライアントとの打ち合わせに「技術担当」として同席することに。
当日は、専門用語を並べすぎて、先方の担当者の表情がどんどん固くなっていきました。「レスポンシブ対応」「カスタムポストタイプ」「ステージング環境」などを説明なしで連発し、後から上長に「相手の言語で話そう」と真顔でフィードバック。
この失敗から、
・専門用語はかみ砕いて例える
・相手が本当に知りたいのは「できるか・いくらか・いつまでか」
という基本に立ち返り、以降は「翻訳者」としての役割を意識するようになりました。

5年目：「テクニカルディレクター」という肩書きに腹落ちした瞬間

案件の流れを一通り経験し、「コードを書く自分」と「プロジェクトを動かす自分」が頭の中でつながってきた頃、「テクニカルディレクター」という言葉に初めてリアリティが出てきました。
特に、WordPress案件で設計段階から入り、
・情報設計とカスタムフィールド設計をセットで考える
・将来の運用を見据えた管理画面のUIを提案する
といったことができたとき、「実装者」ではなく「技術で意思決定を支える人」にシフトしている実感がありました。MARUTTOのように、コーダーとクライアントの橋渡し役を担うポジションは、自分の志向にフィットしていました。

明日からできる「テクニカルディレクターへの一歩」

もし今、「この先ずっとコーディングだけでいいのかな」と感じているなら、いきなり職種変更を考える必要はありません。明日からできる一歩として、例えば次のようなことがあります。
・自社案件の公開作業やサーバ移管に手を上げてみる
・要件整理のメモを自分なりにテンプレ化してみる
・WordPress案件で「設計側の視点」でコードレビューしてみる
こうした小さな実践を積み上げていくと、「コードが書けるだけの自分」から、「技術でプロジェクトを動かせる自分」への道が、自然と見えてきます。