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

本記事では、株式会社SmartHRでエンジニアリングマネージャーを務める菅原 正宜さんによるセッション「マルチプロダクトな開発組織で『開発生産性』に向き合うために試みたこと」の内容をお届けします。

■登壇者プロフィール 菅原 正宜(@sugamasao) 株式会社SmartHR エンジニアリングマネージャー

2020年5月SmartHR入社。入社後はSmartHRの基本機能と呼ばれるプロダクトの開発を行い、同プロダクトのプレイングマネージャー→マネージャーを経て、2024年からテクノロジーマネジメント本部のダイレクターとしてSRE/DPEユニットの立ち上げやマネジメントを行う。また、 個人の活動としてパーフェクトRubyやパーフェクトRuby on RailsなどRuby/Railsに関する書籍の執筆も行っている。

年々新たなプロダクトをリリースし続けているSmartHR

菅原：今回は「マルチプロダクトな開発組織で開発生産性に向き合うために試みたこと」というテーマでお話させていただきます。まず最初に、私の自己紹介をさせてください。

インターネットではsugamasaoと名乗っています。およそ20年この業界で働いていまして、新卒ではSIerに入社し、現職ではSmartHRに入社して4年半ほど経ちました。長年プログラマーとしてやってきましたが、直近の2年くらいは専業でマネジメントをしています。Rubyに関する書籍をいくつか執筆しており、Rubyはちょっとわかるという感じです。

では本題ですが、まずマルチプロダクトな組織とは何か、というお話からしたいと思います。会社の状況をお伝えした方が、今日のトークテーマの前提が伝わると思うので、最初にSmartHRの説明をさせてください。

我々はSmartHRというプロダクトをつくっていまして、年々プロダクトを拡大しています。新しいプロダクトをたくさんつくっていて、新しいプロダクト＝1Webアプリケーションであることが多いです。なので、年々新しいアプリケーションがどんどん増えているイメージですね。

菅原：今年に入ってからも、いくつかのプロダクトをリリースしていて、この図にあるすべてが1Webアプリケーションというわけではないのですが、多くのプロダクトは新規Webアプリケーションとして開発しています。

0→1で新しくつくっているものもありますが、1→10でこれから大きくしていくものもありますし、10→100でより成長させていくものまで、さまざまなフェーズのプロダクトがあります。

菅原：チームは多くの場合、1チーム＝1プロダクトになっていますが、なかには5チームや2チームでLeSSを使って1プロダクトを扱っていることもあります。LeSSというのは、Large-Scale Scrumの略で、スクラムを拡張して複数チームでいい感じにするフレームワークのことですね。

というわけで、これだけプロダクトの種類もあって、フェーズも違って、チームの形態もいろいろある。こうした状況を前提として、お話ししていきたいと思います。

数値に踊らされず、向き合うために必要な前提知識をつける

菅原：では、こうした状況で開発生産性に向き合うために、どういった取り組みをしてきたかという話なのですが、そもそも開発生産性とは何でしょうか。何をもって開発生産性とするかは諸説あって、「これが開発生産性だ」と一言で表すのは難しく、話しているコンテキストによっても異なることがあると思います。

我々も開発生産性について、あまりよくわかっていませんでした。言葉としては聞いていても、具体的な定義がどうなっているのか、どういう状態を指しているのかはわかっていなくて、ぼんやりと話していました。ただ、組織を拡大していくなかで、開発生産性が今どうなっているのか、早くなっているのか遅くなっているのか気になる状態だったんですね。

そうしたなか、2022年の秋くらいに、「Findy Team+」というツールを使うと開発生産性に関するデータが取れるらしいと知りました。僕らは開発生産性が何かよくわかっていなかったのですが、わかっていなさすぎるので、まずは試してみようと考えたんです。

「Findy Team+」について話を聞く中で知ったことと、我々が当時興味を持っていた観点から、Four Keyとサイクルタイムという2つのメトリクスに特に注目しました。

Four KeysはDORAが提唱しているものという理解があったので、これが収集できるのはいいだろうと。それから、サイクルタイム分析の機能では、コミットしてからプルリクを出してレビューしてマージするまでの時間が取れる。そのあたりが取れたら、よくわからないけど開発生産性が見れるんじゃないかということで、トライアルで試してみることにしました。

ここに貼ったものは最新の状態で、当時のものではありませんが、DevOps分析でFour Keysがこのように取れるということがわかりました。ちなみに、このリポジトリは複数チームで開発しているプロダクトです。

