オンボーディング用のクエストを作ろうとすると、たいてい次のように始まります。Wikiからオンボーディング関連のページを集め、各ページの要点となる一文を問題に置き換えるのです。できあがるのは、たいていクイズです。変更要求は誰が承認するのかを問う設問が20個ほど作られ、新入社員は資料を検索して解きます。全問正解した後でも、実際に変更要求が来ると、やはり手が止まります。
文書をクエストに変える作業は、文章を問題に置き換えることではありません。文書に書かれていない判断ポイントを見つけ出す作業です。以下の5ステップは、この順番で進めることで結果が変わる手順です。
Wikiをそのまま移せない理由
社内Wikiは、参照するために作られています。必要なときに調べて読む文書なので、判断の順番や例外の扱いは、たいてい抜け落ちています。書かれているのはルールの最終形です。「緊急リリースはチームリーダーの承認後に行う」という一文は正しいものの、チームリーダーが休暇中ならどうするのか、どこまでを緊急とみなすのかは書かれていません。
新入社員がつまずくのは、まさにその空白です。そのため変換作業の出発点はWikiではなく、Wikiを読んでも残る質問であるべきです。
5ステップの変換ワークフロー
ステップ1：よく出る質問を集める
直近2〜3か月に実際に出た質問を集めます。情報源はすでに手元にあります。チームのチャットで新入社員が質問したこと、社内チャットボットのログ、1on1のメモ、オンボーディング担当者が同じ回答を繰り返した項目、コードレビューで繰り返される指摘などです。
このとき数える単位は、質問の文面ではなく、質問の類型です。「誰に聞けばいいか」と「誰が決めるのか」は同じ類型です。30〜50件ほど集まると、上位10類型が全体の半分以上を占めます。クエストは、その10類型からだけ作ります。
収集結果は、次のような形になります。変更要求が来たときの処理順序が9回、障害発生時の報告先と順序が7回、リリース前の課題に対するGo/No-Go判定の基準が6回、要件があいまいなときの聞き返し方が6回、成果物のレビュー依頼のタイミングが4回。
ステップ2：判断ポイントを抽出する
各質問類型から、実際に判断が分かれるポイントを1つだけ抜き出します。基準は、ここで選択を誤ると損失が出るかどうかです。損失がないなら、クエストではなく文書の項目で十分です。
たとえば変更要求の類型での判断ポイントは、承認者が誰かではありません。それは調べれば分かります。本当の判断ポイントは、依頼を受けた直後に何を先にやるかです。影響分析が先か、関係する職種への連絡が先か、クライアントに回答時期を伝えるのが先か。
1つのクエストに入れる判断ポイントは、1つだけにします。2つ入れると、プレイヤーはなぜ間違えたのかが分からず、不正解のデータも解釈できなくなります。
ステップ3：状況カードに書く
判断ポイントを、実際の状況に置き換えます。状況カードは短くなければなりません。5文を超えると、読まずに選択肢へ目が移ります。入れるべき要素は4つです。時点、主体、出来事、そして制約を1つ。
状況：リリース4日前、クライアントからトップページに新しいバナー枠を追加してほしいとメールが届きました。デザインはすでに確定してマークアップ作業が進んでおり、QAは2日後に始まる予定です。 問い：プロジェクトのPMOとして、最初にやるべきことは何でしょうか。
時点、主体、出来事、制約が、1つの段落にすべて入っています。実際のプロジェクトから持ってきた制約ほど効果的です。日付や成果物の名前が実際に近いと、プレイヤーの没入感ははっきり変わります。
ステップ4：選択肢とフィードバック
ここが品質の分かれ目です。多くのオンボーディング用クイズは、不正解の選択肢の出来が悪いせいで失敗します。「クライアントを無視する」のような選択肢は、誰も選びません。
よい不正解は、半分ほど正しいものです。新入社員が実際にやりそうな行動でなければなりません。先ほどのバナーのカードなら、選択肢は次のように作れます。
- デザインは確定済みなので、変更はできないと返信する。
- まずマークアップエンジニアに、対応できるかを聞く。
- 依頼内容を整理し、スケジュール・スコープ・QAへの影響を確認したうえで、回答時期をクライアントに伝える。
- バナーは小さな作業なのでQAのスケジュールに影響はないと判断し、すぐに作業を依頼する。
2と4は、現場でよく見られる選択です。2は順番を誤っただけで悪意はなく、4は影響を推測で片づけています。こうした不正解があってこそ、不正解のデータに意味が生まれます。
フィードバックには、正解かどうかよりも理由を書きます。4を選んだプレイヤーには、バナーの追加でQAの範囲にどんな項目が増えるかを確認しておらず、作業の規模とQAへの影響は別物だという点を伝えます。2〜3文で十分で、関連資料へのリンクも添えます。
ステップ5：配置とレポート連携
作ったクエストを配置します。難易度は、正解の難しさではなく、文脈の量で調整します。初級は制約が1つ、中級は2つの制約がぶつかる状況、上級は正解が1つに定まらず、根拠を求める形式です。
職種への配置では、同じ出来事を使い回すのが効率的です。先ほどのバナー追加の依頼1つから、5つのクエストが作れます。PMOは処理の順番、プランナーは要件を具体化するための質問、デザイナーは既存のビジュアル階層との衝突、マークアップエンジニアはレスポンシブレイアウトへの影響、開発者はCMS構造の変更範囲を見ます。同じ状況を職種ごとに違う視点で見る経験そのものが、学びになります。
最後に、レポートにつなげます。クエストごとに判断類型のタグを付けておけば、プレイ後に類型別の正答率が出ます。変更管理、エスカレーション、要件の明確化、品質基準くらいに分ければ十分です。このレポートは新入社員個人のためのものであると同時に、組織のためのものでもあります。特定の類型で全員が間違えるなら、直すべきは人ではなく文書です。
よくある失敗パターン
- 正解が見え見えの問題。4つの選択肢のうち1つだけ長くて丁寧なら、それが正解です。
- 検索型のクイズ。資料を探せば答えが見つかる設問は、クエストではなく資料へのリンクで十分です。
- 判断ポイントが2つ以上あるカード。不正解の原因が分かりません。
- ゲーム要素の過剰。ポイントやバッジ、ランキングを先に作ると、コンテンツの品質の問題が隠れてしまいます。
- 古くなった正解。プロセスが変わったのにクエストを直さなければ、新入社員に間違った手順を教えることになります。
- 一度に20個作る。まず5個作ってパイロットを回し、不正解の分布を見てから増やすほうが確実です。
変換チェックリスト
- 質問を、文面単位ではなく類型単位で数えたか
- 上位10類型からだけクエストを作ったか
- クエストごとに判断ポイントが1つか
- 状況カードに時点・主体・出来事・制約が入っているか
- 不正解のうち少なくとも2つが、実際に選びそうな選択肢か
- フィードバックが、正誤ではなく理由を説明しているか
- 判断類型のタグが付き、レポートで集計されるか
- プロセスが変わったときに、クエストを直す担当者が決まっているか
おわりに
このワークフローの要は、ステップ3ではなくステップ1です。繰り返し出る質問をきちんと集めれば、作るべきクエストは自然と絞られ、誰も聞いていない内容を問題にしてしまうこともなくなります。Wikiは引き続き必要です。ただ、Wikiが答えられない質問が何かを把握すれば、オンボーディングで何を作るべきかがはっきりします。
実務シナリオをクエストで体験してみませんか
社内資料をクエストに変えるとどうなるのかを見てみたい方は、First Runのデモをプレイしてみてください。 ゲームを始める