■製品品質と技術者 ３ （No.366）
今回はソフトウェアの品質に的を当ててみる。特に，昨今の製品品質は必ずソフトウェアが絡んでいることが多く，ソフトウェアを除いて品質を語ることはできなくなっている。そこで，私自身ソフトウェア設計者ではないが，ソフトウェア品質を，品質保証的立場で仕事をしたことがあるので，その観点で述べてみる。
ソフトウェアの品質とは
要求される特性を発揮するために，ソフトウェアのプログラムによって組み込まれるが，要求特性が厳しければ厳しいほど，プログラムは複雑にならざるを得ない。ところがプログラムは単純であればあるほど，ミスも少なく，品質としては安定したものになる。このことは，要求が厳しい特性であれば，プログラムが複雑になり，ミスも誘発し易くなり，結果的に品質が不安定になる危険性が増すことになる。
しかし，実際に組み込まれるソフトウェアは年々膨大化され，非常に複雑なプログラムになってしまっている。要するに，人間が十分気を付けてプログラムする程度では品質は担保できず，品質確保には人の思考の限界を遙かに超えてしまっている。つまり，どれだけ優秀な人が慎重な上にも慎重にプログラムを組んでも，必ずバグ（ソフトウェアの欠陥）が内在することになってしまっている。
ハードウェアでの品質確保は，実績ある環境試験などをクリアすることで担保されることが殆どであるが，ソフトウェアの場合，同様の環境試験でパスしても，必ずしも品質が確保できるとは言い切れない。つまり，ソフトウェアのプログラミングが複雑で或る以上，出来上がったもので検証するだけでは，あらゆるケースを網羅することが不可能なのである。僅かなミスでも，プログラム上ではとんでもない大きな問題になることもある。それは，実際，市場でソフトウェアのバグの問題で，市場改修などが行われていることからも容易に想像が付く。
つまり，ソフトウェア組込型の製品では，ハードウェアで品質確保していたやり方では，ソフトウェアの品質確保は不十分なのである。設計にソフトウェアが入り出した頃には，ソフトウェアの品質が十分確保できず，一旦市場に出荷した製品を回収するなど，その被害額が大きなものになったのである。幹部や責任者の多くがハードウェアで育った世代で，ソフトウェアの設計現場との意思疎通がなかなか要領を得ず，声高にどなりちらして右往左往していたことがある。これも一昔前の話である。
組込型のソフトウェアも様々で，一旦ＲＯＭに焼き込んでしまうもの（マイコンなど）から，プログラムした部分だけを組み込み，何か支障があったり改善をする場合，そのプログラムだけを入れ替えするものなど，製品によって様々なものがある。製品の特長と要求価格によっていろいろな使い分けが行われている。ソフトウェアの規模も年々増大化しており，億単位の開発工数を要する製品もある。製品の中枢をソフトウェアが占め，そのソフトウェアの品質が製品の品質を左右していると云える。
品質向上のプロセス
組込型のソフトウェアではなく，コンピュータのソフトウェア開発など，もともとソフトウェア設計が中心に行われていたところでは，既にソフトウェアの品質向上に際してはいろいろな取り組みがなされていた。それらの品質確保のやり方を製品に組込型のソフトウェア開発でも行われてきている。つまり，品質確保は最終製品のテストでは不十分で，設計プロセスの中に品質向上の取り組みがなされている。
先ず，製品としての要求仕様（要求性能）がある。これは顧客からの製品としての要望であり，必ずしも仕様という形では示されないこともある。そこで先ず，要求仕様を顧客の確認をとりながら定め，要件定義を行う。ここでは機能要件として，製品の機能に関することを明確にする。非機能要件として，性能や信頼性，拡張性，保守性，移植性など機能以外にソフトウェアとして必要な要件も明確にする。この要件定義がきっちりできていないと，できあがった製品が，当初狙ったものと違ったものになるので，十分な検討を必要とする。
明確になった要件定義を基に，基本設計に入る。先ず，システム全体の設計で，どのような構成にするか，方式を決める。その後，詳細設計に入るが，製品の機能，制御などをソフトウェアとしての仕様に置き換える。そして，部分的なコンポーネット毎の設計をした上で，コーディングする前段の詳細なフローまで落とし込む。コーディングを行った後は，単体でのテスト，モジュールを結合してのテスト，総合テストと段階を踏み，最終的な製品としてのテストを行う。この流れをＶ字型のプロセス（下図）と呼び，設計と各テストとがリンクされ，品質が保証されて行くプロセスになっている。（プログラムマネジメント 応用編を参照）
ハードウェアの品質が確立されているのは，同じパーツの組み合わせでも，各部品が専門のメーカで，製品環境に即した品質を十分保証したものになっており，それらを組み合わせた製品は，製品として品質が確保できるかどうかで見極めればよい。それに比べ，ソフトウェアはコンポーネントとして保証してくれるメーカなどは無い。コンポーネント自体の品質も自分たちで確立しなければ品質が担保されないのである。この点が大きな違いである。上図で云えば，システム設計して，機能や制御の仕様を決めれば，後は品質か確保された部品を購入すれば良いのであり，V字型の下半分を部品メーカが補っていてくれることになっているのである。
バグとレビュー
上述のような品質プロセスを踏むが，その途中経過では，バグ（設計ミス）が数多く出るのが当たり前である。バグを出そうと思って設計している人は居なくても，人間の考えで進める中では，ミスは不可避である。だから，各段階でテストを繰り返し，バグを減らして行くのである。複雑に出来上がったものでの検証は容易ではないので，単体，結合テストと，ソフトウェア独特の確実なモジュールを作り上げ，順次組み合わせて行くのである。
そのバグの検出に有効なのがレビューで，これの手抜きをするとバグを取り除くことができなく，品質の悪いものが組み込まれてしまう。そこで確実な品質を確保するために，仲間でレビューを行う。これは品質の要でもあり，やり方も様々な工夫がなされているが，要は自分独りでは思い込みの間違いをしたり，気づかなかったことを設計仲間でお互いに補い合うやり方で，より正確なものに仕上げようとするものである。
また，バグの発生頻度も，バグ密度と云った指標があり，ステップ当たりどの程度のバグが発生するか，経験則で判っており，レビューからテストでどの程度検出できたかを計る目安となっている。もちろん，設計者個人の能力差があるので，バグの少ない設計ができる人もおれば，そうでない人もいる。また，レビューはソフトウェアの組み込み方をお互いが学ぶ機会でもあり，新人などの研修には大いに役立つものである。先輩から後輩へ，ノウハウが伝授されるものでもある。
外部委託設計での品質確保の難しさ
ソフトウェア品質で，品質確保を難しいものにしている要因がある。それは，ソフトウェアの規模が小さかったときは自前ですべて設計していたので，弱点や問題点も，比較的容易に判ることができた。ところが，ソフトウェアの規模が大きくなるにつれ，ソフトウェアのプログラムそのものが複雑，且つ難しくなることもあるが，それ以上に，品質を左右させているのが，外部設計委託である。
これはどこでも頭を悩ます問題で，ソフトウェアの設計人材の不足や人件費増から，外部委託をせざるをえない状況になっている。そうすると，外部設計部門との連携が必要となり，そこでのやりとりの不具合も出てくる。また，外部委託先の設計能力の問題もある。目に見えないところでの設計は，仕様のきっちりした取り交わしなど十二分にしても，齟齬のない完全なものとはならない。
特に，オフショアと云われている海外メーカを使っての外部委託設計は，さらに問題が多い。仕様などで明確にできるので，言葉の問題は少ないと思えばとんでもない。ソフトウェアなので大丈夫と判断すること自体が間違っていると云ってもよい。折角仕上がった部分を，日本で再見直しをしなければ役に立たない，などと云った例はざらである。工数による契約をしている場合など，日本のメーカをカモにしているのではないか，と云うことさえある。（詳細はオフショア開発の問題No.１４８，１４９，１７２，１７３を参照）
ここでもハードウェアと比較してみると，ハードウェア設計を海外メーカに委託することは先ず無い。ただ，海外の部品を調達する場合でも，部品メーカとしての品質保証はしている。それを組み込むのだから，組み込む段階で，問題の有無が十分把握できる。オフショア開発そのものが，下請的な扱いであり，品質が十分だとのふれこみであっても，人の移動が頻繁な海外では，設計者が入れ替わることは常時行われていて，品質に対する責任の所在も今一つである場合が多いことが常態化していると言わざるを得ない。
（続く）
ソフトウェアの品質確保は難しい
品質向上のプロセスが生かし切れていないのではないか？
[Reported by H.Nishimura 2014.03.31]
Copyright (C)2014 Hitoshi Nishimura