24歳、若手マネージャーがチーム形成をどうやって実現した？ ～エンジニアのマネジメントどうしてる？ #11～

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

第11回目は、次世代エンターテインメント事業本部 TIPSTAR開発部 システム2グループのマネージャーを務める萩原に話を聞きました。

萩原 涼介
TIPSTAR開発部 システム2グループ マネージャー
2018年にエンジニアとして新卒入社。minimo で Web版サービスの改善やサーバサイド開発を経験。2020年7月にTIPSTARに異動し、API開発や運用業務に従事。2021年4月にTIPSTAR開発部システム2グループのマネージャーに就任。

マネジメントとして意識しているのは「情報の透明性」

━━萩原さんのチーム概要について教えてください。

TIPSTAR開発部には、主に新機能の開発をミッションとするシステム1グループと、「ユーザーへの価値提供速度を向上する」ことをミッションとする私達のシステム2グループがありまして、私達のチームでは、開発着手までのリードタイムや開発後のリードタイムをどれだけ短くできるか検討を行うことや、ユーザーからのフィードバックを受けて、改善プロセスをより早く回していくことが主な役割です。

━━2グループは改善をメインにしているということですね？

そうですね。実際にコードを書くという改善もあれば、仕組み・ルール・ワークフローを作るというアプローチ面の改善もあります。検証用アプリの開発時間を早くするための施策や、サーバーサイドのアプリケーションをデプロイするまでの時間を短くするための改善策等に取組んでいます。私が以前所属していた『minimo』の遊撃チーム的な組織を、新たにTIPSTAR開発部内に設立し、そのマネージャーに私が就いた形です。

━━メンバー構成や役割分担はどのようになっていますか？

チームは私を含めて6名で、メンバーには私より年上の人間もいますし、同期や新卒1年目のメンバーたちによって構成されています。私自身はサービスをより良くするために、色んなチームと関わり合って、何が課題で、どのように解決していくのか道筋をたてるのが得意なタイプ。メンバーたちの方がエンジニアリングスキル的には正直全員私よりも上でしょう。そうした技術力の高いメンバーと一緒に、見出していく課題の質を高めること、そして解決するための手段として、よりよい技術を選択していき、最適な体制を作るのが私の役割だと認識しています。

━━チームのマネージャーに就任するあたり、心がけたことはありますか？

私自身が「情報欲しがり」のタイプだったこともあり、「情報の透明性」を高めることは意識しています。今どういう動きが『TIPSTAR』内にあって、これからどういうアクションが起きていくのかは、誰もが興味がある部分なので、共有できる情報はなるべく早くメンバーに渡そうと心がけています。スピードが求められるものはSlackで即座に、それ以外は週次の定例でまとめて共有しています。ポジネガ両方とも1週間以内には実施していますね。

━━スピーディーですね。

それによってメンバー側から先んじてアドバイスをもらえることもあるでしょうし、メンバーとの相談もしやすくなるだろうという狙いがあります。TIPSTARは事業規模が大きくて、情報共有までのスパンが長くなってしまうこともあるので、なるべく自分が持ってる情報はコンスタントに共有するようにしていますね。

━━情報を共有する / しないの判断って難しくありませんか？

そうですね。特に組織としてのアクションが見えてきたタイミングで伝えるようにしています。検討中のものについては判断が迷うことがありますけどね。実際にマネージャーに就任してみて「共有できる情報」には限界があるんだな…ということに難しさを感じています。情報の内容によっては「ノイズ」として混乱の基になってしまうこともありますし、同じ情報であってもメンバーによって受け取り方が異なるので難しいですね。

━━伝え方にも工夫が必要なんですね。

組織としての大きな流れはグループ定例で共有し、隔週で実施しているメンバー毎の1on1では、それぞれのメンバーにアジャストした内容を伝えるようにしています。例えば「数字の全体感を知りたい」というメンバーに対しては、答えられる範囲での数字の共有に加えて数字の読み方も伝えますし、「組織体制について漠然とした不安があります」というメンバーに対しては、今の体制にはどのような思惑があるのか背景の部分まで説明するように心がけています。

━━けっこう細かいケアをしているんですね。

結果、メンバーが率直に意見を言ってくれるようになったと感じています。なるべく早く情報を共有し、メンバーの意見を聞き、それを意思決定が必要な場で発信する。それによって、メンバーの声が反映されたり、メンバーに対してフォローしたりすることができていることは大きい。

また、「何でも聞いていいんだ」と思って安心感を持ってもらう事にもつながっているはず。聞かれたことには素直に回答するようにしているので、メンバーによる意見や質問があることは、素敵なことですし、議論が活発なグループだなと思います。

━━チーム形成に手ごたえあり、ってところですかね？

まだまだ苦慮していることはありますけどね。マネージャーになってからは色んなチームと関わることが増え、ミーティングで得る情報量が大きく増えました。情報はどんどんメンバーにパスしているつもりでいたのに、実際にはちゃんと伝わっていなくて「え？そんなの聞いてないですよ！」ということがたまにあります。

