前回の記事では、ディレクターの戦いとなる不確実性と不安との戦いの話を書いた。今回はその対処法を書いていきたいと思う。

前回の話の流れだと、ディレクターが「無慈悲にも面白くなる判断」をして、あたかも予算とスケジュールを追加することが正義であるかのように感じただろう。

だが現実には、よほど過去の成果や権限を持っていない限り、予算もスケジュールも伸ばすことは出来ない。出来て１ヶ月程度だろう。

誰が見ても全くおもしろくなくてバグが多くて売れなそうな場合のみ、自分の評価を下げながら３ヶ月や半年スケジュールが伸びる。ただ評価が下がるため、プロダクトに対しての自己コントロール率は下がり、うまくいくかどうかは、他人任せになってしまう。

ゲームづくりに対して理解がある経営層がたまにいるが、残念ながら稀である。理由は簡単で、ゲーム作りは成功率が低いため、挑戦しないで人の失敗を指摘する人が上に行きやすいという悲しい現実がある。また過去に開発者だった経営者も３年程度現場を離れるとかなりの確率で認識がうまくいかなくなる。ゲームも世代が変わり、ハードウェアが変わり、プレイヤーの世代が変わり、マジョリティが変わるからである。

なので、現実には決められたスケジュールと予算の範囲でより面白いものを作るために戦わざるを得ない。ではどうやって、この縛られた状況の中で戦えばよいのだろうか？という方法論を書いていきたいと思う。そして、私がどのようなアプローチでこの不確実性に対して立ち向かっているかを紹介する。

私の過去の戦場はモバイルゲームであり、コンシュマーでは重視する指標が変わると思われる。各自変換してもらえると良いかと思う。

面白さの探索と不安との戦い

戦いの初期条件として、経営層からのオーダーがある。それは例えば、続編で手堅く当てるだったり、版権モノでアニメ放映に合わせてキャラゲーを作って欲しいだったり、オリジナルで一山当ててほしいだったりする。それによって、適切な方法論がある。

全ての方法論は、全ての場合に使えるわけではない。また、オーダーによって回答は異なる。なので、問題に合わせた回答法を探してほしい。

また、チームの不安への対処だが、オーダーや座組に依存することが多く、この条件が違うと、ゴールとなる条件も変わる。例えば他のメディアと連動企画だったりすると、タイミングを合わせるが至上命題となり、遅れると契約上のペナルティが発生する場合もあったりする。なので、多少面白くなく、売れなくても最悪ではないという意味で許容されたりする。

不安＝不確実性をコントロールするためにプロジェクトは組成される。そして、不確実性をどのようにコントロールするかで、プロジェクトの形態は変わる。今回はいくつかのプロジェクト組成の仕方を元に、不確実性や不安をどのようにコントロールするかを見てみよう。

完全受託でIP（版権）モノ、システムは有名ゲームコピー案件

一番不確実性が少ないガチガチ案件からいってみよう。これは、会社的には全力で失敗したくないと言っている。失敗なしに、メンバー分の食い扶持を稼ぎたい、メンバー的にはゲームづくりの知見が貯まり、Lvが上がって将来のオリジナルや、もっと条件のよいタイトルで一発当てられるかもしれないという感じである。

ゲームづくりビジネスは、失敗率が異様に高い。ブランドのない中小企業で自社案件でリクープ（損益分岐）に届けるのはかなりの難易度と確率である。なので、受託案件で安定して収益を稼ぎつつ、本気で社運を掛けるものを作るのに伏して待つという感じだ。そのための方法論として、受託ゲーム開発がある。リクープ後にレベニュー（売上分配）がある程度以上ある場合は、面白くて売れるゲームを作る経済的合理性があるが、そうでない場合は、ゲームもどきを期限内に作るのが最適解になってしまう。当然、発注側はゲームもどきを検収拒絶するので、揉めるわけだが。

わざわざゲームもどきを作ろうと思わずに作ったとしても、普通に作るとスケジュール内でできるのはゲームもどきだったりする。そして、一番簡単な検収を通す方法は、ビジュアルとエフェクトだけ盛る方法である。ビジュアル、エフェクトを盛ると、最初の数十分だけ認識負荷が上がり、フローに入ったり、見た目で高品質に見えたりするのだ。そして今日も見た目だけゲームもどきが作られていく。

発注側の視点をMDAフレームワークを使って説明してみよう。発注側からするとゲームはメカニクス（仕様）の塊に見える。だから、仕様どおりメカニクスをコピーすれば、そこそこのゲームができるだろうと考える。ただ、ゲームの本質はメカニクスから出てきたダイナミクス（現象）、そこから発生するアセスティックス（感情）が本質であり、これはコピーであろうとフレーム単位でチェックして作らない限りコピーは難しい。

そしてアセスティックス（感情）を実現しようとしたときに、メカニクス（仕様）だけを作ったときと比べてどれくらいコストが掛かるのか？私の感覚的には、3～10倍程度かかる。なので、よほど運がよくクリティカル連発するか、すごくモチベーションが高く練度が高い開発でない限り、ゲームもどきが出来上がる。

もちろん、ゲームもどきは売れないのは、発注側も１００も承知である。なので、場外乱闘が始まる。つまり、メカニクス(仕様)を作れと言って発注をしたのだけど、アセスティックス（感情）が無いのは、コピー度が足りないから、品質が足りないからだと言って、追加開発を契約内に押し込んで来るわけだ。当然スケジュール維持、予算維持である。これが開発の終盤に超高確率で発生する。当然開発チームはデスマーチで死ぬ。

