ドキュメントを書く上で重要なのは「ユーザー理解」
岩瀬義昌氏：ということで、さっそく本題にいきますね。1章、まずは読み手の理解です。これが本書全11章の中で圧倒的に大事です。なぜかというところも踏まえてしゃべっていきますね。
（スライドを示して）ドキュメントを書く上で一番大事なのは、誰が読み手か、どのユーザーが読むのかというユーザーを理解することなんですよ。もう1回言うんですが、ユーザーは誰なのか、そのユーザーは何を達成したいのかをきちんと理解するのがめちゃくちゃ大事です。
というのも、ユーザーは別にドキュメントが読みたいわけじゃなくて、何かその先にある課題やニーズを解決したいからこそドキュメントを読みにくるわけですよ。だから、ドキュメントによって何を解きたいのかを、あらためて理解していかないといけないですよね。これを理解ができていないと、無価値なドキュメントが爆誕し続けます。悲劇が起きます。
（スライドを示して）書籍のアウトオブスコープ、範囲外からの引用なんですが、「ビルドトラップ」という言葉があります。これは私も一緒に仕事している@ryuzeeさんのスライドからの引用です。
作っているだけでユーザーの価値につながらないようなプロダクト、機能が備わらないことをビルドトラップと言っているんですが、その兆候の3つ目に「必要性のわからない機能」と書いてあるんですよ。
先ほどプロダクトの（話の）中で「ドキュメントは機能の一部だ」と言ったんですが、必要性のわからないドキュメントを作り続けると害でしかないので、徹底的に考え抜くのは大事だと思います。
どうすればユーザーを理解できるのか？
（スライドを示して）「ではどうやればユーザーを理解できるんですか？」という質問に当然つながっていきますよね。書籍の中ではたくさん紹介されているんですが、代表的なものとして、だいたい5個ぐらい紹介されています。
（スライドを示して）例えば、自分のチーム内でのチャットでの会話ログや、プロダクトの設計メモ。プロダクトを作る以上は目の前じゃなくて、その先にあるユーザーのことを当然考えながら作るので、必ず何かしらのログが残っているはずです。
それであれば、インタビューメモがあるはずですよね。ユーザーに対するインタビューメモ。課題をヒアリングで抽出する部分です。あとはメールやコミットログとか、本当にいろんな情報があるので、このあたりをあらためて見直ししていくと「僕ら、私たちの狙っているユーザーはこういう人たちだったな」という、「ユーザーは誰か」というところと、彼らが成し遂げたいこと、「プロダクトを使ってやりたいことはこうだ」とわかってくるはずです。
ここまではあくまで仮説です。「こうなんじゃないかな？」という仮説なので、なるべく早く検証したいです。検証は基本的に早ければ早いほどいいです。というのも、プロダクトを作り切ってから直すのはめちゃくちゃ大変じゃないですか。エンジニアであるみなさんは知っていると思いますが、めちゃくちゃ大変なので、なるべくシフトレフトして検証したい。
ユーザー検証の方法
だから次にユーザー検証に進むわけですよ。ドキュメントを書き始める前にユーザー検証（をする）ということですね。ユーザー検証をするにあたって、できるのであれば一番良い方法はしゃべることです。ユーザーと直接対話すること。「なかなかそんなチャンネルないよ」と思われるかもしれませんが、意外にあります。
例えば、既存プロダクトがあればカスタマーサクセスがいるかもしれないので、サポート経由（でヒアリングする）とか。あとは、サポートチケットもその1つですね。ユーザーとチャットで会話できるところ。インタビューやアンケートも1つの対話方法ですよね。このあたりで仮説検証をしていくと、より効果的なドキュメントを作りやすくなるので、ぜひここには力点を置いてもらえると良いかなと思います。対話ができると情報がたくさん集まってくるので、それをギュッと圧縮しておくと良いですね。
（スライドを示して）いっぱい（情報の）まとめ方はあるんですが、ペルソナやユーザーストーリーや、ユーザージャーニーマップ。カスタマージャーニーマップと日本では言われたりしますね。これをまとめておくのはけっこう大事で。なぜかというと忘れちゃうし、情報量が多すぎるんですよね。なので、一番重要な情報をギュッと圧縮してまとめておくのは良いプラクティスかなと思います。
（スライドを示して）「あまりこのあたりの（まとめ方についての）ことは見たことがないよ」という方向けに、「ChatGPT的に作るとこんな感じです」というものをサンプルを出しています。今日は細かいところはしゃべらないですが、こんなふうに作れます。ユーザーストーリーはこんな感じです。
「ユーザージャーニーマップはこんな感じです」という例も作ってあるので、興味があればあとで資料を見てもらえるといいかなと思います。
ユーザージャーニーマップの縦軸と横軸
一応このユーザージャーニーマップは縦軸と横軸が重要なのでしゃべっておくと、横軸は時間軸の流れです。「ジャーニー」なので旅路です。左上側に認識・認知ってありますよね。見えているかな？ 認識・認知があって、あとは興味・関心とか評価・検討。
評価・検討した上で「価格がちょうど良いな」と思ったら、決定・購入の意思決定につながり、実際に使ってみる。使ってみて良ければ継続して利用して、かつ、さらに言うと周りに広めてくれる。口コミとかの推奨が走りますよね。というのが、プロダクトに対する一連のユーザージャーニーの流れになっています。
それに対して縦軸は何かというと、先ほどの各フェーズの中でその時ユーザーはどんな疑問を描いているのかとか、あとはインタラクション、ユーザーとプロダクトの接点ですね。例えばニュース記事を読んで知るとか。そういう接点が書いてあるのがここです。その時にどんなことをユーザーが思っているのかという感情が書かれています。
さらに、最後に書いてあるのが、「それに対して我々は何をしたらいいんだ」という改善のアクション案です。一番下のところですね。こういうユーザージャーニーマップを書いておくと、実際に何かプロダクトに対して施策を打つ時に効果的になるので、参考までに紹介しておきます。
おまけでもう1個。たまに感情を線で書いておくというやり方もあるので紹介させてください。たまにというか、そういうやり方があります。これを書いておくとネガティブなところを直しに行くという集中ができるので、これもその1つ（のやり方）です。
ユーザー理解の時には「知識の呪い」に注意
ここまでがユーザー理解のポイントですが、1章にもう1個だけ超重要なところがあるので、ここだけ紹介して1章を終わります。何かというと「知識の呪い」という概念があります。認知バイアスというものの一種で、どこかで聞いたことがあるかもしれません。
簡単にしゃべると、「こんな経験ありませんか？」という例から理解できます。何かというと、例えば同僚が耳慣れない専門用語を使っているとか、あとは同じチームの「README」であれば、開発環境を作る手順について「これぐらいだったらわかるでしょ？」と言う点が書かれていなくて、実際に手順書を見てもぜんぜんわからないし、しかも教えてくれないみたいな。
同僚はたぶん（相手が開発環境を作る手順を）知っていると思っているんですよ。悪気はないんですよ。知っているし、「これぐらいできるかな？」と思っているから教えていない。というのも、逆に教え過ぎると「『こんなことも知らない（のか）』って舐められている」と思う方もいるかもしれません。その可能性もあります。
（スライドを示して）最後のところは、例えばデバッグエラーメッセージで、「『デバッグして』と言われたけれど、エラーメッセージだけを教えてくれて。あとは『検索すればわかるかな』ぐらいの気持ちでやっているんですが、他の必要な背景情報は伝えてくれない」みたいなことはあったかもしれないです。
これは先ほども言いましたが、悪気はないんですよ。おそらく知っていると思っている。これが知識の呪いです。本当は知らないんだけど「これぐらい知っているんじゃないかな？」と思い込んじゃうのが知識の呪いで。
書籍を読むと実際に（このことに関する）研究結果も公表されていて。思ったより相手は知らないです。ただ、書き手、作り手のほうは厄介なことに「これぐらい知っている」と思い込んじゃうというバグがあって。これが知識の呪いです。
「知識の呪い」を断ち切る方法
「じゃあこれをどう断ち切ればいいですか？」という話になっていきます。断ち切るために重要なのが、ユーザーの理解なんですよ。ユーザーへの共感です。「このぐらい知っている」ということをユーザーの解像度が高く理解できていればわかるはずなので、だからこそユーザー理解がメチャクチャ重要です。
もう1個だけ断ち切る方法が紹介されているのを紹介しておくと、フリクションログを作る方法があります。「フリクション」は英語で「摩擦」という意味です。プロダクトを作る時に、「なんかこれは使いづらいな」と思うところがたまにありますよね。これをログとして記録したのがフリクションログです。
（スライドを示して）イメージとしてはこんな感じのログになっていて、上から下に示した手順書だと思ってください。手順書を使った時に、「なんかサインアップページがぜんぜん見つからないな」みたいなところをログとして自分で書いていくわけですね。特に使いづらいところを赤字で書いておくとわかりやすくなるかなと思います。ここまでが1章です。
1章に関する補足
次から次に3章とかをしゃべっていくんですけど、先にちょっと補足を1個しておきますね。1章をずっと読んでいると「あれ？ これはユーザーマニュアルとか、社外の顧客やプロダクトを使う方に提供する時だけのドキュメントなのかな？」と思われる方もいるかもしれません。それはそれでけっこう量が多いのは事実ですが、自分の開発チームに対してもリフレームするとけっこう使えます。
何かというと、例えば社内向けに開発環境の構築手順書を作る機会があると思うんですよね。これはただ単に読み手が社内の開発者になるだけなので、「応用できるな」と思うところはあると思います。なので、応用可能だというところだけは補足しておきます。1章が終わったので、次にいきますね。
（次回につづく）
