企画者と技術者が交わった後の工程で発生する後戻りについて考える

三宅陽一郎MiyakeYouichiro @miyayou

300ｍ の塔を建てて、あと 10m 伸ばしたいんだよ、って言われて、あー、それはそもそも足場からやり直さないといけないんです、っていう感覚ですね。全部、要求は聞きたいのに、最初から言って貰えれば、ですね RT @H_Holon @itohtak @shosira @hdm_tw

shosira / Shoji Ohashi @shosira

言葉の定義の問題というのは結構あって、ゲーム業界からきたプランナーさんに、画面設計まで終わった状態で企画書があがってきたときは、驚くと同時に、ヤバいと思った。

ゆんゆん探偵 @yunyundetective

@miyayou 足場につっかい棒をしてレンガを抜いたり挿したり、無茶なアクロバットをすれば対応出来ないことも無いのだけど、下手すると３００メートル積み上げた塔が丸ごと崩壊するという。

三宅陽一郎MiyakeYouichiro @miyayou

そうですー。それですー。　RT @yunyundetective 足場につっかい棒をしてレンガを抜いたり挿したり、無茶なアクロバットをすれば対応出来ないことも無いのだけど、下手すると３００メートル積み上げた塔が丸ごと崩壊するという。

H.Holon🍤/🐁🌕 @H_Holon

担当プログラマーにとって当然でもそうではない人にとってはわからない限界とか条件って、それこそプログラマー側が事前にみんなに伝えておくほうが良いと思うなぁ。 「このxlsシートで計算するといいよ」ってのを用意するとかね。

三宅陽一郎MiyakeYouichiro @miyayou

そういう小手先もある程度はいいけど、延長技術だけではそもそも対応できない問題も多いし、戦えないですよね。まず大きな技術的基礎をどんと構える時代だと考えています。　RT @yunyundetective

H.Holon🍤/🐁🌕 @H_Holon

プログラマーはもっともっと、プランナーとかグラフィックとかシナリオとかサウンドとか営業とかに語りまくって良いんじゃないかな。直感的ではない作業が多いからこそ、他人に過剰なほど伝えるのは効果的だと思う。

ゆんゆん探偵 @yunyundetective

@miyayou 私は不器用なので、だいたい初めて作った物は途中で破綻して、そこで一から作り直してようやく使い物レベルになります。時には１から作り直した方が明らかにいい、という事はままあって、その見極めが出来るかどうかは極めて重要なスキル。

三宅陽一郎MiyakeYouichiro @miyayou

.@yunyundetective 見極める力は大切ですね。大規模になるほど、取り返しのつかないことを、長いことやってしまうことになるので、技術ディレクションは大切だと思います。

H.Holon🍤/🐁🌕 @H_Holon

プログラマー「それやりたいなら先に言ってくれよ」vsプランナー「それできないなら先に言ってくれよ」。 つまるところお互いに最初から意識統一をはかっておくのが大切だよね。仲間なんだし。

shosira / Shoji Ohashi @shosira

@miyayou こちらの世界だと、どれだけきちんと、モックアップでコンセプトをテストできるかで変動幅の予測可能性が決まりますね。アジャイル開発が歓迎される理由でもありますが。

H.Holon🍤/🐁🌕 @H_Holon

まぁ、なんというか、「みんなで幸せになろうよ」

三宅陽一郎MiyakeYouichiro @miyayou

@shosira ゲームだとユーザー体験が結局評価の基準になる（と自分は思っているので）のと、純粋なソフトウェアの要件主導とは、確かに違いますね。アジャイルどうしようか、っていうのは、今年の CEDEC のテーマの一つでもありましたね。

shosira / Shoji Ohashi @shosira

300mの塔を建てるよって言ったときに、なんで300m?なぜ塔？ってところの試行過程を共有してないと、デザイナーもプログラマーも、お互いに変動幅が予測できない。目的は狼煙をあげることだよね、だったりして。じゃあ塔いらないじゃんとか。

たかひろ @itohtak

もしかして、テクニカルプランナーとか必要なのかも？AI等の高度化したプランナーでは扱いきれない技術を、プランナーがキチンと扱えるようにするお仕事。

shosira / Shoji Ohashi @shosira

@miyayou WebとiPhoneなので、お客様のユーザ体験に左右されるのはこちらも同じですが、検証したい対象が微妙に異なるでしょうか。あとモックアップは、実際に想定ユーザさんを巻き込んで検証します。なので、どうテストをするかが、かなり課題になりますね。

かふ @kafu_f

@shosira @miyayou おそらく、身体と物との関係をプロダクトに落としこんでいくか？ということが違いとしてあるんじゃないかな？Wiiになかなかサードパーティーが参入していかないのは、そういう設計を考える必要があって、今までのゲームのやり方と異なるからが理由なのかも

三宅陽一郎MiyakeYouichiro @miyayou

@kafu_f @shosira モックアップを作って―　は、海外の大規模ゲームでは、そうしますね。日本もβ版作っては、とやりますが、ゲームデザインに対する捉え方の違いなのか、たぶん、ゲームデザインは最後に完成されるという考え方しますね、日本は。

shosira / Shoji Ohashi @shosira

ユーザ調査を通してゲームデザインの検証をどうやるか、といったときにまず考えるのは、①コンセプトをユーザが理解可能か、②妨害要因がないか、③目標を達成可能か、④想定されたプレイ状況が発生しうるか。

shosira / Shoji Ohashi @shosira

@miyayou あ、違いをもう少し詳しく聞きたいです。モックアップは試行の意味合いが強いので、完成するのは最後ですよね。

三宅陽一郎MiyakeYouichiro @miyayou

@shosira 米ではゲームの根幹だけをコアメンバーだけで１年かけて作る場合もあるようです。マニュアルを作って人員を増やすとか。プリプロセスですね。だから、昔、米のゲームは同じような面が延々と続く、大ボリュームのゲームが多かったですね。

shosira / Shoji Ohashi @shosira

多分、デートプランを立ててみようぜ、っていうのに似てる。本人で検証をするのは無理だけど、簡単な確認は用意したいね、ってわけです。となると質問に工夫がいる。例えば食事にいくとしたら、どんな質問をすればいい？というのが問題になる。

三宅陽一郎MiyakeYouichiro @miyayou

@shosira ところが、最近は、ポストプロセスでの調整も大規模にやるようになって、アサシンズクリード２は４００人で作っているけど、週ごとのテストで全ての項目が８０以上でないと、出荷しないとか、なんとか。モックアップ、大規模開発、ＱＡ、を大規模でやるノウハウを身に付けましたね。

三宅陽一郎MiyakeYouichiro @miyayou

@shosira @kafu_f GDC Vault を調べれば、山のような資料があるよ。

三宅陽一郎MiyakeYouichiro @miyayou

でも、技術を導入しようとするときの、摩擦ってとても大切。そんなにスイスイ入るわけじゃないし、逆にスイスイと摩擦もないようなつかみ所のない技術は役に立たないだろう。その摩擦をよく分析して、どうすれば受け入れて貰えるかのヒントになる。それが研究の課題になる。