%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}
この記事の結論
Notionの社内Wikiは、記事の置き場所を決めるだけでは使える状態になりません。誰がどの場面で探し、どの記述を現在の手順として使い、業務が変わったら誰が直すかを一続きで設計します。
Notionの社内Wikiは、記事の置き場所を決めるだけでは使える状態になりません。誰がどの場面で探し、どの記述を現在の手順として使い、業務が変わったら誰が直すかを一続きで設計します。
「必要な手順がどこにあるのか、毎回人に聞かないとわからない」「スプレッドシートや個人フォルダに資料が分かれ、同じ情報を何度も更新している」「Wikiを作ったものの、古い説明と新しい説明が並んでいて、どれを使うべきか迷う」
こうした場合、最初に確認したいのはページ構造ではなく、対象業務と資料の正本です。正本とは、その業務で基準として参照し、変更を反映する資料を指します。例えば「商談前に必要な資料を確認する」という業務なら、利用者が何を手がかりに探すか、資料の内容を誰が確定するか、何を確認できたら次の作業へ進めるかを整理します。
資料同士が食い違うなら、現在の手順を担当者に確認してから記事にします。内容は確かでも見つけられないなら、記事を増やす前に入口や分類を見直します。この記事では、対象業務を選び、構造と権限を決め、記事を試し、更新につなげるまでの判断方法を解説します。
この記事でわかること
社内Wikiの構築や見直しを担当する方に向けて、対象業務の選定から公開後の改善までを順に説明します。まず自社で扱う業務を思い浮かべ、利用者が記事を探す場面と、手順の内容を確認できる担当者を確かめながら読み進めてください。
- Wikiの構造の選び方 — データベース型とページツリー型を、利用者の探し方、記事の置き方、変更時の直しやすさで比較します。
- 権限とオーナーの設計 — 資料の用途から公開範囲を決め、閲覧・編集・内容確認の担当を分けて確かめます。
- テンプレートと運用ルール — 手順の適用条件と完了条件をそろえ、業務変更をどの記事の見直しにつなげるか決めます。
- AI検索とCRM連携の判断方法 — AIの回答は対応する記事と照合し、CRM連携は顧客対応中に必要な情報と参照・更新の要件から検討します。
読み終えたら、対象業務について「正本を決められるか」「利用者が探して使えるか」「変更時に直す人が決まっているか」を確かめられます。決まっていない点があれば、該当する節の確認手順から着手してください。
社内Wikiをページ置き場で終わらせない考え方
社内Wikiは、必要な人が業務の場面に応じて情報を見つけ、自分に適用できる内容か判断できる場所として設計します。
既存資料を集める前に、どの仕事の判断や作業を支えるのかを定めます。正本と内容の確認担当が決まってから、記事の配置を考えます。
読者の業務から対象範囲を決める
まず、Wikiに載せる情報を「誰が、どの業務の、どの場面で使うか」で整理します。
次の場面では、探す手がかりも、手順の内容を確認する担当も異なります。
- 営業担当が商談前に資料を確認する場面
- 新入社員が申請を進める場面
対象を決める際は、繰り返し質問される手順や、担当変更時に確認先がわからなくなる業務を洗い出します。業務ごとに、次の内容を書き出します。
- 作業を始めるきっかけ
- 利用者が最初に知っている言葉
- 作業中に判断が分かれる点
- 完了したと判断する材料
担当者に内容を確認でき、利用者が実際に試せる業務から着手します。
例えば「商談前に必要な資料を確認する」なら、次の点を確かめます。
- 探し方 ── 利用者は商談準備という業務名で探すのか、資料名で探すのか
- 分岐条件 ── 必要な資料が商談の種類によって変わるなら、その分岐条件を担当者に確認する
- 選ぶ条件 ── 記事を読んでも必要な資料を選べない場合は、資料の一覧を増やすだけでなく、選ぶ条件を本文に加える
この業務では、着手前に確認する内容を次のように分けておくと、記事を試す際にどこで止まったかを特定できます。
- 商談の条件
- 参照する資料
- 選んだ理由
- 判断に迷ったときの確認先
資料名を答えられても、別の条件で使う資料との違いを説明できないなら、選択の根拠が記事に足りていません。担当者と条件を確定し、その違いを読者が見つけられる位置に記します。
「営業業務全般」のような範囲では、記事に何を含めるか判断しにくくなります。利用者、利用場面、開始条件、完了条件を説明できる大きさに区切ります。どれかが決まらない資料は、掲載先を決める前に関係者へ確認します。
表計算や口頭確認に残る重複を見つける
既存資料を移す前に、同じ業務の説明がどこにあるかを確認します。資料ごとに、次の内容を記録します。
- 何を説明しているか
- 誰が内容を確かめられるか
- 現在どこから参照されているか
資料名だけで重複を判断せず、対象者、適用条件、作業手順を比べます。比べた結果によって、扱いを次のように分けます。
| 比べた結果 | 扱い |
|---|---|
| 記述が一致し、同じ条件で使う | 共通手順を基準ページにまとめ、案内が必要な場所からリンクする |
| 同じ作業でも部署によって条件が異なる | 共通部分と部署固有の部分を分け、どちらが適用されるかを示す |
| 記述が食い違う | 更新日の新しさだけで決めず、業務の担当者に現在使う手順を確認する |
照合の際は、資料ごとに記述を次のように分けます。
- 一致する記述
- 条件が異なる記述
- 担当者の確認が必要な記述
例えば同じ資料を案内していても、利用できる条件が異なれば単純に統合できません。条件が確定するまで、利用者にどちらかを選ばせる記事にはしないことが判断の分かれ目です。
正本を決めたら、変更をどこへ反映するかも決めます。重複する資料を残す場合は正本への参照を明示し、その資料自体を更新する必要があるのか、正本を直せばよいのかを編集者が判断できる状態にします。食い違いが解消していない記述は、確定した手順として掲載しません。
仕事の流れのどこで使うかを決める
手順書は、業務を始める場面から見つけられるようにします。利用者に、作業を始める場所と、業務名・部門名・担当者名などのうち何を手がかりに探すかを確認します。その手がかりに合わせ、トップページ、業務別ページ、記事一覧のどこを入口にするか決めます。
入口を決めたら、記事名を知っている人だけでなく、その業務を始める人に探してもらいます。つまずいた場所に応じて、次を見直します。
- 入口が見つからない ── 案内の言葉を見直す
- 入口から目的の記事へ進めない ── 分類やリンクを見直す
- 記事に着いても自分に適用できるかわからない ── 対象者と前提条件を冒頭に補う
試すときは、次の順で進めます。
- 試す人には記事名や配置先を先に伝えず、普段の作業を始めるときの言葉から探してもらう
- 見つけた後は「自分が使う手順だと判断した記述」と「次に行う作業」を示してもらう
目的の記事に着いても根拠を示せない場合は、検索や分類だけでなく、記事本文の対象範囲も見直します。
顧客対応で使う情報は、社内共通の手順と顧客ごとの記録を分けて考えます。
| 状況 | 進め方 |
|---|---|
| どの顧客情報を見ているときに、どの社内手順が必要になるかを特定できた場合 | CRMからの参照方法を検討する |
| 利用場面を特定できない段階 | まずWiki内で記事を見つけ、適用条件を判断できるか確かめる |
Notion社内Wikiの構造を選ぶ
記事の置き方は、ページの階層をたどる構成と、データベースの項目で分類する構成から検討します。構造を先に決めるのではなく、対象業務の記事を用意し、利用者が何を手がかりに探すか、新しい記事を置く編集者が配置先を判断できるかを比べます。
データベース型で分類とビューを整える
データベース型では、各記事にカテゴリやタグ、オーナー、更新状態などの項目を設けて整理します。利用者が部門、担当者、状態などの条件から記事を探すなら、必要な項目と一覧の見せ方を決めます。
| 設計項目 | 例 | 運用で決めること |
|---|---|---|
| カテゴリ | 営業、開発、人事 | カテゴリの追加・変更を誰が判断するか |
| タグ | 手順、FAQ、申請 | タグを増やす条件と表記 |
| オーナー | 記事の担当者 | 担当変更時の引き継ぎ方法 |
| 更新状態 | 「公開」「下書き」「要確認」 | 状態を変えるタイミング |
| ビュー | カテゴリ別、更新順 | 利用者が最初に見る一覧 |
最初に利用者が探す記事を挙げ、実際に使った手がかりを確認します。
- 業務名で探せる場合 ── 担当者名やタグを増やす前に記事名と入口を整える
- 別の条件で絞る必要が残る場合 ── その違いを一貫して分類できるなら項目を追加する
例えば同じ「申請」というタグを付けても、利用者が申請前の準備と申請後の確認を区別できなければ、タグだけでは探し方を支えられません。記事名や対象範囲で区別するのか、分類を分けるのかを、利用者が実際に探す言葉から決めます。
編集者によって分類が分かれる場合は、各区分の意味と境界を記し、同じ記事で選び直して確かめます。項目を追加する前には、次の点を確認します。
- 利用者がその項目を手がかりに記事を探すか
- 編集者が値を迷わず選べるか
利用者が使わず、編集者の判断も分かれる項目なら、先に記事名や分類の説明を直します。項目が必要だとわかった場合は、どの記事にどの値を付けるか、境界となる例を管理者と編集者で照合してから広げます。
表のカテゴリ、タグ、更新状態は設計例です。自社で使う名称と意味を決めます。「公開」などの管理用の状態と、実際に誰が閲覧できるかという権限は別々に確認します。
ページツリー型で少数の情報を始める
ページツリー型は、部門や業務ごとに親ページを作り、その下に関連資料を置く構成です。利用者が部門や仕事の順序をたどって探す場合は、親ページの名前と配置先を決めます。
- 名前 ── その下にどの業務があるかを利用者が予想できる名前にする
- 主な入口 ── 例えば部門の名前から探す人と、業務の名前から探す人がいるなら、どちらを主な入口にするかを決め、もう一方からも必要なページへ案内する
- 似た名前の親ページ ── 並ぶ場合は、それぞれに入る記事の違いを説明できるか確かめる
複数部門に関係する手順を各階層へ複製すると、更新先が分かれます。共通手順は基準ページを一つ決め、部門ページからリンクします。部署ごとに異なる部分があるなら、その違いが適用される条件を部門ページに記します。
新しい記事を置くときは、編集者に親ページを選んでもらい、その理由を聞きます。部門名で置く人と業務名で置く人に判断が分かれるなら、どちらを正本の配置先とするか決め、もう一方は案内に使います。
記事を追加する編集者が「どの親ページにも置ける」と迷うなら、階層を増やす前に配置の基準を見直します。利用者が入口を選べ、編集者が配置先を決められることを確かめてから記事を増やします。
方式を業務の探し方から選ぶ
利用者が部門やテーマを順にたどるなら、ページツリー型を検討します。担当者や状態、タグを組み合わせて探すなら、データベース型を検討します。両方の探し方が必要な場合は、トップページで入口を案内し、記事本体を一か所で管理する方法もあります。
| 比較軸 | データベース型 | ページツリー型 |
|---|---|---|
| 向いている探し方 | 条件で絞る、並べ替える | 部門やテーマを順にたどる |
| 初期設計 | プロパティやビューを決める | 親子関係やページ名を決める |
| 部門横断の情報 | 複数のビューから同じ記事を見せやすい | 配置先が曖昧になりやすい |
| 運用での注意 | 項目が増えると入力負荷が上がる | 階層が深くなると見つけにくい |
比較には、同じ業務・記事・利用場面を使い、資料を探す利用者と記事を直す編集者の双方で確認します。
商談前の資料確認では、先に担当者と「どの条件なら、どの資料を参照するか」を決めます。条件が異なる場面も用意し、資料の選択が変わる理由を確認しておきます。
- 利用者 ── 記事の場所を教えず、普段の言葉で資料を探し、自分の条件に合う資料と判断の根拠となる記述を示してもらう
- 編集者 ── 条件の異なる手順が加わったときの配置先と、既存記事の修正箇所を示してもらう
それぞれについて、次の項目を記録します。
- 最初に選んだ入口
- 迷った箇所
- 選んだ記事
- 判断に使った記述
- 編集する場所
所要時間だけで優劣を決めず、選択の根拠と正本の管理先まで照合します。
結果を見直す際は、迷った場所に応じて直す対象を分けます。
| 迷った場所 | 直す対象 |
|---|---|
| 入口を選べない | 案内の言葉を確認する |
| 入口から記事に進めない | 分類やリンクを確認する |
| 記事に着いても別の条件の資料を選んだ | 記事名と対象範囲、本文の分岐条件を確認する |
| 編集者が同じ手順を別の場所へ複製しようとした | 正本の置き場と案内ページの役割を決め直す |
利用者が根拠となる記述を示して手順を選べ、編集者が正本と変更先を説明できたら、その構造で扱う業務を広げます。判断が分かれた場合は該当箇所を直し、同じ利用場面で確かめてから進みます。
この確認で判断できるのは、試した業務で探し方と更新先が通じるかどうかです。実際の利用頻度や業務上の効果は、公開後に質問や利用場面を継続して確認します。
権限とページオーナーを設計する
権限は、情報を閲覧・編集できる人と、内容を確認する人を分けて設計します。まず資料を使う人を特定し、必要な公開範囲を決めます。その後、想定した利用者と編集者が実際にページを扱えるか確認します。
Notionの権限は、ワークスペース、チームスペース、ページ、データベースの単位で設定します。次の表は、メンバー管理とデータベース編集に関する設定例です。前者はワークスペースへの参加、後者は記事の編集に関わるため、対象と担当を分けて確認します。
| レベル | 対象 | 設定内容 |
|---|---|---|
| ワークスペース | メンバー | ワークスペースオーナーまたはメンバーシップ管理者がメンバーを削除できる。出典 |
| データベース | データベース全体 | 「Can edit content」で内部ページの作成・編集とプロパティ値の編集を許可できる。出典 |
「Can edit content」を選ぶ場合も、記事内容を編集する担当と、分類項目やビューの設定を変更する担当を分けて決めます。設定後は権限名だけで判断せず、それぞれの担当者が必要な操作を行えるか確認します。
情報の公開範囲を分類する
業務手順やFAQなど、多くの社員が参照する情報は、対象となる社内メンバーが見つけられる場所に置きます。限定したメンバーだけが扱う情報は、対象者を明確にして閲覧範囲を決めます。
| 情報の種類 | 権限設計の考え方 |
|---|---|
| 全社共通の業務手順 | 社内メンバーが参照できる範囲に置く |
| 部門固有の手順 | 関係部門を中心に閲覧・編集を設定する |
| 限定して扱う資料 | 対象者を明示し、共有範囲を必要な人に絞る |
| 公開前の下書き | 編集者を限定し、公開状態へ移す担当を決める |
分類に迷う場合は、誰がその資料を業務で使うかをオーナーに確認します。共通手順と限定資料が一つの記事に混在するなら、内容を分けてから閲覧範囲を決めます。
共通部分だけで作業できる人と、限定資料も必要な人では、案内すべき次の行動が異なります。
共通手順から限定資料へ案内する場合は、リンク先を開けない利用者の次の行動も記します。別の手順に進むのか、担当者へ依頼するのかを本文で示し、権限の追加が必要かは資料のオーナーが判断します。リンクを置くだけで、必要な人が業務を進められると判断しません。
公開範囲を決める際は、記事本文だけでなく、入口となるページから限定資料の内容が読み取れるかも確認します。共通ページに案内だけを置くのか、内容を含めるのかを分けて判断し、想定した利用者の立場で参照経路をたどります。
閲覧者・編集者・オーナーを分ける
閲覧者・編集者・オーナーの役割を次のように定義し、設定前に記事ごとに担当を決めます。これは社内の運用上の役割です。
| 役割 | 定義 | 記事ごとに決めること |
|---|---|---|
| 閲覧者 | 情報を使う人 | 誰が読むか |
| 編集者 | 記述を更新する人 | 誰が直すか |
| オーナー | 内容と見直しの責任を持つ人 | 内容の正しさを誰が確かめるか |
記事に担当者名を書くことと、実際の閲覧・編集権限を設定することは分けて確認します。
編集者が記述を変更できても業務の判断を確定できない場合は、オーナーへ確認してから公開する流れにします。オーナーが変わる場合は、担当者名と権限の両方を見直します。
権限を設定したら、次の点を確かめます。管理者が開けるという結果だけで公開を判断しません。
- 想定する閲覧者が対象ページを開けるか
- 編集者が必要な更新を行えるか
- 閲覧対象外の人に内容が見えないか
- 閲覧だけを認めた人が意図せず編集できないか
必要な人が開けないなら閲覧範囲を、意図しない編集ができるなら編集範囲を見直します。権限を直した後は、開けなかった人と意図しない操作ができた人の立場で再確認します。
内容について質問を受ける担当者と、担当変更時の引き継ぎ先も記事からわかる状態にしてから公開します。
権限は次の単位で設定します。
- ページ ── ページごとに、利用者の役割に応じて閲覧・コメント・編集の権限を設定する
- データベース ── 閲覧者と編集者で記事の作成・編集可否を分け、オーナーが設定と内容を確認する
Notion Wikiの検証機能を更新管理に使う
Notion Wikiの検証機能を利用する場合は、表示を付ける前に、社内で何を確認したら「検証済み」と扱うか決めます。例えば、オーナーが現在の業務と記事を照合し、対象者、前提条件、作業手順、完了条件を確認する流れです。
照合では、手順を最初から読み直すだけでなく、判断が分かれる箇所を確かめます。
- 前提条件を満たさない人はどこへ進むか
- 例外に当たる場合は誰が判断するか
- 完了を何で確認するか
不明な記述があれば業務の担当者に確認し、修正後は前後の手順や関連ページとの整合も確かめます。
確認の記録には、次の内容を対応させます。
- 対象の記事
- 照合した業務の条件
- 確認した担当者と時点
- 残った確認事項
例えば共通手順だけを確認したなら、部署固有の条件まで確認したことにはしません。残った確認事項が作業の判断に関わる場合は、担当者が確定するまで、その箇所を検証済みの手順として案内しないようにします。
照合を終えてから、確認した担当者と時点を記録します。表示だけで、すべての読者や利用場面に内容が適用できるとは判断しません。手順の前提条件と対象範囲は本文にも明記します。業務変更を把握した人がオーナーへ伝える経路を決め、変更があったら関係する記事を照合します。内容確認とその記録を続けられることを、運用開始の条件にします。
テンプレートで記事の品質をそろえる
テンプレートは、書き手が必要な情報をそろえ、読者が手順の適用条件と完了条件を判断するための枠組みです。欄を増やす前に、その情報が読者の作業や編集者の見直しに必要かを確認します。
業務手順書の基本項目を決める
手順書には、目的、対象者、開始前の条件、作業の順序、完了の判断方法、問い合わせ先を含めます。読者が自分に適用できるかを先に判断できるよう、前提条件は作業手順の前に置きます。
| 項目 | 記載する内容 |
|---|---|
| 目的・対象 | 何の業務で、誰が使うか |
| 前提条件 | 必要なアカウントや事前作業 |
| 手順 | 作業の順番と確認方法 |
| 完了条件 | 何を確認できたら作業を終えるか |
| オーナー・更新情報 | 内容を確認する担当と更新時点 |
| 関連ページ | 前提知識や次に行う業務 |
手順の各段階では、読者が何を見て次の操作を選ぶかを書きます。
- 条件によって進み方が変わる場合 ── 「該当する場合に行うこと」と「該当しない場合に進む先」を分ける
- 完了条件 ── 「確認する」とだけ書かず、何が確認できれば終えられるかを示す
商談前の資料確認を手順書にするなら、次の流れにします。
- 商談の条件を確認する
- 条件に対応する資料を選ぶ
- 資料が現在使うものか担当者に確認する必要がある場合を示す
- 選択を終えたと判断する材料を書く
資料の選択条件を確定できない段階では、資料名だけを並べて公開せず、担当者への確認先を示します。
公開前に、次の点を見ます。
- 対象者が前提条件を満たせるか
- 手順どおりに作業できるか
- 完了を確認できるか
途中で判断が止まるなら、その箇所に分岐条件や問い合わせ先を補います。
前提条件を満たさない場合の進み方も必要です。準備の手順を案内できるなら関連ページへつなぎ、担当者の判断が必要なら問い合わせ先を示します。読者が推測で進まなくて済むことを確認してから公開します。
テンプレートを用途別に分ける
手順書、FAQ、議事録、プロジェクト概要では、読者が知りたいことが異なります。まず共通して必要なオーナーや更新情報を定め、用途に応じて本文の項目を分けます。
種類を増やすか迷ったら、既存の型では不要な欄が繰り返し残るか、必要な情報が抜けるかを確認します。用途の違いを説明できる場合に専用の型を検討し、書き手が選べるようにします。
| 用途の例 | 記載する内容 | 本文だけで足りない場合 |
|---|---|---|
| FAQ | 回答が当てはまる条件と詳しい手順への案内 | 短い回答だけでは作業を終えられない場合は、正本となる手順書へ案内する |
| 議事録 | 決定事項と未決事項 | 未決事項を確定した業務ルールとして使う必要が生じた場合は、担当者の決定を確認してから基準ページに反映する |
違いを説明できない型は増やさず、既存の型の説明や記入例を見直します。型を選ぶ書き手が迷うなら、次の点を確認します。
- 読者がこの記事だけで作業を終えるか
- 判断の経緯を残すか
- 短い回答から別の基準ページへ案内するか
目的に合う型を選べても必要な条件が抜けるなら、その型の記入例を直してから新しい型の追加を考えます。
記入例より更新の責任を明確にする
オーナー欄を置くだけでは、業務が変わったときに誰が直すか判断できません。次の内容を決めます。
- 見直しのきっかけ
- 変更を知った人からの連絡先
- 担当変更時の引き継ぎ先
見直しのきっかけには、作業手順の変更だけでなく、対象者や前提条件の変更、記事を読んだ人からの質問も含めて考えます。連絡を受けたオーナーは、該当記事だけでなく、そこへ案内するページや同じ手順を参照する記事も確認します。
実務で使われない項目が残るなら、読者の判断に必要かを確かめます。必要なら記入例を具体化し、不要なら型から外します。記入例には確認した業務内容を使い、未確認の条件を標準手順として示さないようにします。
担当変更時は名前の置き換えだけで終えず、引き継ぐ記事、確認が必要な箇所、変更の連絡先を共有します。新しい担当者が内容を確認し、問い合わせを受けられる状態になってから引き継ぎを完了します。
更新と定着を運用ルールにする
公開後は、業務変更を記事に反映し、読者が迷った箇所を改善します。誰が変更を受け取り、どのページを直し、どう確認して公開するかを決めておきます。
命名とカテゴリの追加方法を決める
ページ名は、内容を開く前に何がわかるかを示します。例えば「経費を精算する」「VPNに接続する」のように、動作と目的が伝わる表現にします。対象者や条件によって手順が異なる場合は、その違いもページ名や冒頭に示します。
新しいカテゴリが必要になったら、Wiki管理者が既存カテゴリで表現できるか確認します。
- 記事を置く場所に迷うだけの場合 ── 分類の説明を補う方法もある
- 利用者が異なる入口から探しており、既存分類では目的の記事へ進みにくい場合 ── 追加を検討する
追加後は、似た名称の区分が並んでいないか、既存記事の配置に矛盾がないか確認します。
記事名を知らない利用者が、普段使う業務名から探せるかも確かめます。呼び方の違いが原因なら案内文を補い、入口の区切りが業務の探し方に合っていないならカテゴリを見直します。変更後は、迷った利用者に同じ業務から探してもらい、目的の記事とその適用条件を示せるか確認します。
業務変更とレビューを結びつける
手順が変わったら、変更を知った人から記事のオーナーへ伝えます。オーナーは実際の手順と記事を照合し、対象者、開始前の条件、作業手順、完了条件のどこが変わったかを整理します。一部の変更でも、前後の手順や関連ページに矛盾がないか確かめてから公開します。
例えば、状況に応じて次を確認します。
| 状況 | 確認する対象 |
|---|---|
| 開始前に確認する内容 | その条件を記載した記事に加え、記事へ案内するページ |
| 完了条件 | 後続の作業が古い条件を前提にしていないか |
| 複数の記事が同じ手順を参照する場合 | 基準ページとリンク先の案内 |
Notion Wikiの検証機能を使う場合も、表示の更新だけで確認を終えず、内容を照合します。
変更の連絡を受けてからは、次の順で進めます。
- オーナーは影響する記事と案内ページを特定し、内容を確定できる担当者を確認する
- 担当者が内容を確定したら基準ページを直し、関連ページの案内と矛盾がないか確認する
- 利用者が変更後の条件で手順を選べることを確かめてから、確認状況を記録する
変更内容を確定できないなら、未確認の箇所と問い合わせ先を記事に明示します。その箇所が作業の判断に関わる場合は、担当者が内容を確定するまで、その記述を確定した手順として案内しません。
使われ方を見てルールを調整する
記事の作成数だけでなく、次の点を確認します。
- 質問が繰り返される業務
- 検索しても見つけにくい情報
- 更新担当が不明な記事
利用者には、探す途中で迷ったのか、記事を読んだ後に判断が止まったのかを聞きます。
| 状況 | 見直す対象 |
|---|---|
| 入口で迷う | 案内や分類を見直す |
| 記事を見つけても質問が続く | 対象範囲、前提条件、分岐、完了条件を質問内容と照合する |
| 担当が決まらず更新が滞る | オーナーの割り当てと引き継ぎ方法を調整する |
質問を記録するときは、次の内容を残します。
- 利用者が使った言葉
- たどった入口
- 開いた記事
- 判断が止まった箇所
同じ質問でも、記事に着けなかった人と、記事を読んで条件を選べなかった人では直す場所が違います。どちらかを確認してから修正し、変更の理由をオーナーと共有します。
変更後は、同じ業務を想定して利用者に記事を探してもらい、記述に沿って進めるか確かめます。見つけられても途中で担当者の説明が必要になったなら、止まった箇所を本文に反映します。迷っていた箇所で判断できるようになったことを確認してから、同じルールをほかの記事にも適用します。
AI検索とCRM連携を目的別に検討する
AI検索を検討する前に、Wikiの記事そのものが現在の手順を示しているか確認します。CRM連携では、顧客対応のどの場面で社内記事が必要かを特定します。
それぞれの利用場面と参照する情報の範囲を決め、担当者が内容を確かめられることを導入判断の条件にします。
AI検索の回答を参照元ページで確かめる
Notion AIでWikiの情報を探すときは、回答に対応する記事をWiki内で特定し、対象範囲・前提条件・更新状況を確認します。記事の該当箇所と回答を照合し、手順に必要な条件や例外が抜けていないか確かめます。
- 更新状況が分からない場合 ── 記事の管理者や担当者に確認してから判断する
- 対応する記事を特定できない場合や記載が食い違う場合 ── 回答だけで作業を確定しない
例えば申請手順を尋ねたときは、回答に示された操作だけでなく、基準ページの次の記述を確認します。
- 対象者
- 申請前の条件
- 例外時の連絡先
回答が共通手順を示していても、自分に部署固有の条件が適用されるなら、該当する記述を確かめるまで進めません。どの記事を参照したか特定できなければ、業務名から基準ページを探し、見つからなければオーナーに確認します。
| 状況 | 対応 |
|---|---|
| 必要なページが見つからない | 質問の言葉と記事名・分類を比べる |
| ページは見つかるものの回答に適用条件が示されない | 記事本文で条件を確認する。本文にも条件がなければオーナーへ確認し、確認できた内容を記事へ反映する |
| 記事の内容が古い | 回答の表現を直す前に正本を見直す |
確認結果は、次に分けて扱います。
- 回答に対応する記事を特定できたか
- 利用者の条件に合う記述を示せたか
- 例外や完了条件が抜けていないか
参照先が特定できても条件が抜けていれば、回答をそのまま手順として使わず、基準ページで判断します。基準ページにも条件がないなら、業務担当者の確認後に記事を直し、同じ質問で再確認します。
業務ルールの変更判断や顧客へ送る最終案内は、担当者が行います。
AI検索に使う情報の範囲を定める
利用者が知りたい内容と、その判断に使う基準ページを決めます。
- 共通手順と部署固有の例外がある場合 ── どの条件で参照先が分かれるかを本文に記載する
- 資料同士に食い違いが残っている場合 ── 検索の利用範囲を広げる前にオーナーが内容を整理する
回答を確認するときは、記事と記載が一致するかだけでなく、利用者の業務と前提条件に合っているかを見ます。例えば共通手順の説明が正しくても、利用者が部署固有の条件に当てはまるなら、その回答で作業を進めず、該当する手順を確認します。
照合で迷った点は、参照した記事、利用者の条件、回答と本文の食い違いをオーナーに伝えます。
| 照合の結果 | 対応 |
|---|---|
| 本文が正しい | 質問に使う言葉や記事への案内を見直す |
| 本文の条件が不足している | オーナーが業務の担当者に確認して記事を直す |
| 複数の資料が異なる手順を示している | 正本を決め直してから利用を再確認する |
記事を更新した後は、実際の業務で使う質問を用いて回答と基準ページを照合します。新しい内容や適用条件を確かめられない間は基準ページを直接参照し、確認方法を見直します。担当者が対応する記事と適用条件を判断できることを、利用範囲を広げる条件にします。
CRMで顧客情報とナレッジを結びつける
社内手順と顧客ごとの記録は、利用する場面に応じて管理場所を決めます。顧客対応中に社内手順が必要なら、どの顧客情報を見ているときに、どの記事を参照するかを整理します。
NotionとHubSpot CRMの連携を検討する場合は、記事の正本、更新オーナー、対象となる顧客情報を決めます。そのうえで、必要なのが社内記事への参照なのか、顧客ごとの情報の更新なのかを分けます。
| 必要なこと | 先に決めること |
|---|---|
| 社内記事への参照 | 顧客対応のどの場面から記事を開くか。参照だけで業務が進むなら、情報の複製や更新が必要かを改めて判断する |
| 顧客ごとの情報の更新 | どちらで変更を確定し、内容が食い違ったとき誰が判断するか |
その要件に沿って連携方法を比較します。検討時は、次の流れを一続きで確認します。
- 担当者が顧客対応中に見ている情報
- 必要になった社内手順
- 記事を開く入口
- 記事の内容を確定する担当
記事を参照するだけで判断できるなら、その場面で正本へ到達できるかを試します。顧客ごとの記録も変更する必要があるなら、変更を確定する場所と、食い違いを解消する担当を定めてから方法を選びます。
対象を定めたら、担当者が必要な記事を見つけ、権限の範囲内で閲覧できるか確認します。
- 記事が見つからない場合 ── 参照先を見直す
- 見つけても判断できない場合 ── 本文の対象範囲や前提条件を見直す
担当者が記事の適用条件を判断できてから利用範囲を広げます。
次の画像はSync for Notionに関するものです。連携を検討する際は、画像から機能や利用条件を推測せず、上で整理した参照・更新の要件に照らして確認します。
よくある質問
Notionで社内Wikiを構築するときは何から始めますか？
繰り返し質問される業務や、引き継ぎ時に確認先がわからなくなる業務を選びます。記事を使う人、利用場面、作業の開始条件と完了条件を決め、既存資料の対象範囲や記述を比べます。資料が食い違うなら、担当者に現在の手順を確認します。正本とオーナーが決まったら記事にし、利用者が普段の言葉で見つけ、適用条件を判断して使えるか確かめます。判断が止まった場合は、入口、記事の対象範囲、手順の分岐のどこで迷ったかを記録して直します。
データベース型とページツリー型はどちらを選べばよいですか？
部門やテーマを順にたどるならページツリー型を、担当者や状態、タグなど複数の条件で探すならデータベース型を検討します。両方の探し方が必要なら、案内ページと記事データベースを組み合わせる方法もあります。同じ業務と記事を使い、利用者が判断に使った記述を示して目的の手順を選べるか、編集者が正本を複製せず配置できるか比べます。入口で迷えば案内を、記事を誤って選べば対象範囲を、配置先が分かれれば分類ルールを見直します。利用者と編集者の双方が選択の理由を説明できてから対象業務を広げます。
Notion Wikiの検証機能は何に使いますか？
社内で確認した内容と、記事の確認状況を対応させる運用に使います。まず、対象者、前提条件、手順、完了条件の照合を、検証済みと扱う条件に定めます。不明な記述は担当者に確認し、修正と関連ページの再確認を終えてから、確認した担当者と時点を記録します。表示だけで記事の適用可否を判断せず、業務が変わったら内容を見直します。判断に関わる未確認事項が残る場合は、その箇所を確定した手順として案内しません。
NotionとHubSpot CRMはどのように使い分けますか？
社内手順やルールと、顧客や取引に関する記録を分けて考えます。顧客対応中に社内記事が必要なら、どの情報からどの記事を参照するか特定し、記事の正本と更新担当を決めます。参照だけが必要か、情報の更新も必要かで要件を分けます。更新が必要なら変更を確定する場所と担当を決め、利用者が必要な記事を閲覧し、適用条件を判断できることを確かめます。必要な記事が見つからない場合は参照経路を、記事を読んでも判断できない場合は本文の条件を見直します。
まとめ
Notionで社内Wikiを構築するときは、対象業務、ページ構造、分類、権限、オーナー、更新ルールを一続きで設計します。企業様によって最適な形は異なります。利用者がどう探し、誰が現在の内容を確認するかを基準に選びます。
まずは、繰り返し質問されている業務を一つ選び、手順書で説明が足りない箇所を書き出してから、次の順で進めます。
- 対象業務と記事を使う人を決め、既存資料の対象範囲と記述を比べます。食い違いを担当者に確認し、正本とオーナーが決まったら記事にまとめます。
- 利用者の探し方と編集者の配置判断で構造を比べ、分類、テンプレート、公開範囲を定めます。想定する利用者が閲覧でき、編集担当者が更新できることに加え、閲覧・編集の制限も確認します。
- 記事を実務で使い、目的のページを見つけられるか、手順の適用条件と完了条件を判断できるか確かめます。止まった箇所を直し、業務変更をオーナーへ伝える経路を整えてから対象を広げます。
CRMを活用した業務効率化やAIとの連携について、顧客対応のどの場面で社内手順が必要か、参照と更新のどちらが必要かを整理したい場合は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
構造の比較を深めたい場合はツール比較の記事、記事が使われない原因を調べたい場合は定着に関する記事、対象業務の選定から公開までの進め方を確認したい場合は構築ガイドを参照できます。AI検索に使う情報の整理を検討する際の関連記事も掲載しています。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