これでもマシな方で、残念ながら発注元はゲーム開発に詳しくない。発注担当者はゲーム開発の知っているレベルはユーザーとそんなに変わらないが、自分はゲームのプロだと考えている。

面白くないゲームにいちゃもんを付けるのはユーザーでも簡単だ。「このゲーム面白くないです。こんな（有名な、流行っている、自分の好きな）ゲームのこのシステムを入れれば面白くなるんじゃないですか？あなた達が不甲斐ないからこんなに面白くないゲームになってしまったので、このシステム入れてください」というパターンが本当に死ぬ。当然システムを入れても面白くならないし、これをスケジュールの限界まで繰り返す。

受託開発での各プレイヤーの思惑は次の通りであり、それぞれの思惑がずれていることが分かる。

・ディレクター：面白いゲームを作りたい
・経営層：納期までに完成させて、既定額の開発費を支払ってほしい
・発注側：売れるゲームを作って欲しい。追加のお金は理由をつけて払いたくない

こういった受託案件をうまく回すためには、スタートアップで、この案件をうまくいかせないと死ぬといった、よほど高いモチベーションか、どんな条件だろうと最高のゲームを作る！といったプライドだけでの開発でない限り、面白いゲームにまでたどり着くことはかなり難しい。ただし、経営者側からみると悪意なく安定収益でメンバーのレベリング（開発実績を積む）ができるぞと考えてしまうのだ。それぐらいに対比としての、自社単独開発オリジナルは厳しい。

開発者から言うと、企画の自由度は低く、作るものは決まっており、よほど変な企画がやってこない限りそこまで不安になるようなものではない。逆に言うと、経営者側の判断で不確実性を大幅に潰したとも言える。ただ、その反面、自由度が少なくなるため、面白さへの本質のアプローチは難しい。そして受託慣れしてしまうと、最適解は発注者とのうまい握り方みたいになるのでオリジナルゲームは作れなくなる。自由度と不安度が違いすぎるためだ。

また発注側の件で書いたように、一番のリスクは契約と発注者の（言外の）クオリティイメージである。ここを握り損ねると、かなりの確率で死ぬ。開発は蚊帳の外で、無限にデスマーチをすることになる。

また、チーム編成としては、デスマ耐性のためにトップダウンを敷くことが多く、多くの場合炎上特化型のPM（中小では社長がその場合が多い）が、なんとかどうにかすることが多い。しかしデスマを繰り返すと、まともな人材は流出をし、タイトルが失敗すると、次の受託は来ないためつらい。安定した受託開発でチームレベリングとは何だったのかという感じである。

受託案件に関して言えば、先程述べたように、交渉が得意なタイプや、人に好かれやすいタイプに関しては上手くいくことが多い。一方クリエイタータイプは受託案件のディレクターにあまり向いてない。

受託開発のメリデメをまとめると次のようになる。

開発者：作るものが決まっていて安心、オリジナルのモノが作れない
経営者：安定収益と開発者の育成
発注元：決まった開発費で、確実な納期で、安定的な売り上げ
結果として起きること：　安定した売り上げ、クソゲーの量産、デスマ、開発者の離反

自社開発で、IP（版権）モノかオリジナル、システムは売れてるゲームのカスタム案件

次は不確実性が中間くらいの程々のものを書いてみよう。

程々の資金力があり、大手では無いものの、そこそこのヒットを持っていたりする会社は、自社開発、自社パブリッシングが選択できる。そこそこのIP（版権）を持ってきて、ビックヒットを狙ったりする。または自社の得意ジャンルでオリジナルを作ってヒットを狙ったりする。その時の作り方を書いてみよう。

ちなみにこの開発ができる時点で現状では、上場しているか、上場はしていないもののそこそこうまくやっている開発会社である。既に４月なので時既に遅しだが、入る会社はよく考えたほうがいい。

会社としては、ヒットをコンスタントに作って欲しいか、あわよくば大ヒットを狙いたいというかんじだ。

受託ではなく、自社開発である意味は大きい。理由は簡単で、おもしろい売れるゲームを作るというモチベーションが開発、経営層とも一致するためである。ここがずれていると、すり合わせだけで膨大なコストを払うことになる。開発者は、ここのズレに絶望して会社を去る。これは構造的な問題であり、哲学がどうとかゲームが好きだとかすら吹き飛ばす問題だ。なので、わかっている会社は、必ずここを一致させる。

自社開発における各プレイヤーの思惑は次のとおり一致している。

・ディレクター：面白いゲームを作りたい
・経営層：面白いゲームで大儲けしたい

これくらいの案件だとそれなりの自由度があるので、ゲームの内容は会社の文化や、ディレクターの趣味やメンバーによって決まる。作り方としてガチガチのウォーターフォールで作ることもできるし、アジャイルで柔らかくいこうということもできる。

余談「天才」の仕組み

こういった自社開発の組織ではしばしば「天才」が生まれる。「天才」は、面白いゲームにするための理不尽を吸収するために生まれる。私達はわからないけど、あの人がこういっているから、そのとおりに動こう。理解や共感できない納得感を、あの人はすごいからで麻痺させるために使う。

前回の記事でも話した通り、ゲーム開発の現場における、一人でゲームが作れる開発者というのは意外にも少ない。未完成のゲームを遊びながら、完成時点のUXを想像することができる人も極めて限られている。そのためチームの多くのメンバーにとって、開発期間の大部分はクソゲーを触り続けることになる。そして、メンバーは不安になり、チームは崩壊の危機に瀕する。

