どうすれば人は記録を残してくれるのか
おはようございます、柚人です。
情シスslackで面白い質問があって、これは情シスSlack以外でも目に触れてほしいと思ったので書きます。
問
弊社では○○で問い合わせを受けます。
しかし、対応記録・解決策が残らないため、次に活かせません。
どうすればナレッジが残るのでしょうか？
答
サービスオーナーが主体になり、サービス関係者全員で、部門単位で文化を醸成し、システムに落とし込みましょう。
ポイント
問題のポイントは2つあると考えています
調査記録・対応記録など証跡を残さない文化への危機意識がない
ナレッジの残し方、書き方、書くべき内容がわかっていない
この2点をより詳細に紐解いていきましょう
対応記録を残すためには
是非部署やチームで以下のポイントについて話し合ってください。
証跡を残さないリスクを考えよう
ITIL（アイティル、ITサービスにおけるベストプラクティス）ではユーザーがサービスを利用できない状態をインシデントと言います。
利用できないとは、回避策で解決することであっても、想定したサービス水準に至っていないためにサービスが正常に利用できていないことも含み、それはいわゆる「劣化」と言えます。
これらが「劣化したまま」なのか「起こるべくして起きたこと」なのか「ユーザーの勘違い」なのか、が残らないとサービス品質が知らぬ間に低下していきます。
問題を放置し続けていると「根本解決しないために、定期的におきる運用負荷、サービスへの不満」となるわけです。
簡単に言えば「正常に動いているか」のふるいをかけてるわけですね。
なので、たとえ社内のヘルプデスクであっても、顧客営業であっても、コンビニやスーパーのレジ打ちであっても「正常に回らないこと」が起きたら記録し、解決方法も明確に残す必要があります。
別に「上司や関係部署にメールで報告する」でも、自身の部門においては立派な解決策です。（エスカレーションと言います）
「上司や関係部署にメールで報告する」の背景に、「報告先でないと権限がないので出来ない」「報告先でないと閲覧できない範囲に解決策が記録されている」ということがありうるからです。
無かったら上司が退職したり部署変更があった瞬間、その解決策は死にますけど、その責任は末端には関係ありません。会社の責任であり、上司の責任です。
ユーザーの満足度に繋がる意識を持とう
よくあるのは以下の2パターンでしょう
「以前にも同じことが起きた、またそれをやらせるのか！」「もう前に教えてもらった解決策はやった！また発生したんだ！」と怒らせる
「以前に○○さんがやってくれて、すぐに解決しました」から対応のヒントが得られ、新入社員でも分かる内容になっていて、すぐに解決できたのでユーザーが喜んだ
サービス提供において、相手は人です。なので喜怒哀楽やその人の感情が「表に出なくても」あります。
ただ大人を相手にサービスを提供する場合、前者で怒る人はそんなに多くはありませんが、逆に大人なので「不満をためこみ」ます。
そして、その不満がたまり続け爆発すると「サービスの解約」に繋がり、食い扶持を失います。
なので、満足度向上のために記録を残すことが大事、という文化を定着させる必要があります。
明確に、簡単に残せる基準を用意しよう
インシデントが解決した際、解決理由は必ず存在します。
ただし「何をして解決したかを残しておいてね」と言われて、みんなが一定の品質の記録を残せるでしょうか？
具体的な例を挙げてみましょう。
Aさん（新入社員）は「わからないのでBさんにやってもらって解決しました」と記録
Bさん（ズボラ）は「いつもの手順で対応しました」と記録
Cさん（几帳面）は「10:00に受付、10:20に原因を特定、○○に問題があったので業者を呼んで立ち合い、11:00に部品交換終了にて解決しました」と記録
さて、どの記録が分かりやすいかは一目瞭然ですね。
Cさん以外の記録は使うに値しません。
ここで大事なのは6W2H（Who,Whom,Why,What,When,Where,How to,How much）で書かれているかです。
ちなみにCさんの書き方は6W2Hを抑えているだけでなく、事実だけを述べています。
「推測」というものは読み手のバックグラウンド次第ではミスリードをしかねないので、事実だけを簡潔に伝えることが大事です。
次に解決策ですが、Cさんの場合だと「業者を呼ばなくては解決しない」ということが明確です。
これらをよりシンプルに記録するには、対応記録表でもいいし、サービス管理システム（例：Asana,Redmine,ServiceNow,JiraServiceManagement,Zendesk,freshservice他）でも構いませんが、その中に一定の解決理由の項目を用意し、揃えておくことです。
具体的には以下の選択肢に大体分かれます
ユーザーの自己解決
自然解消（原因特定済み）
自然解消（原因不明）
ナレッジを案内して解決（要ナレッジURL）
運用手順に則って対応（例：MFAリセットなど）し解決（要手順URL、手順書管理番号）
外部業者や変更作業にて解決
ナレッジ・手順無しで解決（要報告）
これらの中から選ぶ形にしておけば「発生原因とその対応策」「ナレッジ・手順書の有無」が明確になります。
ナレッジを残すには
ユーザーと対峙する窓口にとっては、ユーザー対応が第一です。
窓口チーム内での手順作成は内部のものはしておかなければなりませんが二の次ですし、ましてやユーザー向けのナレッジとなれば品質が一定でなくてはいけません。
ただ書くだけでなく、それらのフォーマットチェックもする羽目になると、当然大変すぎて不満も疲労も貯まります。
そういった観点から「余力があれば、書くのは窓口でもよい」のですが、正しくは「ナレッジ管理者が適切なレビュープロセスを経て公開する」です。
どう書けばよいのか
書くべき内容は大体パターン化されています。
このナレッジは誰向けか（対象者）
このナレッジは何の解消を目的としているか（目的）
このナレッジに関連するサービス・機能は何か（対象サービス）
このナレッジに必要な前提条件は何か（事前準備）
このナレッジはどのようにして実行するか（How to）
このナレッジによる対応時間はどのぐらいの時間を要するか（所要時間）
このナレッジの主管はどのチームか（問合せ先）
このナレッジについて分からない場合どうすればいいか（問合せ方法）
このナレッジはいつどういう理由で更新・公開されたか（来歴）
これらが網羅されていて、初めて「使えるナレッジ」と言えます。
事実だけが記載され、推測や推論は要りません。
ナレッジ作成の優先度
問題とその解決策を言語化するには、とても多くの調査・確認と記述する時間が必要となります。
ちなみにChatGPTの回答は最初の問合せ対応や書き方がナレッジ寄りで非常にいいんですが、ファクトがめちゃくちゃなので「書き方」だけは参考になるかと思います。
無数にあるパターンすべてに対応するナレッジの記述は膨大な時間を要するため、優先度が設けられます。
これらは「対象者」「影響範囲」「緊急度」で判断され、より緊急性が高く、多くのユーザーが影響を受ける変更は「情報発信」と同時に公開されておく必要があります。
インシデント管理においても障害・不具合に紐づくものなので、なにより優先して作られますが、その他にも上記のように優先度が定められる必要があります。
一人に向けた一人のための手順は一番優先度が下がります。
また、例えば「7月にリリースする機能のナレッジ」であれば6月末までに公開準備を整えておく必要があります。
雑多に書き貯めておけばいいのではなく、適切にリリースされる必要もあります。
ナレッジ管理者（ナレッジマネージャー）の存在
クラウドサービスなどはよく「ヘルプ」であったり「Developer support page」であったり、「ヘルプセンター」であったり「ナレッジベース」であったり、様々な名称でヘルプページがあるのを目にしたことがあると思います。
あれらは一定のカテゴライズがされ、タグが付いていたり、相互リンクがあったりして、記載も一定ですよね？
そのあたりを意識してヘルプサイトのコンテンツを作れるのが「ナレッジマネージャー」の存在です。
ナレッジマネージャーの主な役割は以下の通りです。
ナレッジ全体の優先度管理
フォントサイズ、箇条書きや順番書きリスト、URLリンクの適切さのチェック（ファクト・デザインチェック）
来歴管理、各ナレッジの担当チーム把握
ユーザー心理（読み手）を踏まえた言語表現のチェック
再現性チェック
公開権限
対応内容には専門的な知識・技術を要するものがありますが、ナレッジマネージャーは技術部分については責任を持ちません。
そうでないと、ナレッジマネージャーはユーザー心理も理解し、サービス全体の技術・運用を完全掌握している人しかできず、そんな人にナレッジ記述をさせるとかいうオチになるのでありえません。
そういったものはそれぞれ専門分野の担当に依存します。
しかし、いわゆる書き手が思うままに書いて公開している（このページのような）ブログではありません。
あれらはナレッジマネージャーがいることで「一定の品質」を保っています。
余談ですが、ITSMツールをいくつか見ていると、「ああこの会社はこの製品使って問合せ管理してるんだな」が分かります（通知メールの体裁でも分かります）
まとめ
途中で具体的な製品名を述べましたが、最初に議論を促した通り、サービス管理ツールを導入するだけでは実施されません。
ツールと同時に、「安定して回すための仕組み（ナレッジマネジメント）」と「その運用を理解する」ことが大事です。
それらを共通認識を持って運用を進めれば、より次に活かした記録を残すクセが定着し、サービス品質向上につながるでしょう。
この記事が気に入ったらサポートをしてみませんか？