ソフトウェア品質保証方法への提言

キヤノン株式会社
品質本部製品品質センター
永田　哲

1. 高品質は日本製品の強みの源泉

　日本製品の強みは高品質にあり、それは企画、設計、製造、品質保証、市場サポートに携わる人々の品質意識、技術力そしてプロセスの質の高さによるものです。ハード量産前に工場の技術者により主に生産性に対するチェックを通して設計に磨きがかかります。さらに品質保証部門による統合的なユーザー視点の製品テストとその結果に基づく「生産開始の合否判定権限」が製品の高品質に寄与しています。設計者も製造部門や品質保証部門のハードルがあるからレベルが上がり、三者のモチベーションも高いわけです。
しかし、近年競争の激化に伴う機能と複雑さは増加の一方であり、それを実現するために組み込みソフトウェアの規模も肥大化の一途です。また、生産開始日程や製品品質を決める比重がしだいにハードからソフトへと移ってきています。テスト前の上流工程でのソフトウェア品質は見えにくいため、 ソフトウェアの重要度が増すにつれ品質の維持が難しくなってきています（測定できないものはコントロールできません）。加えて、ハードと違ってソフトウェア設計品質には工場からの磨きはかかりませんので、品質保証部門も最後の総合テスト（システムテスト）のみでは品質に自信を持つことができません。最終の総合テストの段階で予想以上のバグが発見される場合の多くは、それ以前の工程での品質の造り込みが不足していたことを意味しますので、結局出荷後の潜在バグは多いわけです（ブラックボックステストのバグ摘出率は５０％未満といわれています）。

2. 変わるべき品質保証部門の役割と品質保証方法

　品質保証部門はハード主体の製品では総合テストを主たる任務とすることで済んでいましたが、ソースコードを含めた設計品質で製品品質の大勢が決まってしまうソフトウェアでは、それだけでは品質保証はできません。「工程検査」をしっかりやるべきです。すなわち、ソフトウェア開発工程の「要件分析・定義」「外部（主に機能）設計」「内部設計（アーキテクチャ設計とインターフェース設計を主とした詳細設計）」「コーディング」の各段階で、ドキュメントレビューやコードレビューが充分に実施されているかを確認しなければなりません。もちろん、スキルがあればレビュー（検証）に直接参加すべきですが（特に要件定義書や外部仕様書においては）、重要なのは各工程の成果物であるドキュメントの完成度が設計内でチェックされているかを確認することです。ソースコードについては、静的解析ツールを使用しながら可読性を含めたコード品質のチェックも済んでいることを確認します。そして、クラスのメソッドあるいは関数ごとに単体テストが基準を満たすように（例えば正常系はC1パスカバレッジ100%）実施され、関連モジュールとの結合テストが充分に済んでいるかを確認します。
そして、これらの「検証の充足度をいかに可視化するか（ものさし作り）という可視化技術」と「充足度を判定する基準作り」が品質保証部門に求められているわけです。このような途中のチェック能力と、いざとなればブレーキを踏むことができる権限が品質保証部門には必要です。さもないと先に進みたい一心の企画／設計部門はアクセルを踏みっぱなしとなり、途中までは早いですが、最後の総合テストで大ブレーキがかかり、製品プロジェクトという車は結局ゴールに予定時間内につけないことになるか、それでも無理に突っ走れば事故（市場問題）を起こすことになるでしょう。このようなことが起きないように、各製品プロジェクトに参加している品質保証部門の担当者は、設計成果物の品質確認（レビューやテスト）が計画通り実施されていることを適宜チェックしていくわけです。

　 　

3. 請負型契約におけるWin-Win関係を目指して（調達管理）

　現在は、多くの設計開発を資本関係のない外部の、しかも海外の開発会社へ請負型契約で委託しなければ競争に勝てない時代です。請負先には成果物責任がありますが、調達側が受け入れテストで品質の低さに気がついても「時すでに遅し」です。このような事態を避けるには調達側は内部仕様書、ソースコード、テストセット（単体テスト、結合テストに必要なテストコード、スタブ、テストケースなどのすべて）の品質を、早期に確認する必要があります。具体的には内部での開発と同様な成果物の品質保証計画を請負先に要求し、適宜調達側の設計部門が成果物品質を再確認することが大切です。この品質保証計画は当然調達契約書に含むようにします。工程検査では、この品質保証計画書の内容確認とともに、計画通りに請負側と調達側が成果物の確認を実施しているかチェックします。
品質保証部門が請負側のバグ出し屋になってしまうと、人をどんどん増すことになり結局品質も充分に上がりません。ハード部品の調達と同様な仕組みがソフトウェアの調達にも必要です。そして成果物の質と量で対価を支払らうべきです。

4. 最後に

　製品の品質問題を起こしてユーザーに迷惑をかけることは、その製品に関わった個人、チーム、組織のすべてにおいてプロ意識を欠いた恥ずかしいことである、という認識がまず必要です。次にその失敗を繰り返さないように、類似問題の再発防止／未然防止につながる予防措置を組織レベルまで共有することです。そして品質保証部門は、そのような仕組みが正しく機能しているかを確認する必要があります。プロセス改善は重要ですが、製品品質の維持には、特にソフトウェア開発に携わる設計者一人一人の「品質と生産性への意識」と「技術力」のレベルがある水準以上であることが前提です。逆も真、すなわち製品の高品質を目指すことが個人から組織レベルでの技術力、品質意識そしてプロセスの質を押し上げることになるのです。