どの背景でも、半分はすでにある
FDEへの転身を考えるエンジニアの大半は、バックエンド、DevOps・SRE、データエンジニアのどれかから出発します。まず良い知らせから。第2回のスキルマップに描いた8ドメインを物差しに測ると、どの背景でも半分ほどはすでに埋まっています。FDEはゼロから始める職種ではなく、既存のエンジニアリングのキャリアを現場という座標系に移す職種です。
悪い知らせは、空いている半分が背景ごとに違うことです。だから転換の準備は、他人のロードマップをなぞることではなく、自分の背景のギャップ分析から始めるべきです。以下、三つの背景を順に見ていきます。自分の背景を探して読みつつ、他の背景の欄にも目を通しておくと良い。チームに入れば、その背景の同僚とお互いのギャップを埋め合うことになるからです。
バックエンドエンジニアなら
すでにあるもの — API設計と統合、データベース、コード品質、そして製品コードを読んで直す速さです。FDEの成果物が結局は顧客環境で動くコードである以上、コードを速く安全に書ける能力は転身の最も固い元手です。8ドメインで言えば、データベースはおおむね実務ライン、Linuxは最低ラインの近くにあります。
埋めるべきもの — インフラ層です。Kubernetesとネットワークはバックエンドではプラットフォームチームがカバーしてくれていた領域なので、空いていがちです。それから運用経験。自分の作ったサービスの障害を明け方に受けた経験がなければ、オンコールのあるチームに移るか、サイドプロジェクトを実際に運用してでも埋める必要があります。最後に、未知のコードベースへの進入速度 — 他人のシステムをドキュメントなしで読む訓練には、オープンソースへの貢献が良い練習場です。
DevOps・SREなら
すでにあるもの — 技術軸の大部分です。Linux、ネットワーク、Kubernetes、オブザーバビリティ、クラウドと、8ドメイン中5つが業務そのものだった可能性が高い。障害対応の手順感覚、ランブック文化、非難のないポストモーテムといった運用の規律も、すでに体の中にあります。技術ギャップだけ見れば、三つの背景の中で最も有利です。
埋めるべきもの — 向きの違う二つです。第一に、製品コードを書くこと。インフラ自動化のスクリプトと製品機能のコードは筋肉が違います。顧客の要求を受けて機能を作り上げた経験がなければ、小さくてもいいから作るべきです。第二に、コミュニケーションの向きの転換。これまでの会話相手はほとんど社内の開発者でしたが、FDEの相手は社外の非エンジニアです。社内Wikiに書いていた文書を、顧客に送る報告書に変える訓練が必要です。
データエンジニアなら
すでにあるもの — データベースとSQLは実務ラインで、パイプラインを組んで得たデータ地形の感覚が大きな武器です。顧客環境で最初にぶつかる仕事の一つが顧客データの構造と品質の把握ですが、それを生業にしてきた人です。データ境界と個人情報の扱いの感覚もすでにあります。
埋めるべきもの — サービス運用の層です。バッチパイプラインの世界とリアルタイムサービスの世界では、障害の文法が違います。ネットワーク、認証、そしてユーザーがいままさに経験している障害をリアルタイムで診断する経験が、相対的に空いていがちです。オブザーバビリティも、パイプラインの監視からサービスの監視への拡張が必要です。
共通して埋めるべきもの — 顧客の前に立つ技術
三つの背景すべてで最も共通して空いている欄は、技術ではなく顧客対面です。具体的には三つ。第一に、口頭のデモ。作ったものを非エンジニアの前で15分以内に実演して質問を受ける形式は、練習なしには成立しません。社内発表でもいいから機会を作り、回数を積むべきです。第二に、悪い知らせの伝達。第5回で扱った期待値マネジメントは、読むこととやることの距離がとりわけ遠いスキルです。第三に、曖昧な要求をスコープ文書に変えること。「こういうことができたらいいな」を受け取って、成功基準のある1ページに仕立てる練習は、サイドプロジェクトの仮想顧客相手でもできます。
そしてグローバルのポジションを狙うなら、英語は技術スタックの一部です。基準は流暢さではなく、障害の最中に正確に報告できるかどうかです。
6か月の転換ロードマップ
以下は2か月単位で構成した一般ガイドです。在職しながらの並行を前提にしており、個人の出発点によって期間は伸び縮みします。
- 1か月目と2か月目 — ギャップ測定と基礎固め。FDEカリキュラム ロードマップで自分の位置を測り、最も空いているドメインを二つ選んで最低ラインまで引き上げます。ホームラボを作って小さなKubernetesクラスタを一つ自分で運用してみるのが、複数のギャップに同時に触れる近道です。
- 3か月目と4か月目 — 証拠づくり。公開APIのある製品を一つ選び、仮想の顧客シナリオを決めて統合プロジェクトを作ります。成果物はコードだけでなく、アーキテクチャ図、成功基準の文書、障害ランブックまでです。この産出物が証拠ポートフォリオの核になります。並行してFDEエンジニア育成RPGのような診断練習を繰り返し、未知の環境の最初の30分を体に染み込ませます。
- 5か月目と6か月目 — 物語に変えて応募する。既存のキャリアから現場性のあるエピソードを選び、状況-行動-結果の物語に磨き、ポートフォリオと共に応募書類を作ります。面接の形式と準備法は次回で詳しく扱います。
6か月が過ぎると完成したFDEになるのではなく、FDEチームが採って育てる価値のある人になります。それがこのロードマップの正直な目標です。
手を動かして練習する
転換準備の二本柱であるギャップ測定と診断練習は、このブログのツールで始められます。
- FDEカリキュラム ロードマップ — 10ドメイン65スキルでギャップ分析をして進捗を追跡します。
- FDEエンジニア育成RPG — 未知の環境診断の意思決定をミッションで繰り返し練習します。
FDE完全ガイドシリーズ