JaSST'17 Tohoku レポート
こんにちは。はじめまして。
JaSST'17 Tohoku実行委員のささきです。
大分間が空いてしまいましたが、2017年5月26日、JaSST'17 Tohoku 無事開催することができました。
地元からも遠方からも多くの方にご来場いただき誠にありがとうございました。
そして、基調講演と事例発表をしていただいたみなさま。
貴重なお話しありがとうございました。
私自身も勉強になるお話が沢山ありました。
今回のblogでは、そんなJaSST'17 Tohokuのレポートをお送りしようと思います。
なお、当日のスライドは下記に上がっておりますので、
今回参加できなかった方、気になるセッションがありましたら是非スライドをご覧になってください。
http://jasst.jp/symposium/jasst17tohoku/report.html#openning_s
今回のJaSST'17 Tohokuのテーマ :
「テスト分野における人財育成 ～テスト技術者は砕けない～」と
いうことで、育成についての基調講演、事例発表、ワーク等を通じて、
育成についての悩みを共有し、解決のきっかけを見つけて持ち帰って貰いたいということで、このテーマを選定いたしました。
■基調講演
「テストの極みを目指して
～さあ、理想に近づくための一歩を踏みだそう！～」
山崎 崇さま（ベリサーブ）
テストオペレーターからテストのプロフェッショナルへの最初の一歩を踏み出すためのお話をしていただきました。
(印象に残ったワード)
- テストの価値は情報提供
- 早い、安い、旨い
- テストをこなすことにそんなに意味はない。適切な情報を適切なタイミングで提供することに意味がある。
- ほかのエンジニアと違ってテスター≠テストの専門家ではない。テスターはテストの専門家であってほしい
- Professional Tester's Skill-Space (TESTSKILL/ITSKILL/SOFTSKILL/DOMAINSKILL)
- テスターは開発を加速させるための協力者というマインド
- 最初の一歩を踏み出すために重要な3つのこと
①テストの全体感を持つ
②ロールモデルを見出す
③成長へのモチベーションを持ち続ける
①テストの全体感を持つについて
- テストの全体感を持つための3つの軸(テストレベル/テストプロセス/テストタイプ)
- 特に重要なのがテストケースを作るまでのイメージを持てること
- (よくあるパターン)テスト設計技法を勉強したので、実務に適用しようとしてうまくいかない。テストベースに対していきなりテスト設計技法を使うのは失敗フラグ、テスト設計技法を使うためにはいろいろな前準備がある。いきなり使うことはできない。
②ロールモデルを見出すについて
- 大まかな方向性を意識する(技術トラック/マネジメントトラック)
- テストの専門性には様々な方向性がある。具体的にイメージできる憧れの人を持とう。
- セルフデベロッププランを作ろう
③成長へのモチベーションを持ち続けるについて
- 成長は目に見える形で測れて実感できることが大事。
- 社外に飛び出す
(感想)
沢山時間をかけ推敲してくださったスライドは圧巻の一言。
テスターは開発を加速させるための協力者というマインド というところにすごく納得しました。私も目指しているテスターの姿です。対立ではなく、互いに協力できる関係でありたいです。
成長へのモチベーションを持ち続けるために社外に飛び出す についても共感しました。広い世界に飛び出していろいろな人と出会うことはとても刺激になりますよね。
事例発表1
「インキュベート修了者からの変化
～テストエンジニアへ進化するための成長プロセス～」
土岐 しのぶさま （ウェブレッジ）
ウェブレッジさんで実施している、社内教育制度「WRキャリアフレームワーク」と、成長プロセスについてお話しいただきました。
(印象に残ったワード)
- テスト設計研修は「教わる」のではなく「考える」研修
- 基礎編と応用編があり、
基礎編 : 仕様書に書かれていることを整理する
応用編 : テスト観点を洗い出し、構造化する(ワークを実施する)
(感想)
テストを極めるための多彩なキャリアパスがあることがとてもうらやましい。私はテストの研修というのを受けたことがほぼないため、こんな研修をうけられるウェブレッジの社員の方は幸せだなぁ。。。と、終始考えながらお話を聴いていました。
事例発表2
「テストエンジニア版RPG風スキルマップ」
根本 紀之さん (JaSST東北実行委員)
面倒なスキルマップを楽しくつけられるRPG風スキルマップの発表です。
(印象に残ったワード)
- 「学習」を手助けするのが「育成」
- テストエンジニア版RPGスキルマップ
- ロールは 戦士、魔法使い、商人、僧侶、道具使い、盗賊
- スキルマップは自分たちで再構築してみるとよい
- 成長を実感させる方法の一つに褒めることがあるが、タイプによってほめ方を変えるとよい
- タイプは4種類(達成者/探検家/社交家/殺人者)
- 達成者 : 何かを達成することに喜びを見出すタイプ
- 探検家 : 新しいことに挑戦したいタイプ
- 社交家 : 人とのコミュニケーションに重きをおくタイプ
- 殺人者 : 勝ち負けなど競争に重きをおくタイプ
(感想)
スキルマップは実施するのに時間がかかったり、つけることが難しかったりと、必要なことはわかるけどちょっと面倒なイメージを持っていましたが、RPG風のスキルマップを見て「こういう方法もアリなんだ！」と目から鱗でした。
簡単につけられてしかも楽しいところがとても気に入ってます。
事例発表3
「WACATEにおけるワークショップ開発の流れ」
朱峰 錦司さま （NTTデータ）
スライドタイトルは「社内および社外活動におけるテスト研修開発・運営事例」ということで、WACATEのお話と、朱峰さんが業務で携わっている研修開発・運営のお話をしていただきました。
(印象に残ったワード)
- 研修の役割とは学んだことを現場に生かすために間を埋めるもの
- (事例1) 自社グループ向けに実践的なテスト設計研修を開発
- 研修の対象者はテスト専任の方はまれで、基本的には要求定義～実装に関わっている方。
- 2日間で完結するオールインワン。基礎編と応用編。
- 応用編では詳細な仕様書を用意して実施している。
- (事例2) 「WACATE」の運営
- テスト設計に加え、素振り・実践がしにくいテスト分析をグループで演習できる場を提供
- テンプレートを用いたセッション企画
- 開催回ごとにホットな時事トピックを扱う
- NextStepは中級者・上級者向けの施策
- チームでの振り返り、プロジェクトをまたいだノウハウの共有・事例共有
- シンポジウムやカンファレンスでの情報共有・事例発表
- 自身・自社が扱うドメインになるべく近い題材にもとづいた実践的な研修が必要。
- 座学だけでなく、実際に受講者がその場で手を動かしてテスト設計をする演習を盛り込むことがポイント。
(感想)
テスト設計の勉強をしてもそれを業務に生かせない、という悩みは実際によく聞くので、学んだことをどう使うかを知れる研修というのは、素晴らしいと感じました。
私自身はテストのことをよく分からないままテスト業務に放り込まれて、なんでこんなことやっているんだろう?と思っていたことを、テストのことを勉強するうちに「あ、だからこんなことやってるんだ!」と理解してきたのでとても時間がかかってしまったのですが、知識を得て、それを業務に近い形で体験して、実際に業務に入れるというのは
自分がやってきたことをとても短い時間で理解できるのだろうなと思い、素直ににうらやましいと思いました。
その分研修を実施するまでの準備は苦労は多かったと思います。
事例発表4
「テストエンジニアとしてキャリアを積み重ねて見えてきたこと
～ なにを大切にし、なにを変え、なにを変えなかったか ～」
山本 久仁朗さま （アカツキ）
多くの企業を渡り歩いてきた山本さま自身が感じた、評価されるスキル、ポイントと
普遍的なスキルについてお話し頂きました。
(印象に残ったワード)
- 現場の悩みで「テストのキャリアがない」、「テストが評価されない」、「キャリアアップの実感がない」
- 組織ごとの評価ポイントには加点式/原点式と安定/変化がある。
- クラシックなテスト技法は新しい会社では、意外とちゃんとやってない。
- テスター・テストエンジニアの評価が効果的に行われていないのはなぜか
- 評価するには可視化＆合意が必要。つまり「説明責任」
- 良い技術・手法が広まらないと業界損失
- 評価される立場の人は組織カルチャーを認識し、スキルアップし、可視化・合意する
- 評価する立場の人は必要スキルを再確認、組織特性を踏まえた評価方法を検討。
- 評価の先には日本のソフトウェア産業の未来がある
(感想)
山本さんのお話を聞いていると、あ、テストってこんなにすごいものなんだ！そんなすごいことを自分たちはやっているんだと思えるので、すごく前向きになって、最後には「あー、明日からもテスト頑張らなきゃな」という気持ちになります。
テスター・テストエンジニアの評価がきちんと行われるための説明責任と評価方法の検討を今後自分も頑張っていかないといけないな。と思いました
ワークショップ
「状態遷移図(表)を作成してみよう」
状態遷移図の作成のワークを参加者全員で行いました。
作成したものは近くの席の人と互いに見せ合って確認しあいましたが、ほかの方の状態遷移図を見ると自分の考え方との違いが発見できて勉強になりました。
お題が皆さんが想像しやすい内容だったらか、ワイワイと盛り上がりながらワークに取り組んでいただけていたように思います。
お悩み相談会
今回の基調講演と事例の発表者の方々を参加者で囲みながら、参加者の日頃の疑問に答えたり、質問をしたりする時間を設けました。
どこの集まりも盛況で、発表者と参加者はもちろんですが、参加者同士で交流している姿も見られとてもよかったと思います。
■全体を通じての感想
アンケートの結果から参加者の方の満足頂けたのかな、ということが感じられたのがとても嬉しかったです。
テスターのキャリアについてどの現場でも結構悩んでいて、でもそのことについて話を聴ける場というのは少ないと思うので、参加者の皆様の今後のテスト活動において参考になる内容を提供できたならうれしいです。
今回参加された方は、是非次回もご参加いただけると嬉しいですし、参加していただけるイベントとなるよう実行委員一同頑張ってまいります。
今回は参加できなかった、という方も、次回は是非参加していただけると、とてもうれしいです。
それでは、みなさまありがとうございました。
JaSST’17関西 参加レポート
2017年6月23日に兵庫県いたみホールで開催されたJaSST’17関西に参加できたので，レポートします。
公式URL：JaSSTソフトウェアテストシンポジウム-JaSST'17 Kansai
今回のテーマは「アイ，テスト」で，AIをテーマとして開催されました。
募集人数の１００人は満員になり，スポンサー参加を含めると１１０人と，東北の２倍の規模でした。テスト業界におけるAIへの関心の高さがわかりますね。
これだけ大規模なので，関西の実行委員の皆さんの準備は大変だったんだと思います。お疲れ様でした。
（注）最新技術がテーマなためか，予稿集が無くプレゼン資料の一部が公開されていません（3A問題発見セッション，私が参加しなかった3B-1，3B-2と招待講演のみ公開されてます）。
自分の取ったメモと記憶を基にしたレポートのため，誤り等があれば訂正いたします。修正コメント等をいただければ幸いです。
１．基調講演１「人工知能開発の問題点と品質保証について」細川宣啓さん（日本IBM）
印象に残った点
細川さんは最初に，AIによるプレゼン資料の自動編集機能をデモしてくれました。と言うのは嘘で，「AI」と聞くと無条件に受け入れてしまう我々への警告から基調講演はスタートしました。
・テストとAIの話題は，主に以下の二つに分かれます。これは基調講演２の増田さんも共通の意見でした。
・AIそのものをどうテストするか。
・AIによってテストがどう変わるか。
・AIに関する世界の動向について
細川さんの講演ではAIに関する世界の動向の説明があり，アメリカ議会においてスーパーAIは人類の脅威になるか，真剣に議論している事などを紹介してくれました。（その他にもAIに関する様々な話題がありましたがメモしきれませんでした）
・AIが人間に追いつくことができるか
今の時点では，AIが人間の脳と同等を処理を行うには，東京ドーム1.8個分のCPUコアと原発２基分の電力が必要であり，当分，人間に追いつくことは難しいのではないかとのことでした。
・AIそのものをどうテストするかについて
AIの場合，期待値が予測できないため，テストが難しい。思考ロジックが学習により成長するので，答えが一定ではなく，テストが難しいとのことでした。
・アメリカで発生した自動車事故（失敗事例）について
アメリカの事例で，画像認識による自動車の自動運転において，並行するトレーラーの色が背景の空の色と近く誤認識を行い，事故を起こしたケースが紹介されました。画像認識による自動運転では，前の画像と後の画像の差異を見て，背景なのか他の車なのか判断しているため，ほぼ同じ速度で走る背景と同じ色のトレーラーを誤認識してしまったそうです。現時点では画像認識だけの自動運転は難しく，赤外線センサー等を併用する必要があるとのことでした。
・AIの軍事転用と学習データの流出防止について
AIを使ったドローン兵器の話もあり，AIドローンによる攻撃（自爆）後に，ドローンAIの学習データを盗まれない様にする研究も行われてるとのことでした。
・AIシステムの課題として，以下の点を上げていました。（資料上４点あったのですが，１点はメモしきれませんでした）
①学習データのデータポイズニングをどう防ぐか？（不正なデータで学習結果が使えなくなる。例：会話AIに対して差別的発言を繰返し，AIが差別的な発言をするようになる等）
②学習アルゴリズムに関して，入力データの偏りをどう防ぐか？そもそも偏らないデータを作れるのか？
③機械ベースの意思決定に関して，認識や分類の誤りをどう防ぐか？
・細川さんの現在の取り組みについて
細川さんが今，取り組んでいるAI技術として，昔の特撮アンドロイドヒーロー（ギター弾くやつ）の様に，普通の学習結果を出力する『良心回路』と，今までのNG情報から「AIの理解は失敗していないか？不快な結果ではないか？」等のチェックを行う『悪魔回路』の出力をあわせて判定する仕組み作りに取り組んでいるそうです。『悪魔回路』の処理は『良心回路』に比べて２０倍程度の処理時間がかかるそうで，（良心回路の出力を悪魔回路が否定することで）答えが出ない可能性もあるそうです。現在のAIの課題を解決する提案として，とても面白い考え方だと思いました。
・最後に，細川さんが述べていたのが，AIは手段であり「結局，何がしたいのか？」によってAIが適しているのか，他の技術が適しているかである。「AIを使う」のが目的ではないので，「何をしたのか」をよく考えて欲しいとのことでした。私も手段と目的が逆転しない様にしたいと改めて思いました。
受講しての感想
・基調講演にふさわしく，AI技術以外にもAIに関する世界の動向など，幅広い話題にあふれた楽しい講演でした。懇親会で細川さんご本人に確認したところ，後日一部を除いて講演資料が公開されるそうです。公開されたら，色々調べてみたいと思いました。
（余談ですが，懇親会で細川さんと にしさんの掛け合いを見ることができたのですが，とても面白くて時間を忘れてしまいました。細川さんと にしさんが同じ懇親会に居る時は，お二人の近くに座ることを強くお勧めしますｗ）
２．基調講演２「人工知能技術を利用したアプリケーションの開発とテストについて」増田聡さん（日本IBM）
印象に残った点
・増田さんの基調講演も以下の２点を中心に話されていました。
- AIそのものをどうテストするか。
- AIによってテストがどう変わるか。
・AIの処理構造について
遊園地にある音声認識アプリを例に，AIによる日本語認識と回答選択方法を丁寧に説明してくれました。AIの知識が無い私でも，とても分かりやすいものでした。
・今回の例（遊園地の音声認識アプリ）について
遊園地の音声認識アプリは，来場者が出す質問「ゴーカートはどこにありますか？」を認識し，来場者へ「○○にあります」と回答を行うアプリです。
・言葉の類似度の判断方法について
「ゴーカートはどこにありますか？」と「ゴーカートはどこですか？」は似た言葉であり，文章の類似度を測るのにコサイン類似度を使用します。
・判断処理例について
文章を形態素解析し単語に分解して，類似度を判断します。例えば，以下の３つの文書を分解すると
（a）ゴーカート / は / どこ / に / あり / ます / か？
（b）ゴーカート / は /どこ / です / か？
（c）入場料 / は / いくら / です / か？
<それぞれの文章と出現する単語表>
|
ゴーカート |
は |
どこ |
に |
あり |
ます |
か |
です |
入場料 |
いくら |
|
|
（a） |
〇 |
〇 |
〇 |
〇 |
〇 |
〇 |
〇 |
|||
|
（b） |
〇 |
〇 |
〇 |
〇 |
〇 |
|
||||
|
（c） |
〇 |
〇 |
〇 |
〇 |
（a）と（b）のコサイン類似度は 0.676
（b）と（c）のコサイン類似度は 0.3
になるそうです。この場合（a）と（b）が同じ意味と判断して回答します。
また，「ゴーカート」や「入場料」などの特徴的な言葉を「特徴ベクトル」として重み付けをするそうです。
・判断までの処理内容と，目標成功率の実現方法について
来場者の発言は，以下の処理を行い，AIが回答を行います。
①周辺環境（マイク等）→ ②（音声の）テキスト変換 → ③テキスト分類 → ④テキスト音声変換
最終的な成功率を80％とすると，①～④の各工程の成功率は95％が必要となります。
それを少しでも上げるため，②，④で特定キーワードをまとめることで，成功率を上げています。
NG例として
- 「ゴーカートはどこにありますか？」を「豪華はどこにありますか？」に②テキスト変換（誤変換）すると，回答が「イベンドは７月からです」になります。
- 「ゴーカートはどこにありますか？」を「ゴーカードはどれにありますか？」に②テキスト変換（誤変換）すると，回答が「ゴーカートの持ち時間は15分です」になります。
・AIに対するテスト方法について
AIに対するテストは交差検証法を使うそうです。具体的には，学習予定のデータの一部を残しておき，テストデータとして使用し，期待する回答が返るか検証するそうです。
テストデータを学習させると100％期待回答を返してしまうため，学習しないデータをテストに使うそうです。
・AIの場合のV字モデルについて
AIの場合は，V字モデルの右側は，V字と言うより繰り返しになるそうです。
・IBM Jeopardy challengeについて
IBMのAIがアメリカのクイズ番組に挑戦した「 IBM Jeopardy challenge 」の成果について，IBMは2012年に17の論文を公開しているそうです。なかでも興味深かったのが，クイズ番組は対人戦なので，AIが戦略を考え，終盤になってくると正解率が低くても，回答率を上げて得点を稼ぎに行くといった工夫を図っていたそうです。
（https://www.ibm.com/watson/jp-ja/quiz/index.html）
・AIを使ったバグ発生予測について
AIを使ったバグ予測も検討されているそうで，開発プロジェクトにおける各種メトリスクを，AIが学習できるようにデータラベルを付けて加工し学習させることで，その成果物におけるバグの発生量を予測する取り組みも行っているそうです。
・AIによるテスト設計の自動化について
仕様書からテストケースの自動作成について，人間が仕様書の記載内容を確認し，仕様書のなかでテストケースに出来そうな文章を分析して，類似度の高いものはテストケースを自動で作ることができるのではないか，ということでした。
受講しての感想
増田さんの講演は，AIの知識が少ない私にも，AIの内部処理構造等が理解でき，とても分かりやすい講演だったと思います。AIによるテスト設計の自動化についても，自動作成に向いた部分をあらかじめ人間が仕訳することで，ある程度自動設計ができるとの意見で，将来に期待が持てる気がしました。
３A.問題発見セッション｢納得できるテストをつくるアプローチ（ワーク込み）～妥当な判断をするための問題発見方法と思考フレームワーク紹介～」水野昇幸さん（JaSST Hokkaido 実行委員会）
このセッションは講演資料が公開されてます。とても分かりやすい資料なので，是非ご覧いただければと思います。
印象に残った点
・納得できるテストの必要性について
我々はテスト設計結果について，顧客（お客さん）に納得してもらう必要があるとのことです。（当然ですが）
登場人物として，顧客，マネージャ，テスト設計者があるが，マネージャはテスト設計結果を説明できる必要があり，テスト設計者はテスト設計結果に自信が持てる必要があるそうです。
・納得できる証明とは
納得できる証明とは「主張が明確で，筋道がわかること」とのことです。（P.14）
「反論の余地が無く，裏付けが整理されており，知りたい事がダイレクトに答えて明快」なものだそうです。
個人的にはなかなか難しいと思いましたが，実現する方法を説明してくれました。
・納得を実現する方法
具体的には，主張－論拠のツリー構造を使うそうです。（P.15）
ツリー構造で考えることで，繋がりや論拠が明確になります。
また，ツリー構造により，全体的に考えて抜けがなく見えるそうです。
・重要なポイント
構造を考える上で重要な点として「テストケースは何らかの目的を持つ」ことです。（P.18）
そのため，テストケースを，目的－手段のツリー構造で整理することができるそうです。（P.21）
ツリー構造での整理（３段階で整理する）
- ①目的 － ②手段/目的（①を実現する手段であり詳細目的）－ ③手段（②の手段を実現する手段）
表現を変えると，
- ①上位目的 － ②戦略目的 － ③手段
テスト用に表現を変えると，
- ①テスト対象機能 － ②テストケース目的 ― ③テスト手段（テストケース）
になるそうです。
・テストケースの整理が難しい理由
以下の場合，整理が難しくなるそうです。（P.42）
- 作業そのものになれていない。
- テストケース目的に対する知識不足（ドメイン知識やVSTeP観点出し）。
- テスト知識（テスト設計技法）不足。
- 「目的と手段の思考方法」で考えることが少ない。
・目的と手段の思考方法について
目的と手段の思考方法の基本構造は，
目的 ― 手段（＋理由）
です。必要に応じて理由を記載してなぜこの手段を採用したか分かるようにするそうです。（P.47）
・目的と手段の思考方法における注意点について
目的－手段に関して，以下の様な失敗に注意が必要とのことでした。（P.52）
- 循環論理：（例）知識をつけるために勉強する。
- 手段の逆転：（例）TOEICで高得点をとるために英語を頑張る。
- 手段の目的化：（例）チェックリスト項目を完璧にクリアする
・テストケースを整理するメリットについて
目的の無いテストケースはないため，この整理方法を利用すると重複が分かり，不要なテストケースを把握することができるそうです。（P.66）
個人的な意見ですがツリー状で整理することにより，テスト目的の漏れも気付く可能性も多いにあると思います。
・テストケース整理時の注意点について
注意点として「納得できるテスト」は「完璧なテスト」ではなく，作業者の実力通りになるそうです。完璧ではないが，その時点のベストを作ることはできるそうです。（P.71）
個人的には，その時点のベストができれば，十分じゃないかと思いました。
また，今回の構造的な「論理」を作っても，相手から信頼されていない場合は，納得を得られないことがあるそうです。（P.72）
・補足情報について
納得できるテストについては以上ですが，補足として，水野さんが興味深い事を教えてくれました。
（a）ツリー上に整理することによって，「分からないこと」が分かるのが重要とのことです。（P.112） 特に，自分が分かっていないことを理解していことを「愚者の楽園」と表現しており，とても面白く感じました。
（b）SFAA（全てのアメリカ人のための科学）に纏められた「科学的アプローチ」では，分からない事は，論理構造を明確にしながら一つずつ根拠を明確にしながら，仮設検証を繰り返して，明らかにしていくそうです。（P.113）
受講しての感想
ツリー構造を使って納得できるテストを作る手法は，興味深いものでした。
所々，VSTePの紹介も交えながら，水野さんの軽快なトークに引き込まれて，あっという間に時間が過ぎました。水野さんは本日の講演以外に問題解決手法等の講演もされており，他の講演も聞きたいと思いました。
３B.テクノロジーセッション
テクノロジーセッションは私は参加できなかったので，講演資料のリンクのみ記載します。
・3B-1「サービスデザインの時代～顧客価値をビジネスに～」
長谷川 敦士さん（コンセント）
講演資料
https://www.slideshare.net/atsushi/ss-77256833
・3B-2「AIとテストパターン～AIを適用した製品・サービスに対してテストをどのように組み立てていくか～」徳 隆宏さん（オムロン）
講演資料
https://www.slideshare.net/tokutaka/jasst-kansai-2017-ai-ai-and-testing-pattern
４．招待講演「UI自動テストツールとAI」～AIを使った自動テストの「今」と「未来」～ 伊藤望さん（TRIDENT）
伊藤さんの講演資料も公開されてます。
https://www.slideshare.net/NozomiIto/uiaiai
印象に残った点
・伊藤さんは，スマホ等のUI自動テストツールを開発しているそうです。現在β版で提供されているそうです。
http://blog.trident-qa.com/2016/10/introduce_magic_pot/
・今後のAIの利用シーンについて
今後，定型的な作業はAIが実施するように変わっていくのではないかと話してくれました。
・AIが実施するテスト領域について
- テスト設計は，非定型なため AI化は難しいそうです。
- テスト実行は，定型なため AIツール（Magic pod等）を利用できるそうです。
・アプリの自動テスト（Magic pod）について
画面を入れると画面部品をサジェストしてくれる。
画面部品に対して「クリック」や「キー入力」を指定してテストケースを作成していくそうです。
・Magic podの画像解析について
画像解析AIは人間の思考ベースで考えたそうです。画像要素をどう探すかというと，ボタン等は見た目で探しており，入力領域はUI要素のラベルから特定しているそうです。
アイコンやボタンを見た目から特定するのにディープラーニングで，2000枚～3000枚の画像を学習させるそうです。画像の種類を人間が指定して学習させるそうです。学習ロジックの中にランダムな処理（確率的勾配降下法）があり，AIがどう学習したかはブラックボックスになるそうです。
・画像解析AIのテストについて
解析エンジンのテストは交差検証を使って，学習データの１部をテストデータとして使い，正解率で解析エンジンの性能を測るそうです。
・AIの判断間違えについて
Deep Learningは人間と同じ間違えをするそうです。MagicPodのテストでは，正解率の確認と基本ケースのテストは全部行い，間違った判断をしないか確認するそうです。
失敗した時の対策としては，以下の様なものがあるそうです。
（a）間違えたデータを学習データに加える。
（b）とりあえず再学習させてみる。
（c）諦める。（そのままにする）
（d）機械学習ロジック自体の見直し。
・AIの使い所について
AIの使い所としては，以下の様になるのではないかとのことでした。
（a）不安定さを許容できる処理。
（b）人間よりAIの方が精度が良くなる処理。
・Magic podの最終目標について
最終的に人間の書いたテスト設計結果を，AIが理解してテストスクリプトへ落として自動実行にしたいそうです。
・AIによるテスト自動化の範囲について
AIによるテストの効率化は色々可能だが，完全自動化は当面無理とのことでした。テストの完全自動化が実現した時には，システム開発の仕事は全て自動されているだろうとおっしゃってました。テスト設計の自動化は，AIが常識を読み取る必要があるそうです。
・AIによるQAの変化について
AIによりテスト実行などの定型作業は今後減るのではないか。その分，QAはテスト設計などの創造性の高い仕事ができるとのことでした。
テストにおける単純作業がQAの地位を下げている面があり，AIにより単純作業が無くなり，スキル勝負の世界になればQAの地位が上がるのではないかとのことでした。QAの未来は明るいとおっしゃってました。
受講しての感想
AIを活用したツールを制作している伊藤さんのお話しは，AIをとても身近に感じられました。また，AIによってQAの地位が上がるとの，非常に心強いお話しが聞けて，JaSST関西のまとめとしても良かったと思いました。
５．運営について
JaSST関西の運営で、良いと思った点です。他にも色々あると思いますが、気付いたのはこの位でした。次回の東北の運営でも参考にさせて貰う予定です。
・前日の会場作り：
100人規模だから必須なのでしょうが，前日の夜に会場をセッティングしていました。これなら当日の朝にバタバタしないで済むと思いました。残念なのが，前日の夜に勉強会等を企画できない事ですね。どっちを優先するか悩み所です。
・名簿順の受付と申し込み順の受付：
JaSST関西の受付のお手伝いをした時に，申込み順の名簿の他に，あいうえお順の名簿があり，申込み番号が分からない参加者が来た時に，素早く見つけることが出来る様になってました。東北でも次回から準備したいと思います。
・プリンタ持ち込み：
会場にプリンタを持ち込んで，必要な印刷物をその場で作成してました。もちろん，印刷物は事前に準備した方がいいのですが，当日追加で欲しくなる場合もあるので，会場へのプリンタ持ち込みは便利だと思いました。
・情報交換会の全員参加：
東北では情報交換会は事前申し込み制ですが，関西は全員参加を前提にしており，お茶等を全員分準備してありました。また，全員参加が前提なので，情報交換会の後に招待講演がある構成でした。ワークショップによる時間延長等を考慮した構成だったと思うのですが，最初から全員参加という割り切りも良いと思いました。（東北では当日になって参加を希望する方が毎年いるので）
以上。JaSST関西実行委員の皆さん，講演者の皆さん，楽しい一日をありがとうございました。
（記）高橋
JaSST Tohoku 2017もうすぐですよ～
あっ！！
・・と言う間に気付けば、5/26(金)の「JaSST Tohoku 2017」まで後二週間を切りました。皆様申込みはお済みでしょうか？（笑）
何はともあれ、まずは申込みリンクをご案内しますね。
・JaSSTソフトウェアテストシンポジウム-JaSST'17 Tohoku 参加お申込み
http://www.jasst.jp/symposium/jasst17tohoku/query.html
今回のブログは「申込み忘れてた！」貴方へのリマインダ＋α（ちょこっと内容案内）となります。（提供は、実行委員やまゆうでお送りします(^_^;)）
～～テーマ～～
今年のJaSST'17 Tohokuのテーマは「育成」とし、「オペレーターや新人がテストエンジニアになるための最初の一歩」を目的としています！
「テスト技術者はどう育てればいいのだろう？」と育成や社内教育でのお悩みはありませんか？
基調講演、事例発表、ワークショップを通して、皆さんとこの課題の解決に取り組みたいと思います。
開発者・技術者はもちろん、人財育成部門・教育部門・管理職の方々も是非々々御参加ください。
～～概要～～
■基調講演（午前）
基調講演には、第三者検証会社であるベリサーブにてシニアコンサルタントとして、
・テストプロセス改善
・レビュー
・テスト管理ツール
・テスト自動化
などの導入支援にて御活躍中の山崎崇氏をお招きします。
「テストオペレーターから理想のテスト技術者に近づくための最初の一歩を踏み出すきっかけ」
を聞けるということで私も今から講演が待ち遠しいです ｿﾜ(･ω･*)(*･ω･)ｿﾜ
■事例発表(午後)
事例発表も負けていません。
・Web業界やゲーム業界など数社を渡り歩きQA活動を行う山本久仁朗氏
・ソフトウェアテストやアジャイル開発のR&Dを行う朱峰錦司氏
・ウェブレッジで育成チームリーダーを務める土岐しのぶ氏
・テスト設計コンテストの審査員を務める東京エレクトロンの根本紀之氏
と、そうそうたる顔ぶれを揃え（おおっ！(゜o゜; ））
それぞれの立場からテスト設計者の育成事例をお話しいただきます。
もうwktkが止まりませんね！
■他にも・・・
他にも、一風変わったワークやスポンサーライトニングトークス、
本会後（18:00~20:00）には、講演者と参加者が意見交換できる場も用意しています。
有識者の意見を聞くことで悩んでいることの解決の糸口も見えてくるかも・・・？
お時間があれば、こちらも是非ご参加下さい（＾＾）ノシ
更にお時間があれば、20:30~ 懇親会も用意していますので、コチラも是非～。
http://kokucheese.com/event/index/465312/
～～日時、場所など～～
■日時：
2017年5月26日(金) 10:00～18:25
（お悩み相談会 18:30～20:00）
■場所：
仙台市戦災復興記念館 5階会議室
〒980-0804 宮城県仙台市青葉区大町二丁目12番1号
TEL:022-263-6931
■定員：
60名（定員になる前に申込みをお願いします～）
■参加費：
一日券 : 3,000円（税込）
お悩み相談会 : 無料（登録者のみ）
■申込方法：
・JaSSTソフトウェアテストシンポジウム-JaSST'17 Tohoku 参加お申込み
http://www.jasst.jp/symposium/jasst17tohoku/query.html
～～最後に～～
最後までお読みいただきありがとうございました。
では、5/26（金）にお会いできることを楽しみにしております♪
JaSST Tohoku 2017 懇親会のお知らせ
JaSST Tohoku 2017 まで一か月と少しですね。皆さまいかがお過ごしでしょうか。
宴会担当の 村上 です。
今回のブログネタは、いつものテスト三昧と打って変わって懇親会のご案内です。
JaSST Tohoku 2017 終了後、懇親会を行います。懇親会会場は、一番町アーケード
にある蔵の庄 一番町店です。
蔵の庄は、仙台のITイベントでよく使われる居酒屋なのですが、食べ物がおいしい
ことで知られています。また、日本酒の種類も豊富でいろいろなお酒が楽しめます。
興味のある方は、 http://kuranosho.jp/ をチェックしてみてください。
今回の懇親会では、いつも宴会で好評の「天まで・・・」や仙台と言えば
「牛タン焼き」など、各種美味しいものを取り揃えて皆さまのご参加をお待ちして
おります。
開催日 2017/5/26
時間 20:30～
場所 蔵の庄一番町店
宮城県仙台市青葉区一番町3-8-14 鈴喜アバンティビル2F
電話番号 022-224-3031
会費 4,500円
今回の囲炉裏焼き何が出てくるのかな～なんて今から楽しみです。
お申し込みは、こちらからどうぞ。
それでは、JaSST Tohoku 2017でお会いしましょう！
ドラクエ風スキルマップ ～仙台ソフトウェアテスト勉強会～
こんにちは。
JaSST東北実行委員のもりともです。
最近の森友学園問題で思い出していただけていたかなー？なんて勝手に思っています。
さて、4/8(土)はJaSST東北実行委員メンバーで仙台でソフトウェアテスト勉強会を立ち上げた
ねもりん(根本紀之さん)が講師を務める勉強会に参加してきました。
その名もドラクエ風スキルマップ勉強会。
前半はドラクエ風スキルマップという、ドラクエの職業＋レベルを用いたスキルマップを使って、楽しくスキルマップを作成するというもの。
後半は、書籍「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」を用いたワークで、
土曜の午後いっぱいを使った勉強会でした。
私としては何をするのか分からず、ただJaSST実行委員であるねもりんに会いに行くのがメインでしたが、すごくすごく楽しめました。
～～前半～～
まず、前半のドラクエ風スキルマップで見るのは、個人のスキルではなく、チームのスキルということです。
戦士、武闘家、魔法使い、…、みんなで力を合わせてで敵を倒す！というイメージです。
個人のスキルマップは作成していても、チームという考え方は私はしたことが無かったので、この時点でかなり興味津々になりました。
ちなみに、オリジナルネタは、楽天の川口さんという方が日経SYSTEM2015で掲載していたもののようです。
楽天川口さんが作成したのはWeb系の方用ですが、それを根本さんが組み込み系でも使えるように
カスタマイズしたものがあり、当日は参加者によって使い分けました。
根底にあるのはやはり楽しく！というところで、楽しみながらチームのスキルを見える化していくというものです。
また、例えばチームは戦士4人だけじゃなく、もっとバラエティに富んでいた方が良いのでは？と思わせてくれるということでした。
■自分のスキルを確かめよう！
まずは自分のスキルチェックを行いました。
私自身は、今の自分の仕事からは、少し管理よりで旅芸人職が少し高めな結果でした。
その後、3人1組のグループ内で、スキルを足してみました。
それぞれのスキルに違いがあって、チームだったら強みを生かせそうだなと思いました。
チームのキーマンがいなくなったときにどうなるか、何が強みの人を補給するべきか、
1人がいなくなったからと言って、人数合わせのために1人入れればいいという問題ではないのです。
それを見える化するツールとしてとても役立つと思いました。
■工夫してみよう！
次に、それぞれの仕事に合ったスキル(新しい職業)を作成してみたり、いろいろ組み合わせて上級職を用意したり、
しっくりこない文言を変更したりしました。
話の中ではこんなオモシロ職業が出てきました。
・ギャンブラー：仕事の行く末を決める人
・賢者：コンサル系 僧侶と商人を組み合わせた職業
・占い師：コンサル系 お客さんの所に行って要望を聞いて製品の概要を決めるとか、要求を聞くとか
・道具使い：量産とか保守のためのスキル。トラブル対応、お客さまの要望を運用で回避する。
・猛獣使い：上司とか偉い人を言いくるめて使う。業界のトップまで。
・笑わせ師：ムードメーカー。チーム、会社、業界へとレベルアップ。
・船乗り：専門知識を使う。ドメインの知識を知っている。サポート⇒自立⇒社内トップ⇒業界トップ
・吟遊詩人：英語を使う。PM同士でやり取り⇒クライアントと直接やり取り⇒予算交渉⇒テクニカルな内容、仕様
・銀座のママ：話を聞いてストレス解消、やる気になる、お店に来る人達を繋げる、自分のことを売る⇒チーム内⇒部門内⇒本部長⇒社長クラス⇒業界
どれが良かったかの投票も行いました。
実際に会社でもこんなことをやってみたり、投票したりすると盛り上がりそう、ですよね！
メリットとしては、みんなで一緒に考えること、自分たちの会社のスキル定義ができること。
実はこの人はこんなことを思ってた、とか新しい発見もあるも分かっていいということです。
注意することとしては、個人評価に使うのはNG。
ゲーミフィケーションの一種であるため、遊んでいるように見られてしまうかもしれない。
ドラクエを知らない？とピンとこないかもしれない。
ただ、ミッション達成のためには様々なロール（役割）が必要、というところでは、ドラクエを知らなくてもイメージはできると思います。
～～後半～～
そして後半、
「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」という書籍を用いたワークです。
アジャイルに効くとついているが、それだけではなく、組織を変えるためにどんなアプローチをした方が良いか
ということがパターンに分けられています。
現在は、15パターン追加され、48パターン⇒63パターンあるとのことです。
イノベーター理論というものがあり、新しい商品やサービスが市場に浸透するまでの経過がタイプ別に分かれています。
積極性が高い方から、以下5つのタイプに分かれます。
・イノベータ
・アーリーアダプタ
・アーリーマジョリティ
・レイトマジョリティ
・ラガード
アーリーアダプタとアーリーマジョリティの間にはキャズムと言われる溝があり、
組織に新しいものを導入するときにも意識した方が良いということでした。
パターンを使うにしても、各層へのアプローチの方法が変わります。
ラガードにはあまり時間を割かず、捨てた方が良い、という話もありました。
重要なのは、パターンを知って、タイプを判断して、すぐ使えるように意識していること。
実は今までやっていたことってこういうパターンだよね、って分かるところから始めてみたいと思いました。
課題を出したり改善したり、というのは常にそういう意識がないと中々できないところがありますが、
各々の意識を変えるのに使えそう！と思いました。
■パターンを知ろう！ワーク
63パターンの中から、気に入ったパターン、やりたいパターンを3つ選んで周りと共有しました。
私は以下のパターンでした。シンプルで分かりやすいのと、自分が今意識してやりたいとかやっていることを選んでいました。
１．感謝を伝える
２．協力を求める
３．みんなを巻き込む
「著名人を招く」パターンはそのうち会社でやりたい！ということで次点にしました。
共有した中では、その他でいうと支援者や仲間がいること、持続することについて共通して重要と考えているようでした。
■課題出しワーク
各自の課題について、パターンを使ってアドバイスするワークでした。
パターンが頭に入ってないと中々難しかったですが、こう解決できたらいいんじゃないかな、
というのをパターンから見つける、ということは少しできました。
だんだんみんなのお悩み相談になって、それぞれ話が止まらなくなりました。
その後はパターンを新しく作成してみたりと、盛り上がりの中で勉強会は終了です！
私としては、本当にすぐ使ってみたい、もう少し勉強してみたい、というものばかりでした。
また、終始楽しく満足感の高い勉強会で、参加してよかったなと思いました。
最後に…
5/26(金)にはJaSST東北が開催されます！
今年は、テスト技術者の育成がテーマとなっております。
申し込み開始しておりますので、皆さまどしどしご応募ください！！
JaSSTソフトウェアテストシンポジウム-JaSST'17 Tohoku
以上、もりともでした。
SaPID+とVSTePの共通点
今回のJaSST東北実行委員会ブログを担当します、リリカルこと@mhlycです。
JaSST東北実行委員会では「VSTePチュートリアル」というコンテンツを提供しています。
VSTePとは、質の高いテストを行うためのテスト開発方法論です。詳しくは以下のページに資料が掲載されています。
私もVSTePについては個人的に勉強しているところです。
SaPID+ bootcampに参加してきました
ところで私は、先月2月25日〜26日に神奈川 三浦海岸にて開催されたSaPID+ bootcampというイベントに参加してきました。
SaPIDとは自律型プロセス改善手法であり、SaPID+にはさらにSaPIDを拡張した内容も含まれています。
SaPID+ bootcampは、温泉リゾートに泊まり込み、SaPID+ の「STEP0：テーマ共有～STEP3：問題分析・構造化＋α」に集中して”がっつり”取り組むという、内容盛りだくさんの合宿形式のワークショップです。充実した内容で、とても勉強になりました。
さて、SaPID+ bootcampに参加してみて私は「SaPID+とVSTePにはいくつかの共通点がある」と感じました。ここでは、私が思うSaPID+とVSTePの共通点を紹介してみようと思います。（私見ですので、誤りを含んでいるかもしれません）
私の思うSaPID+とVSTePの共通点
- メンバー同士の対話を大事にする。言葉で共通認識を作ることにこだわる。
- 成果物（VSTePで言えばテスト観点図、SaPID+で言えば問題構造図）を作ることが目的ではない。本当の目的は、成果物を作る過程で議論して頭を使うこと(後述します)。また、そのような場を作ること。
- 外から成果物だけを持ってくることを良しとしない。成果物の押し付けでは自分たちの"納得感"や"所有感"がなくなってしまうため、自分たちで作ることを大事にする。
議論して頭を使い、成果物を作る
「普段の業務においても、頭を使って成果物を作るだろう」と思われるかもしれません。VSTePに関していえば、実際の現場においてVSTePそのものはやったことがなくても、テスト計画や方針を話し合う場などで議論をする場は設けられていることもあります。
VSTePやSaPID+で「議論して頭を使う」という部分を強調しているのは、そのプロセス（何をテストしたいのか？／自分たちは何に困っているのか？ を深く考えて議論する）というプロセスをもっと増やしたい／もっと効果的にやりたいからです。そういった意味で、成果物を作るということ自体が目的なのではなく、しっかり頭を突き合わせて議論すること、テスト観点や問題についてもっと深く考えてみる（＝頭を使う）こと、その場を作ることを目的としています。
方法論と聞くと普段の業務でやっていることと離れていると思われるかもしれませんが、議論などの活動の形態が異なっているだけで、似たようなことをしている現場はあると思っています。ただそれを体系立てて進めたり、成果が出やすい進め方にするための工夫がVSTePやSaPID+ には盛り込まれています。
VSTePがテスト開発方法論なのに対し、SaPID+は自律的プロセス改善手法です。また、成果物を構成する要素が「テスト観点（テストしたいこと）」なのか「問題（困っていること）」なのかという点でも違いがあります。それでも、根本的なところで大事にしているポイントは似通っているように感じました。
色々な手法が提案され使われている昨今ですが、それぞれの手法の使い方や利点、使い所などを比較して考えてみるのも、手法を理解して有効に活用するための手がかりになるかもしれないと思いました。
仙台ソフトウェアテスト勉強会〜エンジニアのためのQA研修〜
2017年1月28日に「仙台ソフトウェアテスト勉強会?エンジニアのためのQA研修?」として境野さんにお越し頂き勉強会を開催しました。
勉強会では株式会社ガイアックスにて新人エンジニア向けに実施している「QAレクチャー」を再演頂く形で進行し、ソフトウェアテストの基礎を解説いただきながら『QAって何やってるのか』、『品質が高いものを作るために何を考えればいいか』といったことを中心にお話いただきました。
■第一章：イントロダクション
品質、品質保証、テストって？
当たり前品質、魅力的品質のお話から
ガイアックスでは当たり前品質を確保する為に作った人と別の人がテストする
テストしている内容はどんなことかお話いただきました。
品質保証＝テストではなく手段の一つ
テスト以外に品質をあげる手法はある
テストはなにやっているのか。
・仕様理解し必要なテストをイメージ
・テストケース作成
・テストを実施
・バグトラッキング
■第二章：テストをやってみよう
テスト実施ワーク、バグって？
実際にガイアックスさんの研修で使用している、研修用のイベント登録システムを使っての
テストのワークを行いました。
まずは仕様書を見ないでテストを行い、その後仕様書を見てからのテストを行うことによって
開発者視点としては以下が大事だと言う話をしていただきました。
・作るものを正しくQAに伝えることが大切
・ドキュメント化が基本だが、全ては表現できない
そして、密なコミュニケーションをとり意図や熱意を共有することが大事
【バグとは】
■一般的には
プログラムの誤り
プログラム開発者が行ったミス
■ガイアックスでは
仕様と異なる動き
通常有すべき性質を備えていない
テストはバグを見つけて終わりじゃない
バグの一生
開発者が修正でおわらない
QAが確認してCLOSEする
修正確認、リグレッションテストまでやって終わり
実際の業務では「仕様書の抜け盛れをどれだけ実装前に指摘できるか」が重要
バグは後工程で見つかるほど修正コストが上がる
仕様書レビューのポイント
①こんなときはどうなるの？
②こっちのほうがいいんじゃないの指摘
をどれだけあげられるか
①については全体像がなにで、抜け漏れはないのかが大事
【テストすべきポイント】
その機能、画面でどんなテストするか
フォーム
操作
システムのないようによって代わる
create/read/update/delete
仕様を考える人も、コードを書く人もDが抜ける。
例えば SNSアカウント削除したら投稿、他人へのコメント、友達関係どうする
投稿がシェアされてたら、イベント会社医者だったら
削除後、同じアカウントで再登録できるか
■第三章：QA/テストについて知ろう
ソフトウェアテストの７原則、ソフトウェアテストの分類、テスト技法など
組み込み vs web
①プロジェクトあたりの、コスト 人数 期間がちがう
■求められる品質
【組み込み】
設計段階から、失敗が許されない
【web】
すぐなおせる
個人情報については重点を置く
小機能・短期間で公開してシェアをとる
QA×開発
開発者とQAは対等な立場
組み込みでは品質保証部のほうが権限が大きい場合もある
QAと開発は向かい合って対立しているのでなく、
同じ方向をむいているもの。
いいものを世の中に出そうという想いは同じ
デジカメで学んだこと
人が増えるとプロセス強い
メリット
誰がやっても一定以上の成果。
工業製品の量産とか得意。
デメリット
変化に弱い プロセスを守るが正義となってしまう
組織の硬直化
境野さんとしてはプロセス重視の世界から WEBの世界に来て自由すぎて驚いたとのこと
■所感
新人研修の内容を基にしていただいていた為、基本から丁寧に話をしていただいた結果
最後の質疑応答も質問しやすく盛り上がりさまざまな質問が飛び交いよい勉強会でした。
私個人、組み込みのテストから入り、現在ウェブの検証をやっており似たような境遇であるある話があったり、開発経験がなく、検証していく上で開発知識はどこまで必要かということを最近考えていたところに境野さんの開発修行の話、開発するテストとQAのテスト違いなどを話していただけ大変有意義な勉強会となりました。
【講師プロフィール】
境野 高義 氏
株式会社ガイアックス技術開発部に所属。
組み込み系(デジカメ)のソフトウェアテストを7年経験。
2009年、ガイアックスに入社し、QAチームの立ち上げ、運営を行う。
直近はグループ会社であるアディッシュ株式会社にて業務改善や運用改善を行っている。
過去の発表資料
「WebのQAを5年間運営してみた」
http://www.slideshare.net/takayoshisakaino/ques5-gx
■最後に
JaSSTTohokuでは5月に「育成」をテーマとしたシンポジウムを開催いたします。
ぜひ参加ください！
（菅野）
