「FAQを育てれば問い合わせは減る」——だが書くことと使われることは別物で、体系KCSは査読外だ

同じ問い合わせが繰り返されるなら、FAQに答えを書いておけば問い合わせは減る、と教わる。狙いはまっとうだ。だが書かれた知識は、検索で見つかり、中身が確かで、読めて、古びていないときにだけ使われる。蓄積と活用は別物である。運用の体系KCSにも由緒はあるが、それは業界団体の実務方法論で、査読された理論ではない。FAQのおかげで減ったように見えるとき、そのページが実際に読まれて解決に至ったのかは、たいてい別に数えられていない。

前の単位では、客が自分で解決できるようにする設計を扱った。ここでは、その入り口のうち最も身近な、読んで解決してもらうFAQを育てる運用を扱う。

FAQを育てる、とKCSという出どころ

FAQ——Frequently Asked Questions（よくある質問）——は、客が読んで自分で用件を済ませられるようにした、いちばん身近な知識のページだ。同じ問い合わせが繰り返されるなら、答えを一度書いておけば、次からは読んで解決してもらえる——FAQを育てれば、問い合わせは減る。 これが、この単位で検める俗説である。狙いそのものは、まっとうだ。

この運用の『体系』としてよく引かれるのが、KCS（Knowledge-Centered Service＝知識を中心に据えたサービス）である。だが、その出どころを確かめておく。KCSは、Consortium for Service Innovation という業界団体がまとめた実務の方法論であって、査読された理論ではない。 現場で鍛えられた有用な知の集まりではあるが、その権威は査読ではなく、実務家の合意に由来する。ここでも、この棚の背骨——流通している体系の由緒と、効果の証明は、別物——が通っている。KCSを使うなという話ではない。ただ、それが『査読された事実』ではなく『実務コンソーシアムの体系』だという出どころを、混同しないでおく。そして持ち場を区切っておく。この単位が扱うのは、客が読む面——FAQという顧客向けの知識ページ——である。対応する人が使う内部の知識をどう蓄え共有するかは、この棚の後の単位で扱う。

書くことと、使われることの距離

『書けば減る』の最大の穴は、書かれた知識が、使われるとは限らないことだ。Gray と Durcikova が2005年に、技術サポートの知識リポジトリ（知識をためて検索する仕組み）を対象に行った研究は、知識を速く見つけて使うことと、そこから学ぶことのあいだにトレードオフがあることを示した。答えのコピーで速く片づくことと、担当者がその中身を理解して次に活かせることは、必ずしも両立しない。蓄積することと、活用されることは、別物である。書いた本数が増えても、検索で見つからなければ、古くなっていれば、読んで意味が取れなければ、その知識は使われない。ページが増えたことと、問い合わせが減ったことは、別々に確かめるしかない。

検証と品質が、知識を使われるものにする

では、何が使われる知識と使われない知識を分けるのか。鍵のひとつは検証——書かれた知識が正しいと確かめられる仕組み——である。Durcikova と Gray が2009年に示した研究は、知識の検証プロセスのあり方が、人がその知識ベースに貢献するかどうかに影響することを扱った。さらに Fadel と Durcikova が2014年に示した研究は、その検証が公正だと感じられるかが貢献を左右することを示す。検証が雑だったり不公正に感じられたりすると、人は書かなくなる。

読む側から見ても同じだ。Filieri と Willison が2016年に示した研究は、知識リポジトリからの知識の取り出しと再利用が、知識そのものの品質と、システムの品質に左右されることを示した。中身が確かで、探しやすく、読みやすい——この品質がそろってはじめて、書かれた知識は再利用される。Gray が2001年に問題解決の視点から論じたように、大事なのは『どれだけ書いたか』ではなく『必要なときに、使える形で取り出せるか』である。FAQを育てるとは、本数を増やすことではなく、見つかって、確かで、読めて、古びない状態を保つことにほかならない。

FAQを増やせば問い合わせが減る、とは限らない

そして、いちばん素朴な期待——FAQを整えれば問い合わせは減る——も、自動的には成り立たない。Kumar と Telang が2012年に、あるコールセンターのデータで、Webやセルフサービスの提供が顧客サービスのコストを下げるかを検討した研究は、Web提供が必ずしもコストを下げるとは限らないことを実証した。FAQを置いたぶんだけ問い合わせが機械的に減る、という単純な引き算ではない。読まれなければ、見つからなければ、かえって『FAQを読んだが解決しなかった』という二度手間を生むこともある。FAQ整備＝問い合わせ減、とは書けない。

時間・変化：2001年から2016年へ

順に置く。2001年、Gray が知識マネジメントを問題解決の視点から論じる。2005年、Gray と Durcikova が速さと学習のトレードオフを示す。2009年、Durcikova と Gray が検証プロセスと貢献の関係を、2012年、Kumar と Telang がWeb提供のコスト非自明性を示す。2014年、Fadel と Durcikova が検証の公正さと貢献を、2016年、Filieri と Willison が知識とシステムの品質が再利用を左右することを示す。この15年で確からしくなったのは、『書けば減る』という単純な因果ではない。 確からしくなったのは、蓄積と活用は別物で、検証・鮮度・品質がそろってはじめて知識は使われる、という向きのほうである。

妨げるもの、助けるもの、最初の一歩

妨げるものの筆頭は、FAQを『本数』で育てたと思い込むことである。ページ数が増えても、見つからず、古く、読みにくければ、問い合わせは減らない。KCSのような体系を導入したこと自体を成果と取り違えるのも、同じ穴だ。体系の由緒は、あなたのFAQが使われる保証にはならない。

対応する人の身も一度。『FAQに書いてあります』と客を突き放す運用は、逃げ道のないセルフと同じで、行き止まった不満を結局どこかの窓口——多くは、その場に残った一人——に戻す。FAQは、人への道を消すためではなく、人にたどり着く前に済むことを増やすために育てる。

助けになるのは、自分のFAQを客の目で読み、『見つかるか・確かか・古びていないか』を、一項目ずつ確かめてみることだ。最初の一歩は10分。自分のFAQ（無ければ、自動返信や案内文でよい）から項目をいくつか選び、それぞれ『最後に中身を確かめたのはいつか』『いま読んで、この答えで解決するか』を書き留める。直す作業はしない。誰かに尋ねる必要もない。確かめた日付と、古びていないかの判断だけを、記録するだけでよい。

次の単位は 405「サービスの失敗から立て直すには？」——うまく応え、自分で解決できるようにしても起きてしまう失敗を、どう回復するのかへ進む。

皮肉なのは、いちばん熱心にFAQを『育てた』と誇る現場ほど、その本数を数えていて、使われた回数を数えていないことである。書かれた知識は、検索で見つかり、中身が確かで、読めて、古びていないときにだけ使われる。KCSという体系にも由緒はあるが、由緒はあなたのFAQが読まれる保証にはならない。FAQのおかげで問い合わせが減ったように見えるとき、たいていそれは、まだ誰も、そのページが実際に読まれて解決に至ったのかを、別に数えていないだけかもしれない。