「まずは小さく試してから、本格的に開発したい」。ゲーミフィケーションの企画では、こうした進め方も選択肢になります。ただし、試作品が動いたことと、利用者の行動に役立ったことは、分けて確かめる必要があります。
前回は、見積もり依頼前に整理したい要件を紹介しました。今回は、小規模な検証であるPoC（概念実証）を、次の判断につながる形で計画するためのポイントをまとめます。
1．最初に「検証後に決めたいこと」を書く
PoCを始める前に、結果を受けて何を判断するのかを決めましょう。「本開発に進む」「体験を修正して再検証する」「いったん見送る」など、次の選択肢を用意します。
たとえば、架空の社内学習サービスで「学習後に、次の課題へ進む人を増やしたい」と考えたとします。このときの仮説を「達成した内容と次の課題が分かると、自分で学習を再開しやすくなる」と置けば、確認する場面が絞れます。
「楽しい画面を作れるか」だけで終わらせず、「利用者が何を理解し、どんな行動を取れたら、次に進む材料になるか」まで言葉にしておきます。
判断条件は、目標の数値と、その数字を信頼できる条件をセットで考えます。参加者が少ない、計測が欠けているなどの場合には、結論を急がず追加の確認が必要です。期待した反応が見られても、運用負担が大きければ、そのまま本開発に進むとは限りません。
2．一番不確かな前提から確かめる
すべての機能を小さく作るよりも、企画の成否に関わる疑問を選びます。参加方法が伝わるか、達成の表示を理解できるか、次の行動に移れるか。技術面なら、必要な行動データを既存システムから受け取れるか、といった問いです。
先ほどの架空例なら、最初は課題の完了後に表示する画面と、次の課題への導線に範囲を絞れます。ランキングや景品などを同時に加えると、どの変更が反応に関係したのかを整理しにくくなります。
試作で重要な仮説を優先する考え方は、英国政府のGOV.UK Service Manualでも示されています。これはサービス開発の進め方の参考であり、ゲーミフィケーションの効果を保証するものではありません。
3．問いに合った試し方を選ぶ
説明や操作の分かりやすさを見たいなら、紙の画面案やクリックできる試作品でも検討できます。一方、日を空けて再び使うかを知りたいなら、実際の利用場面で試す期間と、行動を記録する仕組みが必要です。
システム連携を確かめる場合は、利用体験の検証とは目的を分けます。テスト用データで接続できたとしても、本番の権限設定、データ量、エラー対応まで確認済みとは限りません。検証した条件と、まだ試していない条件を残しましょう。
参加者も、社内の企画メンバーだけで済ませず、想定する利用者に近い人を検討します。慣れている人と初めて使う人、継続している人と途中で離れた人では、見えてくる課題が異なる可能性があります。
4．行動の記録と、その理由を合わせて見る
先ほどの架空例では、「課題を完了した人のうち、日を空けて、設定した期間内に次の課題を始めた人の割合」などを指標の候補にできます。対象者、完了や開始の定義、集計期間を先に揃え、人数と割合の両方を記録します。
あわせて、「次に何をすればよいか分かったか」「表示に急かされる感じはなかったか」などを聞きます。途中でやめた場面や、説明を受けないと進めなかった場面も、改善を考える材料になります。
導入前後で数字が変わっても、参加者の違い、周知の方法、繁忙期などが影響しているかもしれません。比較できる条件を検討し、少人数・短期間の結果だけで長期的な継続効果を断定しないことが大切です。
計測を始める前には、同じ操作が重複して数えられないか、途中で離れた人も集計対象に含まれるかを試します。結果が良かった人だけを取り出さず、参加者全体で何が起きたかを確認できる形にしておきましょう。
5．運用の負担と、止める条件も確認する
利用者の反応に加えて、担当者が無理なく運用できるかを確かめます。課題の更新、記録の確認、問い合わせへの対応などに、誰がどれくらい手を動かしたかを残しましょう。手作業で補った部分は、本番でも続けられるかを別途検討します。
負担感や不公平感が強い、目的と関係のない操作ばかり増える、記録が正しく取れない。こうした状況で、何を修正し、いつ検証を止めるかも決めておきます。参加方法や途中でやめる方法、扱うデータと保存期間も、開始前に整理します。
6．結果を、本開発の条件につなげる
検証のまとめには、数値だけでなく「分かったこと」「判断できなかったこと」「次に確かめること」を書きます。想定と違う結果も、対象者や体験を見直すための情報です。
本開発に進む場合は、試作品をそのまま使える範囲と、作り直す範囲を確認します。セキュリティ、対応端末、運用画面、保守など、本番で必要になる作業も整理しましょう。PoCの費用だけで、本開発や運用を含む総額が決まるわけではありません。
PoCを始める前のチェックリスト
- 検証後に決めたいことと、判断する担当者
- 優先して確かめる仮説と、今回試さない範囲
- 参加者、利用場面、検証期間
- 行動の指標、集計条件、利用者に聞くこと
- 運用担当、必要なデータ、負担や不具合への対応
- 続行・修正・中止を判断する条件
- 本開発に引き継げるものと、追加で必要な作業
小さく試し、判断できる材料を残す
PoCの計画では、作る機能の数とあわせて、確かめたい問いを整理することが大切です。結果を見てから判断基準を考えるのではなく、開始前に関係者で共有しておきましょう。
クロスゲームズでは、ゲーム開発で培った視点を活かし、課題に合った体験づくりをご支援しています。「どこから試せばよいか」という段階のご相談も、ゲーミフィケーション開発のページからお寄せください。
コメント