ソフトウェアの品質保証 |
作成日：2008-05-31 最終更新日： |
下記資料は、中小企業診断協会東京支部の研究会である、 安全・品質・環境実務研究会で発表した資料です。 なお、同研究会は2009-03-31 をもって解散しました。
| 年月 | 事件名・障害名 |
|---|---|
| 2002年 4月 1日 | みずほフィナンシャルグループ第規模システム障害 口座振替遅延 250 万件。二重引き落とし 3万件。 リレーコンピュータ処理プログラム受付で、 特殊な条件でのみ顕在化したソフトウェア欠陥により処理が遅延してしまったため |
| 2005年12月8日 | ジェイコム株大量誤発注事件 「６１万円１株売り」とすべきところ「１円６１万株売り」と誤った。 システムでは注文取り消しができなかったため。 |
| 2007年10月12日 | Suicaシステム自動改札停止事件 遠隔操作で作動せず 特殊な条件でのみ顕在化したソフトウェア欠陥により、 不正カードのデータの受付が停止してしまったため。 |
| 2008年2月8日 | 東京証券取引所トラブル事件 デリバティブ取引で、注文表示とデータベース内容の不一致で取引停止 稀なケースで初期化すべき処理がなされていないケースがあったため。 |
| 2008年5月12日 | 三菱東京UFJ銀行システム統合トラブル事件 セブン銀行のATM利用時に取引できない カタカナで受渡すべきデータを漢字で処理してしまったため。 |
| 2008年5月12日 | 京浜急行で全列車緊急停止 緊急地震速報の誤作動で全列車緊急停止 テスト用のデータを Off にすべきところ、 誤って On になっていたため。 |
その他、2006年6月3日、「シティハイツ竹芝」で起った、
シンドラー社エレベータで起った死亡事件も、
ソフトウェア欠陥の疑いがある。
（シンドラー社が情報非公開のため、検証できず）
一般の機械製品や材料などと異なり、「品質」の定義は難しい。 もちろん、所定の機能を発揮するための性質であることは変わりないが、 所定の機能に期待する程度や観点が、利用者によって大いに変わりうる。
ある定義では「品質とは誰かにとっての価値である」となる。 この場合の「誰か」とは、誰でもありうる。 すなわち、「ユーザ」の場合もあるし、「開発者」の場合もある。 もちろん、品質保証という観点から考えると、ユーザでなければならない。
次にソフトウェアでは、どのような品質特性が要求されるだろうか。 現在標準となっている品質特性は、 ISO/IEC 9126(JIS X 0129-1)で定義されている。 主たる特性は６種類あり、 さらに各特性に副特性が数種類定義されている。 ここでは、特性の名称とその概念を紹介する。
| 特性 | 英語名 | 説明 |
|---|---|---|
| 機能性 | functionality | 動作の正確性 |
| 信頼性 | reliability | 動作の継続性 |
| 使用性 | usability | 使い易さと魅力 |
| 効率性 | efficiency | 速いこと、容量(メモリ、ディスクなど)が少なく済むこと |
| 保守性 | maintainability | 長持ちのしやすさ |
| 移植性 | portability | 通用範囲の広さ |
ソフトウェアはその特性上、 他工業製品（ハードウェア）異なる点がある。 これらの違いを理解した上で、品質向上の手を打たねばならない。
コンピュータソフトウェアは論理のみから成り立っている。 その論理に穴が空くことは、すなわち欠陥につながる。
プログラムが見えないことは、保守性の低下につながる。 また、開発プロセスが見えないことは、 「見える化」が必要条件となる品質保証にとって、 都合が悪い。
ニーズやユーザが多様であるため、仕様の増大や変化に対応できない。 また、ハードウェアの進歩が加速し、他のソフトウェアとの連携が進むなか、 動作確認すべき対象がうなぎ登りに増えている。
職人芸（手工芸）とも言われるソフトウェア開発は、 近代的な工業製品に対する手法が取りにくい。
根本対策として、 経営がソフトウェアの品質向上に対して本気であること、 これを示すことである。 マネジメントの基本として、 品質マネジメントの国際規格 ISO 9001 を導入することは、 一つのアイディアである。
ただし、ISO 9001 は製造業向きの規格であるため、 ソフトウェア品質管理のためには、適切な解釈が必要である。
その他、対象に特化した規格として、セキュリティの ISO 27000シリーズ、 IT サービスマネジメントの ISO 20000 シリーズなどがある。
ISO にはないが、システム開発、ソフトウェア開発であれば、 CMMI （能力成熟度モデル統合）が知られている。
マネジメントの導入・強化と併せて、 プロセスそのものの変革を迫ることがある。 例えば、従来人手でプログラムのコードを書いていたものを、 機械で自動的に生成するツールなど、 コンピュータによる開発／保守の支援を行うツール（CASEツール） を適用する。
上流（要件定義から設計まで）と下流（コーディングからテストまで） を比べると、適用は上流より下流が容易であるといわれている。
なお、特に構成管理ツール（バージョン管理とほぼ同じ）は、 必須に近い。
思っている以上に、用語や記法の不統一により伝達や解釈に齟齬が発生し、 その結果品質の低下につながることは多い。 基本となる用語や記法の統一を行うことで、 進捗がはかどるようになる。
お客様と営業、営業と開発者、開発企業と下請企業（さらにその孫請...) など、関係者が多くなると、 コミュニケーション不足により必要事項が伝達できず、 その結果品質が低下する。 何らかの形で必要なコミュニケーションを促すような仕組が必要となる。
なお、プログラム開発者どうしのコミュニケーションに絞ると、 ピアレビュー（peer review）は非常に効果がある。
データを数値化して、目に見える形で示すことは、 共通の議論を深めるために重要である。 たとえば、テストにおいて、プログラムの規模 （たとえばプログラムの行数）に対する欠陥の割合を計測し、 この割合が基準に収まっていれば合格とする、 などの処置を適用する。
ソフトウェアの開発や保守に関する営みを、 一般の読者に対して簡潔に説明した本は極少ない。 下記はその中で勧められるが、絶版である。
ソフトウェアの品質概論としては、 現在は手に入りにくいが優れているのは次の本である。
ほかに、保田氏と奈良隆正氏の共著「ソフトウェア品質保証入門」もある （未見）。
現在のソフトウェア工学を俯瞰するための本は多くある。 次はその一例。
参考になるWEBは下記にある。
まりんきょ学問所 ＞ 品質の部屋 ＞ ソフトウェアの品質保証
