外部メンバーのオンボーディングで痛感した、過去の自分に伝えたい教訓

はじめに

こんにちは！新卒2年目でフロントエンドエンジニアをしている人です。
普段は自社アプリのフロントエンド開発を担当しています。

以前業務委託の方やインターン生といった外部メンバーのフロントエンドオンボーディングから、
最初の実装タスクをお任せするまでの一連の流れを担当する機会がありました。

受け入れにあたり、「限られた時間の中で、スムーズに開発に参加してもらえるように」と、自分なりに準備を重ねたつもりでした。しかし、いざ実装が始まると、僕の「つもり」が原因で、相手の方に余計な時間を使わせてしまう場面が多々ありました。

この記事は、そんな僕自身の知識不足と配慮の甘さが招いた失敗を振り返り、未来の自分が同じ轍を踏まないための戒めとして書き残すものです。

【失敗談】私がつまずいた3つの「つもり」

今振り返ると、私の失敗の根源は3つの「つもり」にありました。

① 必要な情報は渡した「つもり」

オンボーディング資料を整備し、開発環境の構築から丁寧に説明しました。これでキャッチアップは万全だろう、と思っていました。しかし、いざ最初の実装タスクをお願いすると、
「このコンポーネントの使い方はどこに書いてありますか？」
「このAPIの仕様は？」
「どこを参考にしたら良いですか？」
といった質問が寄せられました。

実装に必要な「生きた情報」が、オンボーディング資料から抜け落ちていたのです。
資料はあくまであらすじでしかなく、後で見返すための目次とその情報を提供できていませんでした。

② プロパーと同じ感覚で伝わる「つもり」

自社で開発していると、いつの間にか「当たり前」の感覚が染み付いていました。
例えば、
「このパターンの時は、〇〇の機能を実装する」
「ここの処理は〇〇を横展開したら実装できる」
といった、日々の業務で培われた暗黙の了解です。

僕はその感覚のままタスクを作成し、「〇〇機能の実装をお願いします」と依頼してしまいました。
背景や仕様、実装方針といった「必要な事前情報」を言語化していなかったため、
相手の方はどこから手をつければいいか分からず、大幅に時間をロスしてしまいました。

③ コードを見ればわかる「つもり」

「相手は経験豊富なエンジニアだから、コードを読めば理解してくれるだろう」。
そんな甘えがあったのも事実です。しかし、どれだけ優れたエンジニアであっても、初めて見る巨大なコードベースの全体像を瞬時に把握するのは不可能です。

どこに何が書かれているのか、なぜこの設計になっているのか。
そうしたコンテキストを伝えずに実装依頼を出したことで、相手に大きな不安と負担を与えてしまいました。

未来の自分が同じ轍を踏まないための3つの鉄則

この経験から学んだ、外部メンバーを迎え入れる際に心に刻むべき3つの鉄則をまとめました。

鉄則1：「暗黙知」を徹底的に「形式知」へ。ドキュメントは未来の自分を救う

「こういうもんだ」で済まされてきた社内の常識は、外部のメンバーにとっては最大の障壁になります。まずは、以下の情報をドキュメントとして残すことを徹底します。

• コーディング規約・リンタールール: なぜそのルールがあるのか、背景も添える。
• ブランチ戦略とPRの作法: レビュー依頼時のテンプレートや、期待する粒度を明記する。
• 主要なディレクトリ・ファイル構成の説明: 「〇〇に関するコードは、src/〇〇/〇〇配下にあります」のように具体的に。
• ドメイン知識・用語集: 社内でしか通じない単語は、必ず解説を入れる。

ドキュメント化は、相手のためだけでなく、未来の自分や新しい仲間を助ける最も確実な投資だと痛感しました。

鉄則2：最初のタスクは「完璧な地図」を渡すイメージで

初めてのタスクは、相手のスキルを試す場ではありません。チームの開発フローにスムーズに乗り、成功体験を積んでもらうためのものです。

そのため、タスクを依頼する際は、以下の点を意識して「完璧な地図」を用意することを心がけます。

• 実装の意図：この機能がなぜあって、どういう意図で修正が必要になったのかを明確にする。
• 背景とゴール: なぜこのタスクが必要で、何がどうなれば完了なのかをより明確にする。
• 具体的な実装方針: 「〇〇ファイルを修正し、△△コンポーネントを使ってください」のように、具体的な道筋を示す。
• 関連ファイルのパス: 修正が必要になるであろうファイルのパスを全て列挙しておく。
• 疑問点の仮説: 「おそらく、〇〇の部分で迷うかもしれません。その際は△△を参考にしてください」と先回りしてフォローする。

まずは手厚すぎるくらいの情報を提供し、徐々に自走してもらう。その方が、結果的に双方にとってスムーズに進むはずです。

鉄則3：「何かありますか？」ではなく「〇〇で困っていませんか？」と聞く

新しくチームに入ったばかりの時は、「こんなことも聞いていいのだろうか」と遠慮してしまうはずです。漠然と「何か質問はありますか？」と聞くだけでは、相手の不安を解消することはできません。

「APIの連携あたりで詰まっていませんか？」「ここのコンポーネントの粒度、迷いますよね」といったように、こちらから具体的なポイントを挙げて問いかけることで、相手は安心して質問ができます。

稼働時間が限られているからこそ、密なコミュニケーションで疑問点を早期に解消し、実装に集中できる環境を作ることが、受け入れ側の責務だと考えています。

おわりに

今回の経験を通じて、オンボーディングとは単なる「作業説明」ではなく、新しい仲間をチームに温かく迎え入れ、最高のスタートを切ってもらうための「最初の共同作業」なのだと学びました。

良かれと思った自分の「つもり」が、相手の負担になってしまう。
この失敗を忘れずに、常に相手の立場に立つ想像力を持ち続けたいと思います。
この記事が、過去の自分、そして同じように悩んでいる誰かの助けになれば幸いです。