会社や部署の1人目QAとしてJoinした場合、「このタスクをこなしてください」といった、やることが定まった状態とは限りません。

むしろQAに限らずその組織におけるそのロール1人目というのは、そのロールの役割や組織内の位置づけなどを自ら定めるところからのスタートになります。このことを、私は「仕事をつくる」と表現しています。

QAとして仕事をつくるには、開発組織の現状を把握する必要があります。単純にテスト業務を巻き取ったとしても、直後にはある程度バグが減るかもしれません。しかし、組織としてはそれで満足とはならないはずです。とくに正社員のQAとしてJoinしたのであれば、たとえば組織づくりや仕組み化などを通じ、1人目のQAがずっと手を動かし続けなくとも改善される状態を期待されます。

本記事では、このような仕組み化のための現状把握について、その手段と内容をご説明します。

これから組織に1人目のQAエンジニアを迎え入れようという方や、1人目QAとしてJoinする方に参考にしていただけると幸いです。また、いわゆるテスト会社に所属するQAエンジニアとして客先に入る方にもヒントとなる部分があると考えています。

<1人目QAとしての立ち回り 連載一覧>※クリックで開きます

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

現状把握の方法

開発組織の現状を把握するためには、いくつかの方法があります。もちろんどれか1つというわけではなく、複数の方法を試したり、あるいは時間をあけて何度も行うことも必要になるでしょう。

直接ヒアリングをする

まず考えられる方法は、直接ヒアリングをして話を聞くことです。とくに入社直後であれば、あいさつもかねて会話はしておいたほうが良いでしょう。

テキストチャットのみでのやりとりでも一定距離は縮まりますが、会話すること、それもできれば直接会うことの効果は大きいです。

世の開発者の中には、残念ながらQAエンジニアに対してネガティブな印象を抱いている人もいます。開発スピードが遅くなったり、重箱の隅をつつくような指摘をたくさん起票されてあまりおもしろくない、など理由はさまざまです。理由は何にせよ、これまで居なかったQAエンジニアが組織にやってきた、という状況はある程度心理的なバリアが張られている前提で行動するほうがよい、と考えています。

そのため、まずはビデオ会議なり、対面のMTGなりで直接話をすることからはじめましょう。

また、余裕があれば複数のロールや職位の方から話を聞くのも有効です。

開発部の部長から見た組織の現状と、開発メンバーから見た組織の現状とは多少の違いがあるものです。今後QAとしてなんらかの取り組みをするうえで、一方の視点だけで判断するとうまくいきません。複数の視点から組織の現状を捉えることが大切です。

ちなみに、開発組織の規模にもよりますが、世のQAの中には「入社後にエンジニア全員と1on1をしていろいろ話を聞いた」という猛者もいます。

アンケート調査を行う

直接ヒアリングする他に、アンケート調査を行って質問項目に回答してもらう、という方法もあります。

コミュニケーションや会話の機会としては効果が減ってしまいますが、組織に複数の開発部門・開発チームがあって、それぞれの違いや差を把握したい、といった目的に対してはアンケートも有効です。

また、アンケートで開発部門に対して行う質問を通じて、QAとしての考え方や価値観、組織をどうしていきたいのかなどの思いを伝えることにも繋がります。

『サーベイ・フィードバック入門』という書籍には、以下のように書かれています。

・あなたの職場では、オープンにコミュニケーションできていますか?
・あなたの職場では、メンバー同士は信頼しあっていますか?

言うまでもなく、こうした質問項目を何度も問うこと自体が、「職場ではオープンにコミュニケーションすべきである」「メンバー同士は信頼しあうべきである」というメッセージを、暗に伝えているのです。

サーベイ・フィードバック入門

QAに置き換えて考えると、たとえば開発組織に対して「単体テストのカバレッジを計測していますか?」と問えば、それはカバレッジ計測が大事である・やりましょうというメッセージになります。

ただ漠然と「今どうなっていますか?」というアンケートを行うのではなく、伝えたいメッセージを意識した状態で調査項目を設計すると、より効果的なアンケートになるでしょう。

実際にチームで一緒に働く

現状について開発チームに聞くのではなく、チームの一員として実際に業務を行うことで、生の情報を得ることができます。とくにテスト等のQA活動における課題を体感するには、この方法が一番です。

入社直後のQAは、既存の仕組みやプロセスを最もフレッシュな目でみることができます。そのため、開発メンバーにとって「あたりまえ」になってしまっているけれども対応したほうがいいところ、などを見つけられるでしょう。

何を把握すればよいか

ここまでは現状把握のためにやるべきことの説明でした。とくに意外なやり方はなかったかと思います。

ここからは開発組織の現状把握といったときに何を把握すればいいのかを説明します。

