TMMi(Test Maturity Model Integration)その2

その１からの続きです。

 

■縦軸：成熟度レベル

TMMiの縦軸（成熟度）には下図のようにLevel1～Level5の5段階があります。

（これは組織の成熟度を示す軸であって、プロセス単位の能力レベルではないことに注意してください。）

Software-CMMの開発時に考案された成熟度ですが、大枠で以下のような意味があると思います。

（あくまでも私の理解です。本家であるSEIから見ると異なっているかもしれませんのでご注意ください）

・Level1（初期）：

管理面、モノづくり面の両面でいろいろ実践が不十分な状態。

作業は場当たり的で、人により実践方法がバラバラになっている。

プロジェクトの成功は、リーダや担当者の頑張りと経験・能力に依存してしまう。

要求を満足するソフトウェアやサービスを提供することもあるが、過少見積による予算超過、納期遅延、納品後障害などが多い。

にもかかわらず、組織としてどのような状態なのかを把握していない、改善も魔女狩りや見当違い／形式的な対策で効果が得られにくいなど、管理面が非常に弱いとも言える。

 

・Level2（管理された）：

Level1の状態を打開する意思を持ったチーム･組織が、その対策を実践することでLevel2に上がってくる。

（その意思もないのに形式的に真似るだけでは成果に結びつかないことに注意）

チーム内での作業方法をできる限り同じにするために必要なプロジェクト標準なども整備され、その内容に基づき運営する。

要件を管理し、計画に基づくプロジェクト運営を実践する。

監視・測定に基づき粗いながらもマイルストン時の状況が把握でき、そのタイミングでのコントロールが実践される。

現実的な見積に基づく運営になっていくため、要求を満足するソフトウェアやサービスを提供する確率が高まり、予算超過、納期遅延、納品後障害などはLevel1の状態より改善される。

ただし、これらの内容は「プロジェクト単位」のもので、組織全体で見るとプロジェクト間にバラつきが存在するのが特徴。

 

・Level3（確立された）：

プロジェクト毎にばらついているLevel2の状態を組織全体で統制し、組織的・系統的に実践できるようにしたのがLevel3。

体系的かつLevel2より厳密な組織標準群を立ち上げ、それをベースにそれぞれのプロジェクトを運営することで一貫性を確保する。組織標準をベースにしつつ、プロジェクトの背景や特性に適切に対応するために、テーラリング（仕立て直し）を導入するが、この内容と実践が成果を左右するカギの一つとなる。

以上のように組織的な統制を重視するが、その管理は定性的なものが中心となっている特徴がある。

※組織的に統制することがどのような成果につながるのかを明確化せずに取組み、形はあるが中身が伴わない状態に陥ることも多いので要注意。

・Level4（定量的に管理された）：

Level3では実践不足となっていた品質、プロセスの両面での”定量的な”管理が実践され、それぞれを制御するのがLevel4。

その実現を後押しするのが”計測・測定”。その実践によりモノゴトを定量的に把握することができ、先の見通し＝予測して適切な対策が打てるようになる。この手段を使ってプロセスと品質を制御する。

・Level5（最適化している）：

Level4の実践により精度を高め、漸進的（順を追って少しずつ目的を遂げる）な改善策や革新的な技術の改善策を使いこなしてさまざまな変化に対応し、機会を活かしながら、常に欲しい成果を実現しつづける状態がLevel5。

定量的な状況把握や原因分析に長け、的確な先読みによる予防処置を実践できる。

成熟度では、レベルが高まるにつれてその対象が「個人→チーム→部署→部門→組織全体」と拡大していることがわかります。→Level1～Level3までに主な対象が「個人→チーム→部署→部門→組織全体」と拡がっています。

ではLevel4以上の対象はどこなのか？というと（CMMIを構築したSEIが定めたアセスメントとしては）、Level4はLevel3までが実現できていないと”×”となっているため組織全体でLevel4と5が問われます。

(組織の成熟度を問うモデルなので当然といえば当然ですが)

しかし、それはモデルを構築した方達が決めたことであって”ねばならない”わけではありません。

成熟度がLevel1であっても問題なく成果を上げている組織もありますし、組織全体ではなく個別のチームや部署だけで定量的な管理を実践したり革新的な運営を実現してもよいわけです。

よってこの縦軸（このモデル）に沿わなければならない、とかLevel1よりLevel3が偉い！すごい！、などと画一的に考える必要はありません。

重要なことは「われわれはどうしたいのか？どうなりたいのか？」です。

公的な認証やある組織が決めた基準の下での判断を仰ぐ場合は、それぞれのルールに従うのは当然ですが、自分達がその道具を理解して独自に使いこなすことも可能です。

自分達の目的を達成するためにこのモデルが使えるなら使えばよい。使えない、効果が期待できないなら使わなければよい。

すべてを活用することが達成に役立たないなら一部の役立つところだけを使ってもよいわけです。

これはCMMI、TMMi、QMS、TPI Next、ISO29119-2(33063)などどれを取っても同じコトですのでよく覚えておいてください。

自分達で考えることを放棄し、外部基準や偉い人や組織が言うことにのみ依存するようなことにならないようにしたいものです。

1990年前後にQS（現在のQMS）やSoftwareCMMから始まったプロセスモデルのアプローチですが、現時点でさまざまなプロセスモデルが提案され、充実してきたにもかかわらず、モデルに弄ばれている組織やそれを隠してごまかしている組織が多いのがとても気になります。

さらにその正反対の状況＝「そんな高尚なことやってるヒマはない／形式だよね！」といって中身を見もせずに手も足も出さない組織やチームが多いことも事実であり、モデルの本当の意味や実践方法を理解できていないにすぎない状況もとても残念なことです。（思考を停止し、画一的な捉え方しかできない人たちが多いということですよね）

これまでのIT産業の経験則が詰まったプロセスモデルが充実してきた今、自分達の成し遂げたいことをはっきりさせ、その実現に役立つ手段を自分達で選択し、使いこなしながら進めることができるかどうかが今後ますます問われると思います。

なお、この記事は「プロセスモデル」を擁護したり、一方的によいものである、だから使うべき！ということを伝えるものではありません。ゴルフのクラブのように、道具ごとの特性を理解し、自分が使いこなせる道具の選択肢をいろいろ揃えておく、そして状況に応じて選択できるようにしておくことの大切さを伝えようとしています。

文章が下手なのでわかりにくいと思いますが、念のため。

（その３につづく）