品質保証者の憂鬱「管理か保証かそれが問題だ」

前回の投稿から随分と時間が空いてしまいました。
申し訳ありません。
前回は”品質”と品質保証部、その役割と課題などについて述べさせていただきました。
今回は”品質”というワードで必ず登場する”品質管理”と”品質保証”について、筆者の思うところを述べてみたいと思います。

筆者が開発部門から品質保証部門に異動して間もない頃、品質保証部門は品質保証部員を、開発部門が開催するもろもろの会議（レビュー会議、進捗会議、フェーズ移行提案会議などなど）に積極的に送り込んでいました。
当時の品質保証部門の構成員は元開発部門出身者が多かったので、”技術的な設計観点”で開発部門の活動に介入していました。
それでも品質はなかなか安定せず、突発的な障害があちこちで発生していました。

前回、品質保証とは「製品・サービスが自社の定めた品質を維持しているかを確認し、お客様に満足を提供するための体系的な活動」と定義しました。

確かに上記の定義によれば、品質保証部門が開発部門の様々な活動に参加することも理にかなっているように思えます。
そんな活動を傍から見ながら筆者には漠然とした疑問が湧いてきました。

「あれ？これって開発部門自身が実施する活動とどこが違うんだ？」

不安に思ったので、当時参加していた日科技連でお世話になっている先輩に教えを請うことにしました。
先輩曰く

「まずは世間一般に周知されている国際規格や標準を確認してごらん。それから話をしよう」

と言われ、IPAが発行している共通フレームを確認しました。
IPAとは「独立行政法人情報処理推進機構」といい、メディアでも時々登場しているので名前を見た方もいるのではないでしょうか。
品質にかかわる様々な活動を支援している機構で、情報も豊富に揃っています。
筆者も「データ白書」には非常にお世話になりました。

共通フレーム2013によると「品質保証プロセス」は支援プロセスに分類されています。

品質保証は”支援”のプロセス群に属するので、積極的に”製品・サービスを開発”する側とは異なる活動であることがわかります。

共通フレームでは、品質保証プロセスを以下のように定義しています。

「ソフトウェア製品及びその作成過程が規定要求事項に従い、確定した計画どおりであることを客観的に保証する。共同レビュー、監査、検証及び妥当性確認プロセスを、品質保証の手法として使用してもよい。」

共通フレームの基本構成の中で、品質というキーワードを検索すると「品質管理プロセス」を発見します。
品質管理は「組織のプロジェクトイネーブリングプロセス」に分類されています。

え？イネーブリングプロセス？？？
耳慣れない言葉です。(そもそも英語をカタカナにしてしまった時点で原文を想像し辛くなってます)
Google先生に質問すると「ISO/IEC/IEEE 15288：2015 システムライフサイクルプロセス」の情報がヒットしました。
この規格は「人が作成するシステムのライフサイクルを記述し，システムエンジニアリング手法を適用するための共通のプロセスの枠組みを提供する 」と書かれています。
要はシステムエンジニアリングに必要な条項ってことですかね。

共通フレームでは、品質管理プロセスを以下のように定義しています。

「製品及びサービス，ならびにそれらの作成プロセスが組織の品質目標に合致し，顧客満足を達成することを保証する。」

あれれ…困りました。
品質管理の説明に「保証」という言葉が出てきてしまいました。
これは混乱しますね。
品質保証と品質管理の定義で違うところを探すとすれば「客観的に」という文言が有るか、無いかの違いくらいしか区別がつきませんが、何となくですが、品質管理と品質保証の違いを想像できます。
しかし、まだ漠然とした違いなので、上記を踏まえて、品質保証部門が開発部門と一緒になって実施している活動は何なのか？を先輩に聞いてみることにしました。

先輩は一言
「君は”品質管理”と”品質保証”の区別ができていないようだね。品質は保証するだけじゃだめ。品質を管理しないと品質は永遠に安定化しない、つまり保証できないよ」
と言いました。

理解が追いつきませんでした。
そもそも”品質の管理”って品質保証とどのように違うのでしょうか。

