新人技術者のためのロジカル・シンキング入門（10） ―― 「工学の知」を実務に生かす

【1】「いきなり解決策に飛びつかない」がポイント（2/2）

● 顧客クレーム処理を振り返る

　エレベータ事故ほど重大なものでなくても，組み込みソフトウェアの開発をしていれば，顧客からバグ報告が挙がり，それに対処することがあると思います．そんなとき，バグ対応に非常に時間がかかってしまい，重大な顧客クレームに発展してしまったという場面を考えてみましょう．あなたなら，どのような再発防止策をとりますか.

　ありがちなのは大反省会を開かされ，偉い人にさんざん絞られた揚げ句，「顧客を重視し，コミュニケーションを円滑化する（図4）」という結論を導き出して，やっと解放される，というものです（筆者も似たような経験がないわけではない）．

図4　大反省会にありがちな「解決策」
「顧客を重視し，コミュニケーションを円滑化しろ」というのは反論し難い結論である．しかし，問題を切り分けずにこの結論に飛びついた場合，同じ反省の弁をまた述べることになりかねない．

　「顧客を重視し，コミュニケーションを円滑化する」こと自体は間違いではありません．しかし，結論があまりに当たり前すぎるのが気がかりです．本当に問題を切り分けた結果こういう結論を採用したのなら効果はあると思いますが，そうでないとしたら，また同じような反省会を開くはめになりかねません．では，どうしたらよいのでしょうか．

　筆者ならまず，顧客からの最初のバグ報告がなされてから最終的に問題が収まるまでを時系列で追って，どのような経過をたどったのかを確認し直します（図5）．最近は連絡を電子メールでやりとりすることが多いでしょうから，客観的な「証拠」を集めるのは容易なはずです．こうして得られた情報（図5）を見ると，次の2カ所について，不自然に時間がかかっていることが気になります．

図5　日付でトレースして切り分け
顧客からバグ報告がなされてから最終的に問題が収まるまでどういう経過をたどったのかを時系列で追ってみる．

1） 顧客からの第一報から社内のバグ登録までの期間
2） 社内レポート作成から最終報告までの期間

　図5を基にさらに調査を進めた結果，次のようなことが分かったとします．

・1）について：「顧客から第一報を受け取ったとき，顧客が重大バグと認識していたのを確認しそこねた．加えて社内での再現確認に手間取ったため，当初は顧客のシステムの問題ではないかと疑い，自社製品の問題であるという認識を持つのが遅れた」

・ 2）について：「修正第1版を作成したとき，顧客の窓口となっているサポート・チームが念のため動作を確認したところ，別のエラー・パターンで同種のエラーが検出されることが分かり，最終的な修正に時間がかかってしまった」

　ここまで来れば，対策はかなり具体的に立てられそうです．「顧客からみたバグ報告の優先度をなぜ間違ったのか」は，具体的にどのような連絡がなされたのかをたどれば，どこで誤解が生じたのかが見えてくると思います．「バグの修正がなぜ中途半端に終わってしまったのか」は，開発チームの切り分けの手法や，修正後の追加テストを見直す必要がありそうです．

　「なにやら当たり前の話だな」，と思われた読者もおられるかもしれません．しかし，実際の「反省会」では，客観的に証拠を集めることなく結論を探してしまうことがよくあります．そうなると，原因は他人にあると考えたがるのが人間の常ですから，サポート・チームは2）を，開発チームは1）を主原因と考えるでしょう．これがそのままぶつかれば，不愉快な派閥争いに発展しかねません．結論に飛びつく前にまず事実関係を整理して，客観的な証拠を積み上げるプロセスを踏んで，コンセンサス（共通見解）を得る必要があります．そうしないと，実行可能な対策を得るのは難しいのです．

　「ロジカル・シンキング」などと言うと，大げさに聞こえるかもしれませんが，このように，「客観的に切り分けを進めるためのちょっとした工夫」として活用できるものなのです．