菅原：もう1つは、サイクルタイム分析ですね。これは前述のリポジトリを開発している複数チームのなかでのあるチームの状態ですが、このような感じでコミットからマージまでの時間がわかります。

例えば、ものすごく大きなプルリクをつくると、レビューで見るのに時間がかかってしまうとか、レビューで指摘が多いと手戻りして、最終的なマージまでに時間がかかってしまうとか、そういうことが見えるんですね。この数値だとかなり良い方かなとは思いますが、そういったことが見て取れるようになりました。

菅原：すごいですよね。でも、「これは！」と思ったんですよ。なんかやばいぞと。「数値に踊らされそうな気がする」と思ったんです。数値はわかりやすいですが、数値にはすごいパワーがあるので、高低がどうしても気になってしまう。数値を見てしまうと、振り回されそうだという予感があったんですね。

もちろん改善していくことは必要ですが、必要以上にこだわってしまったり、他のチームと過剰に比べてしまったりするかもしれない。きちんと向き合う土壌、知識がないと運用は難しいのではないかと感じたんです。

グッドハートの法則で言われるように、数値を目標にするとハックされてしまって、信頼を置けないという話もあります。もちろんそういったことをするチームがあるとは思っていませんが、そういうこともあり得る状態でやるのは、あまりよくないと考えました。

それに、僕らは「これ使ったら良さそう」くらいにしか考えていなくて、本当に数字を数字としてしか捉えられていなかったんですね。なので、前提知識がないまま数値を見るのはやばそうだという直感がありました。

菅原：ということで、このときファインディさんにはすごくお世話になったのですが、トライアル後にそのまま運用するのはやめました。まずは前提知識をつけようということで、実施したのが『LeanとDevOpsの科学』という本の読書会です。

Four Keysの指標が選ばれた背景などが書かれた本なのですが、社内でも興味を引くテーマだったのか、エンジニアを中心に20～30人が集まりました。その人数で一斉にやるのは難しいので、いくつかのグループに分け、必要な内容を読んでディスカッションしました。それによって、Four Keysの背後には当時だと24個のケイパビリティがあり、その結果がFour Keysであるという共通認識が得られました。

少し脱線してケイパビリティの話をすると、今DORAのサイトに行くと、こういった図があります。左側の各種ケイパビリティが、真ん中にあるパフォーマンスに影響を与えている。そして、パフォーマンスが右側のアウトカムに影響を与えているということですね。

この図の青色の点線で囲われているところが、Four Keysで見ていくところです。なので、Four Keysで測れるのは、組織やプロダクトのパフォーマンスであって、アウトカムではないことを理解しておく必要があります。

菅原：さらに、ケイパビリティの話を補足すると、DORAのサイトでは今29個のケイパビリティが書かれています。そのなかには、例えばコードのメンテナンス性が大事だとか、自動テストはあった方がいいとか、そういったことも書かれているので、もし見たことがない方がいれば、見てみるといいかもしれません。

菅原：実際に読書会をやってみると、たくさんのプロダクトがあるので、所属するチームごとに特色や感想が異なっていて、知見の共有につながりました。また、エンジニアがやれたらいいよねと思っていること、例えば自動テストがあるといいよねとか、そういったものがちゃんと組織のパフォーマンスに関係があると書いてあるので心強いです。

それに、読む前にイメージしていたよりも、エンゲージメントや組織文化が大事だということが言及されているんですね。コードのメンテナンス性が大事だとか、そういうテクニカルな話だけではなく、取り巻く環境も大事だと包括的に考えられていて、とても学びがあって良かったです。

こうした形で、会社のエンジニア組織として一定の理解を得られているという、なかなか良い状態になりました。このあたりを理解したうえで数字を見るなら、単なる数字の良し悪しよりは、ちゃんと受け取れそうだと思えてきました。

ただ、先ほどのDORAの図であったように、これらはパフォーマンスやデリバリーに対する数値であって、この数値が良いこととアウトカムが良いことはイコールではありません。そこは注意しながら取り組んでいく必要があると思いました。

とはいえ、アウトカムを支えるのはアウトプットなので、アウトカムを出していく組織として基礎体力が必要で、そこはこの数値で読み取るのだと理解しました。なるほど、数値の意味はわかりました。では、この数字をどう活かしていけばいいのでしょうか。