そこで一部のベテランの開発者は、自分たちのゲームを遊びながら「開発者の視点」と「消費者の視点」を交互に入れ替えて観察することで、As-isとTo-beのギャップを見つけ出し、チームに進む方向を示す。そしてチームメンバーからは「天才」として崇められることになる。

「天才」とはそういった不安になるメンバーや、経営層からの要求で生まれる。まるで、神話で怪物を倒す英雄であるかのように扱われる。成功しているときはまだ良いが、百発百中というわけにはいかない。そういうときに、「信じていたのに」「アイツのせいで失敗した」と手のひらを返してくるのは、神話の時代から変わらない。

現実の理不尽を一手に引き受け、努力と根性で成功まで導いたにもかかわらず、失敗したときは全部お前のせいだと言われる。なかなか闇落ちしそうなUXである。

また現実で成功するために仕方なく「天才」のロールを引き受けたりするが、チームメンバーが盲信したり、意見を言わなくなったりと、特にボトムアップ組織では良いことがない。なので、本気で面白さの探索をするのであればあまりオススメはしない。

ただ、別の側面のメリットもあり、マーケティングやブランディングの側面では効果があったりする。有名どころでは高橋名人ってやつだ。高橋名人ほど戦略的に行うならいいが、そうでない場合は組織内と組織外をはっきりと区別して「天才」を扱わねば、「天才」として扱われるうちに、アルファ酔いをして、人格が壊れたりすることもあり、注意が必要だ。

自社開発で、世界観オリジナル、システムもオリジナル案件

次に、不確実性が一番多く、一番難易度の高い案件の例を書いておこう。

この形態は小さなカジュアルゲームとかでない限り、ものすごいお金と時間がかかる。よほど大きな会社の実験的な開発ラインか、チャレンジングな会社、または逆にインディーゲームのような給料を安くして、プライドだけでモノづくりをするといったチャレンジをしているところにしか出来ない。

作り方としては、トップダウンで無限回リテイクか、ガッツで無限に頑張るか、ボトムアップでチーム全体で探索である。どのやり方でもとにかく失敗する確率が高く、何度も作り直しをすることになる。そのため、いずれのチーム形態であっても、何度も作り直しをすることを厭わないチーム風土を醸成する必要がある。

マルチスキル人材の大量投入

マルチスキル人材とはこの記事で書いていた、第一世代の人のことだ。複数スキルを持ち、学習が抽象化されているため、新たな挑戦を厭わない。また先程の段落で書いていた「天才」も単にこのタイプで成果を上げただけの人である。マルチスキル人材同士でなくては経験値に基づく抽象的な議論が行えないため、他のマルチスキル人材がチームに存在しないと、「何を言っているか分からないが、正しいことを指示する人」となり「天才」として扱われるようになる。

「自社開発で、オリジナル、システムもオリジナル案件」に関しては、チーム内のマルチスキル人材の割合が、プロダクトの成否をかなりの割合で決めてしまう。

なのでチームのリーダークラスは全てマルチスキル人材で埋めてしまうくらいがよい。そして、そのチームの中のマルチスキル人材の割合がスクラップアンドビルドのサイクルに影響するため、プリプロダクションフェイズは3~7人程度の小さなチームのほうが良い。このようなチームだとゲームコンセプトの変更は、ゲームが面白くなるかだけで判定され、自分が作ったものがなくなるなど考えている人はいない。なぜなら、マルチスキル人材である彼らは成果物が評価される作業者なのではなく、成果物の売上によって評価される立場だからだ。

ただ経営層からみると、リーダークラスのマルチスキル人材を投入しまくるので、とにかくハイコストな上に時間がかかりリスクが高い。そのため、そういうチームはなかなか実現しないという問題がある。

そして、このチームでプリプロダクションとしてうまくゲームのコアが作れたら、メンバーを拡充して世界観や物量系を作ってゲームとする。プリプロダクションは失敗することも多くその時は、おとなしく諦めることが重要である。作ってしまったサンクコストで、捨てられなかったり、ビジュアルアート的なかっこよさだけで通ってしまうと、その後が悲惨だ。

また、自社開発オリジナルでなくてもチーム内にマルチスキル人材の割合が、プロダクトの成否をかなりの割合で決めてしまうことが多い。なぜ各社は、マルチスキル人材を育成しないのだろうか。

自社開発・世界観システムオリジナルにおける各プレイヤーの思惑は次のとおりである。ディレクターと経営層の間での利害が若干ズレてしまっている。そのため、このズレをいかに潰すかというのも同時に求められている。

・ディレクター：世の中にない新しいゲームを作りたい
・経営層：ハイリスクハイリターンなので、最初は小さく回さざるを得ない。社内のエース級をプリプロダクション開発に持っていかれるのでツライ

話は変わるが、かつて所属をしていた会社では、自分の職の領域外に手出し口出しすることでたしなめられたことがある。目的に対して達成できれば何でもいいじゃんと当時は思ったものだが、確かにマルチスキル人材は統制は取りにくくなる。

統制と良いプロダクトのどちらに比重を置くのかは、企業ごとの趣味ではあるので合わない企業だったなと思う。ただ、個人的には良いプロダクトに全振りで良いのではないかと考える。

なぜなら、良いプロダクトは運で作るものではなく、よいチームで作るものだと私は考えるからだ。では良いチームとはなんなのか？
私の回答は、「目的と現実をみんなで見ることができるタフなチーム」である。

なぜタフなチームが必要なのか？

