テックリードへの成長には、技術力だけでなく、改善を測る力、チームに定着させる力、関係者と判断基準をそろえる力が必要です。
この記事では、ジュニアのインフラエンジニア「中村」が3年間でテックリードの役割を担うまでを、行動、成果、評価材料の順にたどります。
中村は実在の個人ではなく、複数の事例を統合した架空のケースです。本文の数値はこのケース内の変化を示すものであり、すべての組織に当てはまる基準ではありません。
このケースで扱う成長の全体像
中村が所属するのは、プロダクトエンジニア40名とSREまたはプラットフォーム担当7名で構成され、複数のスクワッドが開発を進める組織です。
入社時の担当は、クラウド運用とCI/CDの補助を担うジュニアインフラエンジニアでした。CI/CDは、コードの変更を継続的に検証し、本番環境へ届ける一連の仕組みです。具体的な構成を知りたい場合は、CI/CDパイプラインの実装例も参考になります。
| 時期 | 中心課題 | 主な行動 | 評価材料 |
|---|---|---|---|
| 1年目 | 安定運用の土台づくり | 基礎学習、小さな自動化、運用手順の整備 | 変更差分、命名規約、自動化した検証処理 |
| 2年目 | 改善の標準化 | SLOの導入、リリース改善、コスト管理、メンタリング | SLO定義書、実験ログ、運用方針、ダッシュボード |
| 3年目 | 複数チームをまたぐ判断 | 内製プラットフォーム、インシデント運用、採用と評価の整備 | 構成図、方針文書、責任分担表、評価基準 |
成長を支えた組織の前提
このケースの「成長しやすい環境」は、単に新しい技術を使える職場を意味しません。失敗から学び、小さな改善を測定し、その結果を次の役割につなげられる環境を指します。
- ブレームレスなふりかえり：個人を責めるのではなく、判断に使えた情報や仕組みを検証します。
- 小さく試して測る習慣：試行、検証、標準化の順で進め、効果が不明なまま全体へ広げません。
- 役割と成果を結び付ける評価：肩書だけでなく、担当範囲と生み出した変化を評価材料にします。
- レビューを育成に使う文化：週次デモやプルリクエストのレビューを、品質確認と知識共有の両方に使います。
運用では、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日から半日へ短縮され、オンボーディングは手順書に沿って完了できる状態になりました。
仕組みの流れは次のとおりです。
- 開発者がリポジトリのテンプレートからサービスを作成します。
- CIがコードの検査、テスト、スキャンを行い、イメージをレジストリへ保存します。
- IaCモジュールとポリシーの検査を通して、ステージング環境を用意します。
- 一部の利用先から段階的に切り替えるカナリア方式で確認し、本番環境へ反映します。
- メトリクス、ログ、トレースとSLOを同じ監視画面で確認します。
この構成は完成形ではなく、ケース内の最小例です。実際の採用範囲は、組織の権限設計、監査要件、既存の運用に合わせて決めます。
インシデント対応の役割を明確にする
中村は自動トリアージと担当役割を整え、重大インシデントの検知から収束までの平均時間を41分から17分へ短縮しました。
対応後にはポストモーテムの書式を統一しました。ポストモーテムは、障害の経緯、影響、判断、再発防止策を記録し、次の改善へつなげるふりかえりです。
責任分担にはRACI表を使いました。これは、作業の実行者、最終責任者、相談先、報告先を整理する表であり、緊急時に「誰が決めるか」を探す時間を減らします。
採用、評価、事業判断へ広げる
中村は面接の評価基準を技術スキルと行動に分け、面接官による判定のばらつきを抑える仕組みを整えました。ジュニアからシニアまでのキャリアラダーも、職能と組織への影響の二つの軸で更新しました。
四半期レビューでは、プロダクト、カスタマーサクセス、財務の担当者と、SLO、変更失敗率、コストを一枚のダッシュボードで確認しました。技術指標を並べるだけでなく、どの判断に使う数値なのかを合意することが、この段階の役割です。
3年目に残す評価材料
- IDPの構成図、テンプレート、許可と禁止を定めたポリシー
- インシデント対応のRACI表とポストモーテムの例
- 面接の評価基準とキャリアラダー
- 部門横断レビューで使うダッシュボード
3年間に共通する改善の進め方
中村の成長を支えたのは、毎年別の技術を習得したことだけではありません。対象が個人作業、チーム運用、組織横断の仕組みへ広がっても、次の流れを繰り返しています。
- 観測する：待ち時間、失敗率、復旧時間、未分類コストなど、困りごとを表す指標を決めます。
- 小さく変える：対象と期間を絞り、戻せる形で改善を試します。
- 同じ指標で比べる：変更前後を比較し、効果と副作用を確認します。
- 標準にする：手順、テンプレート、ダッシュボード、評価基準として他の人が使える形にします。
ツールの導入数を成果にすると、利用されなくなった後に価値が残りません。待ち時間や失敗が減り、その方法を別の担当者が再現できる状態まで作ることが、仕組み化です。チーム全体の改善テーマを探す方法は、開発チームのムダを減らす実践フレームワークでも整理しています。
役割が変わるときの30-60-90日プラン
新しい担当へ移るときは、最初から大きな改革を始めず、観測、実装、定着の三段階に分けます。
| 期間 | 目的 | 行動例 | 完了の目安 |
|---|---|---|---|
| 0〜30日 | 現状を観測する | 指標、SLO、依存関係、変更時の危険を棚卸しし、小さな改善を三つ試す | 優先する問題と基準値を説明できる |
| 31〜60日 | 改善を実装する | テンプレートや自動化など、作業の流れを改善する仕組みを一つ導入する | 変更前後を同じ指標で比較できる |
| 61〜90日 | 改善を定着させる | ルール、文書、ダッシュボードを整え、担当者が変わっても運用できるようにする | 別の担当者が手順を再現できる |
ふりかえりは事実、意味、次の行動に分ける
- What：何が起きたかを、観測できた事実として記録します。
- So What：利用者や指標へどのような影響があったかを整理します。
- Now What：担当者、期限、確認方法を含む次の行動を決めます。
複数の改善を並行する場合は識別子を付け、どの変更がどの結果につながったかを追えるようにします。
ADRで判断の理由を残す
ADR（アーキテクチャ意思決定記録）は、技術上の決定と理由を短く残す文書です。
背景、選択肢、決定、トレードオフ、ロールバック条件、再評価日を記録します。結論だけでなく、当時の制約と見直し条件を残すことで、後から同じ議論を繰り返すのを防ぎます。
成長しやすい環境を見分ける質問
転職や社内異動では、制度の有無だけでなく、実際に使われた例を確認します。
- SLOとエラーバジェットを、誰がどの頻度で確認していますか。
- 直近の重大インシデントから何を学び、どの手順や仕組みを変えましたか。
- 開発者が変更を本番へ届けるまでに、どの工程があり、どこまで自分で進められますか。
- キャリアラダーと、実際の昇格判断に使った評価例を確認できますか。
- クラウドコストを誰が確認し、どの会議で利用方針を決めていますか。
抽象的な方針だけでなく、直近の記録、ダッシュボード、改善例が示されるかを見ると、制度が日常の運用に組み込まれているかを判断しやすくなります。
成長を止めやすい三つの落とし穴
- ツールを入れることが目的になる：先に解決したい問題と測定指標を決めなければ、導入後の効果を判定できません。
- 特定の担当者だけが解決できる：緊急対応が成功しても、ランブックと自動化へ反映しなければ、同じ担当者への依存が残ります。
- 成果を記録しない：判断の理由と変更前後を残さなければ、評価材料にも、次の改善の出発点にもなりません。
今日から始める三つの行動
- SLO、変更失敗率、MTTR、コストのうち、担当業務に関係する指標を一枚にまとめます。
- 小さな自動化または可視化を一つ選び、変更前の値と確認方法を記録してから実施します。
- 週次デモで結果と副作用を共有し、次に試す変更を決めます。
テックリードの役割は、すべての技術判断を一人で引き受けることではありません。技術上の改善を測定可能にし、他の人が再現できる仕組みに変え、事業側を含む関係者が同じ基準で判断できる状態を作ることです。
実務で使う確認リスト
- 可用性、応答時間、エラーバジェットを含むSLOを定義したか
- 変更失敗率とMTTRを定期的に確認しているか
- ロールバックを短い手順で実行し、定期的に検証できるか
- 新人が判断条件まで理解できる粒度でランブックを整備したか
- クラウド資源のタグ基準を定め、未分類コストを追跡できるか
- ADRの再評価日を確認し、古い決定を見直しているか
- 採用の評価基準とオンボーディングの内容が一致しているか