2024年11月15日、ファインディ株式会社が主催するイベント「開発生産性Kaigi スタートアップが目指す、開発と事業成長の接続〜価値創造への挑戦〜」が開催されました。

■登壇者プロフィール 湊谷 海斗(@kamina_zzz) Ubie株式会社 テックリード

上智大学大学院理工学研究科理工学専攻情報学領域修士課程修了。食べログ(株式会社カカクコム)を経て2019年SREとしてユビーに入社。以来、SRE業務だけでなくプロダクト開発や組織開発、採用などに従事。現在はtoCプロダクトのテックリードとしてプロダクト開発やチーム内外の開発生産性向上に取り組んでいる。

ハイパフォーマンスなチームとは、どのようなチームか？

湊谷：本日は、開発生産性を上げながらビジネスも成長させてきたチームが、どのようなことをやってきたのかというお話をさせていただければと思います。ユビーの事業はtoCとtoBに大きく分かれていますが、toC向けのメディアサイトも運営しており、自分はそこでテックリードをしています。

チーム状況としては、プロダクトオーナーが1人、エンジニアが3人、デザイナーが1人、医者が1人というストリームアラインドチームを形成していて、ありがたいことに過去1年弱で事業指標を大きく伸ばすことができています。

湊谷：今日は、改めてハイパフォーマンスなチームとはどのようなチームなのかを考え直し、そこから自分たちがどういったアプローチを取ったり、気づきを得たりしたかを共有しようと思います。

そもそも一口にハイパフォーマンスなチームと言っても、競技や大会形式、ルールによって違うはずです。今回の「開発生産性Kaigi」は、スタートアップも1つの切り口になっていると思いますが、Webサービスのスタートアップはどのようなルールでやっているかと考えていくと、基本的にホームランダービーと似ていると思っています。

どういう意味かというと、ここで言うホームランというのは事業を大きく変化させるようなイベントのことで、あらかじめどうしたらユーザーが求めているものを作れるか、どうやったら大きく成功するかはわかっていないわけですね。

湊谷：そのホームランを打てる確率をいかに高くできるか。これには、アイディアの筋の良さが重要になってきます。一方で、同じ制限時間内に何回バットを振れるかどうかも、重要な指標です。これを単純化すると、1週間に何回デプロイできるかといった指標になります。つまり、何回打席に立って、何回ホームランを打てるかというゲームだと思っています。

ただ、実際にはホームランダービーと違うところもあって、例えば1日で勝敗はつかないとか、オフシーズンがないとかですね。残念ながら平日は毎日開催されるので、長い時間をかけることも想定しなければならない、マラソン的な要素もあります。

また、1日だけ施策が大きく当たることにもあまり強い意味はなく、多くの場合、それをコンスタントに打ち続けられる体制づくりに価値がある。長い時間で見たときの、LTVのようなものが重要なゲームになっているといえます。

湊谷：整理すると、Webスタートアップにおいては、いかにアイディアの筋をよくできるか、いかにデプロイの回数を高くできるか、いかに長く良い状態を続けられるか。このあたりを追い求めていくのが良いだろうと思っています。そして、それぞれの計測手法は世に出回っているものがあります。

例えばアイディアの筋は、どれくらい数字が跳ねたかというフィードバックを元に検証することが多いと思いますし、もちろんユーザーインタビューなどもあると思います。デプロイ回数は、バグのない正常なデプロイであるかも含めて、Four Keysで計測できます。いかに長く続けられるかは、チームの存続期間で測れるでしょう。このあたりは、僕らユビーもですが、世の中的にも計測できているチームが多いと思います。

チームが持つケイパビリティに着目し、計測する

湊谷：ただ、これらを計測したからといって、パフォーマンスが良くなるかというとそうではなく、では具体的に何をするとパフォーマンスが向上するのか。そもそもパフォーマンスが良くなるということは、チームは何かしらの変化をしているわけですね。

チームが何かしらのケイパビリティを獲得したから、パフォーマンスが良くなったと考える。逆に言えば、何も変わらないのにパフォーマンスが良くなることはないはずで、Webサービスにおいて放置していて良いことはあまりありません。

