team
ナレッジの共有を始めたはずなのに、書き込みが止まっている。作ったページの更新日が全部同じ週に固まっていて、それ以降が空白になっている。この状態から抜け出したくて調べている人が、いちばん多いはずです。
先に結論を書きます。共有が止まる原因は、書く人のやる気ではありません。書く場所が仕事の流れの外に置かれていることです。仕事はタスクの画面とチャットで進み、記録だけが別の場所にある。この構造だと、書く行為が毎回「余分な一手間」になります。2週間で止まるのは、意思の弱さではなく設計の帰結です。
ナレッジ共有とは、業務を円滑に進めるのに役立つ知識・経験・ノウハウなどを、誰もが使いやすいように共有することです。 出典: business.ntt-east.co.jp
この記事では、共有が課題になる背景から始めて、共有できていない知識の正体、失敗する3つの原因、続けるための手順、ツールの選び方とおすすめの見分け方、そして続いているかどうかを測る方法までを順に扱います。
ナレッジの共有という言葉が出てくるチームには、だいたい共通した事情があります。人の入れ替わりが起きたか、起きることが見えているかのどちらかです。
5人から数十人の規模だと、1人あたりが抱えている手順の量が多くなります。請求の締めの流れ、特定の取引先だけに必要な手続き、過去に一度だけ起きた不具合の直し方。こうしたものは誰かの頭の中と、その人のメールの履歴にだけあります。その人が休んだ日に、同じ問い合わせが2回3回と別の人に回っていく。これが共有の必要性として現れる最初のかたちです。
もう1つの背景が、問い合わせの重複です。同じ質問が形を変えて何度も来る状況では、答える側の時間がそのまま消えていきます。1件10分の説明が週に6件あれば、それだけで1時間になります。答えを書いて置いておけば済むのに、書く時間が取れないから毎回答えている。この循環に入っていることに気づいた時点で、共有の話が始まります。
背景として見落とされやすいのが、道具が増えたこと自体です。チャット、タスク管理、ファイル置き場、クラウドの表計算、それぞれに情報が入っています。どれも便利なので導入され、結果として「どこを見れば分かるか」が分からなくなりました。情報が足りないのではなく、散っているほうが問題になっている状態です。この場合、新しく書く前に、どこを正とするかを決めるほうが先になります。
規模の面でも事情があります。数十人を超えると、情報を集めて整える専任の担当を置く会社が出てきますが、5人から数十人の段階では、その役目は進行をとりまとめている人に寄ります。つまり、いちばん忙しい人のところに記録の仕事が乗る構造になっています。この構造のまま「ちゃんと書こう」と決めても、決めた本人の時間が先に尽きます。だからこそ、書く手間そのものを減らす方向でしか解けません。
業界による違いもあります。建設や製造のように手順が固まっている仕事では、手順書の整備が中心になります。受託の開発やデザインのように案件ごとに事情が変わる仕事では、手順書よりも過去の案件の判断の記録が効きます。前者は文書を整える話、後者は案件に紐づく記録の話で、必要な道具の形が変わります。自分のチームがどちらに近いかを先に決めておくと、次の選択が早くなります。
つまり、ナレッジの共有は「良い習慣を身につける話」ではなく、人が抜けたときと問い合わせが重なったときに備える運用の話です。ここを取り違えると、啓蒙に時間を使って構造を変えないままになります。
ナレッジは大きく2つに分けて考えます。言葉や図にできている形式知と、本人も説明できていない暗黙知です。この区別を先に置かないと、対策の方向がずれます。
形式知は、手順書やテンプレート、過去の見積書のように、すでに形になっているものです。これが共有できていない場合の原因は単純で、置き場所が分かれているか、検索で出てこないかのどちらかです。ファイル名が「最新版_改2_修正後」のようになっているなら、これは分類の問題であって、書く文化の問題ではありません。対策も単純で、置き場所を1つ決めて、名前の付け方を決めるだけです。
難しいのは暗黙知です。この取引先には金曜の午後に連絡しても返ってこない、この作業は先にAを終わらせないと手戻りが出る、この機械は音が変わったら止めたほうがいい。こうした判断は、本人にとっては当たり前なので、書く対象として認識されません。「何か共有することはありますか」と聞いても出てこないのは、隠しているからではなく、共有すべき知識として自覚されていないからです。
暗黙知を引き出す方法は、質問の形を変えることです。「ノウハウを書いてください」ではなく、「この作業でいちばんよく失敗するのはどこですか」「新しい人が最初につまずくのはどの手順ですか」と聞きます。失敗の話は具体的に出てきます。そこから逆算して手順を書けば、それが暗黙知の記録になります。
引き出す順番にも要点があります。全員に一斉に呼びかけるより、1人に絞って始めるほうが結果が出ます。いちばん問い合わせを受けている人の作業を1つ選び、その手順を横で聞きながら書き起こす。本人に書かせないのが要点です。説明を聞いた側が書けば、説明されなかった前提が浮かび上がります。書いたものを本人に見せると、「そこは違う」という訂正が出てきます。この訂正こそが暗黙知の核心です。
この方法には副産物があります。1人分を書き切ると、他の人が「自分の分も同じ形で書けばいいのか」と分かります。書き方の見本がないまま「自由に書いてください」と頼むと、粒度も長さも人ごとにばらばらになり、結果として読みにくい記録が増えます。最初の1本を誰かが丁寧に作ることが、そのあとの量を決めます。
もう1つ効く方法が、進行中の仕事に紐づけて書かせることです。案件が終わったあとに振り返って書くと、記憶が薄れているうえに、その作業自体が追加の仕事になります。作業の最中に、そのカードのコメントとして「ここで詰まった」と1行書いてもらうほうが、量も精度も上がります。記録を独立した作業にしないことが、暗黙知を取り出す条件です。
共有が止まったチームを並べると、原因は3つに収まります。順番に見ていきます。
1つ目は、書く場所が仕事の外にあることです。タスクはタスク管理ツール、会話はチャット、記録は別のツール。この配置だと、記録を残すために別のタブを開き、ページを探し、書式を整える必要があります。この手間は1回あたり数分ですが、忙しい日には確実に飛ばされます。そして1回飛ばすと、次からは書かなくてよいものとして扱われます。
2つ目は、読む人がいないことです。書いた側は、誰かに読まれた実感がないと続けられません。ここで起きているのは、書く動機の問題ではなく検索の問題です。困ったときに探して出てこなければ、書いた内容は存在していないのと同じになります。実際に多くのチームで、記録はあるのに使われていません。検索してもタイトルが曖昧で該当が分からず、結局「あの件どうでしたっけ」とチャットで聞くほうが早い。この状態を放置すると、書く側も読む側も離れます。
3つ目は、誰の仕事でもないことです。共有は全員の仕事として設計されがちですが、全員の仕事は誰の仕事でもありません。書く責任、整える責任、古いものを消す責任が誰にも割り当てられていないと、半年で使えない情報が積み上がります。古い情報が混ざった記録は、検索したときに判断を誤らせるので、無いより悪くなります。
この3つの手前に、もう1つ土台の問題が潜んでいることがあります。何を共有すべきかが決まっていないことです。すべてを記録しようとすると、量が増えて検索が効かなくなり、結果としてどれも読まれません。共有する対象を「2回以上聞かれたこと」と「失敗して手戻りが出たこと」の2種類に絞るだけで、書く量は現実的な水準まで落ちます。絞る基準を決めていないチームは、始めた直後に量で息切れします。
失敗の形として最後に挙げたいのが、道具を入れ替え続けることです。続かない理由を道具に求めて、半年ごとに新しいものへ移る。移行のたびに過去の記録が置き去りになり、どの世代の情報がどこにあるか誰も分からなくなります。入れ替えるなら、古い場所を読み取り専用にして、いつまでのものがどこにあるかを1行で残します。この処理をしないまま次へ行くと、記録は増えているのに使える情報が減ります。
この3つに共通しているのは、どれも個人の意識では解決しないことです。研修をしても、声をかけても、構造が同じなら結果は同じになります。変えるべきは場所、検索のしやすさ、そして役割の3点です。
順番があります。道具を選ぶのは最後です。
ステップ1は、正とする場所を1つ決めること。 いま情報が散っている場所を全部書き出して、「これからはここを見れば分かる」という場所を1つ決めます。他の場所を消す必要はありません。正がどこかを決めるだけです。この宣言がないまま新しい場所を作ると、散っている場所が1つ増えるだけになります。
ステップ2は、書く単位を仕事の単位に合わせること。 ページ単位で「マニュアル」を作ろうとすると、書き始めるまでの心理的な負担が大きくなります。進行中の案件やタスクのカードに、そのつど1行から数行で残す形にすれば、書き始める負担がほぼなくなります。あとから読むときも、どの仕事の話かが分かるので文脈を補う必要がありません。
ステップ3は、書く役割と消す役割を人に割り当てること。 書く側は、その仕事の担当者です。消す側は、月に1回、古くなった記録に印を付ける人を決めます。全部を精査する必要はありません。「この手順はもう使っていない」と分かるものに印を付けるだけで、検索の精度が保てます。この役割を持つ人を決めていないチームでは、6か月で検索が使えなくなります。
ステップ4は、探す入口を固定すること。 困ったときにどこを開くかを、全員が同じ場所にします。チャットで聞く前に、まずその入口で検索する。この順番を習慣にすると、検索で出てこなかったことが「書く必要がある」というサインとして機能します。サインが出た時点で書けば、記録は使われるものだけが増えていきます。
4つのステップのどこから手を付けるべきか迷ったら、ステップ4から逆に進めます。まず、困ったときに全員が開く場所を宣言します。次に、そこに無かったものを書く。これだけで、書く対象が自動的に絞られます。網羅的な手順書を作ろうとする計画は、たいてい着手の段階で止まります。実際に聞かれたことだけを書いていく形なら、量は少なくても使われる記録になります。
期間の目安も置いておきます。場所を決めるのに1日、書く単位と役割を決めるのに半日、そこから実際の運用を2週間試して、続いたかどうかを見ます。この2週間で書き込みが途切れたなら、原因は決めごとではなく手間の量です。開くまでのクリック数と、書式を整える必要の有無を見直します。逆に続いたなら、あとは古いものを消す役割を回し始めるだけで、運用として固まります。
この4つを、道具を決める前に紙の上で決めておきます。逆の順番でやると、道具の機能に合わせて運用を作ることになり、道具を変えるたびに運用が壊れます。
ナレッジの共有に使われるツールは、大きく3つの系統に分かれます。系統を先に選ばないと、比較表を見ても判断できません。
1つ目が文書型です。ページを作って階層に並べる形で、Notionのような道具が代表です。書ける自由度が高く、長い手順書や仕様の記述に向いています。弱点は、階層が深くなると迷子になることと、進行中の仕事との距離が離れやすいことです。文書としての完成度を求める用途では強く、日々の細かい記録の受け皿としては手間が勝ちます。ページの作りとタスクの扱いがどう違うかはNotionとの比較に整理があります。
2つ目が課題管理型です。案件や不具合ごとに記録が積み上がる形で、開発や受託の現場で使われます。Backlogのように課題とWikiを併せ持つ道具がこの系統です。記録が仕事に紐づくので文脈が残りますが、案件をまたいだ横断的な手順書の置き場としては散りやすくなります。課題の粒度と権限の考え方はBacklogとの比較で確かめられます。
3つ目が、タスクの板に記録が同居する型です。カードの中にコメントとチェックリストがあり、話したことがそのまま記録になります。この形は、暗黙知の取り出しに向いています。書くために別の場所を開く必要がないからです。スレッド形式で確認事項を進めて、決まったことがそのまま残る形のボードを持つ道具もあります。用意されているボードの種類はできることにまとめられています。
系統を選ぶときに考えたいのが、記録を読む人の立場です。社内の実務者しか読まないなら、多少雑な書き方でも通じます。新しく入った人や社外の協力者が読むなら、前提の説明が要ります。読み手が広いほど文書型の強みが出て、読み手が実務者に限られるほどタスクに紐づけた記録で足ります。読み手を決めずに道具を決めると、必要のない整え作業が発生し続けます。
もう1つ、AIに答えさせる使い方を前提に置くかどうかで選択が変わります。記録を溜めておいて、あとから質問して答えを引き出す使い方を想定するなら、書式の統一よりも記録の量と、機械が読める形で置かれているかが効きます。逆に人が読んで判断する前提なら、量より整え方が効きます。どちらを主に想定するかで、書き方の指示の中身が変わります。
選び方の軸は4つに絞れます。第一に、検索が実用的に速いか。第二に、権限を分けられるか。社外の協力者に見せる範囲を絞れないと、共有の範囲そのものが制約されます。第三に、書き込むまでのクリック数。第四に、無料でどこまで試せるか。おすすめを探すときは、機能の数を数えるより、この4つを自分のチームの動きで試すほうが確実です。
導入の判断で最初に詰まるのが、どこまで無料で確かめられるかです。ここは道具によって考え方が大きく違います。
無料プランの区切り方には2種類あります。機能で区切るものと、量で区切るものです。機能で区切られている場合、無料のあいだは検索や権限の機能が使えないので、いちばん確かめたい部分が確かめられません。有料にしてから「思っていた検索ではなかった」と分かる形になります。量で区切られている場合は、人数や置ける数の上限まで、本番と同じ使い勝手を確かめられます。
試すときの人数は、実際の運用に近い数にします。1人で触っても、共有の問題は出てきません。検索が効くかどうかも、記録が数十件たまってから初めて分かります。最低でも3人、できれば実務の1案件を丸ごと入れて2週間動かすと、続くかどうかの感触が出ます。
料金の比べ方にも注意点があります。1人あたりの月額だけを見ると安く見えても、共有したい相手の人数を数え直すと金額が変わります。パートやアルバイト、業務委託の協力者を含めるかどうかで、必要な席数は倍になることがあります。逆に、読むだけの人に無料の枠が用意されている道具もあります。機能で絞らず、区切るのは人数とボードの数だけという区切り方であれば、試す段階で機能の判断ができるので、比較の手戻りが少なくなります。人数と数だけで区切る形の料金の考え方は料金で確かめられます。
試す期間の長さにも目安があります。1週間では短すぎます。1週間で判断すると、目新しさで良く見える部分しか見えません。判断したいのは3週目以降の挙動です。忙しい週に書き込みが止まるか、止まったあとに戻ってこられるか。ここが実際の運用と同じ条件になります。無料で使える期限が日数で区切られている場合は、この3週目に入る前に期限が来ることがあるので、期限の形も確認しておきます。
社内の決裁が要る場合は、試す段階で費用の見通しを出しておきます。必要な席数、読むだけの人の扱い、1年分の合計。この3つを先に出しておけば、途中で金額の話に差し戻されません。特に、協力者を含めた人数の数え方は道具ごとに違うので、公開されている料金のページで数え方の記述を確かめておきます。人数の数え方が書かれていない場合は、確かめられなかったものとして扱い、見積もりには含めません。
もう1つ、見積もりに入れておくべき費用があります。移行の手間です。すでにどこかに記録がある場合、それを運ぶ作業が発生します。自動で取り込めるのは限られた組み合わせだけで、多くは手作業になります。自動で運べる範囲を先に確かめておくと、導入の日程が現実的になります。取り込みの対象と範囲はTrelloからの移行に書かれています。
やった気になって終わらせないために、続いているかどうかを数で見ます。難しい計測は要りません。3つだけで足ります。
1つ目は、書き込みがあった日数です。月のうち何日、誰かが何かを書いたか。これが月の後半で急に減っていれば、忙しさに負けた合図です。週3日以上どこかに書き込みがある状態が続けば、習慣として定着したと見てよい水準です。
2つ目は、検索して出てきた割合です。厳密な計測は難しいので、運用で代わりを作ります。チャットで「これどこにありますか」と聞かれた回数を数えるだけです。この回数が減っていれば、探して見つかるようになっています。減らないなら、書く量ではなくタイトルの付け方と分類に問題があります。
3つ目は、同じ質問が再び来た回数です。1度答えた質問がまた来たとき、その答えは記録されていないか、記録されているのに見つからないかのどちらかです。この回数を月ごとに並べると、共有の効果がいちばん分かりやすく出ます。
3つの数字を並べるときは、月単位で1行に書き足していく形にします。凝った集計の仕組みを作ると、その集計自体が続かなくなります。書き込みのあった日数、聞かれた回数、再質問の回数。この3つを毎月1行足すだけの表で足ります。半年並べれば、施策と数字の関係が見えます。
数字が動かないときの読み方も決めておきます。書き込みが増えているのに聞かれる回数が減らない場合、問題は検索とタイトルです。書き込みが減っていて聞かれる回数も減っている場合は、共有が定着したのではなく、聞くことをあきらめている可能性があります。この見分けは数字だけでは付かないので、四半期に1度、実際に探してもらう場面を見るのがいちばん早い確認になります。
測るときに避けたいのが、ページ数や文字数を指標にすることです。量を評価すると、読まれない長文が増えます。共有の成功は、書かれた量ではなく、聞かれる回数が減ることで表れます。指標を量に置いた時点で、目的と測るものがずれます。
社外の人が関わる場合は、ここに1つ足します。見せてよい範囲の確認です。協力者に共有した記録に、社内限定の情報が混ざっていないかを月に1度見ます。権限の設計と保管の考え方は安全性の考え方にまとめられているので、社外との共有を始める前に一度読んでおくと判断が早くなります。
共有が続き始めると、次に決めることが範囲です。ここを決めないまま広げると、事故の形が変わります。
まず、社内と社外の線を引きます。業務委託の協力者やパートナー企業に見せる記録には、社内の判断の経緯や取引条件が混ざりやすい。混ざったまま共有すると、意図しない情報が外に出ます。対策は、外に見せる前提の記録と、内部だけの記録を別の入れ物に分けることです。同じ入れ物の中で権限だけを分ける形は、運用の途中で必ず間違いが起きます。人が判断する回数を減らす設計にします。
次に、個人情報と機密の扱いです。顧客の連絡先や、取引先から預かった資料を記録の中に貼り込むと、その記録の保存期間と削除の責任が発生します。NDAを結んでいる案件の情報が、案件終了後も記録として残り続けることもあります。ここは法の解釈が絡むので、自分たちで判断を固めずに、契約の窓口や専門家に確認する前提で進めます。記録の仕組みを作る段階で、消す手順まで含めて決めておくと、あとから遡って整理する手間が消えます。
3つ目が、共有しないと決めるものです。評価や処遇に関わる話、まだ決まっていない人事の話、交渉中の条件。これらは記録に残す対象から外します。何でも書く場所として設計すると、書けないことが増えた時点で誰も使わなくなります。書かないものを最初に決めておくほうが、使い続けられます。
最後に、範囲を広げる順番です。1つのチームで定着させてから隣のチームに広げる形が、いちばん失敗が少ない。全社で一斉に始めると、部署ごとの書き方の違いが最初に出てきて、書式の議論で止まります。1つのチームで実際に使われている形ができていれば、それが見本になるので議論が短くなります。
比較のページがどう読まれているかを見ると、チームがどこで詰まっているかの傾向が出ます。読まれている比較の中身は、機能の数の多さではなく、いま使っている道具で困っている具体的な1点に集まります。
集まる論点は3つに寄ります。1つは、記録と進行が別の場所にあること。もう1つは、人数が増えたときの料金の跳ね方。最後が、社外の人に見せる範囲の制御です。どれも「機能が足りない」という話ではなく、「いまの形では続かない」という話です。共有が止まったチームの相談も、この3つのどこかに必ず当たります。
ここから分かるのは、道具を変えて解決するのは1つ目だけだということです。料金の跳ね方は使い方を整理すれば下がることがあり、見せる範囲は運用の決めごとで対処できる部分が大きい。書く場所が仕事の外にあるという1つ目だけは、運用の工夫では埋まりません。開くタブが増えるという事実は、気合いでは消えないからです。
同時に、どの道具にも埋まらない穴があることも前提にしておく必要があります。文書型の自由度を求めるなら、タスクとの距離が開くことを受け入れます。タスクに記録を寄せるなら、長い仕様書の置き場としては手狭になります。自動化や外部サービスとの連携を強く求めるなら、その一点で選ぶほうが早い。全部を1つで賄おうとすると、どこかで必ず妥協が出ます。どの系統がどこで妥協するかは比較の一覧を横に並べて見ると判断しやすくなります。
最後に、導入の前に社内から出る質問はほぼ決まっています。保存されたものは誰が見られるのか、やめるときにデータを持ち出せるのか、無料のままどこまで使えるのか。この3点は先に答えを用意しておくと、決裁の往復が1回で済みます。同じ質問への回答はよくある質問にまとまっているので、社内で配る資料を作る手間も省けます。
3人を超えたあたりから効果が出ます。2人なら口頭で足りますが、3人目に同じ説明を繰り返した時点で、書いたほうが早い状態に入っています。規模より重要なのは人の入れ替わりの有無で、退職や異動、業務委託の入れ替えが予定されているなら人数に関係なく先に手を打つ価値があります。
できます。条件は、正とする場所を1つ決めて、探す入口を固定することです。チャットのスレッドを記録に使う場合は、検索で出てこない前提で、月に1度まとめ直す役割を誰かに割り当てます。道具を増やす前に、この運用だけで数週間試すと、本当に足りないものが分かります。
「ノウハウを書いて」と頼むのをやめて、質問の形にします。この作業でよく失敗するのはどこか、新しい人が最初につまずく手順はどれか、と聞けば具体的に答えが返ります。その回答をそのまま記録にすれば、書く負担は答える側から外れます。書式を整えることを求めないのも条件です。
月に1回、古い記録に印を付ける役割を1人決めます。全部を精査せず、明らかに使っていない手順に印を付けるだけで十分です。作った時点で有効期限を書いておく方法も効きます。古い情報が混ざった記録は検索の精度を落とし、判断を誤らせるので、増やすことより減らす担当を決めるほうが優先です。