こんにちは、採用担当の芦刈（あしかり）です！

今回はコネヒトのプロダクト開発体制のリアルをお届けしたいと思い、CTOのいとしょさん（https://twitter.com/itosho）に開発体制の課題をどう捉え、どうデザインしてきたのかを紐解くためにインタビューを行いました。

前編はこれまでの開発体制から現在の体制に至るまでを紹介しています。ぜひご覧ください！

-------------------------------------------------------

最初に、これまでのコネヒトの開発体制について教えてください。

僕がコネヒトにジョインしたのは2017年ですが、当時は在籍しているエンジニアが10名弱でデザイナーやディレクターを含めても10名を少し超える程度の規模だったので、1つのチームで開発するスタイルでした。

そこから組織の成長に合わせてメンバーも増え、チームが15名を超える規模になった頃から、会議の時間が長くなったり、コミュニケーションコストが高くなったりという課題が上がるようになりました。そして、このまま1チーム体制を続けても開発のアジリティを維持するのは難しいと判断し、チームを分割するという意思決定をしました。

この時は「機能」毎にチームを組む形を採りました。例えば、ママリの検索機能を改善するチーム、リテンションを向上させるチームなどです。まず開発する機能を先に決め、そこにメンバーをアサインしていくという感じですね。この体制で、コミュニケーションコストに端を発した一連の課題は概ね解決されましたが、やっていくうちに新たな課題も出てきました。

どういった課題が見えてきたのでしょうか？

コネヒトでは半期単位で一つのテーマを掲げて戦略を進めるケースもあれば、サービスのフレキシビリティが高いためクォーター毎、ないしはそれよりも短いスパンで戦略が変わるケースもありました。そのため、機能を優先する体制だと、頻繁にチーム編成が変わり、担当する機能も変わることが多く発生してしまい、その都度チームに溜まった「学び」がリセットされてしまう感覚を持つようになりました。

この課題を解消するために今度はメンバーのスキルセット（Web、モバイルアプリなど）をベースにチームを組み、各チームの状況に応じて開発する機能を割り振るという体制に変更しました。

この体制に変更したことでチーム変更の頻度が以前より少なくなり、チーム内での学びも溜まっていくようになったので、よりスムーズに開発できる体制が整ったと思います。

※イメージ図（人数は異なります）

状況に応じて最適な体制を整えたのですね

そうですね。組織は生ものなので、その時その時の特徴や課題を見つめながら、どのような開発体制が事業戦略やプロダクトの成功確率を最も高められるかを常に考えて組織をつくっています。

これまで機能開発を優先した体制、その次にスキルセットをベースとした、言い換えるとメンバーを優先した体制という流れでやってきましたが、それぞれ片手落ちだなと思うこともありました。もともと、チームメンバーをある程度固定した上で担当する機能を決めて開発するような体制がよりベターだと思っていたのですが、やりたいことに対してエンジニアのマンパワーが不足したり、戦略の不確実性が高かったりする中でなんとかアウトプットを出していくためにこのような体制を取っていたというのが実際のところです。

ただ、ありがたいことにここ1〜2年で採用が上手くいったこともあり、エンジニアもどんどん増え、機能もメンバーも両取りできる状況になったので、今年度から再度開発体制を整えることにしました。

ちなみに、今回開発体制を整えるにあたっては、かの有名なSpotifyモデルや同じKDDIグループであるmedibaさんの開発体制の記事、RettyさんのLess導入の記事を自分なりに解釈しながら、それをコネヒトの開発組織に落とし込みました。特にRettyのVPoPである野口さんには直接お話を伺わせていただいたこともあり、とてもありがたかったです。

※イメージ図（人数は異なります）

どのようなことを意識して整えたのですか？

新たな開発体制では、アウトプットの先にあるアウトカムを最大化させることを目的に戦略と組織をアラインさせることを意識し、ママリの開発チームをRed / Green / Blue / Yellowの4チームに分けました。具体的には、追う指標が多すぎるという課題を解決するために各チームに紐づく事業KPIを明確にしたり、PdMの負担が大きいという課題を解決するためにPdM/PMM体制にしたりというアップデートを行いました。

ちなみに色でチームを分けたことにも理由があります。基本的には機能毎にチームを分けるスタイルで、チーム毎に任せる機能はある程度区切ってはいるのですが、成長フェーズの事業のため想定していなかったテーマが発生することもあり、事業の優先度に応じて開発の優先度もフレキシブルに変えないといけない場面も出てくると思っています。

そういった状況でも、目指すゴールには何が重要なのかをスピーディに取捨選択しながら、最も良い形で開発できる体制を整えたいという思いから、機能の名前ではなく色でチームを分けることにしました。

あとは、機能で完全に区切ってしまうと、これはコミュニティ機能の開発なのか？広告商材の開発なのか？といった線引きが難しいケースも出てくるというのもあります。

例えば、アンケート機能を開発しようとなった場合に、当初はそれがコミュニティを改善する機能だとしても、広告商材としても利用できる可能性はあるので、意図的に境目をなくしているというのもあります。

2021年4月にこの新体制がスタートしたのですが、これまでの開発体制のトライ＆エラーから得られた学びを踏まえ、現時点ではベストな体制をつくることができたと思っています。

ここまでは、開発体制をどう考えてデザインしたかという話をしてきましたが、では実際に運用してみてどうなのか？という点を、次回の記事でお話しできたらと思います。

-------------------------------------------------

いとしょさん、ありがとうございました！

後編では現状のコネヒトの具体的な開発チームの様子や今回の体制に変更してみてぶっちゃけどうなのか？を、いとしょさんにインタビューしたので、そちらも合わせてご覧ください！