みなさん、バッドノウハウという言葉は聞いたことがあるだろうか。

現在は、いやなブログさんによる、バッドノウハウの本来の定義からやや拡張されて、
uglyなソフトに人間のほうが間尺を合わせるダメな行為を指す意味で使われることが多いように思う。


しかし、これはほとんどエンジニアリング世界（だけ）で通じる言葉でマネージメントの世界でこういう言い方はまずしない。

たとえば、一部で悪名高い、「動いているコードは触るな」メソッドを考えよう。
これはエンジニアから見たら極めて悪辣かつバッドな行為だ。コードを理解せずに対処療法的に問題が出た部分だけを修正してしまうわけだから。
こういうのが積み重なると、こっちを直せばあっちが飛び出し、あっちを直せばこっちが火を噴く。というシステムが簡単に出来上がる。

で、これが何年も前から言われているのに全然なくならない。無くならないどころか減っていく気配すら見えないのは、マネージャーにとって、これは全然「バッド」なノウハウじゃないからだと思う。
マネージャーの仕事ってのは極論すれば「出来るエンジニアがいてもいなくても結果を出す。出せるように手配をする」のが仕事である。たまたま部下にいいエンジニアがいる時にだけ成功するプロジェクト運営方針ってのは明らかに間違ってる。

とするとエンジニアに「ちゃんと理解して修正しろ」と指示するのは間違っているわけだ。ダメエンジニアは理解したつもりで余計トンデモないコードを仕込んでデグレード障害を起こすから。

マネージメントの世界ではこういう教科書的にはちょっとアレゲでも経験的にうまくいく手法をとても大切にする。マネージメントの教科書には書いてないけれども経験的にうまくいく手法を、ベストプラクティスとして蓄積していくわけだ。


でも、これってこの２人の間には深い断絶があるのよね。だってマネージャーはエンジニアに
「お前がバグを入れるかもしれないから理解しろとは言えないし、分かっているから直させろといわれても信じられないんだ。」
とは言えないじゃない。

実はこういう話は一杯あって、エンジニアあがりの新米マネジャーが苦労する一因になっていると考えている。




結論としては、経験則重要、現実を見よう。って事が言いたかったんだけど、この話の流れだとちっともそういう風に見えないな。
反省


・・・・しかし、こういう話をレガシーエンコーディングの話で盛り上がった直後に思いついてしまうのはそれはそれでどうなんだ。