ソフトウェアテスト勉強会〜テスターと創る開発現場〜
10月29日（土）に「ソフトウェアテスト勉強会～テスターと創る開発現場～」として、@miwa719さんをお呼びして、テスターやチームについてお話しいただきました。
今回は、組込みシステムの開発チームで一緒にお仕事をされている、dRubyで有名な@m_sekiさんにも
お越しいただき、豪華二本立となりました。
参加人数は16人で、仙台以外からの外部参加者がとても多く、また、テスターが多いという勉強会となりました。
最初は@m_sekiさんのお話で、チームに新しく新人とテスターがやってきた場合、テスターの方が、バグが多様化したというお話をしていただきました。
この、新しく来たテスターが@miwa719さんということで、ここから@miwa719さんのお話が始まりました。
@miwa719さんがいるチームは、以下のようなチームらしいのですが、未だにそんなチームが存在するのか半信半疑です。
@miwa719さんがいるチーム・・・
開発とテスターが分かれておらず、開発者もこんなにテストするのかというようなチームであり、常に、雑談レベルでも、対象の製品についての話が行われ、誰かが困っていたら、すぐに声を掛け合うような状態のようです。
課題や問題を担当者だけのものとせず、自分ならどうするか、現在どうあるべきか自分の問題としてその課題等に向き合う風土ができているとのこと。
どうしたら、このようなチームが出来上がるのかとの質問には、チーム創設当時、問題意識を持ったチーム員が多くいたこと、問題解決のために専任を設ける体制が組めたことがあげられるとのことで、それなりの環境があったことが伺えました。
その後、@miwa719さんがどうテストしているかのお話が続きました。
基本はチケットにて管理しているそうです。
チケットにはテストケースがあり、それを元にテストを行うようです。
チケットに記載している内容が、わかりづらかったり、やたら長かったりと記載内容から、あやしい匂いがわかるらしいです。
担当者の顔色だったり、声のトーンも気にしているようです。
その他、仕様の変更が多かったり、揉めていたのに急におとなしくなったりと、その時の状況もおかしさを見つけるヒントになるそうです。
テスターにかかれば、どうあってもあやしい匂いをかぎ分けられるとのことでした。
五感どころか六感もフル活用していれば、わかるとか。
ただただ、感心するとともに、「匂い」と表現するところに@miwa719さんのお人柄とテストに関するポジティブさを感じました。
私なら「臭い」と表現したくなりますので、まずはここから気持ちを改めないと、あやしいチケットを見抜けないのではないかと思いました。
より良い製品を作るための、チーム作りについてお話を聞くことができましたが、このようなチーム作りをすぐにするのは難しいと思いますので、まずは、できることから始めたいと思います。
できることは限られているので、私は、例えば、以下の２つぐらいからやれたらよいなと思います。
１．なんでも質問できる会議体を作る
@miwa719さんのところでは、朝会の二次会なるものが存在しており、新人等が朝会で分からなかったところを聞いたりする場を設けているそうです。
なんでも聞くことができる場は、それほどなかったりします。
敢えて、会議体として設定しておけば、何でも聞くことができる雰囲気が出来上がっていくのではないかと思います。
２．製品をよくしたいという目的を共有する
製品をよくするというのは、当たり前のことなのですが、チームが細分化されたりすると、自分のチームの担当部分に注力し、他のチームとの連携に関しては、責任の押し付け合いになったりして、うまくいかなくなることもしばしば・・・。
よく出てくる「３人のレンガ職人」の話のように、目的が違えば、作業のやり方も変わってくるのではないでしょうか。
製品をよりよくしたいという、目的をいつも共有できていれば責任の押し付け合いではなく、うまく連携できた作業ができるのではないかと思います。
ソフトウェアテスト勉強会に参加されているみなさんのお悩みとして、新たなテスト技法をチームに浸透させたいと思っても、チーム内の雰囲気が良くないと、うまくいかないことも多いかと思います。
そんな問題を、今回のお話からヒントを得ることができました。
詳しくは、こちらでご確認ください。
わたしたちの開発現場 // Speaker Deck
@m_sekiさん、@miwa719さん本当にありがとうございました。
（竹内）
テスト設計チュートリアル（U-30版）に参加してきました
JaSSTを主催しているASTERでは、毎年「テスト設計コンテスト」というコンテストを開催しています。
コンテスト開始前には「テスト設計チュートリアル」が開催されていて、テスト設計の考え方を紹介していただけます。JaSST’16 Tohokuでは「テスト設計」をテーマに開催しましたが、このチュートリアルは残念ながら東北では開催されていません。東京会場に行って聞いてきましたので、JaSST’16 Tohokuのワーク内容と紐づけながらレポートしたいと思います。
ASTER-テスト設計コンテスト'17-U30 クラス チュートリアル
テストケース作成を成功させるために
「テストケースを挙げてください」と言ったとき、以下のような状況に陥ることが多々あります。
- 思い付きでテストケースの羅列をする
- 粒度がバラバラ
- よく読まないと分からない
テストケースを作成するとき限りませんが、情報を整理する必要があります。そうすることで、テストすべきことが見えやすくなります。大事なことは、自分が納得して、自分で説明すること。伝えてフィードバックをもらうことで、いいテストができるようになります。
それを実現するために、4つのステップを踏みます。
- テスト観点（テストすべきこと）を整理して、網羅的に挙げよう
ピンポイント型のテスト観点もきちんと挙げよう - テストフレーム（テストケースの構造）を考えよう
- テストコンテナ（テスト観点やテストフレームをまとめたもの）とその間の順序関係を網羅しよう
リスクベース度な優先順位付けをしよう - テスト観点からテスト値（テストケース）を網羅しよう
1.テスト観点（テストすべきこと）を整理して、網羅的に挙げよう【テスト要求分析】
トップダウンとボトムアップを循環させながらテスト観点を網羅していきます。
最終的に、階層型の記法を用いると、様々な抽象度のテスト観点を俯瞰的に整理することができます。同じ階層の粒度は揃えることが大切です。分解については、WACATE2016夏の「分解について」という資料を参考にするとよいでしょう。
【図：テスト観点図の例】*3
ピンポイントの観点も忘れずに
- 起きてほしくないこと
危険事象やハザードなどいろいろ - バグ
絶対に入ってほしくないバグやよく作りこんでしまうバグ - 後工程でバグを引き落としそうな罠や弱点
構造が歪んでいるところや分かりにくいところ
プラットフォームや言語使用に潜む罠や弱点
JaSST’16 Tohokuのワークショップの前半では、テスト観点の洗い出しとテスト観点ツリーの作成を行いました。テスト観点は仕様書を伏せて出して行きました。そうすることで、仕様書に書かれていることに捕らわれず、「自分が使うなら」「自分が開発するなら」「こんなバグに出会ったことがある」といった幅広い観点が出せるようになりました。
チームで行うことで、他の人が持っている観点を共有することもできます。ツリー構造にする時には、粒度や言葉の意味を合わせるのが難しくはありますが、相手に伝え、フィードバックをもらい、納得しあう、というフローは、説明力が求められる「テスト技術」を高める練習にもなるのではないかと思います。
2.テストフレーム（テストケースの構造）を考えよう【テストアーキテクチャ設計（テストフレームモデリング）】
"テストケースの構造"には単純なものから複雑なものまでいろいろあります。テストケースの構造を、テスト観点やテストパラメーターで表したものを「テストフレーム」と呼びます。
【図：単純なテストフレームの例】*4
【図：複雑なテストフレームの例】*5
テストフレームはテストケースのスケルトン（骨格）です。テストフレームの要素を見出しとして表にすると、テストケースになります。テストには様々な観点がありますので、テストフレームは1パターンのみでで表現できるとは限りません。
【図：テストフレームとテストケース表の例】*6
【図：組み合わせのテストフレームとテストケース表の例】*7
テストフレームについては、情報交換会の質疑応答で話題にあがりました。今回はワークの提供ができませんでしたが、その後、勉強会を開催して理解を深めているところです。
3.テストコンテナとその間の順序関係を網羅しよう【テストアーキテクチャ設計（テストコンテナモデリング）】
テストコンテナ（テスト観点やテストフレームをまとめたもの）にまとめる
テスト観点やテストフレームが増えてきたら、「テストコンテナ（テストの箱）」にまとめてあげると見通しがよくなります。テスト設計をする人は、「なぜこれらのテスト観点やテストフレームをまとめて、このテストコンテナにしたのか」きちんと説明できないといけません。社内標準のようなもがあり、それを適用する場合であっても、きちんと説明できる必要があります。もし説明できないのであれば、理解が浅いか、その社内標準とテストがマッチしていない証拠です。
＜テストコンテナの例＞
- テストレベル
- テストタイプ
- テストサイクル
【図：テストコンテナの例】*8
テストコンテナ間の順序関係（テストアーキテクチャ）を考える
後工程や後プロジェクトでテストしやすいようにテスコンテナをまとめ、前後関係や並列関係を考える必要があります。テストコンテナを適切に配置しないと、開発がやり直しになるような不具合が出荷間際に見つかったりする羽目になります。
テストコンテナを用いてテストアーキテクチャを設計すると、テストの全体像が俯瞰しやすくなり、チームで共有しやすくなるというメリットもあります。
【図：テストコンテナの例】*9
テストコンテナ間の結合度を低め凝集度を高めるようにしつつ、テストアーキテクチャ設計の品質特性を高めていくのが王道…ということですが、これがテスト設計の腕の見せどころでもあります。テスト設計コンテストでも特に重要視されており、出場経験のある私としては、ここが一番難しく、評価を分ける部分だと感じています。
※リスクベースドな優先付けをしよう
リスクベースドテストとは、「もしこのテストケースを実施しなかったらどのくらい困ってしまうのか？」と推測し、困ってしまう程度（品質リスク）の高い順に優先順位をつける方法です。テスト担当者はリスクを明らかにした上で、後回しにできる品質リスクを顧客や開発側と相談し、合意を取ります。テストアーキテクチャ設計では、品質リスクに合わせて厚みやバランスを決めていきます。リスクの高さによっては網羅基準を変えることもあるでしょう。
テスト詳細設計では、品質リスクの高い順にテストケースを実施するとよいです。
JaSST’16 Tohokuでは、テストコンテナの作成と並び替えのワークも行いました。私が担当したグループでは実際の業務を意識し、「この不具合はいつの時点で見つかってほしいのか」という視点でコンテナを並び替えました。例えば、「ユーザビリティの観点については、テストの最終段階（リリースの直前）になってから言われても直しようがないので、実装をするもっと前、設計レビューで指摘されたい」といった感じです。テストは実行に目が行きがちですが、レビューも大事なテストの一つ。テストコンテナを作成し並び替えることで、レビューの観点ができあがったのは大きな発見でした。
4.テスト観点からテスト値（テストケース）を網羅しよう【テスト詳細設計】
テストケースの導出までは、以下の流れで行っていきます。
【図：テスト値の導出】*10
青の四角に書かれたものをインプットとし、丸の中に書かれたことを行います。オレンジの四角に書かれているものがアウトプットです。次のインプットにもなっていますね。丸に書かれていることを、1つずつ見ていきましょう。
1.モデルの特定
モデルには以下の4種類があります。
【図：モデルの種類】*11
①範囲：連続性があるもの
②一覧表：因子水準表など
③マトリクス：組み合わせを表現する
④グラフ：画面遷移図や状態遷移図など
グラフは全体を俯瞰しやすい一方で表現するための技術が必要であったり、マトリクスは簡単に作れる一方で巨大化しやすいという難点があったりします。どれを使うのが正解、というわけではなく、その時に整理したい内容や好みに合わせて活用していくのがよさそうです。
2.詳細化する
これ以上細かくならないところまで細かくします。洗い出してしまえば理由を付けてテストの量を減らすことはできますが、洗い出しが不十分な場合、テストが漏れてしまいます。
3.基準を決める
テストの厚みや幅を調整するための基準を決めます。このとき必要になる情報としては以下の2つです。
- カバレッジ基準：説明材料として必要なもの
- 状況、条件、制約：現場や案件の現状に合わせた形にするために必要な情報
これらはプロジェクトやテストの計画時に用意されていることもありますが、ない場合は、様々なテストベースから導き出す必要があります。 リスクベースの考え方を用いてみましょう。
4.基準に沿ったテスト値を導出する
テスト値を作成します。テスト値には、直接テスト手順の一部（テストデータ）として実施できるものと、テスト値からさらにテストデータを導く必要があるものに分かれます。前者の場合、そのままでテスト実行できるかもしれませんが、後者の場合はテストデータの抽出が必要になってきます。
このように、テストケースを作成するときには、詳細化やモデリングを行います。闇雲にテストケースを作成したのでは、このテストが十分かどうかの説明もできませんし、効果的なテストに間引くこともできません。最後まで、自分が納得して自分で説明することを意識するとよいでしょう。
テスト観点図やテストコンテナの作成も、詳細化とモデリングという作業を行っていました。これがテスト設計の肝なのだろうなと感じています。
まとめ
東京で開催されたテスト設計チュートリアル（U-30版）のレポートをお届けしました。テスト設計チュートリアルは全国各地で開催されています。東北のみなさんから「テスト設計やりたい！」というたくさんの声が届けば、来年は東北でも開催されるかもしれません。JaSST東北の実行委員と一緒に、勉強していきましょう！！
お知らせ
10月29日（土）に仙台にて、「ソフトウェアテスト勉強会～テスターと創る開発現場～」が開催されます。JaSST'14 Tohokuで講演いただいた@miwa719さんにお越しいただき、テスターやチームについて語り合います。参加費はお菓子＋会場費として300円のみとなっていますので、ぜひみなさん、ご参加ください！
記：めい
JaSST東北おかわり会(07/02)を開催した話
【JaSST東北おかわり会開催】
7/2(土)にJaSST東北おかわり会ということで
丸1日参加者のみなさんとVSTeP漬けになりました。
仙台で土曜開催にもかかわらず、
仙台の人だけでなく、新潟や愛知の人にも参加していただき、
開始早々プレッシャー高まるおかわり会となりました。
【おかわり会午前の部】
午前の部は、VSTePの紹介を行いました。
JaSST東北本会のにしさんのようにはできないので
にしさんに感謝しつつ
にしさん講演資料ベースにスライドの順番を入替えたり、
今回対象範囲にしない記載を抜いたり、
補足や途中のまとめを入れたり等させていただき
VSTePの概念や大事にしたいポイントをお伝えすることにしました。
（にしさんにはTwitterで質問のフォローをしていただき、本当に感謝してます。）
私には、聞いてるだけだと実際どうやるのか理解しにくいという思いがあります。
どこまで、どの粒度で、はVSTePをやる際、みなさんの悩みどころだと思っています。
JaSST東北本会でも、グループによっては
「詳細に出したまま議論しすぎてしまったため、まとめるのが大変苦労した」、
「粒度がまちまちになってしまい、もやもやした」、
ような話を聞きました。
そのため、午前の部の時点で無茶振りですが、
ざっくり考えてテスト観点出しをするワークや、
そこからテストコンテナを作成するというワークをすることにしました。
ワークでは詳細すぎる観点ではなく、
ざっくりした観点を考えてもらいやすく促そうとしてみたり
VSTePで大事にしたいプロセスをないがしろにした場合に陥る問題の体感をしていただきました。
まずは、自分が気になるところを大事にするといい、ということや
どうなると、「もやもや」するのか？
どの部分の理解が「もやもや」していてのか？
など、早く「もやもや」していただけるようにしてみました。
午前のワーク時間は超短時間ということもあり、
結果はそれなりに狙い通りになった気がしますが、
実際参加者目線ではどうだったのか気になるところです。
無茶振り以外でも何物でもないので、本当に大変だったと思います・・・。
無茶振りにも関わらず、みなさんのアウトプットはいい塩梅で
本当に助けられたと思いました。
参加されたみなさん、ありがとうございました（＞＜）
【午後の部】
午後の部は、JaSST東北本会と全く同じ流れで実施しました。
午前の「もやもや」が晴れて、次なる「もやもや」が生じたようです。
次なる「もやもや」も、まぁそうですよね。と思いつつ、
私たちがよくわからず迷いながらも着実に歩んだ道を
参加者のみなさんは理解しつつ、私たちと違って早足で歩いていただいてるようで、
やってよかったんだろうなぁと実感しました。
「もやもや」が残る方もいる中でそれでも最後に、参加者の人たちから
「楽しかった」、「来てよかった」っていわれる勉強会になって
ほんとによかったです。
【次なる「もやもや」のために】
私たちは最後まで残った次なる「もやもや」に立ち向かおうと思います。
おかわり会のおかわり会を開くことにしました。
しかし、現状のまま自分たちが変わらないと
「もやもや」は減らないままであることも認識していました。
そのため、少しでも自分たちのレベルアップを図ろうと
JaSST東北実行委員は、いろんな「もやもや」解決のため
少しでも期待に応えられるようVSTePの勉強会を独自に開催(7/23)しました。
勉強会の主旨は、分析から、テストケース作成まで一連した流れの体験です。
・詳細設計するために必要なレベルの分析ってどこまでやればいいのだろう？
・コンテナから詳細設計へのつながりってどうやるのだろう？
そんな疑問点が少し晴れる勉強会になりました。
おかわり会のおかわり会では、きっと
若干レベルアップした（かもしれない）実行委員に会えることでしょう。
【年中おかわり会！？】
おかわり会のおかわり会があるなら、
そのおかわり会も・・・・とすると
１年中おかわり会になるんじゃないの！？、
っていう話もありますが、私はあまり気にしていません。
VSTePはテスト開発方法論の１つですが
VSTePが大事にしたいポイントって、テストに限らず
開発、評価問わず業務全般に生かせると思っているので
それが少しでも広まるんであれば、それはそれでいいんじゃないの、と思っています。
私含めて、いろんな人の
「楽しい開発」、「楽しいテスト」に
少しでも生かせるならいいですよね。
【最後に】
みんなでうんうん唸りながら、手を動かしながら楽しんで勉強できるよう
8/27(土)におかわり会のおかわり会を開きます！
http://tohoku-dev.jp/modules/eguide/event.php?eid=317
おかわり会のおかわり会では、
今回の結果を次回に反映したいと思ってますし、
次回は、異なる「お題」で開催してみようと思っています。
VSTePを知らない方はもちろん、
JaSST東北本会やおかわり会に参加された方の中で
異なるお題でやってみたい方はぜひいらしてください。
みなさんと一緒に楽しんで勉強できるのを
JaSST東北実行委員会一同、心よりお待ちしています♪
記：うめつ
JaSST2016東北でVSTePやってみた！
【はじめに】
JaSST2016東北が終わって約１ヶ月が経ちました。
結果は大成功でした。アンケート結果を見てもべた褒めで、正直、信じられない位の大成功でした。にしさんを始め、安達さん、水野さん、JaSST東北に参加してくれた皆さん、スタッフのみんな、本当にありがとうございました。
JaSST東北で実施した内容については、JaSSTのHPおよびレポートを見て貰えば分かるので、ここではスタッフの裏側と言うか、色々準備したことを記載しておきます。
今後、これだけの熱量（＝やる気）が出るか分からないので、記録として残しておくことにしました。
他のJaSSTで同じ様なことを行う人がいるかも知れないので、参考にして下さい。
色々言いたい人もいるでしょうが、やったもん勝ちですｗｗｗ
【JaSST2016東北の概要】
JaSST東北のHPを見て貰えば分かりますが、今年のJaSST東北は「テスト開発しちゃいなよ」をテーマに、電気通信大学のにしさん（@YasuharuNishi）を招いてVSTePに挑戦しました。
午前中がにしさんによる基調講演。午後が参加者全員によるVSTePワークショップでした。
【今回のコンセプト】
JaSST東北の実行委員長をネモさん（@nemorine）から引継いだ時に、以下の思いから、今回の「一つのテーマに終日取り組む」形にしました。
思い①：にしさんを東北に呼ぶ。
４年前のJaSST東北が立ち上がった頃に、一度にしさんが仙台テスト勉強会に来て、お話ししてくれました。その時の話がとても面白くて、その頃から是非JaSST東北で基調講演をやって欲しいと思っていました。
（確かにしさんと話した時の第一声が「CMMiやってますか？」で、その次が「CMMiやって良くなりましたか？」だったと記憶しています）
思い②：テストアーキテクチャ設計を学びたい。
JaSST2015東京のテスト設計 コンセプト コンテストの総評の時に、にしさんが「テスト要求分析、テストアーキテクチャ設計を行うのは当たり前になって来た。テストアーキテクチャ設計のデキで勝敗が決まった」と解説をしていました。これに僕は衝撃を受けました。「テストアーキテクチャ設計ってそもそもよく分からないし、東北でそんなことを行っているのは、（実行委員を除いて）僕は聞いた事がない。東京に比べると東北のソフトウエアテストは遅れているかもしれない・・・」と考え、東北でテストアーキテクチャ設計を学ぶイベントをやりたいと強く思いました。
思い③：スキルを残したい。
JaSST東北は2015年で３回を数え、毎回楽しいのですが、楽しくて終わってしまって、いまいちスキルとして残らない感じがしていました。昨年、安達さん（@kitanosirokuma）に来ていだだき、レビューに関する講演をしてもらったのですが、参加者から「演習時間が短くて、もっとやりたかった」との意見を聞きました。その時に「これなら一つのテーマで１日かけてもいいんじゃないか？午前に講義して、午後にその演習（ワークショップ）を行う感じで」と考えました。私もそうですが、講演等でいい話を聞くと、すぐその気になるのですが、実際に手を動かさないと身に着かず、すぐ忘れてしまいます。そのため、ワークショップで参加者が手を動かすようにしたいと考え、今回の構成にしました。
思い④：JaSST東京の劣化コピーはやりたくない。
2千人が参加するJaSST東京は規模が大きく色々な内容が「広く・深く」入っています。JaSST2015東京の実行委員の方が「JaSST東京はデパート。何でもある」と話していましたが、その通りだと思います。東北（というか地方）で東京と同じ規模のイベントは出来ないと考えます。同じ事をやろうとしても「中途半端で浅く」なると思います。ならば逆に「狭く・深く」やろうと考えました。JaSST東京の劣化コピーなら、JaSST東京に参加した方がいいので、「JaSST東京と違うこと」をやろうと考えました。
【準備作業】
上に書いたコンセプトは、JaSST2015東北を実施した後の振り返り会でほぼ決めてました。
今思うと１年前ですね。もちろん、にしさんへのお声がけも何もしてないので、本当に実現できるかは分かりませんでした。
会場手配とにしさんの快諾
JaSST東北は会場費の節減のため、仙台市の公的施設を借りて実施しています。会場の手配は６ヶ月前の抽選で決まります。このため、１１月頭にならないと会場と開催日程が確定しません。今回は抽選で仙台駅近くの会場が当たったので、良かったです。
会場と開催日程が決まったので、にしさんへ基調講演とワークショップを行いたい旨を伝えたところ快諾をいただきました。
その時に、にしさんから「ワークショップを行いたいなら一度実行委員会でVSTePをやってみて下さい」とのお話をいただき、実施することになりました。
（この時点ではこんな展開になるとは想像もしていませんでした・・・）
１２月の失敗
１２月２７日にスタッフが集まり、東京からメイさん（@hinac0)にも参加してもらい、電気通信大学のにしさんの研究室資料をもとに、VSTePを実施してみました。テスト対象はLhaca（圧縮解凍ソフト）で、まず解凍機能のみやってみました。
結果は大失敗。散々でした。
午後いっぱい作業時間があったのですが、テスト観点図の作成で時間がなくなり、しかもテスト観点図をどこまで作ればいいのか、よく分からなくなって終わりました。
ここで非常に厳しい認識に至りました。
「これはにしさんに教えてもらわないと無理だ」と思い、にしさんに仙台に来てもらえないか、相談することなりました。
２月２１日 にしさん打合せ
にしさんに相談した所、何と（！）仙台に来ていただける事になりました。正直、来ていただけるとは思ってなかったので、感謝の上に感謝しても足りません。本当にありがとうございました。
２月２１日ににしさんに来ていただきVSTePを実施しました。テスト対象はLhacaよりさらに小さいLhasa（解凍ソフト）で実施しました。
にしさんのアドバイスを受け、全部ではないですが、何とかVSTePを理解できました。テストコンテナを作ることによって、前半の観点図の苦労が報われること等、やっとVSTePが少し見えた気がしました。
この時ににしさんから「50人の規模なので、ワークショップはJaSST東北スタッフがモデレータを務めること」「自分（にしさん）は各島を廻り、各モデレータをサポートする」との話をいただきました。50人のモデレータをにしさん一人ができる訳が無いので、もちろん同意なのですが、問題は「我々が本会までにVSTePのモデレートをできる様になるか」が最大の課題になりました。何せ僕を含めてVSTePもモデレートも未経験だったので。
（余談）
にしさんが参加してくれたVSTeP演習の時に、僕がモデレータ役を務めました。こういう時の中心役は大変で、自分の理解度が足りない場合、にしさんに突っ込まれることになります。なので、大変なのですが、逆に一番勉強できる役とも言えます。モデレータ役をやってにしさんに突っ込まれるより、参加者役になって見ている方が楽なのですが、逆にいうと自分の理解が不完全でも誤解したままでも、そのまま終わってしまいます。他人から指摘されるのは辛いかもしれませんが、教えを乞う時はあえて「地雷を踏みに行く」方がいいと考えモデレータ役を買って出ました。恐らくこの時に一番勉強できたのは僕だと思います。
３月５日 VSTeP復習会
２月２１日のにしさん打合せの復習会として、３月５日にT-Pad T-Pod（ミュージックプレイヤー）をテスト対象にVSTePを実施しました。
不思議なもので（当然かもしれませんが）、回数を重ねる毎にVSTePの進め方が上手くなっていくのが分かりました。１２月はテスト観点図でタイムアップしましたが、テストコンテナまで作成できました。そこで、次はVSTeP未経験者を入れてやってみることにしました。
３月８、９日（JaSST東京参加）
本会のモデレータ役をJaSST東北スタッフが実施するのはいいのですが、残念ながらJaSST東北スタッフは僕を含めて１１名しかいません。スタッフ１人、参加者５人で構成しても最大５５人しか参加できません。そこで、JaSST東京に参加した時に、JaSST北海道の安達さん、水野さん(@NoriyukiMizuno)にお声がけして、ワークショップのモデレータやアドバイザー役をお願いしました。突然の無理をお願いしましたが、お二人とも快くお引受けいただきました。本当にありがとうございました。水野さんは前日入りして、我々モデレータ初心者に、モデレートする時の注意点等をアドバイスしてくれることになりました。感謝しております。
３月の失敗と「VSTePワークショップの進め方解説資料」
３月２５日にVSTePの未経験者を入れてVSTePを実施してみました。テスト対象はLhacaの解凍機能です。
ここで２つの課題が判明しました。
①未経験者の場合、テスト観点図の成果物イメージがよく分からない。また、テスト観点図の次の作業が分からないので、どこまで観点図を作っていいか分からない（テスト観点図作成の完了基準がわからない）。
②いきなりテスト観点を付箋に書き出す様にすると、参加者は仕様書のコピーを始める。
というものです。
これを解決するため、
①参加者が完了基準や完成イメージが分かるようにVSTePの成果物サンプルを作る。
②ワークショップの進め方（注意点）をまとめる。
ことにしました。
この二つをまとめた資料「VSTePワークショップの進め方解説資料（＝VSTePでテスト開発しちゃいなよ）」を作成しました。この資料によりVSTePを初めて行う参加者でも、ある程度進められる様になったと思います。（「VSTePワークショップの進め方解説資料（＝VSTePでテスト開発しちゃいなよ）」は予稿集に入れてあります。また、当日のワークショップ終了後に参加者全員に配布しました）
４月９日 VSTePの練習会
４月９日に北海道のネモさんが参加してVSTePの練習会を行いました。テスト対象はカンバンリスト（Webアプリ）です。この日は普段福島にいるJaSST東北スタッフも参加してのVSTeP練習会でした。本来、参加回数の少ない福島組にモデレートをしてもらう予定でしたが、ついVSTePに夢中になってテスト観点図を完成させちゃいました。今までのなかで一番上手くいったと思います。上手くいった要素としては「回数をこなして慣れた」と「テスト対象が、普段仕事で接しているWebアプリだった」ためだと思います。普段仕事で接しているWebアプリだと、テスト観点やその集約化も割とスムーズにできました。
普段福島にいてもJaSST東北のスタッフですので、今回のモデレータを務めてもらう必要がありました。距離的な問題から、練習にあまり参加できなかった福島組は、自社内の同僚を相手にVSTePの練習をするなど工夫して本会に臨んだそうです。
４月２９日 にしさん再打合せと「持ち帰って欲しいもの」
４月２９日にも再びにしさんに仙台へ来てもらいました。当初は本会の進め方やワークショップのリハーサルを行う予定だったのですが、にしさんより「VSTePのメリットは様々あるが、わずか半日のワークショップでそれを全て理解して貰うのは無理である。今回のワークショップで参加者に何を持って帰って貰うか（＝参加者に理解して欲しい事）を明確にする必要がある。そうしないと各モデレータの説明やモデレートの仕方がバラバラになってしまう」との指摘を受けて、丸一日かけて「持って帰って欲しいもの（＝参加者に理解して欲しい事）」を検討しました。
検討した結果、「持って帰って欲しいもの（＝参加者に理解して欲しい事）」は以下の様に決めました。
(1)テスト観点図作成：①仕様書に無いテスト観点が出る。②参加者全員の合意を得る。
(2)テストコンテナ作成：テストの保守性が向上する。
それぞれの「持って帰って欲しいもの」に対して、どうモデレートすれば参加者が意識してくれるか、参加者へのアドバイスの仕方などを資料にまとめて、スタッフで共有する様にしました。（スタッフの手持ち資料になりました）
この日もVSTePの未経験者に参加してもらって意見等を貰いました。「テスト観点図とテストコンテナの違いが分からない」との質問を契機に、僕を含めて各スタッフのVSTePの理解度の違いが分かりました。貴重な時間を我々の練習にお付き合いいただき、ありがとうございました。
５月の直前練習とモデレートの注意点。
５月１２日と１５日に、本会の直前練習（リハーサル）を実施しました。スタッフがモデレート役と参加者役に分かれて、本番の進め方をリハーサルしました。
これは僕がスタッフに無理を言って開催したものですが、やって正解でした。スタッフそれぞれの認識がずれていた事が分かりました。また、ワークショップのタイムスケジュールをあらかじめ定めて、全体で同じ時間で作業する様に見直しました。（それまではワークショップの時間配分は各モデレータの裁量に任せる予定でした）。
リハーサルによって、参加者の議論を活発化するための仕掛けなど、細かい準備を行うことができ、本番に備えることができました。僕の無理を聞いてくれたスタッフに感謝です。
前日の水野さんセミナー
北海道の水野さんが前日入りしてくれて、我々スタッフにモデレータの心得や、本会で「持って帰って欲しいもの」を再確認するセミナーを開催してくれました。お忙しい所、本当にありがとうございました。
【開催当日】
にしさんの基調講演資料について
基調講演資料について、にしさんは今回のワークショップ用にかなり作り変えてくれました。電気通信大学のにしさんの研究室資料を見ると分かりますが、VSTePでテスト観点図を作る時に、テスト観点に「品質リスク」等を記載します。ところが、今回はリスク記載は演習の範囲外なので、説明を全部付録側に移動してありました。
また、予稿集が出来上がった後に、参加者からの事前アンケート結果を送付したところ、作り終わった予稿集に更に質問に対する説明等を加筆してくれました。
にしさんの基調講演について
にしさんは、基調講演資料もそうですが、全９０分のうち最初の３０分をかけて、ひたすら参加者を煽っていました（現状のままで満足している方は、お金返すから帰ってくれとか・・・）。おそらく午後のワークショップに向けて、参加者のやる気を引き出すことに集中していたんだと思います。本当に有り難いです。ワークショップは我々がいくら準備しても、参加者のやる気がないと上手く行きません。午後のワークショップを成功させるために、にしさんは全力で取り組んでくれたんだと思います。繰り返しになりますが、本当に本当にありがとうございました。
ワークショップについて
午前のにしさんの煽りのお蔭か、驚くほど盛り上がり、大成功でした！
お通夜になるんじゃないかと心配していたのですが、そんな事もなくどのテーブルも盛り上がっていました。
お通夜を避けるために、スタッフが話し合ってWACATE等のテストイベントの常連さんたちを、各島に１人座って貰う様にしました。それも上手く行く要因だったと思います。
スタッフの振り返り会では、スタッフの殆どが準備した「持って帰って欲しいもの」を上手く説明できた（＝持ち帰って貰えた）と話していました。
反省点としては、常連さんたちに前もって連絡をしていなかったため、ビックリされた方がいらっしゃると思います。突然、申し訳ありませんでした。
【結果と反省と】
結果としては、大成功でした。こんなに上手く行くとは、スタッフの誰も思っていませんでした。にしさん、安達さん、水野さん、JaSST東北に参加してくれた皆さん、スタッフのみんなにお礼を言いたいです。本当にありがとうございました。
最後の懇親会の挨拶で、泣きそうになりました。それぐらい、嬉しい結果でした。
反省点としては幾つかあります。
・他のIT系のイベントと重なった。
・スタッフがVSTePを習得するのに時間がかかり、JaSST東北本体のイベント準備がバタバタになってしまった。
・スタッフ全員がVSTePのモデレータを出来る様になるため、かなりの時間を拘束した。
【最後に】
当然の事ですが、スキルは苦労しないと身に着きません。
苦労してスキルを身につけるか、苦労せず身につけないかどちらかです。
今回はスキルを身に着けること、東北の人達にテストアーキテクチャ設計を知って貰う（＝体感して貰う）ことを目的としてここまでやって来ました。
参加者の1人でも、JaSST東北が終わったあと、自分の会社等でVSTePを試してもらえれば、頑張った甲斐があるというものです。
また、今回はスタッフにかなり無理を言いました。何度も「これはチャレンジだから、失敗してもいい」と話しました。「上手く行かなかったら、上手く行くまでやる。３年連続VSTePでもいい」とまで話しました。（さすがにスタッフに止めてくれと言われましたがｗ）
スタッフのみんなは、よく頑張ってくれたと思います。僕一人では、こんなことは出来ません。本当に感謝の言葉しかありません。ありがとう！
【ちょっとだけ宣伝】
７月２日（土）にVSTePの復習会をします。一日かけてVSTePのワークショップを行いたいと思います。
JaSST東北に参加できなかった方、何かモヤモヤしてる方、是非、ご参加下さい。
TDCサイトで申込み受付中です。
内容：ソフトウェアテスト勉強会～JaSST'16 Tohokuおかわり会～
開催日：７月２日（土）10：00～18：00
場所：戦災復興記念館 第４会議室
http://www.hm-sendai.jp/sisetu/sensai/index.html#sisetu-annai
参加費：500円
お待ちしています。
以上、長文にお付き合いいただき、ありがとうございました。
（記）JaSST2016東北 実行委員長 高橋
20160624:誤字を修正
