インターン生たちと社内向けサービスを開発しています。スイーツをとる順番を決める（1位の人から好きなスイーツを選べる！）ゲームで、機能としては「エントリー」「スクラッチくじ」「結果発表」と単純なものです。開発途中で年賀アプリがはじまったので中断していましが、年が明けて再開しています。

再開するにあたってまず改善案を整理しつつ思い出していきます。去年に社内のメンバーにテストプレイしてもらったのですが、残念ながら反応はイマイチ。「遊べはするけど、なんかぎこちない」「次に何をすればいいのかわかりづらい」「もうちょっと楽しめそうなのに」といった感想でした(´･ω･`)。

改善するポイントはいろいろあるのですが、はたと考えます。
遊ぶのに必要な画面要素や機能はあるのに、いったい何が足りてない？
ということで生成AIに聞いてみました。（以下抜粋、一部修正）

----------------------------------------------------------------------------------------------

Q. ゲームに必要な要素や機能はありそうですが、全体的な流れがぎこちなくわかりにくいという感想がありました。なぜでしょう？

問題の本質は、おそらく「機能を作る」ことと「体験を作る」ことの違いにあるかもしれません。開発側の意識として、以下のような点が不足している可能性があります：
・ユーザー体験の連続性が弱く、スムーズにつなげていない
・開発者にとって当たり前の操作や用語を用いている
・機能面は満たしていても、楽しさや期待感といった感情的な要素が欠けている
・各ページで「なぜこの操作が必要なのか」の文脈が説明されていない
・ユーザーの操作に対する即時の反応や確認が不足
つまり、単に機能をつなぎ合わせるのではなく、一貫した「体験」としてデザインすることが重要です。ユーザーが自然に、楽しく、不安なく進められる流れを作ることで、ぎこちなさが解消されるはずです。

Q. 「体験」としてデザインすることが重要なのは分かりました。一方で改善案をリストにして修正したとしてもいつまでも「機能」のつなぎ合わせ、つまり部分最適化の状態から抜け出せないような気もするんですがどうですか？

その懸念はとても的確だと思います。確かに、「ここを直す」「あそこを改善する」というリスト形式の提案は、結局のところ部分最適化の集合に過ぎません。本質的な改善のためには、まず「このゲームで実現したい体験」を明確にする必要があります。

「社内の仲間と一緒に、ちょっとしたドキドキ感とワクワク感を共有できる、楽しい社内イベントの1コマを作る」 このような体験のビジョンが決まれば、すべての設計判断の指針になります：
ゲームの導入部分は「仲間と一緒に参加する楽しさ」を感じられるものに
パネルをめくる演出は「ドキドキ感」を引き出すように
結果発表は「みんなで盛り上がれる」ような仕掛けを

つまり、個々の機能や画面を「点」として捉えるのではなく、一貫したストーリーの「線」として捉え直すことが重要です。

現在の設計では、おそらく以下のような暗黙の前提があるのではないでしょうか：
「ユーザーは必要な手順を踏んでくれるはず」
「説明があれば理解してくれるはず」
「機能があれば使ってくれるはず」

これを、以下のような発想に転換する必要があります：
「ユーザーを自然に次の行動に導くにはどうすべきか」
「直感的に理解できる体験をどう作るか」
「思わず使いたくなる魅力をどう作るか」

Q. 体験の言語化と発想の転換が必要ということですね。１つ目の体験の言語化についてですが、抽象的な言葉だけが宙に浮いてしまい実装と乖離する危険性もありそうですが？

その指摘はとても重要です。確かに「楽しい体験を作る」「ワクワクする体験」といった言葉だけが先走ると、各メンバーが異なるイメージを持ったまま進めてしまう危険性があります。 この課題に対処するためのアプローチを考えてみましょう：
・似たような要素を持つ別の体験を具体的な参照点として共有
・プロトタイプの早期作成と体験の可視化
　言葉での説明には限界があるため、まず動くものを作る
　核となる体験から優先的に実現する
・ユーザーテストを通じた「現実の反応」の観察
・チーム内のイメージの異なりを活かす
・判断基準の明確化、体験の質を評価する基準を具体的に定義する

Q. 定義の解像度をあげる、そして形にして擦り合わせることが大事ということですね。２つ目のユーザーはこう使ってくれるはずというある種自分本位な考え方から、相手の目線で想像できるまでにはどのような段階がありますか？

この質問は体験設計の本質に迫る重要な点ですね。「自分本位」から「相手目線」への転換には、おそらく以下のような段階があると考えられます：
1. 無自覚期 ：自分がわかれば他人もわかるはずという思い込み
2. 気づきの段階：テストやフィードバックで自分の思い込みに気づく
3. 学習期：ユーザーの行動を観察し始める
4. 実践期：作る前にユーザーの文脈を考えるようになる、ユーザーにとって本当に必要かと問い直せる
5. 統合期：技術とユーザーニーズのバランスが取れる、異なる立場のユーザーを想像できる

ただし、これは一方通行の進化ではなく、新しい課題に直面するたびに 最初は自分本位になってしまう、気づきがあって軌道修正する、より深い理解に至る という循環を繰り返していく過程かもしれません。 大切なのは、「完璧な相手目線」を目指すのではなく、常に自分の視点を疑い、学び続ける姿勢なのかもしれません。

Q. 体験作りは自分の考えと現実の反応とのズレを埋めていくプロセスでもあるんですね。これは精神的にも認知的にも負荷が高そうですがどうですか？

その指摘は非常に的確ですね。開発者として、自分が良いと思って作ったものが思うように受け入れられない時の心理的負荷は確かに大きいものです。この状況について、以下のような側面があると考えられます：

・心理的な負荷
　自信を持って作ったものへの否定的なフィードバック
　「なぜわかってもらえないんだろう」というフラストレーション
・認知的な負荷
　自分の思考の枠組みを超えて考える必要性
　多様なユーザーの視点を同時に考慮する複雑さ

これらに対処するための考え方として：
・プロセスとして捉える
　完璧な理解を一度に目指すのではなく、段階的な改善として考える
・心理的な距離感の確保
　「自分の作ったもの」と「自分自身」を切り離して考える
　フィードバックを個人攻撃と受け取らない
　「より良いものを作るためのヒント」という視点を持つ
・チームとしての取り組み
　一人で抱え込まず、チームで共有する
　互いの経験や気づきを共有し、学び合う
　「完璧を目指す」のではなく「より良くする」という方向性を共有

Q. ありがとうございます。参考にさせてもらいますね

こちらこそありがとうございました。