「WACATE 2012 冬」参加レポート（その1）――大海原に船を出した蛙、三浦半島へ

コミュニティ活動

» 2012/12/27

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

　もはや半年に一度の恒例行事となりましたが、ソフトウェアテストワークショップ「WACATE 2012 冬」に参加しました。今年はテスト分析によるテストアプローチ、CFD（原因流れ図）の使い方、そしてテストエンジニアのキャリアプランについて深く考える場となりました。

　さっそく、参加レポートをお届けしたいと思います。

■日時と場所

日時：2012年12月15日〜16日
場所：マホロバ・マインズ三浦（神奈川・三浦）

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

　WACATEのはじまりはポジションペーパーセッションです。参加者がグループになって、参加申し込みのときに提出したポジションペーパー（立場表明書）をもとに、参加のきっかけや目的、この場で議論したいことを3分間でプレゼンします。

　わたしは今回、ポジションペーパーには今後の進路というか、方向性についての悩みを書きつづりました。このままテストエンジニアとしてスキルアップに励むのか、現場から少し離れてテストエンジニアをサポートする立場に回るのか。ただひとつ言えることは、どちらを選ぶにしても最新の技術を知りませんでは通用しないこと、勉強だけはずっと続けないといけないということです。

　勉強会の参加目的としては、かなり変化球だったと思いますが、とにかくグループのメンバーに発表したところでわたしのWACATEはスタートしました。

■BPPセッション「かえる井の中ふりかえる 〜わたしのテスト自動化経験〜」

　前回の「WACATE 2012 夏」でBPP賞を受賞した、畠山さつきさんのセッションです。

　BPP賞とは、「ベストポジションペーパー賞」の略です。毎回、WACATE参加者の投票によって選ばれる「最も加速しているポジションペーパー」に与えられる賞です。

　前回、初参加でいきなりBPP賞を受賞した畠山さん、これまでに携わってきたテスト自動化の経験と、WACATE参加後の活動と意識の変化について語ってくれました。

　畠山さんはテストの自動化に携わって7年になります。しかし、職場にはテストエンジニアを目指す人はほとんどいなかったと語ります。なんとか独学でもテストを勉強しようとJSTQBの資格試験を受けてはみたものの、知識だけを詰め込むやり方に疑問を抱いていました。

　もっと同じ志を持った人はいないのか、そういう人が集まる勉強会はないものか。そう思ってテストの勉強会を探していたところで、WACATEを知ったそうです。

　それまではテスト技法もテストコミュニティの存在もほとんど知らない、まさに井の中の蛙だったと畠山さんは自分自身を振り返ります。さっそく「WACATE 2012 夏」に参加して、井戸の外はなんて広いのだ！ とカルチャーショックを受けたそうです。さらに、テストコミュニティのなかに「テスト自動化研究会」というコミュニティがあることを知り、入ることに決めたそうです。

　「テスト自動化研究会」で、畠山さんはTABOKに出会いました。TABOK(Test Automation Body Of Knowledge)とは、アメリカでまとめられたテスト自動化の知識体系です。日本はおろか、アジアでもまだあまり普及していないそうです。

　畠山さんはTABOKについて学ぶうちに、自分の経験について意識が変わって来たそうです。以前は「自分はテスト自動化しかやってない、テスト自動化の経験しかない」と後ろ向きに考えていたのが「自分にはテスト自動化の経験がある、なんとなく過ごしてきた日々の中に、価値ある経験がたくさんあった！」と、前向きな考え方に変わってきました。

　畠山さんは、TABOKを学ぶことで、当時、携わっていたテスト自動化の業務をテスト自動化レベルのフレームワークに当てはめて考えることができるようになりました。そうして自動化テストのやり方を改善したり、自動化テストの適用範囲を広げていったりしているうちに、社内でも自動化チームの活動や自動化支援ツールの存在が知れ渡るようになり、いろいろな相談を持ちかけられるようになったそうです。

　テスト自動化の活動を広げていくうちに、畠山さんは「自動化はテストの目的ではなく手段のひとつ。だから支援ツールに頼り切るだけでなく、テストの知識も必須なんだ」という考えに至りました。

　そこで、「WACATE 2012 夏」に参加してから半年間、機会があればなんでもやろうといろいろなことにチャレンジしました。まずgihyo.jpへのレポート寄稿から始まって、先に上げたテスト自動化研究会への参加、テスト設計コンテストへの参加、それからコミュニティで出会った人たちと勉強したり遊んだり、とにかく数えきれないほどいろいろな経験をしたそうです。それらの経験を通してさらに多くの人と知り合ったり、ひとつの経験が新しいチャレンジへのお誘いにつながったりしていったそうです。

　畠山さんは、これらの経験で初心者から脱却できた、井戸の外に飛び出した蛙が大海原に船を出せたと話しました。

　最後に畠山さんは「今まで自分は未熟だ、自分の経験なんてたいしたことないと決めつけていた。だけど、それはテストのことをきちんとわからないままそう決めつけていて、それは間違いだということに気がつくことができた。自分の経験がテストという大海原でどういう位置にあるのか、それを知ることができた、そして自分の経験に自信を持てたことが、この半年間で一番の成果です」と語って締めくくりました。

