Secret Ninja Blog

Support Engineering Manager してます

プロダクトドキュメントとヘルプセンターとナレッジベースとQ&Aページ

Zendesk Advent Calendar 2019のAdvent Calender23日目です。

adventar.org

Zendeskの使い方について書こうかと思ったんですが、マニアックな内容になりがちなので、 Zendesk Guideとドキュメンテーションの話をしたいと思います。

プロダクトドキュメントとヘルプセンターとナレッジベースとQ&Aページ

みなさんがサービス責任者であるときに、この4つのドキュメントをどう使い分けているでしょうか?

  • プロダクトドキュメント: プロダクトの"正しい"利用方法が書かれてある。"HowTo"が主。
  • ヘルプセンター:サービスの"HowTo"が書かれている。
  • ナレッジベース: 顧客がプロダクト機能のユースケースに応じた推奨方法が書かかれている。古い記事もあって間違っていたりすることもあっても許される
  • Q&A: 顧客がこれまで問い合わせきたものに疑問などに対する回答が書かれている。

B2Cのときは、ヘルプセンターとQ&Aページのみであるケースも多いと思いますが、B2Bのときはこの4つを作る必要があると思っています。

開発者向けにツールやライブラリといったものを提供しているときは、プロダクトドキュメントが非常に重要です。ここに書かれるインストール方法やライブラリの使い方といった情報は常に最新の状態に保つ必要があります。 また、このドキュメントのメンテナンスに責任を持つ人たち、プロダクトと開発者になります。それは、単純なサービスの利用法ではなく、デベロップメントスキルなどの深い知識がなければ、正しいメッセージを発信できないためです。

例として、マイクロソフトでは、Githubに全てドキュメントがホストされていて、プルリクベースでユーザからの修正リクエストの受付もされる。また、Githubを使うことで、ドキュメント内のコードのテストを自動化させたりも可能です。

docs.microsoft.com

ヘルプセンターは、いわゆるマニュアルです。ログインのためには1と2をします。といった手順が書かれており、製品を誰でも使えるようにします。製品の汎用的な内容が書かれているので、あまり頻繁な変更がないコンテンツが基本的には書かれるかなと思います。ドキュメンテーションチームやカスタマサポートがメンテすると問い合わせ時の活用もできて良いと思います。

例えばこんなやつ。

help.twitter.com

ナレッジベースは、ヘルプセンターや開発者と似ていますが、別物だと思っています。実際にユーザや社員がプロダクトを使って、実世界に適用する際に発生するプロダクトの外と中の世界をどうつなぎこむかといった知見や、何らかのパフォーマンスをチューニングしたりといったことが書かれているようなイメージです。これは、HowToのような手順で説明できるものではないし、ツールの説明で解決する問題でもないです。 AWSのベストプラクティス(クラウドコンピューティングのアーキテクチャ: ベストプラクティス | AWS)とかがイメージに近いです。このナレッジベースは、テックサポートやプロダクト・ソリューションアーキテクトのような人たちが作っていく必要があると思います。

Q&Aは、ユーザが直接質問をしたり、サポートが普段受けている問い合わせの内容をQA形式にしたりといった形で提供します。これはカスタマーサポートがメンテすると良いかなと思います。

Zendesk GuideとZendesk Gatherはどれをカバーするのか?

さて、みなさんがドキュメントツールを選ぶ必要がでて、Zendeskをすでに使っているときには、Zendesk GuideとGatherが手軽に使えます。 しかし、用途に対して間違ったプロダクトチョイスをすると、様々な不都合が発生して疲弊します。(僕もいろんな間違いをしました・・・)

ヘルプセンターを作る場合には、、Zendesk Guideが便利だと思います。 これは、ヘルプセンターの特性上、システムの画面や機能などに頻繁な変更が行われないであるためや、管理する人たちのスキルセット的にもGUIで手軽にできるからです。一方で、サービスの高頻度アップデートによる修正変更が必要なケースや様々なコードハイライトが必要なケース、など必要な場合にはZendesk Guideは向きません。

Gatherはコミュニティの機能として提供されていますが、実質的にはQ&Aです。コミュニティの役割を定義するときに、SPACEモデルがあります。SPACEモデルとは、下記の6つのコミュニティの役割を定義しており、GatherはこのモデルのCustomer Support/Successの側面が非常に強いです。 これは機能制約の側面が強く、(2019年段階では)ユーザが任意のメッセージを投稿したりするくらいの機能が主で、他の役割を実施するには実体としてZendesk Gatherの外ですることの方が多くなるかと思います。例えばイベント開催の設定やアンケートを行なったり、などのコミュニティ運営をするための機能などはありません。また、コミュニティの貢献度に対してのリワードを作ったりすることもできないです。

f:id:toru-takahashi:20191224081126p:plain

The SPACE Model: The Framework for Defining Your Community's Business Value

まとめ

僕の文章能力だとZendeskがネガティブなイメージになっているかもしれませんが、目的が正しければそれに必要な機能は備わっているので、 みなさんが顧客に提供する"ドキュメント"を考えるときに、上記の4種類の性質を考えた上で、利用するプロダクトをチョイスすると良いのではないかなと思います。