[テストマネジメント虎の巻] 第十回：テストのモニタリングをする理由

HPソフトウェアの何かのサイトで2012年に公開された（っぽい）のであるが、どこでどんなふうに公開されたかが記憶に無いです。もしかしたら未公開かもしれないです。これがその頃の連載の最後です。公開する場がなくなってしまったのが原因でこの回で頓挫しちゃいました。

ーーーー

皆さんこんにちは。今までの連載では、テストの計画と見積りの話をしてきました。今回からはモニタリングとコントロールの話に入ります。モニタリングは、どのようなデータを計測するべきか？とか、そのデータをどう加工して分析すべきか？といったことが話題になりますが、まずは、なぜモニタリングしなければならないのか？といったところからはじめたいと思います。

テストマネジメントの全体像からみたモニタリングの位置づけ

本連載「テストマネジメント虎の巻」の第二回で、「テストマネジメントの全体像」を示しました。詳しくは第二回目の連載を見ていただきたいのですが、モニタリングとは一言で言うと、「計画通りに実現しているか（データを分析して）把握すること」です。また、計画とは「目的を達成するにはどうすればよいかを活動開始前に十分に検討すること」です。検討した結果が計画書としてアウトプットされるので、そのアウトプット（計測対象と判定方法）を基準にしてモニタリングを行います。モニタリングした結果、計画と違う状況になっていることが見えてきて、そのままでは目的達成が困難になる場合、目的達成できるよう措置をする、つまりコントロールをします。

モニタリングをしないとどうなるでしょうか？自分たちの作業の成果が目的達成に向かっているかどうかが最後までわからなくなってしまうでしょう。真っ暗闇の中を走って目的地まで到達しなければならない状況と一緒です。

モニタリングしやすいよう計画を作る

前述した内容から、計画とモニタリングは対の関係であることが分かると思います。対の関係であれば、計画があればモニタリングはできるので、わざわざ文面を割いて取り上げる話題ではないのではないか？」言う人もいるでしょう。しかし、実際にソフトウェア開発の現場に入った方なら察しが付くと思いますが、現実的には、モニタリングをやらないので状況把握が正しく出来なかったり、データ収集や分析に工数が多くかかりすぎてしまったりといった問題が起きます。ソフトウェアは利用される実態が目に見えない（ソースコードを見ても、ビジネスでソフトウェアが使われるシーンと直結しないと言う意味です）ため、このような問題が起きます。以下に二つの問題についてもう少し詳しく書いていきます。

状況把握が正しく出来ない

状況把握が正しく出来なくなる原因には、二つのパターンがあります。ひとつは、計画が具体的に本当に行うことになるタスクに分解できていなかったり、終了基準（品質を判断するためのデータと分析方法）や中断基準（進捗を判断するためのデータと分析方法）を明示していないために、モニタリングのために具体的にどのようなデータを収集すればよいかがわからない場合です。具体的にはわからないため、現場で解釈し誤った分析方法で判断してしまうといった問題が起きることがあります。例えばテスト対象の品質を判断するのにテストケースの消化状況のデータだけで判断したり（本来は要件との紐付けとバグとテストの関係を見ないとわからない）、テストの進捗状況を判断したいのにバグの件数だけで判断してしまったりといった問題が該当します。そもそもデータ収集をしないといった問題が起こるケースもあります。

もうひとつが、組織の標準的なデータ収集項目と分析方法が決まっている場合です。その場合、データ収集や分析を行うことは問題なく出来るのですが、その結果から何を判断すればよいかがわからないといった問題が起きることがあります。例えば、欠陥数とソース行数の比率で欠陥密度を出すという指標が組織の標準として決まっているとします。ただ、なぜそれを取らないといけないのか、今回の自分たちのプロジェクトではその指標がどのようなことに役に立つのか？といったことへの理解、及び同意がないまま、「そう決まっているから計測しておこう」といった感覚で計測してしまうと、計測した結果から何も判断できなくなってしまいます。もしくは、儀式的になってしまい現場はそのデータを有益だと思わなくなります。欠陥密度の場合、例えば、ソース行数に対して、○件までバグを見つけないとテストを十分に行ったとは判断できない（テスト終了基準を満たさない）、といった基準があると、たとえそのプロジェクトがレビューにて多くのバグが取り除くことができたためにテストではバグが出なくなったとしても、基準に達する件数のバグが出ないという理由でテストを終わらせられません。最悪の場合、基準を満たすために測定結果をごまかすようなことが起きてしまう可能性も出てきます。

