【総まとめ】『LeanとDevOpsの科学』を読み終えて――CMMIに代わる「評価軸」を探して見つけた4つの指標と、人を守る仕組み

はじめに：なぜ私はこの本を手に取ったのか

私がこの本を手に取った動機はCMMIに代わる新しい評価軸を知りたかったからです。

システム開発の委託先を選ぶとき、私たちは長らくCMMIのような成熟度モデルを頼りにしてきました。しかし現場で使ってみると、CMMIには「ごまかしがきく」要素が多いです。
プレゼンでの立派な口約束と現場の実態が乖離していたり、レベルを取得した当時のメンバーがすでに入れ替わっていたり、「資格維持のためのドキュメント作り」が目的化していたりする。そうした違和感の正体を知りたくて、本書を開きました。

読み終えてみると、本書は「委託先の評価軸」という私の当初の関心に答えてくれただけでなく、それ以上に、IT企業が組織としてどうあるべきかについて多くの示唆を与えてくれる本でした。以下、私の関心の順に沿って整理していきます。

そもそもCMMIはなぜ「ごまかし」がきくのか

CMMIの生い立ち

まずはCMMIの成り立ちを確認しておきます。

CMMIの前身であるCMM（Capability Maturity Model：能力成熟度モデル）は、1986年に米カーネギーメロン大学のソフトウェア工学研究所（SEI）でワッツ・ハンフリーらによって開発されました。
研究資金を出したのは米空軍で、背景には、ソフトウェアの下請け業者が絡む軍のプロジェクトが予算超過・納期遅延を繰り返していたという事情があります。
つまりCMMは、発注元（政府）が発注先（契約業者）のプロセス能力を客観的に評価するためのツールとして誕生したものです。その後、複数のCMMが乱立したことを受けて2000年代初頭に統合されたのがCMMIです。

本書による成熟度モデル批判

興味深いのは、本書がこの成熟度モデルというアプローチそのものを「ツールとしても心構えとしても不適切」と切り捨てている点です。本書が挙げる問題点は4つあります。

私が現場で感じていた「ごまかしがきく」という違和感は、まさに4番目の「導入の測定」に起因するものでした。プロセスを導入した証拠（ドキュメント）さえ揃っていれば、成果が出ていなくてもレベルは取れてしまうのです。

本書はこれに代わるものとして「ケイパビリティ（能力）モデル」への転換を提唱しています。静的な到達点ではなく、成果につながる能力を継続的に測り、改善し続ける考え方です。

ただし、この転換は発注側にとって楽な話ではありません。外部ベンダーの真のケイパビリティを外から測ることは難しく、結局は対話を重ね、相手の継続的改善プロセスを見極める泥臭い努力が必要になります。CMMIという「わかりやすい印籠」を手放すことの代償は、正直に認めておくべきだと思います。

本書が提唱する評価軸：4つの指標

「望ましい尺度」の2つの条件

では、成熟度モデルの代わりに何を測ればよいのか。本書は望ましい尺度の条件として2つを挙げます。

4つの指標

この2条件を満たす指標として本書が提唱し、いまや業界標準になりつつあるのが「4つの指標」です。

観点	指標	意味
スピード	デリバリのリードタイム	コードのコミットから本番稼働までの時間
スピード	デプロイの頻度	本番環境への投入回数
安定性	平均修復時間（MTTR）	障害から復旧するまでの時間
安定性	変更失敗率	リリースのうち修正が必要になった割合

私がこの4つを「示唆的だ」と感じるのは、スピードと安定性の両方を同時に測る構造になっているからです。従来は「速さを取れば品質が落ちる」というトレードオフが当然視されていましたが、本書はデータによって、ハイパフォーマーはその両方を高いレベルで達成していることを示しました。

また、これらはドキュメントの有無ではなく、実際の本番環境の動きから計測されるものです。CMMIのように「体裁を整えればごまかせる」余地が小さい。ソフトウェア開発会社が自社の実力を示すうえでも、発注側が委託先の実力を見るうえでも、注目すべき指標だと思います。

使い方の注意

ただし本書も、そして私も、強調しておきたいことがあります。この指標を「罰するため」に使うと、現場はバグを隠したり数字を操作したりするようになり、指標は機能しなくなります。4つの指標は成績表ではなく、改善のための羅針盤として使うべきものです。

逆に「使ってはいけない指標」

正しい指標を知るには、誤った指標も知っておく必要があります。本書は従来よく使われてきた3つの尺度を「望ましくない指標」として名指ししています。

これらに共通する欠点は、「量」を測っていること、そして「個人や単一チーム」というローカルな範囲しか見ていないことです。
「人は測定されたとおりに行動する」という原則に照らせば、誤った指標は組織にとってマイナスな行動を確実に引き起こします。