今までのゲーム制作の話でさんざん書いている通り、売れる面白いゲーム作りをしようとすると、作り直しやコンセプトの変更、チームの組成などが必要になる。ただその方法は、目的を見ていない自分の作業だけを終わらせたい人にとっては苦痛でしか無い。

また逆の視点でみると、そういう売れる面白いゲームを作るのは難易度が高いからこそ、徹底的に行うことで市場での優位性が獲得できる。例えばアングリーバードを作ったRovioは、52作目でようやく成功した。

Angry Birdsのリリース直前にRovioは倒産寸前だったそうだ。

Rovioは最初の6年間で51ゲームを作ったが、まったくヒット作に恵まれなかった。Angry Birdsは52番目のゲームだが、いきなりヒットしたわけではないという。

「最初から成功するベンチャー企業なんてあるわけがない。その仕事が大好きであることと絶対できると信念を持つこと。Rovioが成功したのは、（まったく相手にされなかった）51ゲームを作っているときでも、この2つを心に持ち続けていたからだ」

Angry Birdsはリリース後15カ月間で1億ダウンロードを達成した。その後、Rovioはアニメスタジオを買収し、Angry Birdsのアニメ化にも着手している。現在はアニメ製作とキャラクターのライセンスビジネスも、収益の柱となっているという。

サクセスしたから良かったとはいえ、チームメンバーはヒヤヒヤだっただろう。５０人だった会社が最後は12人にまでなって、アングリーバードを出して成功をした。タフでないととてもじゃないがくぐり抜けられない。

また似たような話で、クラッシュオブクランやクラッシュロワイヤル、ブロスタなどを作ったSupercellも似たようなことを行っている。たった5本のゲームで推定14億ドルを稼ぎだしている。そして、14億ドルをかせぐために、Supercellは多くのゲームを作り、多くのゲームをボツにしている。

また面白いのは、Supercellには「失敗を祝う」という文化がある。Supercellでは失敗がなければイノベーションはないと考えており、失敗そのものではなく、失敗から「学べた」ことを祝う。実際終了プロジェクトのチームには、各メンバーにシャンパンを渡してお祝いをしたそうだ。

組織の学習は難しい。日本人は不安度が強いこともあり、失敗や不安を連想するものを「穢れ」として排除することが多い。そのため、組織では、容易に失敗プロジェクトの存在ごと無かったことになりやすい。それが組織内でどんな作用をもたらすのかというと、人でいうとトラウマだ。なぜだか思い出せないけど、その行動を取ることはいけないと思っている状態だ。こうなると、年月が経てば立つほど理由はわからないけど、避けるルールが増えていき、戦える領域が狭まり、上手く戦えなくなっていく。

そのため、この失敗を組織で正面から受け止めないといけないのだ。人間の学習は失敗をストーリー記憶として学習して、それを避けることによって、結果として成功のルートを浮かび上がらせるようになっている。社内に「失敗」が残っていなくては、どのようにして学習したらよいのかわからないのだ。このような作用を避けるためにも、失敗を認めチャレンジそのものを少なくとも意義はあったと認めてほしい。

私の開発手法：リーンスタートアップ＋ピクサーのブレイントラストカスタム＋グループフロー

私の開発手法を書いておこう。正直、私はそれほど資金や期間が豊富でない戦いが多かった。なので、企画技術や、チーミング技術、マーケティング技術などを積み重ねるテクニカルな戦い方をしてきた。ただ、業界的にはイレギュラーなアプローチをとっているので、誤解を招くことも多い。

私が携わった案件では「自社開発で、IP（版権）モノかオリジナル、システムは他所のゲームを参考にしつつ、かなり作り直し」みたいなのが多かった。システムに凝るのは、私がそういうプレイヤーだからだ。

加えて、私はスタートアップ出身だ。スタートアップは、同じように不確実性との戦いだ。ゲーム開発も一つのスタートアップと捉えることができると思っている。なので、スタートアップ開発の手法の１つであるリーンスタートアップを開発手法として採用している。

リーンスタートアップとは？

リーンスタートアップとは、スタートアップの手法で、作り手が自ら作りたいものではなく「まだ形になっていない市場が本当に欲しいもの」がなんであるのかというのを探りながら作る手法である。

リーンというのは「痩せた」、「筋肉質の」という意味で、トヨタ生産方式のムダ取りの影響を受けている。

コストをそれほどかけずに最低限の機能を持った試作品を短期間で作り、顧客に提供することで顧客の反応を観察する。その観察結果を分析し、製品、サービスが市場に受け入れられるか否か判断し（市場価値が無ければ撤退も考慮）、試作品に改善を施し、機能などを追加して再び顧客に提供する。このサイクルを繰り返すことで、起業や新規事業の成功率が飛躍的に高まると言われている。

リーンスタートアップの手法

リーンスタートアップは「構築」、「計測」、「学習」のプロセスを短期間で繰り返す。

構築

ある想定された顧客がある新規サービス、製品を必要としていると仮説を立て、新規事業のアイデアを練る。

続いて、上記のアイデアを元にした製品をなるべくコストをかけずに開発する。この時に開発される試作品をMVP（Minimum viable product）、実用最小限の製品と呼ぶ。

計測

上記で作成したMVPをアーリーアダプター（初期採用者）と呼ばれる流行に敏感で、情報収集を自ら行い、判断するような人々に提供して、その反応を見る。

学習

アーリーアダプターの反応、意見からMVPを改良して顧客に受け入れられるものにする。

