自分から話すのは苦手なので、とりあえず巻き込まれてみた記録

概要

自分から話すの苦手、人を巻き込んで何かやるの苦手、ならいっそとりあえず巻き込まれてみる方針で行こう、と決めて1年半くらいやってみた記録です。JAWS DAYSに登壇した後輩が、「巻き込まれ力」というテーマで話していて、いい言葉だなーと思ったので書いてみました。ちょっと勢いで書いてみた感があるので、読みづらい部分はお許しください。

きっかけ

勉強会はちょいちょい参加してたけど、どうも自分から話しかけに行くのが苦手なので、なかなか話せる人ができず、ちょっとどうしたもんかなーと思ってました。
そんなところに、ワニ氏からWACATEに誘われ、ついでにコミュニティ活動に興味ないか、と声をかけてもらいました。それが「バグ票ワーストプラクティス検討プロジェクト」。バグ票はもともと困ってた＆技術書翻訳に興味があった、で参加を決めました。
2016年冬のWACATEに初参加。この年は、物心ついてから初めて、カープのリーグ優勝を見たのも、新しいことにチャレンジしてみるきっかけになりました（ホント感動しました）

WACATE

参加してみて、ソフトウェア品質に関わる方々と、夜中まで話せたり、色々な方とのつながりができました！参加レポートはこちらに書いてますので、よかったらどうぞ。
WACATE2016冬「あなたのためのアラカルト」に参加してきました（1日目編）
http://d.hatena.ne.jp/yuki_shiro/20161225/1482659762

WACATE2016冬「あなたのためのアラカルト」に参加してきました（2日目編）
http://d.hatena.ne.jp/yuki_shiro/20161231/1483184966

参加の効果

WACATE後の初JaSST、後輩の登壇で話しかけに来てくれる人がたくさんいたし、WACATEで知り合った人たちが情報交換会で声をかけてくれたり、飲みに誘ってくれたりしました。ぼっち気質の自分にとって、見かけて手を振って声をかけてくれる人のいることはとてもありがたかったです！

SQiP登壇のお誘い

4月末くらいに、SQiPのSIGに応募してみようという話がコミュニティであがり、せっかくなのでまだ登壇したことのない自分に、登壇してみたら、と背中を押してもらいました。正直、お仕事があまりうまくいってなかったり、忙しかったりで不安な部分も大きかったんですが、でも、全力で巻き込まれてみることにしました。ワークショップ的なことをやってみるのは初めてだったのですが、

• やりたいことの整理、コンセプト決め
• ワーク作り
• 例題に必要なダメな例探し
• タイムテーブル作成
• オフラインでの合宿、レビュー

などなど、コミュニティのメンバに助けられて、何とか準備できました。レビューを通して、コミュニティメンバのアウトプットやコメントの正確さに圧倒されました。（コミュニティ活動されている方って行動力すごいなあ）

SQiPでSIGやってみた

初めてのSIGにして、初めてのSQiP参加でした。ワークショップで、タイムテーブル通りにはいかずちょっと焦ってましたが、参加してくださった方にも助けてもらい、無事終了。

SQiPフィードバック実施

会社の勉強会でSQiPのフィードバックを行ったところ、「会社でもワークショップやってみなよー」と背中を押され、全力で巻き込まれてみました。twitterで、会社でもワークショップやってみなよーといわれて企画中と呟いたら、テストクラスタの方々から「やっちゃいなよ！」とか「いいね」をもらえたので、それにも背中を押されました。（呟くことによってやる方向に自分を追い込んだとも言う）11月の連休の真ん中という日程でしたが、ワークショップを実施したところ、先輩、若手が計8人も来てくれて、すごくありがたかったです。社外コミュニティでやったことを、社内にも生かせるとやりがいありますね。

会社のプロジェクトで試験チーム任せてもらう

それまで社外でのプロジェクトに従事していたのですが、9月頃から社内に戻り、機械学習を使ったシステムのテスト。初めてでちょっとビビりつつ、試験チームのリーダをやらせてもらいました。メンバの方にスケジューリングやらなにやらよく助けてもらいました。何かあったら、チームのメンバ集めて共有、作戦会議「ちょっと見てもらっていいですかー」とか、技術書典の戦利品置いといてみたりとか、雰囲気作り的なものをちょっと意識してやってみました。メンバがそれにノッてくれる方ばかりで、私も助かりました。

社内でのバグ票レビュー

12月から1月にかけて、社外コミュニティでバグ票の改善活動をやってることを見た上司から、以前に所属していたプロジェクトのバグ票レビューをやってみないか、と声をかけてもらいました。後輩がいくつか、ダメそうなバグ票をピックアップしてくれたので、そちらにコメントをつけて返却。
ここで、気持ちの良いコミュニケーションをやりましょう、といってた自分がコミュニケーションの失敗をやらかしました。社内SNSのコメントだけのやり取りをしてしまったので、開発チームから「それだとちょっとしんどい」とコメント受けて反省しました。なので、開発チームのメンバに集まってもらい、MTGを実施。

