ソフトウェアテストプロセス評価モデル微考ｗ

次はISO/IEC 33063の解説、のはずでしたが、その代替案として2015.12末に開催されたコミックマーケットに頒布された「Software Testing ManiaX　Vol.10」への寄稿記事「ソフトウェアテストプロセス評価モデル微考ｗ」を掲載します。

内容的にはテストプロセスモデル3つ：TMMi、TPI NEXT、ISO/IEC 33063の比較結果を書いたものです。

寄稿記事なので、である調で記載していますのであらかじめご了承ください。

１．はじめに

2015年3月にふと思い立ってTMMi Foundationの翻訳をはじめた。とはいえ英語力もなく使える時間も週数回昼休み30分程度で歩みは超遅い。そんな矢先、9月にソフトウェアテストプロセスのアセスメントモデルISO/IEC 33063（ISO/IEC33020が縦軸、 ISO/IEC /IEEE 29119-2ソフトウェアテストプロセスが横軸）が制定され、翌月10月にはTPI NEXTの日本語書籍が発売された。ということで、2015年は日本におけるテストプロセスアセスメント・改善の元年ではないかと勝手に決めた。

せっかくなので今回これら3モデルの特徴をざっと整理し、これらをどう使うか？について考えてみたいと思う。

２．大枠の特徴

まずはそれぞれのモデルの大枠の特徴を示す。

比較項目	ISO/IEC 33063	TMMi	TPI NEXT
モデル種別	Continuousモデル（連続モデル）	Stagedモデル（段階モデル）	Continuousモデル（連続モデル）
全体的な特徴	プロセスが4階層グループに分類されている・ドキュメント重視型	CMMIフレームをそのまま採用・プロセスエリア単位の情報が充実	ビジネスゴールにつなげるプロセスの連鎖を明確化する“クラスタ”を持つ
横軸：プロセス	10プロセス+option3プロセス	15プロセス	16プロセス
縦軸：成熟度or能力	プロセス能力を示す6段階（Level 0～5）	組織の成熟度を示す5段階（Level 1～5）	プロセス能力を示す4段階（初期・コントロール・効率化・最適化）

ISO/IEC 33063とTPI NEXTはそれぞれ取り上げたプロセス毎の能力レベルを問うContinuous（連続）モデルであるのに対し、TMMiは組織の成熟度レベルを問うStaged（段階）モデルであることが大きな違いの一つである・・・なんて、いろいろな側面で比較するのもいいかなと思ったが、今回はそれぞれのモデルが「どんな風にプロセスを提示しているのか」に注目してみたい。

３．プロセスの特徴

独断と偏見でプロセスの分類を決め、それぞれのモデルが提示しているプロセスを割り付けてみた。ここでいうプロセスとは、モデルで「プロセスエリア」とか「〇〇プロセス」と称しているものを指す。なお、1プロセスがいくつかの分類に関連する場合もあるが、主にどの分類に関連するかを（直感的に、いや、思いつきで）一分類に割り付けた。

さらに、特にそれぞれのモデルが持つ特徴的なプロセス（他モデルにはないもの、あるいは表現がユニークなもの）については“●”を付与した。

以下、それぞれのモデルが持つ特徴的なプロセス（●）を取り上げた理由を記す。

＜ISO/IEC 33063＞

●問題解決管理：他モデルではインシデント・欠陥管理が存在する中、さらに広く捉えた問題解決管理を取り上げている。

●静的分析：レビューに加え、さらに静的分析を取り上げている。

＜TMMi＞

●高度なレビュー：ピアレビューで終わらずに、さらに高度なレビューを取り上げている。

●製品品質評価・品質制御・欠陥予防：開発プロセスとテストの連携（による開発全体の効果、効率を目指すこと）を強調している。

●非機能テスト：唯一、このモデルのみ非機能テストを単独で取り上げている。

＜TPI NEXT＞

●利害関係者のコミットメント：プロセスに実効性を持たせる重要な要因を単独で取り上げている。

