ドキュメントに書けないことのほうが多い
長年エンジニアとして現場にいて、痛感していることがある。本当に大事なノウハウは、ドキュメントに残らないんですよね。
コードの書き方やシステム構成は記録できる。でも「この人にはこう説明すると通りやすい」とか「この工程で手を抜くと三ヶ月後に必ず揉める」みたいな話は、どこにも書かれない。書きようがないんですよ。
自分がまだ現場をバリバリ回していた頃、後輩に引き継ぎ資料を渡したことがある。百ページ近く書いた。それでも引き継いだ本人から三日後に電話が来て、「ここ、どういう意味ですか」と聞かれた。そういうものなんだよね。
暗黙知は「伝えよう」とすると壊れる
暗黙知という言葉は便利だけど、厄介な性質がある。言語化した瞬間に、それはもう暗黙知ではなくなるんですよ。しかも言語化したものが元の感覚と一致している保証もない。
料理でいえば、「塩は少々」と書いてあっても、その「少々」は作る人の手の大きさや食材の状態で変わる。自分は毎朝出汁を引くけれど、分量なんていちいち量らない。身体が覚えているんですよね。でもそれを誰かに教えようとすると、急にぎこちなくなる。
組織でも同じことが起きる。ベテランの判断基準をマニュアル化しようとして、結局「経験者に聞いてください」と書いてしまう。あ、確かにそれじゃ意味がない。でも実際そうなんですよ。
それでも「隣にいる時間」は無駄じゃない
じゃあどうするか。自分が見てきた限り、一番効いたのは「一緒に作業する時間」だった。言葉ではなく、横にいて同じものを見る。先輩がどこで手を止め、何を確認し、どの順番で進めるか。それを隣で観察する。
効率は悪い。マニュアルを読ませたほうが早い場面もある。でも人間は、マニュアルを読まない生き物なんですよね。面倒だから。怠惰だから。それを嘆いても仕方ない。人間がそうである前提で、仕組みを考えるほうがずっと誠実だと思っている。
記録できないなら、場を残す
最近は技術顧問として若い世代と接する機会がある。彼らはドキュメントもチャットログも丁寧に残す。それは素晴らしいことなんですよ。ただ、記録の外にある空気みたいなものを、どう次の世代に渡すか。ここだけは、まだ誰も答えを出せていない気がする。
自分なりの結論は、「記録できないものは、場で渡す」ということ。カフェで隣の席の会話が自然と耳に入るように、組織の中にも余白の時間が要るんじゃないかと思う。
まあ、矛盾ごと抱えていくしかない
暗黙知を伝えたいのに、伝えようとすると壊れる。この矛盾は解消しない。でも、それでも伝えようとする営みそのものに意味があるんだと、六十年かけてようやく思えるようになった。不器用でも、隣にいること。それだけで十分な場面もある。
—
ところで、技術の暗黙知といえば、古い技術書にもそういう空気が残っていることがある。【中古】(未使用品)DirectX9実践プログラミング 書籍版 (I／O BOOKS)（参考価格￥14,499）なんかは、当時の開発者がどこで悩んでいたかが行間から伝わる一冊。今の技術とは直接つながらなくても、考え方の土台みたいなものが残っている。
逆に、これからプログラミングに触れる子どもたちには、スタディーノではじめる うきうきロボットプログラミング（参考価格￥2,999）のように、まず手を動かして感覚を掴む入口があるのはいいことだと思う。暗黙知は結局、手を動かした人の中にしか宿らないので。
→ プロフィール / 他チャネルを見る
コメント