「WACATE 2011 夏」参加レポート（その3）――あの日見たバグの名前を僕達はまだ知らない

コミュニティ活動

» 2011/07/26

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

　「WACATE 2011 夏」参加レポート第3弾です。今回は、2日目のモーニングセッションと、ワークショップの成果発表の様子をお届けします。

■モーニングセッション「欠陥エンジニアリング技術：欠陥マスターDBの重要性」

　2日目の朝は日本IBMの細川 宣啓さんのセッションから始まりました。この日は小学4年生になる、細川さんの息子さんが一緒に来ていました。

　細川さんは最初に、「欠陥エンジニアリング」とは何かを簡単に説明し始めました。欠陥エンジニアリングとは細川さんの造語ですが、欠陥の情報を記録・管理・分析することで欠陥の除去や撲滅に役立てる、という研究です。欠陥の研究はまだまだ発展途上ですが、これから必ず必要になる研究だと細川さんは説明しました。

　細川さんは欠陥の話をするときに、よく医学にたとえた説明をします。医師は問診や検査をすることで病気の属性をとらえます。そして観察できた属性の塊や組み合わせを見つつ、病気を特定します。病気を特定したところではじめて治療を開始します。

　そのために医師は病気のことを知っていなくてはいけません。医学では病気の症状を事細かに記録し、標本や写真を残していきます（これがいわゆる病理学です）。それによって、病気のマスターを作っているそうです。

　これをテストに置き換えるとどうでしょうか。

　テストエンジニアは、テストをすることでバグを出していきます。バグもまた、属性の塊です。そのため、欠陥本体は名前しかないのではないか、というのが細川さんのご意見です。属性の塊や組み合わせを見ながらバグの原因を特定し、修正するところまでは同じです。

　ところで、今のテストエンジニアはバグのことをどれだけ知っているでしょうか。確かに、テストの最中にバグを発見したら、インシデントレポートを発行してバグを記録しています。しかし、記録した情報を次のプロジェクトで生かして、同じようなバグが発生することを防いでいる、という人がどれだけ存在しているでしょうか。バグを記録してそれでおしまい、結局次のプロジェクトでも同じようなバグが出てしまう、という人が大半なのではないでしょうか。

　今のテストエンジニアは、テスト技法のことはよく勉強して知っているけれど、バグそれ自体のことはあまり知らない人が多い、と細川さんはおっしゃいました。テスト技法というのは、医学でいうとメスでお腹を切る方法のようなものです。ということは、テスト技法を覚えて「とりあえず使ってみよう。何か出るかも」というのは医学に例えると……考えただけでゾッとしますね。

　細川さんは、テストエンジニアがバグのことを知るために欠陥情報を蓄積し、データベース化することで欠陥のマスターを作りたい、というアイデアを提唱しました。それを実現するためにいろいろな活動を始めているそうです。

　欠陥情報を蓄積し、データベース化して誰もが閲覧できるようにすることで、欠陥の混入から除去までのサイクルが短くなり、やがては予測や予防にもつながります。

　最後に細川さんは息子さんのほうを見ながら「この子が将来テストエンジニアになるかどうかはわかりません。しかし、この子が大人になる頃には、『勘でテストをする』という時代ではなくなっているといいと思います。名医とは、病気をよく知っているものです。皆さんには、欠陥のことをよく知っている未来の名医になってほしいです」とおっしゃってセッションを締めくくりました。

　今目の前にある欠陥の情報を未来にどうやって生かすか、深く考えることができたセッションでした。わたしも未来の名医になりたいと思いました。

■ワークショップの成果発表

　2日目のワークショップはいよいよ最後の仕上げと成果発表です。

　各グループで1日目に作成した成果物をもとにして、インシデントレポートの改善案をプレゼンするための発表資料を作成しました。それだけではなくグループワークでうまくいったこと、うまくいかなかったこと、ワークショップで得られた気付きやグループとして、また個人としての反省点を出し合い、発表資料に盛り込みました。

　わたしたちのグループでは、インシデントレポートのフォーマットや書き方について、どうやってプレゼンしようかと話し合っていました。そこに細川さんが通りかかって、わたしのグループの資料を見て言いました。

　「『どう書くか』について話し合っているみたいだけれど、インシデントレポートは書くことそれ自体が目的ではないよ」この言葉にグループ一同、固まってしまいました。

　細川さんは、さらに続けました。「インシデントレポートは、読む人に何かしてほしい、何かを訴えたいから書くものです。問題のあるレポートが、そもそもどうしてこうなったかを考えてみるといいかも」

　去年の夏のWACATEのワークショップでも、改善それ自体にこだわるあまり、本部長に報告する、何を伝えてどうしてほしいのか、という目的を忘れてしまっていましたが、また同じ失敗をしてしまいました。わたしたちのグループは再度話し合い、資料に手を入れました。

　そしていよいよ成果発表。

　1グループ5分で、改善案とワークショップで得られた気付きについて発表しました。わたしたちのグループでは改善案や気付きについては伝えたいことはすべて伝えられたと思います。あとは個人の反省を伝えればOK……と思ったところで時間切れになってしまいました。

　実は資料作成のとき、個人の反省を資料に盛り込むかどうかを話し合っているときに、わたしは「発表まで時間もないし、口頭で言えばいいんじゃない？」と提案し、それが採用されたのです。

　私は発表後、しまった、やっぱり資料に載せておいたほうがよかったのかも、とちょっと後悔しました。結局、ワークショップが終わったあとで発表する機会を設けてくださったのですが、余計なことを言ってしまったかもしれません。グループの皆さん、ごめんなさい。

　今回のワークショップでは、メンバーそれぞれの立場で観点が異なり、自分だけでは気がつくことができなかった意見を聞くことができたのが良かったと思いました。これだからグループワークは面白いのです！

　第3回のレポートはここまでです。次回は、クロージングセッションと後夜祭の様子、そして今回のWACATEで得た気付きについてお送りします。