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

たかひろ @itohtak

日本のゲーム開発はウォーターフォールの悪い所を引きずっているかもしれない。主にパッケージソフト開発において。

たかひろ @itohtak

パッケージソフトの開発は最初に予算とスケジュール満たすべき要件が定義される。ドキュメント化されているかはともかく。この条件で各セクションが最大限の物量を投入しようとした場合、何か一つミスがあっただけで、プロジェクトはピンチに陥る。

たかひろ @itohtak

本来ならばスケジュールに対してバッファが用意してあるため、全体への影響は少ないはずなのだが、各セクションが最大限の物量を投入しようとした場合、早期にバッファは食い尽くされ、開発中盤にはほとんど無くなってしまっている場合も多い。

たかひろ @itohtak

やってみなければ分らない事が多いのは事実だが、上流工程で発生した問題が下流工程で発見された際、既に上流工程の工数を使い切っていて、元に戻れないパターンが良くある。これは全体的な品質に大きな影響を与える。

たかひろ @itohtak

@yoh7686 自分は全部の仕様が入ってから調整期間１ケ月、テストプレイも全てがフィックスしてからマスターアップまで１ケ月を、死守しようとしていたりします。一年以下のプロジェクトだと大体怒られますがwディレクタもテストプレイヤもこれで完成って状態にならないと見えない物が多いので

たかひろ @itohtak

思うにアジャイルが良いって言っている人たちは、スクラムを適用して厳密に開発プロセスを適用するようになったからでは無いだろうか？

たかひろ @itohtak

ウォーターフォールの基礎について、みんな学んだ方が良い様な気がしてきた。

たかひろ @itohtak

ウォーターフォール開発ってレビューをしない訳ではなくて、実際に動く物を作る前にドキュメント上で何度もレビューはする。企画書段階、仕様書段階、詳細設計書段階、全てにおいて。上流工程の段階で正しい事を確認してから下流の工程の作業に移っていく。

たかひろ @itohtak

下流に行く毎に手戻りのコストは高くなるので、本当に上流工程の作業で正しい事を確認できているのなら、ウォーターフォール開発は最大限に効率の言い方法になる。問題は、作ってみなければ正しい事が分らない、新規の分野には弱いという事。

たかひろ @itohtak

う～ん。物事の大小関わらず危機感を共有するのって難しいね。

三宅陽一郎MiyakeYouichiro @miyayou

「あとは調整さえすればいいゲームになる、或いは、神ゲーになるかも…」という感覚は、一体、何なのだろうな…　

たかひろ @itohtak

@miyayou 日本人のゲーム開発者がみんな持っている妄想？ @miyayou 「あとは調整さえすればいいゲームになる、或いは、神ゲーになるかも…」という感覚は、一体、何なのだろうな…

H.Holon🍤/🐁🌕 @H_Holon

私は持ってないなぁww RT @itohtak: @miyayou 日本人のゲーム開発者がみんな持っている妄想？ @miyayou 「あとは調整さえすればいいゲームになる、或いは、神ゲーになるかも…」という感覚は、一体、何なのだろうな…

ひづめ @hdm_tw

シナリオ書き進める前に顔グラフィックの発注だしてるのですが、書き進めると表情のいるいらないが変わってくるので、作業着手されるまえにリスト修正せねばな…

三宅陽一郎MiyakeYouichiro @miyayou

現在用意されている変数の調整だけで何とかなる問題と、それだけではどうにもならない問題の境界って難しい…。しかも、変数増やしただけでどうにもならないゲームのアーキテクチャの問題もある。 RT 「あとは調整さえすればいいゲームになる、或いは、神ゲーになるかも…」という感覚は、一体　

三宅陽一郎MiyakeYouichiro @miyayou

それを最後まで読みきるのが技術ディレクターの役割なんでしょうが、そもそもゲームデザインが変化するから難しいですね。　RT @polestar23 「それのどこが調整だよ」ってヤツですな。 RT 現在用意されている変数の調整だけで何とかなる問題と、それだけではどうにもならない問題

shosira / Shoji Ohashi @shosira

関係者ならベストエフォートで済む話を、知らない他人に納得させるために厳格に定義して、結果いろんなものが転けるというのはよくある話。しかし裁判というのは、それでどちらが先に転けるかという争いなので、司法や警察という他人が介在した瞬間に問題化するんだなー。

三宅陽一郎MiyakeYouichiro @miyayou

ゲームデザインの変動幅と、用意するべき技術の変動幅で比例しないんだよなー。それが、デザイナ－と技術者の間でリズムが狂ってしまう原因の一つなんだと思う。　「これちょっと変えたいんだけど」「いやーそれはー」「なんでこんなこと、できへんのじゃー」^^

北風 @polestar23

それでもよくなると思える変更ならなんでもいいです。じっくり腰を据えてやる育成SLGなんですって言われてたのがマスターアップ3日前くらいに、30分でコンプできるゲームに至上命令で変えさせられたことが・・・

H.Holon🍤/🐁🌕 @H_Holon

それは事前に相互の「できるできないの常識」のすりあわせをすべきだと思いますよ。RT @miyayou: ゲームデザインの変動幅と、用意するべき技術の変動幅で比例しないんだよなー。それが、デザイナ－と技術者の間でリズムが狂ってしまう原因の一つなんだと思う。　

たかひろ @itohtak

@miyayou 環境にもよりますが、デザイナーのコントロール外にある技術の時に、起こりがちな気がします。

たかひろ @itohtak

原因はうまく言えないけど、プランナー考える、プログラマー作る、みたいな体制はもう崩壊しかかっていると思っている。これからはプランナーも利用する技術の事を理解して、コントロールしてゲームをデザインしていく必要がある。

shosira / Shoji Ohashi @shosira

@miyayou ゲームじゃなくても同じ事が起きてます。できるだけ変動幅を共有してないと厳しいので常に確認するようにしてますが、対応出来ないブレは、企画コンセプトの共有ができてない事が経験では多いです。変動幅の可能性に対する想像力が違ってきちゃうことがありますね。

ひづめ @hdm_tw

@miyayou いれこんだ時点で達成感がありますし、開発者は全体を見知っているので、＋調整でいいものになる予感ってしますよね ユーザは一部分しか見てくれなかったり価値観それぞれ違うのでその通り受け取ってもらえるわけじゃないですが…

shosira / Shoji Ohashi @shosira

ブレストの段階で、どういう課題が遡上にあがってくるのかを、デザイナーとプログラマーが双方わかってないとブレる。ただ、プランナーさんの役割がどのくらい強いのかにもよる話なんだよね、これ。