2011/07/26こんにちは、第3バイオリンです。夏」参加レポート第3弾です。今回は、2日目のモーニングセッションと、ワークショップの成果発表の様子をお届けします。宣啓さんのセッションから始まりました。この日は小学4年生になる、細川さんの息子さんが一緒に来ていました。細川さんは最初に、「欠陥エンジニアリング」とは何かを簡単に説明し始めました。欠陥エンジニアリングとは細川さんの造語ですが、欠陥の情報を記録・管理・分析することで欠陥の除去や撲滅に役立てる、という研究です。欠陥の研究はまだまだ発展途上ですが、これから必ず必要になる研究だと細川さんは説明しました。細川さんは欠陥の話をするときに、よく医学にたとえた説明をします。医師は問診や検査をすることで病気の属性をとらえます。観察できた属性の塊や組み合わせを見つつ、病気を特定します。病気を特定したところではじめて治療を開始します。そのために医師は病気のことを知っていなくてはいけません。医学では病気の症状を事細かに記録し、標本や写真を残していきます(これがいわゆる病理学です)。それによって、病気のマスターを作っているそうです。これをテストに置き換えるとどうでしょうか。テストエンジニアは、テストをすることでバグを出していきます。バグもまた、属性の塊です。そのため、欠陥本体は名前しかないのではないか、というのが細川さんのご意見です。属性の塊や組み合わせを見ながらバグの原因を特定し、修正するところまでは同じです。ところで、今のテストエンジニアはバグのことをどれだけ知っているでしょうか。確かに、テストの最中にバグを発見したら、インシデントレポートを発行してバグを記録しています。記録した情報を次のプロジェクトで生かして、同じようなバグが発生することを防いでいる、という人がどれだけ存在しているでしょうか。バグを記録してそれでおしまい、結局次のプロジェクトでも同じようなバグが出てしまう、という人が大半なのではないでしょうか。今のテストエンジニアは、テスト技法のことはよく勉強して知っているけれど、バグそれ自体のことはあまり知らない人が多い、と細川さんはおっしゃいました。テスト技法というのは、医学でいうとメスでお腹を切る方法のようなものです。いうことは、テスト技法を覚えて「とりあえず使ってみよう。何か出るかも」というのは医学に例えると......考えただけでゾッとしますね。細川さんは、テストエンジニアがバグのことを知るために欠陥情報を蓄積し、データベース化することで欠陥のマスターを作りたい、というアイデアを提唱しました。それを実現するためにいろいろな活動を始めているそうです。欠陥情報を蓄積し、データベース化して誰もが閲覧できるようにすることで、欠陥の混入から除去までのサイクルが短くなり、やがては予測や予防にもつながります。最後に細川さんは息子さんのほうを見ながら「この子が将来テストエンジニアになるかどうかはわかりません。この子が大人になる頃には、『勘でテストをする』という時代ではなくなっているといいと思います。名医とは、病気をよく知っているものです。皆さんには、欠陥のことをよく知っている未来の名医になってほしいです」とおっしゃってセッションを締めくくりました。今目の前にある欠陥の情報を未来にどうやって生かすか、深く考えることができたセッションでした。わたしも未来の名医になりたいと思いました。■ワークショップの成果発表2日目のワークショップはいよいよ最後の仕上げと成果発表です。各グループで1日目に作成した成果物をもとにして、インシデントレポートの改善案をプレゼンするための発表資料を作成しました。それだけではなくグループワークでうまくいったこと、うまくいかなかったこと、ワークショップで得られた気付きやグループとして、また個人としての反省点を出し合い、発表資料に盛り込みました。わたしたちのグループでは、インシデントレポートのフォーマットや書き方について、どうやってプレゼンしようかと話し合っていました。そこに細川さんが通りかかって、わたしのグループの資料を見て言いました。「『どう書くか』について話し合っているみたいだけれど、インシデントレポートは書くことそれ自体が目的ではないよ」この言葉にグループ一同、固まってしまいました。細川さんは、さらに続けました。「インシデントレポートは、読む人に何かしてほしい、何かを訴えたいから書くものです。去年の夏のWACATEのワークショップでも、改善それ自体にこだわるあまり、本部長に報告する、何を伝えてどうしてほしいのか、という目的を忘れてしまっていましたが、また同じ失敗をしてしまいました。わたしたちのグループは再度話し合い、資料に手を入れました。1グループ5分で、改善案とワークショップで得られた気付きについて発表しました。わたしたちのグループでは改善案や気付きについては伝えたいことはすべて伝えられたと思います。あとは個人の反省を伝えればOK......と思ったところで時間切れになってしまいました。実は資料作成のとき、個人の反省を資料に盛り込むかどうかを話し合っているときに、わたしは「発表まで時間もないし、口頭で言えばいいんじゃない?」と提案し、それが採用されたのです。私は発表後、しまった、やっぱり資料に載せておいたほうがよかったのかも、とちょっと後悔しました。結局、ワークショップが終わったあとで発表する機会を設けてくださったのですが、余計なことを言ってしまったかもしれません。グループの皆さん、ごめんなさい。今回のワークショップでは、メンバーそれぞれの立場で観点が異なり、自分だけでは気がつくことができなかった意見を聞くことができたのが良かったと思いました。第3回のレポートはここまでです。次回は、クロージングセッションと後夜祭の様子、そして今回のWACATEで得た気付きについてお送りします。Comment(2)次の投稿へ前の投稿へ最新の投稿わたしの前に道はない、わたしの後に道はできる。19:05細川さんにこの前JaSST関西にこられたときに、前日てふかんで「細川さんを囲む会」を開催し、同じような話をしていただきました。細川さんのファンでしたが、大ファンになりました。ここにあるように、バグは基本的に病気と同じで、バグの根というか、人間の失敗するところは、基本的に同じです。私はあるときから、仕様書からテストシートを作るのではなくて逆に、このバグを発見するためのこのテストを作るというピンポイントから、その周辺にテストシートを作成するようになりました。品質保証という一通りのテストは必要ですが、バグを見つけないとテストとはいえないので、バグを出すテスト手順を考えることをするようになりました。今まで発見したバグを分類し、どうしたらこのバグを早く発見できるかに注力していくと、とても仕事が楽しくなったのを覚えています。10年も前の話ですが。テストって楽しいですよね。当時は宝探しのような感じで仕事をしていました。例を言うと私は新聞の間違い探しをよくやります。一瞬にして見つけるようになりましたが、それは7つの間違いがありますって答えが書いてあるからです。大体それでわかります。作った人は7つのバグをしかけていえるのですね。絵を7つに観点わけします。そこを見たらすぐに間違いがわかります。いうバグがあると思って、テスト観点を分けてそのバグを見つけるテストをします。あれよあれよと、面白いほどにバグが見つかります。仕様書からテスト項目を満遍なく作成してテストする方法もあるのですが地域をうまくわけて、そのバグを見つけるとするといいです。そのとき、このバグっていつもあるよね。・変数の引渡しミス・状態繊維中の割り込みそういった、今まで見つけたバグを分類してそれを見るけるテストを考えてみてください。面白いですよ(^^)そのためのバグ整理インシデントレポートが分類しやすいように作られていると整理も楽です。インシデントレポートの書き方工夫をしてください。00:52NAKAさんコメントありがとうございます。JaSST関西前日に細川さんがいらっしゃったときのてふかんの様子はTwitterで拝見しました。参加者の皆さんがとても盛り上がっていた様子が伝わりました!>仕様書からテストシートを作るのではなくて逆に、このバグを発見するためのこのテストを作るというピンポイントから、その周辺にテストシートを作成するようになりました。テストファーストっぽい感じもしますね。10年も前にそのアイデアを取り入れたテストをされていたんですね。すごいです!>なので、こういうバグがあると思って、テスト観点を分けて>そのバグを見つけるテストをします。>あれよあれよと、面白いほどにバグが見つかります。うわー、それは面白そうです!私もやってみたいと思います。その観点でテストを作っていくとしたら、インシデントレポートが整理しやすい内容であること、というのも必然的になりますね。名前を記憶しておくコメント:第3バイオリン開発と評価それぞれの立場を経験した元テストエンジニア。今は主婦として家事と育児の真っ最中です。【書評】エンジニアになりたい女の子にオススメの絵本3選わたしの前に道はない、わたしの後に道はできる。