データ収集や分析に工数がかかりすぎる

モニタリングは、コーティングやテストといった本来の開発活動ではありません。そのため、モニタリングに本来の開発活動以上の労力をかけるのは、誰しも本末転倒だと思うでしょう。しかし、本末転倒だと思うあまり、何も準備もせずに「最後に軽くデータ収集しとけばよいよ。」と言われると大変なことになります。広大な樹海の中に無造作に投げ込まれた宝石を探し出すような作業になります。例えばバグが発生したときのやり取りは電話かメールで行うプロジェクトがあったとします。連絡も直接プログラムを書いた開発者に行う場合もあれば、プロジェクトマネージャへ連絡し、その後指示してもらうこともある、といったことがいろいろなところで発生してしまったら、1日何件のバグが報告されていて、対応状況がどうなのかをどうやって計測しますか？プロジェクトに関わるメンバーが2～3人であれば口頭確認や電話やメールのログを提出してもらい調査することも可能かもしれません。（それでも1日たつと当事者も記憶が曖昧になるので正しくわからなくなります。）プロジェクトに関わるメンバーが増えていくとどうでしょう。筆者の経験では4人以上になると調べるのに時間がかかりすぎて実質不可能になります。もっと大規模なプロジェクトであれば言うまでもないでしょう。

モニタリングが無駄な作業となる理由

上記でお伝えしたいことは、データ収集のような作業に工数をかけたくないあまりに何も考慮しないで開発/テストを進めていくと、データ収集を本当にやろうとしたときに、とてつもなく工数がかかってしまい、また、データ収集して分析した結果が現場にとって有益では無いものになってしまいます。輪をかけて厄介なのは、「データ収集にどれだけ工数がかかっているか」という工数データをも収集していないため、データ収集作業が工数超過の原因だと言うことをマネジメント層が誰も理解できなくなるという状況です。そうなると改善のメスも入らず、常に有益でないデータ収集を工数かけて行わなければなりません。社会人になり、開発やテストの仕事に携わっている期間、常にこういう状況が続く現場で仕事を続けているとモニタリングは無駄な作業だと考えることが多くなっても仕方がありません。

データ収集や分析が出来るようにするコツ

データ収集や分析は、その方法を明確に決めておき、開発プロセスの中でなるべく人の手を介在せずに収集できるような仕掛けを埋め込むことで効率化しないといけません。収集するデータはプロセスのインプットデータであるかアウトプットデータであるかといった分類を行い、収集するための作業手順を決めた上でその手順をできる限り本来の作業の一環とします。

また、仕事を行う人たちにとって有益であることを説明でき、合意することも忘れてはいけません。これには、Basiliが提唱したGQMアプローチが有効な方法のひとつです。ゴール(Goal)に対してそれを実現するための質問項目(Question)を複数用意して、その質問項目の計測尺度(Metric)を決めていく考え方です。これはトップダウン的なモニタリングアプローチです。

ボトムアップ的なアプローチとしてはHetzelが提唱した方法があります。それは測定にはそもそもインプット情報、アウトプット情報、結果の3つの分類があると定義し、プロジェクトで取得できる情報をその分類毎に列挙した後にその情報からどのような疑問に答えられるかを考えていく方法です。

今回は、モニタリングの必要性とモニタリングのためのデータ収集のコツについて説明しました。次回からはテストのモニタリングで一般的に必要とされるデータと使われる分析方法を取り上げて解説していきます。