ボクはゲーム開発者以外の人の書かれた文章を参照することがたびたびありますが、こちらの記事もそのひとつ。
「どうやって２割を見切る？」（Throughさん）
また、「仕様の2割を切る」という意見も、きわめて現代的な作り方だ
と思います。
ゲームとプロジェクトの肥大化にともなって、あまり重要でない仕様を実装するコストが上がっています。さらに、ROMカートリッジの頃より容量が豊富なた
め、重要でない仕様の実装が（容量という）数字で見えにくくなってもいます。メディアだけでなく、RAMやプロセッサの実行処理でも同じです。正確には、
見せる手段もあるけれど、全体の器が大きくなっているから、神経質になりにくい。
精神論的な開発論、あるいはファミコン時代懐古主義的開発論からすると、仕様を切るというのは、まるでとんでもない凶悪犯罪をおかしたかのように叩
かれる危険性はあります。……ああ、もちろんあえて誇張していってます。ただ、プラットフォーム問わず、最近の（結果が）うまくいってないゲームを見る
と、うまく仕様を切れていない印象があるんですよ。ゲームの焦点がボケすぎてます。結果的に広報展開もボヤけたものになり、当然ユーザーの印象には残ら
ず、市場的な結果は芳しくないものになります。
また、これは上記の「調整」重視の流れにも合致します。「調整」するには当然モニターを取って、その結果を反映するための時間を確保しなければなりませ
ん。そのためには仕様のプライオリティ、見切りによって、開発リソースを集中する必要があります。＊
個人的には、アイデアを「深堀り」しないことも重要だと思っています。
新要素入れてみた→あんまり面白くないなあ→ひねって色々入れる→なんか作業がスゲー増えて複雑になる→ゲームの元々の焦点（or テーマ）からはずれてしまう→結局、どういうゲームかわけわかんない→遊んでて遊びにくいだけのゲーム完成→広報展開も当然失敗
掘っていって金脈にぶち当たりそうになかったら、そこで止めちゃうのも１つの勇気。掘った分を埋めちゃうか、そのままにしておくかは意見がわかれるかもしれません。ただ、残しておいてもいいと思うんですけどね。体裁は整えるにしても。
まぁ、古典的なゲーム性議論や、システム論からすると、深堀りしない姿勢は批判を受けそうなんですが。でも深堀りしすぎて、本末転倒の結果になってしまうのはもったいない。あえて暴
言調にいきますけど、大して意味のない要素なんて、ゲームにはいくらでもあるじゃない。ゲーム性理論的に、理屈的に美しいゲームって、案外実際にはつまら
んし（実際にはノイズ的な部分で、ポピュラリティにつながっていたり）。ゲーム性理論しか見ないと、結局ファミコンまんせーで、そこから先に進めなくなる
愚に陥りますわなー。
もちろん、まったく掘らなきゃ何にも出てこないんで、掘ることを否定しているわけじゃありません。ただし、作品のテーマを見失いそうな危険を感じたら、そこで引くのも大切。穴を掘る汗は美しいけど、流した汗をペットボトルに詰めて売るわけにもいかんしね。
（汗の話をすると、ちょっと前の「汗」の記事を思い出す人もいるでしょう。あの時俎上にあげた「鬼武者3」「ジャック2」をイメージする人がいるかもしれません。けど、ボクは両タイトルを”アイデアの深堀りをしすぎたソフト”だとは思ってません。誤解のなきよう）
んー、で、最後にネット上であがっているゲームの現代的な作り方をまとめてみると、
１）徹夜的な開発スタイルを愛好しないこと
２）企画要件を整理して、本当に効果的なことに注力すること
３）商品としてのテーマを明確にすること
４）迷走しかかる自覚があれば時には「深堀りを諦める」勇気をもつこと
といったところでしょうか。
＊
納期性という観点からも、仕様の見切りは大切です。納期を守るためにはもちろんスケジュール管理はとても重要です。けれども、やはり仕様を作る側（企画）
が仕様を見切り、仕様を受ける側（プログラマとデザイナー）がそのための情報を”適切に”フィードバックする必要があるのでしょう。
とはいえ、「どうやって２割を見切る？」にあるとおりで、そんなやり取り・すりあわせ自体が難しいというのも現実。「プログラマーの言い訳」という言葉
は、本当に言い訳の場合もあるし、率直な現状報告の場合もあり、的確な判断は意外に難しい。……と、参照記事の議論の繰り返しになりますが、そこで短期リ
リースが肝要ということになるのでしょうね。
諸注意（あ、ちなみに、ボクは「XP信者」は好きでないので、そういう人はコメント欄に書き込まないでください。「禁句」の方向で。削除
対象かもしれません。JAVAはキライじゃないけど、JAVA信者はキライの法則といっしょ）
コメント
DAKINIさんはじめまして。
こんな名前で失礼します。
以前よりTTNM氏に注目していることもあり、ちょくちょくのぞかせてもらっていました。
「仕様の２割を切る」話がおもしろかったのでコメントをつけさせていただきます。
私の知っている（婉曲表現ですいません）現場では、スケジュールに無理があると判明した時点で、スケジュールを伸ばすか助っ人を入れるか仕様を切るかの３
択で、金と発売時期とゲーム内容をはかりにかけて最適解を探しておりますが、それが結果的には「２割を切る」かんじになっているなあと。
これは、ディレクターにあたる仕事をしている人間が、毎回直面する課題のひとつだと思います。
「映画は決して完成しない。放棄されるだけだ」という格言があるそうですが、ゲームも同様なのでしょう。
まあ実際は、切れる枝葉と切れない幹がはっきりしたゲームの作り方ができ、かつ上手く秤にかけられるような人材は限られているわけですが。
今後も可能な限りこのような理想をもって行きたいと考えています。
あと日本での運営法としてのパブリッシャーチェックですが、下請け法改正の影響でちょっとは増えつつあるような気がしています。いかがでしょうか？
投稿者: キノコ人間 | 2005年10月24日 07:28
こちらこそはじめまして。
今後ともよろしくお願いいたします。
＞人材は限られているわけですが
まったくそのとおりでしょうね。
上記の記事にしても、実践例があるというよりは、あくまで
色々いわれていることをまとめてみただけにすぎませんし。
＞下請け法改正の影響でちょっとは増えつつ
おっと、この辺の事情はそれほど詳しくないのです。すいません。
開発中止はイヤなものですけど、客観的なデータが元になって
いたほうが多少はマシでしょうねえ。
投稿者: DAKINI（管理人） | 2005年10月24日 07:28
すんません「信者」なんですが(^_^;
まま、XPから個人的に受けた影響ってのは「こんなもんでもプロセス」ってことがわかったことですね。
つまり「アンチプロセスも言ってみればプロセス」ってことでしょうか･･･
実際、XP自体の経緯はもっと複雑なんでしょうが、我々低レベルな開発者としては、ウォーターフォール導入こそが至上の価値という有形、無形の圧力から
「世の中にはアジャイルプロセスってのもあってねえ」という説話で対抗できる可能性をみつけたこと。違うな･･･そんなこと強要されたわけでもないのです
が、まあ個人的に心の置きどころができたあたりが、精神衛生上はヨカッタかなあと。
あと、あらゆるプロセスを頑に拒否する自称テンサイ系開発者に対して、それも所詮プロセスといえるようになったとか･･･
でも、天才にはまた会いたい。
最近見かけないもんで。
投稿者: 永遠の三等兵 | 2005年10月24日 07:28
あー、私はエセ信者です。
クラス作るときに
「こんな機能あった方がいいかなぁ」
と悩んだ時は
「必要になったら作る。それがXP流！」
という風にして逃げております（笑）。
テストファーストを守ってる訳ではないのがエセという事で。
投稿者: カリガリ博士 | 2005年10月24日 07:28
＞でも、天才にはまた会いたい。
＞最近見かけないもんで。
減ってるみたいですねえ……そういうタイプのプログラマ。
実際、集団の中で力を発揮できないタイプの人がリストラ
された話は良く聞きますね。
まぁ研究みたいな仕事もあるとは思うんですけど、そういう人に
限って成果物の共有がヘタだったりして。商品作ってないやつを
養うほど余裕がなくなってきた、ってだけでしょうけど。
＞信者キライ
「仕事しない人に限って方法論持ち出す」の例にさえなって
なければ、別にボクも文句はないです。まぁ逆に何年も経験
積んでるのに、自分自身の方法論の改善を何もできない
人間も困るんでしょうけど。
色々な現場の色々な人とお話しすると、「あー、やっぱそう
思うよねえ」（理想と理論にもとづく精神的救い）と「あー、
やっぱそうなんだ」（悲惨な実話と共感にもとづく精神的救い）の
どちらも耳にしますね。
投稿者: DAKINI（管理人） | 2005年10月24日 07:28
「変化ヲ抱擁セヨ」とかいうんでしたっけ。
これはメタプロセスでプロセス自体よりも重要度は高いでしょう。常にプロセス改善は狙っていけってことなんでしょうねぇ。
２割削減プラクティスってのもノウハウとして有能なディレクターあたりは会得してそう。
公理：仕様は必ず削減される
プラクティス：なら自分で削ったほうがまし(^_^;
ってなカンジか(?_?
投稿者: 永遠の三等兵 | 2005年10月24日 07:28
DAKINIさんや他の方の発言にかこつけて、自分の考えていることを述べているだけのような気がしますが、もう少しだけお許しください。
＞公理：仕様は必ず削減される
私が言う「２割カット」は、最初に作られた仕様を１０割としてそこから２割さっぴくという意味の発言ではなく、
作業が進行するにつれ明らかになっていくそのゲームの理想形を１０割としてそこに２割およばない、という意味である気がします。
公理：仕様は変更される
これのプラクティスとしては、将来必ず起こる仕様変更に対応できるよう柔軟に組んでおく・早い段階で仮でも動くものを組んで、仕様が適切なものであるか見
えるようにする、だそうで。
ゲームソフトは仕様通りに作ってもものにならないのが特徴なので（「作ったけど面白くない！どうしよう！？」というのは現場でしょっちゅう耳にします）
ウォーターフォール型は成立しえないと私は考えています。
確立されたタイプのゲームをそのまま作るのでないかぎり。（そして、そういうゲームはすでに消費されきっていて売り物にならないと思います）
念のために、はなからいいかげんな仕様を許すという趣旨の発言ではないです。
仕様はその時点での最善をつくさなければならないのは当然で、それでもこうなるという認識でおります。
投稿者: キノコ人間 | 2005年10月24日 07:28