「WACATE 2011 夏」参加レポート（その1）――三浦半島でインシデントレポートを改善しよう

コミュニティ活動

» 2011/07/14

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

　6月下旬にソフトウェアテストワークショップ「WACATE 2011 夏」に行ってきました。WACATEに参加するのは今回が4度目です。今回も、多くの学びや気づきがありました。さっそく、当日の様子をレポートしながら、振り返りを行いたいと思います。

■日時と場所

日時：2011年6月25日～26日
場所：マホロバ・マインズ三浦（神奈川）

　前回の「WACATE 2010 冬」のときもそうでしたが、今回も前日に会社の懇親会に参加してから、そのまま夜行バスに乗って会場に向かいました。どういうわけか、予定が重なるんですよね。

■今回のテーマ

　今回のテーマは「誰がためにレポートはある」。テストエンジニアなら誰でもインシデントレポート（バグレポート、障害票など、会社によって呼び方はいろいろあるようです）を作成したことがあると思います。また、開発者であれば、プロジェクトにおいて必ず目にするものではないでしょうか（あまりお目にかかりたくない、という方が多いと思いますが）。

　今回は、ワークショップを通して、インシデントレポートのカイゼンについてしっかりと考えてきました。

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

　1日目の最初はポジションペーパーセッションです。このセッションでは、参加者が事前に作成した「ポジションペーパー（立場表明書）」と呼ばれるレポートをもとに、グループで自己紹介を行います。

　まずこのセッションの進行役である、WACATE実行委員の上田 卓由（もとゆき）さんから、セッションの説明がありました。前回まで参加者であった上田さん、過去のWACATEの写真を見せながら自己紹介を始めました。その中に、「WACATE 2010 夏」のディナーセッションの演奏の写真がありました（実は上田さんもこのとき一緒に演奏していたのです）。しかも上田さんと一緒に、わたしまで写っている写真です。

　わたしは気づかないふりをしていましたが、そうは問屋が卸しません。上田さんは「この写真の、バイオリンを弾いている人が今日ここに来ています！」と言いました。言われてしまったらもう仕方ありません。わたしは自分から手を挙げました。

　セッションが始まる前に、思いがけずアピールをしてしまいましたが、おかげでアウェー感はなくなりました。その後の自己紹介タイムでは、それほど緊張せずに臨むことができました。

■BPPセッション「“自分”を研究する～自己のスキル・動機を見つめなおす」

　前回の「WACATE 2010 冬」でベストポジションペーパー賞を受賞された水野 昇幸さんのセッションです。

　前回、初参加にしていきなりベストポジションペーパー賞を受賞した水野さん、今回のポジションペーパーでは自分のスキルをゲームのパラメータのように表現していました。

　このセッションでは、「自分を研究して、意欲的に自分のスキルを伸ばす」ことについて語ってくださいました。

　一口に「スキル」といっても、技術的なスキルもあれば、ビジネススキルもあります。それらのスキルを分類するためのスキル標準や分類方法も世の中にはたくさんあります。また、趣味や社外コミュニティといった、仕事以外の場で発揮されるスキルもあります。

　そのため今の自分のスキルがどのくらいなのか、また、これからどのようなスキルを習得していけばいいのか、具体的にわかりづらい、「見える化」しづらいと思われている方も多いのではないでしょうか。

　水野さんも同じように思っていました。そこで、まずスキルを習得する「目的」を最初に考えて、そこから自分の「興味」や「現状」に従って分類するという、自分だけのスキル標準を考えてみたそうです。今回のポジションペーパーで表現した自分のスキルは、その自分だけのスキル標準に基づいた「マイスキルシート」なのだと説明してくださいました。

　こうして目的を見えるようにしたことで、現在の自分のスキルと興味の全体像が見えるようになったそうです。全体が見えるようになれば、学びの優先度を決めることもできるし、必要に応じて見直しもしやすくなる、と水野さんは語りました。

　しかし、同じ会社の先輩に、その場の思いつき（先輩談）で新しいイベントをポンと立ち上げてしまう方がいるのを目の当たりにして、水野さんは「目的ベースのスキル分類」だけで量ることができない能力があることに気がつきます。

　そこで次に水野さんが考えたのが「動機」でした。先輩のような能力は「これをやりたい」という動機が関係していると思ったからでした。

　水野さんは、動機には「強い動機」と「弱い動機」の2種類があると説明しました。強い動機は自分で意識できるのでそのまま行動力につながりますが、弱い動機は意識の向こうにすぐ隠れてしまいます。それでいて、自分自身を無意識のうちに動かしてしまうので、なかなかやっかいな存在です。

　そこで水野さんは、強い動機を伸ばすと同時に、弱い動機を受け止め、意識して改善につなげることが大事とおっしゃいました。弱い動機を意識できるようにするために、水野さんは自分の考えをメモに残し、振り返るようにしているそうです。

　ここで水野さんは、動機が人を動かす例として、ご自身のお母様のエピソードを紹介してくださいました。水野さんのお母様は、水野さんが高校生のころにトリマーになるために専門学校に通い始めたそうです。親子ほど年の離れた同級生に混じって一生懸命勉強したお母様は、卒業後に自分のお店を開きました。それだけでもすごいことですが、なんとそのお店を市内で一番の人気店にしてしまったそうです。動機があればスキルを伸ばすのに年齢は関係ないということです。

