TMMi(Test Maturity Model Integration)その3

■プロセスエリア（Process Area：PA）

プロセスエリアは以下のようになっていて、大枠で「Level番号の下から順に改善していくといいよ」というメッセージになっています。

 

このようにTMMiは多くの組織で使える大枠の方向性を示すものとして汎用的に構築されたものですので、どんな組織でも必ずぴったりくるものではなく、単にポイントになるコトを集約したものである（モデル、とは特徴的なところを反映し、それ以外の枝葉を省略したものです）ことに注意してください。

 

その割にどうしてあんなに情報量が多いのか？というと、アセスメントで適切に判断できるように詳細な情報（プロセスｰプラクティス-アクティビティ・・・事例などを含む）を載せているからなのだと思います。

■取り上げられているプロセス(1)－管理面のプロセスが多い

TMMiで取り上げられているプロセスをざっと分類してみましょう。

 

かなり荒っぽい分類方法ではありますが、管理面のプロセスがたくさん並んでいることがわかると思います。

現在はスピードが求められる時代、ソフトウェアの規模も大きくなり、さまざまなものと連携する場面が増えている現状からも、テスト必要なリソース･期間の提供、スキルの獲得、計画的な運営、状況把握による問題早期発見・解決、適切な判断などの的確な管理が求められることに疑問はないと思います。

一方で「利益も必要なのだからそんなにできないよ」という意見があるのも事実です。

ここで注意したいのは、沢山管理をするのだからその分だけ比例して工数も期間もかかると考える「線形思考」に陥っていないか？ということです。

本質的にLevel 4～5の組織は「難しいコト、すごいコトをさりげなくやってしまう」組織です。

そう、沢山のすごいコトを短い時間･期間、少ない手間でやってしまうほどの腕っこき組織なので、上図に記載されているような沢山のプロセスを（ツールの活用や自動化などを上手に活用することで）無駄なく、効率的に実施できるのです。

Level 1～2ではその実現は難しく、具体的にイメージが湧かないために「そんなに沢山は無理」と考えてしまう。

致し方ない面もありますが、線形思考の罠に陥らないように注意したいものです。

■取り上げられているプロセス(2)－テストから開発全体へ

TMMiはテストプロセスモデルなので、Level 2～3のほとんどは「テスト」のことを取り上げています。

しかし、Level 3の一部から4～5になるにつれて、開発プロセスとテストの連携や開発全体の最適化・効率化に向けたプロセスに移行していることを理解してください。

つまり、Level 2～3にかけては「テストが適切に、確実に実施できるようになること」が中心。

以降は「テストの技術を開発全体に活用して開発効率を上げること」にシフトします。

テストの適切な実施を継続しつつ、開発過程でレビューを活用し、テストの視点で要求や仕様、実装における欠陥を早めに検出・処置したり、過去の実績や開発過程で検出した欠陥情報から欠陥の作り込みを低減する（欠陥予防）など全体最適を目指すプロセス群で構成されています。

■TMMiのまとめ

以上のようにTMMiを見てきましたが、

・大枠ではあるがテストプロセス改善の方向性が明確である

・今回取り上げる他のモデル（TPI Nextや33063）に比べてLevel毎に取り上げられたプロセスが詳細な情報である

・組織成熟度を高めることを目的とした段階モデルであるため、個別プロセスの改善段階を詳細に把握できない場合がある

というのが特徴になると思います。