こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
株式会社タイミーは「一人ひとりの時間を豊かに」をビジョンに掲げ、日々の開発を行っています。 そんな私たちが開発を通じて得ている学びを発信することで新しい取り組みを後押ししたり、アンチパターンに陥らない様に出来るのであればそれもまたエンジニア一人ひとりの時間を豊かに出来ているのではないかと考え、定期的に勉強会を通じて我々の学びを発信していく予定です。
今回は株式会社カカクコムとの共催イベントです！ 現在、カカクコムでQAの立ち上げを担う伊藤由貴さんをお招きして、タイミーでQAを担う矢尻さんでそれぞれのセッション後にパネルトークを行う予定です。 二人が考える良いQAの在り方やこれからのQAのあるべき姿など見所たっぷりでお届けします！ ハイブリッド開催でオンライン視聴も可能ですのでお気軽にお申し込みください！
会の様子
QAがQAしないでQAするために by伊藤さん
QA組織の目指す姿
開発者主体で品質保証に関する活動およびその継続的改善をする姿を伊藤さんは目指しているということでした。
理由としては、
- 伊藤さんが働いているカカクコムでは、100名程度の開発組織に対してQAは一人であり、QA採用も難しいので、最後の門番となるような体制を作ることができない
- 伊藤さんは一人目のQAとしてjoinしているので、元々は開発者自身でテストを行っていたのでそこを大切にしたいと思った(QAがテスト業務を「はがして」もどうせQAが見てくれるマインドになるような開発者に悩む可能性もある)
を考えているということです。
目指す姿を実現するための取り組み
上述した体制を整えるために、
- QA活動の指針としてのQAガイド作成(QA活動について共通してやるべきことやった方がいいことを定義し、品質向上のためにできることを把握するとともに品質向上の土台を作りたいと考えている)
- 現状把握のためのQAクライテリア作成(QAガイドに即した活動ができているかのセルフチェックリストを用意して開発者に定期的にやってもらうことで、状態を把握している。アンケートは状態把握と共に、じわじわとやるべき活動のメッセージが浸透することを期待している)
- テストのスキルや考え方のトランスファー(取り入れやすく小さな効果が得られそうな部分を伊藤さんから伝えるとともに、能動的に情報取得できる媒体を用意している)
の2点の活動を行っているということでした。
組織の変化
まずポジティブな点として、QAクライテリアの結果が徐々に改善するとともに、QAへの支援依頼*1や相談が増えたということです。
一方でネガティブな点として、状況を可視化して次の改善活動に向けたパワーが足りていないところと、障害数やリリース速度などの定性成果がまだ足りていないということでした。
駆け出しQAコーチがチートポ型組織でQAしないで価値を届けたい話 by矢尻さん
開発チームへ飛び込み
矢尻さんはイネイブリングチームにQAとしてjoinしたそうで、ここでは高速に石橋を叩いて渡れるようにQAコーチとして振る舞いをしていこうと最初は考えていたそうです。
モヤモヤの始まり
チームに入ったところ、QAってテストのことだよね？という話や、QAが品質に責任を持ってくれるんだよね？という話、テストは何のためにやるのか？といった話が出ていたことにモヤモヤした矢尻さんは、
といった話をしたそうです。
イネイブリングの流れ
上記のような状態だったことを踏まえ、
- 現在地点を評価してビジョンを共有する
- アジャイルテストの4象限をもとに戦略を練る
を実施したそうです。イネイブリング活動を行っていくなかでは、「知識は経験から生まれ、意思決定は観察に基づく」というスクラムガイドの一節を大切にしているということでした。
また、教えるための手法としてはアクティブラーニング手法であるThe4Csを使うことを大切にしているということです。
パネルトーク
講演の後はパネルトークがありました。以下、テーマと議論内容を箇条書きかつ常体で記載していきます。
一人目QAは何を学び初手に何をするのか？
- 既存の文化を大切にしながら、今までの知識や認知を捨てるアンラーニングすることが多い
- 飲み会をやってとにかく仲良くなった
- 全チームの代表者とMTGをして、顔合わせ兼ヒアリングをした
- QAに対して悪い印象を抱いている開発者もいるので、そう思われないように振る舞えたのがよかった
現場のやる気、どう引き出す？
- 割と上手くいっている状態でjoinしたので、「もっとこういう部分はよくやれますよ」という話をしたり知的好奇心をくすぐるような知識を渡すようにした
- 心配事を引き出して、その心配事がわくわくに変わるようにするためにはどんなことをすればいい？という話をした
- マインドマップを使ったテスト設計手法など、細かい道具を渡すとやる気が引き出せることに気がついた
QAとしての成果の計測はどうすれば良い？
- 4 keysの変更失敗率やインシデント分析を実施している
- それなりの期間計測できてきた実績がないと意味が薄いと思っている
- 売上とかにどうつなげて話をするのか？というのは難しいと思っている
QAだと減点主義になりがちだと思うがその弊害はあるか？
- テストをやる限りにおいては減点のコミュニケーションになりがちなので、バグをハッピーと言い換えるとかは他社事例ではあるがある
- バグとか障害を見つけたときに躊躇う場面が出てきてしまう
- 偉い人からの今どうなっているんだ！？みたいなものがプレッシャーになる
会全体を通した感想
きれいにまとめすぎることなく、課題感も含めてやっていることを話してくれていたのが非常によかったです。
1人目のQAとして入ると、どうしても短期的な成果を求めたくなるフォースはあるのかなあと思っていましたが、そこで長期的に活動が必要な部分から入れているのが、すごくいいなあと思って聞いていました。
*1:これやってとかではなく、これを自分たちでやりたいのだけどどうやるといいんだろう？
