Encraft #13 に参加して感じたこととか

株式会社ナレッジワークさん主催のイベント「Encraft #13 QA Enablement - Insight by QA activity」に参加してきました。 自組織の課題と照らし合わせて、様々な気づきがあったので、自分用のメモとして記していきます。

knowledgework.connpass.com

登壇者はもとい、参加者にも業界内で著名な方が数多くいらっしゃっており、イベント参加メンバーだけでJaSSTが開催できてしまいそうなメンツですよね。

「品質保証からの情報提供」について考えよう

1つ目のセッションは、ナレッジワークkoyaman(小山)さんからのバグ傾向Dashboardに関するお話でした。

イベントの前日にバグ傾向Dashboardに関してのBlogを公開してくださっていたので、内容が理解しやすかったです。

zenn.dev

発表の中では、テストにより「知ったこと」を“誰かに”伝え、“誰か”が動けるようにするために、5W1Hのフレームワークを使って整理していきましょうというお話がありました。

過去の自分にも思い当たる節があるのですが、新しいツールを導入するときって、Howの部分ばかりが先行しがちです。
導入した結果誰がどのように嬉しいのかが置いてきぼりになりがちなんですよね。

完成形ではないとは言え、2週間でシュッとこのDashboardを作れるスキルもすごいと思うのですが、
Howに寄りすぎず、一歩引いてWhoやWhyを考えて実現されているのが素晴らしいと思いました。

私は自組織の課題と照らし合わせて次のようなことを考えながら聞いていました。

Dashboardを作る際には当然メトリクスが必要になります。
ただ、ある程度組織が大きくなってから「全社的に」とか、「部門全体に」とかチームを跨いでDashboardを作成しようとすると、
チームごとに使用しているBTSが違ったり、フィールドがなかったり、分類が違ったりするので、共通のDashboardを作ることが実質的に困難になります。
はい、今まさに私が所属している組織がそんな状況です。

ナレッジワークさんは品質へのこだわりが高く、開発者により検知したものも含めてバグをJIRAに起票するプロセスが根付いてるからこそ、実現できたとのことでしたが、
ある程度、チーム毎のプロセスが固まってから、それを変えるのは相当な覚悟と勇気と努力が必要になります。 なので、どんなに混沌とした状況(例えばスタートアップのようにとにかく早く価値を提供し、利益を出さないといけない状況)であっても、バグの管理の方法や、そこで付与する属性・値というのは統一しておくべきだなと感じました。
今のところ、1人目のQAになるつもりはないですが、そのときのために。

そして、上記のようなことを考えると同時にいけださんのこのポストを頭に思い浮かべていました。(唐突)

パネルディスカッション

パネルディスカッションでは、開発チームに対するQAエンジニアの関わり方として、下記の4つの仮定に分類してディスカッションが行われていました。

  • In Dev
    • QAエンジニアが開発チーム内でテスト業務を行う
    • QAエンジニアが主要なスクラムイベントに参加
  • Out Of Dev
    • QAエンジニアが開発のチームとは離れている部門でテスト業務を行う
  • Bridge
    • 自社内開発で、ブリッジのQAエンジニアor PdMがいて、テスト業務は第三者検証に委託する
  • Assistance
    • 開発チームとは離れている部門がQA活動に対する情報提供を行う(テストはしない)

パネリストが事前準備なしで臨むというなんともパネリスト泣かせの企画です。
確か、前回のEncraft #9 QA回もそうでしたよね？
そのような状況下でもディスカッションできるパネリスト陣がすごいです。
その場で考えて発言しなければならないので、コンテキストが伝わりづらい場面もありましたが、別のパネリストが補足するような愛を感じるやりとりもありました。

いくつか個人的に良いなと思った内容があったので箇条書きで書いておきます。
(私は聴いた内容を文字に起こすのが極端に苦手なので、異なるニュアンス・表現に変換してしまっていたらご指摘ください。)

  • In Devのメリットはチームと自然に会話できること

    • broccoliさん(@nihonbuson)：「こういうテストをやろうと思っている」ということを「予告」する。予告したところは開発者が気をつけるのでまずバグは出ない。バグを報告して、それを修正して、確認してーというコストを減らすことができる

  • QAエンジニアのメンタルの持ち方、情報を提供する(伝える)時の考え方について

    • ゆもとさん(@yumotsuyo)：強気、対等になることが重要。「自信」を持つ。
      • 自分が一番システムを使っているという「自信」
      • 自分が一番欠陥に遭遇している時間が長いという「自信」
    • broccoliさん(@nihonbuson)：「ここで困っているんです」を伝える。
    • koyamanさん：QAエンジニアは「情報を提供する」ことが仕事(報酬を貰っている)。その目的を達成するために必要だから伝える。

おわりに

たくさんの気づきが詰まっていて、パネルディスカッションについては、ずっと聴いていたい内容でした。
イベントの企画・運営・会場設営・配信に関わってくださった関係者の皆様、ご登壇された皆様、大変お疲れ様でした。そしてありがとうございました！