新卒入社時は技術力に自信がなかった。5年目に『コトダマン』エンジニアマネージャーに挑戦。~新卒成長の軌跡、その後 #09~

新卒入社時は技術力に自信がなかった。5年目に『コトダマン』エンジニアマネージャーに挑戦。~新卒成長の軌跡、その後 #09~

ミクシルでは、新卒スタッフの成長をシリーズでお伝えしています。どのような成功体験や失敗体験を経験し、どんな風に成長したのか?スキルやマインドの成長に大きく役立ったターニングポイントとは?について迫ります。

今回ご紹介するのは、2018年4月に新卒入社した田中です。スマートフォン向け新感覚ことば遊びゲーム『コトダマン』エンジニアグループのマネージャーとして働く上で、メンバーとして働いていたときの経験や思いに基づくマネジメントを心がけているのだとか。メンバーのモチベーションを上げる組織づくりについて、今の思いを聞きました。

田中 恭友
コトダマン事業部 エンジニアG マネージャー
2018年 新卒入社

ゲームという文化を盛り上げていきたい

━━田中さんの経歴を教えてください。

高専で情報系の学科を専攻し、卒業後に東工大の3年次に編入しました。その後、大学院に進学。新卒として2018年にMIXIに就職しました。小さい頃からゲームが好きで、学生時代には趣味でゲームを作ったこともあり、昔から漠然とゲームに関わる業界で働きたいと思っていました。

━━そもそもゲームに興味を持ったきっかけは?

高校生の頃から、対人要素のあるゲームが好きでよくプレイしていました。就職活動の時期には“eスポーツ”がバズワードになったこともあり、「eスポーツをもっと流行らせていきたい」「ゲームという文化をより多くの人に知ってもらい、もっと盛り上げていきたい」と思うようになったんです。ゲームそのものの開発にこだわりはなく、ゲームに関わるサービス全般に視野を広げて就職先を探していました。

━━MIXIを選んだ決め手は何でしたか?

会社説明会で対戦系ゲームのリリース予定や、ゲームユーザー間のコミュニティを活発化するサービスがあると聞いて興味を持ち、入社を決めました。その後、内定者アルバイトとして『モンスターストライク』の公式スピンオフゲーム『モンストドリームカンパニー(以下モンパニ)』のチームでサーバーサイドの開発に携わりました。仕事に取り組むなかで再確認したのは、「やっぱりゲーム作りは面白い」ということ。そういった経緯もあり、入社後も『モンパニ』のチームにジョインすることになりました。

━━その後はどのようなキャリアを築いていったのですか?

入社後は2年ほど『モンパニ』のサーバーサイド開発とリリース後の運用に携わり、その後は『コトダマン』のチームに異動しました。2年半ほど、スクラムチームで『コトダマン』の新規機能の開発や機能改善をはじめ、運用業務からインフラ面のメンテナンスを担当しました。

スクラムチームの中で、コトダマンをより良いゲームにするために他の職種の方と議論を重ねながら開発を進めたことは貴重な経験でしたが、長期の運用によって蓄積した技術的負債によって開発の首が回らない状態に強い課題感を感じました。

運用を自動化し、本番更新のコストを下げていくことや、メンテナンスできないレガシーな実装をリファクタリングしていくこと、その他インフラ面でも様々な課題を解決する必要がありました。スクラムチームのメンバーが機能実装と並行してこういった改善を実行することは困難でしたので、技術負債の解決を主導しプロジェクトに貢献するチームが必要だと考え、新たなチームの立ち上げを提案したんです。

そして2022年の夏にSREチームを立ち上げました。当初は私一人だけのチームだったのですが、9月からエンジニアG全体のマネージャーを担当することになりましたので、採用を通じて徐々にメンバーを増やしていき、時には開発本部のSREグループにサポートしてもらいながらようやくSREチームが本格稼働し始めようとしています。

ゆるふわ勉強会で多くのことを学んだ

━━今までで最も思い入れのあるプロジェクトは何ですか?

印象に残っているのは、『モンパニ』のプロジェクトですね。企画やデザイナー、エンジニア、QAなどいろいろなセクション間の壁がないチームで働けたことが、良い経験になったなと。エンジニアリングの観点からも、リリース後の運用フローがしっかり整っていたので、1~2年目の自分にとってはすごく勉強になったプロジェクトでした。ここで吸収したことが今の『コトダマン』でも活きています。