　実はわたしは前回の「WACATE 2012 夏」のワークショップで畠山さんと同じグループになりました。そのときも初参加とは思えないほど積極的でテキパキとワークに取り組んでいたことを思い出しました。今回の発表を聞いて、半年間にものすごく多くのことにチャレンジされていたことを知り、改めてそのバイタリティに感服しました。また、勉強することで自分の立ち位置がわかるようになって自信が持てるようになった、というお話も素敵でした。

■セッション「テストアプローチにデータ分析を使おう」

　WACATE実行委員の中野 さやかさんのセッションです。

　中野さんは、このセッションの対象者として「テストアプローチをあまり知らない人、テストアプローチに悩んでいる人、データを取るだけになっている人、データ嫌いの人」と説明しました。

　次に中野さんは参加者に向かって「テストアプローチしていますか？」と質問をしました。何人か手を挙げた人もいましたが、大半はしていない、そもそもテストアプローチをよく知らないという人ばかりでした。

　ひとくちに○○テストといっても種類はたくさんあります。それをすべて実施するのは不可能です。何のテストをするか、どのようにテストするか。効率的に欠陥を見つけるテストをするにはどうしたらいいか、それを知るための手段がテストアプローチです。

　中野さんは、ここで「データ分析」のお話を始めました。データといって思い浮かべるものは何でしょうか。数字や数式、パラメータや基準値etc.……なんだか難しくてよくわからないや、という方も多いでしょう。しかし、データ分析をすることで、見積もりや予測ができるようになる、数字で裏付けが取れるというメリットがあります。

　ここで、ワークショップが始まりました。

　ある開発プロジェクトのデータを示したグラフが配布され、グラフからこのプロジェクトの気になるところを探してみる、という内容でした。

　まず個人で気になるところを探し出し、その後グループでそれぞれの意見をまとめました。わたしのグループでは、たくさんあるプロジェクトの問題点を挙げたあとで、少し良い部分もあったのでそこも忘れずピックアップしました。

　グループとしての意見を模造紙にまとめた後で、2日目のモーニングセッションを担当される村上 くにおさんから「日頃、なんとなく作っている、受け継いでいるものを使っているけど忙しくてその意味を考える暇がない、という人もいるかもしれません。こういう機会にそれを見直して、考えてみてほしい」とご講評をいただきました。

　セッションの最後に、中野さんは「今回紹介したグラフがすべてではないし、いつ何時でもこのデータが役立つとは限りません。データ分析だけですべてがわかるわけではないですが、データをうまく利用することも考えてみてください」と話しました。

　グラフのデータから「ここ何か変だぞ、気になる」という部分を探し出し、個人で考えたりグループで議論したりすることでその「何か」が何なのか、どういう意味があるのかを見つける過程が面白いセッションでした。

　このセッションと次のセッションの合間の休み時間に、ご講評をくださった村上さんが突如、メトリクスについてのゲリラセッションを行うという一幕がありました。「メトリクスはともだち！」というセリフが忘れられません。

■セッション「かいてみようCFD」

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

　近江さんは、まずCFDの説明から始めました。

　CFD(Cause Flow Diagram)とは、今回のクロージングセッションの講師を担当される松尾谷 徹さんが開発したテスト技法です。「原因流れ図」ともいって、ソフトウェアの処理の流れを、原因と結果（インプットとアウトプット）の流れ図にすることによって、そのソフトウェアに対してどのようなテストが必要かを整理することができる技法です。CFDをもとにしてデシジョンテーブルを書くと、原因と結果の組み合わせの抜け漏れを防ぐことができます。

　CFDの説明が終わったところで、さっそくCFDを書くワークショップが始まりました。架空のシステムの仕様書が配布され、その仕様書に記載された仕様について、原因と結果を洗い出し、CFDに起こすというものです。

　そこでわたしはいきなりCFDを書き起こしてみたのですが、書いているうちに原因と結果をつなぐ矢印がこんがらがって、わけがわからない図になってしまいました。周りの人のなかには、仕様書をひととおり読んでから、各要素について書く人もいました。こちらのほうが、処理の流れを先に整理できる分、後で楽にCFDを書くことができるようでした。

　ワークショップのあとで近江さんは、「CFDのメリットは処理の順番を意識できること、図にすることで全体を意識しやすくなること、そして一人でも使えるので自分自身のミスをなくすのに役立つことです。とくに、設計段階で取り入れると早い時期からテストに意識を向けやすくなります。直感的に理解しやすいうえ、テストエンジニアでなくても読めるのでステークホルダー同士の情報共有にも便利です。ぜひ、現場で活用してみてください」と話して、ワークショップを締めくくりました。

　わたし自身、とりあえず目についたところからいきなり書き始める、という悪いクセがあることは自覚していましたが、そのクセに足をすくわれてしまいました。CFDはうまく使えば原因と結果の流れがわかりやすくなるはずなのに、無計画に書いてしまったことでかえってよくわからない図ができあがってしまいました。もうちょっと、先に全体を見て、おおまかな全体像をつかむやり方を、CFDを通して学んでいこうを思いました。

 

　今回のレポートは以上です。次回は1日目の後半の様子をお届けします。

　そして、2012年のコラムはこれが最後です。読者の皆様、この1年間読んで下さってありがとうございました。それでは、よいお年を。