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