この視点は、最近読んだPMBOK第8版の「チームのパフォーマンス評価」とも重なりました。PMBOKもチーム全体の有効性を測る大局的な指標を求めており、細かな個人作業量で評価すると「部分最適」に陥り、互いに助け合わないチームができあがると警告しています。正しい物差しを探し続けること自体が、リーダーの仕事だと改めて感じます。

指標の背後にある「組織」の問題

4つの指標が「グローバルな成果」を求めるのには理由があります。本書を読み進めると、指標の話は必ず組織文化の話に行き着きます。

混乱の壁（Wall of Confusion）

開発チームは「新機能をリリースすること（変化）」で評価され、運用チームは「安定稼働（現状維持）」で評価される。この相反するローカルな評価基準が両者の間に壁をつくり、「顧客へ価値を届ける」という本来のゴールを見失わせます。本書はこの壁を壊すために、両者が共有できる指標としてFour Keysを置いているわけです。

一方で、チーム指標だけに寄せると「個人の貢献が見えなくなり、優秀なメンバーが不満を抱く」というフリーライダー問題も起こりえます。私はチーム目標を最優先としつつ、個人データは「ノルマ」ではなく「健康診断」として計測し、1on1で個人の貢献を承認する、というバランスを提案しました。

Westrumの組織文化モデル

本書がパフォーマンスを左右する最大の要因として挙げるのが組織文化、とりわけ情報の流れです。社会学者ロン・ウェストラムの分類では、組織は「権力志向（不健全）」「ルール志向（官僚的）」「パフォーマンス志向（創造的）」に分かれ、創造的な組織は統計的に優れた成果をもたらすことが示されています。失敗を「犯人探し」ではなく「システム改善の機会」と捉えられるかどうかが分かれ目です。

「目に見えないもの」を測る技術：リッカート尺度とeNPS

本書のもう一つの面白さは、組織文化や心理状態といった曖昧なものを、科学的に測定できる形に落とし込んでいる点です。

Westrumの文化診断には、7段階のリッカート尺度による6つの質問が使われています。
ただ、日本の職場でこれをやると「どちらともいえない」に回答が集中する中心化傾向や、上司の望む答えを忖度する同意バイアスが出やすいことが予想されます。
あえて偶数段階にして中立を排除したり、匿名性を確保したりするといった運用上の工夫が必要です。

また、「あなたは自分の職場を友人に勧めたいか？」という究極の1問で測るeNPSも紹介されています。
本書のデータでは、ハイパフォーマー組織の従業員はローパフォーマー組織の従業員より職場を推奨する確率が2.2倍高いそうです。ただしこれも、低い点数をつけたら人事的に報復されるのではないかという恐れがあれば「忠誠心の踏み絵」に変質してしまいます。測定が機能する前提として、心理的安全性が必要です。

技術的な仕組みが「人の心」を守る

私が本書でもっとも面白いと感じた視点がこれです。継続的インテグレーション（CI）や継続的デリバリ（CD）といった技術的プラクティスが、バーンアウトを防ぐというのです。

技術の話と人の心の話は、普通は別々に語られます。しかし本書はデータで両者をつなげてみせました。

継続的インテグレーションと継続的デリバリ

CIとは、コードを定期的にチェックインし、そのたびに迅速なテストを走らせ、不具合が見つかれば直ちに修正するプラクティスです。複数チームがそれぞれ長期間独立して開発し、終盤でまとめて統合しようとして原因不明のエラーが多発する「マージ地獄」を防ぐための「こまめな合体」と言えます。

CDはそれをさらに進め、「いつでも・安全に・ボタン一つで本番環境にリリース可能な状態を常に保つ」ことを目指します。品質を最初から組み込む、作業を小分けにする、反復作業を自動化する、絶えず改善する、全員が責任を担う、という5つの原則が基盤です。

AIコーディングツールの登場で自動化のハードルは劇的に下がりました。一方で、AIが爆速でコードを書けるからこそ「まとめて一気に作ってもらおう」という誘惑が生まれ、「作業を小分けにする」というバッチサイズの原則が崩れやすくなっています。私は、人間が極限まで小さなスコープを設定し、小分けに書かせて即座にテストし、こまめに統合する、という運用を推奨しました。

「オフの満足度」とバーンアウト

では、これがなぜ心を守るのか。

金曜の夜や週末に手作業でデプロイし、休日中はアラートに怯える。私自身、会社員時代は「土日に連絡がこないか常に不安」でした。「期日が来たから勢いでえいやっと本番公開」という体制では、アップロード漏れや環境差分による予期せぬエラーが起き、その対応がまた休日を奪います。

