JaSST Review23に参加しました。

Life is Tech!で１人QAをしているotkyskです。いつもブログをご覧いただきありがとうございます。本日はオンラインでJaSST Review23に参加させていただいたので、その感想と考察を書きます。

JaSSTとは？

こちらを参照ください。ソフトウェアテストを扱っているシンポジウムです。

JaSST Review23に参加した経緯

日頃、レビューをプロセス内で実施している中で今の社内でのやり方とJaSSTが掲げるやり方とで乖離が無いか？１人QAで微力ながらできているか？を振り返る機会にうってつけと考え、参加させていただいた次第です。
＊資料のネタバレが厳禁なので要点を書いていく事になりますがご了承ください。

JaSST Review23の流れ

13:00 - 18:00と長丁場でしたが、以下のようなアジェンダでした。

• オープニング

• JaSST Review23の狙い

  • レビュー活動の言語化

  • レビューの体系化

• Q＆A

• スポンサーセッション

• Lisiさんの講演

• Q＆A

• クロージング

オープニング

要点をまとめます。

• レビューで思い浮かぶものは人によって違う。

• レビューは静的技法でテストできる方法の１つ。

• レビューは完成されておらず、未発展の分野である。

• テスト設計技法に比べて、レビュー設計技法は確立できていない。

これらを踏まえてのセッションと講演が行われました。

レビュー活動の言語化

レビューにはプロセスが存在します。

計画→レビューの立ち上げ→個々のレビュー→共有と分析→修正と報告

ここで、個々のレビューでどういう思考プロセスでレビューを進めていくか？という点がポイントとなります。
思考プロセスは表現できますが、成果物は必須では無いようです。

共有と分析に対しての仮説としては、レビュアーとレビュイーが存在し、レビュアーは成果物に対して、思考をした上で発言をし、それをドキュメント作成者が理解してドキュメントの改善を試みます。
弊社でもプロセスや体系化をしている訳では無いですが、レビュアーとレビュイーがいて、主にPDチームから出される機能仕様書をレビュアーに渡され、機能仕様書の曖昧さや過不足を指摘してFIXを行い、テスト設計した上でレビュイーに落とし込むという流れを踏襲しています。
また、レビューとフィードバックは密接に関わっているか？という疑問が出てきましたが、レビューという言葉の本質を考えると"Re" "View"と、もう一度考えたり話したりすることとやや異なるようです。それと、どのようにして素早いフィードバックに向かう事ができるか？がポイントともなります。

レビューの体系化

現状の典型的なレビューの状態として、「書かれていることに反応し、気がついた事を指摘する」、「レビュー自体の考えが誤っている事がある」という背景があるため、レビューの体系化（バラバラな個々の物事を１つにまとめ、わかりやすくすること）が必要であると言われてます。
今回のJaSST Review23で取り上げられた４点の要点を列挙します。

• レビュープロセスとその実践

  • 利害関係者の関心事のアプローチ

  • 対象成果物に求められることのアプローチ

    • 機能の有無チェックだけではNGで、観点に基づくレビューの評価をつける。（ここはレビュー評価、振り返りは弊社でもやれている）

    • 時間をかけて身につけるのがポイント（繰り返しが必要、止めてはNG)

  • ソフトウェアライフサイクルとレビュー

    • V字モデルではなく、シフトレフトが効果的（弊社ではプロダクトによって完璧なシフトレフトはできていないが、粛々とシフトレフトが自然的に行われている）

    • プロセスの最初から品質を作り込む

    • 観点設計（聞いた限りではテスト設計に近い？）をシフトレフトし、共有〜利用していく事がポイント（弊社学校プロダクトで行われている）

  • レビュー観点（レビューアーキテクチャの要素構成）

    • 誰が何を確認したか？から何を確認したか？へシフトすべき（これは弊社でできている）

      • アドホックレビューをすると重複した指摘が出て効果が薄くなる

      • 人によって観点の捉え方は幅がある

        • この点は１人QAでの落とし穴かと考えられたので組織的に働きかける必要があるとも考えられる

    • 観点があれば雑多な情報群の中から集中して該当を直接探し当てられやすい

    • 書かれるべきなのに書かれていない/書いてあるけど必要な事を見つける

      • 性能、使いやすさ、利用者課題解決など

    • 有効な指摘事項など優先度の高い欠陥・不備を見つけやすい

      • 弊社学校プロダクトは基本優先度付けは行わないが、技術的課題の難易度やリソース、スケジュールによっては次SPに見送りとPdMに判断を委ねる事もある

    • そもそも、観点がないと重複確認や誰も見ていない抜け・漏れが発生しやすい

      • 重複してはいけないという訳ではない

    • 改めて、目的〜観点構造化は難しい

  • レビューアーキテクチャー

    • レビューアーキテクチャーを構築するにあたり、ドキュメントは必須。頭の中での発想、発言だけではレビューが成り立たない。品質も上がらない

    • 観点洗い出し←→同類事項集約←→構造化とブレークダウンして行う

    • レビューアーキテクチャーをいきなり導入するのは困難。組織内の合意、信頼関係が必要。繰り返しと振り返りが鍵ともなる。

• レビュー体系化のこの先

  • 結論からすると未完成。これからも追求していく

Q&A

自分の質問が取り上げられました。経営陣に見せるレビューの指標は何でしょうか？という質問に対してGQMを使ってみてはどうか？とアドバイスを頂けましたので、活用してみようと考えました。

スポンサーセッション

スポンサー会社の紹介でした。割愛します。

Lisiさんの講演

Lisiさんは米国人で、アジャイルテスティングの優秀賞を２０１９年に受賞した方です。今回のJaSST Review23では本人が体験した壊滅的なプロジェクトチームに参画して、彼女の"戦術"で立て直した、一新させたという一例を講演していただきました。

要点はブログに書かれていますが、自分に響いたのはコミュニケーション力を上げるにはコミュニティに参加したり、ブログを発信したりととにかく言葉を発する事。ブログは社内でOKRとして取り入れられているが、コミュニティは是非参加しようと考えています。
あと、Lisiさんの講演でチームの文化が品質の基盤になると言われていましたが、弊社のプロジェクトないし、チームの文化は劇的な改善をするまでもなく、細々とした改善を繰り返していくスタンスであって、品質面にも目が行き届いていて基盤としては壊滅的なものではなく、むしろ成熟に向かっていると考えています。

Q&A

上述しましたが、Lisiさんのコミュニケーション力がとてつもなく高いという事を伺えたので、どうやってコミュニケーション力を身につけたか？という自分の質問に対し、「最初はコミュニケーションが下手だったが、とにかくメモをする、自分は相手の味方です。コミュニティに参加しましょう。」と答えていただきました。

クロージング

JaSST Review23はレビュー手法とLisiさんの講演の２パートで終わりましたが、今回は参加して良かったと考えています。弊社の開発プロセス（だけではないですが）は、一般的かつ先駆者による講演内容において、乖離はしておらず、粛々と活動できていると判断できました。
来年もJaSSTが開催されるので、参加して弊社内、自分で使える情報があれば活用していき、品質、開発スピード、職場環境の向上へと繋げられたらと考えています。
長くなりましたが、JaSST Review23の参加レポートをこれにて終えます。