• QAチームはこのバグ票の書き方だと、ここが困ってる
• こう直してもらえると助かるので協力してくれないか

　ただし、「こう直してもらえる」は無理ない範囲で。
バグ票で困っていることを開発チームに聞いてみたら、バグ票の項目で一部書き方が分からない、という部分があったりと、一応やってみてよかったと思える会にはできたかと思います。

とりあえず、巻き込まれてみる

1年半くらいやってみて、相変わらず、自分から話しかけるの苦手ではあります。けど、話しかけてみたりやってみたりして、なんとかなった、という経験の蓄積中なのでちょっとずつよくはなってるんじゃないかなーと期待。この辺自分ではよく分からないので。
分かってきたことは、「困ったら巻き込んだ人を頼ってみる。素直に助けてっていうと、結構みんな助けてくれる」ということでしょうか。次のステップは巻き込まれついでに、周りもついでに巻き込む、あたりを目指してみますかね。

JaSST'18 Tokyo参加レポート 1日目

今年もJaSST'18 Tokyoに参加してきたのでレポートします。

「Advances in Continuous Integration Testing at Google」

John Micco（Google）

Googleのテスト

• 1日、1億5000万件のテスト実行（420万件のテストを1日35回繰り返す）
• マニュアルテストはない。100%自動化している
• 99%のテストはPASSSする
• コードをコミットするときは、当然のごとくテストコードも一緒

テストの選び方

• 依存性関係を持ったテスト
• コードの依存性グラフを作っている
• テストは450万件あるが、依存関係グラフによって実行対象を絞れる→影響のないところはテストしない、割り切り

テスト結果への対応

• テストの合否はすべて記録（2年分）
• ひたすら自動テストを実行
• PASSからFAILに移行した場合→スケジューリングをさかのぼってどこから変わっ・たのかすぐにチェックする。
• 結果のパターンが見えてくる
• 結果は何種類かに分類することで、開発者とインフラチームが責任を持つべき結果を分けている

Flakyなテスト

• 同じテストを実行する中で、結果が成功から失敗（またはその逆）に状態が切り替わるもの。不安定なテスト。
• テスト結果を蓄積して、Flakyの原因が何なのか分析中。問題がない場合もある

Googleの文化

• テストを自動化する価値→イテレーションの高速化。手動はない。100%自動化。人が死ぬようなシステムないからね！という割り切り。
• コードレビュー時に同時にテストコードをサブミットしてもらうようにしている

感想

愚直な正論の積み重ね。日本の周回遅れを感じました。
あまりに印象が強すぎて、思わず当日券買って次の日のチュートリアルに参加しました。
基調講演聞いて、がぜんチュートリアルに興味が出たので、チュートリアルも受講してきました。

「はじめてみようテストプロセス改善〜テストプロセス改善モデルを使った改善活動の勘所〜」

TPI NEXT、TMMi、ISO/IEC 33063といった各種改善モデルの紹介。

改善の勘所

1.アセスメント
　やってみる
　認識合わせた
　振り返り

2.計画
　関係者の要求を確認
　関係者との調整
　バッファを持った計画

3.実行
　状況確認
　改善アクション
　更なる改善

重要だと思ったポイント

改善は大変。何より大事なのは１人で悩まないこと。いろんな人と話す。困ったら誰かに話す。

「テスト会社のテストリード達はどのようにテストを成功に導いているのか？」

いいこと色々いってたのですが、自分的にはツイートした内容がクリティカルだったので、そこについて。

開発/テストエンジニア/エンドユーザを他で例えてみると
　開発者：小説家、漫画家
　テストエンジニア：編集者
　エンドユーザ：読者
いい編集者は、読者の求めてるものを考えてる、一方作家のやりたいことも理解している。そこにずれがあればうまいこと埋めてあげる。 #JaSST

— yuki shiromoto (@yuki_shiro_823) 2018年3月7日

とても良い例えだと思いました。そして、最近自分はこのように行動できてるかな？と自問するきっかけになりました。一応機能の目的とか、どういうユースケースを想定してるのか前よりつっこんで聞くようにしてますが、もうちょっと開発者と一緒に考えられるようになりたい。

「開発がスクラム導入するんだって！試験どーしよ！？」-サイボウズQAスクラム奮闘記-」

クラウドサービスcybozu.comの管理者機能開発の事例

開発：QA：PO=5:5:1

＜スクラム導入前の問題＞
　バグの検出が遅い
　要件があいまいなまま開発がスタート
　開発とQAの隔たり感

　→スクラム研修受ける
　　やってみよう
　　
＜開始までの準備＞
(1)「カンバン仕事術」輪講

