グループに拡大していくFunctionチームのRoadmap/Missionを策定した話

こんにちは。メルペイでバックエンドエンジニアをしている a-r-g-v です。この記事は、Merpay Tech Openness Month 2022 の9日目の記事です。

この記事では私が所属している Function チームの Mission / Roadmap を策定した取り組みと、そこから学んだことについて書こうと思います。

きっかけ

メルカリがこれから成長していくにあたり、to B向け(法人向け)のプロダクトを提供することが増えています。例えば、メルカリShopsやメルカリステーションがあります。メルカリ自体が事業拡大のためにさまざまなパートナー企業さまとの接点を増やしており、法人向けの機能の開発がさかんにされるようになりました。

私が所属している Function チームである Partner Platform は事業者管理を行っています。今までは主にメルペイのコード決済やネット決済の加盟店さまの審査や管理をしていました。最近では、メルカリグループの新規サービス(メルカリShops等)でメルペイの決済システムを利用するニーズがあり、それを利用するための審査や管理などの機能開発をすることが増えています。今までメルペイ個社向けに提供していたメルペイの加盟店を審査・管理のPlatformをグループで活用するタイミングが到来したのです。

問題意識

Partner Platformがメルペイ個社向けではなくグループに使われていくチームになっていく一方で、チームがグループに対して価値提供していく方向性が定まっておらず、チームで合意できていない問題がありました。

また、各グループ会社で車輪の再発明をしてしまうと、工数がかかり都度の開発速度が低下するだけでなく、システム連携の開発も困難になります。そのため、Partner Platform が保有しているシステムをどの程度までグループに拡大させていくかを整理する必要もありました。

上記2つの問題意識から、グループに対する Partner Platform のあるべき姿を整理することにしました。

取り組んだこと

経験者に聞く

私は個社向けにフォーカスされたシステムをグループ全体に拡大させていく経験はありませんでした。そのため、どのような手順を踏めばよいかわからなかったので、既にPlatformを立ち上げた経験があるチームの人から体験談を聞きました。とても参考になったのは、 Microservice Platform チームの deeeetさん が書かれた「社内PlatformチームのProduct Management」です。MissionやRoadmapを活用したPlatformを作るための方法論やマインドセットが参考になりました。また、上記記事でも紹介されている Googleのre:Workの「Tool: Create a vision with the team」は Mission や Roadmap の役割や作成のための方法論が参考になりました。

同時に、Partner Platformが目指していくべき方向性を考える最初の一歩として、チームの最初期に関わっていた方に当初想定されていた未来像や、未来像と現状とのギャップをヒアリングしました。ヒアリングからは、Partner Platformが潜在的に解決できるユースケースが全社に知られていないため、それを伝えていく必要があることがわかりました。

登り方を決める

上記活動を通して、大まかな推進イメージを得ることができました。重要なのは Partner Plaform が解決できる課題をグループ全体に周知することであると考えました。そのためには、 Partner Platform が解決するべき課題のスコープを定め、それを説明しやすいドキュメントに明文化することが必要でした。そこで、Mission やRoadmap を作成しアウトプットすることでグループ全体に周知していくことにしました。

具体的な手順としては、まずは Partner Platformが将来を含む解決するべき課題のスコープを決めることが重要であると考えました。なぜなら、スコープを決めることができれば、それを抽象化することによって Mission を作成することができると考えたためです。また、Mission を決めることができれば、Mission と現状のギャップを解消するためのアクションアイテムをリスト化することで Roadmap を作成できると考えました。この作業を Partner Platform チームの Product Manager と Enginnering Manager と一緒に推進することにしました。

スコープの探索

まず、解決するべき課題のスコープを決めるために、各グループ会社がPartner Platformに乗ることのメリットを議論しました。メリットをグルーピングによって抽象化し、3アイテムに集約しました。

(図: メリットを議論するワークショップ)
(図: メリットを議論するワークショップ)

次に、今の責務とグレーな部分を洗い出すことによって、現在チームが提供している機能の理解を改めて深め、スコープの線引を検討するべき部分の洗い出しを行いました。この2つの観点をベースに、今提供している機能、今後提供するべき機能、提供をやめるべき機能を列挙しグルーピングを行うことで、Partner Platform が将来やること・やらないことを明らかにしました。しかしながら、この方法で決めたスコープは現実離れしていることに気づいたため、議論をやり直すことにしました。

