team-onboarding-playbook

新しいチームメンバーを予測可能な形で早期に立ち上げ、トレーニングを担当する人たちを疲弊させないオンボーディングプレイブックを作成するための、再現可能なフレームワークです。

使用するタイミング

• 新しいメンバーが入社するものの、文書化されたオンボーディング計画がありません。
• 既存のオンボーディングプロセスが非公式で、一貫性がありません。
• チームが急成長していて、オンボーディングがボトルネックになっています。
• 請負業者や代理店のパートナーを、すばやく立ち上げる必要があります。
• チームメンバーが退職するため、その人の知識を記録しておく必要があります。
• 現在のオンボーディングに時間がかかりすぎていて、短縮したいと考えています。

使用しないタイミング

• 継続的なパフォーマンス管理の場合（別の問題です）。
• 特定のテクノロジーのトレーニングの場合（対象を絞ったドキュメントやチュートリアルを使用してください）。
• 一般的なドキュメント戦略の場合（documentation-strategyを使用してください）。
• 役割の定義や採用の場合（上流の別の問題です）。

必要な入力

• 役割：その人が担当する業務と、90日後に期待される成果。
• 既存の資料：ドキュメント、ランブック、コードベース、デザインファイル。
• チーム：誰がメンターを務め、誰がペアを組み、どのような質問に誰が答えるのか。
• ツールとアクセス権：新しいメンバーが必要とするアカウントとシステム。
• 時間の予算：チームメンバーがオンボーディングに費やせる時間。

フレームワーク

優れたオンボーディング計画は4つのレイヤーで構成されます。4つすべてを整えましょう。

レイヤー1：チームへのなじみ（1日目から第1週）

最初の1週間は、生産性よりもチームになじむことが中心です。ここをしっかり整えれば、その後のすべてが加速します。

• 入社前に歓迎のメッセージを送ります。
• 1日目までにワークスペースとアカウントを準備します。「あとで対応します」は避けます。
• バディまたはオンボーディングパートナーを割り当てます（マネージャー以外の人）。
• 1日目のスケジュールは、会議が8時間続くものでも、会議がまったくないものでもないようにします。
• 日常的に一緒に働くメンバーを紹介します。
• 最初の1週間のリズムを作ります。マネージャーまたはバディと毎日チェックインします。

レイヤー2：背景の理解（第1週から第4週）

次の段階は、背景の理解です。新しいメンバーがシステムを変更するには、まずその仕組みを理解する必要があります。

• 製品またはビジネス：何をしているのか、誰にサービスを提供しているのか、なぜ存在するのか。
• チーム：誰が何を担当しているのか、どのように意思決定するのか。
• 技術または運用の全体像：アーキテクチャ図、主要なツール、重要なファイル。
• 最近の経緯：重要な意思決定、最近のローンチ、現在の優先事項。
• 進行中のプロジェクト：何が進行中で、どのように全体に関わっているのか。

読書リストもこの一環です。短くまとめ、注釈を付け、厳選しましょう。

レイヤー3：貢献（第2週から第6週）

第2週または第3週までに、新しいメンバーは実際の貢献を始めているべきです。十分に立ち上がったからではなく、貢献を通じて立ち上がっていくためです。

• 第2週に完了してリリースできる、小規模で範囲の明確な最初のタスク。
• 第3週に実際の作業の一部でペア作業またはシャドーイングを行います。
• 第4週または第5週までに、小規模なプロジェクトを単独で担当します。
• 最初からコードレビュー、デザインへのフィードバック、または同等のピアフィードバックを受けます。

最初のタスクは重要です。主要なシステムに関わりつつ、重要なものを壊す可能性がない作業を選びましょう。リリースまで完了する作業は、自信と存在感につながります。

レイヤー4：習熟（第2か月から第3か月）

90日が経過するまでに、新しいメンバーはチームの一員として十分に活躍できる状態になっているべきです。

• プロジェクトを最初から最後まで担当します。
• チームで当番制がある場合は、オンコールまたは当番に参加します。
• ロードマップを実行するだけでなく、その議論に貢献します。
• 次に入社するメンバーのメンターを務めるか、サポートします。

90日はチェックポイントであり、ゴールではありません。次のメンバーに向けて、うまくいったことと不足していたことを記録しましょう。

30・60・90日計画

すべてのオンボーディング計画には、30日、60日、90日の明確なマイルストーンを設ける必要があります。

30日

• ワークスペース、ツール、アクセス権の設定がすべて完了しています。
• チームメンバー全員と顔合わせを済ませています。
• 製品、チーム、最近の経緯を理解しています。
• 実際の業務を少なくとも1つリリースするか、そこに貢献しています。
• 最初の主要なプロジェクトまたは担当領域を明確に把握しています。

60 日

• プロジェクトまたは担当領域を自立して担当しています。
• 毎回質問しなくても、答えをどこで見つければよいか分かっています。
• 直属のチーム以外のメンバーとも、協力関係を築いています。
• プロセス、ドキュメント、コードベースのいずれかに、意義のある改善を少なくとも1つ加えています。

90 日

• 役割を十分にこなせる状態です。
• ロードマップや計画に関する議論に参加しています。
• システムの一部について、次に入社する人を指導できます。
• 懸念を伝え、異議を唱えることに抵抗がありません。

30／60／90 日のチェックポイントで、こうした基準に大きく届いていない場合は、率直に対処してください。計画が適切でないか、サポートが適切でないか、役割との相性が合っていないかのいずれかです。自然に解決することを期待しても、うまくいきません。

