ISTQB Foundation Levelに学ぶ指摘者のマインドセットとダイバーシティ
はじめに
みなさんこんにちは。
2022年に ASTQB Certified Tester Advanced Level Test Analyst(CTAL-TA) & Test Manager(CTAL-TM) 試験に合格しました、QAの相澤です。
※1 ASTQBはISTQBのアメリカ合衆国支部に相当します。ソフトウェア技術者のテスト技術向上を目的とした資格認定制度です。
JSTQB/ISTQB Foundation Levelのシラバスには「テストの心理学」/"The Psychology of Testing"なる章があり、簡単な上にあらゆる職種や立場の方に寄与しうる内容となっています。日頃指摘や議論をする方向けに本記事をお届けいたします。「そんなんほぼみんなやん！」と思われた方、その通りです（笑）
おもなメッセージ～指摘のコツ
結論から言います。
あくまで 「成果物」に対してフラットに助言しましょう（≠人格否定）
ポジティブアドバイスを活用しつつ、ゴール・理由・背景を適宜説明することで納得感を醸成しましょう（≠ネガティブアドバイス）
色んなチームや個人の持つ特徴を理解し、共通の目的達成に向けて相互尊重しましょう
これらのメッセージに対して更に理解を深めたい方は以降の内容もぜひ。
指摘者の陥りがちな落とし穴
指摘や反論は下手をすれば、相手への人格攻撃と捉えられてしまう行為です。 まずは大喜利的なノリで、あえて悪い例から想像してみましょう。
悪い例①「不具合の起票なのに根拠を書いてないとかどういうつもりなの？直してもらおうと思ってる？」
悪い例②「こんなテストケースではレビューに値しないから出直してくれ。」
悪い例③「詰めが甘い。そんなことを聞いて何がしたいの？」
良かれと思っての言葉が悪く働いてしまっては悲しいものです。 これらに共通して抜けている考えは一体何でしょうか。 私は以下だと思います。
相手のモチベーションへの影響に対する配慮が抜けていること
ネガティブアドバイスに陥っていること
改善すべき方向性、理由、方法などに関する言及が欠如しており、納得しづらいこと
では、どうすれば他の方のパフォーマンスを上手く引き出せる指摘ができるのでしょうか？
今回の例から言えることは、 「指摘が成果物そのものに対する助言ではなく作者の人格攻撃にまで及んでしまうと、かえって逆効果となり得ること」です。
人間が人格攻撃に対して防衛的になり、つい拒絶してしまうことを心理学の世界では「確証バイアス」と言うそうです。相手の方に納得していただき、改善を仰ぐためには 「内容の妥当さ」だけでなく「相手への配慮」 も必要なのかもしれませんね。モチベーションも成果に影響する要素ですので。
指摘者として心がけたいこと
まずは先ほど挙げた悪い例①～③を私なりに良い例に変えることを試みます。 「これが答えだ。」なんて言うつもりはありません。 お時間のある方はワンクッションを挟んでご自身でも良い例を考えていただくのも良いかもしれません。
改善案①「開発者の方に不具合を直してもらうためには仕様の根拠などを示し、改修の必要性を理解してもらう必要があります。仕様の根拠に限らず、そのために必要な情報があれば記載していきましょう。」
改善案②「～機能のテストケースで書かれてある情報を元に、テスト実行が行われたり、開発担当者によって仕様に関する意識合わせがなされます。のちの用途をふまえつつ、関係者がテストケースに対する理解を深められるように説明しましょう。」
改善案③「～の部分の背景や質問の意図などを補足できれば、受け取った方も～さんのニーズをふまえての回答ができるようになります。」
ポイントは以下の3つです。
相手の人格ではなく、成果物や取るべき具体的な行動に焦点を当てていること
ポジティブアドバイスであること（≒代替案の提示）
見据えるゴール・背景・理由について適宜説明することで、受け手の方による納得感の醸成を試みていること
1.に関して、対面での会話のために補足したいことがあります。あえて相手と目を合わせずに成果物を見ながら指摘をすることで、あくまで成果物に対する指摘だというニュアンスを醸し出せるのでオススメです。
3.に関しても補足を。ゴール・理由・背景の説明を全て省いてみたとします。そうすると不思議なことに、結局「俺の言うことだから従え」っていう風になっちゃうんですね（笑）カリスマな方ならともかく、相手の方の納得感の醸成のためにこれらの説明は不可欠です。説明を丁寧にしていくことで、以降は相手の方が自ら考えていく力も蓄積でき、他の局面でも自発的にアドバイスを応用していけるようになります。ゴール・理由・背景の全てを常に丁寧に説明していると今度は時間が足りなくなくなってしまう心配もあります。相手の方の理解度をふまえ、不要なものは適宜省くことで時間と効果のバランスを取ることを試みましょう。
典型的なQA/テスターと開発者の持つマインドセットの違い
ここからは開発やQAに特化した話をしていきます。 我々のようにQAやテストに携わる人間はある意味、指摘をするのが仕事です。 不具合を起票したり、仕様の不備があれば指摘や提案をしたり、レビュー時に指摘をしたり。ソフトウェアテストの仕事は「指摘」とは切っても切れない関係にあります。 いや、対等な立場の者どうしの話であれば、「指摘」というよりも「助言」 のほうが適切だったりするのかもしれません。
日々指摘をする場面が沢山あるだけに、「指摘」の持つ正の側面も負の側面もどちらも良く理解できている必要があります。
一言で言いますと、破滅的な活動としてのQAではなくて、「建設的な批判」の精神を持ち合わせた者として日々活動していきたいものです。 では、どのようにすれば我々は「建設的な批判」を実践していけるのでしょうか。 ISTQB/JSTQB Foundation Levelのシラバスには以下のようなことが書かれています。
対立よりも協力
高品質なプロダクトという、各関係者共通の目的・共通の利益に根ざした協力
テストのもたらす相手方へのメリットの強調
不具合を生んだ相手への非難ではなく、あくまで客観的な視点に基づいた報告&指摘
攻撃的な批判に対して、人が時には防衛的になり得ることへの理解
情報を受け取る相手の理解度を確認しながらの進行
ISTQBのFoundationシラバスによれば、 典型的なQA/テスターは下記のようなマインドセットを備えているそうです。 これらは彼らがキャリアを進んでいくにつれて、次第に成熟していくようです。
好奇心
あえて悲観的なケース/シナリオを思い浮かべる力
常識を疑い、批判的に見る目
細部まで行き届いた思考
良きコミュニケーション/信頼関係構築への関心
一方、同シラバスによると成功している開発者はよく以下のようなマインドセットを備えているそうです。
システムを創り上げていくこと
問題解決思考
解決策の持ち得る負の側面の軽視
自らの作成したプロダクトに対する誇り
QAが自ら作成したテストケースをこっぴどく非難されると嫌に感じるのと同様に、 開発者の方も自らが誇りを持って創ったプロダクトをこっぴどくと非難されるのは嫌なものです。
だって人間だもの。
そういう意味では、プロジェクト内のみんなが 「働く機械」 ではなくて「感情や良識の備わった人間」 であることへの理解が我々の円滑な仕事の進行のための第一歩なのかもしれません。
指摘とは、ある意味では相手に改善を求める行為です。 言い換えると、 「他責」 の側面が強いものです。 指摘をする側の人間も 「自責」 によって自らを省み、相手と共に改善できることがないかを考えていくことも、長くチームとして関わっていく上ではぜひ留意していただきたいポイントです。
あとがき
今回はあえて、ソフトウェアテストに関連する中でも特にとっつきやすい内容を選びました。 もし「もっとテストに入り込んだ内容も読んでみたい」と思われた方がいらっしゃいましたら、以下の記事もぜひ。
これを機に色んな方がソフトウェアテストに興味を持っていただけますように。
参考文献
1. ISTQB Certified Tester Foundation Level (CTFL) Syllabus
『The Psychology of Testing』章
下記ページ右部の「Download Materials」> 「Syllabus」よりダウンロードできます。
https://www.istqb.org/certifications/certified-tester-foundation-level
※2023年7月7日時点
2. テスト技術者資格制度 Foundation Level シラバス
『テストの心理学』章 下記ページのシラバス（学習事項）> Foundation Level> 「- FLシラバス」よりダウンロードできます。
https://jstqb.jp/syllabus.html
※2023年7月7日時点
3. Rex Black氏著、『Advanced Software Testing Vol.2』(RockyNook Computing社)
「7 People Skills – Team Composition」章
4. トム・デマルコ氏/ ティモシー・リスター氏著、『ピープルウエア』（日経BP社）
5. アンドリュー・Ｊ．サター著、『ユダヤ人の頭のなか～The Way of Brain Success』（インデックス・コミュニケーションズ社）
説明責任を果たすことの大切さなど、本書からもインスパイアされました。
執筆者プロフィール：相澤 恒自
幼少期のうち計8年間をワルシャワ（ポーランド）、モスクワ（ロシア）のインターナショナルスクールで過ごす。慶應義塾大学法学部政治学科卒業後、2017年4月に某ソフトウェアテスト専門会社に新卒入社。初年度にJSTQB Foundation Level(CTFL)を取得。約2年半テスト設計やテスト実行に従事し、2020年12月に株式会社SHIFTに転職。2022年1月にASTQB Certified Tester, Advanced Level Test Analyst(CTAL-TA)、同年5月にASTQB Certified Tester, Advanced Level Test Manager(CTAL-TM)を取得。以後、テスト設計やテスト実行をリードする業務、プロジェクト管理ツールのJIRAにより試験報告の仕組みを構築する業務、試験統括の支援業務などを担当。2019年以降は複数の通信キャリアのプロジェクトを行き来しつつ、BSS:Business Support System（業務支援システム）の開発を対象とするグローバルなマルチベンダープロジェクトにて奮闘中。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/
PHOTO： UnsplashのColine Beulin