【企業向け】業務委託エンジニアのオンボーディング設計

立ち上がりの遅さは、本人ではなく受け入れ準備の問題であることが多い

業務委託のエンジニアに参画してもらったのに、最初の1か月がほとんど環境構築と質問待ちで消える。これは珍しいことではありません。そして原因の大半は、受け入れ側の準備にあります。

正社員であれば、立ち上がりに1か月かけても長期で回収できます。しかし業務委託は契約期間が3か月から6か月です。最初の2週間が空転すると、契約期間の1割以上を失います。単価の高い人ほど、この損失は大きくなります。

オンボーディングは、コストではなく回収の速度を上げる投資だと考えると判断しやすくなります。

参画前日までに用意しておくもの

参画初日にこれらが揃っていないと、その日は待ち時間になります。

• 各種アカウント（ソースコード管理、チャット、タスク管理、設計ドキュメント、必要な検証環境）
• 端末の貸与、または持ち込み端末で必要な設定手順
• 開発環境の構築手順書。最終更新日と、最後に成功した人の名前を添える
• 初日の予定表（何時に誰と何を話すか）
• 最初に着手してもらうタスク1件。難易度は低く、マージまで到達できるもの
• 質問先の担当者。一次窓口を1名、その人が不在のときの代理を1名

とくにアカウント発行は、社内の申請手続きに数日かかることがあります。契約締結の時点で申請を始めておきます。

初日から3日目までの進め方

初日は次の順で進めます。

1. 30分の顔合わせ。チームメンバーの役割と、誰に何を聞けばよいかを共有する
2. プロダクトの説明を30分。何のサービスで、誰が使い、今どのフェーズかを話す
3. 稼働時間帯、連絡手段、反応の期待値をお互いに確認する
4. 開発環境の構築を本人に進めてもらい、詰まったら即座に一次窓口が対応する
5. 終業前に15分、その日詰まった点を聞き取る

3点目を初日に決めておくと、後の摩擦がほとんど消えます。「返信は稼働時間内で、急ぎの場合はチャットで名前を入れて呼ぶ」といった水準で構いません。

3日目までに到達したい状態は次の3点です。

• 開発環境がローカルで起動し、テストが通っている
• 小さな変更を1件、レビューを経てマージできている
• チャットの主要チャンネルに参加し、一度は発言している

最初のマージを3日目までに置くのは、技術的な意味よりも、経路が全部つながっていることを確認する意味が大きいです。ここで詰まる箇所は、次に参画する人も必ず詰まります。手順書をその場で直してもらうと、資産として残ります。

1週目に渡す情報と、2週目のすり合わせ

1週目に渡す情報は、技術情報だけでは足りません。次の3種類を渡します。

• 技術: アーキテクチャの概略図、主要なリポジトリの役割、デプロイの流れ、テストとレビューの運用
• 業務: ドメイン用語集、主要な業務フロー、現在の優先課題
• 文脈: なぜ今の設計になっているか、過去に見送った選択肢とその理由

3つ目が抜けている現場が多くあります。文脈を知らない人は、すでに検討済みの提案を繰り返すか、既存の設計を壊す方向に手を入れます。どちらも本人の責任ではありません。

そして参画から2週間の時点で、期待値をすり合わせる30分の場を設けます。話す内容は3つです。

1. こちらが初月に期待していることを、具体的なタスク名で伝える
2. 本人から見て、現状で無理がある点を挙げてもらう
3. 情報が足りていない領域を確認し、渡す担当と期限を決める

この場を設けないと、ずれは3か月目の契約更新の判断時に初めて表面化します。そこまで来ると、修正ではなく終了の話になりがちです。2週間の時点なら、まだ調整で済みます。

受け入れ側がやりがちな4つのこと

タスクの粒度が大きすぎる

「決済まわりをお願いします」では、どこから手をつけるかの判断に時間を取られます。最初の2週間は、1日から3日で終わる粒度に割ります。

レビューが返らない

レビュー待ちは、そのまま稼働の空白になります。稼働日中に一次レスポンスを返す運用を決め、担当を分散させます。返せないときは、いつ返せるかだけ先に伝えます。

情報共有の経路から外す

「業務委託の方には共有していなかった」という状態は、認識のずれを生みます。参画時に、参加してもらうチャンネルと定例の範囲を決め、書面で共有します。

判断まで委ねてしまう

仕様の判断や優先度の決定を外部に委ねると、責任の所在が曖昧になります。実装の進め方は任せ、何を作るかの判断は社内に残す。この線引きを最初に伝えておきます。

立ち上がりを測る指標

感覚ではなく、確認できる形で見ます。

• 初回マージまでの日数（目安は3営業日以内）
• 1週目の質問件数と、そのうち手順書で解決できたはずの件数
• 2週目終了時点で、独力で着手できるタスクの割合
• レビュー依頼から一次返信までの平均時間

2つ目の指標が高い場合、本人の問題ではなく、手順書の更新が滞っているサインです。その場で直せば、次の参画者から効いてきます。

オンボーディングの設計は、一度作れば次の参画者にもそのまま使えます。参画のたびに同じ質問が出るなら、それは仕組みで解決できる領域です。