「WACATE 2010 夏」参加レポート（その1）――三浦半島よりテストへの愛を込めて

コミュニティ活動

» 2010/06/21

　こんにちは、第3バイオリンです。

　6月12日～13日に、ソフトウェアテストのワークショップ「WACATE 2010 夏」に参加しました。前回の「WACATE 2009 冬」から半年ぶりに、三浦半島でテストや品質について熱く語り合ってきました。

　また今回は、コラムニストのあずKさんも一緒に参加しました。彼の参加レポートとあわせて読むと、それぞれの視点の違いが見えておもしろいと思います。

■前夜祭

　WACATE参加者には地方在住の方も大勢いて、中には前泊する方もいらっしゃいます。それなら前泊する参加者同士、前日のうちに交流を深めよう……というのが、前夜祭の趣旨です。

　前回のWACATEでは、わたしは前夜祭には参加できませんでしたが、今回は前夜祭から参加することにしました。

　前夜祭には、わたしも含めて10名ほどが参加しました。半年ぶりに再会する方、初めて会う方いろいろでしたが、お酒とテストへの愛のおかげで、すぐに打ち解けることができました。また、ときどき実行委員の方も準備の合間をぬって顔を出してくれました。

　とっても楽しい時間だったのですが……残念なことに、途中で寝てしまいました。たぶん朝に新潟を出て、昼間に東京見物をしていたものですから、疲れが出てしまったのでしょう。次回は、もっとゆっくり出発して、まっすぐ三浦半島に向かうことにします。

■今回のテーマ

　今回のテーマは「見たい！ 見せたい！！ 伝えたい！！！」簡単に言うと「見える化・報告」がテーマです。

　テストエンジニアは、開発チームや上司に対して、テストの結果や進捗状況を「報告」するのが仕事です。「報告」するには、現状を適切に「見える化」する必要があります。

　自分が伝えたいことを「見える化」して、「報告書の改善」を行う。これが、今回のワークショップのテーマでした。

　ちなみにWACATEは夏と冬、年2回の開催ですが、夏と冬では趣旨が異なります。冬は「広く浅く」いろいろなテーマを幅広く扱いますが、夏は「狭く深く」ひとつのテーマをしっかり掘り下げるスタイルになっています。

　そのため常連の参加者の方から「夏はワークショップがかなりハード」という噂を聞いていました。そして、実際そのとおりでした。

　そんなハードなワークショップを通して、わたしが何を見たのか、何を見せたのかをさっそく振り返りたいと思います。

■ポジションペーパーセッション

　まずはオープニングで今回のWACATE全体についての説明や諸注意があります。そのあとは、ポジションペーパーセッションです。ポジションペーパーを元に、グループのメンバーが順番に自己紹介をします。

　今回も、凝りに凝ったポジションペーパーが目白押しでした（凝りすぎてとんでもないことになっていた人もチラホラ）。それに比べると、わたしのポジションペーパーは前回とあまり代わり映えしなく、文字ばっかりで内容も硬いなあ、とちょっぴり反省してしまいました。

　セッションの合間に、ふと、あずKさんは何を書いたんだろう、と気になって見てみました。事前にコラムで「ネタに走ろう」と書いておられましたが……確かにそのとおりだったかも。しかし、正直言って「これはアリだな」とも思いました。

　あずKさんのポジションペーパーを読んで、わたしも次回からはもう少しネタの要素も取り入れたほうがいいのかな、と考えてみました。しかし、決して負けを認めたとか、そういうつもりではありません。

■報告書は○○○○○への××××

　WACATE実行委員の近江 久美子さんのセッションです。

　まず「そもそも、報告書って何でしょう？」という質問から始まりました。

　例えば、先輩から「現状を説明するための報告書を作成してほしい」と依頼されたとします。先輩は、その報告書の内容をいつ、誰に対して提示するつもりなのでしょうか。また、先輩が知りたがっている「現状」とは、進捗状況のことでしょうか、それとも、リソースの稼働状況のことでしょうか。

　報告書を出す相手と目的によって、報告書の内容は変わってきます。つまり、「見える化」のやり方を変える必要があるということです。また、相手の立場や都合に合わせて、見やすさと提出のタイミングにも工夫が必要です。

　というわけで、セッションのタイトルの答えは「報告書は特定の相手への見える化」でした。

