ソフトウェア品質とは何か

品質というものは具体的な「物」として存在するわけではなく「概念」です。

ですから「測定」という行為によって私たちが知覚できるなんらかの値に置き換えて認識する必要があります。つまり品質を論じるには、本来"測定"とセットでなければならないのですが、具体的に

　どのタイミングで
　どのような内容を
　何に照らし合わせて

測定するべきかを考えて開発されている方はいらっしゃるでしょうか。

ここで「〇〇がそう言ってるから」という他責で、思考停止した答えは期待していません。みなさん自身がいかなる理解のもとに開発されているかが重要なのです。

残念なことに、多くのSIer、多くのエンジニアは盲目的にどこかの権威を妄信してなんとなく品質を測定しています。そうすると、品質を報告するときはなんとなく程度の理解であっても、とりあえず数値を用いているため説得力自体は生み出すかもしれませんが、工程が次に進んだ際やリリース後になぜかバッチリと報告したはずの工程で発見すべきバグが発見される…ということになります。

そう、品質を正しく使いこなせていないのです。

測定というと、早々に思いつくのはレビューとテストでしょう。
しかし、ここでも大きな問題があります。

多くのSIer、多くのエンジニアは「レビュー」の質に対してとても無関心ということです。その証拠に、設計工程のレビューによる指摘を『バグ』と同じだと認識しているエンジニアは圧倒的に少ないのです。

仮にテスト工程の品質評価や報告をすることはあっても、設計工程のレビュー結果に対する品質評価や報告はしない企業が多いのです。だから、そうした企業に属する多くのエンジニアはレビュー品質に対する

　分析も、対策も、再発防止も

何もノウハウがありません。そうする必要性すら感じていないでしょう。しかも、そうする必要性を感じない根拠すら考えようとしてこなかったのではないでしょうか。

そのこと自体がすなわちダメだとは言いませんが、しかし非常に不足しています。

ソフトウェア品質において、いえ製造における大抵の品質において重要視されるべき品質には大別して４つのポイントがあります。

これは、ISO/IEC 25000:2005(JIS X 25000:2010)によるソフトウェア品質の概要です。

プロセス品質

設計／開発のやり方や手順...つまり仕事の仕方そのもののことです。マネジメント（管理）すべき開発の「進め方」「やり方」と言っていいでしょう。この品質が結果的にすべての品質に影響を及ぼすということになります。だからこそ「設計やテスト工程をどのように進めれば大丈夫なのか？」という問いを最初に検討する"計画"フェーズは非常に重要になるわけです。

内部品質

ソフトウェアの内部的な特徴で、ソースコードのみならず仕様書なども測定対象になるでしょう。

機能レベルの品質を問わず、成果物の在り方を問います。
静的な測定によって得られるものが大半で、たとえば

モジュール性（ソフトウェアが適切に構造化され、変更、修正などが局所的なもので済むようになっている性質）
追跡可能性（要求から実現されたものへの関連、および実現されたものから要求への関連を追いかけることができる性質）

などが該当します。よって、コーディング規約や設計ガイドラインなどの遵守率、文章表現への曖昧さの混入率などもこの観点に含まれます。見えない部分だからこそ、プロ意識をもってしっかりやろうという気概を持たない限り、この品質が向上されることはありません。

外部品質

ソフトウェアが実行される結果に対する品質のことであり、テストデータを用いたテストの結果（実行時のコードの振る舞い）などが該当します。一般的に「製品」の質といえば、この外部品質のことを指すといっていいでしょう。

要求仕様を実現した度合いとして見た場合の品質観点になります。

『モノ作り』だけに注力してしまうエンジニアの多くが「品質」として認識するのはこの部分でしょう。

利用時の品質

その名の通り、特定の環境および特定の利用状況で利用されるときの利用者の視点による評価の度合いです。ひとことで満足度といってもいいかもしれません。

これはソフトウェア自体の特徴を測定することによって認識されるわけではなく、ある環境において、利用者が目標を達成することができる程度を測定することによってはじめて認識することができます。

同じソフトウェア製品でも利用者が異なれば結果（認識される品質の度合）は違います。利用者は自分に関係するソフトウェアの属性のみを暗黙のうちに評価するからです。

そして多くのエンジニアが「品質」として認識することが最も苦手な部分でしょう。

しかし、機能安全も然り、この部分を正しく検討・評価できないエンジニアはお客さまの前に立てません。コミュニケーションもまともに成立しないで、お客様の不安や不満を増長させるだけとなります。なぜなら、お客さまの利用時を想定した提案や検討そのものができないからです。

利用時の品質を検討する際、その品質特性を大別すると以下の４つのポイントが重要になってきます。

有効性

利用者が指定された利用の状況で、正確かつ完全に、指定された目標を達成できる能力のこと。

生産性

利用者が指定された利用の状況で、達成すべき有効性に対応して適切な量の資源を使うことができる能力のこと。資源には作業を完了するまでの時間、利用者の労力、材料または使用した費用を含めることができます。

安全性

利用者が指定された利用の状況で、人、事業、ソフトウェア、財産または環境への害に対して、容認できるリスクの水準を達成するための能力のこと。リスクは一般に、機能性（セキュリティを含む）、信頼性、使用性または保守性の欠陥の結果です。

満足性

指定された利用の状況で、利用者を満足させる能力のこと。
一般に、製品を対話的に利用したときの利用者の反応です。　

通常、エンジニアの多くは「外部品質」にこだわりを持つものが多く、それ以外の品質を見ていない傾向が強いと言われています。

利用時の品質を軽視した場合、業務や運用を無視する形となってしまい、要求は一応満たしているのに

　・顧客の実運用に耐えられない
　・使い勝手が悪い

等の弊害を招き、契約自体は完遂できても顧客満足度を得られず、二度と相手にされなくなります。

内部品質を軽視した場合、通常稼働中にはさほど問題が起きないものの、

　・５～１０年後に再構築(リプレース)しようとしたら、
　　現行システムの内容が非常に難解となってしまっている
　・トラブル発生時に原因解析を行おうと思ったら、
　　ログ１つ出力されない仕組みになっていて原因を特定することすら難しい

等、システムとしての成熟性・安全性を問われる結果に陥り、これまた顧客の大クレームと繋がることになりかねません。

プロセス品質を軽視した場合、既にプロジェクトチームとしては破たんしており、

　・まともに開発が進まない
　・納品までたどり着けない
　・とにかく動くものを作ったけど、他社には見せられないレベルとなっている

等、「とてもこの業界でプロフェッショナルとは名乗れない」「仕事と呼ぶのも恥ずかしい作業をしている」「お金を支払っていただくのも申し訳ない」etc.…そんな進め方になっていると言わざるを得なくなります。