ソフトウェアの品質管理
ソフトウェアの品質は、開発した業務系システム／アプリがお客様の戦略や企画を満たす要件定義に沿って正しく動くことにあります。そこには、開発側の理解力がどの程度のレベルにあるかも大きなポイントとして横たわっているとともに、発注するお客様が、正確に要望を要件定義に落とし込み、明快な仕様として誰が読んでも同様の機能を開発できる仕様書の作成が欠かせません。
既存システムへの付け足し開発
とはいえ、まったく新しいシステムを開発する以外は、既存のシステムをベースに機能（サーバーやDB、ネットワーク、端末などを含む）を追加・修正するか、古いシステム（機能）を削除して新システム（機能）を追加するか、いづれにしろ既存システムへの「付け足し開発」であることには変わりません。 この時に注意することは、既存システムの仕様書が各段階でそろっていて、かつ、その内容と既存システムがシンクロしているかを確認することでしょう。往々にして既存仕様書がしっかりしているシステムは多くないのが現状です。つまり、システムやプログラムがスパゲッティ状態で、機能追加による影響がどこに及ぶかを特定するのも容易ではありません。 要求仕様書や概要設計書などのドキュメントが正しくお客様の要望を反映したものになっているか、それをしっかりとITベンダーが理解して仕様書を作成しているかを検証することが、システム品質を確保する第一歩です。新機能における仕様書は、当事者であるお客様とITベンダーがやり取りすると、どうしてもITベンダー主導になる場合が多いのが実態でしょう。それを解消するためにも第三者が発注者と受注者の間に入り、客観的な目で要件定義から検証していけばシステム品質を高めることにつながっていくはずです。
実際の検証ではソフトウェアテスト手法に基づいた検証を行うことになります。テスト検証専門の技術者が不足しているのであれば、例えば当社を含めてテスト事業を展開するIT企業などが提供している「設計ドキュメントインスペクションサービス」などを活用する手もあります。システムの品質を作り込む作業としてシステム検証を上流工程から手を付けていくことで、製造（コーディング）時のバグつぶしではとらえられない論理的欠陥を明らかにすることが可能になります。つまり開発の後戻りを減らすことにつながるわけです。後戻りはだれでも嫌ですよね。特にお客様からすればサービスインが遅れてビジネスチャンスを逃す恐れがあるだけでなく、開発会社が後戻り分を負担することになる場合もあり、リスクを考えるとシステム検証の必要性はおのずと見えるものです。
国際標準規格への取組み
日本の多くの業務系システム開発では、開発会社がテストまで手がけます。海外では開発会社がテストを手掛けることはほとんどなく、標準的なテスト技法を使った第三者検証が当然のこととしてユーザーに受け入れられています。日本でも組込み系や制御系では第三者検証を行うことが入札条件に謳われ、人命にかかわるような輸出製品についてはワールドワイドで安全性を担保する国際標準規格に合致した開発が欠かせません。システムの品質維持・向上への取組みは、こうした普段は目に見えないところでも進んではいますが、果たして業務系システムの実態はどうでしょうか。
システムの品質を考えた時に、サービスレベルアグリーメント（SLA）を策定し、サービスレベルマネジメント（SLM）を実施していくという考えが浸透しつつあります。SLA／SLMはお客様がITをどのように使うかを分かっていることが前提となります。実際のシステム改修では、お客様「こんな使い方はできないの？」ITベンダー「はい、努力します」、お客様「もう少しレスポンス上らない？」ITベンダー「データベースをチューニングしてみます」など、あいまいな非機能要件を何となく請けてしまったというケースも多いと思います。なぜでしょうか。いろいろとしがらみがありますし、案件も落とせないし…。SLA／SLMではこうした非機能要望に対して数値で表すため、あいまいなままの契約・開発にはならないはずですから、お客様と一緒にSLA／SLMを構築する支援が、システムの品質管理で重要な要素の一つといえますね。 次回は「ソフトウェアの品質を考える（２）」として、品質管理のための第三者検証の重要性をとりあげます。