間違った「対処」をさせるのが管理者の仕事なのか

自分の思っていたことにピンときた。

これは、問題の「対策」じゃない。

問題をひっくりかえしたて「対処」しただけだ。

* 進捗を把握できていなかった→進捗を把握するようにする(進捗管理を強化する)
* 不正なサイトを閲覧した→不正なサイトを閲覧できないようにする
* デプロイに失敗した→失敗しないようにチェックする

これは、イタチごっこを産むだけだ。

マネージャでもエンジニアでも、問題の解決に対して、問題をひっくりかえすだけの対処はしちゃいけない。無意味だから。

そもそも問題が発生しえない土壌を作ることをまず考えないといけない。

「失敗」への対策は「管理」じゃない - Fight the Future

僕が、今の現場で見てきた「対策」というのは、

• チェック作業の追加など、現在の作業量に単純に上乗せされる
• よく読むと「ミスをしないように頑張る」という決意表明をしているだけ

ということ。要は、「やり方を変える」っていうことがほとんどなかった。仕組み上問題が発生しないようにする、発生しても問題が出ないようにする、同じ工数でそれ以上のことができるようにするっていうことがないと、上記エントリで「対処」した分のしわ寄せが別の問題となってそのうち顔を出すはずで、そういうことを考えられていないんだよね（直接の因果関係が見えないから）。学習しない人達のチームに特徴的なことは、ない知恵を絞っておかしな解決策を見出しちゃうってこと。今の現場だと、共有フォルダの複雑な運用ルールがあったりして、「それSubversionで(ry」だったりするし。PMBOKやITILの枠組みが自然に解決してくれるはずなんだけど、現実はどうもそうじゃない。現場の当事者にしか問題は解決できないけど、解決方法を知っているとは限らない。むしろ知らないことの方が多い。それを解決するには、常に書籍やWebでで学んでいたりするような人がチームにいて、その人の意見が取り入れられるじゃないかなと思ったりする。現場に合わない理想に走っちゃったりするかも知れないけど、それこそリスクを「管理」するということじゃないのかな。でも、学ばない人というのは往々にして、教わろうとしない人だったり、正しく行動しない人だったりするから厄介。やり方を変える際のリスクを明らかにして不安を取り除くとか、学習することで成果があったことを見せるとか、単に命令するだけが管理者の仕事じゃないよね。