本記事は、サムザップ Advent Calendar 2019 #1 の12/7の記事です。
サムザップでゲーム開発のチーム作りを担当しています。
そのなかから、メテオフォールに対抗するための組織作りをなんとなく考えていたので、ここで紹介できればと思います
##■メテオフォール開発とは?
適切な開発手法を採用していても、要望や修正依頼などが隕石のごとく振ってきて、いろいろなプロセスが壊されたり、そもそも何を作るんだっけ?という状況になることを「メテオフォール開発」と言います。
EIKI氏、へっぽこ氏(@heppoko)により提唱(http://eiki.hatenablog.jp/entry/meteo_fall) されて以来、開発問題のわかりやすい概念として注目を集めています。
ゲーム開発においては、こうした隕石は当たり前のように降ってきます。しかもこの隕石はよりよくしようという「善意」なのです。決して業務を妨害しようとして隕石振らしているわけではありません。
そして、この隕石は遊べるようになったり姿が出てくるようになると、より強く降ってくるようになる傾向があります。また、チームの内外、立場問わず、隕石はやってきます。
この隕石に当たっても生き残り、お客様に楽しくてクオリティの高いゲームを作るにはどうすればよいでしょうか?
##■学ぶものはどこからか
いにしえの知恵にも学ぼうとしたら、Linux等のフリーソフトの開発が思い当たります。たとえば『伽藍とバザール』に書かれているバザール方式での開発の場合、だいたい「バザールの長老」みたいな人がいて、その人が取り仕切っていたりします。これは「ゆるい独裁者スタイル」などと呼ばれるこの方式で、いくつも著名なソフトウエアがこの方法で育ちました。インターネット上でやってくるリクエストの荒波を超えてきたソフトウェアたちです。この方式を真似てみると、隕石が降ってきたときに対処できそうです。
また、昨今の開発スタイルのトレンドを見ていると、たとえばティール開発のように「あるがままに」というのがキーワードになりそうです。隕石を振らせないようにするよりは、「隕石はあるもの」「あるがままに振ってくれ」として「隕石が来た時にどう柔軟に対応できるか」を考えたほうがイマふうな気がします。
##■メテオフォールへの具体策
それではこれらをベースに、実際に私のチーム内で行ってきた具体策を書いてみます。
###覚書
「これから何を作るのか」というのが箇条書きでもいいので、まとめたものを作ります。細かく書く必要はなく「この機能はベンチマークしているゲームのこの部分を元に、このように追加したもの」程度の内容でかまいません。
これをチーム全員で見て、だいたいのイメージをつかんでから作ります。
これが柱となります。この柱が太ければ、隕石に当たっても折れません。
私のチームでは初期にこれをプロデューサーが示してくれたおかげで、だいたい2か月ほどでほとんどの機能を作成することができ、それをベースにして調整していくような感じで作ることができました。
###コアメンバー
最初は少人数で作り始めます。そこから、少しずつ足りないところを補うように人を集めていきます。スキルが足りなければそれを補える人、年寄りばかりであれば若い人、みたいな感じで「人の組み合わせ」を考えて人を加えていきます。
いきなり人を増やすより、コアメンバーがいろいろ動けるようになってからのほうがよい結果になりました。たとえば、よくうちのコアチームで話しされていたのは「何を採用するかではなく、何を採用しないかのほうを考えてた」ということでした。未検証のものにより検証されたもの、ユーザー数が少ないものより多いもの、サードパーティーより公式のもの、というように優先順位をつけて技術をふるいに落としながら採用していました。それが整ってから人を入れたことにより、あとから入ってきた人にも「なぜこの技術なのか?」というのがわかりやすく、これがとてもよかったように思います。隕石もこれでほどよく打ち返せてました。
###メンバーのスケール
よく隕石が来たら「人を追加すればよい」という動きがされます。安易に人を増やすのは、隕石を受けやすくなるだけなので、あまりお勧めできません。問題が明らかなとき、人海戦術が必要なときにそれに見合うスキルの人を動員していきます。
スケールさせるためには、「ルール」と「マニュアル」です。これをコアメンバーで決めて展開できれば、適切にスケールできます。
###対応を決めてしまう
あまりにたくさんの隕石が来ると、その対応に手間取ってしまい、チームが機能不全になることがあります。そんなときは、「場」「時間」「対応者」をまとめてしまうとよいでしょう。
たとえば「リストにまとめて書いてください」「この人が担当なので聞いてみてください」「この時間の間はすぐやります」などなどです。
よく映画であるような「俺がこの隕石を押さえているうちに、早く!」みたいなノリです。必要な開発をこれで先行させることができました。
###早く正確に作る
隕石を打ち返すためには、それを圧倒できる制作スピードが求められます。隕石より早く動ければ必ず撃墜できる、という理屈です。
これには、人を増やしたり、作成物の内容、制作者のスキルアップ等、できることは多いのですが、結局のところ「作る前の情報」が正しければ、作り直しやヌケモレがなくなり、結果として早く作れます。
私のチームでは事前に機能単位で仕様のレクチャーを受け、そこで作るにあたってあいまいなところを指摘してなくしたり、企画者の意図を組めるような場を「説明会」として用意しました。この効能はそれなりにあり、それ以前と比べて、あまり大きな変更はなくなり済みました。
■隕石を楽しく打ち返そう
「覚書」と「コアメンバー」によってゆるい独裁者スタイルを取ることができ、柔軟性は「メンバーのスケール」で吸収しつつ、「対応を決めてしまう」「早く正確に作る」ことで、いろいろな隕石に対応できました。
こんなことをして、もうすぐリリースを迎えようとしているのが、私のチームです。
隕石すらも楽しんでしまう「どんとこーい」の精神で、これからもゲーム作りをやれたらいいかなと思っています。
明日は @ikutaNさんの記事です。