ＳＷ品質まとめ②ソフトウェア品質

品質というものは具体的な「物」として存在するわけではなくメタな「概念」であるため、「測定」という行為によってなんらかの値に置き換えて認識する必要があります。

測定とはすなわち

　「テストという行為による結果として
　　アウトプット値を測り検証する」

ことです。

この図はとても大事です。この概念自体は、国際規格であるISO 9126などでも定義されています。

ソフトウェアの品質（プロダクト品質、あるいは製品品質）によって直接影響を受けるのは利用者です。その段階での品質のことを「利用時の品質」と呼び、利用者の必要性に合致するかどうかを表しています。

一般には、「顧客満足度」がこの品質を測るために最もわかりやすいフィードバックとなるでしょう。これは利用状況によって異なってきます。たとえば、ある環境で十分満足に機能するソフトウェアも、別の環境では障害を露呈するかも知れないということです。

「利用時の品質」に直接影響するものが「外部品質」です。

ソフトウェアが実行されるときの品質のことであり、テストデータを用いたテストの結果（実行時のコードの振る舞い）などが該当します。ほとんどのベンダーやSIerが『品質』として認識するのはこれじゃないでしょうか。

　「利用時の品質」を代表するもの、あるいは構成するもの

と捉えることもできる。

そして「外部品質」に直接影響するものが「内部品質」です。

ソフトウェアの内部的な特徴で、ソースコードのみならず、仕様書なども測定対象になります。静的な測定によって得られるものがほとんどで、たとえばモジュール性（ソフトウェアが適切に構造化され、変更、修正などが局所的なもので済むようになっている性質）や追跡可能性（要求から実現されたものへの関連、および実現されたものから要求への関連を追いかけることができる性質）などが該当します。解析性やテスト性なんかにも関わってきます。

本当にエンジニアリングのプロなら、ここってすごくこだわりますよね。

最後に「内部品質」に直接影響するものが「プロセス品質」です。

プロセスとは設計／開発の進め方や手順のことで、成果物ができあがるまでの品質を指します。この「やり方」の品質が結果的にすべての品質に影響を及ぼす、ということになるわけです。

一般に、どの業界においてもエンジニアの多くは「外部品質」にこだわりを持つことが多く、それ以外の品質を見ていない傾向が強いと言われています。昨今では、UI/UXなど「利用時の品質」の大切さに気付き始めた企業なども増えてきましたが、やはりまだまだその浸透率は低いといっていいでしょう。

特にユーザー視点を持たないエンジニアや、ソフトウェアだけしか見ていないエンジニアには顕著にあらわれてきます。けれども「内部品質」や「プロセス品質」を無視して「外部品質」だけが十全に成立することは絶対にあり得ないのです。

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

・ユーザーの実運用に耐えられない
・使い勝手が悪い

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

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

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

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

プロセス品質を軽視するということは、既にソフトウェア開発におけるプロジェクトチームとしては破たんしており、

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

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

世の中の製造業がQC活動/QCサークル活動などを行うことが当たり前な理由

それは、

　外部品質を達成するために、内部品質やプロセス品質が
　無視できないことを知っているから

に他なりません。
残念ながら、昨今のQAはそこまで考えていないところもあるようです。だから、「テスト」工程にばかり目が行きます。ですが、先ほども述べたように、機能テスト／非機能テストだけでは内部品質やプロセス品質を保証できません。ソフトウェアとしての機能は問題なくても、その後のメンテナンスや保守対応、改造、リプレース、マイグレーション等を行おうとしたときに大きな弊害となりやすいのです。

『正しい手順（プロセス）を踏めば、正しい結果に必ずなる。』

これは正しい結果から、逆算して、どうやったら正しくなったのかを分析し、一つひとつの手順を定めていけば、必ずそうなるようにできるものです。そうやって定められた手順を常に監視・測定し、少しずつ目標とのズレ（誤り）や、目標に対する不足（抜けや漏れ）を発見することで、改善活動を継続し、より良くするものです。

どんな些細なモノであっても、理想とする正しさから乖離している点を放置してはいけません。これを疎かにすると、リコールや出荷後不良となることを知っているからです。そうして戦後最大の倒産といわれた痛ましい事件もまだまだ記憶に新しいですよね。

戦後最大規模の破綻でもタカタの社員は今も「平和」？

昔に比べ、『品質』を軽視する企業、軽視するエンジニアは決して少なくありません。「MADE IN JAPAN」が世界的に一定の価値ある認識とされてきたのは、『技術』の高さ以上に、その『品質』の高さゆえであるにもかかわらず、それを軽視していては意味がないのです。結果、品質向上を疎かにした組織、企業は、長く続かなくなるのは自明の理です。

ここから先、全11項はファイルにて。

2. ソフトウェア品質
　2.1 測定との関係と視点
　2.2 世の中の製造業がQC活動/QCサークル活動などを行うことが当たり前な理由
　2.3 それぞれの品質の関係性
　2.4 基本的な考え方
　2.5 ソフトウェア品質の優先順位
　2.6 利用時の品質（品質の効果）
　2.7 外部品質（プロダクト品質）
　2.8 内部品質（外部品質を支えるバックボーン）
　2.9 プロセス品質（正しい仕組みと正しい手順）
　2.10 ソフトウェア品質とマッチングしない現場
　2.11 ソフトウェア開発方法論は欧米流が随所に紛れている