(2)もろもろ定義
　完了の定義
　テストに関することをどこまで含めるか定義
　開発チームの実力に合わせることが大事
　→含めなかったこと
　　・テスト実行を完了する
　　・脆弱性検証
　　
(3)アジャイル第一人者の講演を聞く

＜導入後のプロセス＞

• スプリント2週間
• リリース単位は6スプリント＋リリーススプリント

＜よくなったこと＞
(1)バグの早期検出
　類似バグの量産を防げる
(2)要件の明確化
(3)開発チームの一体感
　QAは開発のリクエストにこたえられるようになった
　開発はQAのことをより気に掛けてくれるようになった
　
＜実際＞
スクラムは問題発見のフレームワーク。

Garoonの開発チームの事例

＜開発のプロセス＞
　スプリントは3週間
　リリースサイクルは3か月
　
＜導入前＞
全員スクラム未経験、拠点は日本、中国、ベトナム三箇所
→とりあえず日本のみ
　スクラムチームに日本QAが足りない
　　当時PG7名、QA2名
　　→1名SMやるため実質QA1名
　
→スクラムの基本にのっとるのはあきらめた
　スプリント内では実装完了、次のスプリントでテスト設計・実施
　テスト設計、実施は海外拠点
★結論：失敗した失敗した失敗した

主な原因
　価値分割できず、バックログアイテムが巨大化
　仕掛中タスクが大量発生
　職能の壁が発生

課題はあれど、海外拠点でもやることに

開発と比べると、QAの方が変化が大きいのでは

＜解決＞
チームの有志で勉強：実践アジャイルテスティング
　ABD（Active Book Dialogue)

職能間の障壁を下げる
　できる作業は職能に関係なく着手

感想

★結論のところで、スクラム導入当初のバーンダウンチャートをさらす勇気が素晴らしいと思いました。下がるはずのバーンダウンが炎上している！って紛れもなく失敗で外部に出したくないものだと思うんですが、出してくださって勇気づけられます。失敗しても改善して前に進んでいるチームがいるって事実はちょっとほっとしますね。ありがとうございます。

バグ票の改善観点の紹介と、やりやすいところからの改善のおすすめ

これはソフトウェアテスト Advent Calendar 2017の14日目の記事です。
この1年、バグ票ワーストプラクティス改善プロジェクトというコミュニティで活動して、得たこと、感じたことを書こうと思います。

そもそもバグ票はなんのために書くのか？

バグ票の一番大事な目的は、バグを直してもらうことだと思っています。テスト実施者がバグを見つけ、それを開発者に伝えてバグを直してもらう、そのためのコミュニケーションツールですね。

バグ票のどういう点が問題になりやすいのか？

先日、ソフトウェアテストの小ネタ Advent Calendar 2017の記事である、リリカル氏のブログ記事「エンジニアに「は？」とキレられたバグ票ワースト5」を見ていただくとよく分かりますが、バグ票はよくテスターと開発者の間で問題になります。
・再現できない
・そもそも何がもんだいなのかわからない
・テスターと開発者、または、複数社またがる開発だと開発会社間などで
　やたらとコメントのやり取りばかりが続く　etc
色々パターンはありますね。

バグ票改善観点のご紹介

そんな問題の起こりやすいバグ票を改善するためのヒントとなる本を紹介します。

Bug Advocacy: A BBST Workbook (English Edition)

コミュニティが主催/担当したワークショップで何度か紹介してますが、
こちらは、Cem Kerner, Rebecca L. Fiedler らが2015年7月下旬に出版した書籍で、著者が大学で行った講義の内容をまとめたものになります。
講義資料や、実際の講義のビデオもこちらのサイトから見られますので、興味のある方はぜひどうぞ。

おすすめポイントは、バグ票改善のヒントとなる「RIMGEN」の観点を学べることです。
RIMGENとは、バグ票の記載内容を改善するための6つの要素の頭文字をつなげたものです。

• Replicate（再現性）：再現できるか
• Isolate（独立性）：単純な手順となっているか、1件/レポート となっているか
• Maximize（発端性）：最悪なことが起きるバグの兆候をみつけているか
• Generalize（普遍性）：プロダクトに対するバグの影響範囲を識別できているか、そのバグは他の環境や条件で発生することはあるか
• External（第三者性）：プロダクト利用時にバグの影響範囲を開発者やテスト担当者、開発組織外の視点から識別できているか
• Neutral（中立性）：困惑させるような推測や思い込みなどがないか

※日本語訳は、つけてみたものの、自分でもしっくりきてないところがあるので、何かよい訳があればコメントいただけると助かります。

バグ票の見直しを行う場合や、バグ票の書き方について教育を行う場合に参考にできると思います。

バグ票が、このRIMGENの観点にそって書かれていない場合には次のような問題が起こると考えています。
まず、大きな問題として「関係者間の信頼関係が崩れる」ということがあげられます。
もう少し細かく分類すると

