不具合と向き合う

　不具合が生まれる場所は、基本的にひとつだ。開発者が何かを作ることで、はじめて不具合が生じるのである。開発者が何もしなければ不具合など生まれはしない。もちろん、開発者の手が止まれば製品はかたちをなさないのだから、まずは不具合と共存していくしかないのである。不具合とは、専門的な知識と技術による産物だ。あるいは、賜物と言ってもいいかもしれない。ひとつの不具合に対し、出自の異なる複数の人が協力しあい、修正に至るまでの過程で多くの学びを得るのだから。学びは、次の成功へと確実につながっている。

　不具合は、何もないところから自然発生はしない。製品を作る段階のどこかに、必ず原因が存在する。仕様設計に穴がある、単純なケアレスミス、実現したいことに対して技術力が足りない、疲労や多忙からくるヒューマンエラー、想定外の動きをしたなど、理由はさまざまだ。

　一方、品質管理に携わる者は、不具合を作り出せるだけの力は持っていない。開発者から受け取った仕様書という名の地図を広げ、踏破計画を立て、チーム全員の力を結集して未知の不具合を発見していくのだ。さながら探検隊である。行く道は本当に険しい。新人はもちろん、熟練者であっても、さまざまな困難を前に脱落する者が出てくる。行程 (工程) は一定のペースでは進まない。長時間の残業や休日出勤による肉体的負荷、無理な人員規模拡大によるコミュニケーションストレス、迫る納期、チームの外側からやってくる精神的な負荷。もっとも厳しい負荷は、発売された製品に不具合が残ってしまうことである。困難な道のりを歩き終えた直後だ、ほんの少しでも休息がほしい。しかし、歩き終えたすぐあとが、新たな苦難の始まりでもある。

『なぜこんな不具合が見つけられなかったのか』、心無い開発者はそう言う。『販売元への謝罪が必要になった。なぜ不具合を見つけられなかったのか、原因と今後の対策を、この日までに提出するように』、同じ社内の上役はそう言う。踏破計画をやり遂げたメンバーをねぎらう言葉はあるにはある。だが、課せられるミッションは、休息とはほど遠いものだ。ここで「なぜって？　不具合を作り出したのは誰なんです？」「安全なところにいれば、たらればでもなんでも、どうとでも言えますよ」と言い返してはならない。不具合を作り出した責を棚上げされようと、尽力の過程に目を向けず結果だけ見てものを言われようと、不具合を見つけられなかったのはゆるぎのない事実である。

　誰だっていい、願わくは苦難の道を乗り越えたメンバーたちに、こう声をかけたほしい。『大変な作業をよくやってくれた。不具合があるのは残念だ。だが、それは君たちが生み出したものではない。不具合があることを気にはしてほしい。しかし、気に病みすぎないでもほしい。叱責も謝罪も、わたしたちがさらなる高みへたどり着くための通過点にすぎない。次は、今回よりもいい結果を残そう』と。そんなあたたかい心が、道のりを歩き抜いた者たちにとって救いになるのだ。