オンボーディングは資料ではなく体験だ：読んだことより、判断したことが残る

前回は、プロジェクトでオンボーディングが大切な理由をPMの視点でまとめました。結論はこうでした。目標、スコープ、意思決定者、変更の手順は資料でも伝えられるけれど、よくある状況でどう判断するかは、資料ではうまく伝わらない。

今回はその次の問いです。では、よいオンボーディングとはどんな姿なのでしょうか。

オンボーディング資料は多いのに、なぜ迷い続けるのか

多くの組織のオンボーディングは、似たような形をしています。いくつかのWikiのリンク、会社紹介のスライド、プロセスの資料、そして「わからないことがあったら、いつでも聞いてくださいね」。First Runの紹介ページにもまとめてありますが、従来のオンボーディングがうまく機能しない理由は4つあります。

問題	何が起きるか
くり返される説明	新しいメンバーが来るたびに、会社とプロジェクトの流れを説明し直す
読まれない資料	資料はたくさんあるが、最後まで読んで理解するのは難しい
遅れる実務への適応	実際の状況を経験するまで、どんな判断をすべきかわかりにくい
職種ごとの基準の違い	開発、PMO、プランニング、デザイン、マークアップで、学ぶべき基準が違う

このうち、私がいちばん根本的だと思うのは3つ目です。資料をすべて読んだ人でも、つまずくポイントがあります。ルールを知っていることと、ルールが必要な瞬間に気づくことは、別の能力だからです。

たとえば、オンボーディング資料に「スコープの変更は必ず変更要求として受ける」と書いてあるとしましょう。読めば誰でもうなずきます。でも実際のその瞬間は、「変更要求です」という名札をつけてはやってきません。リリース2日前の金曜の午後、親しいクライアントの担当者がメッセンジャーで「この文言だけ、ちょっと変えてもらえますか」と送ってくるときにやってきます。そのメッセージを変更要求だと見抜く感覚は、資料をもう一度読んでも身につきません。

よいオンボーディングの4つの条件

では、その感覚はどうすれば身につくのでしょうか。私は、よいオンボーディングには4つの条件があると考えています。

1. 実際に近い状況で、自分で判断する

いちばん大切な条件です。オンボーディングの基本単位を、読む資料から判断する状況に変えることです。状況には文脈があり、選択肢があり、選んだ結果があります。

私もPMPの勉強で同じことを経験しました。PMPの問題の多くは知識をそのまま問うのではなく、プロジェクトの状況をひとつ示して、PMがいま何を最初にすべきかを選ばせます。PMP合格体験記 第1部にも書きましたが、正解の文を覚えていたら、言葉が少し変わっただけでまた間違えました。そこで間違いノートには問題そのものではなく、「こういう状況なら、まず___する」という判断ルールを積み上げていきました。オンボーディングも同じだと思います。残すべきなのはルールのリストではなく、状況の中での判断です。

2. 役割ごとに違う道がある

開発者とデザイナーが同じプロジェクトに加わっても、最初の1週間に出会う状況は違います。開発者はAPIのエラーやデバッグを前に、プランナーは要件の衝突を前に、デザイナーはデザインシステムのルールやユーザビリティのチェックを前に、判断しなければなりません。全員に同じスライドを見せるオンボーディングは、誰にもぴったりとは合いません。

かといって、自分の役割だけわかればいいわけでもありません。プロジェクトは結局のところ協業なので、隣の職種が何に悩んでいるのかを知っていれば、会話はずっと楽になります。自分の役割から始めて、隣の役割へと広げていく道筋が、よいオンボーディングの2つ目の条件です。

3. 正解かどうかではなく、理由を返す

「正解です」「不正解です」だけでは、学びはあまり残りません。実務での選択は、たいてい正しいか間違いかよりも、よりよいものと危ういものの違いです。ある選択は最善で、ある選択は悪くないけれど惜しく、ある選択はいまは問題なさそうに見えても危うい。だからフィードバックには、評価と理由がセットで必要です。

状況 — リリース2日前の金曜の午後。クライアントの担当者がメッセンジャーで「決済ボタンの文言だけ変えてください。簡単なものなので」と送ってきました。あなたは今週加わったばかりの開発者です。まず何をしますか？

選択	評価	理由
依頼内容をPMに共有し、変更要求として受けるかどうかの判断を任せる	優秀	リリース直前の変更はQA・翻訳・UATに影響しうるため、意思決定者が判断すべき
担当者に影響範囲をまず聞き、その内容をまとめてPMに共有する	良好	方向は正しいが、決定前に一人で調整を続けると、相手に期待を持たせてしまうことがある
簡単なのですぐに直し、リリース後にPMに伝える	リスクあり	善意ではあるが、合意した手順を飛ばし、リリース直前にデグレのリスクを生む
忙しいので月曜に見ましょうと返し、どこにも記録しない	不十分	依頼が消えてしまい、リリース後に同じ要望がより大きな問題になって戻ってくる

