LabHub

ブログ

FDEオンボーディング90日 — 把握、単独チケット、主導ミッションの3か月

한국어English日本語中文

90日を設計すべき理由

普通のエンジニアのオンボーディングは一重です。新しい会社のコードベースと人に適応すればいい。FDEのオンボーディングは二重です。自社の製品と組織を覚えると同時に、担当する顧客企業のシステムと人にも適応しなければなりません。未知の環境が二つ重なるので、計画なしに入ると、3か月経ってもどちらにも根を張れていない状態になります。

だから最初の四半期は、流れに任せず設計すべきです。以下の90日フレームは特定の会社の制度を写したものではなく、FDEという職種の構造から一般化して構成した枠組みです。骨格は三段階。1か月目は把握、2か月目は単独チケット、3か月目は主導ミッション。各月の目標を一文で決めておけば、毎週のチェックリストは自然に付いてきます。

下に敷かれている原理は信頼口座です。顧客先でのFDEの発言力は肩書きではなく積み上げた信頼から生まれ、信頼は一度の大きな成果ではなく、小さな約束を守る反復から積み上がります。90日を設計する目的は華やかなデビューではなく、この口座をマイナスなしで開設することです。逆に、最初の月に作った悪い第一印象は、残りの任期の間ずっと利子を取り立てます。以下のチェックリストの項目一つ一つが、結局はこの口座への入金行為です。

1か月目 — 環境、製品、人を把握する

最初の月の目標は成果ではなく地図です。ここで描いた地図の精度が、残り2か月の速度を決めます。

最初の月の罠は焦りです。早く何かを見せたくて地図描きを飛ばすと、2か月目に出した速度が3か月目の事故になって返ってきます。

2か月目 — 単独でチケットを処理する

2か月目の目標は、信頼口座への最初の入金です。大きさより完結性が重要です。

この月の罠はスピード欲です。信頼は解決の速さではなく、コミュニケーションの規則性から積み上がります。遅くても予告された遅延は信頼を削りませんが、速くても音沙汰なしの後の完了報告は不安を残します。

3か月目 — ミッションを主導する

3か月目の目標は、小さなものを一つ、最初から最後まで主導してみることです。

90日が終わったときに見えるべきもの

3か月が過ぎた時点で自分に三つ問えば、オンボーディングの成否が現れます。第一に、担当顧客のシステムダイアグラムを何も見ずに描けるか。第二に、その顧客のステークホルダーマップを説明できるか。誰が決め、誰が使うのか。第三に、障害報告が来たら最初の30分に何をするかが決まっているか。

どれか一つでも答えがぼやけているなら、その領域だけ選んで1か月目の地図描きに戻ればいい。オンボーディングは直線ではなく回路で、弱い区間を見つけて巻き戻すこと自体が正常な軌道です。3か月目の目標は完璧になることではなく、どこが空いているかを自分で分かっている状態になることです。

三つとも答えが出ればオンボーディングは完了です。三つ目の答えがぼやけているなら、次の記事がまさにその話です。障害診断プレイブックに進みます。

手を動かして練習する

オンボーディング90日の感覚は、シミュレーションで先に体験できます。

FDE完全ガイドシリーズ

コメント

まだコメントはありません。

ログインするとコメントできます