• 再現不能なバグとして却下される
• 修正されるべきバグにフォーカスが当たらない
• バグの内容を理解するのに時間がかかる
• バグが非現実的、不合理として却下される

ということがあげられます。

バグ票の改善をやりやすいところから始めよう

上であげた問題と、RIMGENの観点、改善ポイント、改善難易度をマッピングしてみた図です。

図の通り、観点によって改善のやりやすいもの、やりにくいものが存在します。
個人的なおすすめは、比較的取り組みやすい「書き方で防げる問題」の対処から始めることです。
可能であれば、開発者とテスターに集まってもらい、
何が書いてあればお互い困らないかを話して、その場でフォーマットを決めてしまうとよいと思います。

ワークショップで、困ったバグ票のサンプルを提示し、それを改善するためのフォーマットを作るという試みをしましたが、
だいたい、どこでも「ファクト・事象」「再現手順」「期待する動作」はフォーマットの内容として挙がってきました。
それだけ、多くのバグ票関係者が困っているところであり、逆にここが改善されると効果の大きいところなのだと思います。
再現手順欄がなければ、欄を作る。
欄があっても書いてくれなければ、理由をヒアリングして対処を打つ、などやりやすいところから着手していくと
テスターと開発者の間で伝わるバグ票に一歩ずつ近づけるはず、と思って活動してます。

まとめ

バグ票の目的は、バグを直してもらうことです。そのためには伝わるバグ票を書くことが必要です。
紹介したRIMGENの観点を使って、やりやすいところから改善することで、お互いに伝わるバグ票を書きましょう！

JaSST'17 Tokaiに参加してきました

2017/12/08(金)に開催されたJaSST'17 Tokaiに
参加＆ワークショップのアシスタントしてきたので、レポートします。
始めてJaSST Tokai参加しましたが、
講師の方や参加者から色々なお話が聞けて良かったです。

はじめの一歩、やってみる現場改善

細谷泰夫氏（三菱電気）
<概要>
現場の改善を行おうとすると変化を伴うため、恐れや抵抗がある。それらとうまく付き合ったり、かわしたりしつつ、どう改善を進めていくかという話でした。
改善活動の形態は次の3つ
(1)チームの一員
良さそうなことはとにかくやってみる
→興味を持ってくれた人に共有、巻き込む
→アピールする（社内、社外）

(2)リーダやマネージャ
基本的にはチームの一員と一緒
他へ展開しようとした時、組織の壁にぶちあたる、どうやって越えるか？
→段階的に導入

(3)組織外の支援者として
支援先が抱える問題やその原因を共有しないまま新しい方法を導入してもうまくいかない
→まずは解決したい課題の明確化、目的の共有
　あとは(1)や(2)と同じ

恐れや抵抗を具体的に越えていくための方法として、講演の中で紹介された本が、
こちらの
「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」
です。
Fearless Change本の中で紹介されているパターンを体感するためのゲームもあるそうです。

＜感想＞
(1)チームの一員から(2)リーダやマネージャ的な立場に移行しつつある立場として聞いてました。
自社の場合は、始めてみる分にはさほどの抵抗感はないものの、
定着するまでに試行錯誤がいるなあ、というのが今感じているところです。
改善は定着するまで、行きつ戻りつの繰り返しだと思うので、
最後の方で言われていた細谷さんのモットー
「短期的には諦めよく、長期的には執念深く」
を真似させてもらうつもりです。

講演を聞く中で、自分に足りてないのはアピールする、だと思いました。
幸いなことに、自社ではアピールのハードルは比較的低いので、
Fearless Change本を読んで実践してみようと思います。

「様々な現場で、改善・生産性向上を進める上で気をつけてきたこと　〜 誰がために、その改善を行うのか 〜」

山本久仁朗 氏（アカツキ）
＜概要＞
様々な組織でQAとしてキャリアを積む中で、
色々試行錯誤されてきたこと、うまくいったこといかなかったことの紹介でした。
(1) QA部署の存在感と実績を積み上げる＠部署立ち上げ時期
　リスクベースドテスト導入
　→リスクの早期削減による手戻りの削減
　各チームへのツール提供、横串活動
　
(2)QA組織のやるべき事
清水吉男氏によると以下の4つ
・ミツバチの役割：他プロジェクトへの展開する
・ペースメーカーの役割：先に進める
・ブレーキの役割：ダメそうなら止める
・コンサルタントの役割：世の中のトレンドにアンテナを張る

＜感想＞
自社でもQA組織をやっているものの、
まだまだ人数も少なく、試行錯誤中なので
リスクベースドテストや、各PJへの展開などはぜひ進めていきたいところ。
QA組織立ち上げ時に、どのようなメトリクスをとっていたかなど
参考になる話も後の懇親会で質問させてもらえたので、
自社展開しようと計画中です。