僕らとしては、やはりアウトカムを重視して開発していきたい。でも、この数値がアウトカムとイコールではないと考えると、我々にとってこの数値に意味があるのかという疑問もわいてきます。

計測する範囲がわかったうえで、定量化された数値を見る

菅原：ここで開発生産性の話に戻って、ここまでの知識や計測できるものを踏まえて、どう開発生産性と向き合ったらいいのかという話をしていきます。

我々が本当に測りたいのは、こういう機能があったらいいんじゃないかという着想から、リリースして、実際に使った顧客からフィードバックを得るといった工程です。ここまで考えて、僕らの考えている開発生産性が指すものがようやくわかったんですね。それは「着想からリリースして価値を届けるまで」というものでした。

そこまで調べられるかはともかく、本当に欲しいのはここだとわかりました。では、Four Keysやサイクルタイムでは不十分なのかということですが、そうではないと思っています。我々が求める開発生産性を直接測るものではありませんが、一部の工程が定量化されることには、大きな意味があると理解しています。

わかりやすい例では、定量化されている範囲で何か問題があれば、数字に表れるので対策が取れます。自分たちの開発リズムでやっているだけだと、異常を検知できないこともありますが、数値で見ると自覚できていなかった問題がわかったりします。

あるいは、自分たちの開発スタイルでは、時間がかかっても仕方がないと思っていた工程が、見る角度や指標が変わると、実はもっと改善できるんじゃないかと視点を変えるきっかけになることもあります。

こちらはかなり大まかな図ですが、このように測れる部分と測れない部分があります。逆に言うと、測れる部分がどの工程なのかがわかりますよね。例えば、サイクルタイムの部分で測れている数値に課題があるのであれば、そこを改善すればいいですし、定量化されている部分に問題がないなら、前後の工程を改善することもできます。

菅原：開発フローを改善すると、それによる副作用も当然あるはずです。どこかの時間が短くなった代わりに、別のところが遅くなってしまったとかですね。ただ、僕らは同じものを開発しているわけではないので、感覚的にこれは上手くいったなとか、大変だったけど前工程で上手くいったからいいかとか、そういう感覚的な感想になってしまいがちです。

それに対して、例えば今回の改善では設計の部分が改善できた一方で、サイクルタイムが悪くなってしまったというような、トータルでの判断ができるようになります。なので、部分的とはいえ定量化されている部分があると、判断材料の1つとして、開発プロセスを改善する指標になりえます。

チームが開発プロセスの改善に時間を割くのって、大変だと思うんですよね。もともと忙しいのに、他のことまで考えなければいけないので。そうしたなかで、やみくもに開発プロセスを改善しようとするのではなく、どこに時間やリソースを投資するかという判断に役立てることができます。

知見共有の場を設け、複数チームで「Findy Team+」を運用

菅原：ここからは、さまざまなフェーズのプロダクトやチームがあるマルチプロダクトな組織で、どう開発生産性に向き合ってきたかをお話したいと思います。定量化することに一定の価値がありそうだとわかってきたので、それをどう活用していったかという話ですね。

まずは身も蓋もない話ですが、「Findy Team+」を導入して定量的に計測しましょう。SmartHRでは、トライアルや読書会を経て「Findy Team+」を正式に導入したので、我々がどのように運用してきたのかをお伝えします。

この手のツールは、導入しただけではダメなんですね。結局誰も見なくなってしまったり、「なんか数値が良くなってそう」で終わってしまったりするので、ちゃんと浸透させて運用していくことがとても大事です。

我々は複数のチームで導入しているのですが、チームによって状況が違うので困りごとも違います。一方で、同じような困りごとがある場合もあるし、そもそもツールの使い方のようなノウハウが散在したり、車輪の再発明をしてしまったりすることも考えられるので、定期的に集まって話す時間を作りました。隔週で30分、5チームくらいで1枠です。

回を重ねながらブラッシュアップしてきましたが、今はこのようなフォーマットで話しています。まず一番上が今の状況で、サイクルタイムを中心に傾向を見ます。次に書くのが、3ヶ月先くらいの簡単な目標と、そこに向かって今どうしているか。これによって、目の前の数値の良し悪しではなく、チームのなりたい姿を見据えてアクションが立てられるようになります。

そして、前回から今回までの間、約2週間の現況や感想を書きます。例えば、サイクルタイムのこの数値が増えているけど、これはこういう事情があった、あるいはこういう改善を行った結果、この数字が良くなったといった内容です。

