ASTER出張セミナー（in 青森）に参加しました！
こんにちは、JaSST東北実行委員の武田です。
9/21（金）に第1回：ASTER出張セミナー（in 青森）が開催されたので行ってきました～！
青森へは初めて行ったのですが、いたるところから三味線が聞こえ、行く先々にはねぶたが彩られ美しいところでした。
海沿いにある会場（ねぶたの家 ワ・ラッセ）も不思議な形をしており、キレイでしたよ。
潮風が強く気温もあまり高くない中、松谷さんが半袖だったのには驚きました！
池田さんによる初心者向けセッション
「単なる仕様チェックから卒業するために ～最初に抑えたいキホンのキ～」
第3回盛岡ソフトウェテスト勉強会でお話いただいたときは、45分という限られた時間の中でお話いただきましたが今回はたっぷり120分でした。
【機】とらえなおそうテストの意義
ソフトウェアテストの意義ってなんだろう・・・
テストを始めたばかりのころは気にせずただ仕事をこなしていたような気がします。
「ソフトウェアテストを行うと、ソフトウェアが作られていく過程で入り込んでしまうバグを発見することができ、そのバグを開発者が修正することによってソフトウェアを利用者が安心して利用できるようになる」
テストをしないと不具合を発見できません。当たり前のようでハッとする一言でした。
【規】テストに必要な思考
テストは仕様確認だけでは単なる動作チェックであって、テストにはテストの思考が必要とのことでした。
設計時は「こう動くべき」「こう動かないべき」という思考になりますが、テスト時の思考としては「それ以外」で何も起きないかも確認せねばならない。この認識があいまいなままテストしている人が多い気がします。はっきりと伝えてあげることで新人さんも早くスキルアップできるのではと思いました。
「行間ってなに？」と質問されたとき、はっきりと答えられる人はあまり多くない気がします。
【紀】テストの分析設計～マインドマップを利用して～
池田さんは書籍「マインドマップから始めるソフトウェアテスト」の著者でもあります。
仕様書から仕様を抜き出して語尾だけ変えるのは単なるチェックどまりというお話でした。
実際の現場だと、CPM法で作ったテストケースを実施する側が行間を読むような形になってしまっていることも多いと思います。現場によってはCPM法で設計するよう指定されたり・・テスト設計はなかなか思うようにはいかないですね。
マインドマップを書く時の注意点としてはテストの思考を意識すること！
意識しないと単なる仕様の整理になっちゃうよとのことでした。
ツール系セッション
松谷さんによる”気軽に使える”14個のツールのご紹介でした。
紹介されたツールはコチラ
- ScreenPresso
- gyazo
- Opne Broadcaster
- 文字列ジェネレーター
- テスターちゃんLINeBot
- LINE DESKTOP
- Postman
- Xmind
- Mind Map Tab
- 意地悪漢字
- バグっぱ！
- FindingBugs
- Mayersの三角形
- テスターちゃん
松谷さんはテスト漫画「テスターちゃん」の作者さんで、マンガでテストを表現されています。
新人教育するときなどに、読んでもらうことで共通するマインドとかを覚えてもらう手間が省けるとのこと。
マンガだから入りやすいし最高だと思います。
池田さん曰く、動画撮影はツールを使わなくてもパワポでもできるとのことでした。
パワポで動画撮影ができるのであれば、現場でツール申請などせずともサクっとエビデンスが撮れますね。
ScreenPressoの動画機能は、クリックしたときに円が波紋状に広がりステップが分かりやすくなっているのでエビデンスやマニュアル作成に最適だなと思いました。※無料版は広告が入るようです
Postmanは業務で使用することがありますが、自動化っぽいことができるのは知りませんでした。毎回コピペでAPIを叩いてたのでもっと早く知りたかったです・・・。
秋山さんによるASTER標準テキストセミナー
9月に公開されたばかりの話題のテキストで楽しみにしていました。
テキストは二日分（12時間）の容量とのことでしたが、今回は3時間でお話いただきました。
社内教育などでの利用で長い時間が取れない場合は、章ごとに分けるのがオススメとのことでした。
品質
「品質ではない、質である」
石川馨さんの言葉だそうです。
品質というと物品の質という感じになってしまうので「質」というようです。質はモノだけではない。
・いくら業務をよくしようとしても、下がよくないとできないので3段階でとらえることが大事
・製品の質だけ見てもダメで、企業がちゃんとしないと品物の質はとれない
※JISの定義は暗記のレベルがいいということでした。
第一章はソフトウェアの危機を感じてもらうことが目的とのことでした。
池田さんのセッションでもありましたが、バグ一つでどれだけ大変なことになるのか、などは考えるのが怖いかもしれませんが初心者のうちにしっかり向き合っておく必要があると思います。
同値分割テスト
わかったつもりでわかってなかったかもしれない同値分割です。
秋山さんがホワイトボードにかいたものをノートに描いて理解促進です。
「全部（の数字）はやらないけど”65だと地球が爆発する”とかならやるよ」がツボでした。
モデルルームの内覧にたとえ、玄関だけみるというのではなく風呂、キッチン、各所をまんべんなくみるよね？というお話が分かりやすかったです！
状態遷移
ラルフチャートで状態をご説明いただきました。
非常にわかりやすいのはJaSST東北でのHAYSTの取り組みがあったから？とも思いましたが、ラルフチャートの図はおそらく新人の人でも直感的にわかりやすいだろうと思います。
今回は3時間で1-4章をお話するというタイトなスケジュールだったので演習はすべて省略となりました。
秋山さんの説明は、背景のお話や、視点を変えたり、ホワイトボードに絵を描いたり、ストーリーに乗せてお話していただけるのでスッと入ってきて夢中になれます。
このテキストに限りませんが、社内教育や勉強会でASTERテキストを実施する場合は、ただただスライドを読んでしまうような形をとってしまうと初心者には興味が薄くなってしまうような気がしました。
その辺りを気を付けて工夫して使用したいと思います。
松谷さんによる事例系セッション
プレイングマネージャーとしてどのようにチームを構築していき、職場で起こる様々な問題に対してどのような施策を打っていったかのお話でした。
ねちゃう問題
あるある・・さすがにこれは解決むずかしいのでは・・と思いましたが松谷さんはなんと「ねてきていい！」にしたそうです。
他国だと「シエスタ」というものがあるらしく、例があるものとは知りませんでした。
かといってなかなかお昼寝導入は難しそうです・・。
ちなみに、職場のデスクでそのまま寝るのではなくお昼寝スペースのようなものがあるそうです。
だれが何やってるかわからない問題
チームの人数が多くなると誰が何をしていて・・などの把握が難しくなります。
松谷さんのチームではwikiでスケジュールや何をしているかをすべて記載していたそうですが、メンバーがそのwikiを見に行くのがメンドウ（ワンクリックだけど）となってしまいメンバーがほかのメンバーのタスクを把握できなくなってきていたようです。
そのような問題に対して松谷さんが打った施策とは、カンバンの見える化（壁に付箋を貼る）でした。
私も職場では壁を利用することがありますが、俯瞰できる、一緒に見ながら相談できるなどメリット盛りだくさんです。デメリットは・・梅雨時にパラパラはがれて落ちてしまうことですね。
時期によって忙しいチームとそうでもないチームが発生
属人化してしまって、サッと手伝うことができなくなって固定化してしまう問題です。
松谷さんは、どのチームでも手伝えるチームを目指し、流動的にまわせるようにしました。
暗黙知でいると手伝えない → ヒマがあれば社内wikiに仕様やテスト観点を落としていく！
メンバー数が多くなり目が届きにくくなった
26名のチームとのことでしたので、さすがに目が届きにくい感じになったようです。
→1on1で面談を行いコミュニケーションをとる
だらだらーっとするのではなく、時間を決めて（15分ほど）プライベートな事でもなんでも話をしたそうです。
1on1で話を聞き、メンバーのやりたいことを朝会で発表してもらい個人の成果のアピールの場をつくったり・・大人数のチームでもメンバーとのコミュニケーションを怠らない松谷さんさすがです。
キーワードは「見える化」で、ばんばん見えるようにしていったとのことでした。
案件が忙しくなるとつい見える化を怠ってしまいます。周りにも情報は伝わっているはず、と思ってしまう事がありますがそういうときこそ見える化が必要なのだなあと思います。
私もばんばん見える化していきますー！
* * *
今回は時間の都合上ワークはナシでしたが、その代わりフルでお話していただけたので濃厚な一日となりました！
講演者の方々に質問しやすい雰囲気で、たくさん質問させていただきました。ありがとうございました！
