唯一無二のソフトウェアテスト勉強会 WACATE
若手のソフトウェアエンジニアの皆様、新春いかがお過ごしでしょうか。きっと早くもコードを書いたりバグと戦うという毎日を過ごしているかと存じます。私、金子昌永と申します。2014年12月6日から7日にかけて、有志により行われるソフトウェアテストの勉強会「WACATE2014冬」が開催されました。私はこの参加者の一人であり、この度その模様と魅力をご紹介する機会をいただきました。
さて、昨今ではソフトウェアエンジニアのための勉強会は各地で毎日のように開催されており、泊まり込みで行うものもあります。中でも「WACATE」はソフトウェアテストを軸としている密度の濃い数十人規模の勉強会です。日本全国各地から集まる数十名が一泊二日を共にし、ワークショップ形式のセッションが多数を占めるプログラムに身を投じるという機会は他には無いことでしょう。
参加者層は、ソフトウェアエンジニアとして何かしらの仕事をしている方がほぼ全てのようです。業種はコンシューマ向けウェブサービスから産業向け組込みシステムまで多様で、職種はやはりテストエンジニアが多めですがプログラマもそこそこいるようです。同じソフトウェアエンジニアでありながら普段なかなか出会えない立場の方と出会えるのが勉強会の魅力ですね。
何よりWACATEのターゲットは若年層であり、初参加者層もそれなりにいるので、合宿型の勉強会にしては参加のハードルは比較的低いのではないかと思います。また、主催者も若年層の技術者が中心であるため、自身と比較して刺激を得やすいという特徴があるかと思います。しかもセッションオーナーはシンポジウム等での発表経験を持つ方が多く、クオリティは折り紙付きです。私は2014夏と2014冬の計2回参加していますが、どちらも得られたものは確かにあると感じております。
それでは、WACATE2014冬の内容をお伝えして参ります。
参加申し込み
WACATEは参加を申し込むところから始まっています。ポジションペーパーを提出する必要があるからです。このポジションペーパーは参加者同士の交流の源になるほか、後に紹介する投票にも使われます。書き方は皆さんそれぞれで、履歴書の自己PR文のようなもの、手書きのイラストをふんだんに使っているもの、笑いに走っているもの、いろいろあります。もしあなたがSNSを使っているのであればアカウント名を書いておきましょう。同志と繋がる絶好のチャンスです。申し込みをしたら後はWACATEは寝て待て。間違っても休日出勤になることのないようにタスクをこなしておきましょう。
オープニング
場所はマホロバ・マインズ三浦というところで、すぐそばには海が見え、心地よい潮風が運ばれてきます。「 本当にここでソフトウェアテストのために一泊二日を費やすのか…」と、釣りにでも行きたい気持ちを押さえて会場のある建物に入ると、それらしい受付スタッフが待ち構えています。ここで参加費を払います。私は35歳以下なので22,000円です。36歳になると25,000円になるそうです（35歳の方、決断するなら今です！） 。
大きめの会議室のような部屋に着くと、数名のグループごとに座るように机と椅子が並べられており、席も決められています。同じグループの方に挨拶をして雑談をしていると、ほどなくオープニングセッションが始まります。ここではWACATE誕生の背景や参加の心構え、一泊二日の過ごし方についてていねいにお話いただきました。
ポジションペーパーセッション
続いてグループの数名を相手に自己紹介をする場が設けられます。ここでポジションペーパーが使われます。このセッションでは各参加者のポジションペーパーをまとめた冊子を見ながら、参加者が互いに自己紹介をします。この自己紹介タイムはメンバーを変えて2回行われ、これで何名かの顔と名前が覚えられます。もう寂しくありません。ちなみにメンバーを変えた後のグループがこの後のグループワークを共にするチームとなります。
このようにオープンニングとポジションペーパーセッションを通して初参加の方がスムーズに馴染めるようにプログラムが組まれています。「 よくできているなぁ」というのが率直な感想です。
また、WACATEでは誰かのポジションペーパーに投票することが恒例となっており、最も得票数の多い賞は Best Position Paper（BPP） Award と呼ばれます。BPPに選ばれると、この記事のようにWACATEの模様をgihyo.jpにてご紹介する権利と、次回WACATEに無料で招待される上にBPPセッションを開く権利が与えられます。というわけで次回WACATE2015夏では一枠担当する予定です。
BPPセッション STORYかけてますか
前回のBPP受賞者である高橋一勢さんによるセッションです。作業計画を立てる際に、6W2Hのフレームワークによる具体化とそれぞれのリスクを考えることを、架空のシステムテスト実施作業の計画を例に語って頂きました。架空の例の割に妙に現実感があるのは、きっと自身の体験になぞらえているからなのでしょう。
単に計画するとは言わず『STORYを描く』と言っているのが高橋さんの主張の特徴で、確かにそう言った方が始まりから終わりまでを一直線にイメージとして考えられますし、想像力を働かせる気になりやすいと思いました。
ボクらのプロセスにきづこう
『工程の方のプロセスであって、OSが管理するプロセスではない。』という注釈があるのがソフトウェアの勉強会らしいですね。といってもWACATEに来る層はアジャイル開発やXDDPなどに比較的親しみがありそうなので、この注釈は必要ではないかもしれません。
このセッションでは「宅配便」のプロセスを図示するというグループワークを行いました。まず個々人それぞれで（入力）－（宅配便）－（出力） というシンプルな図を書いてみることになりました。「 荷物」を入力して、出力も「荷物」…？という疑問に突き当たった方が多いようです。私は「送りたい荷物」を「受け取った荷物」に変換するプロセスと解釈しましたが、他のメンバーは違った解釈をしていました。
このようにプロセスを図示すると議論できることが意外に多くあるのですね。「 宅配便」という身近な例ですら数名で30分程度の議論ができるわけですから、普段の仕事に当てはめてみると、新たな気づきや改善案が数多く出てくることでしょう。
モデル検査入門
モデル検査の概観に関する講義と、状態遷移モデルに対する時相論理を検査する小演習が行われました。演習では『一度ラーメンを食べたくなると、ずっとラーメンを食べたい。』などという時相論理が真である状態遷移モデルが頻出しておりましたが、これはきっと講演者の食欲をモデリングしたものなのだろうと想像しながら演習に取り組みました。
クラシフィケーション・ツリー法入門
分類木を書くことによりテスト条件のモデリングとテスト設計を行うことができる手法だそうです。記述のルール自体は平易で、機能テストの入力や事前条件の整理から始められそうなので取っつきやすい印象を受けました。演習もあったのでわかりやすかったです。
日本では全く無名らしいこの手法をどうやって知ったのかが気になりますが、講義資料の参考文献には洋書が幾つか並んでいましたので、日ごろから洋書を読まれているのでしょう。私もたまに読むことがあるのですが、どうにもMPを大量消費してしまうもので習慣にはなっていません。見習いたいものです。
温泉とディナーセッション
ここで1日目は一区切り。各セッションで集中するとかなり疲れるものです。温泉とご馳走で回復しましょう。ここからはお酒も入ります。実行委員の二人によるトークショーで参加者の申し込み時のメッセージを紹介したり、技術書を抽選でプレゼントするのが恒例のようです。
宴会ですからもちろんのこと親睦を深める良い機会です。セッション中ではあまり接する機会の少ない他のグループの方や実行委員とお話をするのに向いていると思います。私は実行委員の一人に「ブログにあるほぼ全てのエントリを読みました。昔は？？という時代もあったのですね。」と話しかけ、『 うわぁあああ黒歴史見られてるー！』とMPにダメージを与えることに成功しました。親睦の深め方は人それぞれです。
夜の分科会
宴会も終わり21:00を回ると夜の分科会があります。テーマごとに5つ程度のグループに分かれて議論をするものです。各分科会のテーマは参加者が決めるので、特に議論したいテーマがある方は申し込み時に申請しておくといいでしょう。
私は他の参加者が主催した「モバイルアプリ/サービス開発におけるテストエンジニアの向かう先」というテーマの議論に参加しました。私は組込みシステムを専門としていますが、モバイルアプリとウェブサービスの知識も必要ですので有意義な議論ができたと思っています。明確な結論は出ませんでしたが、各参加者それぞれの普段のソフトウェア開発への関わり方、職種、業種の違いから見られる意見の違いは興味深く、副次的に得られた知見は見逃せないものです。
もしあなたが駆け出しのエンジニアであったり、他の職場のエンジニアと会話をする機会に乏しいのであれば、この機会に自分の言葉で沢山議論に参加するのがおすすめです。自分のレベルや、次にステップアップすべきことがきっと見えてくるでしょう。
さて、公式に組まれている夜の分科会は23:00で終了しますが、悪い大人はどこかの部屋に集って深夜の分科会を始めます（ただの飲み会です） 。
バグ票をもっとうまく使うために
二日目の最初となるセッションのテーマはバグ票です。良いバグ票についての議論は少なくともBugzillaなどのクラシックなチケット管理システムの時代からあったと記憶していますが、現代でもまだまだ議論できるところはあるようです。
このセッションの内容は、お題として配られたいくつかの悪いバグ票に対して、デバッグ担当とプロジェクトリーダーのサポートという二つの立場で改善して欲しいことを挙げ、その違いが何かを考察するというグループワークでした。
デバッグ担当者はバグを再現するための情報が欲しい
プロジェクトリーダーのサポート担当者はバグの修正優先順位を決められる情報が欲しい
という傾向がどのグループの結果からも読み取れました。結果自体は予想できるものでしたが、立場によって着目する情報が異なることは、実際の開発の中で各人がバグ票に関わる時にどこまで意識できているかは見直すべきところがあるのではないでしょうか。そう考えさせられたセッションでした。
はじめよう！レビューのいろは
こちらもグループワークであり、お題として配られた仕様書と設計書に対してレビューを行いました。グループの一人は仕様書を書いた人として、一人はレビューの進行役として、他の人はレビュアーとして役割が分かれるという同僚によるテクニカルレビューの形態がとられることとなりました。
お題の仕様書と設計書には実に多くの欠陥があるため、ついつい「こんなことも書けていないのか」という気分になりがちですが、欠陥を書き留めるときも作成者にそれを伝えるときも冷静にならないといけないことを改めて認識できたセッションでした。
1段深い心で人と関わろう
15年間占い師をしているという上條飛鳥さんのセッションです。思想の異なる人たち同士で会議をすると何が起きるかを体験するため、フクロウ、イタチ、ネコ、ロバ、ウシ、ゾウという6種類の動物が集まり、人間によってもたらされた世界的な動物の食料危機を議論するというグループワークを行うことになりました。各人にはその人が扮する動物とその役割が書かれたカードが配られ、役割は他人には明かせないというルールがあります。
私にはイタチのカードが配られ、その役割は「革新的な意見を出す」というものでした。その他の役割には「何でも否定する(ロバ)」「 直感的に判断する(ウシ)」「 総合的に判断する(ゾウ)」といったものがあり、各々の意見が同時に出ると議論がなかなか進みません。どの立場の意見も必要なのですが、議論のフェーズごとに選ばないといけないことがよくわかりました。
セッション中では明らかにされませんでしたが、元ネタは『エドワード・デボノ博士のSix Thinking Hats』ですね。思考ツールや会議を進めるフレームワークとしての紹介ではなく、各帽子を価値観や信条ととらえてワークセッションに仕立てているのが特徴的だと思いました。
なお、革新的な意見を出す役割のあるイタチとして出した意見は、水道・ガス・電気・通信などのインフラを動物達が協力して徹底的に破壊することで、人類が立ち入れないエリアを作ろうというB級映画にありそうなものでした。同様に人類を攻撃する結論を出したグループが全体の6割を占めました。仮想設定に対するグループワークとはいえ、ずいぶんアグレッシブなものです。
ソフトウェア開発に必要な技術としてのコミュニケーション
招待講演者である名古屋大学の森崎 修司先生によるセッションです。コンウェイの法則やブルックスの法則から始まり、情報共有とコミュニケーションについて、ご自身の豊富な経験を交えてお話頂きました。研究者となる以前は開発者であったこと、研究者となった現在でも幾多の企業と関わっていること、シンポジウムにおける組織的活動に関わっていることもわかり、コミュニケーションに関する主張に説得力があるように感じました。終始意気揚々とした口調でしたが、裏には『あなたはどうしてゆこうと考えていますか？』という真っすぐなメッセージがあったようにも感じました。
こう書くとご本人にどう捉えられるか不安なのですが、シンポジウムでお見かけする森崎先生はどちらかと言うとズバッとした明言を避ける方という印象がありました。しかし、今回のWACATEにおける森崎先生は明朗快活な一本筋の主張があったように思います（特に深夜の分科会にて） 。
開発者の皆さん、WACATEに参加しましょう！
私はWACATEに2014年の夏と冬の2回参加しました。ソフトウェアテスト技術等の習得はもとより、私から見て他業界のエンジニアと知り合えたことは貴重であり、その後の努力を続ける契機になっています。素晴らしい機会に感謝しています。
ただ、ポジションペーパーの内容から察すると、純粋な開発者の参加比率は少なく、「 もっと参加した方が良いのでは？」と感じています。
勉強会に参加するような開発者の層には、より良い設計を追求したり、モダンなプログラミング言語や開発ツールを習得するといったことに興味を持っている方が恐らく多いことでしょう。そして、テストにはあまり興味が無いかもしれません。私がそうでした。「 テストに技術なんてあるんだ」くらいに思っていました。
しかし今ではテストの基礎知識は開発者にとって必須だと考えています。開発者がバグを見つける技術を追求すると、設計時に何を誤りやすいのかを自然と追求することになり、ひいては設計スキルの向上に役立ちます。テストのプロセスを学べば、テスターとのコミュニケーションが円滑になります。特に上位のテストレベルの活動については、組織によっては開発者が知らないことが多いかもしれません。ここの知識を埋めるだけでもソフトウェア開発の世界が大きく広がって見えることでしょう。
つまり、テストを学んでいない開発者の方々はWACATEに参加すると良いと思います。これは強引なポジショントークと思うでしょうか？いいえ、WACATEはそれだけの価値ある機会を与えられる場なのです。少しでも共感した方は次回（6月予定）にお会いしましょう。
