KAIZEN

気づいたら随分Blog書いてなかった。来月から本気出す。

去年の頭からアジャイルジャイル言い出して色々と開発現場の改善に取り組んで、改善にもコツがあるなーと気づいた。

KAIZENってなんだ?

KAIZEN。改善。悪いところを改めること。数多くの進歩を継続的に行うこと。

改善を行っていくためには、簡単言えば、思考停止、ダメ。ゼッタイ。なんとなく作業している限り改善は行えない。

KAIZENするとどうなるか?

何か問題があったり、もっと良い方法を見つけたとき、仕事のやり方を変えていく。プロセスを追加・変更したり、ツールを導入したりする。仕事のルールが変わったり増えたりする。そうすることでもっと早く、あるいは安く、あるいは良いモノが作れるようになる。

でもそれは思考停止を誘発する。なぜならプロセスやツールというのは今まで考えないと出来なかったことを考えなくてもできるようにするためのものだからだ。考えること自体はコストだし、僕らエンジニアはもっと本質的で価値に繋がる部分で頭を使わなきゃいけない。考えなくてもできるようにする、別にそれ自体は問題ない。考えなきゃいけない部分まで思考停止しないのであれば、だけど。

どうしたら思考停止を防げるか?

改善をした結果、導入されたプロセスやツールが、余計なところで思考停止を招く様を何度か目にした。もちろん、誰でもそうなるっていうわけじゃあない。でも、僕の観測範囲だと思考停止しない人の方がマイノリティな気がする。そもそも、ありとあらゆる状況で思考停止しないっていうのはある種の才能ではなかろうか。

思考停止、ダメ。ゼッタイ。って言うけど、出来る奴が出来ない奴に出来るハズって言うのは根性論だ。それは何か違う。もちろん、病めるときも健やかなるときも、思考停止しないのならそれが一番いい。でもそれは無理。諦めよう。

プロセスやツールが余計なところで思考停止を招くことはもうしょうがない。そういうものだ。そう認識しておけば対策が打てる。

KAIZENのコツ

どんなプロセス・ツールにも余計なところで思考停止を招く可能性があると仮定して、思考を再開するポイントを事前に設定しておくのが肝なんじゃなかろうか。

そういう意味でも、スクラムはよく出来てる。スプリント計画を立てたらスプリント中は次のスプリントでやることを考えなくて済むし、何か問題が起きても次のスプリント計画で修正できるし、スプリント中に生まれた課題は振り返りであぶり出せる。

僕は今まで振り返りで出てきた何かに対して、漠然と改善策を打ってきたように思う。それで何か新しい課題が出てきても次の振り返りで考えればいいや、と。でも、改善策によっては思考を再開するべきポイントが毎日のように訪れたりして、そういうものにスプリント単位で行う振り返りは無力だ。

じゃあどうするか?別のフィードバックループに組み込めばいい。

結局のところ、思考を再開するべきポイントというのはフィードバックを受け取ったときに発生する。だから、そのフィードバックがいつ受け取れるのかを事前に確認しておく。出来ればスクラムイベントなんかに組み込めると最高だろうけど、その方法は今考えてるところ。