「バグ票カウンセリング　〜 バグ票の悩み、話してみよう！解決しよう！ 〜」

こちらは、アシスタントとして参加してきました。
資料は後ほど公開されたらリンクを貼っておきます。

参加者の皆さんにバグ票のレベルアップを体感してもらおうと、
サンプルの問題事象を提示して、
まずはいつも自分が書いているように、バグ票を起票してもらいました。

次のバグ票改善として以下の3点を紹介しました。
(1)再現性：バグ票に書かれている内容を再現できるか
(2)独立性：バグ票1件で1つの問題について書かれているか
(3)中立性：思い込みや推測で書いていないか

これらの観点を踏まえて、再度同じ問題事象でバグ票の起票を行ってもらいました。
起票の仕方に変化の見られた方が何人かいらしたので、
レベルアップを体験してもらえてたらいいな、と思っております。

ワークの最後に、参加者のみなさんが抱えるバグ票についての問題について
分類してみました。

時間の都合上、それぞれ深堀りできなかったのが残念ですが、
観点ごとに解決へのアプローチが異なるので、
今回のワークがヒントになってくれると嬉しいです。

情報交換会＆懇親会

情報交換会は、バグ票島の担当として、いらっしゃった皆さんと
バグ票にまつわる様々な話をしました。
じゃんけん大会では、気になっていたFearless Change本をまさかのGET！

正直これはかなり嬉しかったです。
読んで実践します！
特に「みんなを巻き込む」とか「成功の匂い」あたりが気になってます。

懇親会では、最近気になっているKPIについての疑問を色々な方に聞いてみました。
突然オープンすぎる質問をした皆様すみません。
真剣に答えてくださってありがとうございます。
自分なりの答えを試行錯誤してるところなので、
この辺は何かまとまったらどこかに書こうと思います。

JaSST Tokyo '17に参加してきました

2/3(金)AM開催のテスト分析とテスト設計勉強会と
2/3(金)、4(土)開催の2日間開催のJaSST Tokyo '17行ってきました。

■テスト分析とテスト設計勉強会
こちらは、以前書いたWACATEでのリリカルさん(@mhlyc)の疑問から発生した勉強会です。

勉強会の詳細や資料はこちらにアップされてますので、参考にどうぞ。登壇された方はどなたも発表が面白く、色々と現状の自分の理解を整理したり考えるきっかけになりました。
https://connpass.com/event/47938/?utm_campaign=&utm_source=notifications&utm_medium=email&utm_content=title_link

勉強会を通しての理解は、
テスト分析：「何」をテストするのか、対象を理解すること
テスト設計：「どう」テストするのか、テストのやり方を考え、観点とかテストケースのひな型を作ること
と私は理解しています。

分析と設計の違いは、LTで登壇されてた河野哲也さんの説明が、すごくしっくりきました。
ソフトウェアで考えると分析、設計をやる人が同じだったり、各成果物が分かりにくかったりで分解しづらい。
そこで次のような注文住宅の例を出されていたのですが、分かりやすかったです。

　注文住宅における分析
　　登場人物：住宅メーカーの営業、注文主
　　やること：注文主の要望のヒアリングと整理
　　　　　　　要望のうち、できないことの明確化
　注文住宅にのける設計
　　登場人物：設計士
　　やること：住宅の設計
　　アウトプット：設計図

分析でやってることって、「これからしようとしていること」への理解と整理なんですよね。だから特にこれと決まったアウトプットがなく、はたから見ると分かりにくい。
会社の上司とも、分析、設計について話したんですが、MindMapだったり、何かしらのリストであったり、やはり分析フェーズのアウトプットは明確でないよね、という話になりました。
昔は「テスト観点」まとめるのがテスト分析だと思ってました。現在は、分析した結果を受けてのどうテストするかが「テスト観点」だと思ってます。ただ、観点を考えているときのモヤモヤは分析の面も入るので、この辺分析と設計は行ったり来たりを繰り返すものかなーと。いろいろやってみて、理解が変わったらまた書いてみようかと思います。

■JaSST Tokyo 2017感想
特に印象に残ったものの感想をあげてみます。

論文発表1 ： テストマネジメント　「品質予測モデルの構築およびプロジェクト管理への適用事例」
　SEPGとして、品質予測モデルの構築して、3プロジェクトへ適用していったお話。モデルの作り方がすごくかっちりされているなーという印象を受けました。途中の予測モデルの構築のやり方は数式が出てきたあたりで脱落しました。すみません。。

