こんにちは！
ourly株式会社という2期目のスタートアップでEM兼BEとして働いている相澤と申します。
ourlyはインターナルコミュニケーション(社内コミュニケーション)活性化を目的としたWeb社内報やプロフィール機能を提供しているSaaSです。組織としては全体で40名弱(業務委託や学生インターン含む)で、そのうち15名ほどがエンジニアです。
今日はそんな2期目のスタートアップがなぜ開発生産性向上に向き合うのか(Why)、どの指標に向き合っているのか(What)、どんな取り組みをしているのか(How)を紹介します。
この記事は開発生産性AdventCalendar2023の8日目の記事です。
簡単にAIで要約した文章を記載しておくのでサクッと内容知りたい方はこちらをどうぞ！
AI要約文章
2期目のスタートアップは、組織の成長指標に対する問いかけから、開発生産性に向き合う決断を下しました。
この転機は、「LeanとDevOpsの科学」から得たFour Keys概念の影響を受けたもので、開発チームは具体的な指標を追い求めています。スプリントベロシティ、工数割合、デプロイ頻度、リードタイムなど、これらの指標を週次で振り返り、継続的な改善に取り組んでいます。開発チームは自身を会社全体にとっての「車のエンジン」と位置づけ、効率的な燃料の消費とスピーディな前進を目指しています。具体的なアクションとしては、PRの細分化、レビューガイドラインの策定、週次の数値振り返りなどが挙げられ、これらの取り組みを通じて開発生産性向上を図っています。
開発生産性の向上だけでなく、テストコードやチーム協力の重要性も強調されています。これらの要素を総合的に取り入れ、具体的な目標を設定することで、2期目のスタートアップは効果的で効率的な開発プロセスを確立し、成功に向けて着実に歩んでいます。
なぜ開発生産性に向き合い始めたのか
開発生産性に向き合い始めた(注力して改善施策を実行し始めた)のは今年の5月からなので半年程度経過した状態になります。
最初から開発生産性に注力しようと考えていたわけでもそういった観点をもっていたわけでもありません。立ち上げ期は他のスタートアップと同じように、少人数でひたすら開発(コーディング)を行い、一刻も早いリリースを、そして一刻も早い新機能開発を目指していました。
無事リリースした後、徐々に組織拡大をしていく中でCEOとの1on1でこんな問いを投げかけられた時に開発生産性を考えるきっかけになりました。
会社の目標に対して営業やマーケターは職種として定量的な目標がイメージしやすいですが、開発は直接売り上げに関与しないことが多いためイメージが湧きにくいというのが一般的かと思います。例に漏れず僕自身もそうでした。
ただ、単純に機能数だけを追っていくことはゴールのないマラソンを全力疾走で続けていくことに近い感覚を持っていたので、それで良いとは到底思えず、開発チームが向き合うべき数字はなんなんだろう、どこにあるんだろうと悶々とした日々を過ごしていました。
そんなある日、CEOが共有してくれた記事の中で、かの有名な「LeanとDevOpsの科学」が紹介されていたことで興味を持ち、読み始めました
探し求めていた答えがFour Keysという形で紹介されており、衝撃を受けたことを鮮明に覚えています。
自分たちは、特定の機能を開発して終わりというような短い道ではなく、会社として目指す目標に対して果てしなく続く長い道を進んでいくことが求められるため、開発生産性に向き合うことで安定してパワーを発揮することが出来ると考えました。
そうした背景から開発生産性に向き合い始めました。
どんな指標を追っているのか
開発チームの状況やメンバーのスキルレベルなどを考慮に入れた結果、自分たちが直近追うべき指標を以下4つと定めました。
- スプリントベロシティ
- 工数割合
- 1スプリントあたりのデプロイ頻度
- PRオープンからマージまでのリードタイム
なぜこの4つの指標に決めたのかの前に、僕自身が会社の中での開発チームの立ち位置／役割をどう捉えているかをお話しします。
僕は、会社全体を一つの車だと捉えた時に開発チームはエンジンだと捉えています。
エンジンが優れていれば少ない燃料で安定したスピードを出し、より遠くまで進むためのエネルギーを生み出すことができます。車をどの方向にどのくらいのスピードでどこまで進めるかなどは、CEOを中心とした会社全体での意思決定になりますが、そのための動力の源は開発チームになるのではないかと考えています。
だから開発チームが一番偉いんだ、ということではなく車を動かすために必要な多くの部品のうちの一つがエンジンで、その役割を担っているのが開発チームなのではないかという意見です。
そう捉えた時に我々開発チームが目指す理想は「投入された燃料を適切に燃やして、少ない燃料で出来るだけ遠くまでスピーディにいけるエネルギーを生み出し続けること」になります。
車で例えると燃費性能／加速性能に優れ、安定した速度で走り続けられる車です。
- 燃料 = 開発工数
- 燃費性能 = スプリントベロシティ
- 速度 = デプロイ頻度
- 加速度 = 変更のリードタイム
と置き換えると、先ほどの理想は「投資した開発工数を適切に消化して、少ない工数で出来るだけ多くスピーディにデプロイ頻度を保ち続けること」となります。
こういった考えから先ほど挙げた4つの指標に向き合うことに決めました。
指標の可視化方法と目標値
大前提として、追っている4つの指標はチームのパフォーマンス性能を測る指標であって評価指標とはしていません。(
ここ超大事です)
これらの指標が自分たちの評価、ひいては給与に影響してくるとなると本質を見失った形でハックすることに繋がるためです。例えば意図的にストーリーポイントを高く設定することで見かけ上のベロシティを上げるなどです。
あくまで、自分たちは今どのくらいのパワーを発揮できていて、定点観測した時に悪化していないか、改善しているのかを可視化し、振り返りの材料としているだけということを先にお伝えしておきます。
スプリントベロシティ
まず、可視化はスプレッドシートで行っています。チケット管理にJIRAというツールを使っており、JIRAのAPIをGASで叩いて取得したチケットの消化されたストーリーポイントを合計しています。
ベロシティは安定性を測る指標なので、数値をあげることが目標ではなく、出来るだけ安定した数値を目指すことを目標にしており、そのため以下観点で数値化しています。
- プランニングした結果の合計ベロシティをきちんと消化できているか
- 前のスプリントと比較してベロシティの誤差が少なく抑えられているか
2軸で見ているのは、差し込みタスクなどを考慮すると「消化率は低いけど誤差は小さい」ということが起きるため、そういった状況に気付けるようにしています。
もちろん差し込みタスクを調整しようとか優先順位きちんとつけようとかはありますが、少人数のスタートアップでやっているのでどうしても綺麗事だけでは回りません。
そういったことも織り込んだ上で可視化して定点観測しておくことが大事だと考えています。
工数割合
可視化はベロシティと同じくスプレッドシートで行っています。JIRAのチケットにつけた実績工数をチケットタイプごとに集計して、このスプリントはどれにどのくらい工数を割いたかを集計しています。
走攻守がいきなり出てきて？マークが浮かんでいる方も多いと思います(笑)
意味合いとしては、チケットタイプを走攻守の3種類に分類して集計しており、それらの比率を出しているだけなのですが走攻守の切り分けは以下の意味で分けています。
- 攻：新機能開発や改善など新規価値創出につながるタスク類
- 守：不具合修正や保守運用など提供価値の維持につながるタスク類
- 走：勉強会やリファクタなど攻守双方の強化に繋がるタスク類
余談ですが「走攻守」という野球用語を使ったのは僕が野球好きだからですが、一番イメージしやすかったからです(笑)
人数が増えたり、導入社数が増えたり状況が変わった際に、工数割合が悪化していないかをきちんと可視化しておくことで適切な量の燃料(工数)を投下出来ているかを把握できます。
1スプリントあたりのデプロイ頻度
こちらは単純で、リリースごとにタグを打っているので単純に経過スプリント数で割れば1スプリントあたりのデプロイ回数を算出できます。
現状のチーム状況だと、新規機能開発が中心になってくると1スプリントでデプロイ出来る単位で機能を切り出すのが難しいため、デプロイ頻度が落ちてしまいますが、将来的には1日あたり複数回のデプロイが行われるような体制を築きたいと思っています。
PRオープンからマージまでのリードタイム
リードタイムを可視化するにあたっては自前でAPIなどを駆使して集計することも考えましたが、構築コスト削減やナレッジ共有などの観点からFindy Team+の導入を決めました。
変更のリードタイムはFindy Team+で可視化されている通り
- コミットからPRオープンまでの時間
- PRオープンからレビュー開始までの時間
- レビュー開始からapproveまでの時間
- approveからマージまでの時間
の4段階に分けられます。もちろん全てに改善ポイントはありますが、まずはPRオープンからapproveまでの時間(真ん中2つの時間)へのテコ入れが工数少でインパクト大だと判断し、今期はその2つに注力することにしました。
導入当初は200h以上かかっていたところから考えると、現在はかなり改善された数値になっていますがまだまだ長いと感じています。最終的にはopenからapproveまでが24h以内のチームを目指したいと思っています。
効果のあった施策紹介
追う指標を決めてそれぞれ改善施策をやってきましたが、効果のあった施策を3つ紹介します。
PRを細かく分割する
対象指標：PRオープンからマージまでのリードタイム
PR分割すべき理由は割と語られ尽くされてる感あるので詳細には書きませんが以下の目的で実施していました。
- レビュアーの負担軽減
- レビューの質向上
- 手戻り工数増大の防止
目安として1PRにつき1変更意図で300行以内に収めるようにしましょうということをチームで共有していました。これにより、PRレビューする際にどこを集中してレビューすべきか、変更の影響範囲がどのくらいかなどの見通しが立ちやすくなり、心理的負担が減ったことでレビュースピードがあがりました。
事前にチーム内で会話していた時は変更行数に制限を加えることに懐疑的な声もありましたが実際やってみると全員がレビューしやすくなったことを実感しているので、導入を迷っている方はまずはやってみるのが良いと思います。
我々スタートアップのようにチーム規模が小さく、特定の人にレビューが集中しやすいような状態の時にはかなり効果的な施策だと感じました。また手戻りが大きくなることを防ぐことができるので、結果的には全体的な開発スピードアップにもつながっているように思います。
今ではレビューの際にレビュアー観点でこういう風にPR分割してもらえると見やすかった、などの分割観点に関するレビューも行われるようになっています。
レビューガイドラインを作る
対象指標：PRオープンからマージまでのリードタイム
PR分割はどちらかというとレビューイ側の改善テクニックですが、当然ですがレビューイだけが改善すれば良いわけではなく、レビュアー側の改善も必要になります。
レビューを努力目標で置いてしまうと、自分の実装タスクを優先して後回しにしてしまったり、レビュー意識の違いによる負荷が偏ってしまったりします。
これを解消するにはシンプルにチームで合意したルールを作ることです。
我々のチームはリードタイムの目標値から逆算して以下のルールで合意しています。
- レビュアーに指定されたPRがオープンされてから2営業日以内にレビューを完了させる
- レビューイからレビュー修正完了した旨の連絡が来たら、再度2営業日以内にレビューを完了させる
また、GitHubとSlackを連携することでレビュアーに指定されたPRがオープンした際にSlackでメンションが来るようにしたり、GitHub Projectsでレビュアーごとに依頼されているPRを一覧化したりすることでルールを守りやすい仕組みを作って運用しています。
※ ↑たまたま変更行数えげつないPRがいくつかありますが、半分機械的な変更で事前にチーム内で合意をとった上で効率化のためにまとめて出してたりします。
週次で数値を振り返る
対象指標：全て
これが全ての基本ではありますが、きちんと追うと決めて可視化した指標をチーム全員が認識するために振り返りを行うことが超重要です。
我々はスプリント開始日に前スプリントまでの指標を数値化し、全員が現在地を認識できるようにしています。そして各数値を要素分解した時にどこに問題が潜んでいるか、改善点があるかを炙り出してNext Actionを決めています。
フォーマットを共有しますので、もしこれから振り返りをやってみるという方は参考にしていただけると幸いです。
向き合い始めて分かったこと
以上、長くはなりましたが今年5月から取り組み始めた開発生産性向上のWhy, What, Howを紹介させていただきました。ここまで振り返り、向き合ったことで以下のことに気づきました。
開発生産性に向き合うための土台としてテストコードは必須
- 指標すべてに関わってきますが、テストがなければデグレと向き合うことが必要になり、変更の影響範囲調査やリグレッションテストなど機能が増えれば指数関数的に必要工数が増えてきます。
- テストコードがあれば工夫次第である程度の改善ができますが、なければ取り得る施策や改善幅が限られてしまいます。
- もちろんPMFするか分からない検証段階でテストコードを書くための工数を投資するかという議論はありますが、PMF後に全て作り直すくらいの気概がない限りは最低限担保したいケースくらいは洗い出して書くべきだと思います。
(2人以上のチーム開発をしていれば)開発生産性に向き合うことで持続可能な開発が可能になる
- これは最初の追うべき指標を見つける前の話に被りますが、機能数だけを追うのは全力疾走でゴールのないマラソンを走るようなものです。生産性に向き合うことでスピードと質を担保しながらプロダクト開発を進めることが出来るはずです。
ここまでお付き合いいただいた皆さま、ありがとうございました。
引き続き我々は開発生産性に向き合い、最高のエンジンとなれるように精進して参ります。
最後になりますがourly株式会社では各ポジション積極採用中ですので、ご興味があればお気軽にご連絡いただければ幸いです。