はじめまして。WACATE 4年生の名野と申します。先日開催された「WACATE2011夏」で憧れのベストポジションペーパー賞を受賞し、このような貴重な機会を設けていただきました。今回は参加者の立場から「WACATE2011夏」（2011年6月25日～26日、於：マホロバ・マインズ）のレポートをさせていただきます。熱く濃厚なWACATEの2日間を読者の皆様に少しでも感じていただけたら幸いです。よろしくお願いいたします。
WACATEとは
Workshop for Accelerating CApable Testing Engineers（内に秘めた可能性を持つテストエンジニアたちを加速させるためのワークショップ）の略です。夏と冬の年に2回開催され、夏は「狭く深く」、冬は「広く浅く」を基本コンセプトとしています。2日間泊り込みの合宿形式のワークショップで、毎回ソフトウェアテストに関するテーマが設定され、そのときのテーマに沿ったセッションやグループワークを行います。参加者の半分以上は30歳前後の若手で、全国各地からテスト、開発、QA、マネージャなどさまざまな立場の方が参加し、参加者が主体となって熱い2日間を繰り広げます。
毎年恒例！「ポジペセッション」
WACATEのスタートはポジションペーパーセッション（通称：ポジペセッション）から始まります。グループになって1人3分間の自己紹介を行うセッションです。事前に提出したポジションペーパー（自己紹介や議論したいことをまとめた1枚のA4用紙）を使って自分の思いをぶつけます。このセッションでお話を聞くと、参加者それぞれが何かをつかもうとしてWACATEに来ているのがヒシヒシと伝わってきます。WACATE参加者は皆モチベーションが高く、内に熱いハートを秘めているのです。私も皆様に負けじと「インシデントレポート初心者で、本を読んでも実感がわかず、この2日間で解決の糸口を見つけたい！」という思いをぶつけました。
BPP賞受賞者が物申す！「自己のスキル・動機を見つめ直してみよう」
前回のWACATE2010冬でベストポジションペーパー賞を受賞された水野さんのセッションです。自分は「一体何がやりたいのか？」、「どういった方向に進みたいのか？」ということに気づき、突き進んでいくためにはどうしたら良いか？ということについて、お話いただきました。
ポイントは「自分のスキルを知る」ことと「自分の動機を把握する」ことの2つ。自分のスキルを知るためにはオリジナルのスキルマップを作成して、持っているスキルを把握し、自分の向かいたい方向（憧れの人）を定める。そして、ライフストーリー分析などいろいろな手法を使って、自分の中にある動機を知りましょうということでした。動機には強い動機（ものすごい成果につながる動機）と弱い動機（意識から去って消えゆく動機）があるそうで、いきなり強い動機は見つからないので、まずは弱い動機を見つけて、それを強い動機に育てていくことが重要ということもお話されていました。
今までの私を振り返ると、ただがむしゃらに突っ走っていた感があるので、ここで一旦立ち止まって、自分を見つめ直してみようと思ったセッションでした。また、私には「強い動機！」と胸を張って言えるものが無いのでついついサボりがち…。まずは弱い動機をみつけて強い動機を育てて行こうと思います。
待ってました！「インシデントレポート改善ワークショップ」
プロローグ
いよいよメインワークショップの始まりです。夏のワークでは毎回現実にありそうなシチュエーションが設定されます。今回のシチュエーション次の通り。
- 私達はエンプラ開発部のテストチーム
- お隣の社内システム部でバグ修正の進捗が悪い問題が発生中
- 原因はどうやら社内システム部のテストチームが作成したインシデントレポートにあるらしい
設定されたシチュエーション
そこでヤマサキ本部長から私達にインシデントレポート改善のミッションが与えられました。
ヤマサキ本部長からのリクエスト
ワークショップのインプットは「社内システム部が作成したインシデントレポート3枚」と「テスト対象物の仕様書10ページ」の2つ。これからのワークでこのインプットを分析し、改善を行っていきます。また、何とワークの中でテスト対象物のソフトを実際に触って、不具合の再現確認も行えることが判明！？ただし時間は10分間（短い･･･）。不具合が作りこまれたソフトまで用意されているとは、今回のワークはいつも以上にリアルです。
チームビルディング
ポジペセッションで自己紹介はしたものの、まだお互いをあまり知らない状態。これから一緒にワークを進めていくために、まずは個々がもっている経験や知識を把握します。その結果、私達のチームはテスト／開発、管理／担当がまんべんなくいるチームで、いろいろな視点から改善が行えそうだということがわかりました。
そのあとはお昼のカレーバイキング（思わず食べ過ぎました）を食べながらチーム名を決めます。千葉出身が多かったことと、開発とテストが一緒の殻に入って仲良くしていきたい！という願いを込めてチーム名は"ぴーなぁっつ"に決定！
お昼のカレーバイキングでチームの親睦を深める
現状のインシデントレポートの問題点は何なのか
昼食も終わりここからが本番。既存のインシデントレポート（3枚）を読み込んで、問題点を明確にしていきます。"ぴーなぁっつ"チームではKJ法を使って意見をまとめていきました。まずは個人ワーク。各自レポートを読みつつ、気づいた問題点を付箋紙に書いて行きます。続いてグループワーク。順番に気づいた問題点を発表しつつ、付箋紙をテーブルにペタペタ貼っていきます。しかし、ここで問題発生。既存のレポートの問題点が多すぎて、机の上が付箋紙で一杯になってしまいました。
問題点を貼り付けた大量の付箋紙
本当はこのあと似たような意見をグループ化して整理して行きたかったのですが、どう考えても時間が足りないため、止むを得ず各自で気になった問題点に印入れて、印が多いものを問題点としました。
続いて、問題点をさらに分析していきます。インシデントレポートに携わる3者（管理者、テスター、開発者）それぞれにとって何が問題になるかを考えていきました。これもKJ法で進めていきます。3者のシートを作って、そこに個々の意見を付箋紙で貼っていきました。
3者にとっての問題点
良いインシデントレポートとは
問題点の分析のあとは、あるべき姿（ゴール）を考えます。これから行う改善の結果、管理者・テスター・開発者全てがうれしくなければなりません。そこで「3者それぞれがインシデントレポートから何が得られるとうれしいか？」ということについてチームで考えていきました。"ぴーなぁっつ"チームでは次のゴールを定めました。
- 管理者がうれしい･･･サマリーを見るだけで問題点がわかる
- 開発者がうれしい･･･不具合が再現できる
- 評価者がうれしい･･･書きやすいレポートのフォーマット
ここからはチームを2つ（フォーマット改善案策定チーム、既存レポート解析チーム）に分けました。本当は全てのワークを全員で進めていきたかったのですが、スケジュールを見積もった結果、時間が足りないことが分かり、二手に分かれます。ただし、せっかくのワークショップです。各チームで作った成果物はチーム全員でレビューしようという事になりました。開発者出身の私は、テスター出身の方とペアになって、既存レポート解析チームを担当しました。
インシデントレポートの解析＆不具合の再現
既存レポート解析チームでは次の3つのワークを行いました。
- 3枚のインシデントレポートの分析とレポートが意味している不具合の解明
- 実機による不具合の再現
- フォーマット改善案策定チームが作成した新フォーマットに従って既存レポートを修正
まずは個人ワーク。最近お気に入りの3色ボールペン法を使って、3枚のインシデントレポート読み込みました。そのあとはペアになって情報を共有。テスト対象物の仕様や、レポートの内容について、お互いに解った事をレポートや仕様書に直接メモしていき、既存レポートが伝えようとしている不具合は何なのか、具体的な再現手順はどれなのか予測を立てました。
開発者出身の私はテスト対象物の仕様は理解できましたが、既存レポートが何を伝えようとしているかなかなか読み取れず苦労しました。しかし、そこはテスター出身の相方にフォローしていただき、どうやら2枚のレポートは同じ不具合について書かれているらしい、その内の1枚は情報量が多く、再現手順の手がかりになりそうだということが解りました（テスター視点の見事な解析に脱帽）。
不具合の予測が立ったところで、実機を使ってペアテスト。私が手順書に従ってテスト実行を行い、もう一人がテストの手順をチェックしつつ現象を監視・記録していきます。また、インシデントレポートへの添付を想定し、動画記録も行いました。結果、ほぼ予測どおり不具合を再現させることができ、ホッと一安心。おまけに、新たな不具合も発見したため、その内容に関するインシデントレポートも作成しよう！という話でまとまりました。
改善インシデントレポートの作成
まずはフォーマット改善案策定チームが考えた新フォーマットのレビューを実施。改善のポイントは次のような点で、チームで考えた3者がうれしくなるための良いインシデントレポートの要素がいろいろ盛り込まれていました。
- 見る人の各立場に対応するためにレポートを3つの領域に分割（上段：管理者用、中段：開発者用、下段：評価者用）
- 文章表現に注意（客観的事実のみを書く、テスターが裁かない）
- 1インシデントに対して1レポート
- 用語を統一
- 選択式の入力箇所のリストを作成
レビュー後は、新フォーマットに従って再現に成功した不具合のレポートをペアで作成。ところが、いざ書いてみるとこれがなかなか難しい。再現テストを担当した2人とも再現手順は分かっているのですが、特定の画面やボタンを何と呼べば良いのか？誤解が無いように手順を説明するにはどう表現すれば良いか？といったことにとても苦労しました。
スケジュールが押す中、何とかドラフト版が完成したので、メンバー全員でレビュー。するとメンバーから「再現手順が細かすぎるのでは？」という指摘を受けます。実はペアの2人とも合意して、誰にでも再現できるようにと再現手順をわざと細かく書いたのですが、逆の指摘を受けてしまいました。理由を聞くと「再現手順がごちゃごちゃしていると、開発者や管理者は見るだけでウンザリしてしまう」、「不具合に直接関係する手順がどれなのか分からない」とのこと。確かに･･･と全員で納得して改善。ポイントを絞って再現手順を数行でシンプルに表現し、それ以外の詳細情報は別の欄に記載するように変更しました。チーム全員でのレビューの効果を実感できたひとときでした。
ここで1日目のメインワークが終了。このあとは楽しい♪楽しい♪夜の部です。
チーム全員でレビュー
お楽しみ♪「夜の部」スタート
私はこの夜の部がある意味一番好きです。会社、職種、年齢、立場などがまったく違うたくさんの人々が集まって、美味しい食事とお酒と共にざっくばらんに語り合う……考えるだけでワクワクしませんか？ WACATEに参加するだけあって、参加された皆さんのテンションは非常に高く、今回も某アイドルグループの歌で大盛り上がりでした。
歌と踊りで盛り上がるディナーセッション
宴会の後は、大部屋で分科会。今回は下記4つのテーマに分かれてざっくばらんにディスカッションを行いました。
- テスト初心者さんいらっしゃい
- テストと数学
- バグ票ワーストプラクティス
- テスト対要求仕様を考える
私は「テスト対要求仕様を考える」に参加。「要求仕様を元にテスト設計を行うけど･･･ではどうやってこの関係を整理したり、検討したりするべきか？」といったことを中心に10～20人くらいでディスカッションを行いました。
分科会後半になってくると、お酒も回ってきてヒートアップ！本気モードで熱いバトルを続けるところ、タイトルから脱線して仕事の悩みや、別のテーマに花が咲くところなどさまざまです。
夜の分科会
夜23時、分科会もお開きとなり各自部屋に戻ります。が、しかし！まだまだ熱い夜は終わりません。話足りないメンバーで集まり、結局2時、3時まで語り明かしたのはナイショです。
胸が熱くなりました！「欠陥マスターデータベース」
2日目のスタートは、WACATEでお馴染み細川さんのセッションです。セッション前半は可愛いゲストと共に診察のデモンスレーション。お医者さんが診察を通して病気を特定する様子と、エンジニアがテストを行って不具合を見つける様子を対比させたときに、見えてくるテストの問題点をわかりやすく説明いただきました。
細川さんのご講演
後半は、欠陥マスターデータベースの必要性についてお話いただきました。医療の世界では病気を抽象化して蓄積しておく世界的な仕組みがあること、お医者さんはその情報を使って病気の予測や予防につなげていることを、私は始めて知りました。そして、細川さんたちがそういったデータベースをソフトウェアの世界で作り上げようと日々活動されていること、できあがれば不具合を除去する方法に大きな改革が起きるかもしれないことを知り、非常に胸が熱くなりました。
私も将来こういったデータベースを使いこなせるよう、日々の業務でバグをコツコツ記録したり、過去に起きた欠陥を調べたり、欠陥に対する知識を蓄えたソフトウェアの名医を目指そうと強く思いました。
さぁ！2日間の「まとめと発表」です
まずは1日目に行ったワークの振り返り。KPT法に習ってチームで「うまくいったこと」と「うまくいかなかったこと」を挙げていきます。ここまでくるとKJ法による意見の整理は慣れたもの。誰かが意見を発表して付箋紙を貼る際に、同じような意見があれば「私もそう思いまいした」と付箋紙をペタペタ。全員の発表が終わるころには意見のグループ化も完了していました。
整理した意見を見ると、インシデントレポートの改善については皆が満足していましたが、その進め方に関する課題が見えてきました。途中でチームを2つに分けることで、作業の効率化を図ることはできたものの、その分、全員でディスカッションする時間が減ってしまい残念！情報共有が不十分だった！と皆が感じていたのです。
そのため、続けて行った「今後どうする」についてのディスカッションでは「情報共有のための時間をスケジュールに入れる」、「途中でチームの入れ替えを行って情報共有を図る」といった意見に皆が頷き、全員でのディスカッションの時間を大切しようという話になりました。振り返りのあとは、改善インシデントレポートの最終調整と発表資料の作成。もちろん資料作成後は、全員で楽しくレビューを行いました。
そしていよいよ発表。2日間頑張った成果を各チームが発表していきます。私たちのチームはトップバッターでしたが、チームで最年少のリーダーが見事なアドリブで発表してくれました。最後にメンバーが感想を順に言っている最中にゴングが鳴って強制終了したのはご愛嬌です。講評で森崎さんにご指摘いただいた「部長への伝達でまず何が問題か（課題）を示して欲しい」という点については、大いに反省。聞き手の立場を考えた発表を行わなければいけないなという気づきを得ることができました。
そのあとは他チームの発表です。
- 改善レポートの変更点に色を付けて、差分を明確にして説明したチーム
- Excelのコメント機能を使って、バグ票の各入力欄にどういったことを入力すれば良いか、分かりやすく補足したチーム
- キャッチフレーズを発表の最初にドーンと示して、考え方を明確に主張したチーム
- 方言を使って聞き手を楽しませるプレゼンを行ったチーム
- プロセスフローの図を使って、各ワークで実施する内容と成果物を最初にメンバー間で明確にしてから作業を進めたチーム
などなど…、チームの色が良く出ていた発表でした。他チームの発表を聞くことで、自分たちのチームでは思い付かなかった気付きをたくさん得ることができ、とても勉強になりました。
チーム発表
著名な方々からのご講評
名残惜しいのですが最後です「コミュニケーションとしてのバグ報告」
ラストは森崎さんのクロージングセッション。笑いのネタを仕込みつつ、バグ報告に関するご自身の知識や経験、研究動向について楽しくご講演いただきました。大変興味深かったのは「コンウェイの法則」。組織のコミュニケーションの密度によって、開発されるモジュールの結合度や品質が左右される傾向にあり、その制度は良くあるメトリクス値よりも高い場合があるというものでした。
また、バグ票を書く際に気をつけるポイントについて、具体例を示しながらわかりやすくお話いただけたので、現場でさっそく使えそうなテクニックをたくさん得ることができました。バグ票の失敗例を収集するプロジェクトも進められているそうなので是非活用したいと思います。
森崎さんのご講演
私にとってのWACATE
6回目の参加となったWACATE。今回も2日間のワークを通して、インシデントレポートについて深く考え、たくさんの気づきを得ることができました。思い返せばテストのテの字も知らない状態でWACATEに参加してからあっという間の3年間でしたが、日に日に加速する自分を実感できる日々でした。加速するために必要なモチベーションや知識、環境、友人などが今の自分にあるのは、WACATEとWACATEをきっかけとして知り合えた皆様のおかげです。本当にありがとうございます。そして、これからもよろしくお願いいたします。今まではコンテンツを提供してもらう側の立場でしたが、これからは提供する側になれるよう、いろいろな発信を行っていきます（※）。
最後に、WACATEにまだ参加したことのない皆様へ。「仕事がうまくいかない」、「やりたい事が見つからない」、「モチベーションが上がらない」などなど、悩んでいる方がいらっしゃったら、ぜひWACATEに飛び込んでみてください。きっと自分の中で何かが変わると思いますよ。
