技術を土台にして自分なりのQAエンジニアを目指す本連載、第9回のテーマは「コーチング」です。
QAやテストの専門性からすると、少し遠い領域だと感じる方も多いかもしれません。正直、私自身、コーチングというものを「なんだか怪しいもの」だと思っていました。
しかし、アジャイルコーチなど現場の最前線で活躍する方々の話を聞くうちに、その認識は大きく変わりました。
人々のアウトプットとしての「品質」を本当に良くしていく、あるいは組織の「品質文化」を変えていくためには、コーチングの技術が極めて有用であると考えたのです。
その気づきから、私自身も本格的に個人やシステムに対するコーチングを学ぶため、スクールに通い始めました。
今回は、私にとって最も直近で築かれた新たな「土台」であるコーチングについてお話しします。
記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合
「教える」から「引き出す」への転換
QAエンジニアとして活動する中で、私は品質やテストについて、比較的解像度高く言語化してきた、あるいは『自分にはそれができる』という自負がありました。
しかし、その自負が、時にチームに対して「専門家としての正解を押し付ける」ような振る舞いを生んでしまっていたと今では思います。
テストにおいても、品質保証においても、「こうあるべきだ」という強い思いがありました。
そういった状態で特に「QAエンジニア」という役割を担ってしまうと、「高圧的で怖い人」として映ってしまうことも少なくありません。
もちろん、専門家として意見をはっきりと伝えることが必要な場面は多々あります。
しかし、人の行動やマインドセットを変容させようとするフェーズになったとき、専門家からの一方的な指摘だけでは人は生き生きと動くことは困難だと気づいたのです。
そんな中で、コーチングという技術を詳しく知る機会がありました。コーチングという技術あるいはその関わり方が、その人の内発的動機を高め、行動に繋げることができるものだと知りました。
そして、実際にコーチングを実践するときには、単なる「聞く」「質問する」といった目に見える表面的な技術だけでなく、自己基盤やコーチングマインドが大事だと知ったのです。
私が実際に通った銀座コーチングスクールでは「コーチングピラミッド」という形で示されています。
https://www.ginza-coach.com/overview/feature/curriculum.html
（参照日:2026/3/21、最終更新日2026/1/20）
自己基盤
まず、コーチングピラミッドにおける「自己基盤」という考えを示しておきたいです。
これは私の理解で言えば、コーチ自身がクライアントに対して恥じることのないあり方を体現していることです。「プロのコーチ」としてプロフェッショナリズムを持っていることだと考えています。
これはQAエンジニアとしての土台にも同じことが言えます。私自身の自己基盤もまた、「プロであること」に加え、例えば「高い倫理観を持つ」「自分自身を裏切らないこと」をベースとしています。
安易に「見栄えのいい専門家」を演出してしまうと、結果として自己欺瞞に繋がり、それは自分自身の自己基盤を揺るがしてしまうと考えています。
泥臭くても自己開示し、困難に対しても正面から向き合えるような、「良いクライアントの鏡でもある」という自負が、私自身のプロフェッショナリズムを育てていると考えています。
コーチングマインド
コーチングを学んだことによる最大の収穫は、「答えは相手の中にある」というマインドセットを得たことです。
コーチングを書籍などで表面的な手法だけ学んでしまうと、「質問」や「聞く」といったスキルで終始してしまうことも少なくありません。私自身も実際にそういった過ちを犯していました。
今ではコーチングマインドや自己基盤、信頼関係といった土台の構築こそが、専門性として身につけるべき本質だと思っています。
相手の中にある視点や気づきをどのように発見し、どう繋げていくか。
この「あり方」こそが、特にQAエンジニアがコーチングを学び、品質文化を醸成する上で非常に重要だと確信しています。
その「答え」は、実は相手が自覚していない場合があります。
むしろ「答え」に向き合う過程で、相手を困難に直面させるようなこともあるかもしれません。
そのような場合であっても、相手のプロフェッショナリズムを心から信頼し、目を背けたくなるような事実を鏡のようにフィードバックすることも、コーチとして時に必要になると考えています。
コーチングの技術を品質保証に活かす
コーチングには「聞く」「認める」「フィードバックする」「質問する」といった技術があります。
上記で述べたように、これらの技術を土台なしに実施することは、本質を欠いたまま適用してしまう危うさがあります。
一方で、正しくこれらを用いて、クライアントの壁打ち相手になったり、適切な問いかけを行ったりすることは、品質保証の活動と非常に相性が良いです。
ここからは、コーチングの技術が、これまでの連載で触れてきた専門性とどのように組み合わさるのかを紹介します。
専門性の組み合わせ：テスト計画(リリース基準)との組み合わせ
テスト計画を立てたり、リリース基準をチームで合意したりする際、コーチングの「問いかけ」や「フィードバック」の技術が力を発揮します。
第３回でテストマネジメントは「合意形成」の技術だと述べましたが、その合意を真に納得感のあるものにするための具体的なアプローチの一つが、このコーチング的な「問いかけ」です。
QAエンジニアが一人で基準を決めるのではなく、チームに対して次のような問いを投げかけます。
- 「どういう状態になれば、自信を持ってリリースできますか？」
- 「あなたがステークホルダーであればこの製品に対してどう感じますか？」
- 「あなたが知っているステークホルダーはどのような人ですか？」
このように相手の思考や気づきを引き出すことは、チームが品質に対するオーナーシップを持つことに役立ちます。
自分自身の言葉で紡ぎ出したオーナーシップは、「生きた品質文化」として根付いていくと考えています。
専門性の組み合わせ：テスト実行との組み合わせ
テスト実行を通じてメンバーの成長を促す場面でも、コーチングは有効です。
テスト実行中に手が止まっているメンバーや、バグを見つけたメンバーに対して、「こういう視点でテストしなさい」と教えるのではなく、気づきを促す問いを投げかけます。
- 「今、テストを実行していて何に気づきましたか？」
- 「もし自分ではなく、別のユーザー(あるいは尊敬するテスター)だったら、次にどうすると思いますか？」
- 「あなたが作り手だったらどんなフィードバックを望むでしょうか？そのためには何をすればいいですか？」
「こういう視点があるよ」と教え込むのではなく、「あ、こういう視点もあるんだ」と自分自身で気づいてもらうこと。
これが、テスト実行における個人のスキルアップや深い洞察に繋がります。
おわりに
QAエンジニアとしてコーチングの技術を扱う上で重要だと考えている点があります。
それは「コーチング技術を自分自身の存在価値のため、あるいは相手のメンタルケアのために使わない」ということです。
QAエンジニアの専門性とコーチングを複合した時に、個人の感情やモチベーションだけではなく、「システム（構造）」に直面することがあると感じます。
例えば、バグが放置されがちな現場があったとします。
ここで「どういう理由で直さないの？（本当はどうしたいの？）」と個人のモチベーションを聞いたり、あるいはただ共感して寄り添うだけでは、根本解決にならないと感じています。
コーチであると同時にQAエンジニアとして考えたとき、このような状況では品質保証の原則である「源流管理」に立ち返ることも時には必要です。
プロのQAエンジニアが行うコーチングとは、我々が理解できていることや、ソフトウェアの動作、バグの発生状況といった「客観的な事実」と向き合うことです。
そして、「この事実が、今の私たちのシステム（開発プロセスやチームのコミュニケーション構造）のどこに問題があることを示しているのか？」という問いを立て、メンバーのプロフェッショナリズムを信じて共に探索していくことだと考えています。
コーチングは、ソフトウェアテストや品質保証とは遠い場所にあるように思えるかもしれません。
しかし、それは「プロとしてのあり方」を学び、チームと協調しながら根本的な品質文化を形作るための、非常に強力な技術です。
この新たな土台が、皆さんのQAエンジニアとしての幅を広げる一つのヒントになれば幸いです。
