社内FAQ・ナレッジ管理の作り方｜同じ質問と属人化を減らす運用設計

Knowledge Base

社内の「聞かないと分からない」を、探せば分かる状態にする

社内FAQやナレッジ管理は、よくある質問、手順、判断基準、トラブル対応を整理し、担当者に聞かなくても仕事を進められる状態を作る取り組みです。ナレッジとは、会社の中にある知識や経験のことです。

中小企業では、経理、総務、情報システム、営業事務、店舗責任者など、詳しい人に質問が集中しがちです。本人は親切に答えているつもりでも、同じ説明が何度も発生すると、その人の時間も、質問する側の時間も失われます。

最初から大きな社内ポータルを作る必要はありません。まずは「同じ質問が3回出たら記事にする」「チャットで流れた回答をFAQに移す」「退職や休職で困る内容を優先する」という小さなルールから始めます。

ユウ

経費精算のやり方、毎月誰かに聞いています。たぶん僕だけじゃないです。

ミナミ

それは人の記憶で会社が動いている状態です。質問が悪いのではなく、答えが置かれていないのが問題ですね。

ユウ

つまり、僕の記憶力の問題ではなく、会社の検索機能の問題。

ミナミ

半分はそうです。残り半分は、聞く前に検索する習慣も育てます。

ユウ

検索する前に聞くクセ、今日で卒業したいです。たぶん明日補習です。

社内FAQに向いている内容

ナレッジ管理で最初に集めるべきなのは、立派な理念や長いマニュアルではありません。現場で何度も聞かれている、短く答えられる質問です。小さなFAQを積み上げる方が、読まれる仕組みにしやすくなります。

社内手続き

経費精算、勤怠、休暇申請、備品購入、名刺発注、出張申請など。総務や経理に同じ質問が集まる内容です。

IT利用

アカウント発行、パスワード再設定、Wi-Fi、チャット、クラウドストレージ、プリンター、共有フォルダの使い方です。

営業・顧客対応

料金表、よくある反論、提案資料、契約前の確認事項、返品・返金ルール、クレーム初動のテンプレートです。

引き継ぎ

担当者しか知らない月次作業、取引先ごとの注意点、締切、ログイン先、確認順序、例外対応です。

作る順番は「質問の多さ」と「止まると困る」で決める

すべてを一気に整理しようとすると、たいてい止まります。まずは質問の多いもの、担当者不在で止まるもの、ミスが起きると損失が大きいものから作ります。

優先度	例	理由
高い	請求書発行、入金確認、返品・返金、アカウント停止、顧客対応	遅れるとお金、信用、情報管理に影響しやすい。
高い	退職者の引き継ぎ、月末処理、店舗開閉店、障害時対応	一人しか知らないと、休みや退職で業務が止まる。
中	備品購入、出張精算、会議室予約、社内申請	質問数が多く、積み上がると管理部門の時間を削る。
低い	年に一度しか使わない細かな手順	重要でも、最初から細部まで作り込むと続かない。

FAQ記事の型を決める

ナレッジは、書く人によって形がバラバラになると探しにくくなります。最初に型を決めておくと、後から増えても整理しやすくなります。

タイトル「経費精算の領収書はいつまでに出す？」のように、検索される言葉で書く。

対象者全社員向け、店舗スタッフ向け、責任者向けなど読む人を分ける。

結論最初に答えを書く。長い前置きは読まれにくい。

手順番号付きで、画面名、提出先、締切、添付書類を書く。

例外迷いやすいケース、上長承認が必要なケース、問い合わせ先を書く。

更新日最後に更新日、担当部署、次回見直し時期を入れる。

チャットとナレッジの違い

ビジネスチャットは相談や連絡には便利ですが、答えを残す場所としては弱いことがあります。メッセージが流れ、検索語が合わず、同じ質問がまた出るからです。

チャットは「今話す場所」、ナレッジベースは「後から探す場所」と分けると、使い方がはっきりします。チャットでよい回答が出たら、そのまま終わらせずFAQに移すのが大切です。

