営業一筋28年の田中さん(仮名)が、ある月曜の朝、心筋梗塞で救急搬送された。命に別状はなかったものの、医師からは「最低でも3か月の療養が必要」と告げられた。会社に衝撃が走ったのは、田中さんの体調そのものより、その日の午後に起きた出来事だった。
取引先のA社から緊急の発注が入った。だが、A社には他の取引先にはない特殊な納品ルールがある。月末締めの請求書は必ず二部作成し、うち一部を先方の経理担当者ではなく現場責任者に直接手渡しすること。このルールを知っていたのは田中さんだけだった。後任として急遽アサインされた若手社員は、通常フローどおり経理担当者にのみ請求書を送付した。結果、A社の現場責任者から「聞いていた話と違う」というクレームが入り、過去に一度同じミスをして信頼関係を立て直すのに半年かかった経緯があることも、誰も知らなかったため、同じ謝罪と同じ説明を一からやり直すことになった。
田中さんの頭の中には、A社だけでなく数十社分の「特殊ルール」と「過去のトラブルとその収め方」が蓄積されていた。それは決してマニュアルの手抜きではない。日々の業務に追われながら、一件一件の取引先と向き合い、失敗から学び、信頼を積み上げてきた28年分の仕事の結晶だ。壁にぶつかるたびに乗り越えてきた、その経験そのものに敬意を払うべきだろう。だが同時に、その結晶が田中さん一人の頭の中にしかなかったという事実は、会社にとって見過ごせないリスクでもある。田中さんが休んだ3か月間、後任者は同じ質問を繰り返し、同じ失敗を繰り返し、そのたびに取引先に頭を下げ続けることになった。
なぜ社内ナレッジは属人化しやすいのか
「属人化はよくない」と頭でわかっていても、実際には多くの中小企業でナレッジの属人化が進行している。理由は決して担当者の怠慢ではなく、構造的なものだ。
第一に、マニュアル化する時間的余裕がない。日々の業務をこなすだけで手一杯の現場では、「今動いている業務」を止めてまで文書化に時間を割く発想自体が生まれにくい。まして田中さんのようなベテランほど仕事量が多く、周囲からの相談も集中するため、記録に回す時間はさらに削られていく。
第二に、口頭伝承の文化が根強く残っている。「わからないことがあったら聞けばいい」という職場では、質問と回答がその場限りで完結し、記録として残らない。聞いた本人の記憶にしか残らないため、同じ質問を別の人がまた別のタイミングでする、という無駄が繰り返される。
第三に、たとえ記録があってもチャットツールの過去ログに埋もれてしまい、検索できない状態になっている。SlackやChatworkでのやり取りは確かに「記録」ではあるが、半年前のスレッドを探し出すのは至難の業だ。キーワードが思い出せない、投稿者名を覚えていない、そもそもどのチャンネルで話したかわからない。結果として「記録はあるのに使えない」という状態が生まれる。これは、マニュアルが存在しないこと以上に厄介な問題だ。情報はどこかにあるはずなのに、誰も取り出せない。
属人化を放置することの実害
属人化がもたらす実害は、田中さんの入院のような突発的な出来事だけに限らない。日常的にじわじわと会社の体力を削っていく。
- 担当者が不在の間、業務そのものが止まる。有給休暇はおろか、体調不良で1日休むことすら「この人がいないと回らない」という理由で躊躇される空気が生まれる。
- 同じ質問、同じミスが繰り返される。過去に一度解決した問題を、記録がないために毎回ゼロから調べ直し、時には同じ失敗を再現してしまう。
- 新人教育のコストが際限なく膨らむ。OJTという名のもとに、先輩社員が同じ説明を新人が入るたびに口頭で繰り返す。教える側の時間も、教わる側の習熟スピードも最適化されない。
- ベテラン社員への依存がさらに強まる悪循環に陥る。聞かれるたびに答えるベテランは、記録を残す時間がますます取れなくなり、属人化は加速する。
そしてもう一つ見落とされがちなのが、ベテラン社員自身の負担だ。自分にしかわからないという状態は、一見「自分の価値が高い証」に思えるかもしれない。しかし実際には、休みたくても休めない、任せたくても任せられない、というプレッシャーを本人が一身に背負い続けることを意味する。ナレッジを仕組み化することは、属人化した個人を守ることでもある。
ナレッジの仕組み化とは何か、身構えずに理解する
「ナレッジマネジメント」や「社内wiki」と聞くと、大掛かりなシステム導入や、分厚いマニュアル作成プロジェクトを想像して身構えてしまう担当者は多い。だが、実際に取り組むべきことはもっとシンプルだ。
まず押さえておきたいのは、マニュアル化と「検索できる状態にする」ことは似て非なるものだという点だ。マニュアルは、業務の手順を体系立てて整理し、誰が読んでも同じ結果にたどり着けるようにするための文書だ。作成には相応の時間と労力がかかる。一方、ナレッジベース(社内wikiのようなもの)が目指すのは、体系立った完璧な文書ではなく、「あのときの質問への答えがどこかにある」状態を作ることだ。極端に言えば、断片的なメモや過去のやり取りのコピーであっても、検索して見つかりさえすれば機能する。
ConfluenceやNotion、esa、Kibelaといったツールが「社内wiki」「ナレッジベースツール」と呼ばれるのは、まさにこの検索性を担保するためだ。チャットログのように埋もれてしまうのではなく、キーワードで引き出せる形で情報を蓄積していく。田中さんのケースで言えば、A社の特殊な発注ルールと過去のクレーム対応の経緯を、完璧な文章でなくとも「A社」で検索すれば出てくる状態にしておくだけで、後任者が同じ轍を踏むことは防げたはずだ。
つまり仕組み化の第一歩は、壮大なマニュアル整備ではなく、日々発生する「聞かれたこと」「調べたこと」「トラブルとその解決策」を、検索できる場所に置いていくという地道な積み重ねなのだ。
実際にどう進めればいいか
仕組み化のハードルを下げるために、進め方には順序とコツがある。
まず、全業務を一度に文書化しようとしないことだ。「今週中に全部署のマニュアルを揃えよう」といった号令は、たいてい現場の反発を招くか、途中で頓挫する。業務は日々動いているのであり、それを止めて文書化に充てられる時間は限られている。
着手すべきは、問い合わせが多い質問からだ。新人からよく聞かれる質問、他部署から頻繁に確認される手続き、担当者交代のたびに引き継ぎで必ず説明している内容。これらは「聞かれる回数」で優先順位をつけられる、いわば投資対効果の高いナレッジだ。1件のQ&Aを書き起こすだけで、以降その質問に答える時間がゼロになる。この積み重ねが、やがて田中さんのような特殊ルールやトラブル対応履歴にも及んでいく。
次に重要なのが、ベテラン社員の負担にならない記録の集め方を選ぶことだ。田中さんのようなベテランに「業務の合間にマニュアルを書いてください」と依頼しても、優先順位は下がりがちだ。有効なのは、次のような方法で本人の負担を最小化することだ。
- 口頭で説明してもらった内容を、聞いた側(新人や後任者)がその場でメモし、ナレッジベースに投稿する。ベテラン社員は話すだけでよい。
- チャットやメールでのやり取りの中で有用な回答があった場合、それをコピーしてナレッジベースに転記するルールを、周囲のメンバーが担当する。
- 音声メモや簡単な録音を文字起こしし、後から整形する。ベテラン社員本人が文章を書く負担を避ける。
- 定例会議や引き継ぎの場を利用し、「今月困った質問トップ3」を共有してもらい、それを記録係が書き起こす。
大切なのは、記録する行為とその負担を、ノウハウを持つ本人以外が引き受ける体制を作ることだ。長年の経験を積んだ人ほど、日々の業務そのものが会社にとって価値を生んでいる。その時間を記録作業に割かせるのではなく、周囲がその価値を形に残す役割を担う。これは敬意の払い方の一つでもある。
ツール選定・発注時に確認すべきポイント
ナレッジベースツールを選ぶ、あるいは外部に構築を依頼する際には、次の点を確認しておきたい。
- 検索性の高さ。全文検索ができるか、タグやカテゴリでの絞り込みができるか。「検索できない」という属人化の根本原因を解決できるツールかどうかを最優先で確認する。
- 投稿のハードルの低さ。専門的な操作知識がなくても、非エンジニアの社員が気軽に書き込めるか。入力画面が複雑すぎるツールは、結局使われなくなる。
- 既存のチャットツールとの連携。SlackやChatworkから直接投稿・転記できる仕組みがあると、日々のやり取りの中で自然にナレッジが蓄積されやすい。
- 権限設定の柔軟さ。取引先の機密情報や社内限りの情報を扱う場合、部署単位・役職単位でのアクセス制御ができるかを確認する。
- 運用・保守にかかる負担。導入して終わりではなく、誰が更新や整理を担当するのか、運用ルールも含めて発注前に設計しておく。
- 将来のデータ移行のしやすさ。ツールを乗り換える際に、蓄積したナレッジをエクスポートできるか。ベンダーロックインのリスクも確認しておきたい。
よくある失敗パターン
ナレッジ仕組み化の取り組みで、実際によく見られる失敗にはいくつかの共通点がある。
- ツール導入をゴールにしてしまう。高機能なツールを契約しただけで満足し、実際に書き込む運用ルールや担当者を決めないまま放置され、数か月後には誰もログインしなくなる。
- 完璧な文書を求めすぎる。最初から体裁の整った丁寧なマニュアルを目指すあまり、着手すら遅れる。まずは箇条書きの雑なメモでよい、という共通認識を持たないと前に進まない。
- ベテラン社員一人に文書化を丸投げする。前述のとおり、これは本人の負担を増やすだけで、優先順位が下がり続け、結局何も残らない。
- 更新されない情報が放置される。一度書いたきりで最新化されず、古い情報を信じた社員が誤った対応をしてしまう。誰がいつ見直すか、というメンテナンスの仕組みを決めていないことが原因だ。
- 経営層が号令をかけるだけで、日常業務の評価に組み込まない。ナレッジ共有が評価されない組織では、忙しい現場ほど後回しにされる。
これらの失敗に共通するのは、ナレッジの仕組み化を「一度作れば終わるプロジェクト」として捉えてしまっている点だ。実際には、日々の業務の中で継続的に積み重ねていく文化そのものを育てる取り組みであり、そこには終わりがない。
まとめ
田中さんが28年かけて積み上げてきた取引先ごとの機微や、トラブルを乗り越えてきた経験は、間違いなく会社の財産だ。壁にぶつかりながらも一つひとつ乗り越えてきた、その仕事への向き合い方そのものに敬意を払いたい。だからこそ、その財産を田中さん一人の頭の中に閉じ込めたままにしておくのは、本人にとっても会社にとっても望ましい状態とは言えない。
属人化は、担当者の怠慢でも、悪意でもなく、日々の忙しさと組織文化が生み出す自然な帰結だ。だからこそ解決策も、気合いや号令ではなく、地道な仕組みづくりにある。全業務を一気に文書化しようとせず、問い合わせの多いところから着手し、ベテラン社員本人ではなく周囲が記録を担う。そして、マニュアル化とは別に、まずは検索できる状態を作ることを目標にする。
次に誰かが長期の休みに入っても、あるいは会社を離れることになっても、その人が積み上げてきた知恵が探し出せる場所に残っている。それは、これまで壁を越えて働いてきた一人ひとりへの、何よりの敬意の表し方ではないだろうか。