この連載では、1人目QAとしてのチームの立ち上げや組織づくりに関して、私が実践したことや試行錯誤中のことも含めてお伝えします。
前回の記事では、チームビルディングの概念や考え方の説明と、QAチームにおけるチームビルディングについてタックマンモデルの各段階をもとに概要をご紹介しました。
今回は、QAと開発者という、異なるロール間でのコミュニケーションについてご紹介します。
コミュニケーションというと非常に広い話になりますし、開発者とQAの関わり方や組織の形なども会社によっていろいろな形があります。ただ、私が他社のQAの方から「開発者とのコミュニケーションに課題があって・・・」と相談をいただいて話を聞くと、いくつかのパターンとそれに対する基本的な対応方法があるように感じています。
そこで、この記事ではQAと開発者とのコミュニケーションに関してよく聞く課題と、とくにQAと組織を立ち上げていく過程で気をつけるべきことについてご紹介します。
QAと開発者とのコミュニケーションにおける課題
QAにとって、開発者との関係性というのは非常に大切です。これは実際にQAとして働いている方にはほぼ確実に同意していただけるのではないでしょうか。
QAだけががんばってもプロダクトの品質向上には限界があり、開発者やマネージャー、デザイナーなど他のさまざまなロールの方と協力して初めて品質を高められます。特にQAが業務レベルで関わるのは開発者である場合が多いはずです。
そのため、開発者との関係性がよければ互いに協力して品質を高めることができますし、逆に関係性が悪いとなかなか同じ方向を向けず品質にも悪影響があります。最近よく聞く言葉で言えば、開発者とQAが協調するとか、互いにロールの垣根を越えて（越境して）働くとか、そういった動き方が良しとされていますね。
こうした理想の姿については、それほど反対されることはないかと思います。
しかし、実際に現場でQAとして働いている方の話を聞くと、開発者とQAとの間のコミュニケーションについていろいろな問題があるようです。
たとえば、技術面で開発者とコミュニケーションが取りづらい、品質に対する温度感の違いがある、QAに対してネガティブなイメージを持たれている、などです。そうした問題をいろいろな方から聞いた中で、大きく以下2つの要素が多く出てくると気づきました。
- QAエンジニアの役割や業務が開発者側に伝わっていない
- コミュニケーションの土台が不足し、開発者体験が悪化している
それぞれについて、どのように対応すればよいのか考えていきましょう。
QAの役割や業務に対する理解を得る
ひとつめは、QAの役割や業務が開発者側に伝わっていないという問題に対する対応です。これは単純に問題の裏返しで、QAの役割や業務に対して理解を得ましょう、という話です。
とくにQA組織をこれから立ち上げる場合はQA組織の位置づけ、どのような役割を担うのか（それによって開発者の動きがどう変わるのか）などが明確になっていないと、すれ違いが発生します。
よく聞く具体的なお悩みとしては、大きく2パターンです。
- 品質に対する考え方に関するもの
- 開発者が「テストはQA・テストエンジニア側のしごと」と考えている
- 品質に対する開発者の意識が低い、大事だと思ってくれていない
など
- QAの役割・動き方に関するもの
- QAが居ると開発スピードが遅くなる、と思われている
- 重要でない細かい指摘をたくさんされると思われている
など
これらの開発者からQAに対する誤解については、ていねいに説明をして理解を得ていくことが大切です。
方法1：QAがやること・やらないことの宣言
これは私が事あるごとにオススメしている方法なのですが、その組織の中でQAエンジニアが何をやるのか＆何をやらないのかを宣言することで理解してもらう、というものです。
たとえば私は現在のQA組織を立ち上げるにあたって、入社してすぐに「QAが決めた基準を守らせたり、アセスメントやメトリクスなどによる定量目標を強制はしません。品質はQAだけが考えるものではなく全員で考えるもので、合意・納得のないルールには意味がないからです」と宣言をしました。
実際に開発者からは「QAが来ると聞いていろいろ縛りがきつくなるのかと思ったけれど、最初に無理やりルールを押し付けないと聞いて安心した。協力できそうだと思った」というフィードバックをもらいました。
一般に「QAがやること」を明確にすることは行われますが、「QAがやらないこと」もセットで伝えることで、開発者にとっての安心につながり、QAに対する意識や見方がポジティブな方向に変わることもあります。
方法2：開発者も含めた全員が品質に対して関係していることを伝える
最近では少なくなってきているように感じますが、「テストはQAに任せておけばいい、品質を考えるのはQAの仕事」といった認識が開発者にあって困っている、という声を聞くこともあります。
この場合は、開発者も含め全員が品質に関係していると理解してもらう必要があります。世の中のQA担当者はさまざまな方法で開発者にアプローチしていますが、たとえばコストに関する以下の図はよく用いられています。
つまり、テスト工程でQAやテストエンジニアが問題を見つけるよりも、コーディング時や設計段階などで問題を見つけたほうがプロジェクトにとっては低コストで済む、ということです。そのため、問題はテスト工程で見つければいいやではなく、開発者も積極的に品質に関する活動やテストを行うべきである、という理屈です。
他にも、体重計とダイエットのメタファを用いることもあります。
ダイエットをしているとき、体重計に乗れば現在の体重がわかりますが、体重計に乗ること自体にダイエット効果はありません。そこでわかった体重をもとに、運動をしたり、食事を見直したりといった行動を起こして初めて体重が減少します。
品質もこれと同じで、テストをすることで現在の品質やどこにバグがあるか等がわかります。しかし、何度テストをしても品質はよくなりません。見つかったバグを修正することで初めて、品質が良くなるのです。
QAやテストエンジニアがいくらテストをしたとしても直接品質を高めることにはならず、開発者によるバグ修正が必要です。つまり、開発者も品質に十分関係している、という理屈です。
ちなみにこのメタファは『ソフトウェアプロジェクトサバイバルガイド』という書籍に登場するそうです。
とくにQA組織の立ち上げ時がカギ
とくにQA組織の立ち上げ時というのはこの「理解を得る」もしくは「誤解を解く」ためにとても重要なタイミングです。組織立ち上げに向かって動き始めるタイミングで、QAの役割や業務に関する価値観・大事にしたいことを打ち出していくと、開発者からも「自分たちに協力してくれるんだ」「メリットが期待できるんだ」と感じてもらえ、協力関係が築きやすくなっていくでしょう。
QAに関する理解については以前【第3回】品質保証やQAエンジニアを知ってもらうための取り組み | Sqriptsに記載しましたので、こちらもぜひご覧ください。
QAとして信頼を得る
もうひとつはコミュニケーションの土台が不足する問題への対応で、ひとつめとも関係しますが、開発者をはじめ他の職種の方から信頼を得ることが大事です。
とくに若手QAの方から相談されることの多いものとして「開発者と技術的な話ができなくて・・・」というものがあります。開発経験がない状態で、テストエンジニアやQAエンジニアになった方だと「開発者が普段話している内容がわからない」「技術的な話についていけない」と感じ、そこから開発者とのコミュニケーションがうまくいっていないと感じることが多いようです。
Developer eXperience Day 2024にて、AtCoder代表取締役社長 高橋直大氏の講演では以下のような内容が話されていました。
- 開発者体験はチームメンバーによっても決まる
- 多くのメンバーにとって当たり前のことを知らず、いちいち説明しなければならない状況が発生すると開発者体験が悪くなる
参考：アルゴリズムと開発者体験 – Tech Team Journal
私はこの講演をリアルタイムで聞いていて「なるほど確かに」と感じました。その後、よくよく考えてみると、開発者とQAとの間でのコミュニケーションにおいても同じことが言えると思いはじめました。
開発者とQAとではスキルセットや持っている知識に違いはあるものの、たとえば一般的な開発プロセスや、プログラミングのごく基礎的な内容については双方にとって「当たり前」とみなされる可能性があります。それをQA側が知らず、かつ理解しようという姿勢がない場合は、開発者体験が低下してしまいます。そうなってしまうと、「QAの＊＊さんがいると全体の効率が落ち（たように感じられ）るよね」「品質を高めるうえでは逆効果だよね」と捉えられてもおかしくありません。
では、QAはどこまで何を知っていればいいのでしょうか。この点に関しては絶対の正解はありません。過去の経験上、以下のような内容を把握しておくと開発者とのコミュニケーションの土台になります。
- 一般的なソフトウェア開発プロセスに関する知識
- ウォーターフォールとアジャイル
- 継続的インテグレーション
- テスト対象アプリケーションを作るうえでの基礎的な技術
- WebアプリケーションであればhtmlとCSS、JavaScriptなどそれぞれの役割と、Web上に公開するまでの流れ
- モバイルアプリケーションであればXCodeやAndroidStudioでアプリを作って公開するまでの大まかな流れ
- スクラム関連
- 各種イベントや用語
- チケット管理
- BTS/ITSなどを使ったチケット駆動の仕事の進め方
私がよくオススメしているのは、簡単なアプリケーションを作って動かしてみることです。難しいことをする必要はなく、インターネット上で公開されているサンプルや入門書のサンプルを作る流れを1度体験するだけでもかなり違います。
まとめ
今回は、開発者とQAとのコミュニケーションに関する問題やその対応について考えました。
一般的な同僚とのコミュニケーションに関する工夫、たとえば雑談をしたり一緒にランチをしたりといった接触機会を増やす他に、本記事でご紹介したような内容に気を配っていただけるとよいかと思います。
QAを取り巻く環境は、以前に比べるとだいぶ良くなっているように感じます。QAエンジニアという職種の認知も進んできています。そうはいっても、個々のQAが自分の周囲の同僚から理解を得たり、関係性を構築したりといった努力が不要になったわけではありません。
品質向上につながるアクションとして、開発者とのより良いコミュニケーションができるようにしていきたいですね。