■ワークショップ「テストにおける報告 ～見たい！ 見せたい！ 伝えたい！ ～」

　WACATE実行委員の村上くにおさんがモデレータを務めるワークショップです。今回のセッションの中で、もっとも長く、そしてもっともハードなセッションでした。

　まずは、ワークショップの前提について説明がありました。

• 参加者は、とある会社の社内システム部のテストチームで働くテストエンジニア
• 社内システムが大幅改修されることになり、この案件について本部長がスペシャルアドバイザーとなることが決まった
• しかし社内システム部の報告書を見た本部長は、その内容のあまりの適当っぷりに「なんじゃこりゃ！」と大激怒

　というわけで、翌日の午後一までに報告書の内容の改善案を検討し、本部長に提案するというのが今回のワークショップのお題です。

■わたしがチームリーダーですか！？

　前提についての説明の後はチームビルドです。

　今回のワークショップでは5～6人がチームを作って作業することになりました。まずは各チームで、チームリーダーとサブリーダーを決めました。チームリーダーの条件は「業務経験3年以上、できれば20代」でした。

　わたしのチームでこの条件を満たしているメンバーは、わたしだけでした。というわけで、チームリーダーはわたしに決まりました。

　しかし、ほかのメンバーは皆わたしよりも年上です。なかにはキャリア20年以上のベテランの方もいました。正直いって「このメンバーをまとめることができるのだろうか……」と少し不安になりました。

　しかし、サブリーダーに決まった方が「ワークショップのいいところは“失敗ができるところ”です。たとえ失敗しても、誰かが困ったりどこかに損害を与えたりするわけじゃないですから」とおっしゃったので、少し冷静になれました。他のメンバーも「役割に関係なく、気がついたことは全メンバーでフォローしあっていこう」と言ってくれました。

　わたしは、「リーダーだからって、何から何まで自分でやる必要はない。ここはひとつ、メンバーの知恵を借りるつもりでやってみよう」と心に決めました。

■結局のところ、本部長が知りたいことって何？

　お昼の休憩をはさんだ後で、いよいよ報告書の改善のために動き始めました。

　今回のワークショップは、前回のWACATEでも取り上げたGQM法を使って、報告書の目的と、目的を満たすための条件、さらに条件を満たすために必要な情報（メトリクス）を順番に検討する、という流れで進めていきました（GQM法の説明はこちら）。

　そのため、まずはGQM法のおさらいということで、前回のWACATEでGQM法のセッションを担当された、WACATE実行委員の原 佑貴子さんからGQM法の講義がありました。今回の場合、本部長が見たいのは「G」、われわれが伝えたいことは「QとM」です。このG、Q、Mをうまく報告書に盛り込むのがポイントです。

　チームで報告書の目的と、目的の達成方法（GQM法のGとQ）についてアイデアを出し合い、方針が決まったところでモデレータの村上さんが課長役になって、レビューを実施しました。

　わたしは、レビューで1発OKが出るとは思っていなかったので、レビュー実施予定時刻をかなり早めに設定しました。そして村上課長とレビューを実施したところ、さっそく厳しい指摘が飛んできました。

　「“報告書を直すこと”にこだわりすぎていますね。ここに列挙したことは、本当に“本部長が知りたいこと”でしょうか」

　早い話が「手段と目的がすり替わってしまっていた」わけです。また、GQM法はあくまでも手段でしかないのに、目の前の問題をGQM法に当てはめることだけに夢中になってしまったところもありました。

　最初のレビューの反省を踏まえて資料を修正し、再レビューを行ったところで村上課長からOKがもらえました。最初のレビューを早めにやっておいたおかげで、なんとか制限時間内に終わらせることができました。チームリーダーとして、時間の管理はうまくできたかな、と思います。

　レビュー後は、報告書の目的達成のために必要な情報（GQM法のM）を検討し、結果を取りまとめたところで1日目のワークショップは終了しました。本部長に発表するための資料作成と、発表は2日目のお楽しみです。

　「WACATE 2010 夏」前夜祭と、1日目のセッションの内容をお送りしました。次回は、ディナーセッションと、夜の分科会について書く予定です。ディナーセッションで、第3バイオリンがおもしろいことをしました！

　乞うご期待！