さて、今回は、ソフトウェアの品質と言えば誰もが引用するISO 9126 のソフトウェアの6つの品質特性、機能性（Functionality）、信頼性（reliability）、使用性 （Usability）、効率性（Efficiency）、保守容易性（Maintainablity）、移植性（Portability）にケチを付けるところから、組込みソフトウェアの品質について再考してみたい。
【ISO9126の品質特性と副特性】
1. 機能性（functionality） - 機能とその特性に影響する特性群。
- 合目的性（suitability）
- 正確性（accuracy）
- 相互運用性（interoperability）
- 標準適合性（compliance）
- セキュリティ（security）
- 成熟性（maturity）
- 回復性（recoverability）
- 障害許容性（fault tolerance）
- 習得性（learnability）
- 理解性（understandability）
- 運用性（operability）
- 時間効率性（time behaviour）
- 資源効率性（resource behaviour）
- 安定性（stability）
- 解析性（analyzability）
- 変更性（changeability）
- 試験性（testability）
- 設置性（installability）
- 置換性（replaceability）
- 環境適応性（adaptability）
『ソフトウェア品質とは何か』の 記事で書いたように品質の定義として「品質とは、顧客要求を満たし満足させる程度」というものがある。上記の6つの品質特性を高めることと、顧客要求を満たし満足させる程度である品質を高めることは組込みソフトウェア開発においてはイコールではない。
ちなみに、6つの品質特性のうち、機能性（Functionality）、信頼性（reliability）、使用性（Usability）、保守容易性（Maintainablity）、移植性（Portability）の5つを目指すということと、再利用を見越したソフトウェアの部品化とは目標が同じであるように見える。
再利用戦略は顧客満足を高めることにつながるというスタンスをこのブログでも取っている。でも、ソフトウェアを部品化することと、商品群全体を見据えた再利用戦略とは同じではない。仮に、もしうまいことソフトウェアを部品化することに成功し、ソフトウェア部品を組み合わせるだけでシステムを作り上げることができるようになったら、それはソフトウェア開発と言えるのだろうか？ 電気回路設計で部品を組み合わせて回路を書くのと同じではないだろうか。
自分は組込み機器開発でハードウェアとソフトウェアが分かれているのは、ソフトウェアには変更容易性があるからだと思っている。その歴史的な背景を考えれば、組込みソフトはハードウェアとハードウェアの隙間を埋めるような存在であり、隙間を埋められる変更容易性こそがソフトウェアの強みでもあったはずだ。
ただ、ソフトウェアシステムが30万行を越えるようになっても、隙間を埋めるような試行錯誤的な作り方をしていれば品質を維持・向上できない。だから、信頼性を高めたソフトウェアのコア資産を作ってこれを出来るかぎり長い期間、再利用するという戦略は正しいと思うし、実際そうすべきだと思う。
けれども、ソフトウェアの変更容易性を捨てては組込み製品の顧客満足を高めることはできないと直感する。
なぜなら、組込みソフトウェアではビジネス要求とコストや制約条件やら、機能と性能やらとのトレードオフが必ず発生し、それらをすり合わせて最適なバランスポイントを見いだすことが顧客満足を高めるためには必要であり、そのためにはソフトウェアの変更容易性を使わなければいけないからだ。
ソフトウェアの変更容易性の特長を使わなければ最適なトレードオフができないから、例えばコストや性能が犠牲になる。モジュール化されたソフトウェア部品を組み合わせてシステムを構築すると目的の機能を早く確実に実現できるが、コストが見合わなかったり、レスポンスが悪かったり、機動時間が遅くなったりする。
例えば、現実問題として開発工程の終盤でライバル会社が新しい製品をリリースし、市場においてアドバンテージを得るようなソフトウェア機能を見せつけてきたらどうする？
ハードウェアはもう変えられない。もしかしたら、ユーザーにとってはよく使うような機能ではなく、カタログスペックだけの勝負で必要な機能かもしれない。その機能をいれないとダメだ、といっているのは会社の中ではたった一人の声の大きいステークホルダーかもしれない。
でも、現実には多くのプロジェクトはその機能を入れることになるのだ。もしかしたら、ライバル会社が入れてきたのは本当にユーザーに役立つ機能かもしれない。そうだとしたら、嫌々ながらではなく、開発工程の終盤であっても、商品の価値を高め競争に勝つために、その機能を入れなければならない。
そんな芸当はハードウェアではできない。ソフトウェアだからこそできる。ハードウェアを変更したらプリントP板を書き換え、部品を選定しなおし、何回か試作し、性能要件が満たしているか、EMCは大丈夫か確かめなければいけない。確実に数ヶ月以上リリースが遅れる。
ソフトウェアの場合でもリリースは数ヶ月遅れるかもしれないが、ソフトウェアの変更容易性を活用して、機能を基に戻したり、バージョンアップで実現したりする作戦を取ることもできる。
また、きれいにソフトウェア部品を作って、それらをつなぎ合わせて、メモリが足らなかったり、ROM容量が足らなかったり、タイミングが間に合わなかったりすることが分かったらどうする？
そんなときは、作ったソフトウェア部品の一部を壊して、すり合わせの作業をし、制約条件や要求性能をクリアするしかない。顧客満足を満たし、商品の価値を高めるためには機能性（Functionality）、信頼性（reliability）、使用性（Usability）、保守容易性（Maintainablity）、移植性（Portability）を犠牲にしても効率性（Efficiency）を優先させなければいけない場合がある。（この例では6つの品質特性は同時には実現できず、一部が背反している）
そもそも、品質特性には組込み機器の価値を高めるために何かを犠牲にしなければならないというトレードオフの概念はない。悪い言い方をすれば、現場を知らない人たちが抽象論だけで作ったガラスの城のように見える。中身のある実態が見えない。
自分がイメージする美しいアーキテクチャとはまず、顧客満足が高く多くの人がその価値を認め購入し、長い間使い込むほど満足が高まるような商品がそこに実現されており、その中身をのぞいてみると価値の高いソフトウェア資産が独立しており、この資産を使って商品バリエーションを作れるような構造のことだ。
ようするに、商品として価値が高くないのなら中身がどんなにきれいにでも美しいとは思わないし、品質が高いとは思わないということだ。
だから、商品価値が高くないのなら、機能性（Functionality）、信頼性（reliability）、使用性（Usability）、効率性（Efficiency）、保守容易性（Maintainablity）、移植性（Portability）の品質特性が満たされていても意味がない。
ただ、30万行を超えるようなソフトウェアで機能性（Functionality）、信頼性（reliability）、使用性（Usability）、効率性（Efficiency）、保守容易性（Maintainablity）、移植性（Portability）がめちゃめちゃなシステムではバグをほとんどゼロにすることは不可能に近い。だから、品質特性を満たすことができないソフトウェアシステムは、結果的に商品価値（特に潜在的な価値、当たり前品質）が低くなる可能性が高い。
それでもなお強調したいのは、機能性（Functionality）、信頼性（reliability）、使用性（Usability）、効率性（Efficiency）、保守容易性（Maintainablity）、移植性（Portability）を高めることを組込みソフトウェア開発の目的にしたのでは、組込みソフトウェアの最適なトレードオフは成就せず、そのハードウェアにおいて商品の価値を最大限に引き出すことはできないということだ。
そうなると一番難しいのは「品質特性を高めること」と「商品価値を高めるために品質特性を犠牲にすること」のバランスポイントをどこに持って行くかだ。どれくらい品質特性を犠牲にすればよいかを判断するためには、もちろん品質特性とは何か、品質特性がなぜ提唱されたのかも知らねばならない。
さらに、最適なバランスポイントを見極めるためには、トップダウンとボトムアップの両方の視点が必要だし、ユーザーやユーザーが商品を使う環境や、世の中の幅広い科学技術や新しいハードウェアデバイスの情報や既成概念を打ち破る発想の転換もいる。
それが簡単ではないからこそ、組込みソフトエンジニアを極めるのは難しいし、顧客満足を高めることに成功したときの喜びが大きいのだ。
それぞれの業務ドメインのおいて、組込みソフトウェアの技術的ゴールはない。ゴールがないからこそ、その市場のユーザーを満足させるための技術的鍛錬をいつまでも続けていけるのだと思う。
もう一つ付け加えるなら、優れた組込みアーキテクトとは組込みソフトウェア開発において商品の価値を最大にする最適なバランスポイントを見つけることのできるエンジニアのことだと言える。最適なバランスポイントを見定めるためには、見渡せる範囲の隅から隅まで知っている必要がある。だから、ソフトウェアの品質特性は知らなくてもいいのではなくて知っている上でどこまで使うべきかを判断できるようにしておく必要がある。
知っているべき範囲は非常に広いので、勉強することがないという状況には絶対ならない。「この技術を使った顧客満足を最適にできるかどうか」という目で世の中を見ながら、「もしかしたら」と思ったら、深く入り込んでその技術を習得し、その技術のメリット・デメリットを頭の中にインプットして必要なときに使えるようにしておく。
これができるようになると広い範囲で問題解決能力を発揮できるようになる。すなわち、どこにいっても「使える」エンジニアになれるはずなのだ。
個人的に、ソフトウェア品質と組込みソフトウェア品質は同じではないと考えている。組込みソフトウェア品質においては、顧客満足を高めることを第一に考え、そのための顕在的な価値と潜在的な価値を高めることを目指し、潜在的な価値を高めるために有効と考えられる品質特性をどこまで取り入れれば、商品価値が最大になるかを見極めるべきだと思う。
P.S.
ソフトウェア品質に関して過去に書いた以下の記事も参考にしていただきたい。
『理系白書から考えるソフトウェア工学』で書いたソフトウェア工学と自然科学の違い。
- ソフトウェア工学は実用的で社会の利益となるような手法・技術を発見することが目的である。
- ソフトウェア工学では、よりどころになる自然科学の法則がほとんど使えず、思考や行動が必ずしも論理的でない人間を研究の対象にするしかない。
- 自然科学で解明された法則は安定しており寿命は長いが、自然科学に立脚した説明がほとんどできないソフトウェア工学は必ずしも安定ではなく寿命もそう長くはない。
また、東京大学大学院経済学研究科教授兼 ものづくり経営研究センター長 藤本隆宏先生が語った「ものの価値について」の話と、広島市立大学情報学部教授 大場充先生のソフトウェア品質の考え方について。『ものづくり戦略とソフトウェア品質』
