品質保証者の憂鬱「負のループを断ち切る」

筆者はこれまで35年ほどソフトウェア開発関係の仕事に従事してきました。
35年間の内訳は

• 25年間：ソフトウェア開発者(後半の数年は開発＆品証の二足のわらじ)
• 10年間：ソフトウェア品質保証者

としてです。

社会人になったばかりの頃はソフトウェア開発部門に配属されました。
それ以降、ずっとソフトウェア開発を生業にしていこうと思っていたのですが、ある時先輩社員から「ソフトウェア品質」について熱く語られ、”ソフトウェア品質って面白いな”と考えるようになりました。
ソフトウェアの品質管理や品質改善に興味を持ち始めていた矢先、諸々の出来事が重なり、あっという間に品質保証部への異動が決定します。
開発部門で働いている時には品質保証部門の方々の活動って意外と見えないものです。
漠然とした知識と経験のまま品質保証の仕事をすることになった私が、部門内外や社外活動で得たエピソードを交えて、私なりの「品質保証って何？」をお話していきたいと思います。

私が品質保証部に異動して、最初に戸惑ったことは
　「品質ってなに？」
でした。
もちろん、ソフトウェア開発に長年従事してきましたから、それなりに品質に対する意識はありましたし、品質改善・品質向上などの品質にかかわる活動に積極的に参加していました。
ですが、いざ「品質ってなに？」とベタに問われると
　「製品の質」
くらいの回答しか出来ない自分がいました。(ただ単に単語に分解しただけというお粗末な回答です)

有名な ISO 9000 を見てみると、品質とは
「本来備わっている特性の集まりが、要求事項を満たす程度」
と定義されています。

しかし、学会や有識者によって”品質”の定義は微妙に異なります。

話をソフトウェアに絞ると ISO/IEC 25000 系では、ソフトウェア品質を
「指定された特定の条件で利用する場合の、明示的または暗示的なニーズを満たすソフトウェア製品の能力」
と定義しています。
(このあたりの定義とその変遷については SQuBOK が詳しいです)

私なりに強引にまとめると
「製品・サービスが要求を満たす能力や程度」
といったところでしょうか。

次に、”保証”という言葉の定義について確認してみましょう。
”保証”は、ソフトウェア品質に限った話ではありません。

保証には、同じ発音で「補償」「保障」があります。
どんな意味の違いがあるのでしょう。それぞれの意味を調べました。

• 補償
  「補って」「償(つぐな)う」ということですね。
  生命保険の約款の中とかに「補償」という文言を見ることができます。
  何らかの損害が生じた場合に、受けた損害の分だけ埋め合わせすることのようです。交通事故などで人や物に与えた損害を金銭などで償うことなどが該当するようです。

• 保障
  「障害」が無い状態に「保つ」ということですね。
  「日米安全保障」ってものがありますね。その文言の中に「保障」の文字を見ることができます。「安全保障」「社会保障」のように、現在・将来の状態や地位を侵略などから防ぎ保護することなどが該当するようです。

• 保証
  「証(あかし)」を「保つ」ということですね。
  要は「問題がないこと」を請け負うこと、つまり「責任を負う」ことのようです。家電製品などを購入すると「保証書」が添付されていると思います。これはメーカーが製品の品質に「責任を負う」ということを書面で表したものです。

一口に”ほしょう”といっても色々と意味が違うようです。

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

製品を開発・提供している会社には、大抵「品質保証部」(の役割を担う部門)が存在していると思います。

先程の「保証」の定義によれば、
　「製品の品質を保証する」
が品質保証部の主な役割でしょう。
また、国際規格の「ISO 9001」にもあるように
　「顧客満足」
を達成することも重要です。そのため
　「顧客対応の窓口」
　「品質トラブルを未然に防ぐ」
などの業務も含みます。

私が品質保証部に異動して最初に感じた”違和感”は、顧客対応業務の量があまりに多いことでした。

とにかくひっきりなしに電話がかかってきていました。
自社の現場はもちろん、パートナー企業さん、販売店さん、直接のお客様などから、次から次に電話がかかってくるのです。

品質保証部の席の近くに居る他部門の人から「大声で電話をするな！うるさい」という社内クレームまでも多発する始末です。

知り合いの他社の品質保証部の方にお話を伺っても、どこの企業さんも似たような状況だったのを覚えています。

お客様からのクレームや改善要望の”圧力”で精神を病んでしまう人も結構居ると聞いて、寒気を覚えたものでした。

このように毎日大量のクレーム処理に奔走していると、品質保証部の仕事がどうしてもモグラ叩きのような対処になりがちです。
クレームを受けたら、現象を分析して、問題の原因を探ります。
原因がすぐにわからない場合は、暫定策として代替機をお客様のところに送ったり、分析用のログを収集したり、実機を回収したりと、意外と手間のかかる作業が多いです。
機器故障の場合は目視で故障箇所が分かるものもありますが、ソフトウェア故障の場合は大抵の場合は目視では故障箇所はわかりません。
ソフトウェアが誤作動して機械が破損したりすれば、”現象”としての故障はわかりますが、何が原因でそうなったのかを突き止めるにはそれなりの準備と分析が必要です。

