オンボーディングはなぜ毎回難しいのか:資料よりシナリオが必要な理由

新入社員や中途入社者、プロジェクトへの新規参画者がなかなか立ち上がれない理由を整理し、資料中心のオンボーディングを、実務シナリオにもとづくクエスト形式の研修に変える方法を紹介します。

First Run チーム
•約5分
この記事の目次

新しいメンバーがチームに加わると、多くの組織は似たような流れを繰り返します。会社紹介の資料を共有し、プロジェクトの経緯を説明し、役割と責任を案内します。必要な資料はすでにどこかにまとまっているのに、新しいメンバーが実際の業務に入ると、同じ質問がまた出てきます。

「この状況では、まず誰に聞けばいいですか?」「クライアントからこう依頼されたら、すぐに反映していいですか?」「QAで課題が見つかったら、リリースを延期すべきですか?」「これは開発者が判断することですか、それともPMOが整理することですか?」

Gallupによると、自社が新入社員のオンボーディングをうまく行っていると強く同意した従業員は12%にとどまります。SHRMは、新しい役割で成果を出すための準備と支援を受けられたと感じた新入社員は29%にすぎないとまとめています。オンボーディングが難しいのは、情報が足りないからだけではありません。新しいメンバーが、業務の文脈の中で判断する経験をまだしていないことに原因があります。

資料の伝達ではなく文脈の学習

よいオンボーディングは、会社のルールを伝えるだけでは終わりません。新しいメンバーが、会社の仕事の進め方、意思決定の流れ、プロジェクトの基準、職種ごとの責任を理解できるよう支えるプロセスです。

しかし、多くのオンボーディングはいまだに資料中心で組まれています。会社紹介のPDF、プロジェクトの概要資料、業務プロセスのガイド、コラボレーションツールの使い方、職種別のチェックリスト。これらの資料は必要です。問題は、資料を読むことと、実際の業務で判断することは違う、という点です。

たとえば「リスクは事前に管理すべきだ」という一文を読むことと、実際にスケジュール遅延が起きたときに、どの情報を先に整理し、誰に報告すべきかを判断することは、まったく別の経験です。

事例:参画1週目によくある問題

新任のPMOが、グローバルWebサイトの構築プロジェクトにアサインされたとします。プロジェクトの資料には、全体スケジュール、担当者、成果物、報告体制がまとまっています。ところが1週目から、クライアントが急に追加の依頼をしてきます。

「今回のリリースに、この機能も一緒に入れられますか?」

資料には、変更要求のプロセスが書かれています。しかし新しいメンバーは、実際の場面で迷います。クライアントにすぐ「できます」と答えてよいのか。まず開発チームに聞くべきか。スケジュールへの影響を整理すべきか。これはスコープの変更として扱うべきか。先に社内に報告すべきか。

こうした場面で必要なのは、単なる知識ではなく、判断の順番です。よいオンボーディングは、このような実際の状況を事前に経験させるべきであり、その経験は資料よりもシナリオのほうにうまく収まります。

シナリオ型が必要な理由

シナリオ型のオンボーディングは、新しいメンバーに実際の業務に近い状況を示し、選択肢を通じて判断させる方法です。

たとえば、次のような問題が考えられます。

クライアントが、リリースの1週間前に追加機能を依頼してきました。PMOとして、最初にやるべきことは何でしょうか。

  1. クライアントの依頼なので、すぐに反映すると答える。
  2. まず開発者に、残業できるかを聞く。
  3. 依頼内容を整理し、スケジュール・スコープ・リスクへの影響を確認する。
  4. リリース後に対応しようと、すぐに断る。

正解は、単に「3番」ではありません。大切なのは、なぜ3番のほうが適切なのか、残りの選択肢にはどんなリスクがあるのかをフィードバックすることです。そうすれば新しいメンバーは、プロセスを暗記するのではなく、状況の中で判断する練習ができます。

クエストにすると何が変わるか

First Runは、こうしたシナリオをゲームの中のクエストに置き換える形で設計されています。新しいメンバーはMake Feelbetterという架空のIT企業に入社し、開発者、PMO、マークアップエンジニア、プランナー、デザイナーのいずれかの役割を選びます。その後、会社のマップを歩き回ってNPCに会い、職種ごとの実務シナリオのクエストを解決していきます。

PMOのNPCは、スケジュール遅延やリスク判断の問題を出します。開発者のNPCは、APIのエラーやデバッグの問題を示します。プランナーのNPCは、あいまいな要件についてどう質問すべきかを問います。デザイナーのNPCは、CTAの優先順位やUIの一貫性を判断させます。

この構成の利点は、はっきりしています。新しいメンバーは受け身で資料を読むのではなく、実際の業務に近い選択を行い、その結果へのフィードバックをすぐに受け取れます。職種ごとに異なるオンボーディング体験を提供でき、繰り返し行う研修を再利用できるコンテンツにできます。

クイズより選択とフィードバック

ゲーム型のオンボーディングが、常によいとは限りません。点数、バッジ、ランキングをつけるだけでは、かえって学習よりもゲーム要素に意識が向いてしまうことがあります。研究でも、ゲーム型の学習は実際の状況をシナリオにして利用者に判断させるときに効果が高い一方、過度なゲーム要素は学習を妨げうると指摘されています。

そのため大切なのは、「どれだけ楽しく飾ったか」よりも「実際の業務判断をどれだけうまく盛り込んだか」です。よいオンボーディングのクエストは、次の条件を備えている必要があります。

  • 実際の業務でよく起きる状況であること。
  • 正解だけでなく、不正解ももっともらしいこと。
  • 選択後のフィードバックが具体的であること。
  • 職種ごとの役割と責任を反映していること。
  • 難易度が段階的に上がること。
  • 最後に、どんな能力を学んだかのレポートが残ること。

First Runが目指している方向も、ここにあります。単に「問題を当てるゲーム」ではなく、新しいメンバーが会社やプロジェクトの仕事の進め方を事前に体験するためのオンボーディングツールです。

まとめ

オンボーディングが難しいのは、資料が足りないからだけではありません。新しいメンバーが、実際の業務の場面でどんな判断をすべきかを経験する機会が足りないからです。資料は引き続き必要ですが、資料だけでは業務の文脈を十分に伝えることは難しいのです。

これからのオンボーディングは、「読む研修」から「体験する研修」へと変わる必要があります。First Runは、その転換をゲーム型のシナリオクエストで実現しようとする試みです。


実務シナリオをクエストで体験してみませんか

新しいメンバーのオンボーディングをもっとスムーズにしたい方は、First Runのデモで職種別のクエストを体験してみてください。 ゲームを始める

オンボーディングRPGを今すぐプレイ

First Runの仮想オフィスを歩きながら、開発・企画・デザイン・PMO・マークアップの実務シナリオをJRPG風のクエストで体験してみましょう。

関連記事