【ソフトウェア品質】納品後不良トラブル

トラブル発生時、トラブルを起こした当事者が、トラブルに見舞われたマネージャーが、検分している品質保証担当者が最初にすべきことは、目の前で起きている問題を”問題である”と認めることからになります。

ここでまずまっさきに注意すべきは、「誰に」問題があるかという問いを持ち出さないことです。これをしなかったがために、どれだけの無駄な時間が失われ、どれだけお客さまに損害を与えているか、計り知れません。それでも「自分のせいじゃない」「自分にも問題はあったかもしれないが、相手の方が悪い」なんてくだらないことを言い合うと言うのであれば、それはもう確信犯的な社会悪です。

いつも現場に立ち会うたびに心底思います。

誰のせいかなんて、問題そのものを解決するための材料になりません。人に原因を求めると、目の前の状況は解決できなくなります。なぜなら人に原因を求めるということは、解決方法は「当人の能力や思考を変える」あるいは、「人そのものを変える」しか無くなってしまうからです。それができるなら苦労はしないんです。

もちろん、容易に問題を起こさないスペックの要員に交代できるほど、潤沢に人的リソースが確保できていればそれも可能ではあるのですが、現実的な話からは程遠くなっていってしまうことでしょう（そもそも、そんな優れた人材が開いているという時点で、会社の事業戦略的に何かがおかしい）。人に原因を求める人はとりあえずその場から席をはずしてもらった方がよいかもしれません。本質的な話が絶対に進展しなくなってしまいます。

そして、問題そのものと向き合う姿勢ができたら、次に「どこに（なにに）問題があったのか」という事実情報に基づいた根本原因を明確にする必要があります。

問題の技術的な根幹は大別して２つしかありません。

　・ 誤りがあった
　・ 不足していた（漏れていた）

このうち、「誤りがあった」場合は、比較的解決方法は確立させやすくなります。なぜなら『やることはやっていたが、やり方に誤りがあった』ということなのですから、誤りのあった部分のみ特定して、"やり方"を改めれば済むことになります。

一方で「不足していた」場合は、解決が難しくなります。ビジネス固有のシステムは小さいものは数十万から、大きなものは数億、数百億にいたるまで、その額は千差万別です。そのため、その金額に見合う責務を果たさなければならないにもかかわらず、それが漏れていた…最大限役割を果たしているにもかかわらず観点から漏れていたのならまだしも、作業タスクとして漏れていた場合は致命的となってきます。どんな言い回しであっても、ユーザーの目には『支払った金額に見合う等価の作業を行わず、手を抜いていた』と見えてしまうからです。

色々な会社のトラブル解決をしましたが、私のところによく依頼されるのが、可能であれば「不足していた（漏れていた）」という理由にならなくていいように、問題理由を調整することです。

図にするとこんな感じでしょうか。

内容によっては、真因にたどり着けなくなる可能性もありますし、ただ単に矛先をそらすためだけというのであれば、大抵は断りますが、言い方／説明の仕方を調整するだけで根本的な解決に誘導できるような場合であれば、稀に対応することもあります（まぁ、言い訳にしかならないので、私自身がマネージャーなら絶対しませんが）。

でも、ほとんどの人はロクにお客さまを納得させられる理由を見つけることができません。多種多様な問題解決と日頃から向き合っていないと、ちょっと知識をかじった程度では無理なのです。

ゆえに、品質保証活動において、トラブル前にプロジェクトに参画する場合、スケジュールやコストなどの制約があっても「必要なタスクや作業を不足させない」ように監視・指摘することを怠ってはいけないわけです。もし、これがおろそかになった場合、トラブル解決のための取り組みは非常に困難になります。