第234号：アプレイザルのチームコンセンサスで指摘されがちな会話の例

CMMIアプレイザルに参加していると、モデルの理解不足やアプレイザの思い込みなどから、「その説明だと評価するためのエビデンスが足りていないのではないか」と指摘される場面に遭遇することがあります。

詳しくない方向けに簡単にCMMIアプレイザルの評価のやり方をご説明しますと、CMMIのアプレイザルでは、組織やプロジェクトがプラクティスの意図と価値を満たす活動をしているかをArtifact(ドキュメント等)やAffirmation(インタビュー結果等)といったエビデンスをもとに評価します。

複数のチームメンバが参加してアプレイザルを実施する場合、典型的には、各チームメンバに評価担当のプラクティス領域(PA)が割り当てられ、メンバは評価期間中の限られた時間内で、ドキュメントレビューやインタビューを実施し、プラクティスが満たされているのか評価して、強みまたは弱みの所見や、FMやLMといった評価の特性値を作成していきます。
※FM=Fully Meet LM=Largely Meet

アプレイザル終盤のチームコンセンサス(フルチームレビューとも言います)では、自分が担当したPAの評価結果をほかのメンバに説明し、結果をチーム全体で合意していきますが、この説明の最中に冒頭の指摘が他のメンバから出ることがよくあります。

指摘に対してうまく説明できない場合、もしくは実際にエビデンス不足が発覚した場合は、弱みとして評価を修正しなおすか、ほかに適切なエビデンスがないか探し始めることになります。チーム全体の作業効率も下がりますし、精神衛生上もよろしくないです。

本来は、不適切または不足しているエビデンスは、アプレイザル開始前までに収集しなおされているのが望ましいのですが、わりと土壇場で問題に気づくこともありがちです。読者の皆さんも身に覚えがあるのではないでしょうか。

以下、私が過去経験したアプレイザルのチームコンセンサスで指摘が出た際の会話の例とその解決案について、いくつかプラクティスをピックアップしてご紹介します。

※凡例：A ……チームメンバA(説明者)
　　　 B ……ほかのチームメンバ

■EST 2.2
　ソリューションの規模見積もりを作成し、最新に保つ。

A「各タスクの工数を根拠立てて見積もっている原価見積書のArtifactが存在し、インタビューでも同様の説明がありましたので、評価はFMと判断しました」
B「規模はどんな尺度で見積もっていましたか？」
A「え、規模？ 工数見積もりのエビデンスは確認できたのですが……」

工数見積のエビデンスはしっかり確認できているのに、プラクティスで求められている規模の見積もりの確認が漏れていることがあります。

規模見積もりは、工数や費用の見積もりの主要な入力であり、ソフト開発の場合の例としては、オブジェクトの数、構成要素の数、フィーチャーの数、ファンクションポイント、要件の数、コード行数などがモデルでは紹介されています。

規模見積もりとプラクティスに書いてあるのだから見逃すわけはないだろう、と思われるかもしれませんが、経験の浅いメンバなどは実はわりと見逃しがちです。
エビデンスの中の規模見積もりに相当する箇所をしっかりと確認しましょう。

■RDM 2.5
　要件と活動、または要件と作業成果物の間の双方向の追跡可能性を作成し、記録し、維持する。

A「要件定義書の文書の中で要件と機能のマトリクス表があり、双方向のトレーサビリティはとれていると思われたの
で、特に弱み無しと評価しました」
B「下流工程のテストケースとの紐づきは確認できてますか？」
A「え、上流工程のトレーサビリティの記録しか見てないですが……」

このプラクティスは、原要件とソリューションとの間の追跡可能性を維持することがことが求められており、そこには原要件と下位レベルの要件が追跡できることや、テスト計画とテストケースが要件を取り上げることなどが含まれます。

ウォーターフォール型のライフサイクルで開発を行っている場合、下流工程のテストと要件が紐づいていないと間違いが起こりやすくなるため、この会話のような指摘が出ることがあります。

■PQA 2.1
　品質の履歴データに基づき、品質保証のアプローチおよび計画を策定し、最新に保ち、それに従う。

A「プロセス品質保証の計画がしっかり立てられており、インタビューでもそのことが確認できたので、弱み無しのFMと評価しました」
B「品質履歴データはどう扱われてましたか？」
A「ひ、品質履歴データ……？」

「品質保証のアプローチおよび計画」に関するエビデンスは確認していますが、「品質の履歴データに基づき」の部分が考慮されてないケースです。それに該当する記録を確認するか、インタビューで確認しておきましょう。

この例のように、複数の要素が登場するプラクティスはエビデンスも複数必要になる場合がありますので注意が必要です。

以上です。
今回は紙面の都合上、3つのプラクティスだけ例示させていただきましたが、この手の話はほかにもたくさんあると思います。気になる方は、組織内の有識者や担当のコンサルタントに相談してみましょう。

たくさん指摘を受けて、もうアプレイザルはこりごりだと思ってしまった方も、あきらめずに次の機会に向けてチャレンジいただきたいと思います。

CMMIモデルをよく読んでプラクティスの理解を深め、参加時の教訓を次に活かし、たくさんアプレイザルに参加して経験を積んでいくことで、徐々にうまく立ち回れるようになると思います。がんばっていきましょう。