パフォーマンスを高めるためには、どんなケイパビリティを獲得すべきか計画したり、チームで目線を合わせたりすることが必要だと考えられます。なので、KPIやFour Keysを計測するだけではなく、チームがどういったケイパビリティを持っているのかも、ちゃんと計測することが大事だと思っています。

湊谷：チームがどんなケイパビリティを持っているかについては、いろいろな考え方があると思いますし、チームが必要としているケイパビリティは何なのかについても、会社やチームの特性によって大きく変わってくると思います。

僕たちはというと、DORAのCapability Catalogを参考にして、その一部を抜粋したりアレンジしたりして、「これはこのくらいできたら、この点数をつけよう」という形で使っています。

僕たちのチームでは、定期的に3ヶ月に1回くらい集まって、点数をつけて見直す時間を設けています。右下に載せたのは、半年から9ヶ月くらいでの変化で、もちろん上がっている指標もたくさんありますが、なかには逆に下がっている指標もあります。

これは僕たちが、より高いレベルのものを求めるようになったということもありますし、あるいは知らず知らずのうちにないがしろにしてしまって、でも逆にそれを投資したことで別の何かを得ていることもあります。

このあたりを客観視して、自分たちが今どのケイパビリティを獲得すると、チームとしてパフォーマンスが上がりそうかをチーム内で共有し、日々のPBRなどに活かしていくことが重要なのではないかと思っています。

湊谷：ケイパビリティを並べたなかでも、どの指標がより重要なのかという優先度を考えるときに、DORAが毎年出しているレポートがヒントになります。全世界を通したアンケートをもとにした示唆がまとめられていて、例えば疎結合アーキテクチャやコードメンテナビリティは他のテクニカルな指標に比べて、アウトカムへの相関が高いといったことが書かれています。

それを読むと、自分のチームでも体感値としては持っていたけど、やっぱり疎結合アーキテクチャは大事なんだなと改めてわかったり、コードメンテナビリティが高くなるようなリファクタリングをしようと計画できたりするので、ヒントとして活用できるといいと思います。

短期でチームを解散させない＆DevOpsをやっていく覚悟

湊谷：まとめです。Four Keysを計測することも大事ですが、同時にケイパビリティにも着目して、チームを強化することを考えていくことが重要だと思っています。これをやっていくうえでは、短期でチームを解散させないこと、DevOpsをやっていく覚悟を持つことが大切です。

短期で解散するチームは、長期的にケイパビリティを獲得していくところに対するインセンティブを失ってしまいます。なので、長い目で見てハイパフォーマンスチームを続けていくということを、チーム全体、あるいはチームを設計するマネージャー、組織設計のメンバーが正しく理解していることが重要です。

メンバーを安定させて、目的のもとに人を集めるのではなく、ハイパフォーマンスのチームにどんな仕事をさせるかを考える方が、パフォーマンスの高いチームを長く存続させることができると思っています。

湊谷：また、DevOpsをやっていく覚悟に関しては、疎結合アーキテクチャやコードメンテナビリティを自分ごと化することですね。自分が欲しいものは自分でやっていくべきで、都度Opsチームのような他チームに依頼するやり方は、ちょっと違うかなと。できないならできるようになっていくというのが、チームとして強くなっていく道だと思います。

そして、作って終わりの仕事はないので、しっかりソフトウェアにオーナーシップを持つことも重要です。もちろん自分のチームだけで完結するものがすべてではなく、例えば疎結合アーキテクチャと言っても、自分が触っているサービスはあるマイクロサービスのサブセットだったり、あるいは単一の小さなマイクロサービスだったりします。

その歪みを解消しようとしても、1人で改修するのはなかなか難しい。自分のチームだけで完結するのが難しいものは、適切に他チームにパスを要求することも、ストリームアラインドチームとしては必要な動きだと思っています。

これからも、こうしたところに注目しながらチームを強化して、パフォーマンスの高いチームをどんどんつくっていければと思っています。ご清聴ありがとうございました。