はじめに
「エンジニアリング組織の生産性をどう測るか？」
これは、CTO やエンジニアリングマネージャーにとって、常に頭を悩ませる難問です。
コード行数やコミット数で測るのは時代遅れだとわかっていても、では具体的に何を指標にすればいいのか。ビジネスサイドに開発チームの価値をどう説明すればいいのか。
今回取り上げる Michiel Mulders 氏による記事 『Engineering Productivity: How to Measure and Improve It（エンジニアリングの生産性：測定方法と向上させるためのヒント）』 は、こうした疑問に対し、現代的な「開発者体験」と「ビジネス成果」の両面から明確な答えを提示しています。
本記事では、このブログの要点を解説しつつ、なぜ今この視点が必要なのかを考察します。
1. 著者はどんな人物か：Michiel Mulders
この記事の著者である Michiel Mulders（ミヒール・ムルダーズ）氏は、テック業界でどのような立ち位置にいる人物なのでしょうか。
経歴のハイライト
彼はオランダを拠点とする経験豊富なフルスタック開発者であり、同時に著名なテクニカルライターでもあります。モバイル開発や Web 開発のバックグラウンドを持ちながら、Google Developers Experts（GDE）のようなコミュニティ活動にも貢献してきました。
現在の活動
現在は主に、開発者向けツールやエンジニアリング文化に関する洞察を発信するライターとして活躍しています。特に、SitePoint、Toptal、そして今回の記事の掲載元である LinearB など、技術とマネジメントが交差する領域での執筆が多く見られます。また、最新の Web 技術や自動化ツールに関する実践的なガイドも多数手がけています。
評価される理由
彼が評価される最大の理由は、 「現場のエンジニアの視点」と「経営層が求める視点」のバランス感覚 にあります。単なる精神論ではなく、具体的なツールやメトリクス（指標）を用いた解決策を提示するため、エンジニアリングマネージャーにとって実践的なアドバイス源となっています。
2. なぜこのブログが執筆されたのか（背景の考察）
2024 年 3 月というタイミングで、なぜ改めて「生産性」が語られたのか。その背景には、テック業界を取り巻く環境の大きな変化があります。
「効率化」へのシフトと「Dual Mandate（二重の使命）」
かつての「成長至上主義」の時代から、現在は「効率性と収益性」が厳しく問われる時代へとシフトしました。記事中で触れられている 「エンジニアリングリーダーの二重の使命（Dual Mandate）」 という言葉が象徴的です。
- オペレーショナル・エクセレンス（運用の卓越性）の提供
- ビジネス成果の牽引
現代のエンジニアリング組織は、単に機能を作るだけでは不十分であり、それがビジネスにどう貢献しているかをデータで証明する必要があります。しかし、多くの現場では未だに「ベロシティ（速さ）」や「個人の消化タスク数」といった、本質的ではない指標を追いかけて疲弊しています。
著者は、こうした「間違った測定」が技術的負債や開発者のバーンアウト（燃え尽き）を招いていることに警鐘を鳴らすため、そして DORA 指標などの科学的なアプローチを普及させるために筆を執ったと考えられます。
3. 記事の要点解説
ここからは、記事で語られている「やってはいけない測定」と「推奨される 4 つの指標」、そして改善策について解説します。
❌ やってはいけない測定（アンチパターン）
記事では、以下の測定方法は生産性を向上させるどころか、阻害すると断言しています。
-
「スピード」への偏重（ベロシティの罠）
- 単に「速い」ことは、正しいものを作っていることや、品質が高いことを意味しません。技術的負債を無視したスピード追求は危険です。
-
個人の生産性測定
- 特定の個人のストーリーポイント数などを追うと、チームワークが崩壊します。レビューやサポートなどの「目に見えにくい貢献」が無視され、チーム全体の最適化が損なわれます。
-
アウトプットベースの指標
- 「コード行数」などは簡単に数字を操作（ハック）できてしまい、ビジネス価値とは無関係です。
✅ 推奨される 4 つの指標
著者は、本当に見るべき指標として以下の 4 つを挙げています。これらは LinearB などのプラットフォームが提唱する現代的な指標です。
-
マージ頻度（Merge Frequency）
- 意味： どれだけ頻繁にコードがマージされているか。
- なぜ重要か： マージ頻度が高い＝ PR が小さく、レビューがスムーズであることを示します。「マージできている開発者はハッピーである」という視点は重要です。
-
サイクルタイム（Cycle Time）
- 意味： コーディング開始からデプロイまでの時間。
- なぜ重要か： プロセスのどこにボトルネック（待ち時間）があるかを特定できます。
-
精度スコア（Accuracy Scores）
- 意味： 計画した作業のうち、実際にどれだけ完了したか。
- なぜ重要か： 予測可能性（Predictability）を高めるためです。ビジネスサイドとの信頼関係構築には「約束を守る能力」が不可欠です。
-
リソース配分（Resource Allocation）
- 意味： 「新機能」「バグ修正」「技術的負債の解消」など、何にどれだけ時間を使っているか。
- なぜ重要か： これこそが「ビジネス整合性」の核心です。「忙しいけれど事業が伸びない」場合、リソース配分が間違っている可能性があります。
🚀 どう改善するか：プログラマブルなワークフロー
測定するだけでは不十分です。記事の最後では、改善のためのアクションとして 「プログラマブルなワークフロー（Programmable Workflows）」 の導入を推奨しています。
これは、小さな変更のレビューを自動承認したり、適切なレビュアーを自動でアサインしたりするなど、 「開発者のトイル（面倒な手作業）」を自動化で取り除く アプローチです。人間に「もっと頑張れ」と言うのではなく、システムで摩擦を減らすことが、結果として生産性向上につながります。
さいごに
Michiel Mulders 氏のこの記事は、エンジニアリングの生産性を「個人の頑張り」から「チームとシステムの効率性」へと視点を移すよう促しています。
特に印象的なのは、生産性を高める目的が「会社のため」だけではなく、 「開発者の幸福（Developer Happiness）」 とリンクしている点です。無駄な待ち時間を減らし、意義のある仕事（新機能開発など）に集中できる環境を作ることこそが、真の生産性向上策と言えます。
日本の開発現場でも、「ベロシティ」や「消化ポイント」に囚われている組織は少なくありません。まずは「リソース配分」や「サイクルタイム」の可視化から始めてみるのが、組織変革の第一歩になるのではないでしょうか。