「伝えていこう」という意志だけではどうにもならなくて、ミーティングに参加したら、共有できる情報はなるべくSlackにメモを残すといった工夫も必要だなと痛感しています。

メンバーの「目線」を合わせ、グループミッションを明文化

━━萩原さんがマネージャーに就任後、最も苦労したことは何ですか？

システム2グループには技術的に尖っているメンバーが多いので、それぞれが個人事業主のように案件を請け負っていくことには長けているのですが、グループとしての成果を発揮するためには「目線合わせ」が必要だと思い、最初の半年間はグループとしてのミッションを明文化できるよう、メンバー同士での議論を重ねてきました。その結果として生まれたのが「ユーザーへの価値提供速度を向上する」というチームミッションですね。

━━どのように実施されたのでしょうか。

ミッションをみんなで考えました。 1on1 や定例の場で部署やプロダクトといった上位目標をもとにミッションをブレークダウン。より高い視座で、何が今、組織・サービスに対して求められているのか、というブレークダウンであれば、メンバーが納得感を持ってくれると考えたからです。

━━確かに納得感は増しそうですね。

もう一つは、そのミッションをしっかり、 評価軸やフィードバック・取り組む課題と紐づけしたことですね。上期の評価や下期の目標設定の軸として「チームミッション」を明確に用いるようにしました。ユーザへの価値提供速度…と僕が何度か口にすることでメンバーも意識することができていると思いますし、個々の課題に取り組むときもチームミッションが自分事化して取り組んでくれていると思います。

━━グループのミッションが明文化されたことで、どのようなメリットがあったんですか？

例えば「テストコードはなるべくたくさん書いた方が良いから書こう」というイシューがあった時に、エンジニアとして「やりたいことドリブン」でアクションを起こしがちですが、その前に「そもそもテストコードを充分書けていない理由は何なのか？」を深堀りし、真の課題は「仕様がはっきりしていないから」じゃないか？…といった具合に、ミッション視点で課題を捉えられるようになりました。

私達の主な役割は、新機能を開発することじゃないので、ユーザーに直接機能として見えるアクションにはなりにくいのですが、ユーザーへの価値提供のサイクルをどんどん回していくこと自体がポジティブなアクションなんだという意識が、議論を重ねたことで醸成され、チームとしての統制がとれてきたと思います。

最近ではみんながそれぞれ課題に取り組むときに、「これによってこういう効果が見込めます」としっかりと説明をしてくれるようになっていて、かなり効果が出てきているんじゃないかなと思います。

━━話は変わって、理想とするマネジメントのスタイルはありますか？

組織体制の話になりますが、私は組織間の繋がりは「疎結合」であるべきだと思っています。例えばサービスの企画チームとエンジニアチームが密に結合しすぎていると、リリースのタイミングがなかなか決められない…ということがありますよね。それでは大変なので、必要最小限のコミュニケーションはとりつつ、それぞれのチームが意志を持って自走できる体制づくりができると良いなということを最近は考えています。

『家族アルバム みてね』開発グループの酒井さんも言っているように「あっちのチームが終わらないから、自分のタスクに取り掛かれない」「向こうのチームの事情を知らないから決められない」といった状況に陥らないように、それぞれのチームに適切な責務を任せて、影響範囲はなるべく最低限にして走れるようにするスタイルが理想的ですね。

━━なるほど。では今後マネージャーとして取り組みたいことはありますか？

メンバーの「課題発見能力」をブラッシュアップしていきたいですね。表層に見えている課題に対して、その根本を紐解いていくスキルをメンバー全体で向上していきたいと考えています。例えば「TIPSTARのテストコードが書きづらいのはなぜだろう？」という表層的な課題に対し、根本にあるのは新機能開発の進め方の問題かもしれないし、開発チームのオンボーディングのやり方の問題かもしれないし、レビューのやり方の問題かもしれない…といった具合に、色んな課題に分解して深堀りしていくやり方を、1on1などでの壁打ちを重ねていくことで、メンバー自らが気付ける瞬間を増やしていきたいと思っています。

━━萩原さんの理想像としては？

将来的にそれぞれの組織で課題解決できるようになるのがベストなので、極論ですが、システム2グループが暇になった時が、私達の目標を成し遂げた時と言えますよね。早くそうなれるようにしていきたいです（笑）。

今回の学び

萩原にマネジメントについて聞いてみたら、こんなポイントがありました。

「グループミッションを明文化し、真の課題を深堀りして捉える」

エンジニアとしては、目の前の諸課題をいち早く解決するために、やりたいことドリブンで手を動かしてしまいたくなるもの。萩原は「ユーザーへの価値提供速度の向上」こそがグループとしてのミッションであることをメンバーとの対話を通して浸透させ、本当に取り組むべき課題を深堀りできるチームの構築に取り組みました。

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