こんにちは。株式会社MonotaROのECシステムエンジニアリング（ECSE）部門で、ECサイトの開発を担当している岡﨑です。
「開発生産性」という言葉を聞いて何を思い浮かべるでしょうか。
ツールを導入すること？ Four Keysなどの開発生産性指標の数値を改善すること？ それとも、開発プロセスを見直すこと？
多くの組織が「これだ」という正解を見つけられずにいる中、私たちもまた、指標計測の導入後の失敗や根本的な考えの転回といった「壁」に直面しました。
本記事では、MonotaRO で「開発生産性の向上」というテーマにどのように向き合い、私たちのチームで具体的にどのような試行錯誤を経て、何を学んできたのかをお話しします。
私たちの取り組みは、決して順風満帆なものではありませんでした。指標計測の失敗や、思うように成果が出なかった経験も赤裸々に共有することで、同じように開発生産性の向上に取り組む開発チームや組織の皆さまにとって、一つの実践例として参考にしていただければ幸いです。
「開発生産性」とは何か？―指標の基本と実践の重要性
まず、「開発生産性」という言葉の定義から始めたいと思います。生産性は、一般的に以下の式で表されます。
生産性 = アウトプット / インプット
ソフトウェア開発において、「インプット」は開発者の人数や労働時間、コストなどが該当します。一方で「アウトプット」は、コードの行数や実装した機能の数などが該当します。
近年、ビジネス環境の変化が速まる中で、開発チームには「より速く、より多くの価値を顧客に届けること」が強く求められるようになり、この開発生産性とその可視化が注目されています。
その代表的な指標が、GoogleのDevOps Research and Assessment（DORA）チームが提唱した 「Four Keys」です。これは「デプロイの頻度」「変更のリードタイム」「変更障害率」「サービス復元時間」という4つの指標で、開発チームのパフォーマンスを「スループット」と「安定性」の両面から計測するものです。
しかし、これらの指標をただ追いかけるだけでは不十分です。開発生産性にはいくつかのレベルが存在します。
- レベル1：仕事量・作業量の生産性: 実装したストーリーポイントやプルリクエストの数など、アウトプット量を測る。
- レベル2：期待付加価値（アウトカム）の生産性: ユーザーの行動変容など、提供した機能がもたらす「価値」を測る。
- レベル3：実現付加価値（インパクト）の生産性: 売上への貢献など、ビジネス上の「成果」を測る。
参考：
qiita.com
多くの組織がレベル1の計測から始めますが、本当に重要なのはレベル2以上の、顧客やビジネスへの貢献を意識することです。
ECSE部門での開発生産性向上――実際の取り組みと試行錯誤
ECSE部門では、2021年から開発生産性向上の取り組みを開始しました。きっかけは、ソフトウェアの内部品質が悪化していたことでした。この課題意識から、部門としての改善活動がスタートしました。
2021年：カナリアリリースからのスタート
当初、私たちは外部の識者に相談することから始めました。そして最初に着手したのが、デプロイ頻度を高めるための「カナリアリリース」です。
カナリアリリースとは、新機能を一部のユーザーに限定して先行公開し、問題がないことを確認した上で、段階的に全ユーザーへ展開していくリリース手法です。これにより、安全性を確保しながらリリースサイクルを速めることを目指しました。
当時の取り組みとその評価については、過去のブログ記事でも取り上げられておりますので、こちらもお読みいただければと思います：
tech-blog.monotaro.com
tech-blog.monotaro.com
2022年：Four Keysの可視化
次のステップとして、2022年にはFour Keysの可視化と定点観測を開始しました。これにより、部門全体の開発パフォーマンスを客観的な指標で把握し、データに基づいた改善を行うための土台を築こうと試みました。
こちらも、導入の経緯などについてはブログ記事になっておりますので、こちらもお読みいただければと思います：
2023年：取り組みの本格化と専門グループの発足
2023年に入ると、部門内チーム横断での「開発生産性MTG」が定例開催されるようになり、11月には「開発生産性グループ」が正式に発足しました。これにより、部門としてより腰を据えて生産性向上というテーマに取り組む体制が整いました。
2024年〜2025年：戦略の整理と各チームへの展開
2024年には、これまでの活動を元に部門としての開発生産性向上の戦略やストーリーの整理を行いました。そして2025年現在、各開発チームでの開発生産性向上のための具体的な取り組みが本格化しています。
私たちのチームでも、まずは自分たちの現状を把握し、改善サイクルを回すことを目標に、開発生産性向上の取り組みを開始しました。
このように、部門全体としては着実にステップを踏み、成功事例も生まれてきました。しかし、これらの仕組みを個々の開発チームの日常業務に落とし込み、成果に繋げていくには、また別の壁がありました。
ここからは、筆者の所属するチームでの具体的な取り組みと、そこから得られた学びについてお話しします。
自チームでの取り組みで見えた新たな課題
私たちのチームで最初に行ったのは、「バリューストリームマッピング（VSM）」です。これは、アイデアが生まれてからユーザーに価値が届くまでの全工程を可視化し、どこにボトルネックや無駄があるかを特定する手法です。
VSMを通じて、私たちは「開発着手から本番リリースまでのリードタイム」や「プルリクエストがレビューされマージされるまでの時間」などを具体的な指標として設定しました。そして、これらの数値を継続的に計測し、改善を図ろうとしたのです。
しかし、結果は思うようについてきませんでした。いくつかの指標は目標値に届かず、特にリードタイムは改善されるどころか、逆に長期化してしまうことさえありました。現場の開発メンバーからは、「これ以上、個々のタスクを速くこなすのは限界がある」という切実な声も上がっていました。
なぜ、指標は改善しなかったのでしょうか。私たちは、計測している数値の裏側にある根本的な原因を探ることにしました。例えば、「プルリクエストのマージ遅延」という問題一つをとっても、その背景には「レビューの待ち時間が長い」「仕様の手戻りが多い」など、様々な要因が複雑に絡み合っていました。
こうした壁に直面していたタイミングで、チームリーダーから DORA Core Model や DX25 といったフレームワークの存在を教わりました。これらは、開発生産性に影響を及ぼす技術的・組織的な要因（ケイパビリティ）と、パフォーマンス指標、そして最終的な組織成果との因果関係を体系的に整理したものです。
これらの理論に触れたことで、私たちは重要な気づきを得ました。それは、「ただ数値を追うだけでは、本質的な改善には繋がらない」ということです。個別の指標を改善しようと対症療法的な施策を打つのではなく、開発プロセス全体やチームの働き方そのものを見直す必要があったのです。
「価値」に向き合うためのタスク分解
私たちの試行錯誤の中で、最も大きな課題として浮かび上がってきたのが「タスクの分解方法」でした。
従来、私たちのチームでは、技術的な関心事ごとにタスクを分割する、いわば「横のタスク分割」を行っていました 。これは、データベースアクセス、ビジネスロジック、UI層といった技術レイヤーごとにタスクを分ける考え方です。
この方法では、各レイヤーのタスクがすべて完了しないと、一つの機能としてユーザーに価値を届けることができません 。また、機能が複雑になると各層のタスクが増え、タスク間の関連性が分かりにくくなり、レビューがしにくくなるという問題も抱えていました。
そこで私たちは、チームリーダーからのアドバイスも参考に、ユーザーに価値を届けられる最小単位で機能縦断的にタスクを分割する「縦のタスク分割」へと大きく方針転換しました 。これは、一つの機能を実現することを一つのタスクと捉える考え方です。
データベースアクセス、ロジック、UIの各層を貫く形でタスクを切り出すことで、最低限の機能が動く状態を素早く作り上げます。この方法の最大のメリットは、タスクの完了が直接「機能が使えること」に繋がることです 。
レビューも機能単位で行えるため容易になり、そして何より、たとえ小さな単位でも機能が使えるということは、それだけで「価値が生まれる、提供できる」ということに繋がります 。これにより、これまで計測が難しかったレベル2の開発生産性、つまり「どれだけ価値を提供できたか」を測るための第一歩を踏み出すことができるのです。
この「縦のタスク分割」を実践するためには、開発チーム内だけの努力では限界があります。企画担当者であるプロデューサー（※）と開発者が一体となり、「この機能を通じて、ユーザーにどのような価値を届けたいのか」という本質的な議論を重ねることが不可欠です。開発エンジニアが、単に仕様書通りにモノを作るだけでなく、企画の初期段階から価値の定義に関わっていく。プロデューサーもエンジニアに対して価値を届けるためのタスク分解がしやすいように企画の構想を練って開発者に伝える。こうした組織横断の協働こそが、本当の意味での生産性向上に繋がるのだと、私たちは考えています。
※MonotaROでは、一般的に「プロダクトオーナー」と呼ばれるポジションを「プロデューサー」と呼んでいます。
「開発生産性」のこれから――現場から得たヒントと次のアクション
先日、「開発生産性 Conference2025」に参加した際、多くの企業が私たちと同じようにレベル1の生産性（作業量）の可視化や改善に取り組んでいる一方で、レベル2以降の「価値」をどのように定義し、計測していくかについては、まだ確立された手法が少なく、各社が模索している段階であることを改めて認識しました。
「価値」の定義に、普遍的な正解はありません。だからこそ、私たちのチームでは、今後も以下のようなアクションを継続していきたいと考えています。
- タスク分割のさらなる洗練: プロデューサーとの対話を密にし、より小さな単位で、かつユーザー価値に基づいたタスク分割を追求する。
- 部門横断での協働強化: 企画、開発、デザインといった各部門が、プロジェクトの初期段階から共通のゴールを持って連携できる仕組みを構築する。
おわりに
私たちのこれまでの取り組みから得られた学びをまとめると、以下のようになります。
- 開発生産性の向上は、単なる開発スピードの向上を意味するものではない。
- Four Keysなどの指標はあくまで現状を把握する手段であり、数値を追うこと自体が目的ではない。
- ユーザーに素早く価値を届け、フィードバックを得るための「縦のタスク分割」が極めて重要である。
- そして最も重要なのは、開発生産性の向上は開発チームだけの課題ではなく、企画やビジネスサイドを含めた組織全体の協働によってこそ達成されるということ。
開発生産性向上の道筋は、組織ごと、プロダクトごとに異なります。本記事で紹介した私たちの失敗と学びが、皆さまの組織にとっての最適解を見つけるための一助となれば幸いです。
MonotaRO では一緒に開発生産性の向上を推進していく仲間を募集しています！もしご興味がありましたら、ぜひお気軽にお声がけください。カジュアル面談もやっています！
