「配属当初はできないことのほうが多かった」　入社4年目でマネージャーになったモンスト開発者が語る、業務への向き合い方

イベント説明とスピーカー自己紹介

サンペイアヤノ（以下、サンペイ）：みなさんこんばんは。The Methodの時間がやってきました。本イベントは、モンスターストライクを運営するミクシィが主催する、世の中にあるさまざまなプロダクトにおいて実践されているメソッドやノウハウを、惜しみなくみなさんに発信、共有するイベントとなっています。

司会はミクシィのモンスト事業本部、サンペイアヤノがお送りします。どうぞよろしくお願いします。さっそくですが、本日のスピーカーの岡本さんを紹介したいと思います。本日はよろしくお願いします。

岡本勇太氏（以下、岡本）：よろしくお願いします。私はモンスターストライククライアント2グループでマネージャーを務めている、岡本勇太と申します。2018年から配属されて、これまではストライクショットや新規コンテンツの実装など、複数の領域を兼任して開発してきました。今日はそういった部分のお話もできればいいかなと思っています。本日はよろしくお願いします。

サンペイ：お願いします。それではさっそくここから本編に移りたいと思います。今日はThe Method初、ミクシィでのモンストエンジニアのキャリアについてということで、お話ができればと思います。それでは、あらためて岡本さんお願いします。

そもそもキャリアとは何か？

岡本：本日は『「モンストをつくるひと」がキャリアについて振り返ってみた』というところを話していこうと思うんですが、キャリアについて振り返るという部分に関して、「キャリアって何なんだ？」みたいなところを、僕自身がまず考えました。

一般的に、仕事や経歴や就職、出世などのイメージで使われることが多いですが、働くことに関する部分では、継続的なプロセスや生き方などの意味合いになるとわかりました。

この発表の話をもらい、自分自身でもあらためて考えてみましたが、僕自身、ふんわりと「おもしろい体験や価値を届けたい」みたいなところと、「そのためのスキルは身につけていきたい」という思いはありつつも、マネジメント方向に進みたいのか、スペシャリストになりたいのかというようなキャリアについては、しっかり考えてはこなかったと思っています。

ただ、数年後にどうなっていたいかの視点では考えていたところがあったので、そういった部分に関して話していこうと思います。

それが、配属時に当時のマネージャーと立てた、半年、1、2、3年後の目標になります。

（スライドを指して）この下の4枚の画像は、実際に書いていた内容をスクショして撮ってきたものです。これを見ると、あまりしっかりと考えられているものではないことがわかると思います（笑）。実際達成できていないものもあるし、判別できていないところもあります。

当時のマネージャーにも言われましたが、そもそも3年後って誰にもわからないということ。目標とずれているからといって良いか悪いかではなく、自分自身がその期間を過ぎてどうなっているかを振り返る、すごくいい指標になりました。

これがこのあとに話す、成長するきっかけみたいなところにつながる部分が多く、この目標に沿って行動していた面が大きかったと思っています。

モンスト開発について

さっそくモンスターストライクとの関わりも含め、振り返っていこうかと思います。まずモンスト開発がどういうものかを説明します。クライアントグループは現在23名で、マネージャーは僕ともう1人の2人体制で構成されています。

中身は大きく担当領域が分かれていて、1つはストライクショットや友情コンボなどを実装する、ギミックの領域です。もう1つが、新規UIや作成ロジックなどの実装を改善するUIの領域で、さらにAPIの通信処理やiOS、Androidのネイティブ周りの開発などに携わる、システム領域に分かれています。

さらにそれ以外に、モンスト以外のアプリという部分で、台湾版モンストの開発やモンスターストライクスタジアムの開発を支えるエンジニアの方々がいます。

これをもとに、開発にどう関わってくるかと言うと、ふだんは開発バージョンという1つのバージョンに区切り、そこに対してどういったものを案件として載っけるか、施策内容や優先度などを含めて挙げられていきます。

一つひとつの案件ごとに、最初に詳細に議論するキックオフが開かれます。企画担当やエンジニア、デザイナー全員が参加して、施策の背景や仕様詰め、実装懸念をお互いに認識を共有して、実際に開発を進めていくところにつながっていきます。

開発が開始したら、QA開始までに、企画やデザイナー、エンジニア、VFX（Visual Effects）それぞれが、期待する機能を実現するために仕事をしていきます。エンジニアにとっては、必要なデータや素材をそれぞれのセクションと密にコミュニケーションをとって進めていくかたちになります。

企画が確認して、QA確認まで無事終わったら申請して、最終的にリリースされ、ユーザーのみなさんのもとに届けられるかたちになっています。

