こんにちは、とのの（@tonono2587）です。
勉強会に参加してきたので、感想を書いておきたくなりました。
今回のテーマ：Encraft #13 「Insight by QA activity」に参加した
イベントページはこちらです knowledgework.connpass.com
参加前の興味関心
イベントテーマ「品質保証活動からの情報提供」が
いまの仕事のヒントになりそうだと思い参加しました。
特にエンジニアや、"QA"のことはあまりよくわからない 人へ向けて
自分がどういう情報を提供したほうがいいのか考えたかったので、そのヒントにできたらいいなと思っていました。
参加してみて
全体的な感想としては、自分の立ち位置や情報提供の宛先によって気になりごとは変わるので
気になりごとにあわせた情報の整理や伝え方、内容にするのがよさそうだと思いました
（書くと当たり前だなぁとは思いつつ）
特に発表のなかの
- 誰にとってうれしいのか
- プロダクト/プロセス（という軸）
この部分は、自分が情報整理するときにまた思い出したい気づきとなりました。
パネルディスカッション
後半のパネルディスカッションは「ケーススタディ」としての切り口がとてもわかりやすく、
何についての話なのかがスッっと入ってきたので
やっぱりここはどんな立ち位置でも大事だよな〜 とか
わかる〜 と思いながら聞いていました。
資料が公開されているので、それを見ながらメモの内容を読んで、中身をかみしめたいと思っています
メモ
- QAの情報提供はプロセスとプロダクトの両面がある
- プロセスマトリクス、プロダクトマトリクス
- コヤマンさんの発表に対する感想
ケーススタディ
In_Dev
いちから始める場合のおすすめは？
- バグをちゃんと記録しよう
- QAの人が？開発チームに働きかけ？
- チームのリズムによって変わると思う。
- エンジニアがやりたければ自分で、時間ないならQAが
- "自然に”できるように
- QAの人が？開発チームに働きかけ？
- いろんな情報が集まるので
- 情報提供の準備をする
- “バグ”を見つけるのは誰？
- 基本的には見つけた人が記録するのがいい
- やだって言われたら聞き取ってQAがやる
- 必ずしもテストで見つかるわけではない
- In_Devじゃなくても、全部でできる
- 「In_Dev」毎日一緒にいて日々情報が入ってくるので、そこならではでできることは？
- 日々入ってくる情報から得る違和感はこまめに伝えたり（これバグかも）
- 会話の中で気づくことも多い
- どういう形式でアウトプットするかはともかく、つっこんでいくことが大事、メリットかな
- 距離感が近いので「情報提供」はやったことよりも「やろうとしてること」に対して、テストをしようとしていることの予告すると思う
- やり方は？
- リファインメントだと口頭
- チケットの受け入れ基準に書くこともある
- 受け入れ基準は抽象度が高いので、テスト設計的な情報は開発前or同時
- テスト分析、設計成果物をみてもらう
- やり方は？
- 予告しておくと、意識して開発するのでバグ出づらくなる
- バグ出てからだとコストがかさんでいく
- “これからとってほしい、つくってほしい” の意見を言いやすい
- 言わないと楽なほうからやっていってしまい、テスト終わらなかったり？
- リファインメント
- 何を持ってチケットがOKになるか を再確認すると、ほんとにそれやったほうがいい？になりやすい
- こっち先にやろうよ、と提案しやすい
Out Of Dev
- DesignDocができた段階でレビュー、というような「前へ」の活動はできる
- ド正常な部分からやって、そこは先に情報提供
- やったところから先に情報提供できるように
- テスト中断の決断にも使えるので
- テストを調整して、安心材料を与えつつ次の開発にも集中できるようにしてあげる
- 情報をくれ、とお願いすることが多かった
- 企画書
- プロダクトをリリースする理由
- なんでこれを、どういう狙いで出さなきゃいけないんだっけ
- そもそもなんでQAがOutにいる？
- QA部門がリリースしていいとかのジャッジをしているから？
- 合わなければリリースを止めるのも仕事に入るため
- Outの場合は「計画」をつくらないといけない
- 直前じゃなく前もって見込みを提供しないといけない
Bridge1（発注元）
苦労しているんじゃないか、アドバイスしてあげられることは
- 委託先の会社の人に騙されちゃう*1こともあるから、鵜呑みにしないように！
- 委託先の人は安全側に倒すから、100件で済むケースを5000件やったりする
- 存在意義、何を大切にするか
- ブリッジの人が、テストの情報をオープンにしたほうがいい
- 委託先の人に対しては、見逃したときに責任をとうつもりはない、と言っておかないとどんどん安全側に倒しがちだから
- 信頼関係、いい関係を築くことが大事
- ブリッジの人はテストのことをある程度わかっている必要がある
- 盲信を避ける
Bridge2（委託先のテスト管理者）
- 「やらないこと」も説明し、合意形成する
- やらないことから出た場合は責任にしない
- 問題が起きちゃったら、次同じことを起こさないようにどうすべきかを一緒に考える
- 狙い、ターゲットにフォーカス
- 競合がすぐ近くにいるので、差がつくプラスワン情報を提供できないか考えていた
Bridge3（委託先の実テスト担当者）
- 数字で伝えること
- 全体の何％終わった
- 何件バグが出てなおっているのは何件で
- 管理者は細かい情報を発注元に伝えないといけないので、現場はまとめてあげて、伝えたほうがいい
- 人数が多ければ多いほど、データを貯めておいて自然に情報が見れるようにしておくのが肝
- 嘘をつかない、誠実に報告する
- 管理者は、悪い情報を受け取ったときは怒らない
- 伝えてくれてありがとう
- 困るからこうしてほしい
- あなたの力が必要なので協力してほしい
- 上下関係じゃなくて仲間
- 管理者に言われて初めて情報提供するのではなく、管理者が期待する情報を常に伝える
Assistance（QAのコーチング、教育）
- チームが何をやればいいのか、判断できるガイドラインを制定
- 自立して動けるための教材づくり
- ヒアリングして、それにあわせて作成
- 「悩んでいること」を聞く
- 聞いて即答じゃなくて、具体的にどのチケットのどういうことをやろうとしているの？
- 一般論としての返答ではなく具体的な現物を確認、ヒアリングしてから情報提供する
- 情報を吸収して横展開
- 全体的にみてここがつまっている、などプロジェクトマネジメント寄りの情報提供
ほか
こういう情報を伝えたい、エンジニアに伝えたいものはもっているはず
それを伝えられないのはメンタル的なところがあると思う
内気な人に対する、壁を超えるアドバイスはある？
- 自信をもちなさい
- この中で一番あなたがシステムを触っている
- 欠陥に遭遇している時間も一番多いはず
- 意見を言うまではいかなくていいから、「困っていること」の相談をしてほしい
- まずは言える人側から困っていることをオープンにする
- プロジェクト、仕事には必ず目的がある。その目的を達成するために必要だから話す
伝えられそうだけど伝え方が上手くない、そこの改善方法やアドバイスはある？
- 訓練
- 話を整理する
- 自分の意見なのか推測なのか
- 感情なのか事実なのか
- 目的は何か
- モデリングする
- 抽象的、具体的をいったりきたりする
- 物事を分類する
- 仲間で練習をやってから
- かわしまさん
- X 140字にまとめる
- あたま使う
- どうやったら上手く書けるかの練習になる
- 業務以外でやっておく
- X 140字にまとめる
かなりのメモなので、内容や実際話された方のニュアンスとは異なるかもしれません…
まとめ
- 自チームではまだ取り切れていない情報がありそう。まず自然に見れるようにならないか考えたい
- プロダクトと、プロセスどっちに要るかラベルつけてみよう（どっちでもなくほかもあるかもやけど）
- 「話」下手なんだよな〜訓練要るよな〜
- 目的を気にするのはこれからもそうしたい
- エンジニアに”認めてもらえてきたかも”ってなる瞬間があるのは、もしかしたら情報提供がうまくいっていたのかも
会場ではお久しぶりの方やいろんな方に会えたのでそれも楽しかったです。
ありがとうございました！
*1:委託先に悪意はない前提で、見方によっては不利益といえてしまう
