ゲームデザイン力を飛躍的に向上させる「実用的な言語化」のやり方
「言語化」って大事だよね、という話はよく聞くんですけどね。
言語化って大事だよなー！できるようになりたいなー！
よーし、言語化できるようになるぞ！！
↓
何すれば良いの……
どうすれば良い言語化って言えるの……
って状態になったことのある人、いるんじゃないですかね？
そしてなぁなぁの内に言語化の存在を忘れて……というのが、黄金パターンだと思ってます。
この「言語化」って言葉、すんごいフワッとした言葉なんですよ。まず明確な定義がありません。皮肉なことに「言語化」という言葉自体がまともに「言語化」されていなかったりします。愉快な話です。
フワッとした言葉をフワッと扱うとフワッとした記事にしかならないので、この記事ではですね。
・言語化を使いこなして、ゲームデザイン能力（思考能力）を上げる
ことを目的に、
・言語化を使いこなすメリットは何か？
・何をすれば「良い言語化」になるのか
・どういう仕組みで「良い言語化」が役に立つのか
というのを明確にして、このフワッとした「言語化」とやらを扱えるようにします。そして
・なぜこのゲームは面白いのか？
・なんでこのＵＩだと分かりにくいのか？
・どうしてこのゲーム仕様にすると面白くなるのか？
といったような事をちゃーんと言葉で説明できるようになる…のが目標に書いこうかなーと思います。
◆言語化が何の役に立つ？
一応この記事、「ゲームデザイン力を飛躍的に向上させる」なんて事を謳っているわけですが。ちょっと具体的に表現するとですね。以下のような形で役に立ちます。
①ゲームの「分析」が正確になる
・自分の作ったゲームの改善点を見つけて修正する力が上がる
・他のゲームへの分析力が上がり、学べることが増える
②より「的確」にゲームの仕様を考えられるようになる
・「作りたい面白さ」を実現する能力が上がる
・「作ってみなきゃわかんねーよ！ガハハ！！」から卒業できる（少ない試行回数で面白いゲームが作れる）
③「より説得力のある話」ができ、上司やメンバーを説得しやすくなる
・「なぜこの仕様にした方が良いのか」がハッキリする
・これやった方が良いよね、というのが共有できれば納得感が出る
あとこの記事はゲームデザイナー向けに書いていますが、内容自体はあらゆる分野で共通している事だと思います。
なので、要は言語化ができると
より的確に物事を考えられるようになる
と思ってください。なんか壮大で書く自信が吹っ飛びそうですが、でもそういう事なのでこのまま書いていきます。まず初めに、言語化について知りましょう。
◆良い言語化ってなーんだ？
なんでしょうね。言語化って。文字通りに考えると
・言葉で表現する事
とかそんな感じになりますけど、「言葉で表現」すれば何でも
①ゲームの「分析」が正確になる
②より「的確」にゲームの仕様を考えられるようになる
③「より説得力のある話」ができ、上司やメンバーを説得しやすくなる
ができるかって言うと、違うじゃないですか。それだったら苦労しないし。
必要なのは良い言語化…つまり実用的な「使える言語化」なわけで。これになるには条件があるんですが、それが分からないと、冒頭で言った
何すれば良いの……
どうすれば良い言語化って言えるの……
と言う状態に陥ってしまいます。
っというわけで。この記事では、まず「使えない言語化」「使える言語化」の例から「言語化」って何って話を具体的にしていきます。
・
・
・
例えばこれ。
ゲームをリリースしたけど、ゲームの序盤で止めてしまう人が多い。
これはチュートリアルの説明不足が原因だ。
プレイヤーがゲームを理解できていないので、止めてしまう。
はい。これは『使えない言語化』です。言葉にはしましたが、起きてることに対してそれっぽい理由をつけた推測にしかすぎません。これに従ってゲームデザインを考えても、だいたいショボいものになります。
対して『使える言語化』の例はこう（内容自体は読み飛ばしても大丈夫）
ゲームをリリースしたけど、ゲームの序盤で止めてしまう人が多い。
これはチュートリアルの説明不足が原因だ。
プレイヤーがゲームを理解できていないため「面白くない」と感じて離脱が起きてしまっている。このゲームの面白さはシステムAとシステムBのが組み合わさって成立するが、今のチュートリアルではシステムBの説明がない。
システムBの説明不足によって、プレイヤーゲーム序盤でこのゲームの面白さに触れることができず、「これ以上遊ぶ価値はない」と判断して止めてしまう。
文字数が増えましたね。そう！実は言語化と言うのは非常に簡単！！文字数が多ければ「使える言語化」になるのです！！！
……嘘です。違いを見ていきましょう。
◆「使えない言語化」と「使える言語化」の違い
結論から言うと、「使えない言語化」と「使える言語化」の違いは、
この原因が『どうやって』その結果を引き起こすのか？
に対する「言語化の深さ」の違いです。もうちょっと正確に言うと、
使えない言語化 ⇒ 間接的な原因で説明している
使える言語化 ⇒ 直接的な原因を繋げて説明している
ですかね。（これから具体的に説明するので、とりあえず「ふーん」と思ってもらえればそれで大丈夫です）
まず言語化の「深さ」について説明するために、さっき出した例をちょっと整理しなおしましょうか。
A.結果
ゲームをリリースしたけど、ゲームの序盤で止めてしまう人が多い。
B.原因
チュートリアルの説明不足
C.具体的な流れ（掘り下げ）
①チュートリアルの説明不足によって、プレイヤーがゲームを理解できず止めてしまう。
これが、「掘り下げレベル1」の言語化です。レベル1なので雑魚です。
対して、『使える言語化』の例は掘り下げレベルが高くなります。
A.結果
ゲームをリリースしたけど、ゲームの序盤で止めてしまう人が多い。
B.原因
チュートリアルの説明不足
C.具体的な流れ（掘り下げ）
①プレイヤーが「面白くない」と感じて離脱が起きる
②「面白い」と感じるには、システムAとBの両方の理解が必要
③今のチュートリアルではシステムBの説明がなく、ゲーム序盤でこのゲームの面白さに触れることができていない
④その結果「これ以上遊ぶ価値はない」と判断して、止めてしまう
掘り下げレベル、4くらいですかね。より深く掘り下げています。
深く掘り下げるにあたって重要なのは、より段階を作って多くの項目で説明をする…ことではないです。もちろん。はい。重要なのは
原因 → 結果 までの流れを、「直接的な原因」で繋いで説明する
ことですね。この説明だと「直接的な原因」って何やねんって話になりますが、例えば、レベル１の例はですね。
原因：説明不足
⇒ プレイヤーがゲームを理解できない
⇒ ゲームを止める
という説明ですが、「理解できない」は「ゲームを止める」の直接的な原因にはなりません。
理解できないけど、とりあえずゲームを続けてみる人だっているじゃないですか。じゃあ続ける人と続けない人の違いはなーに？とか、別の疑問が色々と出てきます。
こうした「確かに何か関わりはありそうだし、一見筋は通っているけど、明確な繋がりを示せない」のが間接的な原因です。
そして「間接的な原因」と「結果」の間には、直接的な原因となる「何か」がいっぱいあるわけですが、言語化が浅いとその存在に気が付きません。
それに対し、深く掘り下げて言語化すれば、その「何か」を明確にできます。こんな感じ。
原因：説明不足
⇒ プレイヤーがゲームを理解できない
⇒ 理解できないと、面白くなるための前提条件が満たせない
⇒ 面白くならないので、つまらない
⇒ つまらないので、これ以上遊ぶ価値がないと判断する
⇒ ゲームを止める
1つ1つの項目で起きる事を繋いで、結果である「ゲームを止める」までに何が起きているのかを説明しています。これが「直接的な原因を繋ぐ」こと。
直接的な原因を明確にすると見えるのがありまして、例えば
これ説明不足を解消しても、（システムBが中盤の要素になってるとかで）ゲーム序盤で面白さの前提条件を満たせていなかったら意味ねーじゃん。
とか。逆に
説明不足で序盤は面白くなくても、何か期待をもたせて「もう少し遊べば面白くなるかも」って思わせることができたら、ゲーム止めないよね
とか。直接的な原因が明確になる事で色々と本質的な所が見えてきて、アプローチの幅が広がります。レベル１の雑魚は本質が見えません。故に雑魚。ざこざーこ。
◆どこまでやれば良い言語化なのか？
さて、以上の事を踏まえるとですね。冒頭に書いた
何すれば良いの……
どうすれば良い言語化って言えるの……
っていう嘆きに対する回答としては、
「間接的な原因」で説明せず、「直接的な原因」を繋いで説明する。
「直接的な原因」を繋いで、『どうやって』この結果を引き起こされるのか、が全て説明できていればOK。
が1つの基準として言えます。
はい。↑の説明でよく分からん！って人はですね。とにかく自分の言語化に対して疑問を持ちましょう。
・なんでこの仕様にするの？本当にこれでやりたいことが達成できる？
・この説明、直接的な話が出来ている？間接的な繋がりになってない？
を常に問いかけてください。
できればこう、上司とか超優秀な取引先から問いかけられるようなイメージで。ちゃんと答えられないなら、相手を説得できそうにないなら、まだ言語化が弱いです。
「ちゃんと答えられるぜフフン」と思えるなら、いいんじゃないですかね。とりあえずは。
※おまけ
似たような話に、オヂサン達が大好きな「なぜなぜ分析」というのがあります。5回「なぜ？」と問いかけて問題点を明確にするやつ。
ただ、言語化にあたって5回も「なぜ？」を繰り返すのを私は推奨しません。いっぱい問いかけることを前提にすると1回の言語化の質が落ちるので。
できるだけ「一撃で最高の言語化をキメる」のが理想…というか、実戦的です。会議で上司とバトる時とか。でも問いには手を抜かないように。
◆ゲームデザイン（仕様を考える）時の言語化
これまで話してきた例は、主に
①ゲームの「分析」が正確になる
・自分の作ったゲームの改善点を見つけて修正する力が上がる
・他のゲームへの分析力が上がり、学べることが増える
の話でしたが、こっちの言語化の例もせっかくなので置いておきます。
②より「的確」にゲームの仕様を考えられるようになる
・「作りたい面白さ」を実現する能力が上がる
・「作ってみなきゃわかんねーよ！ガハハ！！」から卒業できる（少ない試行回数で面白いゲームが作れる）
まず、分析的な言語化では、
◆分析をする際の言語化
A. 結果から（プレイヤーが序盤でゲームを止めちゃう）
↓
B. 原因を推測して（チュートリアルの説明不足）
↓
C. 原因が結果を作る具体的な流れを言葉にする
という形でした。AとBだけじゃダメで、使える言語化をするにはCまでやらないといけない。
これはゲームの仕様を考える時も基本は同じです。つまり、
◆仕様を考える時の言語化
A. 作りたい結果（プレイヤーの感情、体験）を決めて
↓
B. その結果を作るための原因（達成するための仮説）を考えて
↓
C. その仕様がどうやって作りたい結果を作るのか言葉にする（実際の仕様）
って形ですね。言語化としての基本形は変わらないです。
実際の設計例を出しましょうか。私が今作っているゲームブック風マルチエンディングRPG『いのちのつかいかた』の設計の一部です。
◆A. やりたいこと
マルチエンディングなので、「周回」しても楽しくなるようにしたい。（周回が飽きる、つまらないマルチエンディングは地獄）
◆B. やりたいことをするのに必要なこと（仮説）
周回が飽きる、つまらないのは、同じことを何度も繰り返すのが分かって単純作業感が出てしまうから。逆に言えば、周回の度に違う展開、違う内容の体験ができるなら周回も楽しくなる。
◆C. 実際にやる事（仕様）
周回ごとに別の体験を作りたい。まずゲームブック風のシステムを採用し「キャラを動かして進める」のではなく「イベントを選択し、イベントをクリアしながら進める」という形にする。
↓
1つのイベントに対して複数の選択肢（攻略法）を用意して、同じイベントに対して異なる展開を用意する。
更に、一部の選択肢にTRPG的な成功/失敗判定をいれて、同じ選択肢でも判定結果によって内容が変わるようにする。
↓
こうすることで周回するごとに別の展開・体験を作り出し、プレイヤーに「今回はこの選択肢を選んだけど、別の選択をしたらどうなっていたんだろう？」と思わせることができれば、周回を飽きずに楽しんでもらえる。
※イベントに対する選択肢
※TRPG的な成功/失敗判定
説明用に省いたところもありますが、こんな感じですかね。これくらいのレベルで言語化できていると仕様の成功率も高くなります。
「間接的な原因」だけで考えると、その仕様が本当に目的の結果を作れるのか曖昧で不確かです。しかし「直接的な原因」を繋げて
・考えた仕様が、「何に対して」「どんな作用」をするのか
・その仕様がプレイヤーにどんな影響を与えるのか
・その結果、どんな体験が作れるのか
といった道筋まで作れれば曖昧な部分が消えるので、達成したい事が実現しやすい……という感じですね。
実際に例に出したゲームでは、上記の仮説通りにしっかり作った結果、GameVketというイベントで体験版を実況してくれた方から
配信させていただきましてありがとうございました！
— わたあめ子🍭Vtuber (@wata_ame_ko) May 2, 2021
選択は影響しつつ自分の力だけではどうにもならない所が、緊張感や｢もう一度遊びたい｣を生む素敵なゲームでした！
体験版すべてをご紹介できなかったので、また個人的にも配信したいくらい面白かったです！
という感想を引き出しています。「もう一度遊びたい」ですって。へへへ。いいでしょ（自慢）
とはいっても全ての仕様が、言語化していれば上手くいくわけではありません。100%の成功率は無理です。
しかし、言語化していると失敗した時の原因を探りやすくなります。例えば
2週目やってみたけど飽きるわ！周回しようとするとつまらんわ！
となった時に、これが
こんな仕様を考えてみたぞ！
きっとこの仕様なら面白くなるぞ！！
ってレベルで設計されていると、面白くならなかった時にどうすればいいのか、手がかりがありません。「試してみたけどダメだったわ！ガハハ！！」みたいな。
しかし言語化できていると、仮説を言葉に残してあるので、以下の2つを考えるだけで済みます。
①前提となる体験が作れていたか？
周回の度に違う展開、違う内容の体験を、本当に用意出来ていたか？
「今回はこの選択肢を選んだけど、別の選択をしたらどうなっていたんだろう？」と思わせる事ができていたか？
②仮説自体が間違っているか？
周回の度に違う展開、違う内容の体験を用意した所で、周回は面白くならないか？
①がクリアできていないなら、その体験をつくれるように改善すれば良い。①がクリアできているなら②の仮説自体が怪しいので、ぱっぱと違うアプローチを考えた方が良い。
こんな感じで「問題の切り分け」がしやすくなるので、修正が容易になります。つまり、言語化ができると考えた仕様の成功率が高くなる上に、失敗から学べる事も多く、失敗した時のリカバリーもしやすい。素晴らしいですね。更には彼女もでき・・・ン゛ッ。
…なので、言語化がちゃんとできると
②より「的確」にゲームの仕様を考えられるようになる
・「作りたい面白さ」を実現する能力が上がる
・「作ってみなきゃわかんねーよ！ガハハ！！」から卒業できる（少ない試行回数で面白いゲームが作れる）
も達成できるようになるわけです。はい。
◆言語化と説得力の話
ついでに
③「より説得力のある話」ができ、上司やメンバーを説得しやすくなる
・「なぜこの仕様にした方が良いのか」がハッキリする
・これやった方が良いよね、というのが共有できれば納得感が出る
について。
これまでも例を使って説明してきましたが、例えばコレと
原因：説明不足
⇒ プレイヤーがゲームを理解できない
⇒ ゲームを止める
コレだと
原因：説明不足
⇒ プレイヤーがゲームを理解できない
⇒ 理解できないと、面白くなるための前提条件が満たせない
⇒ 面白くならないので、つまらない
⇒ つまらないので、これ以上遊ぶ価値がないと判断する
⇒ ゲームを止める
説得力が全然違うのは、分かってもらえるんじゃないかなーと思います。
間接的な説明だと「そうかもしれない、そうじゃないかもしれない」みたく曖昧な形になりますが、直接的な説明だとより具体的な流れが提示されていて、話の内容に実感が湧きやすいです。
チームで作る上では、この説得力や実感はとても大事で、
・この仕様を入れると、入れると面白くなるから、頑張って作ろうぜ！
って言われたときに
・本当にそれで面白くなるのか？
と思われるのと、
・確かにそれやると面白くなりそうだなぁ！
と思われるのでは、それに関わる人たちのモチベーションは違います。
なので、ちゃんと良い言語化ができると
③「より説得力のある話」ができ、上司やメンバーを説得しやすくなる
・「なぜこの仕様にした方が良いのか」がハッキリする
・これやった方が良いよね、というのが共有できれば納得感が出る
が達成できるわけです。プランナーやディレクターは特に大事な能力ですね。
◆より言語化ができるようになるためのトレーニング
さて、最後に
・どーすれば、もっと言語化が上手くできるようになるんだべぇー
と言う話。
正直に言えば、「これさえ覚えれば言語化なんて楽勝だぜ」みたいな『うるとら言語化テクニック』はありません（誰か知ってたら記事を書いてください）
考え方とか仕組みは色々と説明してきましたが、言語化の精度自体は言語化を繰り返さないと上がらないです。運動しないと筋肉がつかないのと一緒。
なので、ぶっちゃけあとはひたすら反復だと思います。
つまるところ、ゲームで言えば
①他人のゲームを遊びながら、ひたすら分析して言語化しまくる
②色々なゲームデザインに対して思考を巡らしその特徴について言語化する
③自分の作るほぼ全ての仕様を明確に言語化した上で、多くのゲームを作る
とかですね。私は
①はゲームデザインのレビュー記事
②はゲームデザイン論
③は仕事や個人のゲーム制作
という形で全部やってます。（言語化のためにやっているわけではありませんけど）この記事もその一環ですかね。
もちろん、ゲーム以外にも漫画やアニメ、スポーツなどあらゆる事象に対して言語化を心がけると良いとのですが…まぁ、疲れない範囲で。
ちなみに①のサンプルですが、私はこういうの書いてます。
あとは言語化のトレーニング、理想を言えば
・他人（できれば言語化が得意な人）に、ちゃんと言語化ができているか見てもらう
のが良いかなーと思います。私が会社でゲームデザインを教えていた時は徹底的にコレをやっていました。
中々、言語化が得意な人はいないのかもしれないですけどね。アレだったら、私にお金を積めばやりますよ。HAHAHAHAHA。
◆まとめ
今回の話をまとめます。
◆言語化のメリット
①ゲームの「分析」が正確になる
②より「的確」にゲームの仕様を考えられるようになる
③「より説得力のある話」ができ、上司やメンバーを説得しやすくなる
↓
より的確に物事を考えられるようになる
◆良い言語化って？
「言葉で表現する」だけで良い言語化になるわけじゃないよね
必要なのは実用的な「使える言語化」
◆「使えない言語化」と「使える言語化」の違い
この原因が『どうやって』この結果を引き起こすのか？
に対する言語化の「深さ」が違う
↓
使えない言語化 ⇒ 間接的な原因で説明している
使える言語化 ⇒ 直接的な原因を繋げて説明している
↓
間接的な原因は、結果に明確な繋がりが無く曖昧
間接的な原因と結果の間にある「直接的な原因」を言語化できていない
↓
掘り下げて「直接的な原因」を言語化できると本質的な部分が見え始める
そうすれば話に説得力も出てくるし、考えられるアプローチも増える
◆どこまでやれば良い言語化なのか？
「間接的な原因」で説明せず、「直接的な原因」を繋いで説明する。
「直接的な原因」を繋いで、『どうやって』この結果を引き起こされるのか、が全て説明できていればOK。
↓
とにかく自分の言語化に疑問を持つことが重要
・なんでこの仕様にするの？本当にこれでやりたいことが達成できる？
・この説明、直接的な話が出来ている？間接的な繋がりになってない？
ちゃんと答えられるか、相手を説得できそうか？
↓
問いを繰り返すよりも、一撃で言語化をキメるのが理想。
でも問い自体を甘くしちゃダメ。
◆ゲームデザイン（仕様を考える）時の言語化
A. 作りたい結果（プレイヤーの感情、体験）を決めて
B. その結果を作るための原因（達成するための仮説）を考えて
C. その仕様がどうやって作りたい結果を作るのか言葉にする（実際の仕様）
↓
ちゃんと言語化できていると、考えた仕様の成功率も高くなる
失敗した時も、言語化で来ていると対策を打ちやすい
◆言語化と説得力の話
・具体的な流れが提示されると、話に説得力や実感が生まれる
・「これやろうぜ！」と言った時に、説得力や実感があるとモチベが上がる
◆より言語化ができるようになるためのトレーニング
「これさえ覚えれば言語化なんて楽勝だぜ」のは、ない
言語化の精度自体は言語化を繰り返さないと上がらない
↓
①他人のゲームを遊びながら、ひたすら分析して言語化しまくる
②色々なゲームデザインに対して思考を巡らしその特徴について言語化する
③自分の作るほぼ全ての仕様を明確に言語化した上で、多くのゲームを作る
とかやってれば能力は上がってくると思いまする
↓
言語化が得意な人に、ちゃんと言語化ができているか見てもらうのが理想
だいぶ語りましたね。
今回は
・言語化を使いこなして、ゲームデザイン能力（思考能力）を上げる
を軸に言語化のやり方を書いたので、だいぶ偏った話になったなぁとは思います。まぁ、こういう考え方もあるということで。参考になれば幸いです。
◆宣伝
例に出したゲームですが、Steamで体験版を配信中です。
ゲームデザインに関する話はこれ以外にも ↓ のマガジンで色々書いてます。例えば
・ゲーム開発者が知っておくと良い最低限のデバッグ知識
・『素材を集めて装備を作る』が『探索の面白さ』を殺す
・『天穂のサクナヒメ』から学ぶ、単純作業の楽しませ方
・心理学界の異端児「行動分析学」から考えるゲームデザイン
などなど。興味ある方は読んでみてクダサイ。
いいなと思ったら応援しよう！
