なぜ作ったのか
目的は2つあります。
① 新規参入メンバーへの業務ツール勉強会
いつも社内勉強会というと講義式が多いので、一方的に有識者から説明を受けるよりも、自分で手を動かしてみるほうが記憶に残るんじゃないかと考えました。
実務で起きるあるあるのシナリオや事例を使ってクイズを作り、ゲーミフィケーションの要素をもたせることで、楽しく学んで記憶や知識に残ることを目指しました。
② プロダクト開発メンバーのユーザビリティテスト
ユーザーの動きをみながら、プロダクトの使いやすさや改善できるポイントはないか？次に作るプロダクトで考慮するべきUXはどんなものか？を探りたい目的もありました。
単純にExcelやパワーポイントを使って、クイズを出題する方法でもよかったのですが、ゲーム性を高めるために、スクラッチでクイズアプリを開発しました。
それが PAK BootCamp です。
（PAKは「PA基盤課」の略称です）
開発には AI エージェント型の開発環境 Kiro を使い、バイブコーディングで進めました。ルールやコンセプトは自分で考えて、アプリのコーディングはKiroに指示を出して作ってもらうスタイルです。
最初はMVPの構成、機能で作り始めましたが、後からやりたいことがどんどん出てきて、できることをふやしていきました。
ただ、機能を追加していくごとにバグが出る数も増えていきました。なんとなく動くんだけど、ちょっとしたところで漏れやループが発生することがあって、基幹システムや重要な業務アプリケーションなど、品質にこだわるアプリにAI駆動開発を取り入れることの難しさもわかりました。
でも、さくっと素敵なアプリができて、すごかった。
ゲームプレイの流れ
登場人物は3種類です。
- 参加者: スマホやPCで参加者画面を開く
- 司会者: 問題の進行・タイマー操作
- モニター: 全員が見る問題・タイマー・スコアボード表示用
① start.bat をダブルクリックしてサーバー起動
② 表示されたIPアドレスを参加者に共有（口頭 or チャット）
③ 参加者がスマホやPCで /display を開き、チームを選ぶ
④ モニター用PCで /display をフルスクリーン表示
⑤ 司会者が /operator で問題を選んでタイマー開始
⑥ 制限時間内に各チームで業務ツールを使って解く
⑦ 解説タイムに参加者が自己採点
⑧ 全問終了後、結果発表
トップ画面（ロゴもポップな感じで作った）
チーム選択はこんな感じ
問題表示中（司会者画面でタイマーをスタートすると、残り時間が減る）
結果発表
アプリの構成
画面一覧
| 画面 | URL | 誰が使う |
|---|---|---|
| 参加者画面 | /display |
参加者全員（スマホ・PC）とモニター |
| 司会者画面 | /operator |
司会者PC |
| 管理画面 | /admin |
お題の追加・編集・削除 |
| 実施履歴 | /history |
過去の結果を振り返る |
司会者コントロール画面はこんな感じ
参加者画面（/display）は1つのURLで 全役割を担います。
開いた瞬間はチーム選択オーバーレイが出て、チームを選んだらそのまま問題表示・自己採点・結果確認まで同じ画面で進みます。モニターに映す用も同じURLでOKです。
リアルタイム同期の仕組み
参加者全員の画面と司会者画面は常に同じ状態を見ています。
これを実現しているのが SSE（Server-Sent Events） です。
サーバーからクライアントへ状態をプッシュし続けることで、司会者がタイマーをスタートした瞬間に全員の画面でカウントダウンが始まります。解説タイムに誰かがチェックを入れると、モニターのスコアボードが即座に更新されます。
技術スタック
| 要素 | 内容 |
|---|---|
| サーバー | Node.js（標準モジュールのみ） |
| フロントエンド | HTML / CSS / JavaScript（フレームワークなし） |
| リアルタイム同期 | SSE（Server-Sent Events） |
| お題データ | questions.json |
| 依存パッケージ | なし（npm install 不要） |
| 開発環境 | Kiro（バイブコーディング） |
npm install 不要にしたのは、社内PCの環境差を気にせず node server.js の一発起動にしたかったからです。
その他の機能
使いながら追加していった結果、こんな機能が揃いました。
- クイズセット切り替え: 複数の問題セットを作成して切り替えられる。研修テーマごとに使い分けできます
- チーム戦 / 個人戦モード: チーム名を選ぶ通常モードと、名前を入力してエントリーする個人戦モードを切り替えられます
- チーム定員: 1チームに入れる人数を設定でき、定員オーバーになるとグレーアウトされます
- サウンドエフェクト: 出題音・カウントダウン（残り10秒から毎秒）・タイムアップ音・結果ファンファーレを Web Audio API で実装。ゲーム感が一気に増しました
-
共通情報パネル:
info.htmlを編集するだけで、全問共通のルール・注意事項・リンクを参加者画面に常時表示できます
お題設計が一番難しかった
アプリを作るより、問題を作る方がずっと難しかったと思っています。
問題のシナリオは実際の業務をベースにしているので、リアルな問い合わせ内容・アラート・申請データをUAT環境に用意する必要があります。参加者がゲームの中で実際にツールを操作するので、テストデータが揃っていないと問題が成立しません。
しかも毎回実施するたびにデータを初期化しないといけない。テストデータを作る手間がなかなか大変で、ここの効率化はまだ課題として残っています。
問題の種類
実際の業務で発生する場面をそのままシナリオにしました。
| カテゴリ | 概要 |
|---|---|
| 問合せ対応 | アプリ担当からの問い合わせを確認・回答する |
| アラート対応 | 基盤アラート発生時の初動対応 |
| 申請対応 | 申請内容の確認・差し戻し・案内 |
最初に「練習問題」を1問入れて、操作と雰囲気に慣れてもらえるようにしました（練習問題は得点なし）。
採点の設計
問題はこんな形で定義しています。
{
"title": "問合せに回答してみろ！",
"difficulty": "低",
"scenario": "あなたはインフラ運用担当者です。アプリ担当から問い合わせがありました。問い合わせ内容を確認してください。",
"timeLimit": 180,
"scoring": [
{ "label": "ツールにアクセスした", "points": 2 },
{ "label": "対象の問合せを絞り込んだ", "points": 5 },
{ "label": "問合せ内容詳細を確認した", "points": 10 }
]
}
採点項目は「どんな操作をしたか」で構成されています。
正解を一発で出せたかではなく、どこまで実際のルールや業務に沿った行動ができたかを見ます。
加点方式のこだわり
採点は「基本点 ＋ 加点」の設計にしました。
- 低配点（基本点）: ツールを開けた、画面に辿り着いた
- 中配点: 目的の情報を見つけられた
- 高配点（加点）: より丁寧な対応ができた、関連情報もあわせて案内した、など「より良い対応」
基本操作でも点が取れるので 初心者が気後れしない得点設計にしました。
そして高配点には「なるほど、そこまで考えるのか！」という気づきを得てほしいという思いを込めました。
難易度が上がるほど、加点要素の比重が大きくなっています。
| 難易度 | 基本点 | 最大加点 |
|---|---|---|
| 低 | 2点 | 10点 |
| 中 | 2〜5点 | 20点 |
| 高 | 2〜5点 | 30点 |
この加点要素を考えるのが一番難しかったです。
通常操作は基本得点としてすぐ決められるのですが、加点要素は「ここも確認しておけば対応しやすいよね？」「こうすればもっとGoodな対応ができたよね？」というもので、正解が一つではありません。
実際にプレイしてみると、出題者側で想定していた加点要素とは別の気づきや気配りが参加者から出てくることもありました。
もしかすると加点要素は事前に決めるのではなく、解説フェーズでみんなで議論しながら決めるルールにしてもよかったかもしれない。ここも今後改善していきたいなと思っています。
やってみてどうだったか
みんなわいわい、ああだこうだと、楽しんでくれました。
解説のときに、回答内容がおもしろかったり、自分が日頃実施しているお題ならサクサク操作できたり、「これはわからーーん！」と焦る姿を楽しく嬉しく見ていました。
「こう回答すれば問い合わせ者に必要な情報が伝えられるね。」という気づきが得られたということもありました。
「楽しかったです」という声と、「これすごいね！色々な勉強会で応用できそうだね！」という声もあり、これから活躍してくれそうなアプリになりそうです。
UXテストとしての振り返り
初回実施時には、UXテストとしては十分な効果が得られませんでした。
観察するポイントを事前に定義していなかったこと、既存機能が対象だったこと、ユーザビリティテストを意識した問題設計になっていなかったことが原因だと思っています。
開発者からは、「新機能をリリースしたタイミングで、その機能を使って問題を解いてもらい、どこまで得点できるかでつかいやすさを測る、そういう使い方もできるな」という気づきがありました。スコアが高ければ直感的に使えている、低ければ迷いや使いにくさがあるという指標になる。そういう可能性も見えてきたので、これから育てていきたいと思っています。
おわりに
今後は問題を増やしたり、やり方やルールも見直しながら、色々と改善していきたいです。
テストデータ作りの効率化や、UAT環境の初期化まわりはまだ課題として残っています。でもそれも含めて、これから少しずつ整えていく楽しみがあるなあと思っています。
やるぞー！やるぞー！やるぞー！