ジュニアからテックリードへ：3年間の成長ロードマップと実践例

テックリードへの成長には、技術力だけでなく、改善を測る力、チームに定着させる力、関係者と判断基準をそろえる力が必要です。

この記事では、ジュニアのインフラエンジニア「中村」が3年間でテックリードの役割を担うまでを、行動、成果、評価材料の順にたどります。

中村は実在の個人ではなく、複数の事例を統合した架空のケースです。本文の数値はこのケース内の変化を示すものであり、すべての組織に当てはまる基準ではありません。

このケースで扱う成長の全体像

中村が所属するのは、プロダクトエンジニア40名とSREまたはプラットフォーム担当7名で構成され、複数のスクワッドが開発を進める組織です。

入社時の担当は、クラウド運用とCI/CDの補助を担うジュニアインフラエンジニアでした。CI/CDは、コードの変更を継続的に検証し、本番環境へ届ける一連の仕組みです。具体的な構成を知りたい場合は、CI/CDパイプラインの実装例も参考になります。

成長を支えた組織の前提

このケースの「成長しやすい環境」は、単に新しい技術を使える職場を意味しません。失敗から学び、小さな改善を測定し、その結果を次の役割につなげられる環境を指します。

• ブレームレスなふりかえり：個人を責めるのではなく、判断に使えた情報や仕組みを検証します。
• 小さく試して測る習慣：試行、検証、標準化の順で進め、効果が不明なまま全体へ広げません。
• 役割と成果を結び付ける評価：肩書だけでなく、担当範囲と生み出した変化を評価材料にします。
• レビューを育成に使う文化：週次デモやプルリクエストのレビューを、品質確認と知識共有の両方に使います。

運用では、SLO、エラーバジェット、変更失敗率、MTTR、クラウドコストを継続的に確認します。

• SLO（サービスレベル目標）：可用性や応答時間など、利用者に提供したい信頼性の目標です。
• エラーバジェット：SLOを守る範囲で許容できる信頼性低下の余地です。
• 変更失敗率：本番への変更のうち、障害や修正対応につながった変更の割合です。
• MTTR：この記事では、障害や失敗した変更から復旧するまでの平均時間として扱います。

1年目は小さな改善を測定可能にする

1年目の課題は、安定運用の習慣を身につけ、自動化の効果を数字と成果物で示すことでした。

中村はLinux、ネットワーク、HTTP、クラウド、IaCの基礎を、日々の担当業務に必要な範囲から学びました。IaCは、サーバーやネットワークなどの構成をコードで定義し、同じ手順を繰り返せるようにする考え方です。このケースではTerraformを使っています。

3か月までの改善

• デプロイジョブを分割して並列に動かし、平均デプロイ時間を28分から12分へ短縮しました。
• 監視メトリクスの命名規則を整え、誤検知アラートを週35件から8件へ減らしました。

どちらも「ツールを導入した」という説明で終わらず、変更前と変更後を同じ指標で比較しています。改善の価値を共有するには、作業量ではなく、待ち時間や誤検知がどの程度変わったかを示す必要があります。

半年までの改善

• バックアップ検証を自動化し、週次検証の成功率を70%から99%へ引き上げました。
• 主要なランブックをMarkdownで整備し、オンコールの引き継ぎ時間を30%短縮しました。

ランブックは、障害対応や定常運用の手順と判断条件をまとめた文書です。手順だけでなく、確認すべき状態と中止条件まで書くことで、担当者が変わっても対応を再現しやすくなります。

1年目に残す評価材料

• デプロイ時間を短縮したプルリクエストの差分
• 監視メトリクスの命名規則
• バックアップ検証パイプライン
• 変更前後の画面と再現手順

これらは成果を説明するためだけの資料ではありません。次の担当者が改善を維持し、必要に応じて修正するための運用資産にもなります。

2年目は個人の改善をチームの標準へ変える

2年目には、自分の担当範囲で成功した方法を、チームが繰り返し使える仕組みへ広げました。

SLOで信頼性の判断基準をそろえる

