20代で「モンスト」開発部長に　スピード出世を遂げたMIXIエースの「マネジメント論」

　スマホゲームをやらないという人でも、『モンスターストライク』（以下：モンスト）は聞いたことがあるのではないだろか。

【画像】モンストのヒットを支えるエース社員、岡本勇太さん（提供：MIXI）

　同ゲームはMIXIが2013年10月10日にリリースし、2023年に10周年を迎えた。10年たった今でもその人気ぶりは衰えず、2023年上半期、下半期共に日本のモバイルゲーム収益ランキング1位となっている（Sensor Tower「2023年日本のモバイルゲーム市場インサイト」より）。また、2023年6月には世界累計利用者数が6000万人を超えており、日本を代表するモバイルゲームだといえるだろう。

　世界中にファンを抱えるゲームの開発組織は巨大だ。そしてそんな組織の中で、29歳という若さで部長に就任したエース社員がいる。2018年に新卒で入社した岡本勇太氏だ。

　彼がどのようにして大ヒットゲームの開発部長に就任したのか。モンストのヒットを支えるエース社員の、その手腕とマインドをひもとく。

●20代「モンスト」開発部長の素顔

――まず、岡本さんが所属しているモンスト開発部について教えてください。

　開発部は、UIなどユーザーが実際に触れる部分を扱うクライアントグループ、裏側を担うサーバーグループ、品質保証を担うQA（Quality Assurance）グループで構成されています。正社員が45人、業務委託を含めると120人弱の規模で、日々モンストの開発を進めています。

――2018年にご入社されたとのことですが、現在に至るまでのキャリアを教えてください。

　エンジニアとして入社し、4年目でマネジャー、6年目の2月に部長になりました。

　1年目の頃、当時のマネジャーに「モンストの全ての領域に携わらせてほしい」とお願いしました。当時は自分の強みが何なのか漠然としか分かっていなかったので、それを知りたくて幅広く経験できる環境を求めていたんです。ゲームの大事なアクション、操作部分の開発や、iOS・AndroidのOS機能の実装に関わるところなど、インゲームからアウトゲームまでさまざまな業務を経験しました。

　現在は部長として、モンスト開発の「中長期のミッション及びビジョン設計」と、開発に携わるエンジニアたちのキャリアパスを明確にできるよう「評価指標の定義」に取り組んでいます。

●超スピード出世の理由

――モンストを成長させるためにこれまで取り組まれてきたことを教えてください。

　クライアントグループに所属していたときは、「いかに不具合を少なくするか」を意識して取り組んできました。不具合が起きる前にどれだけ準備ができるかが重要だと考え、対策を強化していました。

　マネジャーになってからは、メンバーが相談しやすい環境を意識的につくりましたね。

　当時は開発の相談をする場が少なかった上に、私がマネジャーに就任したタイミングで新型コロナウイルスの感染が広がり、リモート勤務が増えたことでその課題が顕著に表れたんです。そこで週1のKPT（振り返りのフレームワーク）の導入や、社内チャットで気軽に相談できるチャンネル（場所）を用意しました。

　また、案件の担当者をアサインする際、相談者とペアでアサインする「ペアアサイン」を取り入れました。新卒者やコミュニケーションが苦手な方も、最初から相談できる相手と共にアサインされるので、現場での問題解決がスムーズになる体制を整えたんです。

――組織内のコミュニケーションや働きやすさに焦点を当て、工夫されたのですね。ペアアサインなどのアイデアはどのように考え出したのでしょうか。

　いろんなところからヒントを得ていました。週1のKPTやチャンネル作成は、別グループのマネジャーがしていたことを参考にしています。

　ペアアサインに関しては、相談できる人がいないという現場の声が多かったからですね。最初は「チームのリーダーに相談すればいいのではないか」と思っていたのですが、コミュニケーションが苦手な方はリーダーに相談できないという問題がありました。そこで、最初から相談者をアサインすればいいと考えたんです。問題を個人の責任にせず、仕組みから解決しました。

――不具合の防止や組織内のコミュニケーション改善などの取り組みが評価され、今の立場に至ったのですね。

　当時のマネジャーいわく、「案件に真摯（しんし）に取り組む姿勢を評価した」とのことでした。私が100％不具合を出さないことを目指していた点、また、それを他の人の案件も含めて取り組んでいたことが評価されたと思っています。

　他の人の実装を積極的に見て、なぜそのような実装をしているのかを考えたり、自分では思い付かない実装方法を見て解決策を発見したりもしていました。自分自身が学びを得ると同時に、関係者同士での連携の質も高くなりましたね。こうした行動が、自分とモンストの成長につながったと思います。