また、アーリーアダプターの反応、意見から最初に立てた仮説そのものが誤りだと判断されることもある。この場合には仮説そのものを見直して、方向を大きく転換する。リーンスタートアップでは、この方向転換をバスケットボールの用語になぞらえて「ピボット」と呼んでいる。

ゲーム開発もスタートアップと同じで、この仮説検証プロセスを、チーム内でどれくらい高速に回せるかで、面白く売れるゲームが作れるのかがほとんど決まると私は考える。

具体的にどれくらい、この検証サイクルを回すのかを書いておこう。私が過去に作ったタイトルはスマホアプリで予算数億（標準よりちょっと安め）、スケジュール１年程度（11~13ヶ月）のものが多かった。

例えば前回作ったタイトルは、プロジェクトが始まってから大きなピボット（コンセプトレベルでの変更）で５回程度、中くらいのピボット（機能コンセプト変更レベル）で数十回、小さなピボットは数百回といったところだろうか。初期のバトルシステムのプロトタイプは、最初の３ヶ月でVersionが100を超えたことを覚えている。

また明確に否定をしておくが、この開発ですごいのは私のジャッジではなくて、開発チームである。伝えたいのは、こんなにピボットしてるんだすごいぜではなく、こんな変更を「面白く売れるゲームという目的」に本気で立ち向かったチームがすごいということだ。

普通の開発では、アルファ、ベータ、リリース版と開発が進んでいく。私の開発ももちろんフェイズ自体はそうなのだが、バトルシステムにおいてはリリース一か月前まで大きな変更をしながら進んでいた。データにおいてはリリース前日まで作っていた。イメージとしては最初は色々試行錯誤をしているので変更があるは当然なのだが、機能結合後、全体のUXが見えてから、ようやくこのゲームはこういうゲームだったのだと気がつくことが多い。そうした場合に、そういうゲームにピボットをするのだ。このゲームの場合、バトルを最後の４ヶ月でもう一回作り直した。

一緒に数回やっているPMに聞いてみたところ「あのときは正気か」と思ったと、また、試行錯誤無しに最終成果物の物量を最初から作るとして、普通にスケジュールを組んでみると、どう考えても1.5倍の開発期間が必要だと言われた。

自分で書いていて思ったが、やっていることだけを見ると、ただの暴君である。ただ、ここまでやらないと短い期間で安定的に面白くヒットするものが作れないのだ。

せっかくなので、他社の成功例として、パズドラとモンストを挙げておこう。

山本: プロトタイプは開発開始後2ヶ月で完成しました。とはいうものの、現在の物になるまでにどんどん変わっていきましたね。
プロトタイプ期間はパズル部分の作り込みをしていました。プログラマのスキルが非常に高く、パズルのルールを10パターンも用意してくれました。その他にもドロップの大きさや数を変えたり、パズル部分の面積を変更したりと、何が良いのかを、じっくりと試行錯誤しながら進めることができました。

―このゲーム、ゲーム業界では有名な岡本吉起さん※とミクシィがタッグを組んだ、ということでも話題になっていますが…
※（『ファイナルファイト』や『ストリートファイターII』シリーズなどを手掛け、現在はフリーで活動中のゲームプロデューサー）
はい。中（ミクシィ）でネイティブアプリのゲームの開発をしたことがなかったので、パートナーが必要かなと思いました。
5～6社さんに企画書を渡したところ、岡本さんのところだけ、もうモノをつくってきちゃったんですよね（笑）。動かせる状態のものを。
それが岡本さんとタッグを組むことになった、一番の決め手でした。

いずれの会社も、ベテランをかき集めて、短期間にプロトタイプを作って、作っては潰してをリリースまでに繰り返していることがうかがえる。

ピボットについて

今の話だけだとピボットは根性でやっているようにも感じるだろうと思うので補足をしておく。

コンセプトをピボットする時、今作った素材を利用して、別のゲームを企画するつもりで再構築を行う。今まで考えていた企画は一旦忘れ、試行錯誤で得た新しい仮定を元に考え直すのだ。こうすることで、スケジュールはそこまで影響を受けずに進める事ができる。とはいえ、プログラムがどんどん変わっていくため、最後にリファクタリングが必要になることが多い。

コツとしては、MVPの作成と一緒で、ピボットの目的を達成する最小の仕様で実装するのだ。第一世代が集って検討すれば、簡易な実装で目的となるUXを実現する方法をたくさん知っているので、短期間でMVP検証できることが多い。

とはいえ、実装でピボット限界はあるので、無理しすぎないレベルでやるしか無い。

なぜそんな作り方をするのか？かえるD戦記

なぜ私がこのような作り方をするに至ったかを書いてみよう。もともと私はwebエンジニアだった。2010年頃だろうか、コンシュマーゲーム会社から独立した新しい会社に所属をしていた私は、ガラケーのブラウザSNS向けにゲームを企画してみないかと言われた。

前から企画をやってみたかった私は、3回の企画自己リテイクの後にファンタジーソーシャルゲームを作り上げる。私としてははじめてのディレクター体験だった。当時のソーシャルゲームは、まだ企画が簡単だったため素人の私であってもなんとかなったのだ。チームメンバーは全4人で、開発期間は３ヶ月。正社員は私のみ。ちなみに社内での評判は最悪で、最後には損切りという形で、全企画の３割程度のバトルとクエストが出来た時点でリリースされることになった。

社内の評判をよそ目に、そのゲームはヒットをした。４人のメンバーは、マルチスキルのメンバーで、とにかく色々な視点で作品を叩き議論し修正した。その当時社内では考え方として導入されていなかったKPI管理を導入し、ゲームには、当時どこにも導入されていない新しいメカニクスをいくつも導入した。開発は楽しかった。大変だったけど、最高の体験だった。

