freeeのヘルプページをバラバラにしてみた話
freeeのヘルプページは、少しずつ改修が進んでいます。昨年は画面デザイン、記事の階層構造を大幅に改修しました。
ただ、肝心の「記事の内容」自体には手を付けられていませんでした。そこで今年の2月に、ヘルプページの記事の内容を改善するという仕事を任せてもらいました。
いろいろ調べたところ、「1つの記事に多数の内容を詰め込みすぎており、ユーザーが該当の記述にたどり着きにくくなっている」という課題感がありました。
そこで、一部の「内容が詰め込まれた記事」を分解して切り出すことで、記事のタイトルと内容のギャップが少ない状態にし、目的の情報にたどり着きやすくしました（4ヶ月後の6月1日にリリース）。
サラッと書きましたが、無数の記事がある中で、記事ごとの個別具体的な課題と記事間に共通する課題を切り分け、後者を適切に言語化し、それを解き、改善インパクトを出すまでのプロセスはなかなかハードな道のりでした。
ハードだったぶん、成長に繋がるいい経験ができたので、忘れないうちに4ヶ月間の紆余曲折を振り返ろうと思います。
課題の言語化
大まかな方向性を決める(2月上旬)
ヘルプページは「プロダクトを使う中で分からないことを解決する」ために存在しているため、ヘルプページにおけるクリティカルな課題は以下の2つと考えました。
①欲しい情報にたどり着きにくくなっていること
②そもそも欲しい情報が載っていないこと
①の「たどり着きにくい」という課題は、ヘルプサイトの「検索精度」の問題だと思って、今回の「内容改善」のスコープ外とし、②に取り組もうと思って走り出しました。各記事で不足している情報を追加していくという方向性です（あとになって、この判断が大きな間違いだったことに気が付きます……）。
記事単位での改善の検討（2月下旬）
いきなり全記事（2600記事）を対象にするのは無理なので、いったん「口座*」というカテゴリーに属する記事（100記事）に絞って改善することにしました。
*freeeに銀行口座やクレジットカードを連携することができますが、便宜上これらをまとめて「口座」と呼んでいます。
改善する記事を決め、「その記事をみたユーザーの（サポートデスクへの）問い合わせ内容をみる→その中で記事に載せられていない情報があれば載せる」という作業をすれば、各記事で不足している情報を補っていくことができるな、という段取りでいました。
実際に１つの記事（記事Aとします）で、この作業をやってみました。
しかし、実際に記事Aを訪問したユーザーの問い合わせを見てみると、「記事Aとは関係ない記事Bや記事Cの話」になっている場合が多く、記事Aの改善につながるような問い合わせが全然ありません。。
おかしいなと思ってユーザーの行動データを見てみると、「記事A→記事B→記事C→記事D→記事A→サポートデスクに問い合わせ」のようになっている場合がほとんどで、腑に落ちました。
つまり、「記事Aを訪問したユーザーの問い合わせを見る」といっても、いろんな記事を見回る中で一度でも記事Aを訪れていれば記事Aの問い合わせとしてカウントされるため、問い合わせ内容が記事Aの話だとは限らないということでした。
このように、「記事Aに紐づく問い合わせだけを抽出する」ことができないため、「記事単位の改善は現実的ではない」という結論を出し、別の方法を考えることにしました。
問い合わせ起点での改善の検討（3月上旬）
今度は、問い合わせを起点とした改善を考えました。
サポートデスクへの過去の問い合わせは、「同期エラー」「残高ずれ」など、カテゴリー分けしてストックされています。
カテゴリー別に問い合わせ件数を集計することもできるので、「問い合わせが多いカテゴリーを調べる→そのカテゴリーの問い合わせを1つ1つ見て、『適切な記事』に情報を追加する」という方法で改善していくことができると思いました。
ただ、どの記事が「適切な記事」になるか分からないため、「ピンポイントに記事を選んで改善することができない」ことがデメリットでした。が、実際にやってみると、前章の「記事単位の改善」よりは現実的だったので、「できなくはないから、これでやっていくか〜」と思っていました。
ただ、この方法はなんとなく根本的なソリューションになっていない気がして、モヤモヤしました。喩えるなら、「大きな穴の空いたバケツに、上からちょろちょろと水を入れようとしている」ような違和感がありました、、。
”一意性”というセンターピンにたどり着く（3月下旬）
違和感を抱える中、「そういえば記事内容の改善をしようとしているのに、実際の記事の中身をしっかり見たことってあんまりないよな」と思いました。
一度中身をじっくり眺めて、「今回解こうとしている課題はなんなのか」を改めて考えることにしました。
ユーザーもfreee社内の人も含めて、ヘルプページの内容に課題を感じている人はたくさんいると思います。たとえば、記事の下の方に「参考」という見出しが大量にぶら下がっていたり、、
表が延々と続くヘルプページがあったり、、
こうして実態をみていると、冒頭で課題として挙げた以下の２つのうち、前章まででフォーカスしていた②「そもそも欲しい情報が載っていないこと」よりも①「欲しい情報にたどり着きにくいこと」のほうが、「課題の大きさ」としてはよっぽど大きいような気がしてきました。
①欲しい情報にたどり着きにくくなっていること(こっちの方が大きそう)
②そもそも欲しい情報が載っていないこと
ここで、記事単位での改善を考えたときに「記事A→記事B→記事C→….」という回遊が起こっていたことを思い出しました。これは「欲しい情報にたどり着いていない」という課題が具体的に表れている現象です。
なんで回遊がおこっているのかというと、ユーザーの「この記事に欲しい情報が書いてありそう！」という期待を（回遊している回数ぶんだけ）裏切っているからです。
ユーザーは何をもってその期待をしているのかというと、おそらくタイトルです。ユーザーはタイトルを見て「この記事に欲しい情報が書いてありそう！」と思うはずです。
ユーザーが該当箇所にたどり着くまでの流れは、「検索する→記事を開く→該当箇所を読む」だと粗く、「検索する→タイトルを眺める→記事を選んで開く→該当箇所を読む」になっていることを、今まで見落としていました。
当初「たどり着きにくいこと」の原因をサイトの検索精度のせいにしていましたが、実際は検索精度だけのせいではなく、タイトルと記事の中身にも原因があると思いました。
そこで、口座カテゴリーに属する100記事を、「本文に対して、適切なタイトルになっているか？」という観点ですべて読んでみました。
すると、やっぱり本文とタイトルがずれているものが多かったです。特に、「多数の内容を詰め込みすぎていて、タイトルと本文がずれてしまっている」記事が多かったです。たとえば、「銀行やクレジットカードを登録する（口座を登録する）」というタイトルの記事に、なぜか「口座の並び順を変更する」という内容が含まれていました。
このような「タイトルと本文のずれ」をなくすことで、ユーザーの「この記事に欲しい情報が書いてありそう！」という期待に応えれば、回遊が起こるという課題を解決できそうだと思いました。
────まとめると、「記事A→記事B→記事C→……」という回遊が起こっていること自体が課題で、その課題は「タイトルをみて想像する本文の内容と、実際の本文の内容にずれがない」ようにすれば解決できるのではないか、という仮説が立ちました。
この仮説を検証するために、「多数の内容を詰め込みすぎている記事を分割することで、本文とタイトルを一意な状態にする」作業を行うことにしました。
ソリューションの実行
分割の議論（4月）
このタイミングで、社内でも特にプロダクトの仕様に詳しいメンバーを3人集め、分割の議論を進めていくことにしました。
また、分割する対象は、口座全部だと多すぎるので、銀行・クレジットカードの登録・同期というセクションに属している13記事だけしました。
「分割する」とだけ聞くと単純な話のようですが、意外と大変でした。難しかったのは、記事内で「条件分岐」がある場合と、操作が「一連の流れ」になっている場合の２つです。
条件分岐がある場合
まず、記事内に条件分岐がある内容について、例を挙げながら説明しようと思います。
たとえば、「freeeに同期非対応の金融機関」を利用している場合は、freeeに明細ファイルをアップロードして対応します。この明細ファイルを、金融機関側からダウンロードできる場合とできない場合で操作が異なります。
問題になるのは、この場合分け（条件分岐）の内容を「別々の記事にするか、まとめて載せるか」ということです。
厳密に一意にする（ひとつの記事にひとつの内容）ことを考えると、この２つは別々の記事にするべきかもしれませんが、ユーザーは「記事を読む前に条件分岐があることを知り得ない」と思ったので、まとめて載せることにしました。
今度は、「プライベートでも兼用している銀行口座やクレジットカード」をfreeeと同期している場合の操作です。
プライベートでも兼用している口座の動きに関しては、ユーザーが個人事業主か法人かで会計処理が異なりますが、ユーザー自身で個人事業主か法人かということは当然判断できるので、以下のように記事を分けました。
このように考えると、「一意」というのは、「"客観的に"一意」ではなく、「"ユーザーにとって"一意」という意味であることに気が付きます。
内容によって正解が異なるので、条件分岐があるときは、分割する/しないの議論を慎重に行いました。
操作が「一連の流れ」になっている場合
次に、操作が「一連の流れ」になっている場合についてです。
たとえば、freeeに口座をはじめて登録する場合、基本的には以下の3ステップを踏むことになります。
1.そもそも口座として登録するべきどうか判断する
2.freeeに口座を登録する
3.口座を同期する
問題は、これらの操作を3つの記事に分けるか、それともまとめるかということです。「ユーザーにとって一意」にすることを考えると、freeeにはじめて口座を登録するユーザーの9割以上がこの手順を踏むので、ここでは「まとめて載せる」ことにしました。
────このような観点を中心に、プロジェクトメンバーで慎重な議論を重ね、13記事を30記事に分割し、記事の成形までしました。
被リンク対応とリリース（5月）
さて、分割して終わりかと思いきや、そうではありません。
ヘルプページの記事は色んなコンテンツでリンクとして使われています。例えば、他のヘルプ記事、プロダクト、他事業部が作っている資料やサイト、、、などがあります。
今回の施策によって、「これらのコンテンツに記載されているリンク（以下「被リンク」と呼びます）の遷移先が微妙に変わる」ということが起こりえます。
そのため、プロダクト、マーケ、サクセス、サポートなどの各チームに今回の分割施策について共有し、一部リンク差し替えなどの対応をしていただきました。各チームの皆さま、ご対応ありがとうございました🙇♂️🙇♂️
（詳細は割愛しますが、この被リンク対応のコミュニケーションが思っていたより大変で、こちらの記事にある「走っている電車を止めずに改造し続ける難しさ」という言葉を肌で感じました。。）
被リンク対応を終えて、ようやく6月1日に今回の分割施策をリリースできました！
リリースしたら厳しい意見をいただくのではないかと内心ドキドキしていましたが、予想以上に好意的な声が多く、ホッとしました。。
効果測定
リリースから1ヶ月が経過したタイミング（7月1日）で、施策の効果測定を行いました。
該当記事を訪問したセッション（独自指標）の、1セッションあたりの「回遊ページ数*」の変化は以下のようになりました。リリース後は「4」を上回ることがなくなり、わずかですが、いい影響が出ている（=回遊が減っている）と言えそうです。
*例えば、「記事A→記事B→記事C」と回遊すると、回遊ページ数は3とします。
また、該当記事を訪問したあとの（サポートデスクへの）問い合わせ数は（5月）38件→（6月）25件に減少しました。
少なくともネガティブなインパクトはなさそうで安心しました。。どれくらいポジティブなインパクトだったかは、判断にもう少し時間が必要そうなので、今後もウォッチします。
さいごに
今回のプロジェクトがいままでの改修と決定的に違ったのは、改悪になるか改善になるか分からなかったというところでした。プレッシャーが大きかったです。
ですが、freeeに関わる多くの人が、「なんか読みにくい」「なんかゴテゴテしている」と感じていたものを、解決策まで含めて言語化し、実際にアウトプットまでできたのはよかったなと思います。
私はこの７月からヘルプページチームから離れることになってしまいましたが、これからもどんどんfreeeのヘルプページは改善されていきます！！
かなり長くなってしまいましたが、ここまでお読みいただきありがとうございました〜！
（追記）
ヘルプページチームには、日々社内からの更新・修正依頼に対応する保守運用オペレーションがあります。
本記事中の「問い合わせ起点での改善」についても、今回の分割施策とは別に今後着手していく予定です💡
・・・・・
この記事は、「あえ共freee」というマガジンに投稿するために書いたものです。freeeでは色んなことを"あえて"共有しています。
面白い内容の記事ばかりなので、ぜひこちらも覗いてみてください👀
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？