QAの論理、アジャイルの論理

一昨日、昨日とテストエンジニアのためのワークショップWACATE２０１３冬に参加してきた。
諸々の事情から参加は3年ぶりで久しぶりの再会という方も多く、 楽しかった、疲れたとともに懐かしかった。参加者、セッションの担当者・講演者、スタッフの皆さんありがとうございました。
学んだこと、考えたことを忘れないうちにブログを投稿することにする。

なお、今から書く内容はワークショップのセッションや分科会での話し合いなどから個人として考えたことであり、WACATEの全体像や雰囲気を再現するものではなく、時系列的に並べたものでもない。
また、投稿内容に含まれる誤りや意味不明な点はすべて筆者個人の責任である。

夜の分科会でのこと

夜の分科会（私はその一つに参加）の際に、ある参加者がQA（品質保証）として自社のソフトウェア（プロダクト・プロセス）に統一した基準を作り、守ってもらうことで品質を向上させたいと話していた。それについて別の参加者が結局は人に依存ものであり、基準を作ったとしても最低限のものでしかないと話していた。後者の方とはその後でも話す機会があり、（私が曲解したところもあるかもしれないが）大体の考え方を理解できたかと思っている。

私自身は以前テスト、品質保証を担当していて、プロセス改善などを行っていたこともあり、またアジャイル開発（本当のagilerの方から見ればfakeだとは思うが）に取り組んだこともあり、双方の利点や前提条件をある程度理解できる立場にあると思っている。

QAの論理としては、かなり大雑把にまとめると、開発チームは顧客や経営陣などからプレッシャーにさらされていて、開発者だけに任せていると期待に（少なくとも表面上は）応えるために品質をおろそかにする傾向がある、だから第三者が品質を守らせなければならない、ということになる。

一方、アジャイルなどを実践する開発者にとっては、プロジェクトによって正しいやり方は異なる、プロジェクト固有の事情を知らない第三者が口を出してもデメリットの方が大きい、さらには標準を守らせるという発想では守らせること自体が目的と化し、本来の目的が見失われるといったところだろうか。もちろんアジャイル開発でも「テスター」という役割は存在するが、開発チームの一部としての位置づけである。

私としては、特に人間にかかわる理論や思考については、一般化されたものであれば、ソフト開発に限らず、完全に間違っていて学ぶところが何もない、といった考え方はほとんどなく、 問題なのはどのような前提に基づいていてどの範囲で適用できるか、またどれだけ意味内容を持っているかだと思っている。どこまで成功するかはともかく、この観点から検討する。

コインの両面としての現実主義、理想主義

QAの論理は基本的には現実主義に立ったものだと思う。開発者が自らを律することは不可能、もしくは非常に困難だから、第三者の力を借りるしかないということなのだから。こうした考え方は三権分立や社外取締役の設置などソフトウェア開発以外の世界でもみられるものであり、ある種の知恵に基づくものである。ただ、上にあげたようなQAの論理（少なくとも洗練されていないもの）はその裏に素朴な理想主義も含んでいるように思える。

まず、QAに対する抑制と均衡が働いていない。QA自体がセクショナリズムに陥って自らの存在意義を示すために（と意識はしないかもしれないが）必要以上に開発に介入する、という可能性が考慮されていない。 また基準や標準の浸透が必ず品質の改善に結びつくというのも楽観的に過ぎる。（開発効率を示す指標としてコード行数が測定されているから、無駄にコードを書く、といった冗談を話すこともある。）

一方のアジャイルモデルは開発者（チーム）が自律的に品質を高めていけると考える点では理想主義的であるが、QAのような第三者がプロジェクトに貢献する能力や可能性については懐疑的であり。また、遠い昔に他人によって決められた重いプロセスや基準を現在の開発者（およびQA）が自らのものとして受け止めてその精神を守り、発展させていく可能性については悲観的である。

協力とモニタリング

以上に書いたことから、少なくともQAが自らが決めた基準を杓子定規に適用して開発チームを批判する、というのは正しくないものの、状況次第という面はあるが（アジャイル開発における「顧客」とは別に）品質を守るための第三者が必要な場面は多いと思う。その場合、QA（またはそれに似た立場の人）としては、開発者とどのように協力するかが課題となる。

プロジェクトについての十分な知識を持ち、かつ品質を守るために必要な意見を述べ、チームを動かす、というのが理想的な姿ではあるが、以下の理由から通常はあまり現実的ではないと思う。

• チームメンバーであってもプロジェクトや開発の詳細をすべて知っているわけではない。特にパートタイムでプロジェクトにかかわる場合、知識が不足することは避けられない。
• プロジェクトや開発内容にあまりに精通してしまうと、第三者として考えられなくなる。

もしこれができるなら開発者としても自ら規律をもって品質を高めることができる、 よってQAは不要、ということになるだろう。
より現実的なのは、開発者とQAが異なる情報を持ってコミュニケーションを行い、望ましい解決策を探ることだが、コミュニケーションに多少のコストがかかるとしても、画一的な基準の押し付けとなれ合いという両極端を避けるには必要なことなのだと思う。ただ、コミュニケーションの中身についてここで一般的に述べることはできない。個人間の関係によるところも大きいだろう。

小結

ここまで品質保証体制の背後にある前提を抽出しながらそれぞれのメリット、デメリットを考えたが、各種の前提が成り立つかは人次第である。（ただし、同じ人でも何らかのきっかけで変わることはあるかもしれない。）

開発や品質保証の体制をどうするかはプロジェクトの性質に依存するのはもちろんだが、メンバーにも依存するものであり、正しい方法は一つには決まらない。個人も組織も良い面と悪い面は表裏一体のことが多く、良い面だけを伸ばして悪い面は現れないようにするというのは（追求には値するが）簡単ではない。

WACATE1日目のBPPセッションとセッション2では相手のタイプによって接し方を変えることの必要性が説明された。BPPセッションでは「炎上駆動改善」なる方法が紹介され、意識が高くない人も改善に巻き込むための方法が解説された。これもメンバーの動き方についての仮定に基づいた方法論である。自分自身も理由をつけて改善を先延ばしにすることがあるので注意しなければならないと思ったが、意識が高い/高くない、というだけでなく、あることに意識が向いている人、別のことに意識が向いている人、…という面もあると思っている。付け加えるとすれば、相手だけでなく自分についても自分に合ったやり方、合わないやり方があると思う。

他のセッションについても（これもセッションの内容からは離れることになりそう）書きたかったが、時間がかかりそうなので後で別に投稿することにしたい。