今のは一例というところもあり、案件の工数や内容によっては、数バージョンにおよぶものもあったりします。他にも、クライアント発信で提案する場合もあり、その場合は、キックオフの前からどのバージョンを入れるかを相談しながら進めることになります。

さらに言うと、担当領域の部分によっては、すごく密に作業するところもさまざまです。特にギミック開発は、VFXと密に連携して、品質と実装の両方を微調整しながら進めていくことになります。この話は過去のThe Methodで話されているので、詳しくは見てもらえればと思います。以上が、モンスト開発の簡単な流れです。

配属からマネージャーになるまでの携わり方

実際に自分自身がこれまで何をしてきたかに関して話していこうと思います。自己紹介でも伝えたように、僕は複数の領域を兼任してきました。配属してすぐに全部の領域を触らせてもらうよう、お願いしたためです。

というのも、自分自身が何を極めたいのか、何が好きなのかがわからない状態だったということもあり、とりあえずやってみて、極めたいものが見つかればそれをより深めていくつもりだったので、「全部を触らせてください」とお願いしました。

結果的に、マネージャーになってからはギミック開発からは離れてしまいましたが、マネージャーになるまでは書いてあるとおり、SS実装や新規UIの実装、モンスターストライクスタジアムの開発のサポートなど、本当にすべての領域に携わって開発できました。

（スライドを指して）これを見ると、「え？」と思う方もいると思いますが、実は僕は2021年4月まで、まだリーダーでもなかったんです。マネージャーという業務以前に、リーダー業務もよくわからない状態から、マネージャー業務を今しているかたちになります。

リーダーになる前からマネージャーになるまで何があったのかに関して軽く説明すると、ちょうど2021年4月末に前任のマネージャーが退職されるということで。僕自身は4月からリーダーをお願いされていましたが、後任として、2人マネージャー体制の1人に推薦してもらいました。

その理由としては、いくつか評価してもらった部分がありましたが、そのうちの1つが、このあと話す案件に取り組む姿勢につながってきます。もちろん、僕はリーダー経験すらないのですごく不安でしたが、やはり経験として持っておきたい部分でもあると思ったので、引き受けて今に至ります。

実際の業務で言うと、4月はリーダー業務兼引き継ぎ期間、5月から今まではマネージャー業務というかたちで、1on1やモンストにおける日々の開発のマネジメントというところや、どういう人を採用しようかという人員計画みたいなところなど、幅広く携わっています。

マネージャーになるまでの過程ではできないことのほうが多かった

マネージャーになるまでの過程は、ほぼリーダーでもなかったというところですが、どう案件に取り組んできたかに関しては、僕自身は配属からできないことのほうが多かったと今でも思います。

配属当初は、慣れるまで本当に苦労しました。モンストという長期運用ゆえの規模の大きさというところもありますが、やはり規模が大き過ぎてわからないことがすごく多い。それを質問しようにも、なかなか萎縮してしまうようなところがありました。

これは、8年以上積み重なってきた仕様やコードという部分ももちろん、自分の理解が浅いのか、難易度が高いのかみたいなところの判断ができる材料をかき集める部分に対して、かき集めたものもこれがあっているのかと自信が持てなかったところがすごくあります。

それを質問しようとなるとSlackなどを使うわけですが、これだけ関わってくる人が多いと、Slack投稿1つをとっても、僕自身にとってはちょっとハードルが高かったです。

特に質問というコミュニケーションは、質問と回答の連続だと思いますが、お互いの理解度が高くないと、会話を続けるのがすごく難しくなってしまうのかなと考えてます。

これは僕自身が相手の意図を汲みとる力であったり、非エンジニアでも理解できる説明をする力みたいなところが足りなかった部分もあるし、身につけないといけなかったと今では感じています。

実装を読み込む部分で大変だった点と解決のための行動

その手前の実装を読み込む部分で大変だったところもあります。僕自身、モンストに配属されて、ほぼ初めてC++を触りました。学生時代はUnityというゲームエンジンを使っていて、C#を触ることが多かったんです。

C++はほぼ触ってこなかったので、ポインタの概念を学ぶところから始めました。最初のうちはいろいろな人から教えてもらうことが多かったと思っています。実際に実装を読んでいくのに時間がかかるし、質問に行くのにも、ちょっとハードルが高くなったというところです。

さらに言うと、経験や慣れで言語化されていない部分は、仕様1つ、修正1つとっても多く、そうなってくると、自分自身の判断材料にするのが難しくなってくるんです。

「これはどうしてこの実装になっているのか？」みたいな理由は、調べたとしても言語化がされていないと追うのは難しく、覚えたら済むものですが、実際に使ったり、調べるまでわからないところが多かったです。

これをどうがんばって解決していくかですが、最初のうちはできることからやっていきました。

