はじめに
先日、輪読会の主催者の方と勉強方法について話している中で、「暗黙知」と「形式知」という言葉が出てきました。
正直、最初は「なんだか難しそうな言葉だな」と思いました😅
でも、調べてみると、普段の勉強にも関係している面白い考え方だと分かりました。
今回は、自分なりに理解したことを整理してみようと思います。
ちなみに毎週金曜日に参加している輪読会についての感想ブログはこちらです。
ご興味がありましたら、ぜひ一読ください😊
yswengineer.hatenablog.com
目次
- はじめに
- 目次
- そもそも、暗黙知と形式知とは？
- 「自分では自然にやっていたことがあった」という経験
- 何でも自分で気付く必要はない
- 「知っている」と「自分のものになっている」は違う
- エンジニアの経験にも「暗黙知」があるのかも
- 技術記事を書くことにもつながる
- 今回のことで、勉強の仕方についても考えた
- まとめ
- おわりに
そもそも、暗黙知と形式知とは？
まず、ものすごく簡単に言うと、
- 暗黙知：経験などから身に付いているけれど、うまく言葉にしにくい知識。
- 形式知：言葉や文章、図などに整理されていて、他の人にも説明・共有しやすい知識。
という違いのようです。
たとえば、私は普段から料理をするのですが、料理を味見して、
「もう少し塩を入れたほうがいいな」
と判断できる。
でも、「なぜそう思ったんですか？」と聞かれたら、
「うーん……なんとなく😅」
となるかもしれません。
これまでの経験から判断しているけれど、その判断の基準を一つひとつ言葉にしているわけではない。
こういうものが「暗黙知」なのかな、と思いました。
一方で、
「塩は最初に全部入れず、味見をしながら少しずつ加える」
のように、文章などで説明できれば、他の人にも伝えることができます。
これが「形式知」です。
何となくでも伝わっていれば幸いです😅。
「自分では自然にやっていたことがあった」という経験
今回、この話を聞いていて特に面白いと思ったのが、
「振り返ってみると、その勉強方法をやったことがあったな」
ということです。
たとえば、
- まず作りたいものを決める
- 実際に手を動かす
- 分からないところが出てくる
- 必要なことを調べる
- もう一度やってみる
という勉強をしていたとします。
本人からすると、
「普通に勉強していただけ」
なのかもしれません。
でも、誰かがそれを整理して、
「これはこういう勉強方法ですよ」
と名前を付けてくれたら、
「あれ？ 自分がやっていたことって、こういうことだったのか」
と気付くことができます。
「あれ？これって結構面白いな」と思いました。
自分の中では「なんとなくやっていたこと」が、言葉になったことで、初めて自分でも理解できるようになる。
これが、暗黙知を形式知にするということなのかなと思います。
何でも自分で気付く必要はない
ここで大事なのは、
「全部、自分で気付かなければいけない」
ということではないと思います。
むしろ、先人の知恵を借りることは大切ですよね。
本を読んだり、誰かの記事を読んだり、経験者から教えてもらったりもする。
そこで、
「こういう考え方があるのか」
と知る。
そして、実際に自分でやってみる。
すると、
「あ、本当にこういうことなのか！」
と実感することがあります。
そうやって、誰かが整理してくれた知識を、自分の経験をとおして自分のものにしていく。
この過程が大切なのかなと思いました。
「知っている」と「自分のものになっている」は違う
これはプログラミングの勉強でも、よくあることだと思います。
たとえば、データベースの正規化について本を読んで、
「データの重複を減らすためにテーブルを分けるんだな」
と理解したつもりになる。
でも、実際にER図を描いてみると、
「あれ？ このデータはどこに入れればいいんだ？」
となる。
そこで実際に考えて、
「ここに入れると同じデータを何度も保存することになるな」
「だったら、こっちのテーブルに分けたほうがよさそうだ」
と気付く。
こういう経験をすると、単に本に書いてあることを知っているだけではなく、
「こういう場合は、こう考えればいいんだ」
と、自分で判断できるようになります。
最近、自分がER図を描いていて迷ったことも、まさにこういうことだったのかなと思います。
エンジニアの経験にも「暗黙知」があるのかも
これを考えていたら、エンジニアの仕事にも暗黙知がたくさんあるのではないかと想像しました。
経験のあるエンジニアがコードを見て、
「なんとなく、このコードは嫌な感じがする」
と言うことがあるかもしれません。
でも、その人が経験を積んでいく中で、
「この処理は責務が集中しているから、後で複雑になりそう」
「同じ処理が複数箇所にあるから、修正するときに大変になりそう」
などと説明できるようになる。
最初は「なんとなく」だったものが、経験を積むことで理由を説明できるようになる。
これも、暗黙知が少しずつ形式知になっていくということなのかなと思いました。
技術記事を書くことにもつながる
ここまで考えて、以前から「技術記事を書くこと」に興味があった理由も、少し分かった気がします。
たとえば、何かプログラミングでつまずいたとします。
そこで、
「分からなかったけど、なんとなくできちゃったなぁ」
で終わらせるのではなく、
- 何が分からなかったのか
- どこでつまずいたのか
- どうやって調べたのか
- 何を勘違いしていたのか
- 最終的にどう判断して、どのように理解したのか
を書いてみる。
そうすると、自分の中にあった「なんとなく分かった」を、少しずつ言葉にすることができます。
そして、それを記事にすれば、自分のための記録にもなるし、同じところで困っている人の役に立つかもしれません。
そう考えると、技術記事を書くことは、自分の中にある暗黙知を形式知にしていく作業の一つなのかもしれないと思いました。
今回のことで、勉強の仕方についても考えた
今回、暗黙知と形式知について調べてみて、
「知識を覚えるだけが勉強ではないんだな」
と改めて感じています。
本を読んで、
「なるほど、分かった！」
と思っても、実際に手を動かしてみると分からないことが出てきます。
そこで考えて、調べて、試してみる。
そして、
「なぜ自分はこう考えたのか？」
を自分の言葉で言語化して、説明してみる。
そうすると、最初は誰かから借りた知識だったものが、少しずつ自分の経験になっていく。
この繰り返しが、知識を「自分のもの」にするということなのかなと思いました。
まとめ
今回の話を、自分なりにざっくりとまとめると、
暗黙知
経験などから身に付いているけれど、うまく説明しにくい知識。
形式知
言葉や文章、図などに整理されていて、他の人にも説明・共有しやすい知識。
ということになります。
そして、
経験する ↓ なんとなく分かる ↓ 言葉にしてみる ↓ 理由を説明できるようになる ↓ 自分の知識として使えるようになる
という流れがあるのかなと思いました。
まだ「暗黙知」と「形式知」について完璧に理解できたわけではありません。
プログラミングを勉強していく中でも、単に「分かった」で終わらせず、
「なぜそうなるのか、自分の言葉で説明できるかな？」
という意識を大切にしていきたいと思います。
そして、分からないことがあったら、無理に全部自分だけで考え込まず、先人の知恵もどんどん借りていきたいです。
おわりに
今回、「暗黙知」と「形式知」という言葉を知ったことで、普段の自分の勉強についても考えるきっかけになりました。
これまで「なんとなくこうしたほうがよさそう」と思っていたことも、実際に経験を重ねたり、自分の言葉で整理したりすることで、「なぜそう思ったのか」が少しずつ見えてくるのかもしれません。
また、分からないことをすべて自分だけで解決する必要はなく、本や技術記事、経験者の方の知恵を借りながら、実際に手を動かして自分の経験にしていくことも大切だと感じました。
まだまだ分からないことだらけですが、これからも「知った」で終わらせず、「実際にやってみる」「自分の言葉で整理してみる」ということを大切にしていきたいと思います。
そして、この記事のように自分が経験したことを誰かに伝えられるように、言葉にして残し続けていきたいです。
最後まで読んでいただき、ありがとうございました😊✨
