はじめに
この記事は BASE アドベントカレンダー8日目の記事です。 devblog.thebase.in
ネットショップ作成サービス BASE のプロダクト開発チームでエンジニアリングマネージャー（EM）をしている髙嶋です。
「開発生産性」という言葉は、一見共通言語のようで非常にブレやすく、定義も難しいものです。その辺については、昨年のアドベントカレンダーの記事で弊社開発担当役員の藤川も触れています。
今年はその開発生産性というビッグワードにいきなりフォーカスするのではなく、まずはそれを分解した「開発量」を増やそうと開発組織一丸となって取り組んできた1年でした。何がユーザーにとっての価値となるかはデリバリーしてみないと分からないゆえに、開発スピードを上げていかなければならないという前提があると考えています。そのため、まずはいわゆるレベル1生産性と呼ばれるような足元のアウトプットをしっかりと増やしていこうというものです。
私たちのチーム（数十名規模）でも、その方針に沿う形でハイスループットな開発組織になることを目指し、様々な取り組みをしてきました。この記事では、その1年の歩みについてご紹介したいと思います。ざっくりこの1年でのタイムラインを示すと以下の通りです。
- 内製ツールで計測基盤を構築する
- 各チームごとに振り返りの場で計測結果を分析し、改善活動へとつなげる
- 開発組織外へのレポートフローを作成し、組織横断で現状および起こった変化に対する目線を合わせられるようにする
- 改善活動のスピードと質をさらに高めるために外部ツールを導入する
それでは、それぞれについて行間を埋めながら話を進めていこうと思います。
まずは計測して振り返る
とにもかくにも計測基盤がないことには、チームで同じものを見て会話をするといった取っ掛かりを作ることができません。手始めとして内製ツールを利用し、スプレッドシート上で開発スタッツに関するデータを見られるようにするところから始めました。BASE のプロダクト開発組織全体としての数値、あとは各チームごとの数値を、下図のような形式で参照できるようにしました。
これを材料に各チームごとに振り返り会のような場でボトルネックを探ってもらい、改善活動を推し進めていくといった流れです。つまり計測する仕組みと、それを活用する仕掛けを用意したという格好です。プルリクのレビューを最優先にする、プルリクのサイズを適度に小さくするといったことに代表されるような、地道なアクションを一歩ずつ進めていくことで、その結果は着実に数値上でも表れていきました。
開発組織外とのコミュニケーションと組織状況の把握
自動取得できる開発スタッツ系以外の項目も加えて、月次で各種数値を Notion 上に蓄積し、全体のトレンドを把握できるようにしました。さらにそれを月次事業報告として開発組織外にもレポートするフローを作り、開発組織外との目線合わせもできるような体制を構築していきました。開発組織外にも適切に情報を届けることは、全社レベルでの組織運営観点からのフィードバックを得られるようにしたり、非エンジニアも巻き込んだ改善活動に取り組みやすい体制にしたりするために、非常に重要なことだと考えています。
加えておおよそのトレンドや開発 PJ との因果関係といったものも大まかには把握できるようになり、組織として次に目指す方向性を検討する材料の一つにできていると感じます。1年という期間を通じてモニタリングしてきたことで、開発組織としてのリズムをより解像度高く捉えられるようになったことには大きな意味がありました。
内製ツールから外部 SaaS ツールへ
年初からそうした取り組みを始めて半年が経過しようかという頃、改善が進んできたからこそ、内製ツールにおける運用だと以下のような課題が目立つようになってきました。
- 取得できるデータに限りがあって課題の深堀りがしづらく、改善アクションの精度向上が難しい
- メトリクスの悪化に気付くきっかけ（アラート）がなく、対処が後手に回りやすい
- チームのスタッツを相対的に評価する指標や基準がない
- ツールのメンテナンスコストが継続的にかかり、対応も属人的になってしまっている
こうした課題を解決し、改善活動のスピードと質をさらに高めることを目的に、Findy Team+ の導入を決定しました。いきなり有償ツールを入れるのではなく、改善が進んでそれをより発展させるためにツールを入れるという順番になったことは、とても良かったポイントの一つだと考えています。ただしここで一つ懸念としてあったのが、実際に各チームで活用していこうとすると、多機能であるがゆえにどこからどう使えばいいか迷いやすくなってしまうのではないかということです。そのため現場任せにせず、組織として意思を持って活用を進めるために、最初は推奨する活用フローと機能スコープを提示することにしました。
今では基本的な使い方が定着したことで、各チームの課題や開発スタイルに応じてチューニングをしたり、より応用的な活用ができないかといった検討も進めているところです。ちなみにいくつか計測している指標の中でも、サイクルタイムはコミュニケーションの効率化指標として注目して追ってきた項目です。それが下図のように右肩下がりとなってからは安定した状態を維持できていることからも、一定成果が出ている状態にあると言えるのではないかと考えています。
実は2年前にも取り組んだことはあった
いわゆる「開発生産性を上げよう」といった取り組みは、実は2年前の2023年にも取り組んだことがありました。やっていることの内容自体は、その当時と今回とで実はそこまで大きな差分はないのかもしれません。前回は半年程度で立ち消えとなってしまいましたが、今回は1年以上継続しており、来年もその発展をさせていこうという状況です。
では一体何が違ったのでしょうか。それは結局のところ、今回の場合は開発組織全体としての方針が、組織図上の先から先まで張り巡らされていたという前提が大きかったのではないかと考えています。私の立場で言うと一開発部署の一中間管理職となるわけですが、自部署だけで声を挙げて取り組んでいこうとするのではなく、まず会社としての意思が先にあり、それにアラインする形で取り組むんだということで覚悟が違った部分はあったと思います。もちろん自部署だけでスコープを区切って物事を進めやすくするといった手段はよくある話かと思いますし、今回も日々の活動としてはそのような形となっています。しかしながら大前提となる方針が会社レベルで先に示されたことで、自部署内での取り組みに対しても助けになったのは間違いありません。
まずは開発スタッツの計測から始めてみようとしたのが前回だったのですが、探索フェーズと考えればそれ自体がダメだったとは思っていません。ただし組織として目指したい方向性や日々変化する組織状況に対する解像度がマネージャー各人の中でもまだ低かったこともあり、改善が一定進んだときに「さて、ここからどうしよう」となってしまったのかなと思っています。12月4日の @tanden の記事でも、そうした悩みについては書かれています。
今回は幹がしっかりとあり、それゆえ中長期的な活動にすることを見据えて、計測基盤一つをとっても意思を持って整備しにいったことが今につながっていると考えています。
おわりに
開発量向上を旗印に1年をかけて様々な取り組みを進めてきましたが、組織として前進した部分は素直に認めつつ、伸びしろがあるのも間違いはないので今後も着実にレベルアップを図っていきたいと思っています。また本文脈においても生成 AI とどう付き合っていくかは無視できない観点の一つですが、ただ量が出せればいいというわけではなく、当然ながらそこには質や成果が伴ってくることも重要です。目先の数値にとらわれすぎず、エンジニア一人ひとりが納得感を持って前向きに開発に取り組める状態を作ること、一方で自分たちを客観的に見て内省するための仕組みと機会を用意し、より良いチームとなって顧客への価値提供サイクルを早めていくことが求められるのだろうと思います。
BASE では、今後のプロダクト成長を支える技術戦略や開発基盤の構築をリードしていただけるエンジニアを募集しています。 ご興味があれば、ぜひ採用情報をご覧ください。
明日の BASE アドベントカレンダーは @okinaka さんの記事です。お楽しみに！
