自分だけで考えるより、チームで考えたほうがいいものが産まれる ～エンジニアのマネジメントどうしてる？#16～

ひと口にマネジメントといえど、そのスタイルは様々。チームメンバーや部下、組織や技術、やり方も多彩にあります。このシリーズでは、“エンジニア”のマネジメントを担うメンバーに焦点を絞り、「エンジニアマネジメントってどうしてる？」と悩みや独自のやり方などを赤裸々に語ってもらい、メンバーの多種多様な“マネジメント観”を中心に、そのノウハウをお届けしていきます。

第16回目は、『モンスターストライク（以下モンスト）』の解析・分析に携わる吉野曜介に話を聞きました。

解析と分析、２つのチーム

━━まずはじめに、吉野さんのグループについて教えて頂けますか？

私がマネージャーを務めている解析グループは、解析チームと分析チームの2つのユニットで構成されています。前者の解析チームはエンジニアが所属するチームでモンストを始め様々なサービスのデータ基盤の構築や運用が主なところ。続いて、分析チームはアナリストが所属するチームで、エンジニアが構築したデータを活用して分析を行い、施策の振り返りや効果測定を行うビジネスの側面も強いチーム、という感じでしょうか 。

━━大まかにいうと、エンジニアとアナリストが同じグループにいると。

もちろん、アナリストも開発の裏側については把握しておかなければいけないし、エンジニアもデータ分析業務を全くしないというわけではないのですが、大きく分けるとそうなりますね。メンバーとしては解析チームが３名、分析チームが３名と、私を入れて計7名で業務を行っています。あと現在は内定者アルバイトなど、２名在籍しています。

━━モンストのユーザー数に対しては、小規模なように感じますね。

そう感じられるかもしれませんが、私が入社した2017年には、まだグループほどの規模でもなく、私を入れて３名のエンジニアチームという規模でした。その頃から考えると、人数は倍以上になっていますし、分析に特化したアナリストのメンバーも増えました。今となってはモンスト以外のサービスにも関わることも多いので、今後もチーム規模として大きくなっていく可能性はありますね。

目標はメンバー全員で決める

━━マネジメントで悩まれていることもありますか？

まず解析グループは、解析チームと分析チームの２チームに分かれていて、かつ職域も少しずつ違っています。なので、メンバー間でグループとしての共通認識を持ってもらうことは意識しています。

たとえエンジニア同士でも、ひとつの課題に対しての問題意識は人によって違いますし、同じくらいの問題意識はあったとしても、着眼点や想像している解決方法は当然人によって違いますよね。それに加えて、解析グループはプログラミングやデータ基盤運用など技術的な側面が強いエンジニアと分析やビジネスの側面が強いアナリスト、とそもそものロールが違うメンバーがともに業務に就いているわけです。

当然のことではありますが、私たちが一つのグループとして機能するためには、「グループとしての目標」を精緻に言語化して、一つの場所を目指せるようにしないと、今何をすべきか、というところを見誤ってしまう可能性があります。なので、お互いの業務で何をどう行っているのかといった共有の会はまめに実施していますし、コミュニケーションを取る際に、私が常に念頭に置いていることでもあります。

━━「グループとしての目標」は具体的にどう共有していくのでしょうか？

私が解析グループのマネージャーになった３年前は、事業本部の方針をうけて、私が目標を決めてメンバーに伝えていました。でも、トップダウンのような決め方では、メンバーに目標が浸透していない感覚があって…。２年目には、メンバー全員で目標を決めようと、方針を変えました。

そこで下敷きにしたのは、事業本部のマネージャー陣で集まって実施したデザインスプリント*です。メンバー全員で、自分たちの所属するユニットが事業部においてどのような役割なのかを再確認するとこから始めて、それぞれが感じている課題を全て出しあって俯瞰する。優先度をつけ取り組む課題を決め、その期に実施してみて、検証する、といったプロセスです。このプロセスを解析グループに合わせてすこし改変して、皆で目標を決めるようにしています。

*デザイン思考を通じて、課題を解決するための5段階のプロセス。
（1）理解（2）発散（3）決定（4）試作（5）検証のフェーズにわたって、一週間などごく短い期間で実施されることが多い
https://www.gv.com/sprint/

━━実際やってみてどうですか？

少なくとも、私１人で考えてメンバーに共有するよりも遥かに課題や目標が浸透しやすいなとは感じます。タスクの優先順位も、「なぜ今これが最も優先度の高い課題か」といった背景まで理解しながら全員で進めていくので、メンバーの皆さんも納得しながら取り組みやすくはなっているのかなと。まだ課題はありますが、職域の異なるメンバー同士だからこそ、会話して目標をともに決めていく意義がとてもあるように感じています。

常々思うのは、自分だけで考えるより全員で考えた方が絶対いいものができる、ということでしょうか。トップダウン的なアプローチでメンバーに伝えるよりも、全員で共通認識を持って取り組めた方がより多角的な課題が見えてくるし、解決の糸口も見つかりやすくなるんですよね。最初は段階的なやり方にすこし手間も感じますが、解析グループではこのやり方でうまくフィットしたのではないか、と思います。

今回の学び
吉野のマネジメントには、こんなポイントがありました。

・まずは自分のチームの性質を理解する
・職域の異なるメンバー同士でも同じ目標を持てるよう、目標を決めるプロセスから変えてみる

ひとえにデザインスプリントさえ実施すれば問題解決！ということではなく、まずは問題に取り組む姿勢、フレームを変えてみることで、メンバーの取り組みやすさが大きく変わる、という話は印象的でした。

このシリーズでは、引き続き、MIXI GROUP内の“エンジニアのマネジメント”の実態やノウハウを紹介してまいります。