【イベントメモ】わかりやすいドキュメントのためのテクニック〜DevRel/Japan CONFERENCE 2022から
2022年８月５日（金）〜６（土）にDevRel/Japan CONFERENCE 2022がオンライン／オフライン並行で開催されました。昨年もコミュニティやマーケティングに関する多くの知見をを与えていただいたこのイベント。今年もまた個人的に気になったセッションについて紹介してみたいと思います。
DevRelとは？
本題に入る前に少しDevRelというものについて説明します。
DevRelとはDeveloper Relations（デベロッパーリレーションズ）の略で、IT製品やサービスのマーケティング活動の一環として、製品やサービスの情報をそれらを使用する開発者に届けるための活動で、ブログやSNSの発信やコミュニティの形成など様々な活動を行っていくことです。
これらDevRelに関わるマーケター、エバンジェリスト、エンジニアなどのコミュニティのひとつがDevRel Japanであり、その大規模なカンファレンスがDevRel/Japan CONFERENCEです。
＜カンファレンスの動画です＞
パネラーの紹介
モデレータ
丸山 ひかるさん
・現職はアクイアジャパン合同会社でWebコンテンツの技術翻訳やローカライズを担当
・独立系ソフト開発会社でWebAPIの開発に関わる
・テクニカルエバンジェリストとして活躍
・「Drupal9で始めるWebサイト開発入門」執筆
宮内あかりさん
・GG Voice & Action代表
・bgrass株式会社sister事業立ち上げ担当
・もともとはデザイナーだったが2年前にITに転職
・グループワークの作成、関連する本とか映画の紹介
・プログラムを学んだことをZennに執筆
おおつかあぐりさん
・SmartHR UXライター
・老舗実用系出版社で女性誌編集と事業開発に従事
・グローバルデジタルエージェンシーでマーケ支援
・現在はヘルプページの操作マニュアルを作っている
・開発現場でUXの支援
ぴよさん
・サイボウズ株式会社でテクニカルライター
・システムコンサルティング本部と開発本部に所属
ログイン基盤のUIテキスト等
・それまでは教員⇒システムエンジニア
わかりやすさの基準とは？
あかりさん：中学生でも分かる文章を意識しています。あとは読む人がストレスを感じないような文章を書くようにしています。
ひかるさん：それぞれのバックグラウンドがある中でそれぞれの「下」にあわせるということですよね。
Zennのヒカルさんの記事でTipsを書かれるときに文章を短くする。長い文書で書いてしまいがちですね。
あぐりさん：UIテキストはユーザーが読もうと思って読んでいないのでノイズにならないように一文一義でわかりやすくするようにしています。
操作マニュアルはユーザーがドキュメントを読んだ後のゴールを考え、そこから逆算して考えたり使う言い回しを考えたりしています。
ひかるさん：業務アプリケーションって分かりづらいというなかでSmartHRさんは開発チームにUXライターをきちんと置いて、ユーザー体験をより良くするということに重点を置いてますね。
ぴよさん：一般的にわかりやすいと言われている文書にあわせる。方法論や基準に則ればわかりやすく文書をかけるのではと思っています。
ドキュメントのメンテナンスの工夫について（あかりさんの質問）
あかりさん：ドキュメント書いた配位者のメンテナンスされなくなってしまうのをよく聞きます。気が付かない人はやらないので、規模の大きな会社ではどうしてるのかを聞きたいです。
ぴよさん：気がつく仕組みとしては、社内でフィードバックを受け付ける目安箱、ヘルプサイトは常に巡回して見直しています。ドキュメントが大きくなると変更範囲が見つけにくいというのがあって悩ましいですが、ヘルプデスクはドキュメントの管理をGitで管理して変更範囲を洗い出しやすくしています。プルリクをうまく使うと便利だと思っています。
ひかるさん：社内のフィードバックを受け付ける仕組みとありましたが具体的には？
ぴよさん：Kintoneの汎用的なＤＢで目安箱のアプリを作って、社員は誰でも投稿できるようにしています。
あぐりさん：ヘルプセンターの操作マニュアルではサポートのメンバーや開発から修正のリクエストをSlackで受けてチケット化しています。社内ドキュメントの管理としては自身が参加しているスクラムチームではドキュメントのオーナーを気にせずにチーム全体で気にせずにメンテナンスしていく風土が大切。デイリーとかで決めたことをSlackでいったんメモをしていくことを習慣化しています。
あかりさん：Slackのメモ、チケット化はすごくいいなぁと感じました。
ドキュメントの効果測定の指標（ぴよさんからの質問）
ぴよさん：何をもってわかりやすくなったとか ユーザーに届いているかをいつも悩んでいます。何を持って評価しているか、どういう指標を使っているかをお聞きできればと思います。
あかりさん：数値で撮ったりはしていないですがGG Voice & Actionの活動では「問い合わせなかったら伝わっている」と考えています。問い合わせがあったときはチームでどういうふうにするかを話し合います。
あぐりさん：ヘルプセンターの方はページに対するフィードバック（役に立った）を見ています。ヘルプサイトはチャットサポートのメンバーが案内する効率を上げるのににも使うので、案内に使用した数などを使っています。
UIテキストの方はチャットサポートのメンバーにヒアリングする中で「この操作でこういう勘違いをしてしまったユーザーがいた」というようなフィードバックをもらっています。
ひかるさん：部署横断してお客さんとのタッチポイントでの改善を図っていくというのが興味深いところです。ぴよさんのところではお話できるところがありますか？
ぴよさん：まだちゃんと形にはなっていませんが問い合わせを分析して改善を図っていったり、ヒートマップからどこまで読まれているかを考えています。ユーザーさんがどこまで見たのかとか熟読エリアとかをヒートマップで見れるようなツールがあって、それをみています。
ドキュメントへのフィードバックを集めるためにしている工夫（アグリさんからの質問）
あぐりさん：ドキュメントの質を上げるためにいろんな視点のフィードバックは必要ですが、フィードバックを集めやすくしている工夫があったら教えていただきたいです。
ぴよさん：さっき言った目安箱もありますが、開発者向けのドキュメントサイトでは間接的フィードバックということで、質問用のフォーラムにきた質問をチェックています。例えばドキュメントにあるのに質問が来ているとか？ユーザーがキーにするワードが入っていなかったりとか
ひかるさん：フォーラムを用意しているのに書き込まれなかったりというのはありますか？
ぴよさん：それはないですね、認知が進んで頻繁に投稿されていて、１日に２〜３けんあったりします。
ひかるさん：フォーラムを見て質問にちゃんと回答されているのを見て安心感があるからこそ書き込みがあるんでしょうね。
あかりさん：GG Voice & Actionの活動の中ではグループワークを開催した際に毎回アンケートをとっています。センシティブな内容なのでわかりにくい文章があったかと一緒に「嫌な気持ちになった」「もやもやした」というのも毎回聞いています。
GithubやNotionやGoogleドキュメントのコメント機能を使ってフィードバックをもらう用にしています。
あぐりさん：すごい参考になりました。ありがとうございます。
質問コーナー
よい製品はドキュメントを見られっることがないケースも多いので、悦差rんされない部分は「出来の良い製品」かもしれないし、同じページを何度も観る、紹介でしていると良いドキュメントとおもっているのかな
あかりさん：たしかにAppleとかは説明書を見なくても操作ができるので、見てないことが良いことという新しい視点を得ました。
自分自身でドキュメントの評価ってどのくらいですか？
あかりさん：会社で自分自身の文書がわかり易くないと言ったことはあります。６０点〜７０点くらいかな。今度テクニカルライティングの本を読んで資格にチャレンジして８０点〜９０点撮っていきたいなと思っています。
あかりさん：SmartＨＲにもテクニカルライターの資格を持っているメンバーが居ますが私は違っていて、元のしごとで編集者だった頃にお料理とか手芸の記事の原稿でしごかれた経験があります。「原稿に書いてあることだけで再現してちゃんと料理が作れること」と鍛えられているので操作手順は割と書けていると思います。スピードも含めてそこそこ出来ていると思います。
ぴよさん：及第点は取らせてあげたいと思っています。検定は取ったりして努力はしています。その時毎に求められていることが違うので常に知識を吸収して反映させていかないとならないと思います。
この記事が気に入ったらサポートをしてみませんか？