システム開発やITインフラの構築において、外部のベンダー(委託先)を選定する際、あなたは何を基準にしていますか?
これまで多くの企業が、開発チームや組織のレベルを測るために「CMMI(能力成熟度モデル統合)」に代表される「成熟度モデル」を指標としてきました。
つまり「この会社はレベル4を満たしているから安心だろう」という選び方です。
しかし、DevOps界隈でバイブルとなっている名著『LeanとDevOpsの科学』では、この成熟度モデルによる評価を真っ向から批判し、新たな目標として「ケイパビリティ(能力)モデル」へ移行すべきだと強く主張しています。
今回は、成熟度モデルが抱える4つの問題点と、そこから見えてくる「委託先選定の終わらない苦悩」について解説します。
『LeanとDevOpsの科学』が指摘する成熟度モデルの4つの罠

CMMIなどの成熟度モデルは、組織のレベルを1〜5の段階で視覚的に分かりやすく評価できるため、非常に普及しました。しかし本書では、テクノロジー変革の時代において、これを目標設定に使うのは「ツールとしても心構えとしても不適切」だと指摘しています。
その理由として、以下の4つの問題点が挙げられています[1] … Continue reading。
「完了」という概念を作ってしまう
成熟度モデルは「レベルに到達すること」に焦点を当てているため、「レベル4を達成したから、これで完了(上がり)だ」という官僚的な空気を作りがちです。しかし、本来のテクノロジー変革は「継続的改善」であり、状況は絶えず変化するため、到達して終わるような「静的なレベル」など存在しません。
すべての組織に「画一的な正解」を当てはめようとする
組織やチームが置かれているコンテキスト(状況、制約、文化)は多種多様です。それにもかかわらず、成熟度モデルはどのような組織にも同じ枠組みやテクノロジーの導入を「正解」として押し付けてしまう欠点があります。
プロセスではなく「静的な状態」を目標にしてしまう
本当に組織に必要なのは、現在のボトルネックを見極め、それを解消するために改善を回し続ける「動的なプロセス」です。しかし成熟度モデルは、特定のツールやルールを導入し、規定の「静的な状態」に留まることを目的化させてしまいます。
ビジネスの「成果」ではなく「導入したこと」を測ってしまう
成熟度モデルは「この枠組みを導入したか」「環境が整っているか」というチェックリストになりがちです。本来測定すべき「それが事業のパフォーマンス向上にどう貢献したか」というビジネス上の成果とは無関係に評価されてしまいます。
【SSAITSの視点】委託先選定で露呈する「形骸化」のリアル
本書で指摘されているように、成熟度モデルは「達成されたら終わり」という一過性の目的になりやすいという致命的な弱点を持っています。
そして、この問題が最も残酷な形で顕在化するのが、発注側による「委託先の選定」の場面です。
元々CMMIは、「発注先を選ぶ際の客観的な指標が欲しい」というニーズから生まれた側面があります。しかし、発注側が「CMMIレベル〇を満たしているか」をチェックシートで確認しても、実際のプロジェクトでは以下のような悲劇が頻発します。
- プレゼンでの口約束: 提案時の口頭では「要件を満たしています」と立派に語るが、現場のプロセスには全く浸透していない。
- 過去の栄光: 過去に審査を受けたときは確かにレベルを満たしていたが、メンバーが入れ替わり、現在は形骸化して当時の品質を保てていない。
- 審査のための審査: 「資格を維持するためのドキュメント作り」ばかりが上手くなり、肝心の開発パフォーマンスが著しく低い。
これらはすべて、成熟度モデルが「継続的改善のプロセス」ではなく、「認定を取ること(静的な状態)」をゴールにしてしまった結果生じる歪みです。
まとめ:外から「ケイパビリティ(能力)」を測る難しさ
『LeanとDevOpsの科学』が主張するように、あらかじめ決められた階段を登るのではなく、自分たちのビジネス上の制約を解消するために、その時々で必要な「ケイパビリティ(能力)」を継続的に高め続けることが、真の高業績組織を作る唯一の道です。
しかし、この「ケイパビリティ」という動的で目に見えにくいプロセスを測定することは、組織の内部でさえ容易ではありません。ましてや、外部の委託先を選定する際に、彼らの真のケイパビリティを正確に測ることは至難の業です。
「この資格があるから」「このレベルに達しているから」という分かりやすい指標(成熟度モデル)に頼りたくなるのが人間の心理ですが、それだけでは本質は見抜けません。
まだまだ、私たちが委託先の選定に苦労する時代は続きます。
だからこそ、表面的なバッジ(レベル)に惑わされることなく、ベンダーと対話を重ね、「彼らが今、どのような継続的改善のプロセスを回しているか」を見極める泥臭い努力が、発注側にも求められているのです。
参考
- ニコル・フォズグレン、ジェズ・ハンブル、ジーン・キム(著)、武舎広幸、武舎るみ(訳)『LeanとDevOpsの科学』インプレス、2018年
注
| ↑1 | ニコル・フォズグレン、ジェズ・ハンブル、ジーン・キム(著)、武舎広幸、武舎るみ(訳)『LeanとDevOpsの科学』インプレス、2018年、9頁~11頁より。 |
|---|