１作目はうまく行った。そのうち、１作目の評判から、大型IPのブラウザゲームを作らないかという話が入ってくる。それは私が好きなIPだった。喜んで引き受けた私に待っていたのは、つらい現実だった。

まず、１本目の運用と並列で２本目を作る必要があるため、１作目を作ったメンバーが分散をした。最終的には、１本目を作っていたメンバーは全て他プロジェクトに行くことになった。残された私は、ゲーム作りをそこまでわかっていない１０人程度のメンバーと共に頑張って作ることになる。

途中まで順調かと思われたが、徐々に風向きが怪しくなっていく。版元からは「このIPはこのクオリティでは出せません」「こんなスマホゲームアプリみたいにできませんか？」（作っているのはガラケーのブラウザゲームである）「このシステムが無いと出せませんね」という指摘事項が届く。ただただ必死に作った。メンバーには版元からのオーダーに従ってもらうほかなく、トップダウンでチームを回すほかなかった。メンバーから意見を言われても、意見自体が微妙だったり、そもそも版元の意見をひっくり返せるわけないので、否定することが多くなった。やがて大幅にスケジュールをオーバーしそのタイトルはリリースされた。そのタイトルはヒットした。

２本のゲームを成功させた私を待っていたのは、「天才」扱いである。当時の私はアルファ酔いをした。そして、こうすると良いよと親切のつもりで言った意見が、重く受け止められすぎたり、他の人から意見を言われなくなったりした。組織のためにと思って頑張ってきたのに、組織は「天才」としての私は必要とするが、個人としての私を理解してくれなかった。私は孤独になった。

会社は上手くいっていたが、私はこの環境での限界を感じたため、転職を決意する。何を間違ってしまったのだろうと考えながら。

転職した私は、今までとやり方を変えてみようと決意した。アルファを封印し、１本目のような、相互に話し合いながら、お互いに目標を追い求めるような開発をと決意をした。その結果生まれたのが、この開発手法である。出来たスマホアプリは、また社内での最悪の評価を乗り越え、これまで作った３本のゲームの中で一番成功した。

その後もこの開発手法を改良しながらゲームを作り続けている。

ただ、この方法は、経営層、プロデューサーの理解がとても必要となる。チームが非線形に予定を壊しながら加速していくからだ。プレイに基づき面白くなった「見たことのないゲーム」はみんな認識が出来ない。なぜならば、売れそうかどうかを「今市場の売れているゲーム」とのパターンマッチで認識するためだ。うっかりすると迷走していると勘違いされ、損切されたりするのでくれぐれも注意が必要である。

ピクサーのブレイントラストカスタム

では、どんな方法でゲームを作っているのかを紹介しよう。

前回紹介した本を覚えているだろうか。

この本には、ピクサーの映画の作り方が書いてある。ピクサーでは、ブレイントラストと言われる、会議というか討論がある。

ブレイントラストとは？

ここから引用

ピクサー映画は最初はつまらない、それを面白くするのがブレイントラストの仕事である。

どんなに才能を持った脚本家や監督でも、必ずどこかで自分を見失ってしまうので、明確な方向性を取り戻すには、忍耐と率直な議論が必要だということ。

ピクサーの監督は、自身が思いつき、撮りたくてしかたのない映画を撮っているので、製作中に確実に発生する問題に、監督がその情熱のあまり気付かないという事態がいくつか起こる。その時のためにブレイントラストという相談相手が用意されている。

ブレイントラストと他のフィードバック体制の違い

大きく違う点は２つ。

・ブレイントラストのメンバーはストーリーテリングに深い造詣を持つ人ばかりで、たいていそのプロセスを自ら経験している
・ブレイントラストには権限がなく、提案や助言に従う必要は無い

ブレイントラストの流れ

会議の朝、作品の試作映像を観る。上映後、会議室に移り、昼食を食べながらそれぞれの考えをまとめ、そして話し合いの席に着く。

参加するのは

・総指揮のジョン・ラセター
・監督
・プロデューサー
・脚本家
・ストーリーアーティスト（脚本を絵にしていく人）
・他の作品の監督

誰がどこに座るといった決まりはない。みんなが向かいあうような形でテーブルを配置する。監督とプロデューサーが進捗状況を報告する。

誰もが平等に発言権を持つが、ジョン・ラセターが気に入ったシーンや改良が必要だと思うテーマやアイデアを挙げると、そこから率直な意見が飛び交い始める。

作品の強みや弱みについて、それぞれが自由に発言をする。悪いところ、抜けている点、わかりにくい点、意味をなさないとことを指摘する、ただし具体的に。それが批評と建設的な批評の違いだ。批評すると同時に建設しているのだ。

どんな指摘をするにしても、相手を考えさせることが大事だと常に思っています。だから学校の先生と同じことをします。問題点を言い方を変えながら50回くらい指摘すると、そのうちどれかが響いて相手の目がぱっと開く。
「ああ、それやりたい」って思ってくれるんです。

ブレイントラストの考え方

・指摘する側も、される痛みを自身も経験して理解できるという共感と当事者意識のうえで構築すべき
・自尊心を満足させたい、功績を認めてもらいたいという欲求を持ち込ませない
・目的はただひとつ、助け合い、支え合うことによってよりよい映画をつくること
・信頼関係を築き、率直に話せるようになり、反撃を恐れず危惧や批判をできるようになり、建設的な批評の言葉遣いを覚えるまでには時間がかかる。
批評を攻撃と受け取る人、フィードバックを咀嚼しやり直す能力のない人を助けることはできない