使い分け	向いていること	残し方
チャット	急ぎの相談、確認、担当者への連絡	解決したら要点だけFAQにする。
ナレッジベース	繰り返し使う手順、判断基準、テンプレート	検索しやすいタイトルとカテゴリを付ける。
タスク管理	誰がいつまでに何をするか	FAQ更新もタスクにして期限を置く。
クラウドストレージ	契約書、PDF、画像、原本ファイル	FAQから保管場所へリンクする。

権限管理を甘くしない

社内FAQには便利な情報が集まりますが、何でも全員に見せればよいわけではありません。給与、評価、顧客情報、契約条件、システムの管理手順、退職者対応などは、見せる範囲を分ける必要があります。

IPAの中小企業向け情報セキュリティ資料でも、情報資産を守る考え方が示されています。社内FAQを作るときも、情報を共有する便利さと、見せてよい範囲を一緒に考えます。

全社員向け、管理部門向け、役員向け、外部委託先向けを分ける
退職者や外注終了者のアカウント停止手順を残す
パスワードそのものは記事に書かず、保管方法だけを書く
顧客名や個人情報を載せる場合は、必要最小限にする
外部共有リンクを作るときは期限、閲覧範囲、編集権限を確認する

ユウ

じゃあ、みんなが困らないように、全部のパスワードをFAQに載せれば完璧ですね。

ミナミ

完璧に危ないです。FAQには「どこで管理するか」「誰に申請するか」を書きます。秘密そのものは置きません。

ユウ

便利さの勢いで会社の秘密を大開放するところでした。

更新されない問題を防ぐ

社内FAQが失敗する一番の理由は、作ったあとに古くなることです。古い情報が混ざると、社員は「どうせ正しくない」と思い、見なくなります。

すべての記事を完璧に保つ必要はありません。重要な記事だけでも、責任者、更新日、見直し期限、変更履歴を入れておきます。制度変更、料金変更、ツール変更、担当変更があったら、その場で更新する運用にします。

運用ルール	決める内容	例
記事責任者	誰が正しさを見るか	経費精算は経理、Wi-Fiは情報システム、返品は店舗責任者。
見直し周期	いつ古さを確認するか	重要記事は3か月、通常記事は半年、低頻度記事は年1回。
変更履歴	何を変えたか	申請フォーム変更、締切変更、担当者変更を残す。
削除・統合	似た記事をどう整理するか	同じテーマが2つ出たら、片方へ統合してリンクを残す。

小さく始める30日プラン

1週目: 最近1か月で多かった質問を10個集める。チャット、メール、口頭質問から拾う。
2週目: まず5本だけFAQ化する。タイトル、結論、手順、問い合わせ先、更新日を入れる。
3週目: チャットの固定リンクや社内ポータルから見つけられるようにする。検索語も調整する。
4週目: 使われた記事、見られない記事、まだ質問が来る記事を見直す。足りない説明を追記する。

この段階では、ツール選定より運用の型が大切です。Googleドキュメント、Notion、SharePoint、Confluence、社内Wiki、ヘルプデスクツールなど、どれを使う場合でも、検索しやすさと更新責任がなければ定着しません。

よくある失敗と直し方

失敗例	起きる理由	直し方
誰も見ない	場所が分からない、タイトルが検索語と違う。	チャットに固定し、質問文に近いタイトルへ変える。
記事が長すぎる	背景説明まで全部入れてしまう。	結論、手順、例外、問い合わせ先に分ける。
似た記事が増える	誰でも自由に作り、統合しない。	カテゴリ責任者を置き、似た記事は月1回まとめる。
古くて信用されない	更新日や担当者がない。	重要記事から更新日と責任者を入れる。
秘密が混ざる	共有範囲を決めずに便利さだけで作る。	機密度ごとに閲覧権限を分ける。

参考にした公的情報

IPA：中小企業の情報セキュリティ対策ガイドライン

社内FAQ・ナレッジ管理の作り方