「定量的・・・ススメ・・・ガイド」の紹介 ─ その3

　間が空きまくっていますが最後まで書きます、ススメガイドの紹介。

www.kzsuzuki.com

　第二編の第2～5章では、上流工程の定量的品質管理を、PDCA的に説明しています。

　第2章の「組織的準備」とは、裏を返すと、定量的品質管理は、単一のプロジェクトでがんばるようなものではないということ。

『続 定量的品質予測のススメ』　P.68
標準プロセスはガイドラインを整備し、チェックリストを育て、管理指標を最適化し続けるのは、有期活動である「プロジェクト」ではなく、永続的に存在する「組織」の役割である。　※太字は引用者

　CMMIに通ずるところがありますね。

　さて、組織でその準備ができたとして、次に陥る誤謬が「基準は決まった。さあ、全プロジェクトに適用せよ」という無惨なお達し。当然無理な話ですが、ではどういう管理レベルにすべきか、ということを説明するのが第3章。

『続 定量的品質予測のススメ』　P.76
プロジェクトには、そのプロジェクト特性に応じた適切な作業量の品質管理方法を提供する必要がある、端的に言えば、軽いプロジェクトには軽いプロセスを、重いプロジェクトなら重いプロセスでも、である。

　「システムリスク」「プロジェクトリスク」「開発コスト」という大きく3つの要素の大小を組み合わせたプロジェクト・プロファイルに基づいて、管理レベルを決定する手法が紹介されています。
　一定のルールによって管理レベルを決めることで、プロジェクトのコミットメントが得られるようにします。

　計画に基づいた「測定」については、第4章。
　当然のことながらこの測定こそが、現場にもっとも負担を与えるプロセス。品質管理が成功するかどうかは、現場の理解が得られるかどうかにかかっています。
　本資料ではそのことが、繰り返し警告されます。「長い目で見てほしい！いつかは組織の役に立つから！」という説明で、爽やかに協力してくれる人はあまりいないでしょう。

『続 定量的品質予測のススメ』　P.86
品質管理分門等は、収集されるデータそのものの品質、すなわちバラつき等や開発現場でのデータの測定方法を定期的に確認するとともに、定期的に、あるいは開発現場の要請により、地道にデータ測定・収集の目的、データ項目の定義、あるいは収集方法の説明を行う必要がある。

　逆に、品質管理を担当する人間の踏ん張りどころも、ここってことですね。ここで「全然協力してくれない！協力しない方が悪い！」と開き直っても、誰もなぐさめてくれません。

　第5章は、PDCAの「C」および「A」。収集したデータの分析と、得られた結果のフィードバックです。分析の技法については割愛されていますが、当たり前ながら忘れられがちなことが書かれています。

『続 定量的品質予測のススメ』　P.90
対策の実行内容は、そもそもの問題の発生原因を是正できるものでなければならない。（そもそもの問題の本質を忘れて、形式だけの品質改善策を実行してはならない。） 対策の実施範囲は、潜在的な同様の原因を是正する必要十分な範囲とする。（広すぎる範囲に、詳細すぎる品質改善策を強いてはならない。）

　「広すぎる範囲に、詳細すぎる品質改善策」。これは、手を動かさない人が求めがちなことですよね。最適な改善策の範囲を求めることは、分析以上に難しいと思います。

　さて、P.79のコラム「レビューによる設計品質評価プロセスでの留意点」に、テストとレビューの比較があります。

	テスト	レビュー
プロセス	単体/結合/総合テストの計画・テスト設計・実施（障害管理）などプロセスが明確	ピアレビュー、公式レビューがあるが、プロセスとしては不安定
技術	テスト技法があり、また、テスト要領書のレビューにより、確認の網羅度とINとOUTが明確	チェックリストなどでレビューの観点を均一にしようと試みるが、レビューアにより観点がさまざま
人	テスト要領書を作成することでテスターのスキルをカバー	レビューアのスキルによりレビューの質が異なる

　まさに悩み多きところです。

　たとえば、外部設計の段階でレビューの記録をしようとしてハタと気付く。
　「要件定義と外部設計の、明確な境界ってどこだ？」
　「こういう機能が欲しい」は要件だろうけど、「こういう動きにしてほしい」は要件より一歩進んだ「仕様」だと言い切れるか。こちらから提案した動きに対し、お客様に「いや、こういう動きの方がいいなあ」と指摘されて修正するとしたら、それは「欠陥」ということになるのか。考え出すとキリがない。なので、レビューの管理は内部設計以降でこそ有意義なのかと考えたりもしています。

　チェックリストについても、開発するプログラムはそれぞれ違うのだからといって、共通的に「使える」ものを作ろうとして抽象度を上げると、結局「使えない」ものに堕す・・・というジレンマがあります。

　鈴木の品質管理の冒険は、まだ始まったばかり！（ご愛読ありがとうございました。鈴木先生の次回作にご期待ください）