協奏するプロダクト集団を作る ~1年間Saas開発をしてきた今の開発組織と今後のエンジニア組織の在り方について~

こんにちは、ストーリー初投稿です。プロダクトマネージャーの田原です。

プロダクトマネージャーと言いつつこの１年間は、PM・ディレクター・デベロッパーと、開発サイクルの中でその時必要な立ち回りをひたすらにこなす、というなんともスタートアップらしい開発をしてきました。

さて、7gardenは2021年9月に自社プロダクト「tuna」をリリースしました。幸いにも様々な業界に好評をいただいており、プロダクトをさらに加速させていくフェーズに入っています。

同時に今後の7gardenの開発のコアとなるエンジニアを迎え入れたいという想いがあります。もし少しでも7gardenのプロダクト開発に興味を持っていただけたら、カジュアルにお話させていただけると嬉しいです。

まずは今回の初稿に寄せて「7gardenの目指す開発組織の在り方について知っていただきたい」と考えています。

この１年間で身に染みた、チーム開発において何より重要なこと

イノベーターやアーリーアダプター層に届く段階の未成熟なビジネスにおいては、数多くの仮説検証を繰り返しながら「マーケットのニーズはどこにあるか？」の答えを導き出していく必要があります。その過程でPMF（プロダクト・マーケット・フィット）の姿も当然変化にさらされます。

tunaの開発プロジェクトの立ち上げは約１年前でしたが、まさにそれを地で行くような１年間でした。

そして、プロダクトを素早く変化に適応させていくために、エンジニア組織に重要なことは何か？

アジャイル開発やDDDでよく言われているようなことではありますが、下記の２つが非常に重要だ、というのがこの１年で身に染みています。

チームメンバーのビジネスドメインの理解の深さ
チーム内での垣根のない対話

BtoB(toC)のプロダクトには

既存のワークフローを効率化するプロダクト
今までにない新しいワークフローを提供するプロダクト

の２種類がありますが、特に後者の場合提供するUXの設計や実装は抽象レベルの高い思考を求められるので、これらはより重要です。（※tunaは後者にあたります）

短いサイクルで様々な変化に遭遇するビジネスのプロダクトにおいては、トップダウン式の分業制ではプロダクトを変化に適応させていくことはできません。エンジニア自らビジネス背景を理解し、どのような機能性が求められるか考え、それを対話によってプロダクトに昇華させていくことが不可欠です。

持論ですが、

技術レベル10だがビジネス理解が5のエンジニア10人のチーム
技術レベル5だがビジネス理解が10のエンジニア10人のチーム

があったとしたら、スタートアップでSaasの開発を行う上では、後者の方が高いパフォーマンスが出せる、と考えています。

では、「協奏」とは？

エンジニア組織のあり方についてこの１年間考えてきた中で、今のところ１番しっくりきているのが「協奏」という言葉でした。端的に言えば「エンジニア全員がプロダクト視点を持ち、対話することで集合知として完成度の高い設計や実装をしていく」というのが「協奏」のイメージで、今も今後のエンジニア組織のあり方についても、根本にしていきたい思想です。僕の考える「協奏」の要件は下記です。

個々のエンジニアが、ビジネスドメインを深く理解している
個々のエンジニアが、ユーザーストーリーの全体像を理解している
個々のエンジニアに、プロダクトのアーキテクチャのあるべき像の共通認識がある
個々のエンジニアがプロダクトの技術負債についての共通認識がある
どのような構想や改善要望であっても、上記を考慮した上で個々が自立して考えることができる
今のプロダクトに必要なこと・課題を個々が自立して考えることができる
対等な立場で対話することで、個々の考えをプロダクトの機能へと昇華させることができる

7gardenの開発組織はまだまだ小さく、今後の3~4人くらいのエンジニアは間違いなくコアメンバーになります。さらなる組織拡大のフェーズでは分業による合理化を重要視する必要がありますが、その前段階におけるコアメンバーに関しては、同様のプロダクト視点を持って個々のエンジニアが開発に当たれる状態を目指します。