正しい下積みを経験していない若者が、リーダーになるとゲーム開発チームが苦労するというお話
あるゲーム会社に、新卒の若者が入社しました。
彼は高学歴ということもあって、とても頭の回転が速く、仕事を指示されると業務の本質をすぐに理解し、先輩顔負けのクオリティで成果物を出してくれました。
さらに人柄も良く、コミュニケーション能力も高かったので、将来を有望視されました。
そして彼はその期待に応え、入社わずか3年でディレクターに抜擢されました。
とても順風満帆といった感じでしたが、しかし、いかに優秀な彼でも、ディレクターに就任するには、3年という期間は短すぎたようです。
正しい下積みを経験していなかった為、非常に不幸な事件が起こり、ゲーム開発チームが苦労をしてしまいました。
■有望株を育てるという抜擢
「彼をディレクターに抜擢しよう」という方針は上層部が決めました。「彼を育てたい」という思いがあったからです。
筆者はその考えに賛成でした。
能力のある若者は、慣例にとらわれず、どんどんチャンスを与えられるべきだと思っていたからです。
しかし彼はまだ入社3年目。
社歴はもちろん、ゲーム開発経験も不足していました。
その事は無視できない懸念材料で、悩みどころでした。
そこで上層部は、彼をディレクターに抜擢するに際し、プロジェクトマネージャーには経験豊富なベテランを充てがうことにしました。
それが筆者でした。
筆者は彼に好印象を持っていましたし、彼も筆者と親しくしてくれていました。
そして筆者は上層部の「彼を育てたい」という方針にも大賛成でしたので、自分がプロジェクトマネージャーを務めることを喜んで了承しました。
この時は「愉快なゲーム開発が始まったぞ」とウキウキしていました。
■順調なゲーム開発
ゲームの開発期間は15ヵ月でしたが、開発は非常に順調で、12ヵ月間は特に問題なく開発が進行しました。
もちろん仕様変更やスケジュールの調整、各部署間での摩擦など、ゲーム開発にはつきものといった問題は数えきれない程ありました。
しかし、そうした問題には筆者が対応し、解決をしていました。
ですので「問題もなく開発が進行した」と申しましたが、正確には「問題なく開発が進行するように筆者が問題を解決していた」という状況です。
しかし、いよいよリリースまで3ヵ月と期日が迫った時、ついに筆者（プロジェクトマネージャー）の権限では解決できない問題が発生してしまいました。
■プロジェクトマネージャーの権限では解決できない問題
リリースまであと3ヵ月となった時、計画していた仕様の1つが実装できないという事態になりました。スケジュールの残り期間が足りなくなってしまったのです。
この仕様以外にもゲーム要素はいくつもあり、それらについても仕様の内容を見直したり、スケジュールを調整したりして対応をしてきました。
その為、かなり多くのゲーム要素を実装できたと筆者は自負しています。
しかし、最後の最後で、この仕様に関しては、調整の限界を超えてしまったのです。
仕様をオミットしなければならなくなったわけですが、仕様をオミットすると製品のクオリティが下がります。その為、その判断はプロジェクトマネージャーの一存では決められず、ディレクターの承認が必要でした。
そこで筆者はディレクターである彼に相談をしました。
元々が「なくてもゲームは遊べるが、ないよりあった方が絶対に良い」という優先度の仕様だったので、彼も「やっぱりちょっと多くを求めすぎましたね」とわかってくれました。
そして仕様のオミットはすんなり承認されました。
彼が聡明で、話を理解できる人物だったので助かりました。
この時も彼は「仕様のオミットは容認できません。なぜなら製品のクオリティが下がると、売り上げも下がるからです。ですので、なんとしてもリリースまでに実装してください」とは言いませんでした。
こういう事を言って相談ができないディレクターは世の中にたくさんいるので困ります。
もちろんディレクターの立場であればそう言わざるを得ないでしょうが、そんなことは分かった上でこっちも話をしているので、つっぱねないで欲しいものです。
筆者は自分がディレクターをやるときは、絶対にこういうことは言わないぞと心に誓っております。
それはさておき、この時は彼がそういうことを言わなくて本当に良かったと思いました。
しかし、同様の仕様のオミットが翌月にも2つ発生してしまいました。
やはりリリース前ともなると、どうしてもこうした仕様のオミットが発生してしまうものです。
しかし、先月と合わせて合計で3つで済んだことは、むしろ非常に珍しく、ゲーム開発経験者であれば、いかにこのゲーム開発が順調であったかをご理解いただけるかと思います。
因みに、その2つの仕様も「なくてもゲームは遊べるが、ないよりあった方が絶対に良い」という優先度のものでした。
※この時の優先度
Ｓ…この仕様が実装されないと、ゲームとして成り立たない。
Ａ…この仕様が実装されないと、ゲームの面白さが大きく損なわれる。
Ｂ…なくてもゲームは遊べるが、ないよりあった方が絶対に良い。
Ｃ…開発に余裕があったらやる。もしくは別の優先度のタスクに対応する際、ついでにできるならやる。
彼に仕様のオミットを相談したところ、今回も無事、了承してもらえました。
しかし、「事件」が起こってしまったのです。
「事件」というのは、彼が上層部に「筆者がプロジェクトマネージャーとして仕事をしていない」という具申をしたのです。
■なぜ具申されたのか？
上層部から呼び出された時、筆者は驚きました。
「筆者がプロジェクトマネージャーとして仕事をしていない」とはどういうことなのか？
また、それを具申したのが彼であったというのも驚きでした。
しかしよくよく話を聞いてみると、彼のように頭が良く、聡明な人物でも、正しく下積みを経験していないと、こういうことになるんだなと理解しました。
彼の言い分はこうでした。
「筆者は問題が発生した際、仕様内容とスケジュールを調整せず、問題を解決する手段としてディレクターにオミットをお願いするしかしない」というものでした。
確かに、リリース間近になって、3つの仕様はオミットを願い出ましたが、それまでの12ヵ月間、何十、何百という問題に対して筆者は仕様内容とスケジュールを調整して解決をしてきました。
それなのに彼は筆者が問題が発生したらオミットしかしないというような具申をしたのです。
これは何故だったのでしょうか？
■高等テクニックを理解できなかった
筆者のプロジェクトマネージャーとしての信条は次の通りでした。
「二流のプロジェクトマネージャーは、ゲーム開発で問題が発生した際に、うまく対処をする。
一流のプロジェクトマネージャーは、そもそもゲーム開発で問題を発生させない」
これを不言実行していたので、傍から見れば開発は順調で、問題がないように見えたのでしょう。
しかし、経験のある開発者であればわかったはずです。
問題が発生しなかったのではなく、問題が発生する前に、筆者が先回りをしていたということを。
しかし、彼は経験が不足していた為に、筆者がそのような立ち回りをしていたことを認知できず、プロジェクトは「何もしなくても」「日々勝手に順調に進行している」ように見えてしまったのです。
その為、最後になって筆者が3つの問題解決の為、仕様のオミットを相談したところ、その3つすべてがオミット願いだったので、「筆者は問題解決で仕様のオミットしかしない」と勘違いをしたのです。
■相談を受けていた為、自分に人望があると勘違いをした
彼の勘違いはもう一つありました。
それは開発スタッフから相談を受けていたことです。
筆者はプロジェクトマネージャーでしたので、以下のようなことをしていました。
①開発者が自分のやりたいことを実現させるため、スケジュールやコストを無視してアイディアを実装しようとする我がままを抑え込む。
②開発者がしんどいのでちょっとやりたくない、と思っている時に、ゲームを遊んでくれるプレイヤーの為に、開発者の背中を押して頑張らせる。
すると開発者からは以下のような愚痴のひとつやふたつは出てくるものです。
①こうしたらもっとゲームが良くなると思ってアイディアを提案したのに、筆者は採用してくれなかった。
②タスクがいっぱいでしんどいのに、筆者はさらにタスクをねじ込んで無理やり仕様を実装させた。
ここでも経験のある開発者であれば、こうした憎まれ役は誰かがやらないといけないので、ポジション的に筆者が心を鬼にして対処をしたんだな、と理解してくれるはずです。
しかし彼は、その事が理解できず、筆者は人の意見を聞かず、無理やり開発者を働かせる悪いヤツだと思ってしまったようです。
■彼の最大の勘違い
そして彼はついに「筆者がいなくても自分だけで順調にゲーム開発を進行できる」と勘違いをしてしまいます。
彼は面と向かって筆者にこう言いました。「自分の方が筆者より、もっとうまく問題を解決できる。だから筆者がいなくてもゲーム開発ができます」と。
因みに「それは何故？」と聞いてみたのですが、その時の彼の答えは「開発スタッフが筆者ではなく、自分に相談をしてくるからです」という返答でした。
彼のことを買っていたので、この返答はとても残念でした。
まず彼に寄せられていたのは相談ではなく「愚痴」です。
そして筆者にではなく、彼に相談（というか愚痴）を言う者たちは、いわゆる「不満分子」です。
言いたいことがあるなら面と向かって筆者に言えばよいものを、それができないので彼にこっそり陰口を漏らしているのです。
なぜ筆者に直接言えないのかというと、自分たちの意見が、自分の我がままであったり、単なる怠惰であるなど、後ろめたいものであるという自覚があるからです。
筆者は意見を受けた際、その理由や理屈が正しければほぼ間違いなくその意見を採用します。
意見が採用されないのは、理由が不純であったり、理屈が通っていないからです。
そしてその事を本人たちも理解していて、「これは筆者に言っても到底通じないだろうな…」とわかっているので、筆者の目を盗んでコソコソと彼に愚痴を漏らすわけです。
このように正しく自分の意見や考えをゲーム開発チームや会社組織でエスカレーションできない輩の意見は何があっても採用されるべきではありません。
しかし彼は、そんな輩から相談（というか愚痴）を寄せられたことで、自分の方が筆者より信望を集めていると思ってしまったのです。
因みに言っておきますと、筆者は彼より遥かに多くの相談を受けていました。
しかもそれは愚痴ではなく、今のゲーム開発について思う事、今のゲーム業界について思う事、これからのゲーム業界について思う事、今の会社や上司について思う事、さらにはワークライフバランスやキャリアパスなどといった内容の相談でした。
そうであるにも関わず、一部の不満分子から相談（というか愚痴）を寄せられたことで、自分の方が筆者より信望を集めていると彼が思ってしまったことは本当に残念でした。
しかし、彼がそういう結論に自らを導いたのには、あるバイアスがあったからだと筆者は見抜いていました。
それが見抜けたのは、実は筆者も若かりし頃、そうしたバイアスを自分にかけたことがあったからです。
そのバイアスとはある「心情」に起因しています。
■ある「心情」
ある「心情」というのは「自分がゲーム開発チームのリーダーになりたい」と思う「心情」です。
彼も、ついにこの「心情」が芽生えていたのです。
どういうことかというと、今回のゲーム開発プロジェクトの長はディレクターである彼で間違いないのですが、実質的に開発チームを指揮していたのは筆者だったのです。
その為、彼は特に何もすることがなく、毎週の進捗会議で「開発は順調です」という筆者の報告を受けて「わかりました。では引き続い宜しくお願いします」ということぐらいしかなかったのです。
筆者としては手本を見せているつもりでしたが、彼の「心情」としては「自分が開発チームを率いたい。リーダーとして指示を出し、自分の思う通りにゲームを開発したい」という思いが、1年ほどゲーム開発が経過した中で、芽生えていたのでしょう。
特に彼の目には、ゲーム開発がなんの問題もなく、楽々と進んでいるように見えたので「これなら自分にだってできる」と思えても仕方がなかったと思います。
筆者も若かりし頃、このような「心情」が芽生え、先輩や上司に下剋上を挑んだものです。
今にして思えば若気の至り。とても浅はかな行為でした。
当時の諸先輩や上司の皆様、本当にすみませんでした。
■潮時
それはさておき、彼も若かりし頃の自分と同じ「心情」を抱いていることを見抜いた筆者は、「これは潮時だ」と思いました。
このゲームはリリース後も運営が必要なタイトルでしたが、リリース時のゲーム内容はすでにマスター版が形成されており、あとはデバッグをしてバグをなくすだけの状態でした。
リリース後の運営についても、運営スケジュールの策定は完了していて、そのスケジュール通りに進行すれば、問題なく運営できるはずでした。その為の開発体制と開発フローも筆者が構築済でした。
そこで筆者はプロジェクトマネージャーを降り、彼がディレクター兼プロジェクトマネージャーとして開発チームを率いることを了承しました。
「了承しました」と申しましたが、筆者としてはゲームがリリースする直前で梯子を外される形となり、少なからず悔しい思いもありました。
しかし上層部に呼び出された時、すでに上層部もそういう決着にしようと方針を定めていました。考えは同じだったので、筆者もゴネはしませんでしたが、不承不承という部分がなかったわけではありません。
そんなこんなではありますが、結果として彼は筆者という補助輪が外され、ついに独り立ちをしたのです。
■そしてすぐに問題が発生する
自分がリーダーとなった彼は、筆者がゲーム開発を指揮していた時に、密かに抱いていた不満の解消に早速乗り出しました。
具体的には運営スケジュールを自分好みに書き換え、自分で考えた施策を実現しようとしたのです。
筆者も運営スケジュールを策定していましたが、その内容が彼にとっては物足りなかったのでしょう。
しかし、筆者も必ずしも自分の策定した運営スケジュールが100％完璧だとは思っていませんでした。何故なら、そこには開発スタッフの人数や能力、予算、それにスケジュールという制限があったので、その範囲の中で最大限できる施策を運営スケジュールに落とし込んだに過ぎなかったからです。
しかし彼はその事を認知できず、「運営スケジュールはかくあるべき！」と自分の理想の運営スケジュールを作成しました。
そしてその運営スケジュールを発表したのです。
当然、開発チームは騒然となりました。
まず真っ先に各職種のリーダー（プログラマーリーダーやデザイナーリーダーなど）が「今の開発スタッフの人数や能力、予算、それにスケジュールでは、それはできない」と口々に反対しました。
しかし彼は「そんなことはない。自分の計算では、これは実現できる」と反論をしました。
そして彼は、その実現方法を各職種のリーダーに説明し始めたのです。
その実現方法はこういうものでした。
「10人月の作業工数は1人でやれば10ヵ月かかるが、2人でやれば5ヵ月で終わる。だから10人でやれば1ヵ月で終わるはずだ」
ここでも経験のあるゲーム開発者なら、ゲーム開発の作業タスクは、そんな算数の単純計算で済むものではないことがわかって下さったと思います。
しかし、彼はそれがわかっていなかったので、急遽開発スタッフを増やしたり、外部会社に作業の一部をアウトソーシングしたりして対処を始めました。
算数の計算上は、毎日注ぎ込まれる水の量（作業タスク）と、その水をバケツで汲んで外に掻き出す作業者の数はイコールになったかもしれません。
しかし、小さな井戸に多数の人間が殺到すると、スムーズに水が汲みだせないのと同じように、ゲーム開発も人員や外部協業会社が増えると、そうした人員の交通整理をする「管理コスト」が爆上がりをします。
そして、そうした管理コストのしわ寄せを喰らうのは各職種のリーダーたちです。
彼らはとんでもない長時間残業を強いられ、それでも交通整理はしきれないので、結局は自らが手を動かしてタスクを片付けるなど、とても苦労をさせられました。
■そしてパンドラの箱が開く
そして筆者が最も恐れていた問題が顕在化します。
筆者は自分がプロジェクトマネージャーを降りた時、この問題が必ず発生し、大変なことになるだろうなと危惧していましたが、それが現実のものとなってしまったのです。
それまで筆者が抑え込んでした「自分の我がままを実現させたい」と企む不埒な開発スタッフたちが解き放たれてしまったのです。
その者たちは筆者という邪魔者がいなくなったのを「これ幸い」と、彼にすり寄り、言葉巧みに自分の我がままを吹き込み始めました。
＜例＞
建前：シナリオの文字数をもっと増やしてプレイヤーにエモさをお届けしたい！
本音：文字数の制限なく、自分が書きたいだけシナリオを思う存分に書きたい！
建前：BGMの効果を高める為に、ここで唄を入れよう。シーンの雰囲気がもっと良くなりますよ。
本音：BGMに唄を入れるの流行ってるし、オレもやってみたいんだよね～。
建前：キャライラストのクオリティをアップさせる為に、作業を分業化して効率化をはかりましょう！
本音：ラフとか構図（ポーズ）考案とか地味な作業はしたくない。そういうのは外注にやらせようよ。
建前：次の新キャラは女性キャラにしましょう。売上数値も男性キャラより女性キャラの方が1.8倍高いというデータが。
本音：美少女キャラが好き。美少女キャラがいい。美少女キャラしか勝たん。美少女ﾊｧﾊｧ…。
彼は自分がプロジェクトのリーダーになって、はじめて「こういう者たちの意見を聞いてはいけない。この者たちの我がままを採用してはいけない」ということは理解したようです。
しかし、筆者がプロジェクトマネージャーだった時に、この者たちの愚痴を聞き、話にうなずき、「そうか～、筆者はひどいな～。せっかく君がアイディアを出してるのに話を聞いてくれないなんて。自分から筆者に一言いっておくよ～」などと一緒になって筆者を貶めた手前、今更、掌返しはできませんでした。
彼はその者たちの側に取り込まれてしまっていたのです。
そして一部の開発者の自己満足でしかないクオリティアップが次々と計画され、実行されていきました。
無計画かつ同時多発的にこうした計画が発生した為、ゲーム開発チームは、もはや「誰が」「いつまでに」「どれくらいの作業タスクをこなさなくてはならないのか？」というスケジュールさえも定められず、とにかく目の前の作業タスクを消化していくことしかできなくなってしまいました。
こうならないように、日々、細心の注意でゲーム開発チームを制御していた筆者の努力は、瞬く間に水泡に帰してしまったのです。
■結果的に…
結果的にゲームはリリースしましたが、リリース後の最初の更新はスケジュールがギリギリで、デバッグや調整も不十分なものとなり、たちまち問題だらけになりました。
そしてその問題に対応している間にも、次の更新の期日が迫ってきます。
両方に対応しながらなんとか次の更新を乗り越えますが、そこでもまた「負の遺産」が生じ、こうした「負の遺産」は更新の度に蓄積していきました。
そしてそうした「負の遺産」が重荷となり、要所となる更新時に効果的な更新が行えず、その結果、売り上げが伸び悩み、すると予算が削減され、ますます大きな更新が行えなくなり…と、負のスパイラルに陥っていきました。
そして「サービス終了」の判断が下されてしまいます。
すると、ほどなくして彼はゲーム開発チームからも、そして会社からも居なくなってしまいました。逃げるように退職をしてしまったのです。
彼は各職種のリーダーや、我がままを言わず、黙々とタスクをこなしてくれた多くの開発スタッフから大いに恨まれてしまいました。
頭の回転が速く、コミュニケーション能力も高かった彼が、まさかこのような結末で退場することになるとは思いもよりませんでした。
彼の行き先は不明ですが、もし、どこか別のゲーム会社に再就職しているのであれば、この会社で経験したことを活かし、次は同じような事態に陥らないよう頑張って欲しいものです。
■筆者が言いたいこと
さて、その上で筆者が言いたいことは、「こういうことになるから若者には長い期間の下積みをさせるべきだ！」というものではありません。
筆者の持論は「自分が30年かけて学んだことを、次の世代も30年かけて学ばれては困る」です。
最低でも10年、今の変化が激しく、便利な世の中であれば5年で学んでほしいと思っています。
ですので期間が短いことは全く問題ありません。しかし「これは経験しておいてもらわないとこういった問題が発生する」というものは経験しておいてもらえるようにしたいです。
では何を経験してもらえばよいか？
それは「自分がこういう仕様を実装したい！」と言ったら、それを実現させるために、各職種の作業者、中間管理者、リーダーの人たちが、どういうことをして、どういう苦労をするのかがピンと来るようになって欲しいのです。
つまりは「人の痛みがわかるようになる経験をしてもらいたい」と思っている次第です。
ではそうした経験はどうすればできるのか？
…すみません…。
実はその部分で悩んでいて、答えが出ていないのです…。
いろいろ思考をめぐらしましたが、結局のところ、やっぱり「能力のある若者にはどんどん新しいことを経験させよう」しかないと思っています。
しかしそれではこれまでと同じです。
ただ、今回のことで「若者に経験をさせると判断した者は、自分もまた経験をしよう」というのは付け足されました。
今回のことは筆者にとっても勉強になりました。
どんなに高学歴で、頭の回転の速い逸材でも、だからと言って不用意にリーダーに抜擢するとこういうことになるということを学んだのです。
おそらく次、また同じような逸材が入社しても、今回のような結末は迎えないようにするでしょう。
しかしこれでは経験から学ぶことしかできないので、なんとかその前に、未然にこうした不幸を防ぎたいと思っております。
ですので、もし良いお考えや手法をお持ちだったり、実践されている方がおられましたら、ご教示いただけますと幸いです。
この記事が気に入ったらサポートをしてみませんか？