ここまで引用

私はこれを見てとても良いと思ったので、取り入れることにした。ただ、そのままは無理なので、大分カスタムした。

ピクサーのブレイントラストカスタム＝確認会とプレイサイクルテスト

ゲーム作りは、とても大変だがとても楽しいことだ。つい自分の山盛りの担当作業にどっぷり浸かって、どんなゲームを作っているのか、今どんなゲームになっているのかを忘れがちである。

もっと簡単に言うと、開発中に開発しているゲームを実際にプレイをしているひとは、かなり少ない。何もしないと２０％くらいになると思う。そして、自分たちのゲームを遊んでいる人と遊んでいない人の間に温度差が生まれてしまい、チームの目線が少しずつズレていってしまう。そのため、チームが一丸をなってゲームをより良いものにする体制を構築するには、全員がゲームを強制的に遊ぶ時間を作ることが必須となる。

確認会

これを行うのは、ゲームコアができるアルファの終わりと、ベータの結合以降ずっとである。そんな特殊なことを行うわけではないので、単純に「確認会」とよんでいる。

確認会はこういうものだ。

・２週間に１度ほど、１時間チーム全体で時間を取る
・１チーム５人くらいの小グループに分かれる。チームは毎回ランダムで決定する。チームには一人、リーダーとなるファシリテーターを用意する。
・小グループは円形に集まる、最初の15分でテーマとなる箇所のプレイをする。
・次の１５分で、小グループでプレイしたところの、ユーザーとしての感想を一人づつ言ってもらう。小グループリーダーはGoogleDocsなどにまとめる。状況を詳しく聞いたりはしてもよいが、感想の良い悪いや、その際にどの意見を誰がいったかは記録しない。
・最後の３０分で、プロジェクターでGoogleDocsをみんなで見ながら、全体でどんな意見が出たのかを小グループリーダーに発表してもらう。
・最後に、ディレクターとしてこういうところが問題として上がっているという話を少しだけする。出た意見の良し悪し、これからどうするという話は行わない。

この確認会の意図はいくつかある

・プレイしていることをチーム全体で担保すること
　・自分たちのゲームを遊んでいて当然という空気感を醸成する
　・我々が何者でなんのために今頑張って作っているのかを再確認すること
　・匿名化することで、心理的安全を保ったまま「このゲームおもしろくないよね」が言える
・小グループでランダム結成すること
　・変更したところ、直したところは、ある人にとっては良いけど、そうじゃない人にとっては良くないということを実感してもらうこと
　・色々な視点があり、色々なメンバーがいることを認識してもらうこと
・誰が出した意見とかの情報は、感情ヒューリスティクス（人の好き嫌いが意見の良い悪いに感じてしまう）が入ってしまうため排除する
　・ディレクターは、「誰が言ったのか」を気にせず情報だけを見ることができる
　・偉い人の意見もこれでバイアスを消す

これを行うことで、全体の視点や目的が本質に近づく。もちろん、否定の意見が最初は多い。否定の意見も伝えてもらって構わないことは伝えておく。というか、この確認会の大きな目的の１つは「このゲームおもしろくないよね」とお互いに言えることである。もちろん、すごく頑張って作っているのでお互いにショックを受ける。

ただ、そういう意見が一人ではなく、たくさんのグループから聞こえると本当にそうなんだなと思える。また、開発をしていないユーザーの意見も、容赦なくこうであったと思い出すのだ。まだ出来てないからとか、まだ仮素材だからというのは、開発者のいいわけである。面白くないものは面白くないし、本素材にしたところで面白くなるわけではない。

また仮素材から本素材に変更したときも、容赦なく前のほうが良かったという意見が出てくる。担当のデザイナーやエンジニア、ディレクターは、良くなったはずだと思いたい。だが、他の担当の人は容赦なく見たままを伝えてくれるのだ。

ディレクターやチームの担当メンバーは、確認会で出た意見をどうやって反映するのかを決めるのだ。それは、こういうふうに反映しますというのを、まとめてチャットなどでチームに伝えられる。

この確認会を回すことで、チームは「何と戦っているのか？」そして「私の意見はどう反映されるのか」や「チームメンバー同士」を理解していく。ある一定水準をこえると、私はディレクターというよりは、ファシリテーター（催促者、まとめる者）として意見を集約するだけで、次に何をするべきかが見えてくるのだ。それはまるで進化し続けてる生き物のメンテナンスをしているかのような気持ちになる。私たちはチームになる。

開発後期は、ゲームが実際に面白くなってくる。今までの努力の成果が本当に実るのだ。そのとき、チームはグループフローに入る。誰が命令するわけではなく、チームが一体として目的に対しての最適行動を取るのだ。それは、劇的な体験だ。

グループフローについてはこちらの記事の最後にかいてある。グループとしてフロー（時間を忘れて没頭する体験）に入ることだ。

プレイサイクルテスト

開発終盤、ベータのあとの数ヶ月、私の開発ではプレイサイクルテストという期間を置く。ようするにデバッグ期間なのだが、ここでも確認会の方式でゲームがどうなっているのかを確認しながら進める。

プレイサイクルテストというのはこういうものだ

・１サイクルは１週間程度
・１週間に１回確認回が行われる
・ユーザデータは初期化して、最初から始める
・確認会までにゲームのチュートリアルから対象の場所までプレイをして、感想を持ち寄る
・１週間で全体のバランス、全体のボトルネックを改修して、もう一度サイクルを回す

