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