はじめに
本ブログは、ソフトウェアテスト - Qiita Advent Calendar 2024 - Qiita の3日目です。
2日目は usk_ymst_P さんの テストレベルってなんなの？ でした。
さて、11月15日にテストラジオのパーソナリティ2名、テスターちゃん著者、会場提供いただいたLIFULLさんのQAエンジニア２名、私ぱいんで発表会を行いました。
発表会は様子はこちらです。 togetter.com
発表資料のふりかえり
アウトラインとしては、私がこれまで10年ちょいQAエンジニアとして活動してきた中で、様々なプロジェクトから相談を受けたときに聞いてきたこと、気にしていたこと、流れなどを言語化しました。
発表の大前提
コスパの意味
タイトルにもある通り、「コスパ全振り編」となっています。ここでの「コスト＝私の工数」「パフォーマンス＝プロジェクトの品質改善の効果」を指しています。したがって、最初のオファーでの会話では概略をチラッと教えてもらい、事前調査は行いません。また、60分でヒアリングからネクストアクションを決めるところまで行います。
テストコンサルタントを目指して
言葉の定義としてあっているかわからないですが、目指すところはテスト相談を受けるコンサルタントのつもりです。課題の核心を突いて、品質改善を最大化したいと思っています。なお、ここでの品質とは、プロダクト品質、プロジェクト品質、作業品質など相談相手が一番求めているものを探しながら決めていきます。
発表内容の補足
質問内容の特に説明したいところ
Qualityの部分は比較的オーソドックスな質問をしているつもりです。
「公開区分」は、組織によってはPoC(Proof of Concept; 仮説検証)のプロダクトから限定公開（クローズドβ）、一般公開まで幅広く行っている場合があるため、質問に入れています。
「相談者がこの課題を私が肩代わりしたらやりたいこと」は、相談者がテストを変わってもらえるとしたらやりたいこと、つまりテストよりも優先したいと思っていること、を引き出す質問です。この質問によって、質問者の最大の関心事、プロダクトやプロジェクトで心配に思っていることや必ずやっておきたいことが言語化されます。
Delivery については、納期を抑えるというのはもちろんのこと、 「誰に向けてのマイルストーンか」を重視します。
例えば、チーム内の状況共有と社長への報告を考えるとき、伝えるべき情報の内容や伝え方は変えなければならないということがわかるかと思います。
質問を投げかける理由
当日、アイスブレイクのあとにかける一言目は「伺った内容って〇〇だったかなと思うんですが、合ってますか？」といった言葉から始めることが多いです。すると、相手から詳細な状況や気になっていることが出てきます。
一通り話をしてもらってから、質問にある内容を深堀りしていくのがよくあるスタイルです。
さて、ここから様々な質問を投げかけるのですが、この段階では相手がモヤモヤした表情を浮かべていることがよくあります。
これは、話した内容が相談者自身もしっくり来ている確信がないのかもしれないなと考え、先述した「相談者がこの課題を私が肩代わりしたらやりたいこと」を聞くといった流れです。
若手に時々あるのですが、自分で言語化しきれていないということはあるかと思います。こうして相談相手になっている私自身も若手と呼ばれていた頃は説明が非常に下手でした。
そうしたときに、様々な質問の仕方によって相談者の頭の中にあるモヤモヤを言語化してもらうということが、相談者自身にとってもスッキリの一助になることはあるかと思います（私が、誰かに壁打ちしてもらうときの目的は大抵これです）。
相談者自身が言語化することをアシストすることによって、思考が整理されます。さらには、整理された事項から何から取り組むべきか、一番の困りごとはなにかといった確信に一緒に考えることで迫ることができているのでないかと思います。
相談時間内は、チームとして変えられることにフォーカスする
組織的に短期的にはどうしようもならないことはあるでしょう。したがって、現状手が届きそうなことやサポートできそうなことについての議論に専念します。
ただし、変えられないような組織の根本的な課題に対しては、マネジメントにレポートするようにはしています。
発表では触れなかった話
終わったあとにやっていること
短縮版議事録まとめ
議事録担当者がいなかった場合、私がまとめページを作成します。
10分程度でまとめます。これは10分を20分かけたところで成果が2倍にはならないためです。ここもコスパ全振りです。そこで、最低限、当初の相談事項、相談の中で出てきた重要な課題、ネクストアクションは書くようにしています。
マネジメントへのフィードバック
マネジメントへのフィードバックを行います。これは、実際どういう困り事をもっていたか、それに対してどういったネクストアクションを提案したか、フォローをどう進めるか（頻度、体制）を共有しつつ、マネジメントとの課題感に対して、レビューしてもらうためのアクションです。
FAQ
こうした質問はワークシートにしたら良いのではないか
はい、説明するのが得意でない方など相談者によってはワークシートにするほうが効果的であるかもしれません。テストについて詳しい人と紹介され、まだ会話を一言二言しか話していない状態で、ワークシートのファイルを渡されたらどう思うでしょうか？私が相談者であれば、萎縮してしまいます。過去にはワークシートを使っていた時期もありますが、最近は当日ヒアリングするようにしています。
参考文献と推す理由
ここでは、発表に至るまでに参考にした資料を3点紹介します。どれも私が尊敬するソフトウェア開発者の知恵と経験が詰まった名作です。
違和感のつかまえかた 組み込みシステムの開発者（テスター）としてやっていること - JaSST ‘19 Review
この発表は、私も企画運営をしているJaSST Review (ソフトウェアレビューシンポジウム)で発表いただいた内容です。
「開発の現場で、違和感を感じたら、良い製品を作るためには行動を起こさなければならない」という壮大な提言から始まり、違和感とはなにか、どこで違和感を感じるのかをプロダクトだけではなく、様々なシーンから感じることを説明されています。また、筆者がこれまで培ってこられたコツの説明も必見です。
説明できるテストをつくるためにできることを考える - JaSST ‘24 Tohoku
こちらは、今年のソフトウェアテストシンポジウム東北で発表された内容です。
私の説明資料のDeliveryの部分について、参考にさせていただいています。
初心者向けとのことですが、テストを説明するために考慮すべきことが体系化されており、テストエンジニアであれば、一読することをおすすめします。
悩めるエンジニアのためのぽけっとファシリテーター (同人誌; 紙冊子のみ?)
具体的な「問いかけ」にフォーカスをした同人誌です。この書籍は、テストに限らず日常においてもモヤッとしたときに眺めるのもよし、パッと開いた問いに答えるのも良しです。
私の調べた限りでは電子書籍化はされていません。もし、読んでみたい方は私までお声掛けください。
最後に
いかがでしたか？
私自身これが正解だと思ってませんし、様々な経験や失敗を経て今ここにあるという話なので、もし参考になれば幸いです。
また、この話に興味を持ってもらった方は、Xやオンラインでお話するのも歓迎です。よろしければどうぞ。 https://x.com/pineapplecandy
明日は、 sibukawa さんのDBUnitでハマった話です。お楽しみに。
