ノウハウの4レイヤー
スキル(ノウハウ)には最低でも4つのレイヤーがあると思う。 １：バッドノウハウ。２：バッドノウハウを作るスキル。 ３：バッドノウハウを取り除くスキル。４：バッドノウハウを作らせないスキル。
１の「バッドノウハウ」は例えば「～という問題に対処するにはソースの一行目にhoge=1と書くとよい」 という知識。この知識を持っていることで、その問題を解決することができる。 しかし、その問題しか解決できない。
２の「バッドノウハウを作るスキル」は、なぜその問題が起こるのかを調べて、 本来1になっているべきhogeの値が0になっていることを発見してそれを書き換えるなどができるスキル。 このスキルがあれば、まだ誰も解決していない問題に直面した場合にも 自力で解決することができる。 また作り出したバッドノウハウを公開することで、 「同じ問題に直面し、かつそのバッドノウハウにたどりつくことのできたひと」 の問題も解決することができる。
３の「バッドノウハウを取り除くスキル」は、 なぜ本来1になるべきhogeの値が0になっているのかを調べ、そこを修正するスキル。 「ソースの一行目にhoge=1と書く」というバッドノウハウ自体が必要なくなる。 このスキルのある人が活動すると 「同じ問題に直面したorする可能性のあった全ての人」の問題を解決することができる。
４の「バッドノウハウを作らせないスキル」は少し逆説的。 なぜバッドノウハウを作られてしまったか、３ではなく２になってしまったか。 それは「なぜ本来1になるべきhogeの値が0になっているのか」が調べにくい、 またはなぜかわかっても修正しにくいからだ。 これを容易にするスキル。 誰でも理解できる整理されたシステム、柔軟に修正や拡張ができるシステム、 そういうものを作るスキル。 このスキルのある人が活動すれば、 将来発見されうる問題も含めて「バッドノウハウを作らない対策」が容易になる。
目指すべきところは４なのだけども、なかなかそこに到達するのは難しい。 高林さんが主張されたこと(バッドノウハウと「奥が深い症候群」)は 「１や２のレイヤーでバッドノウハウを集めて喜んでいてはいけない。 バッドノウハウがたくさんあるのはシステムがよい設計ではない証拠だ」 だろうし、結城さんの主張されたこと(バッドノウハウからグッドラッパーへ)は 「『システムの設計が悪い』と言うだけでは生産的ではない。 レイヤー３の活動で対処しよう」 ということだろう。
バッドノウハウの多くできるようなソフトウェアは２と３の間の段差が大きいから、 そのソフトの手のひらの上で活動していると３というレイヤーがあることに 気づけないのかも知れないなぁ。