菅原：大事なこととして、チームの事情はそれぞれ異なるので、各数値はチームで比べません。ただ、数値に特別な大小があれば、何らかの特徴があるということなので、それについては話します。例えば、レビューまでの時間がすごく短いけど、どう工夫しているのとか、コードをコミットしてからプルリクを出すまでがすごく短いけど、前準備にどんなことをしているのとかですね。

補足すると、我々の開発チームは多くの場合スクラムを採用していて、1週間で1スプリントであることが多いです。そうした開発リズム自体は似ているので、知見を得やすい部分はあるかなと思います。

実際に「Findy Team+」の画面を見たり、それをもとに改善していくとなると、チーム内で合意を得る必要もあるし、1人の担当者が頑張ろうとすると大変なんですね。なので、そうならないように先に導入したチームが、新しく導入したチームに運用の知見を伝えられる、とても良い場になっていると思います。

「Findy Team+」は見る時間ひとつとっても、いろいろな選択や工夫があるんですね。スクラムの振り返りの時間に見て、振り返りの材料にしているパターンもあれば、時間を取ってちゃんと精査しているパターンもあるし、チームごとに違っていて参考になります。多くの場合は、健康診断的にチーム状況を振り返るために使われています。

ちなみに、「Findy Team+」の運用にあたっては、ファインディのCSの方に相談に乗ってもらうこともできます。数値をどう見ていったらいいかなど、いろいろな話が聞けて、そこもかなり助かっています。

お気づきになったかもしれませんが、この会ではFour Keysではなく、サイクルタイムを見ています。これはなぜかというと、Four Keysは遅行指標なので、短いサイクルで見るものではないからです。一方で、サイクルタイムはリアルタイム性が高いので、近況を見るのに適しています。

とはいえ、サイクルタイムはチームメンバーが長期休暇しているとか、今週は連休があったとか、そういうイレギュラーな状況の影響をかなり受けやすいんですね。なので、1週間単位ではなく、少し広めに取って28日間のサイクルタイムの傾向で話をするようにしています。

このような形で「Findy Team+」を導入して、複数チームでの運用は大変な部分もありますが、知見を共有する場を設けるとメリットも多いことがわかりました。

開発生産性を評価するフレームワーク、SPACEとEBM

菅原：ここまでの内容を聞いて、つまり「Findy Team+」を導入したという話ですか？ と思った方もいらっしゃると思います。そうだけどそうじゃないよという話をこれからしていきます。「Findy Team+」を使って定量化できるようになりましたが、開発生産性に関する取り組みというのは、もっとたくさんあるんですね。

ですので、今回はいくつかチャレンジした取り組みをお伝えしていきたいと思います。まず1つに、「SPACEフレームワーク」というものがあります。これは『LeanとDevOpsの科学』の著者の1人が論文の中で提唱している、開発者の生産性を多面的に評価するフレームワークです。

5つの頭文字を取ってSPACEと呼んでいて、従業員の満足度と幸福、パフォーマンス、アクティビティ、コミュニケーション、効率性とフロー、といった観点があります。それらに対して、個のレベル、チームのレベル、システムのレベルで評価していく指標です。見ての通り、エンジニアの働きやすさやコミュニケーションの取りやすさなどが、指標とされていることが特徴です。

菅原：従業員のウェルビーイングが生産性につながることは、「State of DevOps Report」にも記載されていますから、これらの指標には一定の価値がありそうだと。組織の健全性という観点でも、定常的に取得すると、よりよい環境をつくっていけそうだということで実施しています。開発組織単位でサーベイを取っている部分もありますが、ここではチーム単位での取り組みについて簡単に紹介します。

あるチームでの取り組みで、まだ探り探りの段階のため、しっかりとした定量化は行っていません。ただ、「Findy Team+」で得られている情報や、日々のチーム内での改善活動に対して、SPACEフレームワーク上でどの位置に当てはまるかを整理しながら、どこに注力したらいいかを考えています。

例えば、今期はCI/CDの改善をやっていきましょうといった話などですが、詳細に話すとこれだけで1枠使ってしまうので、過去に同僚が発表したスライドを貼るに留めます。指標をどのように使って、納得できる目標を立てるかといった話が出てくる興味深い内容なので、参考になるかと思います。