●テスト担当者のプロ意識：内容はエンジニアのトレーニング、スキル管理だが、インパクトある表題で取り上げている。

●報告：コミュニケーションがあるにも関わらず、あえて報告を単独で提示している。

●手法の実践：手法･様式の明文化に基づく実践をインパクトある表現で提示している。

●テストウェア管理・テストツール：他のモデルでは目立たないテストウェア管理、テストツールをあえて前面に出している。

分類	ISO/IEC 33063	TMMi	TPI NEXT
組織的インフラ	・組織的テスト・スキル開発	・テスト方針／戦略・テスト組織・テストトレーニングプログラム	●利害関係者のコミットメント・テスト戦略・テスト組織 ●テスト担当者のプロ意識 ●手法の実践
開発との連携	・テストインシデントレポート ●問題解決管理・ソフトウェアレビュー ●静的分析	・テストライフサイクル＆統合・ピアレビュー ●高度なレビュー ●製品品質評価 ●製品制御 ●欠陥予防	●関与の度合い・コミュニケーション ●報告・欠陥管理
テストマネジメント	・テスト計画・テスト監視＆コントロール・テスト完了・計測	・テスト計画立案・テスト監視＆コントロール・テスト計測	・見積と計画・テストプロセス管理・メトリクス
テスト開発	・テスト設計＆実装・テスト実行	・テスト設計＆実行 ●非機能テスト	・テストケース設計
テスト支援	・テスト環境セットアップ＆保守	・テスト環境	●テストウェア管理・テスト環境 ●テストツール

４．活用方法

以上の特長を踏まえ、それぞれのモデルをどのように活用するのが良いのかをおさわり程度に整理してみる。

モデル

ISO/IEC 33063

TMMi

TPI NEXT

用途

ドキュメントレベルの確認をしっかり行いつつ、プロセスの状況を大枠で把握したい場合

・すでにCMMIを活用している組織がテスト領域も同様に把握したい場合

・テストプロセスの詳細状況を把握したい場合

成果を高める効果的なポイントを強調したい場合

用途の根拠

組織、マネジメント、動的・静的テストの3領域でわかりやすく把握できる／ドキュメントの詳細が提供されている

CMMIと同じフレームと評価方法でモデルが作られており、詳細に情報が提供されている

インパクトのあるプロセス名で結果を示すことができる（誰が何をすべきかが伝わりやすい）

整理した結果をみて、、、いまいちな内容だと実感した。（苦笑）

５．そんでもって

　モデルの特長を把握して使いこなすことも重要だが、そんなこといちいち考えるもの面倒だし、できるだけ手間をかけずにそれぞれの良いところを全部のせしたい、というものぐさな方もいると想定している。

ということで、3モデルを解析して統合し、一度アセスメントすると3モデルそれぞれに対する結果を出力できるしくみを構築した。まだ素案であるため、近日中に手を挙げてくれた組織でトライアルアセスメントを実施する予定だ。

また、フルアセスメントによる改善アプローチは、費用、工数が膨大にかかり、その効果も詳細すぎて大事なポイントが玉虫色にもなりやすい。そこでソフトウェアプロセス改善手法SaPIDを拡張して、フルアセスメントに頼らずとも、モデルを生かして有効な改善対象を特定できる手法と、アセスメント結果とビジネスゴールとの関係性を図式化して関係者で共有し、納得しながら進めることができるも手法も合わせて開発した。これらもトライアルを回しながら精度を上げていこうと思う。

業界ではSLCP、QMS、CMMI、Automotive SPICE、ITSMS、ISMS、今回ご紹介したテストプロセスモデル群のような「プロセスモデル」「プロセス要求事項」であふれているにもかかわらず、使いこなせずに思考停止している組織やチーム、管理者・エンジニアが未だに多いのは嘆かわしい。プロセスモデルに弄ばれず、使えるところを思い切り活用して（使えないところは捨てて）成果を上げていくようにしたいものだ。

ところで・・・TMMi Foundationの翻訳っていつ終わるんだろうか。→自分（爆）