開発プロセスやテストプロセス

まずは、既存の開発プロセスやテストプロセスについて知ることが大切です。

長く続いている開発チームなどではこのあたりが暗黙知になっていることもままあります。その場合は、QAが自身の把握のためにプロセスをドキュメント化するところから始めるのも有効です。手近なところからチームに貢献できますし、図などにプロセスを書き起こそうとするといろんな方から「実はここがプロジェクト規模によってやらないときもあってね・・・」などの追加情報が出てくることもあります。

そのようなチーム内での細かいルールなどを知る土台にもなるため、現状の開発プロセスやテストプロセスを知り、可視化することがオススメです。

理想・現実・問題・課題

現状把握の先で改善活動につなげることを考えると、当然開発チームの問題を把握することも必要です。

私がQA業務でよく使う図をご紹介します。

この図は、よく混同されがちな「問題」と「課題」の違いについて表した図です。

本記事では「現状把握」と表現していますが、知るべきなのは今の状態だけではありません。

開発者やマネージャーが考える、理想の状態とはどのようなものかを知ることも大切です。もしかしたら、理想が明確になっていないかもしれません。その場合は、QAがリードして一緒に理想と現実を明確にするのも良いでしょう。

そこで明確になった理想と現実とのギャップが、今の開発組織における「問題」となります。

そして、QAはそこから「課題」、すなわち理想と現実とのギャップを埋めるための施策を考え、行うという流れです。

この図に基づいて考えていくことで、各要素が整理され、かつ周囲とのすり合わせが行いやすくなります。

現状とれているデータ

開発組織における問題の把握とともに行うべきなのが、現状どのようなデータがとれていて、どのように管理・集計・公開されているか、です。

大きな目的としては、QAが開発組織での改善活動を進める際に、その効果を定量的に示すことです。昨今は4 Keys Metricsなどがよく知られていますが、品質についてもなんらかの指標に基づいて改善の取り組みを行うべきです。

指標としてはたとえば、障害発生件数やテスト期間、不具合対応工数などさまざまなものが考えられます。これらはその組織ごとに選択・検討するべきものなので、「これを測っておけばOK」という絶対的なものはありません。

ただ、避けなければならないのは「なんとなく」で改善活動を行うことです。

とくに1人目のQAは、その組織内での評価が固まっていない、いわば不安定な状態です。極端なことを言えば、「居てもとくにメリットを感じないよね」と思われてしまう可能性もあります。そのような事態を避け、見える形の成果を出していくには、定量的な成果を意識していくことが大切です。

そのために、現状とれているデータは何かを把握し、それを元に改善ポイントを検討するのがよいでしょう。

一方、1人目のQAが入った時点では品質に関するデータやメトリクスがとくに集計・公開されていない、ということも多々あります。この場合は、QAとしても「**が*%改善しました」といった説明ができないため、他の工夫をする必要があります。

私がこうした状況で鉄板だと思っていること、そしてまさに今行っていることとして、「現状を計測・可視化するための仕組みをつくる」ことがあります。つまり、今可視化できていないのであれば、可視化すること自体がひとつの成果である、という理屈です。

先にご説明したアンケート調査なども該当しますし、SCMなどの開発ツールからさまざまなメトリクスを取得することもできます。

こうしたデータ収集や可視化からスタートして、品質改善に取り組むポイントを選ぶことも1人目QAの仕事のひとつだと考えています。

開発組織の今を知るところから改善をスタートしましょう

本記事では、1人目QAが開発の改善やさまざまな仕組み化を行ううえで必要となる現状把握の方法や把握すべきことについてご説明しました。

とくに品質面で課題のある組織などでは、1人目のQAがJoinした直後は「とにかくテストを!」といった目の前のことに意識が向きがちです。これ自体はやむをえないことですが、長期的には目先のテストを行うだけでは、組織全体が良い方向に向かっていきません。

まずはQAとして、開発組織の今を知るところから始めて、少しずつでも改善を行っていきましょう。

連載一覧

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

SHARE

  • facebook
  • twitter

SQRIPTER

伊藤 由貴(いとう よしき)

記事一覧

テスト自動化エヴァンジェリストとして、エンジニア育成・テスト自動化コンサルテーション・部署の立ち上げ・マネジメントなどを経験。
現在は複数Webサービスを運営する会社の横断部門にて、QAエンジニアとして活動中。

RANKINGアクセスランキング
#TAGS人気のタグ
  • 新規登録/ログイン
  • 株式会社AGEST
NEWS最新のニュース

Sqriptsはシステム開発における品質(Quality)を中心に、エンジニアが”理解しやすい”Scriptに変換して情報発信するメディアです

  • 新規登録/ログイン
  • 株式会社AGEST