こんにちは、リーガルブレイン部リーガルブレイン基盤チームでエンジニアリングマネージャーをしている丸山です。
現在はリーガルブレインエージェントのための認証・認可基盤の開発をしており、将来的には弁護士ドットコム共通の基盤となることを目指しています。
はじめに
エンジニアリングマネージャーに課せられるミッションのひとつとしてチームの 開発生産性 向上があげられます。みなさんは業務の中で、 開発生産性 をどの程度意識していますか。開発生産性は上げるものなのか、それとも下げないように守るものなのか、いったい何なのでしょうか。
本記事では 開発生産性 が良い状態とは、にフォーカスし、どのように捉えられるか、私なりの考えと解釈を紹介します。
開発生産性とは何か - 従来の指標への疑問
開発生産性 を向上させたい、その効果を測定したいと言われたとき、どのような指標に着目すれば良いでしょうか。 私が真っ先に思いついたのは ROI（Return on Investment, 投資利益率）と FourKeys でした。
ROI = 開発生産性か
ROI は、かけたコスト（インプット）と、それによって生み出された利益（アウトプット）の比率で定義できます。
KPI に直結する機能改善を行い ROI を評価すれば、開発生産性 が良いかどうかの評価になりそうです。
ですが、開発生産性 には持続性も求められます。 莫大なコスト（インプット）をかけて、コストを凌駕する利益（アウトプット）を生み出せたとき、ROI は高くなります。 この状態は一時的には評価できますが、メンバーが燃え尽きるなどデメリットを多く含みます。持続性はなさそうですね。
ROI は 開発生産性 を良くする指標のすべてではないといえるでしょう。
FourKeys = 開発生産性か
Google が提唱した指標である FourKeys は以下の 4 つで構成されます。
- デプロイ頻度
- 変更のリードタイム
- 変更障害率
- サービス復元時間
これらの指標は、サービスが安定してユーザーに価値を提供できているかを計測する基準の 1 つです。しかし、指標を高い水準で維持していても、必ずしもユーザーにとって価値があるとは限りません。
例えば、誰にも求められていない機能を頻繁にデリバリーしても、指標自体は向上しますが、ユーザー価値には直結しません。
ある指標が目標になると、その時点でその指標は“良い指標”ではなくなる
2025 年 7 月の開発生産性 Conference で Kent Beck 氏もグッドハートの法則に言及されていました。
FourKeys を改善していくことは 開発生産性 を測る指標の 1 つです。ですが、 開発生産性 を良くすることを目的に FourKeys だけを追究するのは適切でない、と私は考えます。
開発生産性が良い状態とは
いろいろ考えた末、以下の考えに落ち着きました。
開発生産性が良いとは、価値あるアウトカムを持続性をもって創出している状態 ではないか。 限られたリソースの中で、サービスを維持し、価値を見つけ、それを届け続けている状態 が良い状態ではないか。
無駄な機能開発ではいけないし、それが持続可能な状態でないといけません。
価値あるアウトカムをみつけるためのディスカバリーもアウトカムの源泉であり重要。 サービスを持続可能な状態にする保守・運用タスクもまた大切です。 もちろん機能をユーザーに十分な品質でデリバリーしなければなりません。
これらを理解するための構成要素を説明します。
稼働時間
稼働時間は以下の総和と考えます。
- 特定の期間でかけられる時間（例： 人月、20 営業日など）
- 残業時間
会社によっては一定量の残業があることを前提に稼働時間を設定することもあるようですが、ここでは残業は前提にしないこととします。気持ち的にも、管理者的にも、残業はないのがいいですよね。
また稼働時間における活動は以下の 2 種類と整理してみました。
- 機能開発工数
- 障害対応工数
機能開発工数 はこの後説明します。
障害対応工数は、計画にない対応へ奪われる時間を指します。名前のとおり障害対応がメインとなりますが、ほかにも、問い合わせ対応やデータ不整合の修正など、突発的な作業全般を含みます。
機能開発工数
機能開発工数 を以下のように考えました。
- コア機能開発
- 所属組織において優先度高く取り組みたい開発タスク（いわゆるデリバリー）
- コア機能について意思決定をするためのタスク（いわゆるディスカバリー）
- 意思決定のための調査や PoC 開発もここに含む
- 運用基盤開発
- CI/CD といった業務効率化の側面が強いタスク、保守にかかるタスクをイメージします
- 維持することでトラブルを未然に防ぐようなタスクもここに含む
- CI/CD といった業務効率化の側面が強いタスク、保守にかかるタスクをイメージします
全体像
ここまでの内容で稼働時間を下図のように整理してみました。
残業、障害対応工数を抑え、運用改善にも対応し、機能開発に比重高く取り組めていることは 開発生産性 が良い状態と考えます。
開発生産性が悪い例
以下の極端な例をみてみましょう。
- 稼働時間に占める残業時間の割合が多い例
- 稼働時間に占める障害対応工数が多い例
過度な残業は疲労・ストレス・健康へ悪影響を与え生産性を低下させることや、離職率の上昇リスクがあります。 障害対応に追われ続け、機能開発に取り組めていない状態も、ユーザーに価値を届けられず、ビジネスの成長を阻害します。
どちらも 開発生産性 が良い状態とは言えないでしょう。
機能開発工数を多くするための克服案
前述した 2 つの例を解決するため、運用基盤開発に注力することは 開発生産性 を良くする 1 つの手段と考えます。
一時的に運用基盤開発に注力し、運用基盤を整えた後コア機能開発の割合を増やしていくイメージです。日常的に発生する作業を効率化する開発や、技術負債を解消することで、将来発生し得る障害対応工数や運用基盤開発を減らすことを目的とします。
DevOps にかかわる開発は組織全体に対して未来の時間を増やすことにもつながるため、早いうちに整備しておくことは重要と考えます。 増えた時間はコア機能開発に充てられ、品質を高くするための開発工数にも充てられるでしょう。
過去記事に 税理士ドットコム流のCI/CDを設計する考え方と実践 があります。よければ読んでみてください。
価値あるアウトカム
機能開発に時間が当てられるようになっても、まだ 開発生産性 が良いとは言えないと考えています。 それは「機能開発に時間が充てられている」という指標が目標となってしまっている状態だからです。
価値あるアウトカムを持続性をもって創出している状態
では、価値あるアウトカムとはなんでしょうか。
それは組織やプロダクトによって大きく異なります。ユーザーにとっての価値、ビジネスにとっての価値、そしてチームにとっての価値など、多面的な視点で考える必要があります。
重要なのは「何をデリバリーしたか」ではなく「そのデリバリーによって何が変わったか」を常に問い続けることです。 機能追加や改善が実際にユーザーの行動や感情にどのような変化をもたらしたのか、ビジネス指標にどのような影響を与えたのかを観測することで、価値あるアウトカムを見極めることができると考えます。
また価値あるアウトカムを見出すためには、組織内での継続的な対話が不可欠です。デリバリーによってどんな影響を与えられそうか、何を成功と捉えるのかを事前に議論し、共通認識を持つことも重要です。
この対話と検証のサイクルを回し続けることで、組織にとっての「価値あるアウトカム」の定義が徐々に明確になっていくと考えます。
具体的な事例を挙げて「開発生産性 が良い状態」を断言できませんが、これまで述べた内容を実践しながら妥当性を検証していきたいと考えています。新たな気づきがあれば、今後もブログで共有します。
最後に
日々の業務で感じる 開発生産性 について、私なりの考えを紹介しました。 サービスを維持、成長させていくことは簡単なことでありません。今自分たちが置かれている状況を理解し、業務のバランスを理想の形に近づけ価値を創出していく継続的な努力が必要です。
ハックできる指標を追いかけるのではなく、価値あるアウトカムを創出していくために今自分たちが何に注力すべきか、それを考えるきっかけになれば幸いです。
