品質の分析 -3-（作りこみ工程）

３日かけて、「質」のあり方について説明してきました。これが最後となりますが、改めておさらいしておくと、『技術的原因』によって具体的に何が問題だったのか？つまりは「What」を確認しました。

これを明確にすると、修正するべきポイントが特定できるようになります。「技術」「知識」「スキル」といったハード面に特化した問題特定です。「判定の仕方に不備があるなら、判定の仕方を修正すればいい」「冗長的なコーディングに原因があるなら、冗長化しないコーディングをすればいい」ということになります。

「なにを、そんな当たり前のことを」と思うかもしれませんが、これが結構特定できていないケースが多いのです。あるいは特定してみたら「恥ずかしい内容だった」と言ったために何とかごまかそうとする人が出てくるため、本質的な改善ができないと言った事例もままあるのです。

技術的原因は、「それさえ修正すれば、不良や欠陥そのものは解決する」と断言できるものでなくてはなりません。変に誤魔化そうとすると、必ずつじつまの合わない理由になっていきます。

こう言った内容は、何もソフトウェア開発に限った話ではありません。問題が起きてしまったことは仕方のないことですが、問題をしっかり解決するためには「それさえ直れば」と言えるポイントを特定しなければならないのは、どこでも誰でもまったく同じことでしょう。

たとえば、「売上があがらない」という問題に直面した時、その技術的原因が『売れる商品が無いから』という理由だったとしたら、

　「じゃあ、単価上げよう」

という解決では意味がありません。どんなに単価を上げても売れる個数がゼロなら、何を掛けてもゼロにしかなりません。このように、原因特定がままならないと、解決策は必ずおかしな方向へ進んでいってしまうのです。

そして、次に『動機的原因』です。

『動機的原因』によって、なぜそういう問題を引き起こしてしまったのか？つまり、「Why」を確認しました。

これを明確にすると、根本的に解決するべきポイントが特定できるようになります。「思考」「判断/決断」といったソフト面に特化した問題特定となります。「判断を誤るのであれば、誤らないアルゴリズムを策定すればいい」「思考が属人的で思い込み不良を起こすなら、思い込みが介入する余地のない仕組みを定義すればいい」ということになります。

動機的原因は、過ぎ去った「（「問題を起こした」という）結果」に対しては作用しません。ですので、是正（不良の修正）にはほとんど効果はありません。しかし、改善（再発防止）には非常に効果があります。問題を起こした当人だけでなく、チームメンバー全員にも波及するからです。

同じ不良はできるだけ発生件数が少ない方が良いに決まっています。一度発生させてしまい、解決策から再発防止策まで検討されていれば、その後起きたであろう不良を未然に防ぐことになり、その分よけいな手戻りを発生させなくて済むのですから、きちんと整理して仕組みに活かせる人は、陰の功労者とも言えます。

作りこみ工程

ここまでの分析によって、「是正」と「予防」が対策できるようになります。対策内容を正しく吟味すれば、二度と問題は再発しない可能性も出てきます。

では、これで万事解決となるでしょうか？

いいえ、なりません。

さらに、この不良が、どの工程で作りこまれたのかも重要になってきます。なぜなら、不良が検知された時点で、既にほかにも同じ不良があちこちに作りこまれてしまっている可能性があるからです。

ここでは、その不良が「作りこまれたタイミング」と不良を「発見したタイミング」が適切であるかどうかを確認します。