ソフトの品質向上はプロダクト品質とプロセス品質に分けて対策を進める
ソフトの品質向上のための方策はプロダクト品質とプロセス品質に分けると判り易い
ソフトの品質を向上するためには何をすれば良いのでしょうか、ネットを調べると様々な情報が得られます。テストの改善や設計レビューの実施や開発プロセスの強化やリリース判定の重要性 などなど・・・情報が多すぎて何から手をつければ良いのか判らなくなります。そんな時には、ソフトの品質をソフト開発プロダクトの品質とソフト開発プロセスの品質とに分けて、それぞれの品質を向上し保証するための方法を考えると、判り易くなって何から手を付けるのが良いかが見えてきます。
プロダクト品質は開発成果物の品質でプロセス品質は開発作業手順の品質
それでは、ソフト開発プロダクトの品質やソフト開発プロセスの品質とはどんな事でしょうか。一言で言い表すと、ソフトの開発作業で生み出された成果物がソフト開発プロダクトで、それらの成果物の良し悪しがプロダクト品質です。そして、ソフト開発プロダクトを生み出すための作業手順がソフト開発プロセスで、それらのプロセスの良し悪しがプロセス品質です。このソフト開発プロセスとソフト開発プロダクトとを、一般的なウォーターフォールの開発の流れにそって少し具体的に書き表すと次のような図になります。
ソフト開発プロセスとソフト開発プロダクトの図（クリックすると PDFファイルが開きます）
図の上半分がソフト開発プロセスで下半分がそれぞれのプロセスの成果物として生み出されるソフト開発プロダクトです。
ソフト開発プロセスは、設計から始まって、設計レビュー・コーディング・テスト設計・テストレビュー・テスト実施を経て、リリース判定に辿り着きます。ソフト開発プロダクトは、上記のプロセスの成果物として、ソフト設計書・（設計の）レビュー指摘・ソースコード・テスト計画書・（テストの）レビュー指摘・バグ一覧等の中間成果物を経て、実行プログラムや完成図書という最終成果物に辿り着きます。
各々の開発プロセスや開発プロダクトに付けてある青やオレンジの背景色の吹き出しは、各々のソフト開発プロセスやソフト開発プロダクトの品質を評価する時の主要な観点です。ソフト開発のプロセスは開発組織によって色々ですので、そのプロセスから生み出される成果物であるソフトプロダクトも色々です。この図に挙げたのはごく一般的なソフト開発プロセスとソフト開発プロダクトですが、開発プロセスの品質と開発プロダクトの品質を理解するには役に立つと思います。
プロダクト品質とプロセス品質のもう少し具体的に紹介すると
図だけでは少し判り難いですので、何点か例を挙げてもう少し具体的に紹介してみましょう。例えばソフト設計というソフト開発プロセスの品質の良し悪しを判断するのならば、設計の手順が決まっているか（要求仕様を確認し、実装する機能を決め、各機能を利用するインターフェースをきめ、設計書に書きだし、設計書のレビューを受け、、、などですね）、設計すべき項目が決まっているか（機能、性能、安定性、堅牢性、故障回復性、セキュリティ、保守性、、、などどんな設計項目が必要かですね）、設計した内容を書き記す設計書の記述様式が決まっているか（設計はフローチートで表すのかUMLで表すのか、設計書は Word や EXCEL で書くのか専用の設計ツールで書くのか、、、などですね）、などの設計の手順についての決めごとの良し悪しを見る事で、ソフト設計という開発プロセスの品質の良し悪しを判断できます。
同じ様に、設計レビューという開発プロセスの品質であれば、レビューの方法が決まっているか（会議形式なのか、資料回覧形式なのか、ピアレビューなのか公式レビューなのか、、、など色々なレビュー方法のどれをつかうかですね）、レビューの参加者の選び方は決まっているか（同等レベルの設計者、設計リーダ、技術に詳しいアーキテクト、品質保証担当、、、どのような参加者でレビューをするかですね）、レビューの時に確認するチェック項目は決まっているか（設計での注意点が整備されているかとか、過去に他の人がよく失敗した項目を一般化したレビューのチェックリストが整備されているかどうか、、、ですね）、など良し悪しから、設計レビューという開発プロセスの品質の良し悪しを判断できます。
同じ様に、図の下側の開発プロダクトについても少し具体的に紹介してみましょう。例えばソフト設計書という開発プロダクトの品質であれば、設計の粒度は適切で設計書の中で均等になっているか（設計書に書く内容の細かさですね）、設計の網羅性は十分か（必要な設計項目に漏れは無いかですえ）、設計した内容には自社の独自の技術は入っているか（他社との競争優位性を発揮する大元ですね、これが何もないと製品としての魅力に欠けます）、などが設計書という開発プロダクトの品質の良し悪しを判断するポイントです。
設計レビューという開発プロセスの成果物であるレビュー指摘（の一覧）という開発プロダクトの品質であれば、レビューで発見した指摘件数をレビューに要したコストで割って計算される指摘密度（レビューに掛けた工数やレビュー対象のページ数に対する指摘の件数ですね）、レビューで指摘した内容の修正率（レビューの指摘事項は全て修正したのか、いくつかは再度よく検討するとやっぱり修正は不要だったのか、要するに指摘の適切さですね）、レビューの指摘事項に対する修正の応答性（指摘内容を修正するまでに平均してどの程度の時間・日数が掛かったかですね）などが、レビュー指摘という開発プロダクトの品質の良し悪しを測るポイントとなってきます。
ユーザにとって重要なのは最終プロダクトの品質でその良否判定がリリース判定
ところで、図の下の方にも書いてありますが、ソフト開発プロダクトは中間プロダクトと最終プロダクトに分かれます。製品を利用するユーザにとって必要なのは、市場にリリースされた最終プロダクトの品質だけです。ユーザが実行するソフトそのものの品質が良く、ソフトの取説等の資料が判り易くなっていれば、それだけで十分です。 ですので、この最終プロダクトの品質が一番大切で、最終プロダクトがリリースしても大丈夫なレベルまで十分に品質が良くなっている事を確認し保証するための開発プロセスがリリース判定です。 ソフトのユーザの視点から見れば、最終プロダクトの品質とそれを守るリリース判定さえしっかりしていれば、問題は在りません。
しかし、市場に品質の良いソフトをリリースし、リリースしたソフトの機能追加やバグ修正等のために改定版のソフトをリリースするというソフト保守サービスを提供しなければならないソフトのベンダとしては、最終プロダクトの品質とリリース判定という最後の開発プロセスの品質だけに注目していては片手落ちです。最終プロダクトの品質を良くするには、開発の上流工程にある中間プロダクトの品質を良くする事が必須ですし、中間プロダクトの品質を良くするには、それらの中間プロダクトを生み出すソフト開発プロセスの品質を良くする必要があります。
ソフトの品質はプロセス品質２割プロダクト品質８割で決まる
ソフトの品質を良くするには、ソフト開発プロダクトの品質とソフト開発プロセスの品質の両方を良くする必要があるのは判りましたが、では品質をよくするためのコストをプロダクト品質とプロセス品質の向上に半分ずつ掛ければ良いのでしょうか？ 答えはＮＯです。 実際のところ、ソフトの品質はプロセス品質２割プロダクト品質８割で決まるので、品質を良くするコストもプロダクト品質を良くするために８割を投入するのが良いでしょう。このあたりが、工場での量産品の製造とは異なるところなので注意が必要です。
工場での製品の製造は製造設備が行います。設備は機械なのでちゃんと整備して正しい原料を入れれば、性能に見合った製品をバラつきなく生産してくれます。ですので、工場で生産される製品の品質を良くするには、製造設備の運用・維持のための管理プロセスの品質を良くすればそれで事足ります。製品を作り出す製造設備そのものの品質は設備メーカが保証してくれます。
ところが、ソフトの開発では設計にせよコーディングにせよ、開発プロダクトを生み出すのは全てソフトエンジニアという「人」です。人なので、一人一人の能力が大きく異なりますし、その能力を定量的に評価する良い方法もありません。能力を評価する良い方法は無いのですが、能力を向上させる方法はあります。教育と訓練です。新しい技術や手法についての知識を覚え込むための座学と、覚えた知識を実際のソフト開発の作業で使って習熟させる実施訓練とを根気よく続ける事で、ソフト開発エンジニアの能力は向上していきます。
様々なソフト開発についての技術や知識を知り、実際の開発プロジェクトで経験を積んだ優秀なソフト開発エンジニアをできる限り多く抱える事が、品質の良いソフトを作るための最も重要な事です。 そして、優秀なソフト開発エンジニアがその能力を発揮できる環境を揃えるのが、良いソフト開発プロセスです。
ソフトの品質を良くする活動では、 ISO9001 や CMMI のように、ソフト開発プロセスの改善にばかり目が行く事もありますが、ソフト開発の根本はソフト開発エンジニアが担っている事は、忘れないようにしましょう。 ソフト開発エンジニアに対する教育と訓練の場が充実していないと、品質の良いソフトはできてきません。