プライベートでゲームを作る際に企画兼ディレクター兼プロデューサー職みたいなことをやったから書いてみる。
ここに書くことはゲームに限ったことではないと思う。
私の本業はエンジニアなので本業の人から見ると未熟な点が多いと思う。
私が担当したチームは3人から初めて10人弱まで大きくなった。
ここで書いたことと３割ぐらいかぶってる。
"開発効率とゲームの面白さをあげるために、私が同人ゲームのチーム開発でがんばった１０個くらいのこと"
http://www.slideshare.net/shinsemiya1/ss-48614980
ということでディレクターとして気をつけたこと８つくらい。
ビジョンを作るためにプロトタイプ作り
「こんな感じの超かっこいいプロダクトを作りたい！」というビジョンを決める。
たたき台やプロトタイプを練っては壊し練っては壊しを繰り返す。
このフェーズは考えをまとめるレベルなので、短時間で作れるプロトタイプがいい。
ペーパープロトタイピングみたいな「誰でも作れる、すぐ作れる、アイディアを言葉から視覚化できる」ものが便利だと思う。
このプロダクトを一言で言うと「xxx」みたいなキャッチコピーができれば完成。
全員でブレストに近いレベルでアイディアを出し合い、踏み固めて結論の方向に全員の足並みと体の向きを揃えるのが目的。
また状況が変われば計画も変わる、リリースすればそれだけ新しい事実が浮かぶため、この作業は最低でも隔月のペースで行った。
ここにかける時間をケチると、最後でブレる。逆にここで時間をかけると最後までぶれずに最初のトップスピードまでの加速がスムーズになる。
ゴールを明確にし、ゴールまでの段階とシナリオを考えておく
ゴールは「売上xxxx本、xxxジャンルのトップジャンルに上り詰める」みたいな数値を伴った目標になる。
数字が出まくる企画書が書けるレベルまでのことはこの段階で考えておいた。
次にそのゴールにたどり着くまでの段階的な作戦レベルの目標を考えておくこと。
「ユーザーを100人集める」「売上を保ちつつプライスアップして黒字化し、リリースサイクルを早める」「販売チャンネルを増やして新規ユーザー数の増加させユーザー数1000人を狙う」みたいな段階ごとの目標を決める。
山登りの行程表に近い。
注意したのは「第一段階でAとBの機能のリリース」みたいな機能ベースの目標にしないこと。
手段であるはずの機能をリリースすることが目的となって、本来狙いたかったユーザーの確保などの目標への意識が薄れるから。
この作業も同じく隔月単位で見直しを行った。
特に販売チャンネル系に関わるものは相当レベルの見直しが入ったため、見直しは必須だと思う。
また気軽に目標を変えられるので気軽に野心的なチャレンジングな目標設定を行える点は大きい。
リリース単位で狙うものを絞る
「新規ユーザーへの訴求」「ゲーム性の向上」「販売チャンネルの拡大」などやりたいことは大量にあったが、リリース単位で狙う目標はできるだけ絞って、多くの兎を追わないようにした。
同時に狙う目標が多いと往往にしてそれぞれの目標達成に必要な機能実装などが競合したり、意識しなければいけないものが増えるので、作業効率が落ちたから。
とにかくリリース単位で狙うものは絞った。
また、今回のリリースはどの作戦目標達成のための布石なのか、布石をうつ作戦目標は最終ゴールまでのどの位置づけになるのか、という地図確認に相当する行為を隔週で行った。
目標を絞ることで効率は上がるが、効率を下げてでも物量で多くの目標を狙うのは企業で体力があればアリだと思う。
ただし物量で押そうとするとチームの規模が拡大したりチームをまたいだ構成が必要になるのでマネジメントコストがあがったりリスクが増えたり別の問題が出ると思う。経験的にはそうなった。
ホラクラシー型チーム
ホラクラシーはAmazonが採用している組織構造、らしい。
この組織構造をとった。
プロダクトの開発に必要な役割があって、それぞれのロールに人間をおいた。兼務は可能だが１つのロールの権限は大きく、１つのロールを複数の人間が同格で務めることはない。
ロールを受け持つ担当者はプロダクトについて担当領域を大きな裁量で決めることができる。自分で決めた仕様のため責任感が大きくなり、逃げないし強いやる気を発揮して高い開発スピードを維持できた。
また、担当領域がリリースで狙う目標への貢献への意識を強く持たせるため、リリース目標の決定や数値の設定にも強い発言権を与えた。
数値目標の設定
「計測できないと改善できない」byトヨタ
リリース目標、作戦レベルの目標はすべて数字を設定した。
ただし、数字が読めない場合、「信頼性の低い数字を設定した。達成できなかったがもともとの計画の数字の信頼性が低いため仕方がない」=>「誰も数値達成できないことを問題視しなくなる」という問題や「数値達成が絶対目標化し、プロダクトの価値を劣化させてでも数値目標を達成させようとする」という問題が以前勤めた業界ではあった。
そこで、２点締切に近い２点数値目標をおいてこの問題を回避した。
なぜ成功したか、なぜ失敗したか、あるいはなぜ当初の見積値が間違っていたか、という問題を考える過程でメンバーのプロダクトと周辺環境への理解、および当事者意識が急速に成長した。
また、数値設定時点で各人に見積値を出させると「なぜその数値が妥当と考えたかの根拠」をいうため、各人が「ドメイン知識を深める」「誰がその領域に知見を持つか明確化される」というメリットがあった。
「何を知り、何を知らず、その上でどう考えるか」
すべての計画を立てる上では情報が必要である。
計画実施するための情報をどの程度自分が持っているか、またどの情報がないことを知らないか、その上でどういった仮説を立てるか、を重視し、周囲にも伝えた。
計画実施に必要な情報が揃っていればそれは予定された成功の収穫であり、情報がまったくなければそれは投機や賭博に近い。
しかし現実には必要な情報をすべて揃えられない。
理由は二つある。
１つは情報の収集による利益と収集にかかるコストのあるため。そのため、効率と必要を考えながら適当なところで折り合いをつけることが必要になる。
もう１つは自分が持っていないことを知らない情報を意識して収集することはできない。定期的に行動のフィードバックを受けながら状況に関する認識を見直す必要が有る。
戦意大事
アメリカでホーソン実験というのがあって、「高度な作業を効率的にやるためには作業者のやる気が大事」ということがわかった。
「今回のリリースは全体の戦略目標達成のためのどういうフェーズのための布石なのか、また、自分の作業はそこでどういう役割を果たし、完成すればユーザーにどういった価値を届け、どういった利益を受け取る予定なのか」という点を全員が言えるレベルまで浸透させることで全員の当事者意識とモチベーションを高く保った。
また、「リリースによる目標達成の成功率」を高く保ち、成功体験を経験させることで自分の苦労は報われるという信頼をメンバーに与えるよう勤めた。そのためにディレクターとして計画の練り込みや情報の収集には手を抜かなかった。
会議重要
チーム間のコミュニケーションは重要だが、だらだらと時間を食いつぶさないように会議自体の目標の明確化や時間制限など「短時間で効率の良い会議」を狙った。
「今回の会議で話すことは戦略レベルなのか、作戦レベルなのか、戦術レベルなのか、あるいは技術や情報の検証についてなのか」という点は必ず明らかにし、主題とそれるディスカッションが長く続く場合は強制介入で打ち切った。
時間内に終わらない場合も容赦なく打ち切った。続きは次回ってことで。
そうすると最終的な時間あたりの成果は高くなる。
また夢が膨らみ会議が際限なく続くことも防げる。
ただし、状況によってエンドレスに続けさせたほうがいい場合もある。さじ加減大事。エントロピーが上がった時はエンドレスにしたほうがいいと思う。
プロセス信仰の否定
プロセスはなにかやりたいことがあってその目的達成のための手段として導入される。
プロセスを導入しただけでは効果は得られないし、時には形骸化することもある。
プロセスは遠慮なく変えた。
ただし最初は有志による一部導入にして成功した場合のみ導入させることにした。また、導入者には定着までリードさせて定着の責任をもたせた。