「リスクあり」と「不十分」を比べてみてください。どちらもよい選択ではありませんが、理由が違います。「リスクあり」はうまくやろうとして生まれた危うさで、「不十分」は見落としから生まれた問題です。この違いを理由と一緒に聞いてこそ、次に似た状況で違う判断ができます。

4. 間違えてもいい安全な場所がある

実際のプロジェクトで上の「リスクあり」を選べば、その代償はリリース後に払うことになります。オンボーディングは、その代償なしに間違えてみられる数少ない時間です。そのためには、間違えても大丈夫だというサインがはっきりしていて、間違えた問題をもう一度解く機会がなければなりません。一度間違えたら終わりの試験ではなく、間違えた理由を確かめて再挑戦する練習場であるべきです。

資料型オンボーディングと体験型オンボーディング

4つの条件を並べると、違いがはっきりします。

	資料型オンボーディング	体験型オンボーディング
基本単位	読む資料	判断する状況
道筋	全員に同じ資料	役割ごとに違う道、その後ほかの役割へ広がる
フィードバック	ない、または正解・不正解だけ	評価と理由、学びのポイント
ミス	実際の業務で初めてする	練習の中で先にして、もう一度解いてみる
終わったと言える基準	全部読んだ	判断できる

誤解のないように付け加えると、資料が要らないという話ではありません。目標、スコープ、意思決定者のような調べるための情報は、資料がいちばんです。ただ、資料だけで終わるオンボーディングは、新しいメンバーにとっていちばん難しい部分、つまり初めて一人で判断しなければならない瞬間を空白のまま残して終わってしまいます。

だからFirst Runをつくった

この4つの条件を一度に入れられる形式は何だろうと考えたとき、私の答えはRPGでした。だからFirst Runをつくりました。First Runには、4つの条件がこんなふうに入っています。

• 状況の中での判断：実際の業務の状況を描いたクエストで、何から手をつけるかを選びます。正解を覚える問題ではなく、判断の問題です。
• 役割ごとの道筋：開発者、PMO、マークアップエンジニア、プランナー、デザイナーの5つの職種ごとにクエストとメンターNPCがあり、レベル3からはほかの職種のクエストにも挑戦できます。
• 理由のあるフィードバック：回答は優秀・良好・リスクあり・不十分の4段階で評価され、理由と学びのポイントが一緒に示されます。
• 安全な失敗：間違えたクエストは復習ボードでもう一度解くことができ、プレイが終わると、強み、補うべき領域、おすすめの復習クエストをまとめた結果レポートが出ます。

そして、これらすべてを会社やプロジェクトに合わせて変えられます。実際の業務シナリオやプロジェクトのルールでクエストをつくり、実在のメンターをモデルにしたNPC、オフィスマップ、ブランディングを反映できます。上の例のクエストのような場面を、自分たちのチームの実際の状況で埋められるということです。

オンボーディング資料は、これからも必要です。ただ、資料が終わるところで、新しいメンバーが初めて一人で判断しなければならない瞬間が始まります。その瞬間を、実際のプロジェクトより先に、安全に経験できるようにしたかった。だからFirst Runをつくりました。

試してみる — 無料デモはログインなしでブラウザからすぐにプレイでき、韓国語・英語・日本語・スペイン語に対応しています。First Runをプレイする →

次回は、このシリーズ最後の問いです。なぜよりによってゲームなのか、そして仕事の中の遊びはなぜ大切なのか。ヨハン・ホイジンガの『ホモ・ルーデンス』に答えを探してみます。

よくある質問

オンボーディング資料はもう要らないのですか？+

必要です。目標、スコープ、意思決定者、手順のような調べるための情報は、資料がいちばんです。ただ、資料ではいまこの状況で何から手をつけるかを判断する練習がしにくいので、資料に状況の中での判断の体験を加えるのがよいと考えています。

First Runは、一般的なeラーニングのクイズと何が違いますか？+

正解を覚える問題ではなく、実際の業務の状況で何から手をつけるかを選ぶ判断の問題です。回答は優秀・良好・リスクあり・不十分の4段階で評価され、理由と学びのポイントが示されます。間違えたクエストは復習ボードでもう一度解けます。

First Runはどんな職種を扱っていますか？+

開発者、PMO、マークアップエンジニア、プランナー、デザイナーの5つの職種です。レベル3からはほかの職種のクエストにも挑戦して、協業の感覚を広げられます。

参考資料

• First Run：ゲーム型オンボーディング・新人研修RPG
• PMP間違いノートの書き方：間違えた問題を「判断ルール」に変える6ステップ