はじめに
サポートエンジニアになり3年程経ちますが、ナレッジベース（以下、ナレッジ）を活用することで、
ユーザーからのお問い合わせ対応時間を1~2割減らすことができるようになりました。
意外とナレッジを書いて放置したまま、使用していない場合も多いようなので、
サポート業務を1~2割減らすためのナレッジ活用方法について実践したことを書いてみようと思います。
（業務系のちょっと複雑なシステムを想定しています。）
再利用性を考える
プログラミングでは同じコードを書かないよう再利用性を大切にすると思いますが、
ナレッジとなると何回も何回も同じことを書きがちです。
たとえば、Qiitaのナレッジベースで、
「アイコンの設定方法」「パスワードの変更方法」という記事を別々に作成したとします。
両方とも設定画面にある機能なので,
「画面右上のアイコンのとなりにあるプルダウンタブをクリックします。その後、設定をクリックし設定画面に遷移します。」
などと、単調な手順をそれぞれの記事で案内する必要があります。
このような、重複する文章は別ナレッジに切り出すと捗ります。
例えば「設定画面までの遷移方法」というナレッジを作り、スクリーンショット付きでわかりやすく遷移方法を説明します。
そして、それぞれの記事では、遷移方法を文字で書くのではなく、
「設定画面まで遷移します。（参照リンク：http://）」といったように「設定画面までの遷移方法」記事へのリンクに変更します。
可読性があがりますし、UIに変更があった場合も
「設定画面までの遷移方法」を編集すれば良いだけなので、変更が用意になります。
Qiitaはシンプルですが、業務システムは画面遷移が複雑な場合も多いので再利用できる典型例だと思います。
メールで案内することを前提とした記事もこっそり作る
ナレッジというとユーザーが検索して、自己解決するためのもの。というイメージが強いのではないでしょうか。
その思い込みを捨てて、お問い合わせが来たときにメールで参照リンクとして記載する用途の記事も積極的に作成するべきだと考えています。
1つ例を上げると、製品サポート用のログは、基本的にはサポートからの依頼がないと取得しないですよね。
なので必然的に手順もメールで送ることが多いです。このような場合ナレッジに追加したものか迷うのですが、
製品サポート用ログ取得手順としてナレッジ化してしまいます。
ナレッジにすればスクリーンショット使ってわかりやすく案内できます。
メール本文に長い手順を書くことは可読性を落としますし、サポート側としても毎回コピペの手間が発生します。
メールに間違いがないかレビューするときも、最低限の確認で済みます。
ただ、このようなナレッジには、サポート窓口から案内があった場合だけ実施して欲しい旨を
記載した方が無難です。
必ず検証する
ナレッジに間違いがあってはいけません。記憶を頼りにしたり、ほぼほぼ大丈夫だろ、、といった意識でナレッジを書くのはやめましょう。
不特定多数のユーザーの目に触れるものですので、ナレッジに間違いがありデータが欠損した。なんてことになると一大事です。
必ず検証して、間違いが無いように記載することが結果的に一番効率化できます。
前提条件を記載する雛形をつくる
ナレッジには決まって記載する前提条件などは、雛形として毎回ナレッジの冒頭に書くようにしています。
例：
- 所用時間
- 影響範囲
- 対象の製品バージョン
たまに最後に記載しているナレッジがありますが、
製品バージョンや所用時間などは、このナレッジを見るか見ないか判断する上で重要な情報なので、必ず冒頭に書くようにしています。
コマンドやクエリの実行は、正常な実行結果も合わせて案内する
ひと手間ですが、コマンドの実行が終わると〇〇というログが出力されます。といったように
正常に実行が終了したことを確認する方法も合わせて記載しています。
作業後の期待する結果を記載しないと、
コマンドを実行後エラーで止まっているのに、エラーメッセージが英語でユーザーの目にとまらず、
1週間待ってもコマンドの実行が完了しないといった、悲しいお問い合わせをいただくことになってしまいます。
文章はとにかく。で区切る
小説ではないので、一文は短く”。”で区切っています。
これは技術系の書籍は一文が短いので試しに真似してみたのですが読みやすく、書きやすくなります。
「Qiitaにログインして、画面右上のアイコンのとなりにあるプルダウンタブをクリックした後に、表示された設定をクリックして、設定画面に遷移します。」
よりも
「Qiitaにログインします。画面右上のアイコンのとなりにあるプルダウンタブをクリックします。表示された設定をクリックして、設定画面に遷移します。」
の方が読みやすいのではないでしょうか。
重複をおそれない
記事が増えてくると、あれ？これと似たような内容むかし書かなかったっけ！？と心配になることもあります。
5分程度で書けるナレッジなら書いてしまった方が早いです！ 同じ内容でも切り口が異なると記事は有用ですし、昔より今の自分の方が良いナレッジが書けるはずです。
スクリーンショットを多用する
文章で手順を説明するのではなく、とにかくスクリーンショットを使います。
またQiitaの例ですが、「Qiitaにログインします。画面右上のアイコンのとなりにあるプルダウンタブをクリックします。表示された設定をクリックして、設定画面に遷移します。」
よりもスクリーンショット一枚とった方が早くてわかりやすいです。
まとめナレッジを作る
ある程度ナレッジが溜まってきたら、見てもらいたいのに埋もれてしまうナレッジも出てくるので、
「最低限の設定で始めるスタートアップチュートリアル」とか、「ダッショボードを使いこなす方法」など
テーマごとにリンクを集めてまとめナレッジを作っています。
まとめナレッジは通常よりもわかりやすい場所に表示します。
番外編
target blank をつける
文中のリンクには必ずtarget=”_blankを付けて新しいタブで開くようにしています。
ナレッジ読んでいる途中にあとで読もうと思ってリンククリックしたときに、そのまま画面が更新されると絶望します。
まとめ
以上がサポートを効率化するために行なっているナレッジの運用方法です。
また思い出したら随時更新していこうと思います。