エンジニアのオンボーディングでは、資料を渡すだけでなく、参加した人が開発環境を動かし、コードの流れを理解し、相談しながら小さな変更を届けられる状態を目指します。受入担当者は、本人が進める作業と、組織側で先に整える権限・情報・相談先を分けて準備すると進行を把握しやすくなります。
この記事では、開発チームへ新しい技術者を迎えるための手順例を示します。当社の導入実績や効果測定の報告ではなく、公開されている開発組織の手順を参考にした設計案です。必要な期間や担当範囲は、参加者の経験とプロジェクトに合わせて調整してください。
到達点を「最初の変更を説明できる」に置く
初日や初週のチェック欄が埋まっても、どこを読めばよいか、誰に聞けばよいか分からない状態は残ります。開発の受入では、例えば次の四つを到達点として使えます。
- 許可された環境でアプリケーションを起動し、既存テストを実行できる。
- 一つの機能について、入力から出力までの主な処理を説明できる。
- 小さな変更の理由と確認結果を、レビューに必要な形で提出できる。
- 詰まった点を、試したことと合わせて適切な相手へ相談できる。
これは全員に同じ日数を課す基準ではありません。権限の発行待ちと知識の不足を区別し、受入側の準備不足を本人の進捗遅れとして扱わないためにも使います。
参加前に、作業と担当者を結び付ける
用意するものを「資料一式」とせず、使う場面ごとに分けます。
| 準備するもの | 内容の例 | 確認する担当 |
|---|---|---|
| 開発環境の手順 | 対応OS、必要な版、起動・テスト手順 | 開発担当 |
| アクセスの申請経路 | リポジトリ、検証環境、必要な権限 | 管理担当・承認者 |
| システムの入口 | 構成図、主要ディレクトリ、用語集 | 技術リード |
| 仕事の進め方 | チケット、レビュー、リリースの流れ | チームの受入担当 |
| 相談先 | 業務仕様、実装、環境、契約上の窓口 | 各担当者 |
秘密情報を手順書へ直接書いたり、全員で一つの認証情報を使い回したりする設計にはしません。組織で定めた申請・保管・付与の手順を案内し、作業に必要な範囲のアクセスを用意します。
GitLabの公開オンボーディング手順では、共通タスクと職務別タスクをIssueで扱い、相談できる担当を案内しています。GitLab固有の日数や仕組みをそのまま採用する必要はありませんが、作業を見える形にして支援先を結び付ける例として参考になります。
開発環境は、新しい参加者の手順で確かめる
既存メンバーのPCで動くことと、新しい環境で再現できることは別です。初回は手順書を使って起動し、途中で口頭説明が必要になった箇所を記録します。
例えば「依存関係を入れる」とだけ書かれているなら、利用するツール、版、実行場所、成功時に確認する結果まで補います。認証が必要な手順は、秘密情報の値ではなく、取得の窓口と設定方法を示します。
確認は、起動できたかに加えて、検証用データで代表機能を操作できるか、既存テストを実行できるかまで進めます。初回から本番データや本番変更を必要にするのではなく、チームが許可する検証環境を使います。起動に失敗した場合は、環境の差、手順の不足、既知の不具合を分けて受入担当者が支援します。
コードは、一つの利用場面からたどる
リポジトリ全体を最初から読もうとすると、何を理解したいかが曖昧になります。例えば架空のタスク管理アプリなら、「タスクを追加すると一覧に表示される」という一つの操作を選びます。
入力画面
→ 送信処理
→ APIの入口
→ 入力の検証
→ 保存処理
→ 応答と画面への反映参加者には、この流れのファイルや関数、テストの場所を探してもらいます。受入担当者は、歴史的な事情や例外がある部分を補足します。理解した内容を短いメモとして返してもらえば、用語の食い違いも確認できます。
「設計資料を全部読んでおいて」より、「この入力がどこで検証されるかを一緒に確認する」のように問いを具体化すると、説明する範囲を決めやすくなります。既存実装を見て気付いた疑問は、すぐ変更する項目と、背景を聞く項目に分けます。
最初の変更は、確認方法まで説明できる大きさにする
初回の課題には、変更理由と影響範囲が把握でき、担当者がレビューできるものを選びます。例えば「入力欄の補足文を、仕様に合う表現へ修正する」「既知の条件に対するテストを追加する」などが候補です。小さい修正でも、利用者や既存動作への影響は確認します。
GitLabのFrontend開発手順では、Issueの理解、実装の計画、コードとテスト、レビューという流れを示しています。これを参考に、初回のPRには次を記載する案があります。GitLabでは同様の変更提案をMerge Requestと呼びます。
- 何が問題で、変更後はどうなるか。
- どのファイルを、なぜ変更したか。
- どの条件で確認し、何が分かったか。
- 未確認の範囲や、判断を相談したい点は何か。
初回の目的は、変更の量よりもチームの開発手順を一周することです。レビューを受け、修正し、反映結果を確認するところまで支援します。公開や本番反映は、既存の権限と承認手順に従って担当者が行います。
詰まりを共有するための短い記録
受入担当者が毎回状況を聞き直さなくて済むよう、例えば次の形で記録を残します。これは評価表ではなく、支援をつなぐための例です。
| 状態 | 記録例 | 次の行動 |
|---|---|---|
| 完了 | 起動と代表テストが成功 | 代表機能のコードを追う |
| 依頼待ち | 検証環境の権限を申請済み | 管理担当が発行状況を確認 |
| 調査中 | テスト失敗、版とエラーを記録 | 開発担当と環境差を確認 |
| 判断待ち | 表示文言の意図が不明 | 仕様担当へ確認 |
相談時は「動きません」だけでなく、実行した場所、対象の版、期待した結果、実際の結果、すでに試したことを添えます。ログや画面に秘密情報が含まれる場合は、共有範囲に合わせて取り扱います。
受入の振り返りを、次の手順へ戻す
最初の変更を終えたら、本人と受入担当者で、分かりにくかった言葉、足りなかった権限、古かった手順、相談先に迷った箇所を振り返ります。「慣れれば分かる」で終わらせず、手順書や相談先一覧のどこを直すかを決めます。
進捗を見る場合も、最初のPRまでの日数だけで人を比較せず、権限待ち、課題の難しさ、支援に使えた時間を併せて確認します。少ない数字から能力や定着への効果を断定するための指標にはしません。
受入担当者は、まず一つの機能と一つの小さな変更を選び、環境・資料・相談先をそろえてみてください。その一周で見つかった不足を直すことが、次の参加者も使えるオンボーディング手順につながります。