CIとCDによってテストとデプロイが自動化されると、デプロイは「日中の低リスクなルーティン」に変わります。本書はこれを「オフの満足度」という形で測定し、技術的プラクティスへの投資が休日の質を向上させることをデータで示しています。

バーンアウトについても同様です。日本的なマネジメントは、燃え尽きを「個人のストレス耐性」の問題として扱いがちでした。しかし本書は、クリスティーナ・マスラックの研究（過重労働、自律性の欠如、不十分な報酬、人間関係の断絶、公平性の欠如、価値観のズレ）を踏まえたうえで、組織の仕組みを改善することが根本解決になると主張します。手作業の不確実なリリースを自動化して深夜作業と休日出勤をなくすこと、失敗から学べる文化をつくること、技術的負債を返す時間を確保すること。これらはすべて「人への投資」です。

精神論ではなく仕組みで心を守る。これは、IT企業の経営者やプロジェクトマネージャーが本書から受け取るべき、もっとも実践的なメッセージだと思います。

私の結論：CMMIの「代わり」は見つかったのか

最初の問いに戻ります。CMMIに代わる評価軸は見つかったのか。

答えは「半分イエス」です。

ソフトウェア開発会社が自社を評価する軸としては、4つの指標は十分に「代わり」になりえます。 本番環境の実データから計測され、スピードと安定性の両方を見るため、ごまかしの余地が小さい。さらに、4つの指標を改善しようとすれば、CI/CDの導入、混乱の壁の解消、情報がよく流れる文化づくりへと自然に手が伸びます。指標が組織を正しい方向に引っ張ってくれる構造になっているのです。

一方で、発注側が委託先を評価する軸としては、CMMIのように一枚の証明書で済む便利さはありません。 相手の4つの指標を外部から検証することは容易ではなく、結局は対話を重ね、相手が継続的に改善しているかを見極める努力が要ります。ただ、それは「証明書があれば安心」という幻想を捨てるという意味で、健全な方向だとも思います。

そして本書の本当の価値は、評価軸の話にとどまらないところにあります。指標・組織文化・技術的プラクティス・人の心が、すべてデータでつながっていることを示した点です。CIを入れると休日が守られ、バーンアウトが減り、職場を友人に勧めたくなり、それがまたパフォーマンスにつながる。IT企業にとって、これほど実践的な希望を与えてくれる本はそう多くありません。

記事一覧

本書について書いた記事を、本まとめの流れに沿って並べておきます。

テーマ	記事
成熟度モデルの限界	【CMMIの限界】成熟度モデルの罠と委託先選定の難しさ
正しい指標	【Four Keys】ソフトウェア開発の正しい4つの指標
誤った指標	【アンチパターン】「望ましくない3つの指標」
誤った指標	【PMBOK第8版】チームのパフォーマンス評価とは？
組織	「混乱の壁」とは？局所最適化が生む組織の分断
組織	「Westrumの組織文化モデル」
組織を測る	リッカート尺度とは？
組織を測る	eNPSとは？「究極の1問」と踏み絵の罠
技術的プラクティス	継続的インテグレーション（CI）とは？
技術的プラクティス	継続的デリバリとは？AI開発時代の「バッチサイズ」
人を守る仕組み	継続的デリバリが「オフの満足度」を上げる理由
人を守る仕組み	バーンアウトを防ぐには？「仕組み」で心を守る

まとめ

• CMM／CMMIは、米国防総省側が契約業者のプロセス能力を評価するためのツールとして生まれた。本書はこの成熟度モデルを「導入の有無しか測れない」と批判し、ケイパビリティモデルへの転換を説く
• 本書が提唱する4つの指標（リードタイム、デプロイ頻度、MTTR、変更失敗率）は、本番環境の実データからスピードと安定性を同時に測るため、ごまかしの余地が小さい。ただし罰ではなく改善のために使うこと
• コード行数、ベロシティ比較、稼働率100%は「人は測定されたとおりに行動する」がゆえに有害
• 指標の背後には組織文化がある。混乱の壁を壊し、情報が流れる文化をつくり、リッカート尺度やeNPSでそれを測る。ただし測定には心理的安全性が前提
• CI/CDという技術的な仕組みは、オフの満足度を上げ、バーンアウトを防ぐ。技術への投資は人への投資である

『LeanとDevOpsの科学』は、評価軸を探しにきた私に、評価軸以上のものを渡してくれました。ソフトウェア開発に関わる方、とりわけ「うちの会社は何を測るべきか」に悩んでいる方には、ぜひ手に取ってほしい一冊です。