　「テストマネジメントツールSquashTMを利用した継続的テスト改善 」
　会社の後輩の発表でした！日本では適用事例が（たぶん）初となるテストマネジメントツール「Squash TM」を適用してみた時の話です。テストマネジメントツールの導入は、テストエンジニアの皆さん関心が高いようで、盛り上がった発表でよかったです。
　発表資料は、後日JaSST公式から公開されますが、今回登壇した後輩が、Squash TMの紹介記事を書いてますのでご参考にどうぞ。
　SquashTMことはじめ。
　http://qiita.com/miwakai/items/843c76e50eef7719ae6d

「VSTePのファーストステップ〜JaSST'16東北出張おかわり会〜」
テスト分析の技法であるVSTePのワークショップ。VSTePの詳細は、以前のJaSSTの西康晴さんの資料を参考に。
http://www.jasst.jp/symposium/jasst13tokyo/pdf/A2-4.pdf
今回のワークショップで扱った範囲は次の通りで、ワークのグループ毎に、みんなで納得できることをポイントに実施。
　<1>テスト観点出し
　<2>テスト観点図の作成
　<3>テストコンテナ（テスト観点をグルーピングしたもの）の作成

「みんなで納得できること」というのがミソで、これでグループ全員が戦力になれる、誰でも作ったテストについての質問を受けた時に答えられるという状態になります。

　<1>テスト観点出し
　・面白い！　人と話すと自分になかった視点が出てくる。

　<2>テスト観点図の作成：出した観点をツリー上に整理していく

　・<1>で出した観点を、うまくツリーに整理するのが難しい。
　・なんとなく気になったからあげてみたとか、うまく階層化出来ない観点がいる。
　・ツリー状にすると抜け漏れやまとめられるものが出てくる（InがあるけどOutがない、共通化できる奴はどれだ？）

　<3>テストコンテナの作成：ツリーにした観点をさらに整理、分割して意味のあるグループにする

　・テスト計画ともリンクできるようにコンテナを作成
　　→最初に確認したい基本的なパスを通すコンテナがないね！ということに気づく
　・コンテナ間で依存関係のある奴はどれだ？
　・コンテナで先にやっといたほうがいいやつどれだ（バグ出たときに手戻りがでかいやつ）

というようなことを、ワイワイ話しながらやるのでとても楽しかったです。納得感大事。

ちなみに「最初に確認したい基本的なパスを通す」ことを、うちではなんとなく「疎通テスト」と呼んでいるけど、ご一緒した他社の方のところだと「疎通テスト」はpingが通ることを指すんだそう。用語の共通認識って大事ですね。

テストと人工知能
人工知能を使ったシステムをテストする話と、人工知能やディープラーニングを使ったテストツールのお話でした。個人的にはMagic Potという画像認識などの技術を使ってる自動テストシステムが面白かったです。テスト実行は今後AIとかが活躍する分野になり、テスト設計や分析などのスキルが増す求められると、最後の方で話されてましたが、これは今後のスキルを考えるうえで重要ですね。

「品質保証活動の本質」
品質保証なんて言葉のないころから品質保証活動やってこられた方の話なので重みがあって面白かったです。最近はプロジェクトでデータを扱うことをやっているので、「データは提供してくれる人のために使うべき」って話には考えさせられました。自分は割とデータ取りっぱなしとか、取る目的整理できてなかったりは自分もやってしまいがちなアンチパターン。そこちゃんと考えないと品証も開発も苦しいだけですね。この点は、自分の課題です。

WACATE2016冬「あなたのためのアラカルト」に参加してきました（2日目編）

遅くなったWACATE感想2日目編です。

2日目もよく晴れて絶好の勉強日和！発表資料公開されているものはおいおい追加しておきます。

12/18(日)
-■BPPセッション「WACATEによる加速事例〜加速が止まらさんない世界」（ときわ　かおり）
　＜感想＞
WACATEに参加してからの加速の様子や、実際に現場で何に取り組んでこられたかがよくわかるセッションでした。WACATEの半年に一回ってペースは、自分の振り返りやらアウトプットのタイミングとしてちょうど良さそうな印象を受けました。

-■問題を捉えよう　〜自律の入口へようこそ（常盤　香央里）
＜概要＞
　自律して問題を把握し、解決につなげていくための手法を、SaPID法に沿ってやってみるセッション。問題を捉えることから始めれば解決に近づくというところがポイント。

＜感想＞
ワークで、実際に自分が感じている問題を一つ書き出す、その後「それで何が困るのか」を深めてみるというのをやってみるのが、すごくよかったです。自分が問題としてパッと挙げられるものは、大体単なる事象なんですね。それによって本当に困ってることに近づくためには、さらなる問いが必要。

-■忘れたころにやってくるテスト技法　〜組み合わせテスト〜（藤原 洋平）
＜概要＞
１．「組み合わせテスト」
　　組み合わせによる爆発
　　　→テストで確認したいポイントは抑えつつ、テストケース数を削減したい