品質保証業務がクレーム処理で忙殺されると、他の業務「製品の品質を保証する」「品質トラブルを未然に防ぐ」の活動がどうしても疎かになってきます。

その結果、さらにフィールドからクレームが増加し、負のループが完成します。
一旦形成された負のループは品質保証部員のやる気を削ぎ、心身ともに疲弊していきます。

一度負のループが完成すると、その後は「増殖モグラ叩き連鎖」が始まります。
トラブルを叩き潰すのが速いか、新種のトラブルの発生・従来種のトラブルの再発が速いかの「根性ゲーム」になります。
品質保証部員の多くが「俺たち、何やってるんだ？」と言いながら、どうしようもない状況で奮闘している姿を見てきました。
他の事業部や、他社の知り合いと話をしても、似たりよったりの所が多かった印象です。

人間は焦ればミスも増えますし、情報が錯綜して必要な処理が停滞し、不要な処理が増加します。
その間、モグラは高速で増殖していくのです。
モグラは疲れません。
さらに悪いことに、ソフトウェア・モグラの場合、根本対策を打たない限り、モグラはデジタルコピーされ半永久的に増殖が可能です。

上記のような環境が長年放置されると、次に良くない現象として、開発部門と品質保証部門の関係が悪化してきます。
品質を保証すべき部門が正常な機能を果たせていないので、開発部門にもしわ寄せが行きます。
品質保証部門は「開発部門が粗悪な製品を製造する」と言い、開発部門は「品質保証部門はただの”お客様への謝罪部隊だ”」と言うような関係に陥りやすいです。

品質保証部門には強力な権限が付与されている会社さんが多い印象です。
品質保証部門が「その製品は出荷停止！」と一言いえば、製品は出荷停止されます。
その結果、開発部門と品質保証部門で品質の総点検が始まります。
それ自体は悪いことではありませんが、売上に寄与しないばかりか、開発部門と品質保証部門の間で責任の押し付け合いが始まることもあります。

「製品の品質に責任を負う」のは品質保証部門ではあるのですが。

私の知り合いの品質保証部長が嘆いていました。
「今の品質保証部門と開発部門の関係は”警官と泥棒”だ。どっちも相手を信用していない」
こんな関係にはなりたくないと誰もが思いつつもです。

”銀の弾などない”…。

ソフトウェア開発関係の仕事をしていたら、上記の言葉を一度や二度くらいは聞いたことがあるでしょう。

フレデリック・ブルックスが著したソフトウェア工学とソフトウェアプロジェクト管理の書籍「人月の神話」に登場する言葉です。

この言葉の意味するところは
狼男を一発で仕留める銀の弾が無いのと同じように、ソフトウェア開発の諸々の問題を一発で解決する施策など無い
です。

この書籍では主に「ソフトウェア開発における生産性」について述べられていますが、品質保証にも多くの示唆を与えてくれます。

品質をあっという間に安定させる ”特効薬” などはありません。

”銀の弾などはない” けれども、”出来ない理由ばかりを探していても、解決しない” のもまた事実。

上記で特効薬など無いと言ってしまっているので、驚くような解決策はありませんが、一つだけ言えることは
　「顧客対応の窓口」
と
　「製品の品質を保証する」
の歪な工数比率を見直すことは必要だと思います。
銀の弾が無いの同じように、両方を完璧にこなすスーパーマンも居ないのですから。

歪な工数比率を正常化するには「物理的に担当を分ける」ことが解決策の一つになると思います。

話が脱線してしまいますが、私はSF小説が好きで良く読んでいました。
神林長平氏の「戦闘妖精・雪風」が好きでした。
雪風は、地球外の惑星の異星人(接触できていないので異星人かどうかも不明)と闘う空軍に所属する電子偵察機です。
電子偵察機の使命は一つ「たとえ目前の味方を見捨ててでも敵の情報を持ち帰ること」です。
味方が全滅しようとも、自らは決して参戦せず、確実に敵の情報を持ち帰る。
(そのために、友軍からも煙たがられるのですが)

サッカーでもそうでしょう。
味方が劣勢だからといって、ゴールキーパーまで前線に上がってしまっては試合に負けます。

確実に「製品の品質を保証する」業務を遂行できるか、が肝だと思っています。

書き進めていて、意外に話が長くなってしまったので、この続きはまた書きます。
物理的に担当を分けて「製品の品質を保証する」を任されたとき、自分に何が出来て、何が出来ないのか。
また、何をすべきで、何をすべきでないのか。
・・・考えることはつきません。