%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
社内Wikiが使われないときは、「書かれていない」「見つからない」「見つかっても使えない」のどこで利用が止まるかを、実際の業務で確かめます。止まった場所によって、記録する工程、記事の入口、内容を確認する責任のうち、先に直すものが変わります。
社内Wikiが使われないときは、「書かれていない」「見つからない」「見つかっても使えない」のどこで利用が止まるかを、実際の業務で確かめます。止まった場所によって、記録する工程、記事の入口、内容を確認する責任のうち、先に直すものが変わります。
次のような状態が続くと、社員はWikiを開かず、詳しい人に直接聞くようになります。
- 「記事を書いてほしいと伝えても、忙しくて後回しになる」
- 「必要な情報があるはずなのに、検索で見つからない」
- 「手順が変わったのに、Wikiの内容が古いままになっている」
社内Wikiとは、業務で得た知識や手順を組織で共有し、必要な人が再利用できる形にまとめる仕組みです。
定着を考える際は、記事の量から判断するのではなく、利用者が必要な情報にたどり着き、その内容を使って仕事を進められるかを確認します。
この記事では、次の流れで説明します。
- 実際の質問を起点に原因を切り分ける
- 書く・探す・更新する手順を整える
- 対象業務を広げてよいか判断する
本記事は社内Wiki・ナレッジベースカテゴリに属しています。経営管理全体を体系的に学びたい方は経営管理完全ガイドをご覧ください。
この記事でわかること
社内Wikiを用意しても、書き手や読み手が増えず、内容の更新も止まってしまうことがあります。ここでは、繰り返された質問について「回答は存在するか」「利用者の言葉で見つかるか」「読んで次の行動を決められるか」を順に試します。それぞれの段階で何を記録し、誰に確認し、どの状態になれば次へ進めるかを説明します。
- 書いてもらえない原因 — 知識が生まれる業務の節目を見つけ、既存記事の参照・修正・新規作成を選ぶ担当と完了条件を決めます。
- 情報が見つからない原因 — 利用者が入力した検索語から題名、記事への入口、分類の順に確認し、どこを直すか判断します。
- 内容の鮮度を保つ方法 — 記事のオーナー、変更の連絡先、確認の根拠、現行記事への案内を決めます。
- 社内WikiとCRMをつなぐ考え方 — 顧客ごとの記録と再利用する説明の役割を分け、HubSpotのナレッジベースを検討する際の公開範囲と利用条件を確認します。
社内Wikiが定着しない原因を業務の流れから捉える
社内Wikiの利用が止まったとき、社員の意欲だけを原因にすると、改善策も「もっと書いてください」という呼びかけに偏りがちです。
直近で繰り返された質問や、探すのに迷った手順を取り上げ、次の点を確認します。
- 質問した人
- 回答した人
- 参照できた情報
例えば同じ手続きについて質問が続く場合でも、回答が記録されていない場合と、記録はあるが利用者が別の名称で探している場合では、直す工程が異なります。
質問を調べる際は、質問文を利用者の言葉のまま残し、次を並べます。
- 回答者が参照した場所
- 利用者が探した場所
- 回答後に残った疑問
ここで記録、発見、利用、修正のどこが途切れたかを特定できれば、先に直す仕組みを選べます。
「導入した」だけでは利用が始まらない
Wikiを用意しただけでは、どの情報を載せるべきか、どこに書くか、誰が読むかが社員に伝わりません。例えば、問い合わせへの回答を残したい場合でも、対応者が要点を書くのか、内容を確認する人が記事に整えるのかが決まっていなければ、記録の機会を逃します。
進め方は次のとおりです。
- 対象業務を選び、その業務で繰り返し必要になる情報を挙げる
- 情報を記録する人、内容を確認する人、記事を使う人を決める
- 実際の利用者に「どの作業中に、何を判断するために開くか」を聞き、答えがそろえば題名や置き場所を決める
利用場面が定まらない情報は、記事にする目的から見直します。
- 特定の案件の経緯を残したいだけ ── その案件の記録に置く方が適切な場合があります
- 別の担当者が同じ判断や作業に使う説明がある ── 共通記事にする範囲を切り出します
表計算や個別連絡に分散した情報を見直す
情報を表計算ファイルや個人のメモ、チャットのやり取りに分けて保管すると、最新版がどれか分かりにくくなります。
担当者が変わったときに、過去の経緯や手順を探すため、複数の場所を確認しなければならないこともあります。
| 情報の置き方 | 起きやすいこと | Wikiで決めること |
|---|---|---|
| 個人のメモやファイル | 作成者以外が見つけにくい | 共通の保管場所と記事の題名 |
| チャットでの質問と回答 | 後から同じ情報を探しにくい | 回答を記事に転記する担当とタイミング |
| 部門ごとの手順書 | 内容や用語に差が出る | 部門共通の分類と用語 |
| 共有された記事 | 更新の責任者が曖昧になる | 記事のオーナーと見直しの条件 |
情報の所在を確認したら、Wikiで参照すべき現行情報と、判断の経緯を残す記録を区別します。
- 同じ手順に異なる説明がある場合 ── どちらが現行かを業務の責任者に確認します
- 現行版が決まっていない場合 ── 記事を統合する前に業務上の判断をそろえます
保管先を決めるときは、次の問いを分けて確認します。
- 「この手順を今日実行する人はどこを見るか」
- 「変更を決める人はどの情報を根拠にするか」
Wikiに転記した後も別の場所で内容が更新されるなら、更新の基準となる場所と、変更をWikiへ伝える担当を決めます。
この関係が決まるまでは、複数の説明を一つの記事にまとめても、どれを信じるべきかという問題は残ります。
定着の問題を切り分ける
「使われない」という声だけでは、何から直すべきか判断しにくいものです。実際に起きた質問について、次の点を確認します。
- 質問の内容
- 利用者が探した場所と検索語
- 見つけた記事
- 記事を読んだ後に残った疑問
そのうえで、回答となる記事があるか、利用者の言葉で見つかるか、読んだ内容だけで次の行動を決められるかを順に試します。
| 利用の場面 | 確認すること | 改善の方向 |
|---|---|---|
| 情報を残す | 記事を作る業務上のきっかけがあるか | 振り返りや対応完了の流れに記録を含める |
| 情報を探す | 題名や分類が利用者の言葉に合っているか | 検索語とタグ、カテゴリを整える |
| 情報を使う | 内容の担当者や更新時期が分かるか | オーナーと見直し条件を示す |
| 情報を改善する | 利用者が誤りや不足を伝えられるか | 修正依頼の窓口と反映担当を決める |
試した結果は、次のように見直します。
- 記事がない ── 回答者がどこで知識を得たかを確認し、その業務の完了時に記録できるようにします
- 記事があるのに見つからない ── まず実際の検索語で探し、結果に出ないのか、出ても選ばれないのかを分けます
- 見つかっても利用をためらう ── 対象条件、手順、確認責任のどれが不明かを利用者に聞きます
修正後は同じ質問を別の利用者に試してもらいます。記事を見つけても担当者への確認が必要だったなら、その確認が業務上必要なのか、記事の説明が足りないのかを分けて調べます。
確認が必要な判断まで記事だけで済ませようとせず、記事から確認先へ進める状態を目指します。
書いてもらえない問題は業務プロセスで解決する
執筆のお願いを繰り返しても、Wikiへの投稿が通常業務の後回しになれば、更新は続きません。
知識が生まれる業務を選び、完了時に既存記事を参照するのか、修正するのか、新しく作るのかを判断できるようにします。
記録が進まない場合は、次のどこで止まったかを調べます。
- 書く範囲
- 作業のタイミング
- 確認を待つ相手
記録するタイミングを業務の節目に置く
記事を書く機会は、プロジェクトの終了、問い合わせ対応の完了、手順変更の確定など、情報が新しく整理されるタイミングにあります。
ただし、毎回新規記事を作るとは限りません。既存記事で回答できたなら参照先を記録し、不足があれば追記や修正につなげます。
| 業務の節目 | Wikiに残す内容 | 記録する担当 |
|---|---|---|
| 問い合わせへの回答後 | 質問、回答、関連する手順 | 対応した担当者または確認担当 |
| プロジェクトの完了時 | 判断の背景、再利用できる進め方 | プロジェクトの担当者 |
| 手順の変更時 | 変更点、適用範囲、旧手順との違い | 手順のオーナー |
| 引き継ぎ時 | 現状、未完了事項、参照先 | 引き継ぎを行う担当者 |
新たな作業を足すだけでは負担が増えるため、既存の報告や完了処理と一体にします。
- 記録欄 ── 例えば、対応を完了するときに「既存記事で解決できたか」「新しい記事や修正が必要か」を記録する欄を設けます
- 「修正が必要」とした案件 ── 該当記事、足りなかった説明、確認を依頼する相手を残します
依頼が出ても記事に反映されないなら、依頼を受け取るオーナー、内容を確認する人、反映の完了条件を確かめます。
完了条件は投稿したことだけでなく、指摘された不足が解消し、元の質問への回答として使えることまで含めます。
書き始めやすいテンプレートを用意する
白紙から記事を作ると、何を書くべきかを考える時間がかかります。記事の目的に合わせたテンプレートを用意し、利用者がその記事で判断するために必要な項目を先に示します。
次のような構成が考えられます。
- 問い合わせ対応の記事 ── 「質問」「回答」「対象」「関連手順」
- 業務手順 ── 「目的」「準備」「手順」「完了の確認方法」
例えば、回答だけでは適用できる相手が分からないなら「対象」を補います。作業後に何を見れば完了と分かるか曖昧なら「完了の確認方法」を具体化します。
書き手が項目を埋められない場合は、説明を追加すればよいのか、業務の責任者による判断が必要なのかを分けます。
- 責任者の判断が必要な箇所 ── 推測で埋めず、未確認の点と確認先を残します
- 項目の見直し ── 別の利用者が記事を使って迷った項目は残し、使われない項目は見直します
投稿数だけでなく、業務で使われたかを見る
投稿数だけを評価すると、記事が増えても重複や未整理の記事が積み上がる可能性があります。次の点も確認します。
- 記事が実際の業務で参照されたか
- 質問への回答に再利用されたか
- 内容の修正につながったか
同じ質問が続くなら、まず回答となる記事の有無を調べます。
- 記事がある場合 ── 質問した人に普段の言葉で検索を試してもらいます
- 見つからなければ ── 入口や題名を見直します
- 見つかっても再質問が必要なら ── 回答の対象や手順を見直します
- 既存記事と新規記事の内容が重なる場合 ── 用途の違いを明確にするか、現行の参照先を一つに決めます
評価制度に結び付ける場合も、記事の量だけでなく、正確さを誰が確認し、再利用できたかをどう判断するかまで決めます。記録から次に直す工程を選べないなら、数える項目より先に、利用時の困りごとを残す方法を見直します。
情報を探せない問題は分類と題名から直す
記事があるのに検索で見つからないと、利用者はWikiを頼らなくなります。最初に、見つからなかった人が入力した言葉と、探していた記事を確認します。
次のどれかを分けると、直す場所を選びやすくなります。
- 記事が検索結果に出ない
- 結果には出るが選ばれない
- 開いても目的の箇所にたどり着けない
利用者の検索語を記事の題名に反映する
執筆者には分かりやすい専門用語でも、利用者が別の言葉で検索している場合があります。次のように題名を整えます。
- 問い合わせ時の表現や現場で使われる呼び方を拾う
- 記事が何の判断や作業に使えるかを題名で示す
呼び名が複数ある場合や、似た記事が並ぶ場合は、次のようにします。
- 複数の呼び名で表す対象 ── 題名に主な呼び方を置き、本文やタグに関連語を加えます
- 検索結果に似た記事が並ぶとき ── それぞれの対象や用途の違いを題名と冒頭で示します。例えば、申請前の確認手順と申請後の修正手順が別なら、その違いが記事を開く前に分かるようにします
題名を変えた後は、最初に見つからなかった利用者の検索語で再び探し、目的の記事を選べるかを確かめます。
- 結果に出ない ── 検索対象となる記載や分類を確認します
- 結果には出るが選ばれない ── 題名の用途表示を見直します
カテゴリとタグの役割を分ける
カテゴリは情報を大きく分ける棚として使い、タグは記事を横断して探すための語として使います。どちらにも同じ分類を重ねると、入力する側も探す側も使い分けに迷います。
- カテゴリ ── 業務やテーマのまとまりを表します
- タグ ── 対象製品、業務上の状態、関連する質問などを補助的に示します
「営業」「セールス」のような同義語が混在する場合は、標準表記を決め、追加や変更の担当者を明らかにします。
分類を変えるか迷ったときは、次の点を確かめます。
- 利用者が最初に選ぶ業務の入口として使えるか
- 複数のカテゴリをまたぐ探し方をタグで補えるか
記事の置き場所を変更する前には、利用者が現在どの入口から来ているかを確認し、その入口からも記事へ進めるようにします。
分類を整えた後も見つからなければ、題名や本文中の言葉を再確認します。
よく使う記事へ到達する道筋をつくる
利用頻度の高い手順や、問い合わせで繰り返し案内する記事には、利用する業務の入口からたどれるリンクを置きます。重要な情報をトップページに並べる場合は、掲載の基準と見直しの担当も決めます。
検索で見つからない記事があるときは、利用者が使った検索語を確認し、題名や本文、タグに不足がないかを調べます。
- 検索結果には出るのに開かれない ── 題名だけで用途が伝わるかを確認します
- 開いても必要な箇所に到達しにくい ── 別の目的の情報が記事内に混在していないか調べます
記事を分ける場合は、これまでの入口から各記事へ進めるよう参照先も整えます。
変更後は、記事の場所を知っている担当者ではなく、実際に探していた利用者に同じ作業を試してもらい、目的の箇所まで進めるか確認します。
情報の鮮度と信頼性を保つ運用をつくる
手順が変わっても記事が更新されなければ、利用者はWikiを信用しなくなります。内容を確認する担当を置くだけでなく、次を決めます。
- 変更を知った人から担当へ伝わる経路
- 確認に使う情報
- 更新が完了したと判断する条件
記事ごとにオーナーと見直し条件を決める
オーナーは、記事の内容が現在の業務に合っているかを確認し、変更があれば修正を調整する担当者です。
記事を書いた人と同じとは限らないため、役割として割り当てます。
記事には、内容を確認する担当、最後に確認した時期、見直しが必要になる条件を記録します。条件は、変更を知る人が判断できる形にします。例は次のとおりです。
- 「手順の決定が変わったとき」
- 「記事が説明する製品の仕様が変わったとき」
- 「利用者から内容の相違が報告されたとき」
変更が起きたら、オーナーは該当記事だけでなく、そこから案内している記事にも影響があるかを調べます。
- 影響する記事が分からない ── 利用者から寄せられた質問や、記事が参照している手順からたどります
- 確認が終わるまで判断に使えない箇所がある ── その範囲と確認先を利用者に分かるようにします
更新・レビュー・アーカイブを一つの循環にする
記事の運用は、作成して終わりではありません。変更を見つけた人からオーナーへ連絡し、現行の業務と照らして内容を確認します。
更新する場合は変更点と適用範囲を示し、利用を終える場合は次に参照すべき情報を決めます。
| 状態 | 担当者の対応 | 利用者に伝えること |
|---|---|---|
| 新規作成 | テンプレートに沿って内容を記録する | 記事の対象と用途 |
| 内容の確認 | オーナーが業務との一致を確認する | 確認した時期と担当 |
| 変更の反映 | 変更点と適用範囲を更新する | 何が変わったか |
| 利用終了 | 現行の記事へのリンクや整理方法を決める | 参照すべき現行情報 |
削除やアーカイブの判断を執筆者だけに任せないことも大切です。
- 過去の判断を残す必要があるかを確認する
- 利用者が古い記事にたどり着いた場合には、現行の手順へ移れる案内を設ける
どの記事が現行か決められない場合は、先に業務上の判断を確認します。
更新を終える前には、次を確かめます。
- 変更を求めた人が問題の箇所を確認できるか
- 旧記事から現行記事へ進めるか
手順自体が未確定なら、記事の表現だけを直して完了とはせず、責任者の判断が必要な点を残します。
内容の信頼性を個人の記憶に依存させない
記事の正しさを詳しい人の記憶だけに頼ると、その人が異動した後に確認できなくなることがあります。
- 手順の根拠 ── 手順の根拠となる業務上の決定や関連文書がある場合は、Wikiから参照できる形にし、更新時に一緒に確かめます
- 修正依頼の入口 ── 記事に誤りを見つけた人が修正を依頼できる入口も用意します。依頼には、該当箇所、困った業務、確認したい点を残します
オーナーは現行の手順と照らして反映するかを決め、保留する場合も理由を伝えます。
- 同じ指摘が続く ── 記事の説明だけでなく、参照している業務手順そのものに確認が必要かを検討します
- 異なる担当者から異なる回答が出る ── どちらかを記事に採用する前に、判断を担う責任者と現行の根拠を確認します
使いやすさと組織の推進を両立する
Wikiの操作が難しい、記事の書き方が分からないといった負担は、利用の障壁になります。
実際の記事を使って、書く人がどこで迷い、読む人がどこで探すのをやめるかを確認します。その結果に応じて、次を調整します。
- テンプレート
- 入口
- 担当者の支援方法
小さな業務範囲から始めて利用者の声を集める
いきなり全社の情報を移すと、分類や権限、更新責任の調整が複雑になります。まずは繰り返し発生する質問や、引き継ぎで困りやすい手順など、改善対象を絞って運用を始めます。
対象を選ぶ際は、次を確かめます。
- 質問した人と回答した人の双方に協力してもらえる業務か
- 現行手順を確認できる責任者がいるか
責任者が決まらない業務は、記事を増やす前に判断の所在を明らかにします。
運用中は、次を記録します。
- 記事が書きにくかった点
- 検索で迷った言葉
- 古くなった情報
テンプレートや分類を直した後、同じ業務で書く・探す・更新する流れを確かめます。
次の状態になったら、対象部門や記事の種類を広げます。
- 記事の作成が止まらない
- 別の利用者も必要な情報を見つけて使える
- 変更時の連絡先が分かる
いずれかが止まるなら、対象を増やす前にその工程を直します。
操作説明と実際の記事作成を一緒に行う
説明会で機能を案内するだけでは、社員が自分の業務でどう使うかまで伝わりにくいものです。操作を学ぶ場で、参加者が実際に使う記事を作成し、別の利用者がその記事を探して手順を確認できるか試します。
次の内容を聞き、書き方の説明が必要なのか、題名や記事の内容を直すべきなのかを分けます。
- 作成者 ── 何を書くか迷った項目を残してもらいます
- 利用者 ── 最初に使った検索語、選んだ記事、読んだ後に確認したくなった点を聞きます
部門ごとに相談できる担当者を置く場合は、投稿を代行する役にせず、利用者が自分で書き、探し、更新できるよう支援する役割を明確にします。
支援担当に作業が集中する状態になったら、何を毎回説明しているかを確認します。
- 同じ項目で書き手が迷う ── テンプレートを見直します
- 同じ入口で読み手が迷う ── 案内を見直します
経営層と管理者が利用の前提を示す
Wikiの利用を現場に求めるなら、管理者や経営層も共通の情報基盤を参照し、方針や手順を記事として共有します。
会議や業務連絡でWikiを参照先として使うと、社員はどの情報を記事で確認するか判断しやすくなります。
- 参照を求めるとき ── 記事を参照するよう求めるだけでなく、記事の説明が現場の判断に足りなかったときの連絡先も示します
- 管理者が別の資料や口頭説明を使った場合 ── その理由を確かめます。Wikiに載せるべき内容が不足しているのか、別の保管先で扱う情報なのかによって、対応が変わるためです
利用状況を見る際は、閲覧や投稿の数だけでなく、どの業務で記事が参照され、どの質問には記事が使われなかったかも確認します。
同じ質問が続くなら、質問した人に次のどれかを聞き、該当する工程を見直します。
- 記事の存在を知らなかった
- 見つけられなかった
- 読んでも判断できなかった
HubSpotのナレッジベースを顧客情報の流れに結び付ける
顧客対応で得た知識を次の対応に使うには、顧客ごとの経緯を残す場所と、再利用できる回答を置く場所の役割を決める必要があります。
ここでは、記事を読む相手と扱う情報を先に分け、HubSpotのナレッジベースを検討する際に確認したい利用条件と公開範囲を整理します。
顧客対応の知識をCRMの業務で活用する
HubSpotのナレッジベースを検討するときは、まず記事を誰に読ませたいかを決めます。顧客向けの回答、担当者が参照する手順、個別の顧客記録では、必要な内容と閲覧者が異なります。
次のような役割分担が考えられます。
- CRMの記録 ── 顧客の状況や対応履歴を確認します
- 記事 ── 複数の対応で使える説明を整えます
例えば、問い合わせへの回答を記事にする前に、顧客固有の経緯と、別の対応でも使える説明を分けます。固有の条件を除くと回答が成り立たない場合は、共通記事にする範囲を再検討します。
担当者が対応中に記事を参照する運用なら、次まで決めます。
- どの場面で探すか
- 回答後に不足を誰へ伝えるか
記事を参照しても顧客ごとの判断が必要な場合は、CRMの記録で確認する事項と、記事から得る共通の説明を担当者が区別できるようにします。
以下の画面は、HubSpotの取引画面からNotionページを閲覧するデモ表示です。ページ内の案件概要などは画面例であり、実顧客の事実として引用しません。顧客記録を確認する場面で、参照先とその用途を担当者にどう示すかを考える例としてご覧ください。
機能の利用条件と公開範囲を確認する
HubSpotのナレッジベースを利用する場合は、予定しているプランで必要な運用ができるか、記事を置く前に確認します。
- 利用条件 ── 作成できる範囲や利用条件はナレッジベースの記事を作成、カスタマイズするで確認し、実際に扱う情報と照らし合わせます
- 公開範囲 ── 顧客が読む記事と、社内だけで扱う手順を先に分けます。設定の確認にはナレッジベースの設定をカスタマイズするを参照し、想定する閲覧者が記事を開けるか、想定しない閲覧者には見えないかを確かめます
判断は、次の順で進めます。
- 記事ごとに用途と閲覧者を記す
- 予定している利用条件でその閲覧範囲を扱えるかを確認する
- 閲覧者からの見え方を確かめる
必要な閲覧範囲を設定できない情報は、記事を置く場所から見直します。用途や閲覧者が決まっていない情報は、設定を選ぶ前に整理します。
一元管理・自動化・可視化を段階的に設計する
CRMとの連携を検討するときは、情報を集めることだけでなく、誰が更新し、どの業務で使い、どう改善するかを設計します。
コンタクトや会社の情報、対応履歴、チケット、ナレッジ記事の役割を整理し、担当者が同じ内容を繰り返し入力している場面を確認します。次の順に進めます。
- 一つの対応を追い、顧客固有の記録、共通の説明、記事の修正依頼がそれぞれどこに残るかを確認する
- 担当者が回答を探すときの入口と、記事が不足していたときの連絡先を決める
- この流れを実際の対応で確かめてから、通知や作業の自動化が必要かを判断する
記事の見直し依頼や担当者への通知を運用に組み込む場合は、何が変わったときに誰が判断するかを先に決めます。
利用状況を確認するときも、記事が開かれたかだけでなく、担当者が回答や引き継ぎに使えたかを確かめます。
手作業が残るなら、その作業が内容を確認するために必要なのか、同じ情報を転記しているだけなのかを分けます。
- 内容を確認するために必要な作業 ── 担当を明確にします
- 同じ情報を転記しているだけの作業 ── 元となる情報と更新先を確かめてから改善方法を選びます
定着に向けた進め方と運用上の注意点
社内Wikiの改善は、業務で繰り返し発生する情報の受け渡しを確認するところから始めます。
- 対象業務を選ぶ
- 実際の質問から記事の有無を調べる
- 別の利用者が記事を探して使えるか試す
書く・探す・使う・直す工程で見つかった課題を修正し、同じ業務で確かめてから範囲を広げます。
現状の情報の流れを確認する
最初に、よくある質問や繰り返し行う業務手順を選び、現在どこに情報が置かれているかを確認します。
個別ファイル、チャット、担当者の記憶に分かれている場合は、どの情報を共通の記事として整えると再利用しやすいかを決めます。
- 情報を探す人にも聞く ── 記事を作る人だけでなく、実際に情報を探す人にも、いつ、何を知りたくなり、どの言葉で探したかを聞きます
- 並べて見る ── 回答者が参照した情報と、質問者が探した場所を並べると、記録と検索のどちらに課題があるか分かります
この段階では、次を一緒に記録します。
- 質問文
- 回答の根拠
- 現在の保管先
- 利用者
- 内容を確認できる人
必要な情報と利用者が明確になったら記事の対象と用途を決めます。現行の手順が担当者によって異なる場合は、執筆前に業務上の判断をそろえます。
小さく試し、運用の詰まりを直す
対象業務を決めたら、記事テンプレート、分類、オーナー、更新のきっかけを用意して運用します。
書いた記事を別の利用者に普段の言葉で探して使ってもらい、検索した言葉、迷った箇所、内容だけでは判断できなかった点を記録します。
| 段階 | 実施すること | 次へ進む目安 |
|---|---|---|
| 対象を決める | 繰り返し発生する質問や手順を選ぶ | 記録する情報と利用者が明確になっている |
| 運用を設計する | テンプレート、分類、オーナーを決める | 作成・検索・更新の担当が決まっている |
| 小さく試す | 実際の業務で記事を作成して利用する | 書き方や検索で生じた課題を記録できている |
| 見直して広げる | 課題を修正し、対象を追加する | 担当者に過度な負担がなく運用できている |
試した結果は、次のように見直します。
- 記事が作られない ── 作成依頼が発生する業務の節目と、依頼を受け取る担当を確認します
- 記事があるのに見つからない ── 利用者の検索語で再現し、結果に出ない場合は検索に使う言葉や分類を、結果から選ばれない場合は題名を見直します
- 見つかっても使えない ── 対象条件や手順の不足か、責任者による判断が必要な事項かを分けます
修正した点を同じ業務で確かめます。次の状態になってから対象を追加します。
- 別の利用者が記事を探し、必要な作業または確認先を選べる
- 変更が生じた際の連絡先も分かる
いずれかが確認できなければ、対象を広げる前に該当する工程へ戻ります。
数値目標を置く場合は、行動につながる指標を選ぶ
利用率や投稿数を測る場合は、その数値が何を改善するためのものかを先に決めます。投稿数だけが増えても、記事が探されず使われなければ、定着の判断にはつながりません。
次の点を確認します。
- 繰り返し質問された内容に記事で回答できたか
- 見つからなかったときにどの言葉で検索したか
- 手順変更後に古い記事が参照されていないか
記録する項目は、質問の内容、記事の有無、検索時に止まった場所、利用後に残った疑問、修正担当といった、次の行動に結び付くものから選びます。
比較するときは、同じ業務の質問について、修正前後で利用者がどこで止まったかを見ます。
- 記事がなければ ── 作成につなげます
- 見つからなければ ── 題名や入口の変更につなげます
- 古い内容が残っていれば ── オーナーによる確認につなげます
記録を見ても担当者が次の行動を選べない場合は、目標値を増やす前に集める項目を見直します。
ツールの機能と組織の運用を分けて考える
検索機能やAIを追加する前に、記事の重複、題名の分かりにくさ、更新責任の不明確さが利用を妨げていないかを確かめます。実際の検索語と記事を照らし、入口や内容を直した後にも残る課題から、必要な機能を判断します。
保管先を比較する際は、情報ごとに次を並べます。
- 「何の判断に使うか」
- 「誰が読むか」
- 「誰が更新を決めるか」
顧客向けの公開情報、社内だけで参照する情報、権限を限定する情報では、求める閲覧範囲が異なります。それぞれについて、候補となる保管先で次を確かめます。
- 必要な閲覧範囲を扱えるか
- 利用者が業務中にたどり着けるか
- 変更をオーナーへ伝えられるか
確かめた結果は次のように扱います。
- 閲覧範囲が合わない ── 保管先を見直します
- 入口だけが問題 ── 案内や題名を見直します
- 更新責任が決まらない ── 移行より先に担当を決めます
情報の用途と閲覧者を説明できない場合は、移す範囲を決める前に整理します。
よくある質問
社内Wikiの運用では、記事を誰が書くか、見つからないときに何を直すか、古い記事をどう扱うかが迷いやすい点です。ここでは、実際の質問を使った原因の切り分けと、担当者が次に取る行動を説明します。
社内Wikiが定着しない場合、最初に何を見直せばよいですか？
繰り返された質問や、探せなかった手順を取り上げ、回答となる記事があるかを確認します。記事がなければ、回答者が使った情報と、記録する業務の節目を確認して担当を決めます。記事があるのに見つからなければ、利用者が入力した検索語で探し、結果に出ないのか、出ても選ばれないのかを分けます。見つかっても使えなければ、判断に足りない内容と、それを確認するオーナーを特定します。直した後は同じ質問を別の利用者に試してもらいます。
社員に記事を書いてもらうにはどうすればよいですか？
問い合わせ対応やプロジェクト完了など、知識が生まれる業務の節目に、既存記事の参照・修正・新規作成のどれが必要かを確認する工程を置きます。担当者が書き始められない場合は、何を残すか示すテンプレートと、内容を判断する確認者を見直します。記事を書く作業と確認する役割を業務として決め、完了時に参照先または修正依頼が残っているか確かめます。依頼だけが残る場合は、受け取るオーナーと反映の完了条件を確認します。
古くなった記事は削除したほうがよいですか？
まず現行の手順と、古い記事を残す必要があるかをオーナーに確認します。置き換える記事があるなら、利用者を現行記事へ案内します。経緯を残す必要がある場合は、古い内容を現行手順と誤認しない表示やアーカイブ方法を決めてから整理します。現行の手順が決まっていない場合は、記事の整理より先に業務の責任者へ確認します。
HubSpotのナレッジベースを社内Wikiに使えますか？
扱う情報の用途と閲覧者が、利用できる設定に合うかを確認して判断します。顧客向けの回答と社内手順を分け、予定しているプランの利用条件、公開範囲、閲覧者からの見え方を確かめます。必要な閲覧範囲に合わない情報は、保管場所も含めて検討します。用途や閲覧者が決まっていない場合は、設定を選ぶ前にその情報を整理します。
投稿数や利用率を目標にすれば定着しますか？
投稿数や利用率だけでは、記事が業務で役立っているかまでは分かりません。実際の質問について、検索で見つかったか、回答に使えたか、変更が必要な記事を直せたかも確認します。その結果を見て、記事の作成、題名や入口の変更、更新担当の確認のどれを行うか決めます。修正後は同じ業務で利用者が止まる場所を再確認します。結果から次の行動を選べない指標なら、測る項目を見直します。
まとめ
社内Wikiが定着しない原因は、知識を記録する節目がない、利用者の言葉で記事を探せない、内容を確認する担当がいない、といった業務の流れの中にあります。まず実際に繰り返される質問や手順を選び、利用者がどこで止まったかを確かめます。
- 情報がどこにあり、誰がいつ、何を判断するために使うかを確認します。
- 記録する担当、記事の題名と入口、内容のオーナーと見直し条件を決めます。
- 別の利用者が実際の業務で記事を探して使い、止まった工程を直してから対象を広げます。
記事が見つかっても判断できなければ内容と確認先へ、必要な閲覧範囲を扱えなければ保管先へ戻って見直します。書く・探す・使う・直す流れを対象業務で確かめられたら、次の業務にも適用するかを判断します。
企業様によって最適な形は異なります。CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
