PKTと引き算 - 室長のひとりごち

エンジニア界隈に限らないが、ミスったり、ルールどおりにやっていないと指摘されて是正を求められる時代だ。

エンジニア界隈であれば、トラブったら即、『再発防止策をせよ』と言われる前から様式美のように『こちらが再発防止策でございます』と右から左に持ってくる。

様式美なので内容は問われない。『左様か、では次は気をつけ給え』以上である。

この風潮の気に入らないのは、ミスった原因の作業プロセスの手直しをせず、ミスった当事者に責をなすりつけ、効果性のないチェックリストを追加したり、ダブルチェックと言うものをやると言う。

わかっている人には、チェックリストを持ってきたってなんら効果のないことはわかっている。ただ、立場的に様式美にしたがって進める方が労力は少なく、波風も立たない。こうしてゴミが増えていく。

KPTはご存知のとおり、ふりかえりの手法でふりかえりは何もKPTばかりではないが、残念ながら、KPTをやっておけばいいと言う風潮がもしかしたら、再発防止策と同じようにあるのかもしれない。まぁ何か1つを推すのは日本人特有なのかもしれない。

KはKeepで続けること。PはProblemで問題で止めることである。Kは出やすいが、Pは出にくい。どちらかと言えば、TのTryの方がPより出やすい。

なぜか。

Pは今やっていることから減らさなければならない。これはとても労力のいることなのである。

考えてもみたまえ（ムスカ風に）。

Tryで足すのは、何でもかんでも改善に見えるのだ。それが全く意味のないチェックリストだとしても。

一方、Problemで何かを辞めようとなったとき、今までやってきたことを止めるのだから、何かしらの策で今までやってきたことに変わる代替策で同じ効果を得たいと思ってしまうのである。

何も効果がなかった、返ってマイナスだった作業だとしても、習慣担っているとやめられないのが日本人なのだ。

そして、なぜか止めようと提案する人にそれをやめても現状を維持するように意味のないオーダーをするのである。いやいや、今までそれをやっていても何も価値を生んでいないのだから、止めるに際しても何も考慮はいらないはずだとしても。

このことから、作業プロセスは価値を生むだけのアクティビティをデザインしなければならないことを学ばなければならないが、それ以前にそういった知識を持っていないので思いも、考えもしないのである。

KPTでTryばかり増やしてはいけないのである。Problemで同じくらい、いや、それ以上、ルールを減らさないといけないのである。