開催レポート
第１回（2015年10月3日）
初開催なので、はじめは参加者が増えるか不安だったのですが当日は19人の方に参加いただきました。
会場での反応や懇親会での会話からは、開催してよかったのではという印象です。
ツイートまとめはこちら。次回はもっとツイートも増えるといいなあ。
第１回盛岡ソフトウェアテスト勉強会ツイートまとめ - Togetterまとめ
開会のご挨拶〜ことはじめ
自分が担当したセッションです。
ちょっと会がスタートしてから話しっぱなしだったので、もう少し、勉強会の中で参加者間の交流を持てるコンテンツがあれば雰囲気も柔らかくなったかなと反省しています。
内容としては、自分が入社してQAに配属され、1年目〜3年目の社会人生活で学んできたことについてお話ししました。
皆さんがソフトウェアテストについて学ぶにあたって、少しでも参考になれば幸いです。
質疑応答
Q1. プロセスのレベルの話があったが、そのレベル３とレベル４の具体的な例があれば教えて欲しい。
A1. レベル３は、社内やプロジェクトで定められたプロセスや規格に沿って作業すること。そうは言っても実際はその定義されたプロセスの通りに実施することはプロジェクトによって困難であることがある。そのため、このプロジェクトではこの規格のこの部分をこう読み替えよう、というようにテーラリングを実施して、プロセスを変更して実施するのがレベル４。このレベルで、清水吉男氏が提唱するPFD（プロセスフローダイアグラム）といったツールも使用することがある。
Q2. テスター VS 開発者 の話で対立したのは、「アプリケーションとしてこうあるべき」というテスターの考えと、「開発者の立場で考えて決定した仕様」との齟齬が理由になっているとのことだが、「アプリケーションとしてこうあるべき」という意識は全社あるいはプロジェクト単位で統一されているのか。
A2. 全社レベルではできていないと思う。プロジェクト単位ではできているところもある。そういった現場のプロダクトは比較的品質も良い印象がある。
Q3. 今回発表したような内容に気づけたのは、会社で教わったからなのか、それとも社外での勉強会で教わったからなのか。
A3. 両方あると思う。会社の先輩もベテランの方が多く高いスキルをお持ちだが、一方で会社の中で勉強する機会は限られていると思う。なので、自主的に勉強会などで学んだ部分も多くある。
「ソフトウェアテストチョットデキタ！- テスト設計コンテストから学んだこと -」
テスト設計コンテスト2014で優勝した、チーム「しなてす」で当日のプレゼンを担当した佐藤さんのセッションです。
実は、関東の勉強会でも優勝報告のプレゼンは行われていたのですが、今回、盛岡版に大幅にアップデートをかけてくださいました。
テストに関するかなりの情報がつまっていて、テスト設計コンテスト出場者はもちろん、テスト関連の学習をされている方は必見の内容でした。
質疑応答
Q. 今回の発表内容で言及されていたテストに対する意識は、全社レベルで統一はできているか？
A. できていないと思う。こういったテスト関連の勉強会でお会いする方々の間では、ある程度常識といったレベルで普及してはいる。しかし、現場にずっとこもっていて外の文化を知らないエンジニアなどは、テストに対して（発表の中で言及したような）意識を持っていないことがある。
このズレを解消していくのは今後の課題だと感じている。
「テスト自動化の現場から ～落とし穴に気を付けよう～」
株式会社ウェブレッジ様から、テスト自動化アドバイザーの浦山さんにお越しいただきました。
こちらは長崎の勉強会（8月12日 長崎SWQuality&DevelopmentGathering2015(長崎県)）の 再演だったのですがこちらも、盛岡発表版としてアップデートしていただいていました。
参加者の方で自動化に取り組んでいる方は少ないようでしたが、今後自動化を進めていくにあたって参考になる情報だったのではと思います。
質疑応答
Q1. ランニングコストとイニシャルコストの話があったが、具体的にどのくらいのコスト比にすれば良いなどノウハウがあれば教えて欲しい。
A1. コスト比といった具体的な数値は示せないが、ランニングコストができるだけかからないようにする工夫は重要だと考えている。例えば、メンテナンスが頻繁に必要になる機能は自動化のスコープから外すなどといった方法がある。
Q2. 組込み分野におけるテスト自動化が思うように進まず困っている。導入のアドバイスがあればいただきたい。
A2. 自分はドメインが組込みではないのであまり詳しいアドバイスができないが、過去のシステムテスト自動化カンファレンスでは、組込みドメインのエンジニアの発表もあったので参考になると思う。
「LTセッション（"Bug Advocacy"を読んで）」
今回は希望者が少なかったこともあり、バグ票ワーストプラクティスのすずきしょうごさんに少し長めのLT（？）をしていただきました。
内容は洋書"Bug Advocacy"の概要についてです。
この本は珍しく「悪いバグ票とは何か」にフォーカスして述べられており、開発者とテスターとの間のコミュニケーション改善に役立つのではと思います。
自分はすこし中身を見せてもらったことがあるのですが、洋書とはいってもそこまで文章がぎっちり詰まっているわけではなく比較的読みやすそうな印象を受けました。興味のある方は調べてみるとよいかもしれません。
「ソフトウェアの高品質保証とテスト －機械制御関連ソフトウェアの開発を通じて－」（岩手大学 金 天海 准教授 招待講演）
金先生の研究紹介と、そこで困ったバグについてご講演いただきました。
金先生の研究テーマであるロボティクスは、参加者のドメインからはやや外れたものであったかもしれません。
ただ、研究というのは本質的には問題解決のプロセスであるため、そのアプローチ手法から業務改善のヒントを得ることもできるのでは、と私は思います。
また、今回紹介くださった「こんなバグが出て困った」というお話を聞いて、
研究分野におけるソフトウェアテストというのは、案外需要がありつつもまだ開拓されていない分野なのではと思いました。
研究において、ソフトウェアを作成することは目的ではありません。その点が、業務でのアプリケーション開発と大きく異なります。研究においてソフトウェア開発は、目的ではなく過程なのです。
しかしながら、その過程において解決困難なバグが発見された場合、研究の進捗に深刻な影響を与えうることは想像に難くありません。
そういった面をサポートするのを、ソフトウェアテスト業界が担えるととても良いのかな、などと頭の中で考えていました。
質疑応答
Q. 水上の流体の制御において、入手すべきデータが漏れてしまう（入手できない）心配はないのか。
A. 完全に制御することは難しいので、大まかなレベルで制御することを考えた。ただし、さすがにGPSのような10mレベルの誤差が生じるのではまずいので、今回発表した位置特定の仕組みを用いた。
「閉会のご挨拶」
ちょっと時間が押し気味だったので、すこし巻き気味でのクロージングでした。
私がこの勉強会を主催したのには当然理由があります。それは簡単に言えば地元に貢献したいからであり、そのきっかけは東日本大震災でした。
自分自身は内陸に住んでいて大した被害は受けませんでしたが、その翌年に就職活動をする中で、地元に貢献することについて深く考えました。
今自分は関東で働いてはいますが、ここにいてもできることはきっとあると思っています。
盛岡で働くことは当分なさそうなのですが、それでもこの勉強会は来年も開催します。
幸いお手伝いくださるという方も何名かいらっしゃいます。力を合わせて進んでいこうと思います。
懇親会
懇親会も非常に盛り上がりました。当初4,000円のコースでしたが、500円追加してベアレンビール（盛岡で人気の地ビール）を飲めるようにしました。隠れメニュー（？）の「ハーフ＆ハーフ」も頼んで、みなさん満足いただけたようです。
今回は現地（岩手県内）から参加の方が多く、講演者の佐藤さん、浦山さん（出身は盛岡市）、自分（出身は盛岡市）は関東在住だったのでなかなか交流できない方と交流することができてとても良かったです。勉強会についてもぜひ第２回をやりましょうということで、お手伝いしていただける方も出てきました。来年は今回の反省を生かして、さらに充実したイベントにしていきます！
以上イベント内容について簡単にまとめましたが、皆様の参考になりましたら幸いです。
このたび応援してくださった方々、参加してくださった方々に改めて御礼申し上げます。ありがとうございました！