Scrapboxで組織内の暗黙知を明文化する
学習には色々方法があるけど
資料を集めて読む
時間かかる、読み間違える
インターネット検索
速いけど、嘘も混じってる
有識者に教えてもらう
有識者の負担が半端ない
などなど問題がある
Scrapboxで、わからない事をなんとなくで書くといい
言葉の定義、設計意図やノウハウなど何でも
それを組織内の有識者に添削・修正してもらう
教える側も、相手が何がわからないのかがわかった上で添削できるので楽
高速に暗黙知が明文化される
先週mongodbが重くて、色々やって改善した
その為のパフォーマンス分析をしている時に、この記事を思い出した
色々調べて、mongodbの気持ちになってqueryを書いたら速くなった。
状況
mongodbが遅くなっていて原因を調べている
mongodbは使えるけど、運用には詳しくない
mongodbの運用に詳しい
過去にGyazoで様々なパフォーマンストラブルを経験してきたようだ
組織内の暗黙知
mongodb内部で何が起きているか、
はかなり理解している
「こうやった」という作業ログはCosenseに残っている
「なぜやったか」を、mongodbの内部の仕組みに沿って解説するドキュメントがあまりない
どうなったか
それを文章化できた
これまでにGyazoがやったパフォーマンスチューニングの記録を読み解く、とっかかりを得た
まあ結局mongodbのレプリケーションはfscrapboxのパフォーマンスに関係なかったのだが、関係ないという事が理解できたのが良かった。
Scrapboxで暗黙知を明文化するプロセス
情報収集しながら
実際のDBの動作ログを見る
社内外のドキュメントを読む
同時に仮説を書き出す
こうだからこうなったのではないか？
mongodbのこの動作って、こういう事じゃないのか？
その時、見つけた言葉の意味を定義したり、意味を自分なりに解説・推測する
（このへんのページは社内のprojectにある）
そこに等から肯定や修正が入る
この、まずわからない人が説明し、わかってる人が訂正するという方法の効率が良い
暗黙知を1人で明文化するのは、とても難しい
何が暗黙の知なのか？は、対話の中で明らかになる
相手が何がわからないのかわからないので、いきなりは説明しづらい
ゼロから解説するより、ツッコミを入れる方が楽
別ページのリンクを示して、「こういう事があってね」と解説できると楽
「この人が知ってる」と他人にパスする事もできる
人・物・出来事・概念の、定義と関連の説明は、1人で全部やると無限に時間がかかる
詳しい人からすると
どこまで詳細に深く説明するべきかわからない
加減すると説明不足で伝わらないかもしれない
伝わっているのかどうかわからない
Scrapboxでやる
後からページタイトルを変えたり、ページの一部を別ページに切り出したりと、柔軟に知識を明文化できる
コメントしやすい箇条書きで書く
指示語無しでコメントできるフォーマット(美文章滅すべし)
相手の理解度は丸見え
肯定・修正をすればいい
ターン制コミュニケーションではないので話が早い
空ページリンクが作れる
未説明の単語を、未定義のままで置いておける
もしくは自分で解説を書き、修正してもらう
上の協調作業がリアルタイムにできる
レポート書いて提出し、赤ペン入れて戻す、みたいな往復ではなく
調べる→まとめる→誰かにチェックしてもらうを具体的に説明した感じ
検索する事と質問する事のコストの差
共通した知識を持っていない人同士が知識交換するとコスパが良い
というような事がかかれていて、それはわかるのだが
検索すると嘘や誤った解説がけっこう混じっている、という問題がある
検索して、メモを書いて、それを有識者に確認してもらいながら学習できると良いと思う
結論
わからない人が書けばいいと思う