体験型装置のセルフUI開発｜5分の体験設計と失敗しない進め方

商業施設やイベント、店頭に置かれる「体験型の装置」が増えています。カメラで撮影して結果を返すもの、映像や光で演出するもの、診断結果からおすすめを提示するもの。技術としてのコアはすでに動いているのに、実用化の直前で止まってしまうケースは少なくありません。

止まる理由の多くは、技術ではなく「スタッフが横についている前提の体験を、来場者ひとりで完結できる体験に作り替えられていない」ことにあります。

この記事では、体験型装置のセルフ化に必要なUI設計と、開発を安全に進めるための考え方をまとめます。

体験型装置のセルフ化でつまずく3つのポイント

出典：https://unsplash.com/ja

1. 「案内役がいる前提」の体験フローになっている

PoC（実証実験）の段階では、開発担当者やスタッフが横で操作を補助しています。この状態で完成した体験フローをそのまま画面に落とすと、来場者は必ずどこかで止まります。

分岐の説明、次に何をすればいいかの案内、うまくいかなかったときのリカバリー。人が担っていた役割を、すべてUIと音声に置き換える必要があります。

2. 既存システムとの「繋ぎこみ」の工数が読めない

体験型装置は、カメラ・プロジェクター・センサー・制御PCといったハードウェアと、その上で動く自社開発の制御プログラムで構成されています。新しく作るUIは、これらと通信しなければ動きません。

ところがこの連携部分は、実機に触れるまで工数が確定しません。仕様が曖昧なまま一括請負で契約すると、納期と金額の両方が破綻します。

3. リリース後、体験フローは必ず変わる

提示する選択肢の数、コンテンツの入れ替え、文言の修正、多言語対応。運用が始まれば改善要望は必ず出ます。このとき「都度コード改修・都度見積」の構造になっていると、改善サイクルが費用と時間に縛られます。

解決策①：5分の体験を「秒」で設計する

出典：https://unsplash.com/ja

「体験時間は5分」という要件を、そのまま受け取ってはいけません。5分＝300秒をどう割り当てるかまで落として、はじめて設計になります。

たとえば5ステップの体験なら、次のように配分します（あくまで一例です）。

重要なのは、ハードウェア側の処理時間（映像の切り替え、解析の完了待ちなど）を実測してから配分を確定させることです。ここを想定値のまま進めると、実機で「5分に収まらない」という致命的な手戻りが発生します。

解決策②：セルフ体験で必ず起きる例外を、先に潰す

来場者はマニュアルを読みません。想定どおりに操作してくれることのほうが稀です。設計時点で、次のような例外を織り込んでおきます。

• 撮影・スキャンに失敗する → 再試行は2回まで。3回目は代替処理で続行し、体験を止めない
• 途中で立ち去る → 無操作60秒でアテンション、90秒で初期画面へ復帰。取得済みデータは破棄
• 複数人が同時に映り込む → ガイド枠で対象を1名に固定し、条件を満たさない間は操作を無効化
• 機器に異常が出る → 来場者の画面は待機演出のまま維持し、スタッフ側にのみ通知。エラー表示は見せない
• 個人情報の入力を拒否される → スキップ可能とし、体験自体は最後まで通す

あわせて、導線設計の原則を3つ置いています。

1. 一画面一意思決定：1画面で問うことは1つだけ。決定ボタンは常に同じ位置に固定する
2. 待ち時間を演出で埋める：「処理中」ではなく、いま何が起きているかを可視化して体感時間を縮める
3. 迷ったら進める：無操作10秒でヒント音声、20秒で推奨候補をハイライト。行き止まりを作らない

これらは実運用で必ず起きます。開発着手後に発覚すると、追加開発か体験品質の妥協かの二択になります。

解決策③：繋ぎこみの不確実性は「Phase 0」で先に消す

出典：https://unsplash.com/ja

ウィルダーが体験型装置の案件でご提案しているのが、本開発の前に置く1〜2週間の技術検証スプリント（Phase 0）です。

Phase 0 は単独でご契約いただけます。検証結果をご覧いただいたうえで、本開発を発注するかどうかをご判断いただく形です。

この進め方には2つの利点があります。ひとつは、発注側が小さな金額でリスクを確かめられること。もうひとつは、検証の結果として工数が想定と乖離した場合、本開発の着手前に見積を出し直せることです。着手後に「思ったより大変でした」と追加請求が発生する事態を、構造的に防げます。