現実的なスコープを決めるために、新規サービスを作る側の目線で再考することにしました。法人向けサービスを新規に作る上でPartner Platformが協力できることはなにか?という観点からやること・やらないことを再整理しました。具体的には、過去のグループ会社に向けた開発の例を踏まえ、もし工数的な余裕があった場合にPartner Platformがどのような機能を提供しているべきだったかを議論しました。また、既にチームがグループに提供している機能を整理し、誰に対して・何のために・どの機能を提供しているかを表に整理しました。この2つの議論の結果を整理し、チームが提供していくべき機能を決定しました。その後、機能をグルーピングによって3つに分類し、その分類を明確に線引するために、それぞれを1文で表現しました。

Mission, Roadmap の作成

Missionの作成では、これまでの取り組みでスコープを決めることができたため、Partner Platform がやるべきこと・やらないべきことが明確になりました。やるべきこと・やらないべきことを一文で表現し、それをMissionとしました。

(図: Missionの作成ワークショップ)
(図: Missionの作成ワークショップ)

Roadmapの作成では、直近2年間で着手する必要がある項目を明確化させるために、直近関係がありそうな各グループ会社のRoadmapを収集しました。その中から、策定したMissionを利用することで関与するべきことを限定し、Partner Platform が 直近グループに向けてやるべきことを議論しました。また、Missionの実現のために必要な開発項目を議論しました。この2つの議論の結果、生まれたアクションアイテムを着手時期を直近2年間のクオーターから選択した後にRoadmapにプロットしました。

成果

Missionを作ることで、チームが解くべき問題の境界を明文化することができました。そのため、チームがグループ会社に向けた開発を行う際の責務整理の指針を作ることができました。また、プロダクトやシステムの理想状態を明文化できたため、都度の開発で差分を埋める検討を行う状態を作ることができたと思います。チーム外へは、どのような問題に関心があるチームであるのかということを明示できるようになりました。

また、Roadmapを作ることで、Missionを達成するために歩むべきアクションアイテムがQ毎にまとめられた状態を作ることができました。これにより、グループへの開発とPlatformへの投資のリソース配分を検討できるようになりました。また、理想へ近づくためのアクションアイテムの管理ができるだけでなく、他チームへ将来的に取り組むことを説明できるようになりました。

一方で、当初の目的としていたチーム外への説明というアクションは取ることはできていないため、継続して取り組む必要があります。

取り組んだ感想

取り組みの改善点

スコープの議論に時間を浪費してしまう問題がありました。初回に現実的ではないアウトプットを作ってしまったため、手戻りが発生したことが原因です。要因として、チームの自己理解・分析が不十分であったためだと考えます。改めて考えてみると、まずは現状をスコープに落とし込むことに注力すべきでした。その後で将来像の議論をしたほうが効率よく進むことができたと考えます。

個人の学び

新たな視点として、中長期的に物事を見るということを得ることができたのかなと思います。短期的な開発やリアーキテクチャ等の議論では、目先の変更にだけフォーカスするだけではなく、中長期的なあるべき姿から逆算した観点を考えることの重要性に気づきました。

一方で、決めた理想像を推進していくための方法については課題が残ります。本当に使われるかどうかわからないユースケースに対しての開発を先行して行ってしまうと、無駄になってしまうことがあります。それだけでなく、そもそも直近で必要な機能開発があるため、そこに対して投資をするのは難しいと考えます。よって、そのユースケースが必要とされたタイミングで漸進的に理想へ向けて推進していく必要があるというように考えるようになりました。このためには、前もって将来的に計画している機能開発と、それにより実現されうるユースケースをまとめておき、いつでも説明できる必要があると考えます。Mission と Roadmap はこれを行うための良いツールであると学びました。

今後やること

まず、グループ全体に対して Partner Platform チームがどのような問題に関心があるチームであるかを周知していきたいと考えています。説明のための Mission, Roadmap を作ることができたので、これを活用したいと思います。

また、定めた Roadmap を実行したいと考えています。直近で必要なユースケースを満たす開発とMissionを達成させるための開発を両立できるように推進していきたいです。

最後に、Mission と Roadmapの更新があります。プロダクトやシステムを理想状態に保つためには、日頃からあるべき理想をチームで議論してストックしていく必要があると考えます。そのため、理想を継続的に議論し Mission, Roadmap へ反映させていくサイクルを回していきたいと思います。

  • X
  • Facebook
  • linkedin
  • このエントリーをはてなブックマークに追加