　　※用語の確認
　　　因子：入力の条件、組み合わせの要素
　　　水準：因子がとりえるパターン
　　　有則：因子が動作や結果に影響する関係を持っている
　　　　　　仕様上のかかわりがある
　　　無則：結果には影響しない
　　　禁則：実現不可能な因子の組み合わせ

　　２．技法の種類
　　　＜有則系＞
　　　ディシジョンテーブル
　　　原因結果グラフ
　　　CFD
　　　ドメイン
　　　＜無則系＞
　　　ペアワイズ
　　　直行表
　　　クラシフィケーションツリー

　　　(1)ディシジョンテーブル
　　　(2)ペアワイズ
　　　　ツールの紹介
　　　　・PICT
　　　　・PictMasterOA
　　　(3)直行表
　　　　直行表の選び方
　　　　　・テストの目的
　　　　　・コスト・費用対効果
　　　　　・因子・水準が洗い出されていること

＜感想＞
こちらもワークで直行表、ペアワイズをやってみたのがよかったです。設計技法は会社でも取り組んでるので、自社のテストチームで同じようなワークをやってみようと思ってます。
ただ、未だによくわかってないのが直行表、ペアワイズってどんな条件のシステムに向くんだろう、というところです。以前ペアワイズを使ってみようとしたんですが、禁則が多すぎるなどでうまく使えず、結局手でテスト項目を作ったことがありました。一緒にワークしたメンバーに聞いても、同じ疑問を持っていました。もうちょっと経験が必要なのかな。

-■伝わる報告書への第一歩（小池 香織)
＜概要＞
自分の取り組み、作業などをきちんと伝えるためには、どうしたらよいかというセッション。ポイントとしては、相手が何を知りたいのか、報告先がどう思うか、に注して書くこと。事実、推測、感想の3点は分けて書く。

＜感想＞
これもワークで行った、悪い報告書の例の訂正が面白かったです。自分の書いた文章だと悪い点に気づかないこともありますが、人の書いた文章だとよく見えるなーと。我がふり直さなければ！

-■僕らの僕らによる僕らのためのBOK等の解説（朱峰　錦司）
　1.BOKとは
　　特定の専門領域についての知識体系
　　→BOKガイドでまとめられている

　　例）SWEBOK
　　　　SQuBOK
　　　　PMBOK
　　　　REBOK
　　　　BABOK
　2.本日のターゲット
　　SWEBOK　ソフトウェアエンジニアリングについての知識体系。辞書的
　　SQuBOK　ソフトウェアの品質についての知識体系。辞書的
　　PMBOK　プロジェクトマネジメントについての知識体系。
プロセスと入力・出力成果物を整理している
　　　　　　→プロセエス定義のひな型にできる

＜感想＞
3つのBOKの概要を1時間で紹介してもらう、ちょっと駆け足気味なセッションでした。でも、各BOKの雰囲気はつかめたし、実際にBOKガイドを読んでみようという導入になりました。自分の場合は積ん読してるSQuBOKからですね。

-■シン・テストエンジニアのキャリアについて（山本　くにお）
甘口モードの資料はこちら。辛口版は参加者だけのお楽しみ。

「シン・テストエンジニアのキャリアについて： Q裏 甘口」 wacate_2016_winter from 久仁朗 山本(旧姓 村上)

＜感想＞
「QA・テストが日本の産業を救う」という熱い想いのもと、今までのキャリア失敗談を紹介してくださるセッションでした。「QA・テストが日本の産業を救う」は自分もそう思ってます。

■全体を通して
自分の興味が広がったり、日頃の疑問点を話せたりですごく楽しい二日間でした。ソフトウェアテストのプロセスに沿って広く浅くできて、自分の中でのプロセスの理解が整理でき、最初のWACATE参加が冬で自分にとってはよかったと思ってます。夏も行きたい！
夏は6／17,18だそうです！

WACATE2016冬「あなたのためのアラカルト」に参加してきました（1日目編）

12/17(土)、18(日)に行われたWACATE2016冬「あなたのためのアラカルト」に参加してきました！

会場のマホロバマインズ三浦からは富士山がばっちり！
北は東北から、南は九州まで、ソフトウェアテストに関係する人が集まってわいわいやってるのは楽しかったです！
特にWACATEはWorkshop for Accelerating CApable Testing Engineers と銘打ってるだけあって、各セッションでワークができるのがよいですね。班のメンバでグループワークなんかすると他社の方のやり方とか、自分が見えてなかった点とかが見えてきます。で、「あ！この考え方真似させてもらおう」ってポイントが見つかるのが嬉しい！

というわけで、各セッションの振り返りと感想です。

-「テストは料理だ！」（竹花　和裕）
資料はこちら。

テストは料理だ！テストのレシピを見てみよう #wacate from 和裕 竹花