最初は、コードを読み込んで、自分の担当以外の知識を補完していくところをやっていた感じです。僕自身は、コミットベースで追うようにし、どうしてその実装にしたのか、その実装にした理由を調べるようなことをしていました。答えがあって、解説を求める感じを続けることで、自分自身の知識を補完していき、スキルレベルのアップにもつながっていたと思います。

このコミットベースで追っていたことは今でもメチャメチャ役に立っているなと感じていて、このおかげで不具合報告などを積極的に拾えるようになっていったと思います。なぜかと言うと、最初のうちは「この不具合の原因がわかればいいな」と思って手元で調べていましたが、コミットベースで追っていると、不具合が起きた時にどういう差分が影響していそうかというようなところが、自然と心当たりがつくようになってくるんです。

「あの時入れたあの差分が影響しているんじゃないか？」のように、原因箇所を特定するスピードが上がるのにもつながりました。

ある特定の実装が、ぜんぜん違う実装に紐づいているというような、関連箇所にも気づけるようになっていきました。このように気づける部分が多くなると自分の知識の自信にもつながるし、判断材料みたいなところにもつながってきます。

コミュニケーションの部分は他のメンバーの方々のやり方を真似て、トライアンドエラーで慣れていくというかたちでがんばっていきました。

提案の経験を積んで、広い視野を持てるようになった

このように慣れていった部分も多いですが、さらに提案する経験も積んでいきました。これが大きかったなと思うのは、自分自身の提案が優れていたかどうかは置いておいて、提案して初めて、開発する上で重要なことや、モンストとして何を重視しているかみたいなところが、自分自身にない視点で考えられるようになったからです。

「影響範囲やQAコストはどのくらいかかるの？」とか、「それだったらベストな対応より、もうちょっとベターな対応でもいいんじゃないか」とか。

「そもそもユーザーにとってうれしいことなのか」「今後の開発の上で重要なものなのか」みたいなところの優先度の大きさなど、こういった視点が増えることは、自分自身が課題を見つけてそれを解決につなげる動き方というところで、すごく広い視点を持って動けるようになったと感じています。

欠かさなかった丁寧な実装の意識とコミュニケーション

さらに案件との向き合い方の部分で欠かさなかったのは、丁寧な実装の意識です。ふだんゲーム開発をしていく上で、“バグはつき物”と言われていますが、自分自身は100パーセントバグを出さないところを目指しています。

これは実装時点やQA時点で気づけたものは絶対あると思っていて。それは「振り返れば改善できるものが多くある」と思っているからです。ただ、それは慣れてきた時に理解したつもりになってバグを生み出すことにつながってくるので、仕様の変更や機能拡張などを含め、常にバグを出さない意識をアップデートしていくようなところを、欠かさずやっています。

特に、モンスト開発では案件ごとにチケットと呼ばれるものがありますが、チケットベースのやりとりも、人一倍丁寧に書くように心がけています。対応内容であったり、不具合原因、影響範囲、QA観点など、QAや企画担当に向けて説明する部分も多いですが、雑に書きたくなると思うほど、自分自身の実装理解が甘いと気づけます。これが丁寧に書けるようになってくると、より理解度が上がっていくかたちになっています。

また、コミュニケーションの部分でも重要視しているのが、委ね過ぎないことです。企画やデザイナーはプロなので、そこの領域に関しては任せるというのはもちろんあります。

ただ、背景や理由などの部分を自分自身でも理解した上で、「それって実装コスト的にどうなのか」とか、「こういうふうなかたちはどうなのか」と提案して、よりよいかたちにつなげていくのが大きいかと思っています。実際に、これがコミュニケーションをとらなくていいという理由にはならないから、というのもあります。

できることを当たり前に、そしてそれが強みに

ということで、これまでのキャリアについて振り返りましたが、どうだったでしょうか。もちろん配属当時からいくつか課題はあって、僕自身できないことも多かったですが、最初はできることからやっていって、それを自分にとっての当たり前にしていきました。

それがいつの間にか強みになっていて、現在のマネジメントに携わるチャンスにつながっていったかと感じています。もしこれからエンジニアを目指す方々であったり、マネジメントに興味がある方の参考になれば幸いです。

また、モンスト開発に関しては、モンストでしか経験できないところが多くあると思っています。もちろん改善しないといけない課題もたくさんあるし、今後運営を続けていく上で、向き合い着手していかないといけないという意識ももちろんあります。

そういった環境はすごくエンジニアとして成長できる場所でもあると思うし、そういった組織にしていきたいとも思っています。エンジニアとしてのやりがいや、成長できるチャンスをたくさん作っていければいいなと思うし、僕自身それを作っていきたいと考えています。今日の発表でモンストにも興味持ってもらえたら幸いです。以上が発表になります。ありがとうございました。

サンペイ：ありがとうございます。