━━具体的に、どのようなことが糧になっていますか?

なかでも良いなと思ったのは、各セクション間の壁をなくすために取り組んだ、ゆるふわ勉強会です。もともとエンジニアが業務で使うツールの使い方やシステムの仕組みなどを共有する場だったのですが、徐々に「企画はどういう考えでイベントを設計しているのか」といった、他職種のメンバーも発表する場に変化していきました。

この取り組みを通じ、このチームにはどんな考えの人がいて、どういうところにプライドを持って仕事をしているのか、どういうところにスペシャリティを持っているのかを共有しあうことができました。この場で生まれた職種を超えた相互理解がチーム全体の信頼関係を育む土壌になったのではないかと思います。

『コトダマン』のチームも心理的安全性の高い良いチームになっているとは思います。しかし、プロジェクトの規模も大きく、多くのメンバーが所属しているので、なかなか全員の人となりを把握することは難しい状態です。残念ながら、業務上関わりが薄いチームのメンバーともなると、Slack上でのアイコンしか知らないという状態の人もいます。今後はチームを超えた信頼関係を育む場をもっと作っていけたら、さらに良いチームになれるのではないかなと考えています。

━━入社当初と比べて、成長を実感するポイントはありますか?

自分は高専時代からエンジニアリングを学んできたので経験年数自体は長いのですが、のんびりしていたタイプだったので(笑)、技術に尖ったエンジニアではありませんでした。入社当初も、同期と比べると技術力に自信がなかったくらいです。そんなスタートではありましたが、『モンパニ』や『コトダマン』などでの業務を通して、自分の得意領域を見つけられたかなとは思っています。

━━というのは?

どんな設計であればバグが起きにくいかという知見が身に付き、長年運用しても問題が発生しにくいアプリケーション開発ができるようになりましたし、インフラなど今はあまり自信のない分野もやればできるという自信がつきました。

まず『コトダマン』のプロジェクトに入って直面したのが、言語化する力でした。長期運用でメンテナンスが難しい状況を改善するための提案をするときも、「なぜこの実装は良くなくて、提案の内容はなぜ良いものといえるのか」を言語化できないと、他のメンバーに納得してもらえません。曖昧な知識しか持っていない状態では言語化も難しいため、設計に関する学習を進めていく必要がありました。そうやって試行錯誤しているうちにスキルを磨いていくことができたのではないかな、と思います。そういった好循環の中で、エンジニアとしてのスキルとコミュニケーション能力などのソフト面のスキルという両面が徐々に身に付いてきたかなと思います。

個人の力には限界がある

━━相手に伝わるコミュニケーションを試行錯誤するなかで身につけてきたんですね。

『コトダマン』のチームは、サーバーエンジニアやクライアントエンジニア、デザイナー、企画などが一つのチームになったスクラム開発体制をとっていました。そのなかで、どうしたらもっといい働き方ができるか、どうしたらもっとゲームが良くなるかと、臆せず議論を重ねていくうちに言語化する力や議論する力は磨かれたと思います。

また、本番環境で障害が発生してしまった時にリスクやバックアッププランを考えながら対応することは結構得意でした。こういった場で他チームのリーダーなどから信頼を得られたので、普段の業務においても会話をする機会が増えていきました。

━━マネジメントに興味を持ったのはいつ頃ですか?

マネジメントを意識しだしたのは、『コトダマン』のチームに入ってからです。仕事を通じて実感するようになったのは、議論が活発に進められるチームや、信頼関係が構築されているチームではないといいモノはできないということ。

また自分一人の力で貢献できる量は限りがあると思っていたので、それをスケールさせていくためには、どこかで個人の力ではなくチームの力を高めていかなきゃいけない。じゃあどうやってチームの力を高めていくべきなんだろう?と考えるようになっていったんです。また『モンパニ』も個人的には良いチームだったと思っていますが、残念ながらそれでもビジネス的には成功しなかったので、どうしたら成功するチームになるんだろう、というところに興味が湧いてきたこともあります。

これからのゲームはアジャイルな変更がカギに

━━今後の目標について教えてください。

短期的な目標としては、『コトダマン』のプロジェクトを成功させることです。課題はたくさんあるのですが、なかでも大きなものは技術的負債の解消ですね。それがプロジェクト自体の選択肢を狭めてしまっている状態にあります。