中村はフロントAPIについて、応答時間のSLOをp95で300ミリ秒、可用性のSLOを99.9%と定めました。p95が300ミリ秒とは、このケースで計測した応答の95%が300ミリ秒以内に収まる状態を目標にするという意味です。

ダッシュボードを公開したことで、開発側とプロダクト側が同じ数値を見ながら、機能開発と信頼性改善の優先順位を話せるようになりました。

リリース失敗から戻る時間を短くする

統合テストを開発工程の早い段階で実行し、Blue/Green方式で切り替えられる運用を整えた結果、このケースの変更失敗率は23%から9%へ下がりました。

Blue/Green方式は、現在の環境とは別に新しい環境を用意し、検証後に接続先を切り替える方法です。問題が起きたときに元の環境へ戻しやすいため、ロールバックの平均時間も48分から14分へ短縮しました。

コストと育成も担当範囲に加える

中村はFinOpsの取り組みとしてクラウド資源のタグ基準をそろえ、未分類コストを月額の12%から2%へ減らしました。予約または利用コミットも見直し、年間見込みコストを11%削減しました。

FinOpsは、技術、財務、事業の担当者がクラウド利用と費用を継続的に確認し、支出の判断を改善する運用です。このケースでは、まず「何に費用がかかっているか」をタグで追える状態にしました。

同時に、インターン2名のメンターを担当しました。週次の1on1では、目的、進捗、障壁、次の一手を順に確認し、技術的な答えを渡すだけでなく、仕事の進め方を共有しました。

2年目に残す評価材料

• SLO定義書、運用方針、四半期のエラーバジェットレポート
• 変更失敗率を下げた実験ログとロールバック手順の動画
• FinOpsのタグ設計とコストダッシュボード
• メンタリングで使った目標とふりかえりの記録

3年目は技術、人、事業の判断をつなぐ

3年目の中村は、自分が作業を完了するだけでなく、複数のチームが安全に作業できる共通基盤と判断方法を整えました。

内製プラットフォームで安全な作業を標準化する

内製開発者プラットフォーム（IDP）は、開発者が共通の手順と制約のもとで、環境作成やデプロイを自分で進めるための社内基盤です。

このケースの最小構成では、リポジトリのテンプレート、CI/CD、権限、監視、SLOのひな形をまとめました。新しいサービスの初回デプロイにかかる時間は3日から半日へ短縮され、オンボーディングは手順書に沿って完了できる状態になりました。

仕組みの流れは次のとおりです。

1. 開発者がリポジトリのテンプレートからサービスを作成します。
2. CIがコードの検査、テスト、スキャンを行い、イメージをレジストリへ保存します。
3. IaCモジュールとポリシーの検査を通して、ステージング環境を用意します。
4. 一部の利用先から段階的に切り替えるカナリア方式で確認し、本番環境へ反映します。
5. メトリクス、ログ、トレースとSLOを同じ監視画面で確認します。

この構成は完成形ではなく、ケース内の最小例です。実際の採用範囲は、組織の権限設計、監査要件、既存の運用に合わせて決めます。

インシデント対応の役割を明確にする

中村は自動トリアージと担当役割を整え、重大インシデントの検知から収束までの平均時間を41分から17分へ短縮しました。

対応後にはポストモーテムの書式を統一しました。ポストモーテムは、障害の経緯、影響、判断、再発防止策を記録し、次の改善へつなげるふりかえりです。

責任分担にはRACI表を使いました。これは、作業の実行者、最終責任者、相談先、報告先を整理する表であり、緊急時に「誰が決めるか」を探す時間を減らします。

採用、評価、事業判断へ広げる

中村は面接の評価基準を技術スキルと行動に分け、面接官による判定のばらつきを抑える仕組みを整えました。ジュニアからシニアまでのキャリアラダーも、職能と組織への影響の二つの軸で更新しました。

四半期レビューでは、プロダクト、カスタマーサクセス、財務の担当者と、SLO、変更失敗率、コストを一枚のダッシュボードで確認しました。技術指標を並べるだけでなく、どの判断に使う数値なのかを合意することが、この段階の役割です。

3年目に残す評価材料

