説明｜【QCDS】ゲームの話にかこつけて仕事の話をしようかな
開発現場のメランコリー
何かしらのプロジェクトに関わり始めると出てくるのが『QCDのバランス』というフレーズ。
すなわち、
Q（Quality）…品質
C（Cost）…費用
D（Delivery）…納期
の３つに
S（Service）…サービス
の視点を足したのが『QCDS』。
今回はわかりやすい有名どころのゲームを取り上げながら、それぞれの開発現場に思いを馳せてみたいと思います。またの名を妄想といいます。
実際その場にいたわけではないので、事実とは異なることをご容赦ください。あくまでも『QCDS』の概念を説明すると言った感じです。
1｜Quality 「こだわり」を捨てるのか？
誰だってお金と時間さえあれば湯水のごとく使って品質を上げたいんです。納得の行くまで磨き上げたいんです。
しかしそれは許されない…！会社ならお金と時間にも限りがあるし、インディーなら時間はあってもお金が足りない、何よりユーザーが待ってくれない。
故にみんなの第一目標でありながら、最も切り詰めることになる部分が「品質」です。
まさしくそれをやっていたのは記憶に新しい『ゼルダの伝説 ティアーズオブザキングダム』でしょうか。
素敵なおヒゲのおじさんが謝罪するだけの動画が世界で何百万と再生されるぐらいユーザーの期待値が高い作品でした。
（リンク先：「『ゼルダの伝説 ブレス オブ ザ ワイルド』続編の発売時期に関するお知らせ」）
不足していたお金と時間を確保してブラッシュアップにブラッシュアップを重ねたことは容易に想像できます。
しかし、人気作品なのに発売を延期する…納期を犠牲にするデメリットは軽視できません。大作だから、前作が最高だったから、あの人が頭を下げたから…などの世間が我慢できる見込みがあって、現場では初めてデメリットの許容を検討できるようになります。
何でもかんでもお金と時間をかければ良くなっていいこと尽くめとは言えないところが難しいところですね。
2｜Cost 無い袖は振れない
費用を抑えて高い品質のものを作れたら。これを体現できる可能性があるのはインディーゲームでしょうか。ただ個人で出せるお金はよっぽどのことがない限り多くはないのでやむを得ず、というパターンが多くを占めています。
お金が出せないとき、そのゲームはアイデア勝負になります。だからこそ尖った作品が生まれやすく面白い世界。逆にコスト度外視で自分の作りたいものを作るのもインディーゲームならではだと思います。
組織立って開発する場合はなかなかそうもいきません。プロジェクトには定められた予算があり、基本的にその枠内でやりくりをすることになります。予算を超えそうな予感がするときに予算を増やすか、他の何かを犠牲にするかの検討を行います。大体において後者です。
だからこそ個人にせよ企業にせよ、費用は守るべきルールの一つであり、コスト面のクリアを目標には掲げていないと思います。（そう思いたい…。）
3｜Delivery 迫りくるデッドライン
納期は費用と同じく守るべきルールであって、達成すること自体を主目的には据えません…。が、そうも言ってられないゲームはあります。
みなさまご存知『ポケットモンスター』シリーズです。調べると、ほぼ毎年ゲームタイトルかDLCを発売してコンテンツを提供し続けています。
おそらく開発チームが複数あるのでしょうが、計画〜テストまでのスケジュールをどうやり繰りしてるのかこっちが知りたいぐらいのリリースペースです。
現場が納期第一！と具体的には掲げていないと思いますが、必ず毎年何かしらのイベントごとがあります。その理由は想像することしか出来ませんがおぽのの友人が結構鋭いことを言っていました。
「ポケモンは他メディアの展開が多いため納期をずらすこと自体ができないのでは？」と。
なるほど。アニメ、グッズ、その他あらゆる広報によって外堀が埋められている状態で、屋台骨たるゲームを発売しないという選択肢はない、ということは有り得る話だと思います。
納期を守るゲームは、たとえギリギリまで障害があってもゼロデイパッチ（発売初日と同時にゲームをアップデートすること）で間に合わせてくる周到さがあります。
この他にもホビー展開の多い作品やマンガ・アニメなど原作付きのゲームは、基本的に発売を遅らせることがやりにくい事情がそれぞれの現場にあると想像できます。
4｜Service 世に出てからが始まり
サポート、サービスですが…プロジェクトの特性によって安全性（Safety）や顧客満足度（Satisfy）などのように意味がブレる第四の要素です。
ゲーム開発の場合、発売後の視点が重要になると考えているため、おぽのは”S”を「サービス」として語ります。品質が達成目標ならサービスは継続目標にあたるのです。
オンライン要素のあるゲームは、特にこの観点を無視することは出来ません。ユーザーからは長期的なサポートと、対戦ゲームならバランス調整まで求められます。当然費用も嵩みます。
製品を作って終わり！とはいかないのが今のものづくりの宿命。それに加えて、ユーザーをずっと引き止め続ける力を生み出さなければなりません。
『ゼルダ』『ポケモン』と挙げたなら、思い浮かべるのは『Splatoon』の開発現場でしょうか。
四半期に一度、カタログ更新の名目で新要素の追加に加えて月々のバランス調整を繰り返す、いわばずっと走り続けているような現場なのでしょう。
オンラインゲームのユーザー数はピークを超えた辺りからどんどん目減りしていくものです。それを少しでも食い止めるためか、開発現場は短いスパンで計画〜製造〜テストを回しながら、追加要素を何度も出し続けることになっているのです。
鮮度を落とさないため、そのような手厚いアフターケアを行っている作品は少なくありません。しかしいくらなんでもシャトルランが過ぎるよ…。
おわりに
昨今のゲームが発売されると同時に騒がれるのが、バグ発見報告。「テストプレイ」や「デバッグ」なんて言葉はもはや当事者である開発現場だけではなく、一般ユーザーも当たり前のように意識する時代になりました。
デバッガーの悲鳴のようなエピソードはこのネットの海に散見しています。おぽのが読んだ範囲だけの話ですが、皆さんまちがいなく誇張はすれども嘘はついていないと思っています。
こういった現場の“生の声”を知っているおかげでユーザーの中には過敏なほどバグ報告に反応する方もいます。
そのような時に一つ言えることは、すべての現場が人を摩耗させる基準でやらないといけないのかというと“△”です。
やるべきでしょうが、現実的ではありません。
なぜそんなことが言えるのか。
現場に近い人間だから庇い立てするつもりなのか。
多少のバグを許せってことなのか。
ではなくて、『QCDS』の例で挙げた通り、開発環境の全てが修行のような過酷な基準ではないですよ、こういう考え方がありますよ、というお話がしたかったのでした。
教科書に則ったようなお手本と、ちょっとかじっていればわかるような入門的な『QCDS』を語らせていただきました。プロジェクト傾向を抑えると想像できることも増えていきますね。
色々遊んでいると、個人でこんな作品ができるの！？とか、この作品気合入ってて最高だったな…という出会いもたくさんあります。それもこれも、品質の向上を諦めないでくださったことが想像に難くありません。
それがゲームという作品群の魅力の一つでしょう。