社内FAQの作り方｜「聞かれたら書く」で続く社内ナレッジの始め方と運用

「経費精算のやり方、どこかに書いてありましたっけ」──社内チャットで、この種の質問に答えるのが特定の誰かの仕事になっていないでしょうか。答えを知っている人に質問が集中し、その人の手が止まり、その人が休んだ日には業務まで止まる。社内 FAQ は、この構造を解くための道具です。ただし、時間をかけて網羅的なマニュアルを作り込む話ではありません。社内 FAQ は「作ってから使う文書」ではなく、「聞かれるたびに 1 問ずつ貯める運用」──これが本記事の結論です。先に完成を目指すから終わらず、終わらないから使われない。逆に、実際に聞かれた質問から始めれば、初日から使われる状態で公開できます。この記事では、顧客向け FAQ ページとの違いの整理から、置き場所の決め方・最初の質問の集め方・書き方の型・止まらせない運用まで、今週から始められる手順に落とし込みます。特別なツールは前提にしません。共有の表計算シートや、いま使っている社内 wiki で十分です。

社内FAQとは ── 顧客向けの「FAQページ」とは別物

最初に言葉を整理します。同じ「FAQ」でも、世の中で語られるものには 2 種類あります。1 つは、顧客が読む FAQ ページ。自社サイトに置き、問い合わせの前に顧客自身に解決してもらうための対外コンテンツです。作り方は「FAQページの作り方 ── 問い合わせを減らす質問の絞り方・書き方・置き方・更新の回し方」で 4 ステップに分けて解説しました。もう 1 つが、本記事で扱う社内 FAQ──オペレーター・バックオフィス・情シス・新人といった社内の人間が、業務の途中でつまずいた瞬間に引く一問一答のナレッジです。両者は名前が似ているだけで、設計はほとんど別物です。

この 2 つを 1 つの文書で兼ねようとすると、どちらも中途半端になります。社内手順や判断基準は対外には出せないので、混ぜれば公開できる丸い表現しか残らず、社内の実用性が消えます。逆に社内用語のまま外に出せば、顧客には届きません。読者が違う文書は、最初から分けて作る──これが出発点です。そして分けてみると、社内 FAQ には対外版にはない強みがあることに気づきます。読者が社内にいるので、反応が直接返ってくるのです。何が探されて、何が見つからなかったかを、隣の席の声で拾える。この近さが、後述する「聞かれたら書く」運用を可能にします。

「作ったのに使われない」社内FAQ、3 つのつまずき

社内 FAQ やマニュアル整備に一度挑戦して、頓挫した経験のある方は少なくないはずです。うまくいかないケースには、はっきりした共通パターンがあります。

• ①完成を待って、公開されないまま止まる ── 「まず全業務を洗い出して、体系立てて書こう」と網羅型のプロジェクトにすると、担当者の通常業務が忙しくなった時点で必ず中断します。数ヶ月後に残るのは、目次だけ立派な書きかけの文書です。網羅は初期条件ではなく、運用の結果として後から付いてくるものです。
• ②探す側の言葉で書かれていない ── タイトルが「経費精算規程について」では、「立て替えたお金はいつ戻る?」と探している人に届きません。書いた本人は場所を知っているので気づきませんが、検索で見つからない FAQ は、存在しないのと同じです。
• ③古い情報が混ざって、信頼を失う ── 一度でも「FAQ の通りにやったら手順が変わっていた」を経験すると、人はその FAQ を引かなくなり、確実な方法──人に聞く──へ戻ります。更新が止まった FAQ は、単に古いのではなく、FAQ 全体の信頼を静かに下げ続けます。

3 つに共通する根本原因は、社内 FAQ を「文書を作るプロジェクト」として設計していることです。実際に機能している社内 FAQ は、文書というより「質問対応」という日常業務の置き場に近い形をしています。誰かが答えるたびに 1 問増え、探されるたびに磨かれる。以降の 4 ステップは、この形を最短で立ち上げる手順です。

社内FAQの作り方 4 ステップ

ここから、冒頭のロードマップに沿って手順を具体化します。所要の目安は、ステップ 1〜3 の初期設定が半日、ステップ 4 は日々の運用そのものです。凝った準備はいりません。

ステップ 1: 置き場所を 1 つに決める ── ツールは今あるもので

最初に決めるのは中身ではなく置き場所です。条件は 3 つだけ。全員がログインの壁なしにすぐ開けること、キーワードで横断検索できること、誰でもその場で追記できることです。この 3 つを満たすなら、共有の表計算シート(エクセルやスプレッドシート)でも、社内 wiki でも、グループウェアの掲示板でも構いません。むしろ、新しいナレッジツールの選定から始めるのはおすすめしません。ツール選定はそれ自体がプロジェクト化して、FAQ が 1 問も書かれないまま比較表だけが増えていくからです。いま全員が毎日開いているツールの中に置くのが、最も早く、最も定着します。もう 1 つ大事なのが「1 か所」に限定することです。置き場所が 2 つあると、探す側は両方を引く羽目になり、書く側はどちらに書くか迷い、やがて両方が中途半端に古くなります。既存のメモや手順書が散らばっている場合も、無理に移植せず、「これからの質問はここに貯める」と決めた 1 か所から始めれば十分です。

ステップ 2: 最初の 20 問は「実際に聞かれた質問」から集める