品質保証を知る前に、”品質の管理”を理解しないとだめだということでした。
先輩は私に２つの”コントロール”の話をしてくれました。

これから述べる内容には筆者の私見がかなり入っています。
一般の教科書や文献に載っていたというわけではないので、一つの考えと思って読み進めてください。
まず、

品質が安定している　＝　品質が管理(コントロール)されている状態

と考ます。

品質が”管理(コントロール)されている状態”ってどんな状態でしょうか？
ここで頭に浮かぶのはQC7つ道具の「管理図」でした。
管理図を簡単に言うと「製品・サービスの品質が”安定して”製造・提供されているかを示すものであり、品質のばらつきを分析し管理するためのグラフです。

横軸には時間や製造ロットを当てはめます。
縦軸には品質のばらつき（中央値からどれだけ乖離しているか）を描画します。
管理図のイメージ図を以下に示します。

例えば上図の場合、中央値は2.5で、本来は測定値は中央値付近に”管理(コントロール)”されているべきですが、群4の値は4.5になっており、中央値からかけ離れた値になっています。(この値が異常値なのか、通常でもありえる値なのかは別途統計的な手法を使って検証しますが、今回は概念的に捉えてください)

長い期間にわたってデータを追っていると、どこの値が”異常値”であるのかが分かるようになります。
このような”異常値”をすぐに発見して対処するために、管理図で常に監視し、適切に管理(コントロール)されている状態が”管理されている状態”であると考えます。
”管理されている状態”にならなければ、当然品質は安定しません。

さて、さきほど”管理されている状態”について言及しました。
”管理されている状態”を実現するには、何が必要なのでしょうか？

管理図を描いて、異常値がわかったとしましょう。
さて、何をすれば異常値を正常値に近づけることが出来るでしょうか？
次の概念は

品質を望ましい状態に変化させる　＝　品質を制御(コントロール)できる

です。
おっと、ここで”管理”と”制御”に同じ「コントロール」という文字を当てはめてしまいました。
これはミスではなく、わざと当てはめています。
先輩曰く、この「コントロール」という言葉が被ることが”制御”と”管理”の理解を難しくしている問題の一つだということでした。

筆者なりに解釈すると、この”制御(コントロール)”とは「あるプロセスにある入力を与えた場合、期待する出力が得られるようにプロセスを設計・実装・実行できる能力」です。

レビューを例にしてみましょう。

仕様書をレビューして欠陥を検出するプロセスを考えます。
ある製品・サービスに仕様バグが多発しているため、仕様書作成の段階で欠陥を検出して修正したいとします。
つまり、仕様書のレビューをしっかり実施して欠陥を検出して取り除きたいと考えています。
さて、どれくらいの欠陥を取り除けば仕様書の品質は安定化するといえるでしょうか？また、欠陥を抽出するのにどんなスキルセットを持った人的リソースをどれくらいの時間投入すれば期待する欠陥数を検出できるでしょうか？

上記の答えは簡単には出ません。
組織は長い時間をかけて、人材を育成し、プロセスを設計し実装して、プロセスを実行できるだけの能力を獲得する必要があります。
闇雲に人をかき集めて「さあ、レビューしろ！」と号令をかけても成果は得られないのです。
条件が満たされて初めて、”レビューによって仕様書から欠陥を検出する”プロセスが制御(コントロール)できるのです。
このような条件を満たした状態が”品質を制御(コントロール)できる”状態であると考えます。

品質は”制御(コントロール)”されているべきであり、
品質は”管理(コントロール)”されているべきです。
制御と管理の両輪が回ってこそ、安定的に品質が作り込まれている状態だと言えると思います。

では、このような組織・仕組みをどうやって作っていけば良いのでしょうか？

一つに指針になるのがISO9001に代表される「品質マネジメントシステム」であり、IPAの共通フレームであると考えます。

「マネジメント」は制御や管理よりももっと大きな枠組みとしての話だと考えられます。

今回は品質というキーワードを掘り下げていき、品質保証の他に品質管理について考えてみました。
今後、品質の他のキーワードである「品質計画」「品質改善」も含めて考えてみたいと思います。