なぜディレクターはUXを分解・言語化しなくてはいけないのか？クソゲーが生まれてしまう原因
ゲームディレクターとして動いていると、企画やできたもののフィードバックをよくする。そうすると必要なのは、UX（ユーザー体験）を言語化して説明をして納得をしてもらうことだ。一緒にやっているプランナーから、UXの分解・言語化をどうやっているのか？という質問が来たので、書いてみる。
ゲームディレクターは、なぜUXの分解・言語化が必要なのだろうか？
これは簡単で、自分が感じていることを言語化できないとチームメンバーに伝えることができず、納得感を持って作ってもらうことができないためだ。「なんとなくダメ」とか、「理由は説明できないけどこうして」という指示は、繰り返せば繰り返すほどやらされる方はしんどくなっていく。当たろうが外れようが、何をやっているのかよくわからなくなってくる。主観ではなく、客観で伝えることができないと、チームは納得がしにくい。なので、ゲームディレクターにはUXの言語化能力がとても必要とされている。
この記事の結論としては以下となっている。
UXの分解・言語化をするためには以下が必要となる
・言葉がないと認識・表現ができないので言葉を覚える
・言葉とUXの紐付けの訓練を行う
・MDAフレームワークによる構造分解を行う
・自分とは異なるユーザーセグメント、Not for meを理解する
・ディレクター、プロデューサー間は言葉が伝わらないとクソゲーができるので注意
言葉がないと認識・表現が出来ない
言語化するにおいて、言葉を知らないと言葉に変換することは出来ない。だが、もっと困ったことに、言葉で表せないUXは認識も困難である。
これは、アメリカには肩こりという概念、言葉がないので肩こりがわからないという話と似ている。
アメリカでは、肩こりという概念を示す言葉がないそうだ。have a stiff neck（首筋が凝っている）という表現はある。結果、肩こりが認知出来ないそうだ。そもそも肩こりという言葉は夏目漱石が創作をした。それが普及をした結果、日本人は自覚をするようになった。
また、虹が何色で構成されているかというのも国によって違うようだ。
これも言語が認知を規定する例といえるだろう。他にも似た例として、日本の信号の青が緑であるという話がわかりやすいと思う。昔の日本語では、緑も青の一種だったのだ。
あなたがプログラマーであればGoFのデザインパターンが分かりやすい例だろう。
デザインパターンは優れたプログラマが行っているコードの書き方に名前を付けることで、プログラマ間のコミュニケーションが円滑化され、良いコードを模倣できるようになった。今ではデザインパターンの機能を標準として取りこんでいるプログラミング言語も多い。
このように、言葉によって認識は制限をされている。なので、言葉を取り入れる事によって、表現の幅は広がるだろう。UXを言語化できない一つの原因として、表現する言葉を知らない事があるだろう。
「遊び」や「面白い」の言語化は過去に幾人もの先駆者が行っている。
ビューラーの分類（心理的機能面）、カイヨワの分類（遊びの内容）、ピアジェの分類（知的発達の視点）、バーテンの分類（遊び方の観点）といくつもの分類がある。
保育における子どもの社会性とイメージする力を育てる遊びより引用。
この話は、これについてとても詳しく詳細まで理解が必要という話でない。言葉が無いと言語化が出来ないという話の例である。この話を知らなくても、別にゲームは作れる。知っていると言語化に便利であり、人に体験を伝えたり、議論したりするのに重宝されるということだ。
個人的に学習をおすすめしたいジャンルとしては、ゲームユーザーのセグメント、認知心理学、行動経済学、物理学などである。人によってはもっと別のジャンル（歴史、物語論、比較神話学、物語の類型、人体の構造など）を必要とすることもあるだろう。先人たちが開拓した研究分野には物事を背明するための多くの専門用語があるので、世界を見る視点・視座を獲得するためにもこれらを学ぶことがゲームディレクターには求められている。
また、これは応用となるが、現状ある言葉で足りない場合もあるだろう。このときには、自分で新しく言葉を作ってしまって良い。私はよく作る。ただ、すべての人に通じないため、説明が必要となる。私は、この新しい概念の言葉を作りすぎて、ただ話すだけでは通じなくなってきてしまっているが、これはこれで問題ではある。
言葉と体感の紐付けの訓練
言葉が手に入った場合は、次に必要なのは、言葉とUXの紐付けの訓練だろう。言葉とUXの紐付けには、まず一番単純なUXを自らの言葉で説明していくのが良いだろう。
具体的な例をだそう。アクションゲームのジャンプの気持ちよさの話だ。殆どのアクションゲームで、ジャンプすることは楽しい。なぜならば、歩いているだけでは届かないところに届くことができるし、さらには見た目として、自分がジャンプ操作をしたから、実際にプレイヤーが放物線の軌道を飛ぶという見た目上の変化を起こすからである。更にマリオなどでは、ジャンプ自体が攻撃を兼ねていたりもする。
ただ、このジャンプは現実世界のとおりに実装しても微妙なUXになる。物理世界では、ジャンプをしたあとの軌道は、空気抵抗以外に何かを変化を起こすものがない。なので、ジャンプをした瞬間に軌道を決定、そのままコントロールを出来ないままに放物線軌道を描くのが物理上では正しい。
実際にこれを作ってみると分かるが、ジャンプしたあとに何も出来ないというUXは気持ちよくない。これを改良しようとすると、ジャンプ後に勢いを前後キーでコントロールできるようにする、ジャンプボタンを押した時間でジャンプの高さを調整する、２段ジャンプ、壁ジャンプ、ジャンプ攻撃の実装を加える、着地地点をコントロールしやすくするための落下速度の上限値の設定、などの方法がある。
ジャンプは、ジャンプしているから気持ち良いのではなく、ジャンプに伴うコントロールが強くあるから気持ち良いのだ。それは物理世界のジャンプではなく、心象物理世界のジャンプが理想なのだ。マンガの世界でできることは、ゲームの世界で出来たほうが気持ち良いのだ。
単体のUXで一番わかり易いのは自分で作ったミニマムなゲームである。意図から起こした仕様で、意図したUXを実現できないのは誰でも一度作ってみればわかるのだが、そのときになぜUXが実現できないのか、どうすれば実現するのか模索したり、または似たゲームで１つの正解の形というものを確認すると、自分が本当に見て感じていたのは、実は認識しているものとは全然別のものだったみたいなことがよくあると理解できる。
ここで必要なのは、すごい面白いゲームではなく、ミニマムで（やや微妙な）ゲーム群だ。すごい面白いゲームは複合的にUXデザインがされており、UXのほころびが隠されてしまっている。UXが複合的にデザインされているため、そのため単体のUXで何が起きたのかわかりにくい。
また、自分で作ったもので無いものであれば、広告から行った全く知らない（小さい）ゲームのほうが都合が良い。知っているものというのは、どこかですでに期待値が存在するため、見えているようで見えていない。広告等でまったく知らないゲームをプレイするのは非常に勉強になる。期待値がないので冷静に見れる、冷静に見た上で、自分の面白いと感じるポイントを見極めるのだ。これを繰り返すことで、単体のUXがどのように出されるかが認識でき、よくできたゲームの複合UXも認識できるようになっていく。
MDAフレームワークによる仕様から感情までの接続
人間のUXと認識というのは実はとても曖昧なもので、ゲームディレクターが設計上意図した因果関係が、ユーザに実際に認知されていないことが多い。
MDAフレームワークというものは、起きていることの因果関係を３つの要素に分解をして、認識、分析をしましょうというフレームワークである。こうすることで、感じていることと起きていること、仕様をそれぞれ分離して認識することができる。
MDAフレームワークで既存のゲームを分析する際には、アスセティックス（感情）→ダイナミクス（現象）→メカニクス（仕様）という流れで分析をする。自分の体感はどのような現象から生まれたものか、その現象はどのようなゲーム仕様から創発されなのかを考えるのだ。こうすることで、感情→現象→仕様の連鎖を理解できるようになる。
ゲームを自分で作る場合はこれが往復構造になる。ユーザに与えたい感情→与えたい現象→実際のゲーム仕様→創発された現象→体験した感情、という構造になる。往復構造により「与えたい感情」と「体験した感情」の相違や、「与えたい現象」と「創発された現象」の差異が明らかになっていくのだ。
こういった往復構造でゲームデザインを考えると、仕様を変えることで直接感情が変わるみたいな夢見事を考えなくなる。また、これを当てはめることを訓練を続ければ、空で体験を分解して認識できるようになるだろう。
ドラクエの成長感
例を出そう。RPGのドラクエでは、レベルアップが成長感を生みとても楽しくなるようにデザインされている。しかし、RPGでレベルが上った！成長したと感じるようにデザインをするのは、適当にやるとなかなか出来ないものなのだ。RPGツクールなどでやってみればわかるが、レベルが上っても、そのUXが無い、または強くなりすぎて面白くない状態にすぐになってしまう。あれだけ簡単にみえたドラクエの成長UXとは何だったのだろうか？MDAフレームワークを通じて、ドラクエを分析してみよう。（最近のドラクエはあまり触ってないので、ここではドラクエ３をベースにしています）
ドラクエにおけるA(感情)は「レベルアップによる成長感により、もっと成長したいと思える」である。ではD(現象)やM(仕様)は何であろうか？
ドラクエにおけるA(感情)を生み出すD(現象)は「強いボスが倒せた」というのもあるが、じつは「継続戦闘能力の向上」なのである。町に戻らないでどれくらい戦えるか、どれくらいまでダンジョンの奥深くに潜れるか、ダンジョンが踏破できるのか、そして次の町に到達でき新しい冒険が始まる。これがドラクエのD(現象)である
では継続戦闘能力とは何から生まれているのだろうか？それは、単純化をすると「１バトルでの被ダメージをどれくらい抑えられるか？」である。そして被ダメージは回復リソース（MPとHP回復アイテム、世界樹の葉、MP回復アイテム）を削っていき、それらが枯渇したら全滅である。
継続戦闘能力はパラメータや回復魔法、回復リソースなどに依存しており、上がったパラメータや、アンロックされた要素、購入できる武器防具などによって強さを実感できるように調整されている。なによりターン性バトルと緻密なパラメータ調整により、少し成長することで3発で倒せていた敵が2発になり、2発が1発になる。ほんの僅かなパラメータの成長により被ダメージを大幅に軽減できるのである。さらには敵グループという概念もあるため、ベギラマのようなグループ攻撃魔法や、イオラのような全体攻撃魔法によって効率的に進められるようになっている。
つまりドラクエにおけるMDAフレームワークの構造は次のとおりである。
A: 「レベルアップによる成長感により、もっと成長したいと思える」
D: 「継続戦闘能力(被ダメージの低下)の向上により、より遠くまで冒険できるようになる」
M: 「緻密なパラメータ調整により、わずかな成長でも大幅な被ダメージ軽減ができる」
なので、適当に作ったRPGでは倒したボスの強さでプレイヤーの強さを表現するため、レベル上げがさっぱり面白くないし、全く違う仕組み（継続戦闘が無い）のソシャゲでドラクエのようなバトルシステムを作ってもさっぱり面白くないのである。
FTLの飢餓感・緊張感
もう一つ例をだそう。私が作っているローグライクゲーム「DIMENSION REIGN」を作っている際、FTLを参考にプロトタイプを作っていた時があった。FTLはとても良くできている面白いゲームだ。
このゲームは面白いが、具体的に何が面白さに寄与しているのかがわかりにくいゲームである。リアルタイムのバトルが、ビルドが、制約がということは言える。だが本当にそうなのだろうか。実際に作って再現をしてみたところ、ぱっと見わからないが確実に面白さに影響している要素は「敵がマップの背後から進軍をしてきて、それがマップ上で可視化されること」による緊張感・飢餓感であった。
インディーズゲームの小部屋：Room＃273「FTL: Faster Than Light」より引用。
FTLはローグライクである。ローグライクで私が必要だと思っているのは、飢えである。FTLは直接飢えること（満腹システムなど）がない。FTLはどうやって飢えさせているのか、それは１つは「人や電力リソースを再配分させることで常に足りないものを意識させる」、もう一つは「敵の成長と自分の成長のレースによる成長欲求」、そして「敵がマップの背後から進軍をしてきて、それがマップ上で可視化されることによる恐怖」によって、時間的空間的な飢えとピンチを感じるということであると言うことがわかった。私は実際に再現をしてみることによって、そのことに気がついた。
MDAフレームワークでまとめてみると以下の構造になる。
A：「緊張感・飢餓感を探索をすることによって解消したいと思う」
D：「敵軍が背後からマップ全域に広がりながら迫ることによって、探索領域が狭まる」「敵と交戦することによって部品が壊れ、各種リソースが失われることによる制限」
M：「敵軍が背後から可視化されながら迫ってくる仕様」「敵とリソース、成長の綿密なバランスによって常に少し足りないこと」
このように、ローグライクではあるものの、満腹度のような飢餓体感を別の形で再現していることがわかる。ただ、このシステムは導入するとFTLそのものになってしまうため、最終的にはボツになった。
自分とは異なるユーザーセグメント、Not for meを理解する
UXは万人にとって面白いと感じる普遍的なものもあるが、特定のユーザーセグメント（ユーザーのまとまり）に刺さるUXというものはある。誰でも自分がプレイしてみたら微妙だったのに、レビューは大絶賛というゲームに覚えがあるだろう。これは、ステマということもあるだろうが、大抵は自分の好みと違うものだった、Not for me（自分向けじゃない）ということだろう。
UXを分解・構造化して言語化できたら、次は客観的なUXの理解である。このユーザーセグメントにはこのUXが刺さる、このユーザーセグメントにはこれは刺さらないといった情報を収集し学習するのである。こうすることで、自分以外の人の体験を自分に置き換えて理解をすることができる。
ユーザーセグメントの分類例をいくつか紹介する。まずはこのnoteで何度か紹介しているMtGのティミー、ジョニー、スパイクだ。
この分類は割とどんなゲームにも使えるので、私はよく使っている。今作っているゲームも、ティミー向け、ジョニー向け、スパイク向けのコンテンツをそれぞれ組み込むというようなことをしている。
次は、ソーシャルゲームのユーザ分類で使われるアチーバー、エクスプローラー、ソーシャライザー、キラーだ。
これもよく聞く分類だろう、ただこの分類はソーシャルゲーム初期のものなので、コンシューマゲームとの境界が曖昧となった今日では少々使いにくい。
Googleが分類をした、社交性とパッションの２軸、４分類もある。
これは、ゲーマーが見落とす、そこまでやる気がたくさんあるわけではないユーザーというのも含めての分類となっている。ゲームディレクターはゲームに対する情熱にあふれているため、「ゲームに興味がない人」という存在を見落としてしまうのだ。
そして、最後にスパ帝のゲーム民族論だ。
こちらは、ソーシャリティの部分は考慮に含まれていないが、どういうメンタリティのプレイヤーがいるのかという視点でとてもよくできている。
多くのゲームディレクターは自分の作っているゲームを「プレイヤーに提示するフェアな課題である」と捉えがちである。気づいたら作っているゲームの競技性がどんどん上がっていくのだ。これは意思決定民族に特有の考え方だ。
しかし、意思決定民族はそこまで多くはない。マジョリティは管理民族やロボット民族なのである。プレイヤーを褒めてあげよう。我々は競技ではなくエンターテイメントを売っているのだ。
このようなユーザーセグメント論を理解し、実際にユーザーに話しを聞いて、自分との違い、その人だったらどんなことを感じどう動くのかというのを理解していくことで、いろいろなゲームを作ることができるようになる。
ターゲットセグメントを明らかにすることでチームを強化する
ディレクターといえども、自分自身がターゲットであることは多くはない。また、ターゲットセグメントの言語化を行わないと、チームの中で共有が出来ず、なんだかよくわからないけどよくわからないターゲットに向かって作っているという状態になる。チームメンバーからしてみても「自分が面白いと思えないクソゲーを開発している」という認識になるので、チーム崩壊秒読みである。
また、ディレクター自身がターゲットセグメントであった場合は特に注意しなくてはいけない。ディレクターはただでさえチームの中で権力を持つのに、ターゲットセグメントのユーザがどう思うのか？というユーザ評価までをも独占してしまうと、ディレクターが言っていることが全て正しいという独裁国家になってしまう。これを防ぐためにも、ターゲットセグメントの言語化を行い、どういうUXを求めているのか、どういうUXが嫌いなのかというのを言語化・可視化・共有し、分権化し、チームメンバーが自分自身で意思決定できるように自律化することが求められる。
私は、２本目のゲームを作っているときに、「自分はマイノリティじゃん！」と気がついてしまった。なのでその後は、チームの人、会社の人、新しく会った人ととにかくどういうUXが好みでどういうUXが苦手なのか、どういう考え方でどんなゲーム・どんな趣味をしているのかというのをもう７年以上ヒヤリングし続けている。私のチームに入った人は知っているだろうが、なんでそんなに聞くの？というくらいに聞く。
そして、その知見を使って、私は独自のセグメントモデルを作った。そしてそのモデルを使って、更に質問などをしていき精度を上げていった。今回は、このモデル自体の話ではないので記載はしない。ただ、人によって、同じ言葉や行動でも意味や価値がちがい、全く違う世界観の中をあたかも共通化された認識の中で生きているということがわかった。インターネットで世界はつながったが、価値観はつながっていない。
よいプロデューサーは何をしているのか？
プロデューサーとディレクターは、どのようなゲームをつくるのかを話し合う。ここで、どのような話をするのかでゲームは決まる。
だが、MDAフレームワークを学習したり、ユーザーセグメントを学習すると分かるように、「どんなゲーム」というのは表現すること自体が難しい。同じタイトルを引き合いに出しても、見え方はユーザーによって違うのだ。プロデューサーとディレクターの間でも、面白さの評価が違っていたりすることがままある。
私が考える良いプロデューサーは、ユーザーセグメントとアセスティクスを指定し、それを実現するためのダイナミクスの例示を行う。そして、ディレクターはダイナミクスを実現するためのメカニクスを構築するのが仕事となる。ただ、現実ではそう簡単には行かないことが多い。
プロデューサーなのにユーザーセグメントやアセスティクスを指定しなかったり、仕様（メカニクス）＝なにかのコピーを指定したりするケースが多々ある。また、ディレクターなのにメカニクスは再現するが、ダイナミクスやアセスティクスを再現出来なかったりするといった、悲劇はよくある。
こういった環境では、どういうユーザーセグメントにとって何が面白いのか全くデザインされていないのに、ゲームシステムは何かのゲームにそっくりというモノが出来上がり、売上的には大爆死する。これが副題である「クソゲーが生まれてしまう原因」である。
こうした悲劇が起きないようにするために、相互に学習や何をベースに話をしているのかの話し合いをするのが良いだろう。現実では、会社間の関係性や、お金を出している方が偉いといった不均衡が発生しており、それによっていつまでも是正されないのが悲劇ではある。しかし、この不均衡のまま放置しても相互に誰も得をしないため、踏み越えた話が必要とされるだろう。
まとめ
・言葉を知らないと認識・表現ができないのでなるべく知る
・知らない言葉は表現ができない
・知らない概念は認識ができない
・言葉を知ることで、その言葉を知っている人の間では円滑に情報伝達が行えるようになる
・単体のUXを言語化する訓練を行う
・ミニマムなゲームでUX評価を行うのがよい
・UXをMDAフレームワークで分解して認識してみる
・分解し構造化することで、何がどうなっているのかを認識できるようになる
・ユーザーによって求めるUX、嫌いなUXは違う
・Not for meを理解する
・ユーザーセグメントを認識して、どのユーザーにとってどんなUXがどうなのかを認知していこう
・プロデューサーとディレクターの間も、ゲームの言語化が必要である
・自由に話し合えない関係性はクソゲーという悲劇を生むので、回避しよう
この記事を書いたあとで、ディレクターはゲームから、ゲームをプレイする人間や人類に興味を広げたほうが良いという話を書いていることに気がついた。ゲームを作る人はゲームが好きすぎて、いろいろなゲームに詳しくなれば面白いゲームが作れるように考えていることが多いが、プレイする人間側を知らないと「多くの人にとっての面白い」が作れないと思う。
UXが人に依存関係がある以上、UXの言語化には人間の言語化が必要となる。矛盾をするような話ではあるが、ゲームだけに興味がありすぎる人は逆に商業ゲームのディレクターに向いていない可能性はある。ゲーム大手がゲームマニアを採用しないという理由はこういうことかと思う。ディレクターになりたい人は、ゲームだけではなくプレイするユーザーの方にも目を向けたほうがより面白いゲームが作れるようになるのではないだろうか。
記事が面白かったら、シェア、コメントやtwitterアカウントなどをフォローなどしてもらえるとありがたい。
参考記事
私はいくつかディレクター関連の記事を書いているので、この記事が面白かった方はこちらも見ていただくと面白いと思う。学習順に並べておく。
以下作ってるゲームの宣伝です。
DIMENSION REIGN大型アップデート＆セールのお知らせ
現在アーリーアクセス中のDRで、待望の大型アップデート（ダンジョン追加）しました！あとGWセールがはじまりました！
オートマトンさんが記事を書いてくれました。DRはこんなゲームだそうです！
『DIMENSION REIGN』は、ScopeNextが開発中のデッキ構築型ローグライトRPGである。プレイヤーは、それぞれ特徴の異なる2人組の主人公エッジとカミーラを操作。ダンジョンの最奥に待つボスを目指し、多数のモンスターと戦いを繰り広げていく。本作の特徴は、ゲージの破壊によって追加ターンがもらえるブレイクチェイン攻撃にある。本作では、通常1回か2回程度主人公側が行動すると、敵にターンが回ってしまう。モンスターは数が多く、エッジとカミーラの防御手段は限られているため、無策でターンを回してしまうのは危険だ。そこでモンスターを倒すか、HPゲージを1本削り切ってゲージを破壊し、追加ターンを発生させる。
今回の大型アップデートにて、EXダンジョンを追加しました！！試練のお守りというメリデメのある新要素がはいって、今まで以上にピーキーな体験ができるようになっています！今までのダンジョンだけでは物足りない方、ちょっと違うパズルをときたい方にはオススメです！今後もさらにたくさんのアップデートを考えておりますので、ぜひ買ってプレイしてもらえると嬉しいです！レビューは、ツイッターやDiscordに書いてもらえるとありがたいです！
GWセールが始まりましたので現在20％OFFで販売しています！この機会に是非どうぞプレイしてみてください！
記事を読んでいただいてありがとうございます！ 良かったらサポートしていただけると大変嬉しいです。