初期セットは、頭の中で「聞かれそうな質問」を想像して作るのではなく、実際に聞かれた質問から集めます。質問には強い偏りがあり、聞かれたことのない項目を先回りして書いても、ほとんど引かれないからです。集める場所は 3 つあります。社内チャットの履歴(「どうやって」「どこにある」「誰に聞けば」で検索すると質問が並びます)、新人が最初の 1 ヶ月にした質問(教えた側のメモや記憶で構いません)、そして質問が集中しているその人自身へのヒアリング(「先週答えた質問を、思い出せるだけ挙げてください」)。この 3 つをたどると、20 問前後はすぐ集まるはずです。そして20 問ほど揃ったら、その時点で公開してください。「まだ 20 問しかない」と考える必要はありません。その 20 問は想像ではなく実績で選ばれた、確実に需要のある 20 問です。少なく始めることには利点もあります。1 問ずつの品質に目が届き、探す側も全体を見渡せるからです。

ステップ 3: 書き方の型を揃える ── 1 ページ 1 質問・質問の言葉・結論先出し

書き方の型は 3 点だけ揃えます。1 ページ(1 行・1 項目)に 1 質問だけを書くこと。タイトルは質問者の言い回しの疑問文にすること。最初の 1 文で結論(答え・ありか・担当)を言い切ることです。実例で比べると、違いがはっきりします。

タイトルを疑問文にするのは、見た目の好みの問題ではありません。検索に使われる語は質問者の頭の中の言葉なので、タイトルがその言葉と一致しているほど見つかります。加えて、各項目の末尾に「最終更新日」と「書いた人(または確認先)」を必ず残してください。読む側が鮮度を判断できることが、後述する信頼の維持に直結します。もう 1 つ、書く前の見極めとして、答えが状況や相手によって変わる質問は、無理に FAQ 化しないでください。判断が要る相談に一律の答えを書くと、その答えが誤用されます。その場合は答えの代わりに「この件は○○チームの担当者に、この情報を添えて聞く」と窓口と聞き方を書く──これも立派な FAQ です。「誰に聞けばいいか分からない」こと自体が、社内で最も多いつまずきの 1 つだからです。

ステップ 4: 「答えたら書いて、リンクで返す」を唯一の運用ルールにする

ここが本記事の中心です。社内 FAQ を育てる方法として、「毎週金曜に 30 分、文書化の時間を取る」といった専用タイムを設ける案がよく出ますが、この方式は通常業務に押されて数週間で消えます。代わりに、誰かの質問に答えたら、その答えを FAQ に書いてから、質問者にはリンクを返す──これを唯一の運用ルールにしてください。ポイントは、追加の作業時間がほぼ発生しないことです。チャットで質問に答えるとき、あなたはどうせ答えの文章を書いています。その書き込み先を FAQ に変えて、チャットには URL を 1 本貼るだけ。答えた直後は内容が頭に完全に載っているので、書くのに数分もかかりません。そして次に同じ質問が来たときは、リンク 1 本で答えが終わります。書くのは答えた側でなくてもよい、という点も付け加えておきます。教わった直後の人は「分からなかった側の言葉」を持っているので、質問した本人が書いてタイトルを付けると、次に同じ場所でつまずく人に一番届く FAQ になります。新人の受け入れ期間に「教わったことを 1 問ずつ FAQ にする」を組み込むと、教育とナレッジ整備が同時に進みます。

社内FAQが止まる理由と、生かし続ける運用

型ができて動き始めても、社内 FAQ は放っておくと止まります。止まり方は決まっているので、先回りして 3 つだけ手を打っておきます。

最後に、正直に書いておきます。社内 FAQ を整えても、社内の質問がゼロになることはありません。判断が要る相談、初めて起きる例外、個別の事情──人に聞くべきものは必ず残ります。それでよいのです。社内 FAQ の目的は質問の撲滅ではなく、何度も繰り返される定型の質問を仕組みに逃がして、人は判断が要る相談に集中できるようにすることです。「同じ説明を今月 3 回した」が消えるだけで、答える側の負担感は大きく変わります。

貯まった社内FAQは、次の仕組みの燃料になる

「聞かれたら書く」を続けていくと、数ヶ月後には、実際の質問に裏打ちされた一問一答が数十〜数百件の単位で貯まります。これは検索して読む文書としての価値にとどまりません。整理された一問一答のナレッジは、AI に回答させる仕組みの知識源としてそのまま使える資産です。社内資料を知識源にして AI が質問に答える仕組みの全体像は「社内ナレッジをAIに回答させる仕組み(RAG入門)」で解説していますが、どの方式を選ぶにせよ、鍵を握るのはナレッジ側の質です。本記事の型──1 ページ 1 質問・質問の言葉のタイトル・結論先出し・更新日付き──で貯まった FAQ は、AI にとっても引きやすい形になっています。

もう 1 つの展開先が、顧客対応です。社内 FAQ を眺めると、「顧客からも同じことを聞かれている」質問が必ず見つかります。オペレーターが社内 FAQ を引いて答えている質問は、顧客が自分で解決できる形──対外の FAQ ページや Web 上の自動応答──に転用できる候補です。電話やメールの問い合わせを減らす打ち手の全体像は「問い合わせ削減の方法【完全ガイド】」で整理しているので、社内の型が回り始めたら、次はナレッジを外向きに効かせることを考えてみてください。

ここで、当社の AI チャットボット「コルット」について 1 つ線を引いた上で紹介します。コルットは自社の HP に設置して顧客からの質問に 24 時間 365 日自動応答する対外向けのサービスで、社内 FAQ ツールそのものではありません。ただし接点があります。コルットは社内ナレッジ(マニュアル・規定・対応ログ)を知識源に回答を組み立てる方式で、一問一答 FAQ を新たに作り込む必要がありません。つまり、本記事の型で「実際に聞かれた質問と答え」が貯まっている会社は、対外の自動応答を立ち上げるときの初期ナレッジ整備を、すでに半分済ませていることになります。導入時は初期ナレッジの整備・構築から伴走し、設置は HP にタグ 1 行、最短 3 日で公開できます。

よくある質問