こんにちは。
QAEチームのぜにまるです。
今回は10/28（金）に開催された JaSST Review ‘22 の参加レポートです！
※個人の解釈で記載している部分があります

もくじ

• イベントの主旨
• Mattさんの基調講演
  • うまくコラボレーションするための4つのヒミツ
    • Be kind（誠実）ってなんだろう？
    • Embrace discomfort（苦難）について
• ワークショップ
  • 典型的なレビューと狙い撃ちレビュー
  • レビュー観点導出アプローチ
• 感想

イベントの主旨

オープニングにてイベントの主旨についてお話がありました。

• “懸念事項の共有度分析”では質問による深堀りが重要ではないか？
• “個々のレビュー”の具体的な思考プロセスを表現できるのではないか？

イベントの主旨説明の際に、「レビュー」のプロセスは「テストプロセス」と似ている、というお話がありました。
イベント参加前の「レビュー」は「= レビュー実施」という印象でしたが、テストプロセスと同じように、個々のレビューにおいて「分析」「設計」「実装」「実行」と分けて考えることができるという発見がありました。

Mattさんの基調講演

午前のセッションでは、Mattさんの基調講演「うまくコラボレーションするための4つのヒミツ」がありました。

紹介された4つのヒミツ

1. Find small pieces（小分け）
   • 実例マッピングを用いて課題を小分けにして解決に繋げよう
2. Be kind（誠実）
   • チームメンバーに対しても自分に対しても誠実に仕事をしよう
     ※”kind”は「思いやり、親切」というような意味ですが、Mattさんと実行委員との事前打ち合わせの上、「誠実」と訳すこととされたそうです。
3. Embrace discomfort（苦難）
   • 苦痛だとしても早期学習に取り組もう
4. Seek joy（機智）
   • ガッツや熱意を持って楽しんでいる状態にあると、自ずと生産性も上がってくる

どの秘密も刺さるものでしたが、4つの中から特に印象深かったのは「Be kind（誠実）」と「Embrace discomfort（苦難）」でした。

Be kind（誠実）ってなんだろう？

Mattさんからの学び

【3つのフィードバックについて】

1. 感謝する
2. 評価する
3. コーチングする

【誠実なフィードバックを行うためのコツ】

• 相手がどのようなフィードバックを貰いたいのかを探り、それに応じたフィードバックを行う
  • 求められていないタイプのフィードバックを、自分本位で行わない
• 批判的な意見を伝えたい時は、「褒めことば：批判的な意見 = 5 : 1 」 で伝えると良い

考えたこと

相手がどのようなフィードバックを望んでいるかを把握する、ということについては当たり前のような気がしますが、普段は意識していなかったなとMattさんのお話を聞いて気付かされました。

QAという立場は、開発プロセスの中で開発者に指摘事項があったり、ヒアリング等で開発者と話す機会が多々ありますが、立場上言い方次第で開発者との確執が生まれてしまいがちだと思います。
自分は開発者と話したあと、あの聞き方・伝え方がよくなかったな〜とか、逆にやんわりと聞いたり伝えたりしようとしすぎて不思議な空気が流れる時間を作り出してしまったな〜と日々反省しています。
自分が指摘事項を伝えるときは、なるべくマイナスな感情や意味も含めずその事実だけをニュートラルに伝えることを心がけてはいますが、一歩先の相手のほしいフィードバックを伝えられる、良いコミュニケーションを取れるように心がけたいと思いました。

Embrace discomfort（苦難）について

Mattさんからの学び

【Learn early】

苦痛であっても最初に問題を学ぶ

【Mattさんの発表を聞いていない人が苦難を受け入れやすくするコツ】

• PJを最初からやり直せる + 今の知識を行かせるとしたらどうなるかを考えてもらう
  → 簡単にPJを実行できる、という結論になる
  → その今の経験をどこで学ぶのが良いかを考えてもらう
  → 早めに学ぶことができたらいいよ、という結論になる

考えたこと

レビューやテストプロセスにおいて、最初によく考えた方が良い分析や設計の部分を後回しにして、なんとなく進んでいきがちなのは自分にも心当たりがありました...。
開発プロセスに対して早期的にQAチームが入っていく取り組みと同時に、自チームのプロセスの見直しも必要だと感じました。

ワークショップ

午後からのセッションは、ワークショップ「レビューでは何を確認するといいのかな？さまざまなレビューの意図を整理して確認事項を明らかにしてみよう！」がありました。

ワークショップでの学び

典型的なレビューと狙い撃ちレビュー

• 典型的なレビュー（誰が 確認するのかが重要）

  • 書かれていることに反応し、気がついたことを指摘
    • 有識者がいないと軽微で表面的な指摘ばかりになる

• 狙い撃ちレビュー（何を 確認するのかが重要）

  • 対象の内容や構造、記述レベル等をざっと把握し、目的や条件に応じて必要な レビュー観点 を洗い出し、それぞれの観点に沿ってレビューを実施する
    • 有効な指摘事項など優先度の高い欠陥・不備を見つけやすい

レビュー観点導出アプローチ

【レビュー観点導出アプローチ（6つの例）】

1. 作成者コンテキストアプローチ
   • どのような状況の中でどのように作成されたのか、からレビュー観点を導入する
     • 多忙、経験年数、初メインプロジェクト、最終編集時間など
   • 兆候から仮説を立てて想定される欠陥を考え、レビュー観点を出す
2. 利害関係者の関心ごとアプローチ
   • それぞれの人のシステムへの関心ごとを洗い出し、必要な観点を考える
3. 対象成果物に求められることアプローチ
   • 確認方法を明確化すること = レビュー観点導出とする
4. 対象成果物によくある欠陥アプローチ
   • よくあるリスクや過去の観点をリストにする
5. プロダクトリスクアプローチ
   • 利用者の立場、こんな使い方をすれば発生するかものリスク
   • 類似製品の事故や障害、問題発生事例の確認
6. 利用シナリオアプローチ
   • 利用シナリオ（通常と例外）を作成し、それをベースに対象成果物をレビューすることで不明点や指摘事項があれば記録する

考えたこと

開発プロセスへの早期的なQAチームの参加 + 仕様等の静的レビューを行うことは大切だ、ということは認識していたのですが、実際のところどうレビューしたら効果的なのか？というところがもやもやしていました。
今回、実際にレビューをするにあたって対象を分析していく具体的なアプローチ方法を知ることができて、もやもやがかなり解消されて、ものすごく腑に落ちました。

また、このワークショップを見学していて、多角的な考え方でいろいろな証拠を集めて推理していく、なんかテストって刑事みたいだな〜と感じました👮

感想

今回初めて JaSST Review に参加してみたのですが、午前のセッションも午後のセッションもかなり身になるお話でした。
自チームに持ち帰ってできるところから取り組んでいきたいと思います！

ワークショップは参加せず見学をしていたのですが、レビューの意図やレビューに対する捉え方について、参加されていた方々のいろいろな考えをみることができて大変楽しかったです。
また次回の JaSST のイベントに参加したいと思います！

関連する記事はこちら

障害対応のフローをまとめてみました Valentine’s Special Cont. 「フロント・オブ・ザ・フロントエンド」と「バック・オブ・ザ・フロントエンド」について