　最後に水野さんは、前回WACATEに参加することで多くの気づきを得ることができたこと、そのときの「感謝」の気持ちが動機となって今回のセッションにつながったことを伝えたい、と言ってセッションを締めくくりました。

　目的や動機といった、自分の内側から沸き起こるものでスキルを分類し、伸ばしていくという水野さんのお話は、とても興味深いものでした。わたし自身も、どのようなスキルを伸ばしていくか、まだまだ迷うことはたくさんあります。しかし、水野さんのセッションを聞いて、目的や動機について考えてみることで、何かヒントが得られるかもしれないと思いました。また、お母様のエピソードにも、とても勇気付けられました。

■ワークショップ「インシデントレポート改善ワークショップ」

　WACATE実行委員の坂（ばん） 静香さん、井芹 洋輝さん、加瀬 正樹さんが進行役を務めるワークショップです。

　最初に坂さんから、JSTQB ソフトウェアテスト標準用語集（日本語版 Version.2.0.J01）におけるインシデントレポートの定義と、インシデントレポートの標準的なライフサイクルについての説明、そしてワークショップの前提について説明がありました。

• 参加者は、「WACATE Corporation」という会社のテストチームのメンバー
• ある日、社内システム部が宴会の抽選会のために作ったツール「WACATE抽選クン」のインシデントレポートのクローズに時間がかかるので調査を依頼された
• 本部長から特に処理が滞っているインシデントレポートについて、フォーマットと記述について改善案を出すようリクエストされた

　というわけで、翌日の午後一までに本部長に改善案を提案するのがワークショップのお題となりました。

　まずはチームビルディングです。最初に、リーダーとサブリーダー、記録係を決めます。「WACATE 2010 夏」のワークショップで、わたしはリーダーに任命されましたが、今回は役職なしのメンバーとなりました。

　メンバーの役割が決まったところで、わたしのグループでは最初に各メンバーのキャリアの棚卸しから始めました。グループは6名。そのうち開発者が2名、テスト担当者が2名、マネジメント担当者が2名でした。なかなかバランスが取れています。

　チームビルディングが終わったところで、参加者全員に「WACATE抽選クン」の仕様書と、特に処理が滞っているインシデントレポート3通のコピーが配られました。

　インシデントレポートにざっと目を通しましたが、まあひどいこと（苦笑）。手順が整理されていない、入力データの条件が記載されていないなんていうのはまだかわいいもので、「メールじゃないんだぞ」と突っ込みたくなるような記述があったり、テストエンジニアが主観を書いてしまっているもの（しかも読んでいてイラッとくる文面で）があったりして、なんともいえない気分になってしまいました。別に駆け出しテストエンジニアだった頃の自分がこういうインシデントレポートを書いていたから、とか、そういうわけではありません。ええ、違いますとも。どうか、そういうことにしておいてください。

　また、実機での動作確認も必要ということで、各グループに「WACATE抽選クン」をインストールしたPCを用意してもらえることになりました。ところが、「WACATE抽選クン」が開発中ということもあって、各グループに与えられた動作確認の時間はわずか10分間でした。たった10分で何ができるというのか……と思ったものの、現場では思い通りに動作確認できないこともあります。この10分をどう使うかは重要なポイントです。

　ここで読者の方の中には「え？ わざわざバグを埋め込んだプログラムを用意したの？」と驚かれる方もいらっしゃるかもしれませんが、その通りです。進行役の加瀬さんと井芹さんが、わざとバグを埋め込んだプログラムを作成したのです。井芹さんは「バグを“正確に”埋め込むのは辛かった」とおっしゃっていました。

　最初にわたしたちのグループは、インシデントレポートを見て、まずは具体的にどこが悪いのか、何が問題なのかを洗い出しました。そして、それらをインシデントレポートのフォーマットに関する問題と、文面など、書き手のリテラシーに関する問題に分類しました。

　それから、各グループが実機を使う順番を決めた後で、わたしたちのグループの順番が来る前に、実機で確認したいポイントを洗い出しました。

　実機の順番が回ってくる間に、「良いインシデントレポートの要素」についてメンバー全員でアイデアを出し合いました。メンバーそれぞれの意見を聞いていると、各自の経験や普段の仕事ぶりが見えて面白いと思いました。

　そしていよいよ、わたしたちのグループの順番が回ってきました。あらかじめ再現させたいバグを選んで、動作を繰り返したのですが……結局、時間内にバグを再現させることができませんでした。ああ、なんということでしょう（泣）。今から思えば、動作確認をしながら入力データの内容を決めていたのが最大の敗因だったのかもしれません。事前にデータを用意しておけば、結果は違っていたかもしれません。

　まあしかし、再現できなかったものは仕方ありません。クヨクヨしても始まりません。わたしたちのグループは洗い出して分類したインシデントレポートの問題について、改善ポイントを整理しました。そして、改善ポイントを反映して修正したインシデントレポートのフォーマットを作成しました。そこで1日目のワークショップは終了しました。

　第1回のレポートはここまでです。次回は、1日目の夜の様子をお送りします。