品質に厳しい組織で、なぜ品質が劣化するのか？

このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。
12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。

今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。

特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。

矛盾する問題

私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。
絶対数で言えば、そんなに多くはないかもしれませんが、その経験上感じているのは、このタイトルの通り、

品質に厳しい組織で、なぜ品質が劣化するのか？

ということ。

レビューを強化したり、テストを強化したり、品質分析を強化したりと、いろいろな対策を打っているにも関わらず、品質が維持されるどころか、劣化することがあります。

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

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

と思っています。

どこの組織でもある程度の規模になれば、品質保証という活動が出てくると思います。
典型的な例として、「バグ密度などの指標を決め、品質見解などを求める」、ということがありますが、結果をチェックされるために、それを求められる開発側は、適切な取り組み／分析をするよりも、指標値の範囲内に収めよう、という思考が働くのです（本末転倒）。
そうなると、品質の良いモノを提供しようという意識も弱くなり、大概は、それなりに良く見える品質レポートを提出して納得する／させる、ということになるのです。

「よくある話」と思う人も多いかもしれませんが、品質を厳しくチェックするがために、品質が劣化する、という矛盾には、開発者も品質担当者も悩んでいる状況が続いている現場は多いのではないでしょうか？

ここまで読んで「だからTDDしよう！」などと思われる人もいるかもしれませんが、私の考えでは、それでは根本解決はしないと思っています。
TDDでカバーできるのは実際的には一部のテストですし、そもそも、同じプロダクトやサービスを提供する関係者が、敵対関係のままであるのは、解決したいところなのです。
アジャイルでは「協調」が大事にされていますが、顧客だけでなく、開発チーム／組織の中でも、同様に大事ですよね？

体制のリファクタ

さて、ここからが本題。
私自身、試行中ですが、上記のような問題をどうすれば改善されるか、を考えています。
その結果、必要だと考えているのは、以下の3つの転換。

1. 「品質保証」ではなく「品質支援」を

まず「保証」という言葉が良くない。なので「品質保証」という言葉も部署も、無くしてしまいましょう。

※全国の品質保証の方、ごめんなさい m(__)m
※でも、実力のある品質保証の方って、実際的には、保証だけをしているのではなく、開発が成功するよう、積極的に支援していると思うんですよね。

「保証」と言われるがために、品質保証側も、その後問題が発生したときの責任を考えてしまい、形式的な指摘や粗探しをしてしまうのではないでしょうか？
責任は、プロジェクト全体で分担するのが適切で、だからこそ、プロジェクトが成功するよう、品質エンジニアも開発エンジニアを支援するし、開発エンジニアも品質エンジニアにアドバスを受けるかたちが良いと考えています。

実際には、

• 設計やテストケースの検討を一緒に行う
• 品質エンジニアは、開発エンジニアが自動テストを行いやすいよう、支援する
• メトリクスを開発エンジニアが収集し、分析は品質エンジニアが行う

といった活動が必要でしょう。

2. 「やり直し」ではなく「フィードフォワード」を

品質に問題があると、強化テストや、レビューのやり直しを求められることってありますよね？
でも、あれって大抵うまく行きません。

なぜかというと、そもそも、自分たちが分かっていなかった部分で問題が出るのであって、それが分からないメンバがやっている限り、いくら時間をかけても無駄です。

工程毎や、イテレーション毎で、なんらかのチェックをするのは重要だと思います。
ただ、その結果、やり直し作業になるのって、モチベーションも下がりますよね。

問題があれば、次の工程やイテレーションで何をすべきか、フィードフォーワードを行うべきだと思います。
そもそも、過ぎた時間は戻らないし。

設計漏れや試験漏れがあったとしても、その後の工程やイテレーションで、何をすべきかに注力して考える方が建設的だと思いますし、そのために、品質エンジニアは適切にアドバイスできるだけのスキルが必要だと思います。

3. 「レビュー」ではなく「検討会」を

最近、「レビュー」は難しいなって思っています。
レビューは、なにかしら「できたモノ」を評価することになりますが、人間、できたモノがあると、そこのフォーカスで物事を考えがち。そうすると、重要であっても書かれていない部分の問題は、見逃してしまいがちなんですよね。
スキルのある人は、当然そのようなことはないですが、必ずしもそのような人ばかりでないのも現実です。

そのために、私は「検討会」を勧めてます。

• プロジェクトの進め方
• 設計の内容
• テストの観点抽出

など、レビューをする前に、検討会で考えを出し合う方が、内容も良いモノが出来上がりますし、トータルな時間も節約できると感じています。

最後に

最近では、「DeveloperTest」と「QATest」のように、開発エンジニアが行うテストと、品質エンジニアが行うテストが区別されてしまっているケースもあります。

本来は、良いプロダクト／サービスを提供する、という部分で目的は共通だと思っているのですが、歪んだ品質管理／品質保証のやり方により、おかしい部分が生まれてきてしまっているように感じています。

私は、今でも、「開発者」「品質管理者」「プロジェクトマネージャ」と、複数の役割を持っています。実際の仕事も、コーディングもしますし、他プロジェクトの品質管理もしますし、OSSやフレームワークの提案などもしています。

今回、それらの役割が決別するような状況は変えていきたいと思って、今回のエントリを書きました。