外部品質偏重の先にあるもの

日刊工業新聞にコラムを寄稿しました。2015年7月16日から10月1日まで週1回のペースで全部で12回です。連載タイトルは「ソフトウエアの価値」です。組込みソフトウエアやその開発に関してこれまで感じていたことや今後の展望を書きました。機会をみつけて12回分のタイトルをまとめてみたいと思います。

本ブログエントリで紹介したいのは連載11回目(9月24日掲載分)の「ソフトウエアの外部品質と内部品質」というタイトルの記事です。ソフトウェア品質を外部品質と内部品質に大別する考え方があり、国際標準でも言及があります。記事では、外部品質を偏重して内部品質の優先順位が下がると弊害があることを書きました。

細かい定義はおいておいて、ここでは外部品質は使ってみて顧客が感じる品質、内部品質は作ってみて開発者が感じる品質とします。一般に内部品質は外部品質に影響を与えると言われています。中の作りが悪いと開発者が何をするのにも考慮が必要で、結果としてできたものを使ったときにも問題が出やすいというものです。

ソースコードのコーディング規約やソースコードメトリクスは内部品質を評価するものであり、間接的に外部品質を評価しようとしていると解釈できます。

日本人の感覚で考えてみると、ユーザが直接感じる外部品質を内部品質よりも優先させることはそれほどおかしいことではないと思います。「ユーザに迷惑をかけないように」という考えを美徳とする場合もあると思います。しかし、海外でも常にこの考え方が受入れられるわけではありません。中がひどいものは外のデキもそれなりだろうというのが一般的ではないでしょうか。

組込みソフトウェアの中には海外に輸出されるものもあります。過去に日本メーカーの組込みソフトウェアに問題があるのではないかという疑問を投げかけられ、NASAが調査したことがあります。調査結果はここで公開されています。調査結果はソフトウェアに問題はみつからなかったと結論づけられています。調査はハードウェアやソフトウェアの詳細までが対象となり、メーカーの技術者へのヒアリングもあったようです。調査項目は外部品質はもちろん内部品質にも及んでいます。調査項目は突飛なものではなく、ソフトウェア品質に影響する可能性が指摘されているものです。

海外で調査の対象となった場合には、日本の外部品質を優先する考えは必ずしも通用しないでしょう。疑いの目で見られている場合はなおさらです。スケジュールやユーザの利益を優先するため外部品質を優先すること自体は状況によってはしかたがない場合もあるでしょう。しかし、それが常態化すると上のような調査の際には問題視される可能性もあります。外部品質を優先したときには、その次の開発で内部品質にも気を配ることや予算をとって内部品質を向上することは必要でしょう。外部品質の優先度を高めるときには、こうした調査のことも忘れてはいけません。

2015年9月に上梓した「間違いだらけの設計レビュー」の改訂版で実在の3事例とともに紹介した架空の事例（事例D）は本ブログエントリや日刊工業新聞への寄稿にも大きく関連しています。本当は長期にわたって内部品質を維持しなければならないのに、管理職、トップの一声で犠牲になりがちな内部品質をどのように維持するか、そもそもそうした重要な内部品質を他の内部品質とどのように区別するかを記載しています。お持ちの方は、75～80ページをご覧ください。購入は日経BPオンラインストア、amazonからもできます。