ユーザーに価値を届けるためのコネヒト開発体制の試行錯誤〜後編〜

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

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

前編では、これまでの変遷を紹介しましたが、後編ではコネヒトの具体的な開発チームの様子や現状の組織体制に変更してみてぶっちゃけどうなのか？を聞いてみたので、ぜひご覧ください！

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

現在のコネヒトの開発体制について教えてください

前回の記事でも触れましたが、現在はアウトプットの先にあるアウトカムを最大化させることを目的に戦略と組織をアラインさせることを意識し、開発チームを4つに分けています。

チームは開発する機能毎に構成しており、コミュニティグロースをRedチーム、メディアの開発をBlueチーム、有料機能や広告商品の開発をYellowチーム、プレゼントサイトやキャンペーン機能の開発をGreenチームで担当しています。

新しい機能の開発が始まると、チーム関係なくGitHubやSlackなどが結構盛り上がるのですが、そのやりとりからもプロダクトやユーザーのことを考えるのが好きなメンバーが多いなと感じますし、純粋に楽しんで開発に取り組んでいることが伝わって嬉しくなりますね。

※イメージ図（実際のメンバー構成は異なります）

エンジニア以外の体制もアップデートしたんですよね？

そうですね。今回の体制ではPdM（プロダクトマネジャー）とPMM（プロダクトマーケティングマネジャー）をエンジニアやデザイナーと同じチームに配置する形にしたことも大きな変化でした。

以前までは、PdMという役割でひとつのグループを構成し、PMMはまた別の組織に在籍する形を取っていました。この体制だとPdM間でのナレッジ共有がしやすいなどのメリットがある一方で、部門横断のコミュニケーションが多く、戦略実行のための調整コストが高くなったり、検証サイクルをスピーディに回す難易度が高かったりという課題を感じていました。

プロダクト開発ではアジリティを高めるためにチームが一枚岩になっていることが大切だと考えているので、思いきってPdMとPMMを同じグループにする形に変更しました。これにより、同じチームに所属するPdM、PMM、エンジニア、デザイナーがスピーディにコミュニケーションを取り、より同じ目的や文脈を共有しながら開発できるようになったと感じています。

また、PdMとPMMへの期待値に社内でもばらつきがあったので、全員で認識を揃えるために役割の定義を作りました。PMMはプロダクト開発でビジネス側に責任を持つ、PdMはプロダクト開発で開発に責任を持つと定義し、PdMとPMMがタッグを組んで進めらえる体制をつくりました。

ここまでがチームのアジリティを高める目的での変化ですが、一方で、チームを分けることによって個別最適が進んでしまうリスクもあると感じていました。

そこで、コネヒトのプロダクト開発全体が同じ方向に向かえるように、横串でクオリティを担保する体験設計チームという組織も新たに設けています。体験設計チームでは、各チームが個別最適の開発になりすぎないよう、例えば、ビジネス視点では良いけどユーザー視点だと逆に使い辛くなっているよといったレビューが入るようにすることで、コネヒトが最も大切にしている「顧客主語」のプロダクト開発がちゃんと守られることを目的としています。

組織体制を変更してみて、実際のところはどうですか？

自己採点だと50点くらいかなと思っています。

これは決して低いということではなく、半年ではまだ評価出来ない部分が多いと考えているからです。その中で、もともと今回の体制作りで目指していた「各チームに裁量を渡して、スピード感を持って開発していく」ことは徐々に上手く出来るようになり、安定感も出てきたので、その点は手応えを感じています。

とはいえ、この変更でユーザーに新たな価値を提供できたかと言われると、短期間ではなかなか成果を出せるものではないなと思っているので、まだ道半ばだなと感じています。

また、おおよその開発は各チームで推進できている一方で、大きな機能開発の際にチームだけでは意思決定出来ないケースも出てくるという発見もありました。

例えば、Yellowチームで課金ユーザーへの新たな機能を開発したいと思っているけれど、それがユーザー体験という観点ではコミュニティに影響が出てくる場合に、プロダクトとしてどう最適化していくか？どうやって意思決定をしていくか？を全体で判断していく必要があるのですが、このあたりはまだ改善の余地があり、体験設計チームの力なども借りながら解決していきたいと考えています。

あとは、ちょっとした負債解消や技術的な改善に関してもチームの枠を越えると調整コストが増え、最適な頻度やタイミングでの施策実行の難易度が上がることが分かりました。ですので、今後はできる限り全ての取り組みをチームのコントロール下に置くような体制にしていこうと考えています。

今後はどういう組織を目指しているのでしょうか？

現断面ではアジリティを高めることを重視しているので、チームがコントロールできるスコープを増やしたいと考えています。ですが、チームを分割していくと組織がサイロ化していく傾向があるとも感じています。

特にコロナ禍でリモートワークが続く中では、ある程度意図的にチーム間の交流が図れるといいのかなと思っています。また、メンバーを固定化することでチームの学びを溜める必要性があると前回言いましたが、一方で、長期に渡って固定化が続くとチームが硬直化するので、その学びがリセットされない程度にローテーションの仕組みも必要だと考えています。

今後は、例えば、チームを移籍した場合のキャッチアップ負荷を解消したり、各チームが工夫してアップデートした取り組みを共有できる仕組みや場を作ったりすることで、仮に組織やチームが変更になった場合でも、開発の質や速度を落とさずに進めることができる流動性の高い体制をつくっていきたいと思っています。

ちなみに、これはTech Visionの「スーパーモブ」という戦略でも掲げています。

最後に、今後に向けて一言をお願いします！

今回の変化は、役職関係なく全員で課題を発見し、解決に向けて実行する、みんなでコトに向かう風土があるコネヒトならではの組織づくりだと思っているので、まだまだ改善点はたくさんありますが、「課題を一つ一つ解決し、着実に一歩ずつ前進していく」ということを今後も忘れずにしていきたいと思っています。

そして、結果的にユーザーに価値をガンガン提供出来る組織をつくっていきたいです！

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

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

今後コネヒトがどんな組織になっていくのか？、引き続き注目していただけると嬉しいです！