LeanとDevOps生産性の神話(3) - CMMIへの批判は成り立つか？
CMMIに喧嘩を売る
「LeanとDevOpsの科学」にはもう一つ面白い議論がある。第１章「業務を加速させること」の中に「『成熟度』ではなく『ケイパビリティ』に焦点を」というセクションがあるのだが、そこでCMMI(能力成熟度モデル統合)に喧嘩をふっかけているのだ。
従来、現状把握や目標設定に成熟度モデル（maturity model）が使われることが多かったが、このモデルがツールとしても心構えとしても適切でない点は、いくら強調しすぎてもしすぎることはない。これに代わって、ソフトウェアのデリバリを加速させたい組織に必須なのが、ケイパビリティモデル（capability model）への移行なのである。
要は「成熟度モデル」なんて古いので、これからは「ケイパビリティモデル」を使うべきだという主張である。
ここで「成熟度モデル」と言っているのはCMMIを念頭に置いているんだと思うけれど、CMMIは「Capability Maturity Model Integration」の略なので、そこには「ケイパビリティ」も「成熟度」も含まれている。一体何を言っているのだろうか？
この文章の前後には「レベル２」であったり「プロセス」であったり「成熟度」といった単語がならんでいるので、間違いなくCMMIを指しているのだと思う。
それはCMMIではないのでは？
本書が指摘するCMMIの問題点を順に見ていこう。本書では「ケイパビリティモデル」が「成熟度モデル」に勝る理由は４つに集約できると言っている。まず一つ目。
第１に、成熟度モデルは組織が一定の成熟度に「到達」することに焦点を当てており、所定のレベルに到達すればそれで完了というスタンスを取っているが、テクノロジーの変革は「継続的改善」というパラダイムにシフトすべきなのである。
成熟度モデルは「到達」してしまったらそこで終わりなので「継続的改善」にはそぐわないと言っている。
少なくともこれを読む限り筆者はCMMIのプロセスという概念を全く理解していないか、CMMIの「レベル」の概念を誤解している。
開発のための CMMI 1.3 版の冒頭から引用する。
我々は、技術がとてつもない速さで変化を続ける世界に住んでいる。同様に、人員は典型的には生涯のキャリアを通して多くの会社に勤める。我々は動的な世界に住んでいる。プロセスの重視とはインフラストラクチャと安定性の提供であり、そのようなインフラストラクチャと安定性は、絶えず変化する世界を扱い、そして競争的であるために人員の生産性と技術の利用を極大化するのになくてはならないものである。
CMMIでは、技術が急速に変化する世界に対応するためには、人員やツールとプロセスを切り離す必要があるのだと主張する。そして、プロセスはプロセス単体として取り扱うことが可能で、動的な環境の変化に対応するための、組織の自己改善の動きを抽象化したものであるとしている。
本書の筆者はこのCMMIのプロセスを、組織の静的な姿を表していると誤解しているのだ。
CMMIの最も重要な思想は、組織の動的な自己改善運動を人員やツールと独立であつかえるということなのに、全く逆にとらえている。
本書では「所定のレベルに到達すればそれで完了というスタンス」と言っているが、CMMIではこうした組織の運動は継続した点検が必要だとしており、その証拠にCMMIのレベル認定は３年間しか有効ではない。いったい何をさして「それで完了」と言っているのだろうか？
２つ目に行こう。
ケイパビリティモデルへの移行が求められている第２の理由は、成熟度モデルは多くの場合、段階を追って所定の成熟度を達成していくことを良しとし、同じレベルのチームや組織には似たようなテクノロジーやツール、ケイパビリティを推奨していくという点である。特定のレベル（たとえば「レベル２」）と認定されたチームや組織は、どれも似たり寄ったりの状況、状態にあると仮定するが、これが現実に即していないことはテクノロジー関連組織で働く者にとっては周知の事実であろう。
ここでも同じ指摘が必要だろう。CMMIではテクノロジーやツールは時代とともに変化していくので、組織の状態を捉える際にはテクノロジーやツールとは切り離して考える必要があると明確に主張している。
本書では「特定のレベル（たとえば『レベル２』）と認定されたチームや組織は、どれも似たり寄ったりの状況、状態にある」としているが、ここでも本書の著者はCMMIでのレベルを静的な組織の状況、状態と誤解している。
私はCMMIの主張が全て有効と考えているわけではないが、CMMIを批判し検証するためには、少なくとも対象に関する正確な理解が必要だろう。
３つ目、
第３の理由は、ケイパビリティモデルは結果をベースにする点である。<中略>成熟度モデルはほとんどの場合、組織内での技術的熟練度やツールの利用状況を、成果とは無関係に測定するだけなので、結果はいわば虚栄の指標になってしまいがちなのである。
「ケイパビリティモデル」は結果を見るが、「成熟度モデル」は技術やツールの利用状況を把握するにとどまり、結果を正確に測定できないと言う。
ここまでくると、まともに検討するのもバカバカしくなってくるが、今まで触れた通り、CMMIでは技術やツールは時代と共に急速に変化するので、それらと切り離したものとしてプロセスを扱っている。
また、CMMIでは成果についても基本的に直接に扱うことはしない。人員x技術xプロセスの結果が成果であり、あくまでプロセスの改善の結果として成果が出るという間接的な扱いである。CMMIで成果を扱うとしても、レベル５の最適化の手続きの中で登場するくらいだろう。
最後４つめ
第４の理由は、成熟度モデルは、テクノロジーやプロセスに関わる能力（機能）や、組織そのものの能力に関して、到達するべき静的なレベルを定義するという点である。テクノロジやビジネスをめぐる状況が絶えず変化し続けている点を考慮にいれていないのである。
どうしても、静的なレベルという理解をしたいようだが、CMMIがそれと真逆であるのはこれまでの指摘で明らかだろう。むしろCMMIは「テクノロジやビジネスをめぐる状況が絶えず変化し続けている点を考慮にいれて」いるのである。
率直に言って本書におけるCMMIの批判は、CMMIについての無理解あるいは単なる無知から来ているのではないだろうか。
管理するのではなくエンジニアリングするのだ
なぜこんなことが起きるのだろう。それは本書の著者に、DevOpsの生産性を組織の生産性に直接結びつけたいという強いモチベーションがあるからだと思う。だからこんな無理筋の主張をするはめになるのだ。
私は、序文のマーティンファウラー氏と同じく、重要ではあるがあくまで開発の一部に過ぎないDevOpsの生産性を、組織全体の生産性に結びつけることはできないと考える。
もっと言えば、生産性という概念から検討が必要だと考える。CMMIは人間と技術から切り離したものとしてプロセスを扱うことで、生産性や成果についての不毛な議論から人々を解除した。
2022年にストックホルムで開催されたカンファレンスでジャスティン・リオック氏が「Developer Productivity Engineering」と題した講演を行なった。彼は当時JavaのビルドツールのGradle社のCTOだったので、ポジショントーク的な部分は割り引いて考える必要があるが、開発の生産性を考えるうえで、個別の現実的な改良にフォーカスしている点が印象に残る。
「Developer Productivity Management」ではなく「Developer Productivity Engineering」なんだと、管理するのではなくエンジニアリングするべきだという主張は、本書のような粗雑なモデルの主張よりも、より現実的な解に近づく手がかりになるのではないだろうか。
この記事が気に入ったらサポートをしてみませんか？