aumo開発のエンジニアとPdMの連携

aumoのプロダクトマネージャとして、日々エンジニアの皆さんと関わっている伊藤です。

aumoに入社し4年目で、まだ開発チームの人数が少ない頃から、生方さんや村田さんを中心に企画や開発の連携を進めてきました。

aumoがメディアだけでなく、SaaS事業に参入していくというところで、エンジニアの採用を強化しています！

そこで、今までの開発フローをより多い人数のメンバーが関わり、多くの機能開発、改善を進めていく必要があるので、今までの開発スタイルやフローを変えていく必要があります。

今まではエンジニアのメンバー含め、少人数かつ長く在籍しているメンバーも多かったことから、よくある阿吽の呼吸、で解決していった部分が多々ありましたが、プロダクトをより速く、力強く進化させていくために、より科学的な開発フローに則った連携を進めています。

機能の企画のやり方や開発フローは、オールマイティに通用するゴールはなく、常に目的に即した改善とチームメンバーとの合意と連携が必要だと思います。とはいえ、何もないところから改善はできないので、その土台づくりを進めて、日々エンジニアの皆さんと改善しているところです。

エンジニアの開発体制については村田さんが以前こちらでまとめてくれていますので、今回はaumoのエンジニアとPdMがどういう風に企画とエンジニアが連携しているのか、をご紹介できればと思います。

aumoのPdM業務

まず、PdM（プロダクトマネージャ）とは、について。
aumoのPdMも、PdMに求められるところとして重要な、なぜ（Why）何を（What）いつ（When）どのように（How）作るのか、を決め合意形成をして実行していくことが業務の中心です。
名の通り、プロダクト全体に責任を持つべきというところで、どのように（How）作るか、をエンジニアのメンバーと検討し、ユーザーストーリーや目的を達成するために最適な機能とスケジュールを決め関係各所と連携をしながら実行していくというところも含まれます。
PdMという言葉もここ数年で一般的になり、幅広い業務を多くの方々が必要なスキルや進め方についてまとめていますが、PdMは、なぜ作るのかをチームとしても、会社全体としても確からしい答えを見つけ、それに関わるあらゆることをして、リリースされた機能に責任を持つ、ことが根幹だと考えています。

関わる人も多い職種ですので、週次、月次の定例会議を設置することでメンバー間の連携をリズムよく進めることができるようにしています。

なぜ（Why）、何（What）を作るのか

日々モニタリングしている数値や、ベンチマークとのプロダクト差分から課題発見をしていきます。後に書くように、エンジニアと検討する定例会議を定期的に設置しているので課題とやりたいことの共有を細かくしていきます。

KPIの設計や分析もここで必要になるので、プロダクトのデータ構造や分析するために必要なクエリを書くというところは、非エンジニアでも理解し使えるようにしています。

特に社内のエンジニアのメンバーに、依頼している、発注元と外注先の関係にならないように、目的の合意は必須です。

そのため、週次で事業状況を共有する定例会議を実施し、マクロな事業の方向性を開発チームで認識を揃えています。また、こちらも週次で事業ごとのプロダクトに関する定例を実施し、チーム全体が個々の課題を理解している状態を目指しています。そうなることで、事業会社の開発チームのパフォーマンスと存在意義が格段に向上します。

ドキュメント化も目的の共有する方法のひとつとして重要で、少人数で進めてきたこれまでは、スピードを優先し細かく資料を残すことはしてきませんでしたが、今後の開発チーム拡大に際して注力していきたいところです。できる限りフォーマット化し、情報の抜け漏れや認識のずれを防いでいます。下の画像のような形です。

今までJIRAやconfluenceといったAtlassianの管理ツールを使ってきた経緯もあり、基本的にツールの思想にあったフローを土台に、実態にあったやり方へ関係者と調整をしていっています。

aumoが今後進めていくSaaS事業のプロダクトをなぜ（Why）なに（What）を作るのか、は生方さんが下記で紹介しています。

PdMが語るaumoにおけるSaaS開発

いつ（When）どのように（How）作るのか

なぜ（Why）、なにを（What）を作るのか、が決まり、認識が揃ったところで、いつ（When）どのように（How）作るのかを決めていきます。大きな粒度での開発計画は役員を中心に経営レイヤーとの合意をするためにも、数ヶ月単位での開発スケジュールを組みます。この段階でエンジニアのメンバーと一緒に話すことで、技術的な課題や必要な工数感について検討し、計画のズレを最小化するようにしています。とはいえ、事業状況によって優先度が変化することは当然ありますので、大体の見積もりでざっくりと線を引いています。

個々の開発については、目的を達するためのいわゆるMVP（Minimum Viable Product）を理想としています。1日でも早く価値あるプロダクトを世に出していくことが重要なので、どのようにどこまで作る必要があるかは、リリース後、プロダクトの振り返るべきポイントに絞った要件で進行することが多いです。

一方、あまりに小さなリリースにしすぎると、開発の手戻りや非効率な連携になる可能性があるので、PdMとエンジニアで、なぜ（Why）、と、どのように（How）、作るのかを双方から効率の良い要件になるように議論しています。

リリース後

新しく開発した機能が世に出て、事前に設定していたKPIが取れるようになっていきます。ここの数値も都度の事業ごとの定例会議でエンジニアメンバーに理解してもらえるように共有しています。リリースされた機能がどういう風にユーザーに使われ、どんな良いことがあったのかを知ることはエンジニア冥利に尽きることだと思います。良い数字が出たときはみんなで拍手してお祝いしたいですね。

この辺りの数値を分析することで得た示唆から、またなぜ（Why）なにを（What）作るのかが決まってきます。事前に開発チーム全体で認識を揃えているので課題のキャッチアップのスピードは日を経るごとに早くなっていき、効率的になっていきます。続ければ続くほど効率的になるフローにしていくことは重要ですよね。

最後に

このように、PdMはエンジニア含め関係するメンバーと最善なプロダクトを最速でリリースできるようにしています。プロダクトの改善と同じように、開発に至るまでのプロセスの改善も終わることがないものだと思います。プロダクトを使ってくれるユーザーのためにも、より良い開発プロセスにしていければと思っています。

aumoでは、一緒により良いプロダクトにしてくれるエンジニアやPdMなど多岐に渡って職種を募集しています！

少し話をしたい、だけでももちろん大丈夫ですので是非お声かけいただければ嬉しいです。お待ちしています。

募集職種を見る