• IDPの構成図、テンプレート、許可と禁止を定めたポリシー
• インシデント対応のRACI表とポストモーテムの例
• 面接の評価基準とキャリアラダー
• 部門横断レビューで使うダッシュボード

3年間に共通する改善の進め方

中村の成長を支えたのは、毎年別の技術を習得したことだけではありません。対象が個人作業、チーム運用、組織横断の仕組みへ広がっても、次の流れを繰り返しています。

1. 観測する：待ち時間、失敗率、復旧時間、未分類コストなど、困りごとを表す指標を決めます。
2. 小さく変える：対象と期間を絞り、戻せる形で改善を試します。
3. 同じ指標で比べる：変更前後を比較し、効果と副作用を確認します。
4. 標準にする：手順、テンプレート、ダッシュボード、評価基準として他の人が使える形にします。

ツールの導入数を成果にすると、利用されなくなった後に価値が残りません。待ち時間や失敗が減り、その方法を別の担当者が再現できる状態まで作ることが、仕組み化です。チーム全体の改善テーマを探す方法は、開発チームのムダを減らす実践フレームワークでも整理しています。

役割が変わるときの30-60-90日プラン

新しい担当へ移るときは、最初から大きな改革を始めず、観測、実装、定着の三段階に分けます。

ふりかえりは事実、意味、次の行動に分ける

• What：何が起きたかを、観測できた事実として記録します。
• So What：利用者や指標へどのような影響があったかを整理します。
• Now What：担当者、期限、確認方法を含む次の行動を決めます。

複数の改善を並行する場合は識別子を付け、どの変更がどの結果につながったかを追えるようにします。

ADRで判断の理由を残す

ADR（アーキテクチャ意思決定記録）は、技術上の決定と理由を短く残す文書です。

背景、選択肢、決定、トレードオフ、ロールバック条件、再評価日を記録します。結論だけでなく、当時の制約と見直し条件を残すことで、後から同じ議論を繰り返すのを防ぎます。

成長しやすい環境を見分ける質問

転職や社内異動では、制度の有無だけでなく、実際に使われた例を確認します。

• SLOとエラーバジェットを、誰がどの頻度で確認していますか。
• 直近の重大インシデントから何を学び、どの手順や仕組みを変えましたか。
• 開発者が変更を本番へ届けるまでに、どの工程があり、どこまで自分で進められますか。
• キャリアラダーと、実際の昇格判断に使った評価例を確認できますか。
• クラウドコストを誰が確認し、どの会議で利用方針を決めていますか。

抽象的な方針だけでなく、直近の記録、ダッシュボード、改善例が示されるかを見ると、制度が日常の運用に組み込まれているかを判断しやすくなります。

成長を止めやすい三つの落とし穴

• ツールを入れることが目的になる：先に解決したい問題と測定指標を決めなければ、導入後の効果を判定できません。
• 特定の担当者だけが解決できる：緊急対応が成功しても、ランブックと自動化へ反映しなければ、同じ担当者への依存が残ります。
• 成果を記録しない：判断の理由と変更前後を残さなければ、評価材料にも、次の改善の出発点にもなりません。

今日から始める三つの行動

1. SLO、変更失敗率、MTTR、コストのうち、担当業務に関係する指標を一枚にまとめます。
2. 小さな自動化または可視化を一つ選び、変更前の値と確認方法を記録してから実施します。
3. 週次デモで結果と副作用を共有し、次に試す変更を決めます。

テックリードの役割は、すべての技術判断を一人で引き受けることではありません。技術上の改善を測定可能にし、他の人が再現できる仕組みに変え、事業側を含む関係者が同じ基準で判断できる状態を作ることです。

実務で使う確認リスト

• 可用性、応答時間、エラーバジェットを含むSLOを定義したか
• 変更失敗率とMTTRを定期的に確認しているか
• ロールバックを短い手順で実行し、定期的に検証できるか
• 新人が判断条件まで理解できる粒度でランブックを整備したか
• クラウド資源のタグ基準を定め、未分類コストを追跡できるか
• ADRの再評価日を確認し、古い決定を見直しているか
• 採用の評価基準とオンボーディングの内容が一致しているか