第7回 ソフトウェア品質特性

ソフトウェアは目に見える製品ではありません。だからこそ品質に関して整理して考える手がかりとして“品質特性”という考え方があります。

そもそも品質が良いとされてきたのは「ちゃんと動く(要求した機能が正常に動作する)」ことでした。また利用者からの要望も、機能面における「あったらいいな」がほとんどで、基本的には入力した結果が正しく保存され、（色々な条件で）活用され、正しく出力されれば良しとされてきました。

しかし、今では機能面での実装は当然のものとして、その上で「もっと簡単に」「もっと速く」「もっと現場に即したものを」と、単に機能を実装しているだけでは良い品質とは言えなくなりました。

お客様の「もっと」にどう応える？

この要求について分類・整理したのが国際規格SQuaREシリーズ（以下SQuaRE）※ の製品品質8特性です。

①機能適合性　②性能効率性　③互換性　④使用性　⑤信頼性　⑥セキュリティ　⑦保守性　⑧移植性　があり、最近はこれに利用時品質として ①有効性　②効率性　③満足性　④リスク回避性　⑤利用状況網羅性　といった、客観的基準で測れない品質も求められています。

この製品品質には、各特性の下に副特性も定義されています。
例えば　①機能適合性　に関しては「機能完全性、機能正確性、機能適切性」です。

その機能は要求目的に合っていて、正しく処理され、他のソフトとの互換性があり、一定の権限において運用可能で、規格や法律があればそれに準拠しているということです。これは最初にお話しした、「ちゃんと動く」基準においての品質レベルです。ではその先はどうでしょうか。少しかいつまんで記載してみます。

いかがでしょうか？　④使用性　のところで「これってどうやって定義するの？」と思われた方、その通りです。ソフトウェア開発でこれらの品質を最初から要求するのは現実的に難しいですし、いくら予算があっても間に合いません。

提案はフェーズを分ける

目に見えるものや既製品だと、比較的話は簡単です。「予算200万円で車を購入したいんだけど」と来店されたお客様に対して、車屋さんは当然軽自動車のラインナップを提案すると思います。この場合は双方のイメージが合致しているので、齟齬は生まれにくいです。

ただ開発（特に、目に見えないソフトウェア）だとそうはいきません。こちらは「予算200万円＝軽自動車」だという想定のもと作っていたら「ほしかったのはベンツだったんだけど」と言われるようなものです。不穏な空気が漂いますよね。このようにお互いが「思っていたのと違う・・」という事態を避けるため、発注側も請け負う側も、事前に「できること/できないこと」や範囲を限定して同意することがとても重要になってきます。

開発をしていると、1つの処理だけでも

• 何件までは何秒で処理可能とする
• 同時アクセス数は100端末までとする
• 運用するのは熟練のオペレータのみである

といった具体的な利用環境を限定して設計することが大切なのです。

特に利用時品質となると、実際に導入・運用しないとわからない項目もあり、設計時点では想定できない場合も多々あります。そのような場合は、導入後にチューニング作業を行なったり、運用開始後もデータベースを見直すなど、適切なパフォーマンスを出せるように調整を行う必要が出てきます。

そのため、このように運用を開始してから発見される要求に関してはフェーズを分けることを事前にお客様にはお話ししておき、別予算・別工程として提案し、時間をかけて修正していかなくてはなりません。

宙に浮いた要件を着地へと導く手腕

以前は「機能要件/非機能要件」という考え方があり、非機能要件については要求や定義をしなくても当たり前に実装しておくべき機能として議論されていました。ただ、「当たり前」ってすごく難しいですよね。業界によって、企業によって、人によって、基準は違うわけですから。その、どこまでやれば当たり前なのかわからないふわっとした状態で、エンジニアはこれまで多くの時間を浪費してきました。

昨今のソフトウェア業界に関しては、各品質特性について、どの粒度まで、もしくはどこまでの目標で、といった数値を明確にして開発しなければいけないという考えは浸透しています。ただ、お客様はその限りではありません。昨日今日で担当になった方もいらっしゃいますし、開発プロジェクトが初めての方もいらっしゃいます。

その場合、お客様の求める品質は際限なく広がってしまうことがありますが、それに対し、応える製造者側には真摯に対話する姿勢が必要とされます。説明を省かず理解を求め、両者の溝がない状態でプロジェクトを進めていくことこそが、本当の意味で“高い品質”なのではないでしょうか。

※規格番号で表現される場合ISO/IEC25000シリーズ