SIerが仕切っている開発現場でありがちなのが、何かミスを犯すと、そのミスを防止するようにすごく手間がかかるチェックが追加されて、開発効率とモチベーションが下がるというダメなパターン。

たとえば、「今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました。 - SiroKuro Page」とか。

これはプロセスマネジメントでもなんでもない、管理ごっこだ。管理したつもりになって自己満足しているに過ぎない！！

プロセスをマネジメントしたければプロセスを削れ：DESIGN IT! w/LOVE

では、次のように述べられている。

プロセスマネジメントにありがちな間違いのひとつに、ミスを減らそうとして、そのチェックをするプロセスを増やしてしまうということがある。

もちろん、すべての場合にそれが間違いというわけではない。

そのチェックが機械によって自動的に行われるのであれば大丈夫だし、そもそものプロセスが単純なものであれば、ひとつ工程が増えても大きな問題にはならない。

ミスを減らそうとして、そのチェックをするプロセスを増やしてしまうことが問題になるのは、そのミスが実はすでに多すぎて複雑な工程からなるプロセスそのものが負担となり、業務の遂行を圧迫しているケースだ。

すでに多すぎて複雑すぎるところに新たにチェック工程など追加すれば、業務の圧迫度合いはより大きくなり、また違うところでミスが起きやすくなるのは目に見えている。

この主張に同意する。

息の長いプロジェクトだと、チェックとか認証手続きとかで本来の仕事の割合がかなり減って、仕事自体が罰ゲームみたいなことになってる場合が多々ある。

こういった仕事の効率を下げるようなルールは、ほとんどがささいなミス＝ヒューマンエラーが原因でつくられていて、ちょっと注意すれば防げそうに見えるんで、チェックリストとかで対策しがち。

だけど、チェックリストを作ったからといって、それで対策が完璧になることはない。チェックリストをチェックしているのは人間だからだ。たと えば、「チェックリストの1つの項目をチェックし忘れた。」とか、「面倒だったので、ざるチェックで通していた」とか、ありがち。そして、チェックリスト のチェックリストが作られたりするというアホな状況が発生するわけだ。

結局のところ、人間が作業しているが故に発生しているヒューマンエラーに対して、人間がチェックを入れるという対策をしても、問題の発生位置が変わるだけで根本的な対策にはなってないのだ。

ソフトウェア開発からムダを減らし、もっと効率良く価値を提供していくためには、このような後ろ向きな対策ではなく、チェックを機械化したり、ヒューマンエラーにすぐに気づく様にするなどといった、もっと前向きな対策をする必要がある。

チェックリストが機械的にチェック可能なモノなら機械化するなり、自働化するなりして人間が関わらないようにする。たとえば、コーディング規約を守らせたいなら、いちいち人間が調べてコーディング規約を守らせるのではなく、checkstyleなりコードフォーマッタを使うなりして、自動的にチェックするようにすれば手間もかからないし、見落としもなくなる。

コミットをミスってビルドが壊れたというのが問題なら、デイリービルドするなり、継続的インテグレーションをするなりして、ビルドが壊れたことをすぐに検知できるようにする。ビルドが壊れたことにすぐに気づけば、どのコミットが問題なのかを突き止めるのも簡単なはずだ。

逆に考えるんだ。「ミスをしないようにする」んじゃなくて「ミスをしても大丈夫なようにする」んだ。それがプロセスの改善だ。