ボトムアップではじめるFour Keys・SPACEを用いた開発プロセスの改善事例 〜開発生産性に向き合ってチームの成長を実感する〜

菅原：次に、もう1つ別の取り組みとして、EBM（Evidence-Based Management）があります。これは、エビデンスベースマネジメントガイドから引用すると、「エビデンスベースマネジメント（EBM）とは、意図的な実験とフィードバックを用いることで、人々、チーム、組織がゴールを達成するために、よりよい情報に基づいた判断ができることを支援するフレームワークである」と説明されています。

このフレームワークでは、4つの重要価値領域に対して計測していきます。未実現の価値、現在の価値、イノベーションの能力、市場に出すまでの時間。これらに対して、我々のチームがどのようにアプローチしていくかを実験し、実験によって得たフィードバックをもとに、より前に進めるようにしていくというものです。

菅原：ここまでお伝えしてきたように、サイクルタイムはあくまでアウトプット指標であり、アウトカムやインパクトの測定はできません。ですが、EBMを使うことで、仮説検証サイクルができるので、プロダクトがちゃんとユーザーに価値を届けているかといった部分に対する、改善を促進できるのではないかと考えて導入を進めています。

EBMの導入にあたっては、ガイドが公開されているものの、かなり抽象的でどう進めていいか自分ではなかなかわかりません。なので、関心の高いチームを募って、2チームに1日構成で7時間の研修を受けてもらいました。その研修で得た知識をもとに、自分たちのプロダクト開発だとどういうことができるか、目標を決めてトライしてもらっています。

ゴール設定にはいくつか抽象度があって、近い方から即時戦略ゴール、中間ゴール、戦略的ゴールと定められています。そのなかで、例えば即時戦略ゴールに「この機能をn%のテナントユーザーが使えるようになる」と設定して、それに対してどう測定するのか、どんな機能があったらいいのか、どういうつくり込みが必要なのかといったことを話しています。

やってみてどうだったのか、気になりますよね。僕も気になります。ただ、取り組みを始めてからまだ2～3ヶ月しか経っておらず、結論めいたことは言えませんでした。とはいえ、実践にあたって、全然効果がなかったというような悲観的な状況ではなさそうです。社内でも試してみてどうだったかを話しているところなので、何かしらの形でお伝えできることがあると思います。

さまざまな取り組み方があるが「カイゼンに終わりはない」

菅原：それでは、取り組んできたことをまとめます。チーム開発を行っていると、改善したいことはたくさん出てきますが、そうしたなかで定量化された一定の指標があれば、どこに時間やコストを投資するかを判断する材料になります。そして、定量的な数値を定期的に見ることで、今どのような変化が起きているのかがわかります。

また、マネージャーという立場からの話になりますが、複数チームで一気に取り組みを行うときは、目的や前提知識をそろえてから実施しないと、各チームのやる気や関心次第になってしまいます。なので、そのためのサポートや座組みは、マネージャーが整えてあげるとスムーズだと思います。

ここまで「Findy Team+」導入を足がかりにして、さまざまな開発生産性の取り組みをしてきました。SPACEフレームワークやEBMといった手法にチャレンジしているのも、定量化に取り組む文化ができてきたからこそだと思います。

マルチプロダクトな組織で、状況の異なるいろいろなチームがあるからこそ、異なる手法を考えたり挑戦できたりする余地がありました。そして、開発プロセス全体やアウトカムまで意識できていることで、サイクルタイムだけを見るのではなく、アウトカムを目指して、さまざまなアプローチに目を向けられています。

最後に、「カイゼンに終わりはない」。これが言いたかったことです。いろいろな方法やフレームワークがありますが、終わりはありません。定量化はハックできたり、限られた範囲しか取れなかったりします。でも、自分たちのAS-ISやTO-BEを考えて、目指す状態がブレていなければ、数字をハックしてやろうと思うこともなく、ちゃんと前を向いて進んでいけるので、こうしたツールやフレームワークは有効な道具になると思います。

いろいろな取り組みをしてきましたが、開発生産性やアウトカムを意識した開発は、組織文化がとても大事だと思います。『LeanとDevOpsの科学』にもある通り、組織文化がなければ、こうしたチャレンジは自発的にできないし、持続しません。SmartHRは、僕が入社したときから既にそういう文化がある会社でしたが、組織文化をつくっていくことは、ものすごく大事なことだと思っています。発表は以上です。ありがとうございました。