例を出すと、ガチャ機能の実装が複雑になっていて、なかなか手を入れられないんです。ガチャに新しい機能を追加したいがコストを考えると後回しにせざるを得ないという状況が続いてしまっています。本来はユーザーにもっと楽しんでもらえるアイデアがあるのに、あるいはビジネスチャンスになりうる選択肢があるのに、負債が残っているためにで実現できないというのは非常にもったいない。今はこの課題の解決に力を注いでいきたいと考えています。

━━組織やマネジメントに関する思いはありますか?

『コトダマン』のメンバーはどのチームのメンバーもひとりひとりがプロダクト愛を持って、プロジェクトを成功させるにはどうしたらいのかを一生懸命考えているのですが、チーム間のコミュニケーションのロスによって、その力を100%引き出せていないなと感じることがあります。100%の力を発揮できる円滑なコミュニケーションを、あわよくばチーム間の相乗効果でその力を120%まで引き出せるような組織を実現したいと思っています。

また、スクラムチームのメンバーが更にそのパフォーマンスを発揮できるように、他チームとの連携を改善していったり、プロジェクトの成功に辿り着くためのロードマップが見えるチームにしていきたいと思っています。

━━具体的にどのような取り組みを考えていますか?

具体的な話をすると、今まではディレクターの引いた開発ロードマップに従って、スクラムチームが機能を実装していく、その機能の詳細についてはチーム内で議論を重ねていくという流れを取っていました。それが悪いわけではないのですが、ディレクターの目が行き届かない細かい改修はどうしても置き去りになり、それがユーザビリティを下げる結果になってしまっていました。そこで、スクラムチームごとに異なるミッションを与えることにしました。

仮に今ユーザーの継続率を上げることがプロジェクト上重要なミッションであるならばユーザー継続率を高める専門のスクラムチームを用意します。このチームは現状の課題を探索し、例えば初心者のユーザーが離脱しているポイントを発見して改善することでKPIを上げていく。データに基づいた判断と、机上の空論に陥る前にまずリリースしてみよう、という判断のできるアジャイルなチームにしていきたいなと思っています。

━━なるほど。

また、新機能を実際にリリースして分かったユーザーからのフィードバックを反映して機能を改善する機会がなかなかなく、メンバーが歯がゆく思っているところも課題です。なぜそれができていないかというと、現在ではある程度ロードマップが決まっていて、新機能をリリースしたら次の機能の開発に移らなければいけないという流れになっているからです。

リリースした機能が、成功だったか失敗だったか、目標を達成できたかを計測して、さらなる機能改善に着手するべきか、あるいはその次の開発に着手するべきかをチームが決められる体制にしていきたいなと思っています。

━━そのやり方のほうが、メンバーのモチベーションにつながりますよね。

今のスクラムチームのメンバーには「あと一週間あればより良い機能にできるけど、次の機能も落とせない…」といったようなジレンマが度々あるんですよね。自分がメンバーだったときもそうでしたし、今のメンバーもそう思っているだろうなというのが感じられるので、その点は改善していきたいと思っています。

━━『コトダマン』のプロジェクト成功と、チーム内の意欲を引き延ばすチームづくりが短期的な目標ということですね。中長期の目標についてはどうですか?

ここまで5年間、ゲーム事業に関わるなかで、ゲームづくりの奥深さや面白さをひしひしと実感しています。ゲーム自体の制作にこだわらず、ゲームに関われるサービスなら何でも良いという思いは就職前のときから変わらずあって、今後もゲームを盛り上げる何かしらのサービス、アプリケーションなど、モノを作っていきたいです。

最近は継続的にアップデートして長期運用していくゲームがコンシューマのタイトルでも増えてきていますよね。リリースして終わりというゲームは、アップデートの必要がないので、たとえメンテナンスが困難な作りになっていたとしても問題ありません。そういったゲームはエンジニアリングよりもシナリオの要素やビジュアルの良さが売上に直結するのではないかと思います。

一方で、継続的にアップデートしていくゲームは、webサービスと同様に高速な変更を可能にするエンジニアリングの力がより重要になると考えています。ユーザーに長くゲームやアプリケーションを楽しんでもらうために、どんなチームが必要なのか、どんな実装であれば運用に耐えうるのか、という自分が運用タイトルで培ってきた経験を活かせるマネージャーになれたらいいなと思っています。

PAGE TOP