品質保証者の憂鬱「制限事項 VS 注意事項」

前回は「管理」と「保証」の違いについて考えてみました。
今回は開発部門と品質保証部門、さらにマーケット部門、営業部門、調整部門などを巻き込んで日夜展開される「制限事項 VS 注意事項」をお話したいと思います。

製品・サービスの開発が順調に進んでいて、開発部門から「最終チェックも終わるし、”大体”OKなんじゃね？」って声が出てきて、さらに品質保証部門としても「指摘は”ほぼ”是正されたし、弊社の定める品質基準も”ほぼ”クリアになったんじゃね？」となったとします。
その後「出荷承認会議」が設けられ、開発部門長と品質保証部門長が”製品・サービスの出荷を”めぐって相まみえることになります。
（いつもそんなにピリピリした関係ではないのですが、出荷承認会議だけは空気が張り詰めることが多い印象です）

大抵の場合、各部門が個々に思い描いている製品・サービスの完成度の認識には差異があります。
会話の中に「大体」とか「ほぼ」っていう文言が入る場合、かなりグレーな状況です。

検出されたバグ数やパフォーマンスデータなどの「定量的に評価できる」指標が確立されていれば、事態は深刻ではありません。
しかし「人間の感覚」や「定性的な評価」でしか推し量ることができない指標を前にすると、かなり議論は白熱したものになります。

私が駆け出し品質保証者だった頃、出荷承認会議で議論している製品・サービスに「何らかの問題」があった場合、これらの問題を「制限事項」にするか「注意事項」にするかで大いに盛り上がるのを不思議に思っていました。
大抵の場合、

• 開発部門は「注意事項」として処理することを主張し、
• 品質保証部門は「制限事項」として処理することを主張する

のです。
マーケット部門、営業部門、調整部門もどちらかの主張を支持しています。

まだ私は駆け出しだったので「え？それって何が違うの？」と思ったものです。

「制限事項」は「利用における限界を示す事柄」です。
ここで言う「限界」とは、製品・サービスが提供する機能を「制限」するものを指します。
例えば本来、製品・サービスに要求されている機能が「画面の表示更新3秒以内」であるのに「画面の表示更新5秒以内」と制限されているような場合は、「制限事項として”画面の表示更新5秒以内”とする」と利用に制限があることを明記することになります。
もし「魅力的品質」が「画面の表示更新3秒以内」で、「当たり前品質」が「画面の表示更新5秒以内」であれば、なんとか及第点になりますが、この「当たり前品質」では「お客様(ユーザ)が考える製品・サービスの価値を大きく損なう」と考えられる場合、現状設けている「制限」を最終的に取り除かなければなりません。
（画面遷移が多いシステムの場合、画面を開く度に毎回5秒もかかっていたら、どんなに気の長い人でもイラッとすると思います）

製品・サービスを修正し「制限」を取り除いてからお客様に提供できるのであれば、それに越したことはありません。
しかし、お客様が製品・サービスを必要とする納期の関係によっては「制限有り」の状態で製品・サービスを出荷するしかないと判断することもあるでしょう。
製品・サービスを使用する時期が遅れる方がお客様が受ける損失が大きいと判断した場合は「条件付き出荷」として許可されることになります。
「条件付き出荷」の場合「いつまでに制限事項を取り除くか」を開発部門がお客様や品質保証部門に対して約束する必要があります。

会社によって「制限事項」の意味するところは異なるかもしれませんが、制限事項は「利用時に何らかの制限」をかけるため、殆どの場合歓迎されません。

「注意事項」は「利用において気を付けるべき事柄」です。
かなり平たく言うと「(修正しないから)注意して使ってね」ということです。

例えば先程は制限事項として処理した「画面の表示更新5秒以内」が、「初回画面を表示した後、他の画面へ遷移や再表示が(ほとんど)行われない」画面での性能だったとしましょう。
この場合は「画面の表示更新3秒以内」に対する「制限」としての「画面の表示更新5秒以内」はこのまま放置してもほぼ問題ないと言えます。

先程の制限事項とは違って、多少不便なことはあるかもしれませんが、製品・サービスが提供する価値を大きく損なうこと無くお客様に機能を提供できる場合は「注意事項」として処理します。
問題を修正・テスト・確認するコストが膨大になり、その割に得られる改善効果が少ない場合、費用対効果の関係で「無理に修正しないで注意事項にする」を選択することは多々あります。
（ただし、必要な情報は取扱説明書などに明記します。不要なクレームやトラブルを防ぐためです）

筆者は開発部門と品質保証部門の両方を経験してきましたので、どちらの主張もよくわかります。
安易に注意事項付きで製品・サービスを出荷したがために、市場で正しい評価を得られずに悪評が立ち、結局製品・サービスを改修することになった事例も少なくありません。
最終的に改修するのだったら計画して限定出荷にしておいて「計画されたリプレース」を実施した方がトータルコストは安く済んだのにと思うこともありました。

また「(今思うと)どうでもいい改修」に膨大な修正コストと時間をかけて出荷したけれども、出荷遅れによるダメージを取り戻すことなく、無駄に開発リソースを浪費してしまって、市場機会を失ってしまったこともあります。

マーケット部門、営業部門は「D（デリバリー）」を主張し、市場機会の喪失を恐れます。
開発部門は「C（開発コスト）」を主張し、ただでさえ少ない開発リソースの浪費を恐れます。
品質保証部門、調整部門は「Q（製品・サービスの品質）」を主張し、クレームや調整コストの増加を恐れます。

製品・サービスを”適正”な状態で世の中にリリースするのは非常に難しい作業なのです。

どの部門の主張もよくわかります。
Q、C、D のバランスが崩れると、全体最適からどんどん遠ざかってしまいます。

その中でも特に”品質保証部門”は製品・サービスの出荷に強大な権限を付与されていることもあり責任は重大です。

「製品・サービスを開発する組織だけで品質を満足させることができる」のであれば品質保証部門なんて必要ないと思います。
しかし、多くの会社で独立した組織としての品質保証部門を設けているのにはやはり理由があるのだと思います。

”適正”を正しく判断するにはコストがかかりますが、”適正さ”を疎かにした結果、信用・信頼を一瞬にして失うことは簡単に起こりえます。

私がよく知る品質保証部門の長がこんなことを言っていました。

「我々には権限が与えられている。それもかなり強い。でもなあ、強大な権限があるってことは、もし重大な不祥事があったときには品質保証部門長が逮捕されることもあるんだぞ」

と。