役割ごとの調整

上記のフレームワークは、すべての役割に適用されます。具体的な内容は役割によって異なります。

エンジニアリング

• 1 日目：開発環境を動作させ、初めてのコミットを行います（ドキュメントの修正や簡単な変更など）。
• 1 週目：アーキテクチャドキュメントを読み、主要なサービスのコードパスを確認します。
• 2 週目：小さなバグ修正またはリファクタリングをリリースします。
• 4 週目：機能またはコンポーネントを担当します。
• 2 か月目：オンコール対応にシャドー参加し、その後、実際に担当します。

デザイン

• 1 日目：デザインツールをセットアップし、デザインシステムにアクセスして、ブランドガイドラインを確認します。
• 1 週目：スタジオクリティークとデザインレビューに参加します。
• 2 週目：小さな領域（設定ページや空の状態など）を担当します。
• 4 週目：進行中の機能について、デザインレビューを主導します。
• 2 か月目：機能のデザインを最初から最後まで担当します。

プロダクト

• 1 日目：戦略ドキュメント、ロードマップ、最新の PRD 3 件を読みます。
• 1 週目：顧客との通話に同席し、サポートの定例ミーティングに参加し、関連するすべてのチームのスタンドアップに参加します。
• 2 週目：ディスカバリードキュメントまたは競合分析を作成します。
• 4 週目：機能仕様を担当します。
• 2 か月目：ロードマップの領域を担当します。

マーケティングまたはコンテンツ

• 1 日目：ブランドボイスのドキュメント、最近のキャンペーン、最も成果を上げたコンテンツを確認します。
• 1 週目：顧客調査の成果物とペルソナのドキュメントを確認します。
• 2 週目：小さなコンテンツ（ソーシャル投稿やブログの編集など）を公開します。
• 4 週目：コンテンツを最初から最後まで担当します。
• 2 か月目：キャンペーンまたはチャネルを担当します。

役割や技術スタックに合わせて調整してください。基本的な構成は変わりません。

ワークフロー

1. 新しいメンバーが入社する前に、オンボーディング用の手引きを作成します。1 日目に書き始めてはいけません。
2. アカウント、ハードウェア、アクセス権を事前に準備します。これは 1 日目に最もよく起こる失敗の原因です。
3. バディを割り当て、期待する役割を伝えます。
4. 入社前に、歓迎のメッセージと 1 日目の予定を送ります。
5. 最初の週は成果よりも、チームへの帰属意識と背景知識の共有を重視して進めます。
6. 最初の週は毎日、その後の最初の 1 か月は毎週、状況を確認します。
7. 明確なマイルストーンを設定し、30／60／90 日の正式なチェックインを実施します。
8. 90 日後に振り返りを行い、うまくいったことと不足していたことを確認します。
9. 振り返りをもとに手引きを更新します。オンボーディングのドキュメントは常に見直していくものです。

失敗につながるパターン

• 計画がない。 予定も、ノートパソコンも、アカウントもない 1 日目は、最初の印象を決定づけます。
• 情報を一度に詰め込みすぎる。 1 日目に 8 時間の会議を詰め込んでも、何も覚えてもらえません。
• 実際の仕事を任せるまでが長すぎる。 3 週間も「ドキュメントを読む」だけでは、意欲がそがれます。早い段階で小さな成果を出してもらいましょう。
• バディ任せで、マネージャーが関与しない。 バディは頼りになりますが、評価や支援の働きかけはできません。最終的な責任はマネージャーにあります。
• 暗黙知がボトルネックになる。 「質問があればサラに聞いてください」では、サラが休暇に入った途端に困ります。サラが何度も答えていることをドキュメントに残しましょう。
• 30／60／90 日のマイルストーンがない。 忙しそうに見えた時点でオンボーディングが「終了」してしまいます。それはマイルストーンではありません。
• どの役割にも同じ計画を適用する。 エンジニアリングとマーケティングでは、最初の週に必要なことが異なります。役割に合わせた調整を行いましょう。
• 振り返りがない。 手引きが更新されないため、同じ不足が新しいメンバーのたびに繰り返されます。
• バディに時間がない。 自分も手一杯の人をバディに任命すると、オンボーディングの質が下がり、燃え尽きる原因になります。バディの時間を確保しましょう。
• 顧客やプロダクトの背景を共有しない。 顧客を知らないエンジニアは、誤ったものを作ってしまいます。プロダクトの仕組みを知らないマーケターは、内容の薄いコピーを書いてしまいます。

出力形式

成果物：

1. 初日前のチェックリスト：アカウント、ハードウェア、アクセス権、バディの割り当て、歓迎メッセージ。
2. 初日のスケジュール：ミーティング一覧、自己紹介、最初の成果物。
3. 最初の1週間の読書リスト：厳選した注釈付きドキュメント5～10件。
4. 30日・60日・90日のマイルストーン：この役割における具体的なチェックポイント。
5. バディガイド：オンボーディングパートナーに期待されること。
6. マネージャーとのチェックイン頻度：予定されている1対1のミーティングとマイルストーンレビュー。
7. 振り返りテンプレート：次回の改善に向け、90日後に記入します。

参考ファイル

• references/onboarding-checklist.md：最初の30日間を日ごと・週ごとにまとめたチェックリスト。役割別のバリエーションと、30日・60日・90日のレビュー用テンプレートも含まれています。