SQAは最後の砦 - ソフトウェア環境の変化とSQA -

ソフトウェア技術者協会に品質保証分科会(SEA-SIGSQA)が発足するのを記念して、2月6-7日にSEA ソフトウェア品質保証ワークショップが開かれます。テーマは「ＳＱＡは時代の変化と今の要請に対応できているか？」ということで、私も参加することにしました。

私のポジションペーパを載せておきます。感想などをいただけるとうれしいです。

SQAは最後の砦 - ソフトウェア環境の変化とSQA -

１．概要

ソフトウェアを取り巻く環境は大きく変わり、新しい技術やプロセスへの支援への要望が大きくなる反面、新しい技術やプロセスの変化によって、関与できる支援が限られてきている。本ポジションペーパーでは、ソフトウェア環境の変化とSQAの位置づけを整理し、今後のSQAの在り方について考察した。また、考察の結果を元にインタビューを行い、SQAは最後の砦として最低限の品質を守りつつ、開発部隊の自律的な品質活動を支援する事が望ましいと思われた。

２．ソフトウェアを取り巻く環境の変化

SQAに関する議論では、低コストと短納期、さらに、ほどほどの品質がSQAの活動を困難にしているとされている。これは近年のソフトウェア開発の特徴であるが、その背景に90年代から始まったダウンサイジングの流れが、大きく影響していると考えられる[4]。

PC等を用いたダウンサイジングのシステムでは、小規模な組織での開発が多く組織的な品質向上策が困難である[1]、最新技術に対する経験が少ない、自由度が高いので仕様の決定が困難であるという特徴がある。また、従来のソフトウェア開発において重要視される品質特性は主に信頼性であったが、90年代以降の開発では使用性や機能性など従来よりも多くの品質特性を考慮しなければならなくなった。

このような環境の変化の中で、ソフトウェア開発は以下のように変化してきた。

• 実装重視
• ユーザによる判断の優先
• 工程の不明確化

新しい技術を利用する目的や、自由度が高い中で様々な品質特性を満たす仕様を決定する目的で、早期にプロトタイプを作成したり、アジャイル手法を用いた実装重視の開発が増えている。また、企業責任としての最低限の品質保証を除いては、ユーザとの合意に基づく品質判断も増えてきており、ユーザによる判断を優先する傾向がある。さらにこれらの影響で仕様がなかなか確定しないなど、工程の境界が不明確になっている。次の工程の作業を許さないことが現実的でなくなり、ウォーターフォールモデルと言いつつも柔軟な開発が増えている。

このような傾向は、開発中にSQAが関与する機会を奪いがちである。具体的には

• 現場はより具体的な技術問題の解決を期待している
• ユーザが認めればそれで良いという風潮
• 工程会議などで支援する機会の減少

ということがあり、近年はさらに

• 低コスト
• 短納期

のプレッシャーから

• ほどほどの品質で良い

という風潮も生まれ、SQAは軽視されがちである。また、景気後退局面に入った事から、ユーザは「新技術の育成から、これまでの投資の刈り取り[3]」に向かっており、ユーザのコスト低減圧力はさらに強くなると思われる。

３．開発部隊が求めている支援とSQAの特徴

新技術や新しい品質特性への対応が求められているが、対応しなければいけない情報が増えるにつれて、従来のようにあらかじめ準備しておくことが困難になっている。網羅的な技術を得ることが困難な現実を考えると、必要に応じて学習する方が効率的である(Learning on demand[2])と考えられる。そこで、開発部隊が支援組織に求めるのは、

• 具体的でインタラクティブな支援
• 観点、戦略といった抽象度の高い支援

の2種類であると思われる。

ここでSQAの特徴を考えると、「第三者」であること、そして「プロジェクト横断的」であることの2点である。第三者であることで、出荷時の検査を客観的に、ユーザ目線で行うことができる。また、プロジェクト横断的な組織なので、組織的な支援や教育を行うことができるのである。

しかし、開発部隊が求めているものは、現状のSQAの活動とは若干異なる。具体的でインタラクティブな支援をSQAが直接行うとすると、担当者の負担が大きくなりすぎると考えられる。仮に支援を行うなら、文献[4]の作業報告書を元にした経験データベースのように、ツールを中心とした支援が現実的であると思われる。また、支援する内容は生産技術の支援が多いと思われるので、SQAが担当すべきでないかもしれない。一方、抽象度の高い支援を行うのであれば、組織の戦略を担うPMOが担当することも可能である。

以上のことから考えると、SQAという組織を残すのであれば、第三者としての検査が必要であるかどうかを検討する必要がある。これは、特に開発部隊からは求められていないように思われるが、実際にSQAの現実を知る必要がある。

４．SQA経験者へのインタビュー

そこで、SQA経験者に上記の考察を踏まえてインタビューを行った。その結果、

• SQAとそれ以外の境界はあいまいなので、なくそうと思えばなくせる
• 当たり前のことができていないので、SQAの必要性はある
• 逆にSQAがなくなった方が、自分たちで品質向上ができるようになる気もする

というコメントが得られた。このコメントから考察すると、すでにSQAが存在する組織においては、SQAの存在が当たり前になっている。このため、ある日突然にSQAをなくすことは企業の信用を落としかねない。SQAをなくすのではなく、SQAに依存しない自律的な開発組織になる事が重要だと思われる。その上で、最低限の品質確保をすることが望ましい。

このことは、ほどほど品質の実現とも整合性がとれる。ユーザが求めるほどほどの品質とは、小さな問題はあるものの致命的なトラブルのない品質である。そのような品質を検査だけで実現することは困難であり、致命的な問題が入りこまないように作りこまなければならない。そのためには開発者のスキルアップが重要である。

５．まとめ

SQAには多くの仕事があり、ソフトウェア環境の変化を考慮すると他の部門に移管するべきものもある。しかし、企業の信用を守る最後の砦として、最低限の品質を確保することはSQA以外にはできないことである。ほどほどの品質を実現するには、致命的なエラーを埋め込まないような教育をするなど、開発部隊のスキルアップのほか、SQAによる最低限の品質保証が重要である。

[1] J. G. Brodman and D. L. Johnson, "What small businesses and small organizations say about CMM", In Proc. of the 16th ICSE, pp. 331-340, 1994.
 
[2] Fischer, G., "User Modeling in Human-Computer Interaction," User Modeling and User-Adapted Interaction (UMUAI), Dordrecht, The Netherlands: Kluwer Academic Publishers, 11(2), pp. 65-86, http://l3d.cs.colorado.edu/~gerhard/papers/umuai2000.pdf, http://swiki.cs.colorado.edu:3232/dlc-2004/uploads/um-lod-hfas-march8.pdf, 2001.

[3] 垣内郁栄, フラット化するIT予算, http://www.atmarkit.co.jp/news/200901/15/gartner.html, @IT.

[4] 阪井 誠，松本 健一，鳥居 宏次, "ダウンサイジング時代のプロセス改善モデル", ソフトウェアシンポジウム'95論文集，pp.131-140, 1995．

謝辞：

ポジションペーパ作成にあたり、議論に参加してくださったTさんに感謝します。