概要
オンボーディングとは、新しく加わったメンバーが組織の中で自律して動けるようになるまで、チームが支える取り組みです。対象となる期間は、初日より前から、メンバーが手取り足取りの指示なしに自分の仕事を進められるようになるまでです。 このページでは、学ぶ側ではなく教える側、つまりチームの視点からオンボーディングを扱います。まずオンボーディングが目指すものと管理の仕方を定め、初日までの準備、初日・1週間・1か月の支え方、AIエージェントによる変化を順に説明します。オンボーディングが目指すもの
オンボーディングの目標は、メンバーが組織の中で自律して動けるようになることです。そうしたメンバーは、チームの開発の進め方や意思決定の仕方、情報のありか、誰に何を聞けばよいかを知っており、それを使って自分の仕事を前に進めます。オンボーディングはこの状態に至るまでを支える取り組みであり、資料を読み終えたら完了するものではありません。 自律して動くことは、1人で抱え込むことではありません。自律したメンバーは、適切なタイミングで助けを求め、問題を早めに共有し、見つけた古いドキュメントを自分で直します。オンボーディングで取り除くのは手取り足取りの指示への依存であり、協力し合うことではありません。 最初の変更がマージされることは、その途中にある最初の節目です。小さな変更を1つリリースすると、開発環境の構築、リポジトリの構成、レビューの流れ、リリースの流れを一度ずつ通ることになります。手順を読むだけでは、この経験の代わりになりません。その道のりにある障害をメンバーが加わる前に取り除いておくと、オンボーディングの期間をプロダクトと組織の理解に使えます。完了条件つきでゴールを決める
メンバーにとって「自律して動ける」とはどういう状態かを、メンターとメンバーが一緒に確認できるゴールとして定めます。各ゴールにおおまかな完了条件を添えておくと、進み具合が見えるようになります。
完了条件は合格基準ではなく目安として扱います。メンバーの経験や担当領域（フロントエンド、バックエンド、インフラ）に合わせて調整し、最終的な判断はメンターとメンバーの対話で行います。想定期間も同じように決め、経験のあるメンバーは短く、実務経験の浅いメンバーは長く見積もります。
チェックリストで管理する
オンボーディングのタスクは、テンプレートから作成したIssueのような1つのチェックリストにまとめ、各タスクにマネージャー・メンター・メンバーのいずれかを担当者として付けます。チェックリストを共有すると、何が終わり何が止まっているかが見え、準備が特定の人の記憶に頼らなくなります。 必要な準備が異なるメンバーの種類ごとに、テンプレートを用意します。正社員、業務委託、インターンが典型です。業務委託では本番環境の権限が不要なことがあり、短期のインターンでは最初の数週間ではなく初日中のマージを目標にすることがあります。 開始時に、メンターとメンバーでチェックリストをメンバーのゴールに合わせて調整します。終了時には一緒にオンボーディングをふりかえり、得られた気づきをテンプレートに反映して、次のオンボーディングが改善された状態から始まるようにします。テンプレートの例はこのページの後半に示します。ファインディでは、正社員・業務委託・インターンごとにオンボーディング用のIssueテンプレートを用意し、各タスクに担当者を付けて管理しているチームもあります。
初日までの準備
準備は、アカウントや組織面の手続きを担うマネージャーと、仕事そのものを準備するメンターで分担します。1
アカウントと権限を事前に申請する
アカウントの発行は数日かかり、他部署に依存することも多くあります。入社日が決まったら、コードホスティング、チャット、クラウド環境、パスワード管理ツール、デザインツール、AIツールの利用申請を済ませます。権限は役割に応じて決めます。たとえば業務委託のメンバーにはステージング環境の権限だけで足りることがあります。
2
開発環境を再現できるようにする
環境構築の手順は文章ではなくコマンドやスクリプトで書き、最新の状態に保ちます。秘密情報の入手やAIツールのセットアップまでを含む、順序立てたクイックスタートを1つ用意し、各リポジトリのREADMEへの入口にします。特定の人の手助けがないと構築できない環境では、最初の数日が待ち時間になります。
3
ドキュメントを最新の状態にする
タスク分解、プルリクエストの粒度、コミットの規約、レビューの進め方を文書にし、メンバーが加わる前に既存のドキュメントに古い記述がないかを見直します。更新案はAIエージェントに下書きさせ、チームでレビューする方法があります。人の頭の中にしかない価値観や手法は、コードを読んでも学べません。
4
最初のタスクを用意する
簡単すぎず大きすぎないタスクを2〜3件選び、変更するファイルを明示します。同じ種類の修正を複数箇所に適用するタスクが向いています。最初の1か所をサポートを受けながら覚え、残りは反復で身につけられるためです。「good first issue」のようなラベルでこうしたタスクを日頃からストックしておくと、毎回ゼロから探さずに済みます。
5
メンターを決め、連絡の場を整える
質問に答え、メンバーの変更をレビューする人を決めます。この期間はメンターの成果が落ちることを事前に合意し、メンターが普段と同じ期待値で評価されないようにします。あわせて、定例の会議と必要なチャットチャンネルにメンバーを追加し、メンバーが作業を書き残す個人用のチャンネルを作成します。
初日・1週間・1か月の支え方
初日
初日のうちに、ドキュメントの修正でもよいので最初のプルリクエストを出すことを目指します。初日に行うことは次のとおりです。- 開発プロセスを、必要な承認などマージを止めるルールに絞って説明する。
- クイックスタートに沿って、メンバーに環境を構築してもらう。
- プルリクエスト・レビュー・メンションの通知がメンバーに届くことを確認する。
- メンターとの1on1を高い頻度で設定し、メンバーが慣れたら頻度を下げる。
- 最初のタスクに着手する。
最初の1週間
- メンターと一緒に、オンボーディングのチェックリストを調整する。
- ドキュメントは全部を読むのではなく、何があるかをざっと把握する。
- 見分けやすいチャットの表示名とアイコンを設定し、レビューのリマインダーを設定する。
- 営業・サポート・企画など職種をまたいだメンバーと短い1on1を組み、誰に何を聞けばよいかを知る。
最初の1か月
- 監視、エラー追跡、クラウドの各ツールにアクセスできることを確認する。
- 開発プロセス、バックログ、チームの指標を把握する。
- ステージング環境で主要なユーザーの操作の流れを一通り試す。
- メンターが準備できたと判断したらレビューに加わり、リリースを1回実施する。
- 本番データを変更するときのルールを、メンターとのペア作業で学ぶ。
- 担当領域に含まれる場合は、問い合わせとアラートにそれぞれ1件対応する。
日々の支え方
情報は段階的に渡します。初日にシステム全体を説明しても、知識を結びつける先がまだないため負荷になるだけです。個々の背景知識は、タスクで必要になったときのほうが理解しやすくなります。 助けを求めることを当然の行動にします。取り組んでいる作業、出たエラー、試したことをメンバーが書き残す個人用のチャンネルをチームの誰もが読めるようにしておけば、個別に頼まれなくても複数の人が手を差し伸べられます。30分ほど詰まったら1人で考え続けずに質問する、という目安が役に立ちます。 レビューは速く返します。最初のタスクがレビューを何日も待つと、その間メンバーは何も学べません。小さなプルリクエスト、自動化されたチェック、自動化されたリリースは、どれも変更からフィードバックまでの間隔を縮めます。ファインディでは、オンボーディング期間中に定期的なふりかえりを行い、出たアクションをすぐに実行して、次のふりかえりで効果を確認しているチームもあります。
オンボーディング用Issueテンプレートの例
このページのゴールとタスクを、GitHubで正社員のエンジニアを受け入れる場合のチェックリストにまとめたテンプレートの例です。.github/ISSUE_TEMPLATE/に置き、タスク・ツール・完了条件はチームに合わせて書き換えてください。
.github/ISSUE_TEMPLATE/onboarding.md
AIを使ったオンボーディング
AIによって変わること
AIエージェントを使えば、新しいメンバーは見慣れないコードベースを探索し、構造について質問し、タスク分解の下書きまでをほぼ自力で進められます。入社から実装を始めるまでの時間が大きく縮み、メンターがコードを1行ずつ説明する時間も減ります。 一方、アーキテクチャの経緯やドメイン知識のように書かれていないことは、AIにも補えません。こうした知識をメンターの説明に任せたままにすると、新しいメンバーが来るたびに同じ説明を繰り返すことになり、メンバーのAIエージェントはそれを一切使えません。文書にしておけば、人とAIの両方に役立ちます。AIが読むコンテキストを整える
これまで口頭で伝えてきたことを文書にします。アーキテクチャの決定はその理由とともに記録し、ドメインの用語や業務のルールは用語集にまとめます。これらの文書は、リポジトリのように人とAIエージェントの両方が読む場所に置きます。そのうえで、説明した内容を文書に起こし、次のメンバーに同じ説明が要らないようにすることもメンターの役割になります。 チームのルールを文書にし、繰り返し使うワークフローをSkillにまとめておくと、新しいメンバーのエージェントも初日からチームのやり方に沿って動きます。AIツールのセットアップはクイックスタートに含め、環境構築の一部にします。古いコードの整理も続けます。エージェントはコードベースにある古い書き方を読み、そのまま再現することがあるためです。関連ページ
タスク分解
メンターが新しいメンバーと最初に一緒に取り組む、1つずつマージできる単位へのタスクの分け方です。
プルリクエスト
粒度が適切だからこそ、新しいメンバーが毎日フィードバックを受けられます。
コードレビュー
最初のタスクがフィードバックを待たないよう、レビューを速く明確に返すために読みます。