開発チームと品質保証チームの反目と、解決への道

SoftwareTest

ひさしぶりに、QAまわりの話題です。:)

前段

昨日Twitterで、次のような発言をしたところ、

こんなコメントをいただきました。

（反応ありがとうございます）

前者は、テストは万能ではないよという意味であれば、まったくもってそのとおりですねｗ テストは、欠陥があることを示すことしかできません。

後者については、ソースを探してウロウロしていたら、2008年のこの話であると教えていただきました。開発チームが品質保証チームに不具合の検出を丸投げしてしまったり、品質保証チームが製品のあら探しに終始してしまったり、という問題のようです。QAの仕事はQAチームだけの仕事じゃないだろう、という話ですね。たしかに、これも一つの課題です。（ただし、品質保証のためのテストの有効性の話とは、別の議論であるという認識です。）

さて、ではその取り組むべき課題に対して、どうすればよいのでしょうか？ 自分は答えを持っていません。また、世間で一般的にどのような対策が語られているのかも、不勉強で分かりません。

この点が気になっていたところ、同日に偶然、この話題を扱った記事に出会いました。

この原因について、私なりの答えを書くと、

プロジェクト／組織の体制に問題がある

と思っています。

品質に厳しい組織で、なぜ品質が劣化するのか？ - 現場のためのソフトウェア開発プロセス - たかのり日記

szk-takanoriさんは、「体制のリファクタ」として、次の3つの改善策を提案されています。

1. 「品質保証」ではなく「品質支援」を
（中略）
2. 「やり直し」ではなく「フィードフォワード」を
（中略）
3. 「レビュー」ではなく「検討会」を

品質に厳しい組織で、なぜ品質が劣化するのか？ - 現場のためのソフトウェア開発プロセス - たかのり日記

もしまだ読まれていなければ、ぜひ元記事をどうぞ。どれもなるほどと感じました。

もしかして、「部門や会合の名前を変えるなんて、単なる言葉遊びじゃないか」と感じられたでしょうか？ 一見そう見えますが、名前ではなくあり方を変えようという提案であることは、元記事を読んでいただければ、分かると思います。

関係者が意味のあるかかわり方をすることが、品質保証を機能させる上では大前提です。エンジニアリングにはサイエンスとマネジメントの側面があり、前者を十分に活用するためには、後者を無視するわけにはいきません。


思ったこと

さて、それぞれの項目について、思ったことを書いてみます。

"「品質保証」ではなく「品質支援」を"について

品質支援部門の活動として書かれている内容を見ると、開発担当と品質支援担当が協力し合う姿が浮かびます。

品質「保証」部門というと、製品の出荷停止権限を持つ、監視機構のイメージが強いです。しかし、「支援」であれば、開発担当と品質担当は、良いシステムを作って顧客に迅速に届けるための同士です。

成功する会議と一緒で、「開発担当 VS 品質保証担当」ではなく、「問題 VS 我々」の構図を作ると良いのかもしれません。

"「やり直し」ではなく「フィードフォワード」を"について

実際、開発中に品質支援部門から不備の指摘を受けたとしても、立ち止まってやり直しをするような余裕はないことが多いと思います。次のフェーズの中で拾っていける内容に注力するのが現実的です。

"「レビュー」ではなく「検討会」を"について

「重要であっても書かれていない部分の問題は、見逃してしまいがち」というレビューの問題は、実際そのとおりだと思います。レビュアーが、ドキュメントの漏れを想像して補う引き出しを持っていなければ、やる意味は半減です。

また、開発担当が、レビューを試験や批評であると捉えてしまうと、レビューの目的が、品質の確認ではなく「パスすること」になってしまうという問題もあるでしょう。さらに、レビューの実施や準備は、それ自体が開発を推進する作業ではないので、負担でしかないと考える開発担当もいるはずです。こうなると、レビューはますます、歓迎されないものになっていきます。

考えを出し合う場としての「検討会」を開きたいですね。

szk-takanoriさん、参考になる記事を書いてくださって、ありがとうございます。:)