暗黙知の共有方法の検討
こんばんは、joniyです。
今回は「暗黙知の共有方法の検討」と題して書きます。
記事の概要
ちょっと長めの記事になりますので最初に全体の概要を記載します。
書こうと思った経緯
- この題材を選んだ理由
そもそも暗黙知とは
- 暗黙知とは何か
- 暗黙知が暗黙知足り得る理由
- 暗黙知と形式知
一般的に実践されていること
- 一般的に暗黙知に対して実践されている(と思われる)こと
注意事項
- この記事で取り上げている内容
- 暗黙知を共有することのコスト
社内で実践できそうなこと
- ライブコーディング
- ペアプログラミング
- 社内ハッカソン
終わりに
- 記事のまとめ
参考文献
書こうと思った経緯
社内では毎月1回集会を開いています。(Aqutras GW Campを実施しました!) そのときにそれぞれが前月に担当していた各プロジェクトに分かれてKPT分析を用いて振り返り作業を行います。 これまで毎回Problemとして暗黙知の話が出ていました。
naosuke さん「前回もProblemに暗黙知が出ていましたよね」
iguto さん 「暗黙知っていうのは無くならないもので、そもそも暗黙知が暗黙知足り得るのは...」
(曖昧な記憶に基づいて再現しています)
このような流れで話が終わってしまい、Problemとして出てはいるものの具体的なTryについてはほとんど検討されないままになっていました。
そもそも、社内で暗黙知が問題とされているのはメンバーの技術力の差が少なくないことが原因です。
ある人では1時間くらいで実装できるのに、他の人では似たものを実装するのに5時間以上かかってしまうということもあります。
その二人の間にある違いが単純に技術に関する知識量はもちろんですが、暗黙知をどれだけ持っているかだろうということで問題とされています。
そこで今回、せっかく暗黙知が問題になっているという認識はメンバーで共有できているので、
どのように暗黙知を共有すれば問題認識が無くなるのかについて書いてみようと思いました。
おそらく、企業やサークルで暗黙知を新入社員などに伝えようと苦心されている方は少なくないのではないでしょうか。 今回記事で取り上げている方法を実践してみた方は、結果や意見をコメントいただけましたら幸いです。
そもそも暗黙知とは
暗黙知という言葉が初めて出てきたのは1980年に出版された「暗黙知の次元」という書籍です。マイケル・ポランニーという科学哲学者の方が執筆されています。
暗黙知とは、人間が暗黙のうちに知識として持っている、言語（文字）にできない（またはすることが難しい）ものを意味します。 ※暗黙知と形式知より
例えば、野球においてまったくの素人に「フライってどうやって取ればいいの？」と聞かれても、言葉だけで的確に教えることは難しいでしょう。 実際に取る様を見せたり、何度もフライを投げて取らせたりすることでようやく教えることができると思います。 つまり暗黙知とは、経験によって自分の中に存在する勘やコツ、センスといったものが該当するのです。
何度も何度もノックを受けてようやくスタメン入りして守備に付けたり、職人のもとに弟子入りして技を盗み見てだんだんとプロの職人になるように 暗黙知を自分のものにして一人前になるためには時間がかかります。
どうして暗黙知を身に付けるにはこのように時間がかかってしまうんでしょうか？
それは、相手に暗黙知を言葉や身振りで教えてもらったとしても自分の暗黙知にならないからです。 教えてもらった知識はまず形式知となります。
※ プロジェクト管理における暗黙知と形式知（その２）より引用
形式知とは、上の図のように自らが持っている知識の氷山の一角のようなものです。
Webや本で見ただけのことが形式知で、知ってはいるけれど実践したことが無い、ルールは知っているけど実際にプレイしたことはないといった状態です。
要は、身に付いていない知識が形式知です。
経験で得られたコツや勘を相手に伝えても、それは上辺だけしか理解できません。
実際にやってみて実感を伴わなければ暗黙知に変換できません。
ということでざっくりまとめると、暗黙知を教えるには暗黙知を形式知として相手に理解してもらうフェーズと、形式知をもとに実践して暗黙知に変換するフェーズが必要ということになります。
一般的に実践されていること
一般的には暗黙知を共有するためにどのようなことをしているのでしょうか。 新人が入ると1～2か月かけて新人研修を行い集中的に教え込んでいるところ、 失敗することを考慮してプロジェクトに組み込んでタスクを割り振り、失敗を経験させることで 暗黙知を獲得させるところ、うちの仕事には暗黙知ばかりだから!と諦めて教えようとしないところ などなどそれぞれの方法で実践していると思います。
以降の項では、数ある方法の中でもITエンジニアが短期間で実践でき、効果がありそうなものを紹介します。
注意事項
1. 効果の確認が取れていることを書いているわけではない
この記事に書いてある方法は全てが実際に実践してみたものではありません。
Aqutrasとして実践してみたいこと、実践できれば効果がありそうだと考えたものを記載しています。
2. 暗黙知を伝えることはとても疲れる!
暗黙知については上の項で触れているように、そもそも言語化しづらい知識であるから暗黙知なのです。 つまり、誰かにわかるように伝えることはとても骨の折れる作業になります。 今回、私は暗黙知を学ぶ側として書いていますが、暗黙知を教える側に強制するのはあまり良いことではありません。 長期的に見れば、全体の技量が上がり生産性が上がると思います。 しかし、教える側は現在の生産性を維持している人です。暗黙知を教えるための準備に時間を割くということは、業務にかける時間を割くということになります。 そのため、あくまで相手に余裕があればお願いするくらいの気持ちでやるのがベストでしょう。
社内で実施できそうなこと
1. ライブコーディング
何かしらのお題を決めて教える側がコーディングしている様子を学ぶ側に見せます。 敢えて言うならば、弟子に職人の作業風景を見せることに該当するのではないでしょうか。
暗黙知を暗黙知のままに実践して見せることで、作業の流れを疑似的に学ぶ側に体感させることができます。 職人を例に出しがちですが、ITにおいて暗黙知とは全てが経験によってしか掴み取れないものではありません。 明確な理論や知識によって決まる手順をいかに早く判断できるか、その判断材料が暗黙知と言えるのではないでしょうか。
つまり、学ぶ側はただぼーっとライブコーディングを眺めているだけではダメなのです。 教える側がささっと実装を進めていき、自分が理解できなかったらすぐに「どうしてそこはそのようにしたのか」を質問するべきです。 (私もあまり実践できていないので強く言えないですが...)
ただコーディングを見せるだけでは、暗黙知は全く学ぶ側に伝わりません。手品を見ているようなものです。 理解できないことを質問し、手品のタネを教えてもらい形式知として記憶する必要があります。
これによって暗黙知を形式知として学ぶ側に伝えることができ、さらにどのように実践すればいいのかも教えることができるので、 暗黙知に変換しやすいという一石二鳥な効果が期待できます。
ちなみにAqutrasでも前回の集会で、iruca3さんによるライブコーディングのセッションを行いました。 とあるバグフィックスととある機能の実装の2つをやっていただいたのですが、私からすると恐ろしいスピードでの実装でした(;´･ω･) しかし、実装内容は全く知識の無いことではなく、こんなにすぐに判断してコーディングできないよ!といった部分が多くありました。 所々質問のあったところでは、判断基準などの解説があり、まさに暗黙知の伝達となっていました。
2. ペアプログラミング
教える側と学ぶ側でペアを組み、一人がコーディングして一人がサポートするという一般的なペアプログラミングの形式です。 教える側がコーディングしているときは、学ぶ側は書いていところでどうしてそうしたのかわからなかったらすぐに聞くようにします。 学ぶ側がコーディングしているときは、書いていて教える側が気付いた点や、こうした方が良いよという点があれば指摘するようにします。
大切なのは、急ぎすぎないことです。 何か課題を決めて、この時間内にやりましょうと期限を決めて行うことになると思いますが、 急ぎすぎてしまうと貴重な質問の機会や、指摘の機会を見逃さなければなりません。 課題を達成することが重要なのではなく、課題達成の経路を一緒に模索することが重要です。
3. 社内ハッカソン
二人から四人ぐらいの少人数のチームを組んで行います。 ハッカソンでは、アイデアを出すためのブレーンストーミングや、 この機能はどうやって実装するかを互いにしっかり話し合う必要があります。 また、ゼロから開発した経験が得られるため自信が付きます。
ハッカソンでは、システム開発を凝縮して体験することができます。 教える側と学ぶ側が一緒に作業することで、アイデアの出し方、 工程の決定の仕方、作業分担方法、実装方法などなど実に様々なことを同時に行うことになります。
このとき、学ぶ側が自分で決定できないことがほとんどでしょう。 教える側がドンドン引っ張っていきつつ、学ぶ側は分からないことをどんどん質問する必要があります。
ハッカソンでは、質問して形式知を獲得することを優先して、製作物を疎かにするよりも、 製作物を完成させることを優先すべきです。 なぜなら、最初に述べたようにゼロから開発した経験を得ることを優先させるべきだからです。
学ぶ側が未熟で実装できた機能が少なかったとしても、 実際にできた製作物に関わり、ここは自分で実装したんだ！という自信が付きます。
終わりに
暗黙知とはどういったものなのかを解説し、暗黙知を共有するための方法を検討しました。 今回暗黙知を学ぶ立場を意識して書きましたが、実際には暗黙知について問題視するのは教える側の方々だと思います。
そして、教える側は学ぶ側にいかに興味を持たせるかに苦心することになると思います。 暗黙知を正確に完全に伝えることは不可能です。そのため、形式知として一部だけ講義形式で教えることになってしまいがちで、いつの間にかついていけなくなることも少なくないのでしょうか。
今回挙げた内容では、比較的短時間で実践でき、教える作業に学ぶ側が積極的に関わる必要があり、出来るだけ楽しく、暗黙知を暗黙知のままとして見たり聞いたりしながら、形式知として自分の中に積み重ねていけると思います。
是非実践してみてください！
