【第3回】品質保証やQAエンジニアを知ってもらうための取り組み

なお、以下の方法はいずれか1つを行えばよいというものではありません。複数のチャネルで多方面から発信することで、より効果を発揮します。

ミーティングへの参加など、直接会話する

もっとも強力な方法は、直接話をすることです。これは皆さんの実感とも合っているのではないでしょうか。

会ったことがある、話をしたことがある、というのは相手との関係性を良くするうえでとても重要です。とくに1人目のQAとしてさまざまな品質向上活動をしていく場合、開発者に工数を割いてもらったり、いままでのやり方を変えてもらったりと、拒否反応を示される可能性のあるタイミングが多々あります。そうしたときに快く協力してもらえるか、しぶしぶ協力してもらえるか、あるいは協力してもらえないのか・・・この結果は会話の量に大きく左右されます。

会話の機会を持つ方法として私が実践したのが、Joinしてすぐに行った「全開発部ヒアリング」です。これはその名前の通り、すべての開発部に対して「今どのような流れで開発していますか？」「どのようなテストをしていますか？」「品質について困っていたりしますか？」など、いろいろな内容を直接会議をして聞くというものです。また会議の冒頭10分程度では自己紹介やQAエンジニアの位置づけ、今後どう貢献したいかなどを説明し、ヒアリングとあわせて相互理解の機会として活用しました。

私は横断部門の1人目QAとして仕事をしているため、上記の方法を取りました。もし個別の開発部における1人目QAとしてJoinした場合や、会社規模がそれほど大きくなく開発組織が1つという場合は、「全員と1on1ミーティングをする」という手段も検討できるでしょう。部単位での代表者からのヒアリングと比べて、より深い話ができ、つながりも強化できるでしょう。

その他、上司や同僚のスケジュールを常にチェックしておき、呼ばれていない会議でも自分から突撃する、という強者QAも居ます。その方はオープンスペースから「テストが～」等関係ありそうな単語が漏れ聞こえてきたときにも話に入っていったそうです。

勉強会や輪読会の開催

ミーティングへの参加に近いものとして、QAエンジニアとして勉強会や輪読会を開催する、という方法もあります。

一般で行われているのは、JSTQBのシラバスを輪読したり、とくに若手の開発者に対して「品質とは？」や「テストとは？」といった内容を伝える勉強会などです。私自身も入社直後から継続的に勉強会を開いています。

勉強会や輪読会というと、知識を伝えるというイメージを持たれるかもしれません。確かに、ソフトウェアテストやQAに関しては開発者よりもQAエンジニアのほうが詳しいことが多いでしょうし、QAとしての視点で伝えられることはたくさんあります。しかし、私は勉強会や輪読会はただの勉強の場ではなく、むしろ生の情報や思いを直接やりとりするコミュニケーションの場だと捉えています。

生の情報、というのはつまり、現場で実際に開発業務を行っている方の視点での情報です。「今こんなことで困っていて」や「本にはこう書いてあるけど、実際にはそううまくもいかなくて・・・」など、先に挙げたヒアリングよりもカジュアルな形で本音が聞ける可能性があります。勉強会で伝えている内容や輪読会で読んでいる本の内容はあくまでもトリガーであり、より価値があるのはそこから出てくる開発者の本音や声、だと考えています。

また、開催している側から参加者に対しては、思いや熱量を伝える機会でもあります。1人目のQAとして、組織をこう変えていきたい。こんなことをやっていきたい。そのような思いというのは、1回や2回全体周知をしたところで伝わりません。むしろ個別に、頻繁に、何度も伝えてやっと浸透していくものです。そのため、品質文化を浸透させるという大目標には、こうした勉強会や輪読会の場を活用することも有効です。

少し大きな話になりましたが、純粋に接触機会が増えるため、QAエンジニアや品質に関する認知、という点でももちろん有効です。

ちなみに私は勉強会・輪読会の他に「ライブテスティング会」も開催しています。これは、開発チームに提供してもらった実際のアプリケーションを、ビデオ会議で画面共有しながら探索的テストをするというものです。テストする側も、される側も、かなり緊張するイベントなのですが、QAエンジニアやテストエンジニアが何を考えてどうテストしているのかを生で見てもらう良い機会になっています。こちらも認知という意味ではとてもオススメです。

品質やテストに関するナレッジベースをつくり、育てる

上記の2つは、同期的に何かを伝えて認知してもらう、いわばアクティブな方法でした。しかし、アクティブな方法だけでは限界があります。ほぼ自分が会議や勉強会をしている間しか、認知の向上につながらない、という点です。

そこで私がオススメしたいのは、社内Wikiなどに品質やテストに関するナレッジベースをつくり、育てていくことです。このナレッジベースはいわば1人目QAの分身のようなものです。

テストに関する用語や考え方、社外の動向やツールのノウハウなど、知り得るいろいろな情報を残しておきます。こうすることで、組織の誰もが好きなタイミングで情報にアクセスでき、そこから「＊＊＊について相談したい」「＊＊＊について教えて」といった声がけを得られる可能性が出てきます。

また、このナレッジベースは基本的に年中無休です。1人目QA本人が何か別の仕事をしている間にも、誰かがそれを見て問題を解決できるかもしれませんし、知りたかった情報を得られるかもしれません。これによって、知らない間に誰かの役にたち、認知向上につながることもあります。

複数のチャネルで接触機会を増やしつつ、QAを知ってもらおう

今回は品質やテスト、それからQAエンジニアについて、開発組織内で認知してもらう際に有効な取り組みについてご紹介しました。

本記事で挙げた他にも、できることはあると思います。方法やチャネルは複数持つことが有効です。直接対話する機会を持ちつつも、ナレッジ等はできる限り多く、かつ見える形で公開しておいて接触機会を増やすようにしましょう。

連載一覧

【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方
【第2回】組織に品質保証を浸透させるアプローチ
【第3回】品質保証やQAエンジニアを知ってもらうための取り組み
【第4回】1人目QAのスタートは開発組織の現状把握から。やるべきこと・把握すべきこと。