ソフトウェア開発における品質管理の難しさ
製品そのものの質には、厳密にいうと「プロセス品質」と「成果物品質」があります。
この点については、たとえばソフトウェア開発の業界にいらっしゃる方であればすでに周知の事実かもしれません。ソフトウェア品質（ISO/IEC 25010）などに定義されている品質モデルをよくよく読んでみれば明らかです。
この図はＩＴ業界においてはとても有名ですよね。
いまでこそISO/IEC 25010:2011に移管され、あらためて「ソフトウェア品質」として再定義されていますがその根源的なコンセプトは何も変わっていません。そして、現在定義されているISO/IEC 25010では
と言われていますが、このなかで言う「製品品質モデル」とはISO 9126の外部品質を指しており、「利用時の品質」はISO 9126の利用時の品質からそのまま変わっていません。品質特性の中身は多少変わっていますが、根本的な考え方に違いはありません。
そう考えるとISO/IEC 25010のなかでいう「システム/ソフトウェア製品品質」は結果的に外部品質だけを挙げているように見えますが、その外部品質が依存している『内部品質』や『プロセス品質』もすべて包含されていると考えるべきです。
また余談になりますが、狩野モデルでいうところの「当たり前品質」と「魅力的品質」というのもまったく同じだと考えています。契約の中で定めた製品に対する仕様を満たすのは、お客さにとっても契約にとっても「当たり前」のことです。この部分を100%達成させるのは企業としてもそうですが、そのプロジェクトにかかわると決めた以上、かかわった全員が「当たり前」のことだと自覚し、その「当たり前」を当然のように実施できる取り組みが求められます。
では、そうした取り組みを「品質管理」で実施できるのか？と言うとどうでしょう。
そもそもこのシステム/ソフトウェア製品品質（以下、成果物品質）が担保されなければその活動のなかで作成された成果物そのものに報酬に見合った価値はありません。
そのことがわかっているからこそ、日本では特に成果物品質を偏重する傾向があります。しかし、欧米ではその逆で、
「成果物が正しくできあがるはずの正しいプロセスを理解し、
そのプロセスを忠実に実施していれば、常に安定した質の成果物ができる」
という観点から「プロセス品質」を重要視しています。
これは、先のソフトウェア品質モデルの図からもわかります。
成果物品質の最終的な形が上図でいうところの「外部品質」であった場合、この外部品質は必ず内部品質の影響を受けますし、内部品質に依存してその品質の上限が確定します。そして内部品質は、必ずプロセス品質の影響を受け、同時にプロセス品質の高さに依存して内部品質の上限が確定します。
このような関係性が成立していることから、「プロセスが真に正しければ、そのプロセスによって作成された成果物も正しいものになる」という因果関係が成立するのは自明です。もしも成果物の品質が期待値未満だったとしたら、それはどこかプロセスに問題があったということです。
日本企業の多くでいまだ問題が絶えないのは、結果や成果が期待値未満だった際に
期待値未満しか出せなかった『人』に責任を求め
『人』を交代させればなんとかなると思い込み
プロセスそのものに目を向けようとしない
からにほかなりません（正直、こういった考え方しかできない人に管理職や経営者をさせるべきではないとさえ思うのですが…）。
そのため、欧米では「出荷検査」のような水際で問題を止めようとする文化があまりありませんでした。自分たちのプロセスに自信を持てるような取り組みをしているため、出荷前に疑う必要が無いからです。
このような水際で問題を堰き止めようとする日本の文化から生まれたのが「品質管理」や「品質保証」です。品質管理と品質保証はまったくの別物ですが、日本では大抵同じ部署が取りまとめることが多いとされています。
「品質管理」は製造業などにおいて、研究・開発が完了して以降、工場のラインにのせて量産するなかでの品質状況を管理・維持することを目的としたものです。
これが何を示しているかというと
あらかじめ質が維持されるプロセスの確立された状態が
変化していないかどうかを監視・コントロールする
仕組みだということです。
さて、そんな製造業の長い歴史の中で生まれた品質管理の考え方をソフトウェア開発にも流用しようという発想はいいのですが、翻ってソフトウェア開発とはどのような業務の進め方になっているでしょう。
ソフトウェアに量産はあるか？
・コピペで済むので、業務としてはありません。
・ソフトウェアは開発しかありません。
ソフトウェア開発はどのように進められるか？
・原則、プロジェクトという単位で行われます。
では「プロジェクト」という活動は具体的にどのような特性を持っているでしょうか。
そう、「独自性」というものがあります。
その名の通り「未経験の要素」を含むため、過去の経験やプロセスをそのまま踏襲するだけでは不確定要素が大きくなりかねない…という特性です。
品質管理は、すでに確立されたプロセス（ベースライン）があるからこそ、結果や成果と比較することで監視ができ、異常を検出することが容易となり、だからこそコントロールすることが可能となる仕組みです。
しかし、常に独自性を持たざるを得ないプロジェクト活動においては、この「確立されたプロセス」を使うことができません。厳密には使える部分が限定されます。そのような状況下で品質管理を実施することは可能でしょうか。
答えは「極めて難しい」です。
確かに不可能ではありません。プロセスを部品化し、それらの部品を蓄積し、部品の組み合わせによって常に最適解を選択することは可能かもしれません。
ですが、
・過去のプロジェクトのプロセスを詳細に蓄積している
・蓄積したプロセスを部品化し、抽出可能な状態に整理している
ような企業がどこに存在しているのでしょうか。
すくなくとも私がこれまでに在籍してきた企業、協業してきた同業他社、二次請け・三次請けで受けてきた中でお付き合いしてきた元受けの大手SIer、etc.…かれこれ100社以上見てきましたが、プロジェクトプロセスのベストプラクティスを部品化、整理、管理し、それらを未来のプロジェクトに最適な形で利用し、それぞれのプロセスに即した品質管理を行っている…なんて組織を１度も見たことがありません。
たしかに、品質管理の多くは「定量的」に評価することが多く、上司に対しても、お客さまに対しても「数字で見せる」ことができる管理方法なため説得力を生みやすく、その意味で活用したい方法論であることはわかります。
ですが、品質管理そのものの特性を考えれば、プロジェクト活動との相性が相当に悪いことがわかるのではないでしょうか。
こうした取り組みを推奨する人は、おそらく「品質」に特化した取り組みだけに注力してきた方なのでしょう。研究職のような方かもしれません。しかし、そうした人たちはおそらくプロジェクトマネジメントのベテランではないのでしょう。
プロジェクトやプロジェクトマネジメントを深く知れば知るほど、相性の悪いことがわかるからです。
みなさんもプロジェクトマネジメントを遂行する中で、お客さまに品質の報告をする際にこうした「品質管理」手法に則った説明をしている人は多いでしょう。しかし、その説明根拠にみなさんは本当に納得していますか？
たとえばこのようなゾーン分析法などがありますが、その方法論や仕組みは大体の人が理解できると思います。手法として間違っているわけではないのでしょう。
でも、このゾーン（境界）を定める閾値はどのように定めているでしょうか。
IPAやJUASの提供する偏差値をベースにしているところが多いのではないでしょうか。では、みなさんの行うプロジェクトの閾値がIPAやJUASの提供する偏差値を用いることを妥当とする根拠は何でしょうか。さらにいえば、こうしたゾーン分析手法自体の説明・解説はいろんなサイトでわかりますが、
「閾値の正確性／適切性／妥当性を証明する方法」
がどこかで説明・解説されていたりするでしょうか。
…残念ながら、ほぼ見かけません。
ブログ等ではあるかもしれませんが、公式に定められているところはありません。そもそもプロジェクト一つひとつが独自性という要素を持つ以上、よほど開発プロセスが固定化／標準化されていない限り、自組織の過去データを引用しても妥当といえない可能性もあるのです。
そんな薄氷の上に立つかのような、とてもリスクの高い手法であるということを認識したうえで、どうすれば品質を証明できるのか考えなければなりません。
少なくとも私は品質に関する情報を収集し、一つひとつの定性的な問題と向き合わずに数字的な偏りだけからすべてがわかった気になるだけの「品質管理」は不要と考えています。
一つひとつの問題、課題に対して都度適切な対処ができていれば何も問題はありません。そう、問題解決管理（検証工程であれば「障害管理」、設計工程であれば「指摘管理」）のプロセスさえ正しく構築できていれば、わざわざ精度を落とすだけの品質管理に頼る必要もありません。
発生した問題を詳細に把握したうえで
対処は適切か
ほかに類似の問題を見直す必要はないか
再発防止は検討できているか
対処の結果、影響範囲は特定できているか
たったこれだけのことが一つひとつの問題に対して適切に管理できていれば、別途「ほかに品質上の懸念はないか」という検討すら必要ありません。②の「ほかに類似の問題を見直す必要はないか」が適切に確認できている以上、別の方法でほかの問題有無を探しても見つかるはずがないからです。
仮に見つかるようなことがあったとしても、それは「品質管理をすればよい」と判断するものではなく、プロセスを中心に考えるのであれば「問題解決管理方法を見直せばよい」ということになるはずです。
今後、ほんの少しずつでもそうやってソフトウェア開発の「品質」を正しく導けるプロジェクトが増えてくれるといいなー…と個人的に思っています。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。