品質の改善とは「プロセスの改善」である

誰でも作業ミスはします。それ自体は悪いことではありませんが、悪いのはそれを改善できないことです。

■ 品質の改善とは

例えば、プログラムを書く時に以下の「やり方」でプログラミングをしていたとします。

設計書を読む
ソースを書く

その結果、たびたび実装漏れが起こったとします。そこで以下の「やり方」に変えたとします。

設計書を読む
ソースを書く
再度設計書を読む

それでも、たびたび実装漏れが起こったとします。そこで以下の「やり方」に変えたとします。

設計書を読む
ソースを書く
設計書にチェックする

実装漏れは無くなりましたが、実装ミスが起こったとします。そこで以下の「やり方」に変えたとします。

設計書を読む
ソースを書く
設計書にチェックする
第三者にレビューをしてもらう

このように、「やり方」を改善していくことで品質は良くなっていきます

■ プロセスを確立する

作業品質を全然改善できない人がいます。私の経験上、その原因は「プロセス」を確立できていない人です。

ソースを書いてから設計書を読んだりすることもある
設計書にチェックをするときもあればしないときもある
レビューしてもらうこともあればしてもらわないこともある
やり方はその時の思いつき、気分、環境で変わる

こういう人の作る成果物にはムラがあります。良く出来ているものと、全然ダメなものが混在するのです。こうなると、水平展開で見直しをしようとした時に、全ての成果物を一から見直ししなければなりません。

そして、自分自身でも、自分の成果物の何に自信を持てて、何に自信を持てないのかがわからない、という状態に陥ります。

こういう人もいます。

実装漏れがあったプログラマーに「設計書にチェックいれましたか？」と問うと「いれました」と言い、「でも設計書に明記されているのになんで実装が漏れたんですか？」と再度問うと、「もしかしたらいれてないかも」と言う。

発言が変わる人は自分の「プロセス」を確立していないからです。

■ プロセスが確立されているから改善できる

上記のように「プロセス」が統一されていないと、どの成果物をどこまで信じていいのかわからなくなります。そのため、問題が起きた時の原因究明や対策、改善が難しくなります。

従いまして、「やり方」つまり「プロセス」を明確にし、それをルールとして絶対に守るようにしましょう。品質の改善は「プロセスの改善」です。