なお、既存の制御プログラムのI/F仕様書（制御方式・コマンド体系・応答仕様など）をご提供いただける場合、Phase 0 の工数は大きく圧縮できます。浮いた分は減額としてお返しすることも、同額のまま本開発の工数に振り替えることも可能です。調査に使うはずだった予算を、そのまま開発に回せるということです。

解決策④：運用後に変え続けられる「設定駆動」の作り方

体験フローを画面ごとにハードコードすると、些細な変更でも改修案件になります。そこで、体験を「ステップ定義データ」として外に出し、UIはそれを解釈して描画する構造にします。

この作りにしておくと、次のような変更は設定側の書き換えだけで反映できます。

• 体験ステップの順序・スキップ
• 選択肢の提示点数
• コンテンツ・マスタデータの差し替え
• 画面文言・音声トラックの差し替え
• 言語の追加（辞書ファイルの追加）
• タイムアウト時間・演出秒数

初期構築のコストは多少上がりますが、リリース後の改善サイクルが「都度見積」から「保守の範囲」に移るため、中長期では確実に回収できます。PoC後にフローが変わることが前提の案件では、特に効果が大きい考え方です。

ウィルダーの提案の進め方

出典：https://unsplash.com/ja

提案の段階で、画面ラフまで作ります

体験設計は、文章で説明するより画面を見ていただくほうが早く伝わります。ウィルダーでは、ご提案の段階で主要画面のラフ案を作成し、資料に含めてご提示しています。

「どんな画面になるのか」「5分に収まるのか」「迷わず操作できるのか」は、実際の画面を見ながらでないと議論になりません。提案書を読む時間そのものを、要件のすり合わせに変えることを狙っています。

こんなご相談を承っています

• 自社で開発した制御システムはあるが、来場者が操作するUIを作れる相手を探している
• PoCは動いたものの、実用化・常設運用に向けた作り込みが止まっている
• ハードウェアとの連携部分の工数が読めず、見積が出てこない／各社バラバラ
• リリース後に自分たちで改善を回せる構造にしておきたい
• 短納期で、まず小さく検証から始めたい

体験型装置のUI開発は、Web制作ともシステム開発とも少し違う勘所があります。「動くもの」を作るのではなく、「初見の人がひとりで完走できるもの」を作るという前提に立てるかどうかが分かれ目です。

現在お持ちの資料（体験フロー案、既存システムの構成、想定予算・納期）をお送りいただければ、まずは論点の整理からお手伝いします。

よくあるご質問

Q. ハードウェアの開発や調達もお願いできますか？

A. 本記事でご紹介しているのは、既存のハードウェア・制御システムに接続するUI層とアプリケーション層の開発です。ハードウェアそのものの設計・製作・調達は対象外となりますが、既存機器との連携部分（コマンド送出、状態同期、異常検知）は対応範囲に含みます。

Q. Phase 0 だけを依頼することはできますか？

A. 可能です。Phase 0 を単独でご契約いただき、技術検証報告書をご覧いただいたうえで本開発の発注をご判断いただく形をとっています。検証の結果、想定と大きく異なる事実が判明した場合は、本開発の着手前に改めてお見積りをご提示します。

Q. 既存システムの仕様書が手元にない場合はどうなりますか？

A. 仕様書がない前提でもお受けできます。その場合は Phase 0 で実機を触りながらI/Fを調査するため、期間・工数がやや大きくなります。逆に仕様書をご提供いただける場合は Phase 0 を圧縮でき、その分を本開発に振り向けられます。

Q. 短納期でも対応できますか？

A. スケジュールの逆算と、スコープの優先順位づけをセットでご提案します。納期が動かせない場合は、初期リリースに含める機能と、リリース後に追加する機能を分けて計画を立てます。無理な工数圧縮でご提案することはいたしません。

Q. リリース後の運用・改善もお願いできますか？

A. 月額保守という形で承っています。稼働監視・障害一次対応・軽微な不具合修正に加え、設定データの変更代行（コンテンツ・文言・提示点数の入れ替え）まで含めた範囲でご相談ください。体験フローの大幅な改訂や多言語追加など、開発を伴うものは別途お見積りとなります。

体験型装置のセルフ化について、構想段階からのご相談も歓迎しています。「何を決めればいいのかがまだ整理できていない」という状態でも問題ありません。論点の洗い出しからご一緒します。