＜概要＞
料理に例えて、テストプロセスとは何ぞやを説明してくれたセッション。
テストに限らず、プロセスを把握しているということは
→全体を抽象化して把握できている
→全体を把握して自分の仕事を設計することができる
と　いうわけでプロセスはとても重要。

JSTQBのテストプロセスはこんな感じ。
　(1)テスト計画
　(2)テスト分析
　　「何」をテストするのか
　　テストするものの理解
　　どんな振る舞いか
　(3)テスト設計
　　「どのように」テストするのか
　　テスト方針の整理
　　どの技法を使うか
　(4)テスト実装
　　実行の方針を決定
　　設計で決めたテスト技法を適用
　(5)テスト実行
　(6)レポート・評価
　　ステークホルダーが理解できる用語で書く
　(7)終了作業
　　振り返り

＜感想＞
プロセス全体について説明してもらい、その後の導入になってよかったです。ここではワークでテストプロセスの(1)〜(7)まで、自社でどのような作業とアウトプットがあるか、PFDで整理してみるというワークをやりました。他社で、どのようなプロセスの分け方をしているか、各アウトプットがどうなるのかが見られて興味深かったです。　
自分としては、
　分析：「テスト観点」
　設計：「テスト項目」
　実装：「テスト手順」「テストスクリプト」
が出てくるイメージです。ただ、分析と設計についてはちょっと迷ってるところもあるので、もうちょっと整理したいですね。

-見積もり入門　規模ってなんだろう？（福良　智明）
資料はこちら。

規模の見積もり WACATE 2016 winter from Tomoaki Fukura

＜概要＞
見積もりは、ステークホルダーに適切な意思決定をしてもらうための判断材料の提供を行うもの。
まずは、数値ができるものをもとに規模を見積もる
→規模をもとに工数や費用、工期の見積もりを行う。

規模の見積もりの方法は、
　(1)LOC
　(2)FP法
　(3)ストーリーポイント
の大きく3つ。FP法が、ユーザ視点になっている、国際的に標準化され人に依存しない、という点で広く使われている。ワークは実際にFP法で見積もり。

＜感想＞
見積もりは普段あまり触ってない分野なので、新鮮でした。FP法はあくまで、ユーザ視点なので、ユーザに見えない部分が見積もりに出てこないというのが自分が見事にミスってた部分でした。ワークでやってみて実感しましたが、初期段階と、ある程度設計が進んだ段階で見積もりずれそうですね。なんとなくですが、初期段階で見えてないことがありそうな感じがしました。

-幅広なテスト分析ができるようになろう（山口　寛子）
資料はこちら。

幅広なテスト分析ができるようになろう from scarletplover

＜概要＞
テスト分析はなぜ必要か、どのように行うのかを紹介してくれたセッション。
　１．テスト分析とは
　(1)「何」をテストするか決める
　(2)メリット
　　テストの抜け漏れ防止、テストのやりすぎ防止、テスト対象とテスト要求の紐づけ
　(3)プロセス
　　・テスト対象分析
　　・テスト要求分析
　２．テスト対象分析をやってみよう
　(1)テスト対象分析
　　・準備
　　　<1>テスト対象が記述されたドキュメントが存在するか
　　　<2>ドキュメントはレビューや、修正(適宜)されているか
　　・やり方
　　　<1>3色ボールペン
　　　<2>インプット資料の目次
　　　<3>6W2H
　　　　開発　Why、What(仕様)、How to、Whom、How much
　　　　顧客　When、Where、to Whom
　(2)テスト要求分析
　　・FV表
　　　テスト対象分析の内容から、ユーザストーリを挙げる
　　　　・目的内容
　　　　・検証内容
　　　　・技法
　　・品質特性から展開
　　　ISOの製品品質。非機能要件の抽出にお役立ち
　　・Ostrandの４つのView
　　　ユーザView
　　　仕様View
　　　バグView
　　　設計View
　(3)その他
　　・ゆもつよメソッド
　　・VStep

＜感想＞
自分としては、今回最もためになったセッション。6W2Hのワークをやってみると、あのとき出してしまったバグは、この分析やっておけばある程度防げたんじゃなかろうかと思いました。これと2日目のテスト技法のワークは、仕事でも力を入れようとしている部分にちょうど合ってます。ちょっとアレンジして社内でワークやりたいな。

• 普段の活動がどのように役立っているか説明できますか？

　「それ役に立つんですか？」への備えとして　（森崎　修司）
SQiPにみんな論文出そうぜ！というセッション。

• ディナーセッション

おいしい夕食を堪能しながら、テストトークで盛り上がる。抽選会の商品で直行表下敷きがあったのに驚きました。ちょっと欲しかったｗ

• 分科会

WACATE初心者グループに参加してきました。「開発側から見たテスト側がどう見えるか」、とか「何をテストしてほしいのかをどう引き出せばよいのか」とか面白い話題が色々。

なんだか、長くなってしまったので2日目編は別途投稿します。