Melting Pot of Thoughts

SaaSスタートアップのCTOです。思考の整理のため考えたことをメモとしてアウトプットしていくブログです。

暗黙知ははたして悪なのか?

”暗黙知”という言葉はたいていネガティブな文脈で使われます。

”暗黙知”でGoogle検索すると、対義語の”形式知”について触れつつ「どうすれば暗黙知を形式知に転換できるか」についてのノウハウが書かれた記事がたくさん出てきます。

 

暗黙知(個人が持つ知識・ノウハウ)を形式知(文書・マニュアルなどに落とし込んだ他者が共有できる形のもの)に変えるメリットとしては、属人化の防止やスキルの伝達などがよく言われます。

しかし逆に暗黙知のほうが優れている点については語られているのは見たことがありません。

 

今回は『暗黙知を形式知化するのが常に正解というわけではない』というテーマについて書きます。

 

============

※ 形式知の代表例として、社内共有された社内制度・業務ルール等のドキュメントを想定して書きます

 

形式知化するとコストがかかり続けます。

初めにドキュメント化するコストはもちろんですが、その後ドキュメントを現実に合わせてずっとメンテナンスし続ける必要があります。

このメンテナンスが中途半端だと、内容が誤った”ゾンビドキュメント”が増えていきます。

誤った知識が伝わってしまう上、正しいドキュメントですら信用できない状態になってしまうため、「コストをかけているのに恩恵が得られない」むしろ害が大きい状態になってしまいます。

 

 

また形式知は読む方にもコストがかかります。

近年は透明性という意味で社内のあらゆる情報をドキュメント化する企業が増えましたが、読む方としては膨大なドキュメントに圧倒されていざ何から読んでいいかわからないのも事実です。

透明性という意味で『あらゆる情報にアクセスしたければアクセスできる』ことはとても重要なことですが、一方で『本当に知っておくべき情報が埋もれてしまったり、重要な情報を斜め読みしてしまう』問題も起きます。

 

 

一方悪く言われがちな”暗黙知”ですが、メリットもあります。

業務を属人的に行うことによる業務スピードの上昇度合いは凄まじいものがあります。

形式知化して複数名で作業するより、一人が属人的に仕事を進めたほうがスピードも質も圧倒的に高いケースはプログラミングにおいては非常によくある話です。

情報共有や議論などのあらゆる間接業務を排除し、属人的に行うことで10x(10倍)のパフォーマンスを出すことができるという話は以前ブログにも書きました。

blog.doyaaaaaken.com

 

============

 

ここまで一方的に暗黙知の良さについて書いてきましたが、もちろん形式知化することは大事です。

ただし常にそれが正解ではないということがあまり語られることはないので、今回テーマとして取り上げました。

 

形式知化に頼りすぎるとむしろ害になりえるようなものの例としては以下のようなものがあります。

  • 0から何かを始める場合のように、立ち上げスピードや柔軟な方向転換が求められるもの。
  • 変化しやすいもの。
  • コンテキスト含めきっちりと理解してほしいもの。人により理解度に差が出ると困るもの。

 

そういった場合、暗黙知を形式知化するのではなく、暗黙知を暗黙知のまま伝達するという方法もあります。

例えばソフトウェアエンジニアだとペアプログラミングと呼ばれる、ペアで作業する方法があります。

設計パターンやコーディングルールについて変に形式知化(ドキュメント化)しても、読まれずメンテナンスもされないドキュメントが量産されてしまいがちなので、むしろ暗黙知のまま継承する仕組みがあるほうがいい場合もあります。

他の例としては、業務に必要な業界知識の伝達があります。ドキュメント化しても人により理解度に差が出るので、ドキュメントと合わせて丁寧な口頭説明を行うなどもしたほうがいい場合もあるでしょう。

 

============

 

以上、「暗黙知ははたして悪なのか?」についての話でした。

暗黙知が悪いケースはありつつも常に悪とはいえず、『暗黙知はなくすものではなく、組織としてうまくマネジメントするもの』ではないかという話でした。