テストど素人、WACATEに参加した（4）：「GQM法で報告書改善」
以前からの宣言どおり、8月1日開催のTOEIC SWテスト受験に申し込みました。直前に1つ記事を書きたいところですが、このレポート連載が終わるかどうか……。
というわけで、このWACATEレポートも今回で4回目。一部の方に「打ち消し線が1カ所もない！」と驚かれた前回は、報告書を書く理由について書きました。今回は、それを踏まえた上でスタートした報告書改善のグループワークについて書いていきます。
■テストにおける報告 ワークショップ
グループワークは今回のメインイベントです。実行委員の村上くにおさん司会のもと、グループワークの説明からはじまりました。
今回のグループワークのコンセプトは「テスト報告書の改善」。また、今回のWACATEのテーマが「見たい！見せたい！伝えたい！」ということで、
- 何を見たいのか
- 見せたいポイントは何か
- 何を伝えたいのか
以上の観点をもって、グループワークを進めましょうという話になりました。
また、このグループワークのゴールとして、「報告書のポイントの理解」「GQM法、メトリクスの活用についてイメージを持つ」「テスト報告書の貢献・効果について理解する」という点が挙げられました。
■設定
今回の参加者は、全員「WACATE Corporation」の社員として勤務しているという設定です。テストチームに所属しており、社内のプロジェクト進捗報告書のフォーマットに従って、毎週進捗報告を記録しています。うろ覚えですが、このような感じの報告書だった、というものを下記に示します。
細かい点については気にしないでください（笑）。
ところで、ある日、本部長という方がその進捗報告を見て、
「なんじゃこりゃー！」
と、叫んだそうです。「死にたかねぇよ」とまでは言ってませんが。 とにかく、その報告書を見ても、よくわからない様子。実際、本部長からは、
- テストの進捗が知りたい
- バグの状態が知りたい
- その他、何かトピックスがあれば知りたい
というリクエストが挙がりました。そこで、1日かけてグループワークで報告書の改善を行い、2日目の午後に本部長へ改善提案をしよう、という設定です。
■報告書の改善にGQM法を使用する
「報告書の改善に『GQM法』を使おう」というコンセプトになっていました。GQM法は何か、について簡単な説明がありました（具体的な説明は2009年冬のWACATEで行ったそうです）。
GQM法のGQMとは、"Goal-Question-Metrics"（ゴール・クエスチョン・メトリクス）の略で、とある目的（Goal）を立て、そのゴールを達成するために知るべき疑問点（Question）を洗い出し、そのクエスチョンに対するデータ（Metrics）を測定しよう、というものです。
例えば、「彼女がいないけど結婚したい！」と思ったときのことを考えてみましょう（例えばの話です）。このときゴールを指定する際に重要なファクターは主に4つ。
- ステークホルダー：「○○の観点で（○○が）」
- フォーカス：「○○における」
- 目的：「○○のために」
- 対象：「○○を××する」
これに沿ってゴールを設定すると、「僕が人生における結婚のために奥さんになる人を見つける」になります（あくまで、例えばの話です）。
次に、このゴールを達成するために何を知るべきか（Question）を考えますと、「結婚に必要な貯金はいくらくらいか」「いつまでに結婚するか」「どのような女性が理想のタイプか」といったものがあるかと思います。
そして、このクエスチョンを解決するために、必要なデータ（Metrics）は何かを考えます。「一般的な結婚資金額」「現在の自分の貯金額」「現在の自分の年収」「現在の年月日」「現在の自分の年齢」「相手の年齢（理想）」「相手の性格」などが挙げられると思います。基本的にメトリクスは測定できるデータ（定量的なデータ）となりますが、定性的なデータ（先に挙げた例でいうと、相手の性格）があっても良いようです。
また、1つのプロジェクトにゴールは複数ある（ステークホルダーが違えば目的も変わるように）場合もあれば、ゴールとクエスチョンの関係、およびクエスチョンとメトリクスの関係が多対多であってもよいようです（先に挙げた例でいうと、自分の年齢は、婚期と理想の結婚相手の両方に関わってくるメトリクスだと思いますから）。
簡単な概略図を下記に示します。
■グループワーク開始！
さて、グループワークの流れですが、まずは各人のスキルといったチーム状況の把握、次に報告書の現状把握、その後、ゴールとクエスチョンを決め、メトリクスを決め、改善提案の発表に向けて準備をし、発表本番。以上の流れになりました。
途中ではさむ昼休みでは、「チーム名も決めてくださいね」との指示が。ここで、僕の入った班は、なぜか「マヨネーズ（アクセントはマで尻下がり）」になりました。理由は、あるチームメンバーの方に由来するものです（詳細はナイショ）。議論が横道に反れたら「かけすぎー！」と叫ぼうっていう取り決めもできました（笑）。ノリがよかったです、僕の班。ノリがいいうえに、テストエンジニアとしてもすごい常連の方々が集まっていました。僕がこのコラムで「テストど素人で不安だ不安だ」と書いていたのを読んだ実行委員の方が気を遣ってくれて、特にすごいメンバーとくっつけてくれたのかなと邪推したほどで（笑）。
何せ、途中までグループワークの進ちょく度がトップでしたから。ゴールの設定まではすんなりと進みました。前回書いた「報告書では相手と目的のことを考える」という話を全員が踏まえていたので、最初から「本部長が見て分かりやすい報告書にしよう」という方針が掲げられました。それに沿って「本部長が報告書を読んで『テストの進捗』『バグの状況』『その他のトピックス』が分かるように報告書を修正する」というゴールを設定し、各情報がわかるためにはこういうものを考える必要が……というようにクエスチョンも次々に決まっていきました。
■メトリクスの呪縛
途中まで順調であったものが、「ではメトリクスは何を取得するか」という話に入ったときからチームが停滞ムード。気がつけば進ちょくが1時間遅れていました……。テストの勉強不足であった僕は、メトリクスの項目を見てもイマイチわからない部分も多かったので、記録に徹することで逃避していた時間帯もありました（苦笑）。ただ、ふと、ここまでの内容を振り返ったときに、「クエスチョンとして設定されたものが実はメトリクスなのではないか」と思いました。「本部長が見て分かりやすい報告書」をテーマにしていたことを考えると、本部長の立場としては僕のように細かい話は理解していなくてもいいのではないか、と。本部長にとっては「進ちょくはオンスケなのか遅れているのか」「重大なバグがあるのかないのか」ということさえ知れればいいのではないか、と、ふと思いまして。
その旨をチームに伝えました。「ここまで知る必要はないと思う。これはメトリクスになるのではないか」と。そこから、他の方が僕に対し、先輩が新人に教えるかのごとく「本部長が進ちょくの遅れを知ったら、どういう行動を取るか」というような一問一答の問答が繰り広げられて、新人の僕は更にチームの足を引っ張ることになりました（苦笑）が、何とか僕でも理解できる程度のGQMの設定にブラッシュアップできました。2日目に解説が入りましたが、メトリクスに囚われすぎることの弊害の1つが、こういうことなのかなと思いました（メトリクスの呪縛については、また追々）。
☆★☆
そんなこんなで、1日目のグループワークは終了し、同じ部屋に泊まる方と挨拶を交わしつつ部屋へ行き、ホテルの温泉に浸かり、その後、夜にはディナーセッションという名の宴会が始まりました。
今回はここまでです。次回はディナーセッションからの話を書く予定です。
☆★☆
次回予告：「消えた第3バイオリン」
……タイトルは気にしないでください（笑）。