これをチーム全体で行う。チームにはゲームが得意ではない人もいるし、ゲームが得意な人もいる。初心者に対してのバランスや、実際の結合バランス、体感などを調整する。意図は必ずと言っていいほどずれて体感されるのでそこを調整する。また、意図が伝わってないところや、褒めが足りないところなどには急遽演出や説明を入れて補足をしていく。

また、この段階でも機能のピボットなどを行うことがある。今の仕様のままではうまく統合出来ないことが判明することは結構多い。最小ピボットでなんとか着地できる道を探す。これが最後にできるかどうかで、完成度はかなり違うものになる。ただ、デバッグとコンフリクトするためリスクは高い。

これをリリースまで、２～４ヶ月ほど続ける。８サイクル目くらいでかなり完成度が上がる。

そして、ついにリリースだ。チームは、浮かれることなく、ユーザーからの感想を楽しみに見る。俺たちのすごいゲームを見てくれ！と。

似たような取り組みとして、ゼルダの伝説 ブレスオブザワイルドでも、300人規模で最初からエンディングまで開発者全員が遊んで感想を書く、というテストプレイを行っており、親近感を覚えたのを思い出す。

さすがに300人規模は本当に最後の頃でしたけどね。もちろん、僕もプロデューサーなので、開発費用を考えれば、そこはなんとか短くしたいと思うんですけど、現場のスタッフが「ダメです」と言ってくるわけですよ。だから僕もキッチリ1週間、遊びます。するとやっぱり何が問題点なのかが見えてくるんですね。

結局、このゲームは各々の考えで作っているものですから、それをみんなでプレイして全体像を見渡して評価するのがいいんです。そうすると、「何を作れていて、何ができていないのか」が全員分かるんです。

だって、責任者が言葉で自分の考えを末端まで伝えるのなんて、本当に難しいですよ。だけど、みんなが遊んでいれば、「あそこさー」「ですよねー」で会話できる。そのことで逆にこの広い世界を作り込む時間的なコストは劇的に下げられていると思いますよ。

ゲーム開発者なら、誰もが羨む数百人規模の大規模テストプレイだ。私の手法は、それほどの余裕が無い場合でも、いかに現実的にクオリティを上げるかを突き詰めている。

何度も言っているように、ディレクターだけではなくチーム全体で面白さに正面から立ち向かうことが全てにおいて大切だ。手法は本質ではない。手法は状況に合わせて使えばいいし、合わなければ手法自体探索して探せば良い。あなたのゲーム開発でヒントになると幸いだ。

まとめ

開発体制と不安の関係性
◆有名IP、受託開発
　・不安：低　自由度：低
　・チームを安全に育成することができるが、面白いゲームを作りたいというメンバーと、納期通りに納品することがゴールの経営で対立して、人が抜けるリスクがある
◆有名IP、オリジナル開発
　・不安：中　自由度：中
　・トップダウンでコントロール可能
　・「天才」を置くことで、不安を払拭することが可能
◆独自IP、オリジナル開発
　・不安：高　自由度：高
　・第一世代、マルチスキル人材で中核を固めつつ、ボトムアップが必要

不安に強いチームを作れるのであれば、より高い自由度の体制で開発を行うことができ、より多くの収益を上げることができる

「天才」の悲運
　・不安を払拭するために「天才」が欲せられる
　・チームを「天才」が支配することで、不安から逃れられる
　　・時として、経営層もこれを思ってしまう
　・ボトムアップ型の組織と「天才」は相性が悪いので、リスクを取った開発を行いたいのであれば、おすすめはしない

第一世代、マルチスキル人材
・リスクが極めて高い案件には、第一世代のマルチスキル人材の投入が必要
・成果物の売上が評価されることを経験した連中は、作り直しを厭わない

かえるDのやり方
◆リーンスタートアップ
　・MVP
　　・第一世代の連中をかき集めて、短期間で動くものを作る
　・ピボット
　　・遊んでみて、面白くなかったら素早くゲームの方向性を変える
◆ブレイントラスト会議の改良
　・確認会
　　・２週間に1時間程度、特定機能を重点的に触る
　　・開発チームを5人程度の少人数に分けて意見を出してもらって集約
　　・自らのゲームを遊ぶことによるチームの一体化
　　・意見の匿名化による心理的安全性の担保
　・プレイサイクルテスト
　　・開発末期に１週間ずつ
　　・長期プレイでのユーザ体感を確認

記事が面白かったら、シェアやtwitterアカウントなどをフォローなどしてもらえるとありがたい。

参考文献

再度の紹介になるが、モノづくりはこういうもので、自分だけではないのだと理解するだけでも非常に心強い。そしてここまで志高くものを作るのだという参考になる。一読をおすすめしたい。

記事中で説明した、リーンスタートアップの本だ。なんとなく壊して作るスクラップアンドビルドを、より精度が高く現実的に使えるようになる。経験則的にそれっぽいことをやっている人は多いとは思うが、確かにこうすると短期間で行える等のヒントもあるので是非読んでもらいたい。

こちらも再度の登場となるが、もともとフローは、ゲームのためではなく仕事で上手くいっている人を調べていたら共通点が見つかったという話である。なので、どちらかと言うとこういう記事で紹介するほうが正しいとは思う。手段は他の記事でも書いたが、なんせフローは深い。私も手探りで進んでいるという認識はある。色々迷ったときに、読んでみるとヒントになるだろう。