●個人・組織を成長させる「手を抜かない」マネジメント

――部長となった今、日頃の業務やマネジメント、部下とのコミュニケーションで気を付けていることはありますか。

　部長になってからは、たとえ些細（ささい）なことでも自分の考えや思考していることをなるべくマネジャー層と共有しようと意識しています。

　私自身もまだ部長になって日が浅いので、やるべきことを整理している段階ですが、その中でもマネジャー時代にはない気付きや視座が得られることが多くて。それは今のマネジャーにも持っていてほしいものでもありますし、マネジャー時代の私が知りたかったことでもあります。

　また、私はマネジャーの頃から、グループ内で関係性を高めるコミュニケーションを意識していました。マネジャーという立場を生かして年上の方には経験から生まれる良い考えや実力を引き出し、年下の若手にはラフに話しながらその内容を伝えるなど、円滑なコミュニケーションが生まれるようにしていました。

　例えば、ミーティングの場で年上の方が強い意見を言うと若手は質問しづらくなります。そういう場合、何を言っているのかを私が聞き返して分かりやすく変換するようにしたり、若手が発言する際は私から質問を投げかけて話しやすい状況をつくったりしました。

――マネジャーに就任されて以降もかなり円滑に業務を回されていらっしゃいますが、これまでの取り組みの中で失敗した経験、挫折したことなどはありましたか。

　マネジャーになったタイミングで、現場から手を引くのが寂しいという思いから開発業務も頑張ってしまったことです。マネジメントと開発を半々で取り組んでいたのですが、結果的にマネジメントの質がすごく下がってしまい、メンバーの悩みなどがくみ取れていませんでした。業務自体は回っていたので、気付くのが遅くなってしまったこともよくなかったです。

　そのときに、マネジメントは手を抜こうと思えば抜けてしまうということに気付いたんです。例えばメンバーから出てきた悩みが個人の問題であれば、その人自身を成長させていくことで対応できるでしょう。しかし、開発フローに問題があることで個人の悩みが出やすい状態にある場合、マネジャーが手を抜いては根本的な解決はできません。

　対応すべき課題が「グループ」や「開発のフロー」といった大きな単位になると、対応するコストやカロリーは高くなります。だからといって手を抜いてしまうと、その場しのぎな中途半端なアクションとなり、お茶を濁すだけになってしまう。

　業務を回すことよりも、個人や組織が今よりも成長するにはどうしたらいいかを考えていくのがマネジメントのやるべきことだと認識を改めました。それからはマネジメントに専念できるよう、自分がしていた開発を他の人に委譲したり、すぐに委譲できない場合は中長期で考えて体制を整えたりしました。

●エンジニアがキャリアパスを描ける組織作り

――最後に今後の展望をお聞かせください。

　今考えていることは、エンジニアのキャリアパスについてです。エンジニアは一般的に、マネジメントを担うのではなく、スペシャリストとして成長していきたいと考えている人が多い傾向があります。これはモンストの開発部も同様です。だからこそ、よりスペシャリスト志向のキャリアパスを描き、成長できる強い組織体制にしていきたいと考えています。

　そんなキャリアパスが、今の開発組織ではまだ描きづらいと思っています。モンストのような大規模なプロダクトになると、「運用」といわれる業務がすごく多いんですよね。そうすると必然的に管理や安全にするための判断が増えるため、マネジメント的な要素が強くなります。こうした環境下では、エンジニアは「これ以上技術的に成長するにはどうしたらよいのか」が考えづらくなってきてしまう。

　ですが、私としてはエンジニアの皆さんにはマネジメントを意識してもらわなくてもいいと考えています。どちらかというと、必要なのはリーダーシップなんです。ここで言うリーダーシップとは、将来的な状況をイメージして戦略を練り、チームと協力し全体をモチベートする力のこと。高い技術力を持っているけれど「マネジメントはやりたくない」と考えているエンジニアには、ぜひこの力を身に付け、スペシャリストを目指していってほしいですね。

　当社の等級制度は6段階あって、4段階目でジェネラリストかスペシャリストを選ぶことになっています。そこで自分がどちらに進むかを選ぶのですが、結局、「今いる部署で自分としてどちらの方が活躍できるか」を優先して考えてしまうことが少なくないと思っています。

　自分に技術力があるかと問われると、それほどではないかもしれない。でも最近は運用業務の方が多いから、マネジメントはしたくないけれど運用という形でもう少し手助けしていきたい。そんなことを考え、ジェネラリストの道を選ぶのは本質的ではありません。

　だからこそ、自社のエンジニア一人一人が、明確なキャリアパスを描けるような手助けや後押しをしていこうと考えています。