第276回： 「CMMIのすすめ」4 （CMMIが用意した仕掛け 中編）
◀前の記事へ 次の記事へ▶︎
≡ はじめに
前回は、「CMMIが用意した仕掛け」のうち「❶ ステップアップの仕掛け」について書きました。また、「❷ モデルを使う」について途中まで書きました。
「❶ ステップアップの仕掛け」で、一番大事な箇所を再掲します。
「レベル3を達成するためには標準化を行って、“標準プロセスマニュアル”を作ってそれを使うことでプロセスを安定させる」、「レベル4では、安定したプロセスに対して“統計手法を使用して予測、制御”する」、「レベル5では、レベル4の活動成果がプロジェクトの成果にとどまらず事業成果に結びついている」というように組織能力を段階的に成熟させると上手くいくとCMMIは言っています。
その通りだ！と思う一方で、普通の開発組織が、最速でレベル3になるまでに2年、レベル4になるには更に2年、レベル5になるのに更に2年かかることを考えると、最速でレベル5に達するとしても6年かかり、「えー？そんなにかかるの？」となります。
第一回目に私の経験を書きましたが、CMMの環境が色々と整っていない状況とはいえ、レベル2になるのに30カ月、2から3になるのに32カ月かかっていますので、レベル3になるまでに計62カ月（5年2カ月）かかりました。
レベル5までチャレンジを続けていたら10年はかかったのではないかと思います。
こちらによると、今の会社でも取り組みを2015年に始めたと書いていますので、9年間かかっています。
様々な事情があると思うので一概には言えませんが、レベル1を取る企業は本当に少ないです。
普通の企業ではレベル2から始めるのですが、ISO 9001を取得している企業は「品質マニュアル」というQMSを支援するためのプロセスを文書化したものを作っているはずなので、レベル3からでよいと思います。
なお、NECのようにいきなりレベル5を取ってしまう企業もありますが、かなり例外です。
ところで、問題はレベル5に到達するまで、10年かかることではありません。問題は「プロセス改善の取り組みを始めて10年しないと効果は表れないのか？」という点です。
今回の、「❷ モデルを使う（の後半）」ではこの点について、そうならない仕掛けがあるということを書きたいと思います。
なお、書いてみたら長くなってしまったので「❸ アプレイザル」については次回に回します。
≡ CMMIの仕掛け
❷ モデルを使う（の後半）
ソフトウェア開発をTQCの道具を使って良くしていきたい。そのために、「統計が使える土台（前提）を固めよう」、「組織能力を段階的に無理なく、スムーズに成熟させよう」とCMM（を創ったハンフリー）は考えました。そしてCMMIにその考えは受け継がれました。
その結果、上に書いたとおり、「レベル5にならないとTQCは始まらないのか。それまでの10年間はどうしたらいいんだ。」という課題が発生しました。
もっとも、実際に、CMM/CMMIに取り組んでいる企業は、そんなことには頓着なく、レベル2からレベル3になれば、品質と生産性が1.5倍になると無邪気に信じているかもしれません。
しかしながら考えてみたら、レベルは、比例尺度（比率計算が可能）ではなく、間隔尺度（数字の間に等しい距離がある）ですらなく、順序尺度（データに順番やランキングができる）です。
ですからレベル2からレベル3で、1.5倍の品質や生産性というような乱暴な計算ができるわけがないのですが、数字で示されると、できそうな気がするようです。
「初期レベル」、「計画ありレベル」、「開発標準をテーラリングレベル」、「統計活用レベル」、「最適化レベル」といった名称にするほうが誤解がなくて良いと思うのですが……。
それで、CMMI 1.3までは、この課題に対して、仕組みとしての対応は、できていなかったと思っています。
特に、初期のCMMの時代には「あるレベルを、到達してからでないと上位レベルの活動は行うべきではない！？」といった今考えたらバカバカしいことすら真面目に議論されていました。
ところが、CMMI 2.0から、「プラクティス文」に「価値」が追加されたことで、一気に良くなりました。
「価値」については、一般に非公開なのですが、「見積もり(Estimating, EST)」というプラクティスエリアだけ一部公開されているので、それを使って説明します。
EST 1.1
プラクティス文
作業を実施するための概算見積もりを作成する。
価値
スケジュールや予算が超過する可能性のある作業が続くことを回避するため、概算見積もりを行い、作業の規模、費用、およびスケジュールの不確実性に対応する。
EST 2.1
プラクティス文
見積もり対象のスコープを作成し、最新に保ち、使用する。
価値
目標達成と手戻り回避の見込みを高めるため、ソリューションの全てに確実に取り組む。
上記は、EST 1.1とEST 2.1の「プラクティス文」と「価値」です。
CMMIのレベル1を達成するためには、EST 1.1を満たす必要があります。（CMMIの連載の1回目に書いた通りです）
ここで、プラクティス文とは、「そのプラクティスで実施すること」です。
EST 1.1なら「作業を実施するための概算見積もりを作成する。」と書いてありますのでEST 1.1の要求を満たすためには、「概算見積もりを作成」すればよいということが分かります。
ここで、プラクティス文は「必要条件」だけれども「十分条件」ではないことに注意が必要です。
つまり、「概算見積もりを作成」することは必要条件ですが、それだけでは、EST 1.1を達成したかどうかは判断できないということです。
組織がEST 1.1を達成したかどうかは、「EST 1.1」の価値が提供できているかどうか、すなわち「作業の規模、費用、およびスケジュールの不確実性に対応できている」かどうか、「スケジュールや予算が超過する可能性のある作業が続くことを概算見積もりを作成することによって回避できているかどうか」で見極めます。
前回、以下の図を描きました。
でも実際は、先に書いた通り、それぞれの段階で価値を提供しています。したがって、下の図の方が、より正確です。
《ソフトウェア開発プロセスの生産性を上げたい。また、開発成果物（プロダクト）の品質を上げたい》というのはソフトウェア開発者の共通の願いでしょう。
もしも、そう思っていない開発組織があったら、そう思っていないことに問題があります。
さて一般に、ソフトウェア開発で困った時には、ソフトウェア工学の本を読みます。たとえば、『実践ソフトウェアエンジニアリング (第9版)』を読みます。そこには、実証済みの良い方法が多く書いてあり、とても役に立ちます。
一方で、「どこが悪いのかわからないのだけど、このままじゃいけないってことだけは、わかっている」というケースもあります。
「ソフトウェア開発」には、「なにをすればいいのか」が見えにくいという側面があります。
自分たちの仕事の進め方に何かが足りていないことには気がつきます。ところが、足りていないことに気がついても「なにをすればいいのか」が分からないことが多いものです。
また、仮に分かったとしても難しすぎて手が出ないということが起こります。
プレスマンの『実践ソフトウェアエンジニアリング (第9版)』を読めば「なにをすればいいのか」は見つかりますし、その何かをコーチしてくれる人も探せば見つかります。（社外のコンサルタントだけではなく、社内の有識者も見つかります）
でも、現状とのギャップを段階的に埋めない限りその「何か」だけを実践しようとしてもうまくいきません。
「何か」とは、例えば、「リリース後のリスクの予測」です。
そんなときには、CMMIのようなプロセス診断（アセスメント）がついていて、段階的に良くしていく方法がおすすめです。
さらに、CMMIでは、「これを行え（プラクティス文）」と「実施して成功した時に得られる価値」がセットになっていますので、レベル5を獲得してから得られる価値だけではなく、レベル1ならレベル1なりの価値が得られます。
この仕掛けは本当にとてもよくできていて、全てのプラクティスに価値が書いてあるので、CMMI 2.0の教本を読み返すたびに「良くできているなあ」と感心します。（多くのソフトウェア工学の研究者が、何千もの組織を研究して、何十年もかけてつくっただけのことはあるなあと）
≡ おわりに
今回は、「CMMIが用意した仕掛け 中編」をテーマに書きました。
ゴールに向けて段階的に習得する技術と、それを実践した時の価値がセットになって提供されているという点が「❷ モデルを使う」に隠された？仕掛けです。
ようやく、お勧めする理由の一つが書けました。
次回は後半（❸ アセスメント）を書きます。これも、非公開事項ばかりなので細かなことは書けないのですが、アセスメントを毛嫌いする人の気持ちを少しでも前向きにしたいです。
この記事が気に入ったらサポートをしてみませんか？