前回の「人間は言葉で表せる以上のことを知っている」の中で、形式知や定型／非定型業務について書きました。
今回は、暗黙知について考えてみたいと思います。
前回にも書いたように、暗黙知とは「経験的に使っている知識だが簡単に言葉で説明できないもの（知識）」とされています。例えば、個人の技術やノウハウ、ものの見方や洞察など主観的で言語化しようとしても肝心な部分が伝わりきらない知識のことです。
業務で言えば、非定型業務にて発揮される知識と言えます。例えば、「クリエイティブクラス」と言われるソフトウェアエンジニア、芸術家、コンサルタント、金融や企画などの非定型業務や「サービスクラス」と言われる理髪業や配管工、レストランのサービス、清掃などの非定型業務においてです。
ただこうした非定型業務における暗黙知も、細かく因数分解していけば、形式知に限りなく近い形で整理することはできるかと思います。（活用できるかどうかは人的部分に依存すると思いますが。）
暗黙知＝「経験」によるDB（データベース）と考えると、暗黙知は以下の数式として表せるではないかと思います。
暗黙知（経験によるDB）＝f（x,y,z）
f： x,y,zの関数（関係性）
x= 「現象や原因」のDB
y= 「打ち手・解決策」のDB
z= 「結果」のDB
暗黙知（≒経験値）とは、まず事象の発生にどれだけ遭遇しているか（現象や原因）、そしてそれに対して自分事としてどれだけ対応したか（打ち手、解決策）、そしてその結果がどうだったかをどれだけ見届けたか（結果）の質と量かと思います。
同一レイヤー（階層）の質の事象や問題に関しては、10、50、100と経験していけば、その内にある特定の現象・問題（Inputデータ）が起きた時は、「この打ち手をしておけば、こうした結果になるはずだ」と最適な方法を選択できるようになります。
この関数f（x,y,z）が暗黙知と言えます。
暗黙知をある程度形式知化するとすれば、このxとyとzを人間の脳から切り離した形でDB化を行い、最適化計算をさせるか（そうなると次に目的関数の設定が必要となりますが）、f（x,y,z）そのもののノウハウを分かりやすい定式モデルとして抽象化させるかのどちらかかと思います。
また、このf（x,y,z）はアナロジーとも言えるかもしれません。（アナロジーとは、特定の事物に基づく情報を、他の特定の事物へ、それらの間の何らかの類似に基づいて適用する認知過程のことです。）
アナロジーという意味では、子供の頃によく観た「日本昔ばなし」を思い出します。「日本昔ばなし」はほのぼのとする話もありましたが、かなり怖い内容や救いのない話なども数多く出てきます。
しかしどの話も「ある現象が起きる→それに対してある対応をする→結果こうなった」の流れが集約されています。その一連の流れを普遍的な教訓として昇華すれば、暗黙知そのものとなります。
例えば、「紺屋とゼニガメ」というお話があります。
昔あるところに、川を挟んで東と西に二軒の紺屋があった。二人の紺屋はいつもその川で、染めた布を水洗いしていた。ある日、白い髭を生やしたお爺さんが二軒の紺屋にやって来て、「お金はいくらでも出すから、この布を紺色に染めて下され。」と言い、白布を一反ずつ置いていった。東の紺屋は「しめしめ、金は望みのままだ。」と言って喜び、西の紺屋は「よほど大事な布だろうから、丁寧に染めねば。」と考えた。ところがこの白布は、いくら一生懸命染めようとしても川で水洗いするとたちまち元の白布に戻ってしまい、どちらの紺屋もどうしても染めることが出来なかった。二人はすっかり困ってしまった。やがて約束の日になって白髭のお爺さんがやって来た。東の紺屋は約束通り出来たと言って、水洗いせずに乾かした布を差し出した。お爺さんは、何も言わずに大金の入った箱を置いて帰っていった。西の紺屋は染められなかったことを謝ると、白布と一緒にもう一反の別の紺色の布を差し出した。お爺さんは、やっぱり何も言わずに大金を置いていった。その夜、東の紺屋が変な物音に目を覚ますと、箱の中の大金に手足が生えてみんな小さなゼニガメになっていた。ゾロゾロ箱から逃げ出したゼニガメを東の紺屋が追いかけていくと、川の中からあの白髭のお爺さんがゼニガメ達に手招きしていた。お爺さんはその川の水神さまだったのだ。それ以来川の東側はゼニガメのために水が濁り、良い染め物が出来なくなってしまったが、西の紺屋は水神さまからもらった金で益々大きな紺屋になって繁盛したという。（引用：狢工房サイト）
この話をf（x,y,z）としてどう捉えるかは、それぞれで良いと思います。東の紺屋がダメで、西の紺屋がいいとは限りませんし、結果をどう捉えるかは各人次第です。（ビジネス的にはちゃんと代案を出す西の紺屋は誠実なように思いますが、仕事を受ける前に確認しないのもどうなのだろうとも思いますし。。）
ただ、それよりも重要なことが、2つの異なる対応に対して異なる結果が生じたという関数です。
こうした関数である暗黙知を生かして、働く人数が少なくなっても、誰でも適切なソリューションを出せるようにするには、変数であるx,y,zを如何に外部記憶のDBとして意味のある形で残していけるようにするか、またそこから派生する関数である暗黙知をどれだけ創造できる（組み合わせられる）ように工夫できるかにかかっていると思います。
この辺りの領域の検討をFRINGEとしても今後具体的な事象ベースに考えていきたいです。
