新しく組織に加わったメンバーは大きな不安を抱えています。周囲から「どのくらいのことができるのだろう？」「⁠実力はあるらしいけど、ほんとなのかな？」と思われてしまう不安です。この不安が、本来の力を発揮することを妨げます。

新メンバーは活躍したいと思い、組織も活躍してほしいと思っている。なのに、うまくいかない。ここにはミスマッチ・すれちがいがあります。解消するのがオンボーディングです。2025年12月に刊行された『オンボーディングの教科書』を参考に、どうすればよいのか、少しだけ紹介しましょう。

オンボーディングはコストではなく、投資

オンボーディングは、採用にかけた時間とコストを無駄にしないための投資です。適切なオンボーディングがなければ、高いモチベーションを持つ人材も、期待と現実のミスマッチから早期に離脱したり、空回りしたりします。短期的にはコストかもしれませんが、オンボーディングは結果的に組織全体を強くします。

ドキュメントの準備で、不安を解消する

オンボーディングを成功させるための土台は、計画と情報による安心感の醸成です。たとえば、次のようなドキュメントを準備します。

• オンボーディング計画
  • 「いつまでに・どんな状態になってほしいか」という期待をスケジュール付きで明確にします。大切なのは、組織が作成するのではなく、新メンバーとともに作成することです。
• 実績解除マップ
  • 業務に必要な知識やスキル・タスクを、ゲームのクエストのように可視化します。新メンバーは今、自分がどこに向かって進んでいるのかを確認し、達成感を得ながら道筋を確認できます。
• ワーキングアグリーメント
  • チームの価値観やコミュニケーションルールを明文化し、文化への摩擦なくスムーズになじめるようサポートします。

信頼関係を築く、コミュニケーションの作法

なにより大切なのはコミュニケーションです。ドキュメントをそろえたのだからもう十分、と思うのは大きな間違いです。結局のところ最後の頼りは人です。

• 初期集中型の1on1を実施する
  • 入社直後の1週間は毎日15〜30分の短い1on1を実施しましょう。「⁠何をすればよいかわからない」という新メンバーの不安を取り除く最善の方法です。業務の確認よりも、コンディションの把握と信頼関係の構築に集中します。
• 成長を奪わない「適切なサポートレベル」の運用
  • トレーナーは、質問に対する答えをすぐに与えるのではなく、自律的な試行錯誤を促す「サポートレベル」を意識して対応します。「⁠なんでも聞いてください」という言葉の裏にある、成長を奪う罠を回避します。

エンジニアには、まず最初のPull Request

エンジニアのオンボーディングでは、早期の成功体験が重要です。コードベースに慣れるための基礎知識のインプットに加え、入社後すぐにチームに貢献したという自信を得るため、小さな修正タスクで「最初のPull Request」を完了させることを目指します。そのためには「Good First Issue」を用意します。

開発環境の構築などはペアプログラミングで行いましょう。開発環境にはチーム固有の事情があり、新メンバーはつまずきがちです。コードを書くだけではなく、チームの文化やツールについて質問をするコミュニケーションの機会となります。

小さく始めよう！

ここに紹介したのは、本書のごく一部です。

たとえば、エンジニアだけなく全社員が必要とする各種制度や手続きの仕方、事業や自社を理解するための簡潔なドキュメント、Slackなどのチャットツールをいつ・どのように使うか、どのように意思決定されるかを明示する「組織図一覧⁠」⁠、困ったら誰に相談するのかを示す「ご近所さん一覧⁠」⁠、新メンバーをサポートするサポーターをサポートする研修、1on1での「フィードバックの4A⁠」⁠、フロントエンドやバックエンドのアーキテクチャを理解する手軽な方法（依存ライブラリの定義一覧を上から眺めながらライブラリの用途について説明する）……。まだまだ続きます。

こんなにたくさんのことができるかのか！ と思う方も多いかもしれません。そこで本書はスモールスタートを勧めます。

第4章の「コミュニケーションの作法」を実践するだけでも、オンボーディングは大きく改善します。（⁠本書のP.32）

どれだけ立派なオンボーディングのしくみがあっても、最終的に成否を分けるのは人と人とのコミュニケーションです。逆に言えば、現場でしっかりコミュニケーションが取れていれば、システムの不備はカバーできます。（⁠本書のP.75）

本書をごく一部でも取り入れ、少しでも新メンバーや組織の不安が解消されることを願います。