言葉のこぶし👊で理解（わか）らせろ！SmartHR式、UXライターの流儀
はじめに 〜祈り〜
言葉は神だ。
僕は毎週祈っている。
日曜日のプ○キュアのコマーシャル中、セコ○ヤチョコレートのアシッドなロックチューンで脳をトロトロに溶かしながら祈っている。
言葉は神だ。
唯一ヒトに所有されることを許す神。
ヒトが扱うことを許す。ヒトが発することを許す。
唐突に「メチャウ○ーメイド！」とか「ト○ピカル〜ジュ！」とか奇天烈なこと言っても許す。
しかし、言葉は神だ。
ヒトには容易に御せぬ力がある。
現に、記事がはじまってほんの数行で、言葉に惑わされた僕は何を書きたかったのか見失っている。
おそろしい力だ。男の子だってお姫様になれる。
日曜の朝（概念）からこんにちは。SmartHR VP of ProductDesignのおうじです。
2022年からSmartHRの開発組織もいろいろと体制面で変わりまして、今年よりプロダクト／プログレッシブの両デザイングループに加えて、UXライターたちの組織（UXライティンググループ）もお手伝いさせてもらうことになりました。
よい子のみなさんはUXライターというおしごとを知っているかな〜？
プロダクトにおけるマイクロコピーやメッセージ、つまり「言葉」を考えるおにいさんおねえさんたちのことなんだねぇ〜（突然のニチアサ口調）
今日は「言葉」を軽やかに使いこなし、ユーザー体験をHUGっとハートキャッチしてハピネスチャージするUXライターたちのデリシャスパーティーを紹介したいと思います。
冒頭から何を書いているのか僕も本当にわかっていませんが、少なくともこの記事では以下のことがわかります。
SmartHRにおけるUXライターの業務内容
なぜプロダクト開発でUXライティングが必要なのか
UXライティングとテクニカルライティングの違い
UXライターとプ○キュアの宇宙的因果関係
少しでも興味のあるトピックがあれば、ぜひ最後まで読んでもらえるとうれしいです。
SmartHR UXライティンググループの現在地
SmartHR UXライティンググループは、2020年8月にまずはSPグループ（チャットサポート）内のいちユニットとして誕生しました。
当時、SPグループではチャットサポート業務と並行してユーザーがプロダクトの困りごとを自己解決するためのヘルプページ作成も行なっており、現在のUXライターたちが主に執筆をリードしていました。
ヘルプページのようなユーザーが「困ったとき」のサポートだけでなく、ユーザーが「困る前」にプロダクトでサポートするために、グループとしても職能としても独立したのが2021年10月。
現在では開発チームの中からプロダクトUIのマイクロコピー設計や、ヘルプページのコンテンツコントロールを行なっています。
詳しい方針や未来像はマネージャーのotapoさんがまとめてくれているのでこちらもご覧ください。
メンバーに聞く、UXライターのおしごと
ここからは、より具体的にUXライターのお仕事とその威力を知ってもらうため、現グループメンバーのうち2名にインタビュー形式でお話を聞いていこうと思います。
メンバーの紹介
keroyama
農学府で昆虫病理学を研究したのち、「難しいことを噛み砕いて人に伝えることが好きだ！」と気づきマニュアル制作会社にテクニカルライターとして就職。3年半ほどさまざまなマニュアル・ヘルプのライティング・ディレクションに従事。 2021年1月にSmartHRにUXライターとして入社し、SmartHR基本機能を担当。 趣味はペットのインコを吸うこと。
8chari
制作会社でテクニカルライターとして、システム管理者向けソフトウェアのマニュアルを7年ほど担当し、アジャイル開発の現場を経験。同社の別プロジェクトでPMOを経験した後、電機メーカーで複合機のマニュアル制作のディレクションに従事。2021年6月にSmartHRにUXライターとして入社。趣味は妄想の中で猫を飼うこと。
UXライティングってなに？
おうじ「今日はよろしくお願いします。まずはおふたりから見たUXライティングという領域について聞きたいのですが、ざっくり説明をしてもらえますか。」
8chari「ざっくり言うと、『プロダクト開発において、ユーザーの目に触れる言葉を考えること』ですかね。」
keroyama「加えて、SmartHRは業務アプリケーションなので、ユーザーの業務がきちんと達成されるようにガイドするような言葉をデザインすることが多いですね。（すぅ…はぁ…）」
おうじ「keroyamaさん、どうしましたか？」
keroyama「飼っている…（すぅ）…インコを…（はぁ）…吸って…（んすぅぅ）…ます…（むはぁ）」
おうじ「…ほどほどにお願いします。」
UXライターとしての日々
おうじ「ではより具体的に、おふたりが日々会社でどのように過ごしているかを教えてください。」
keroyama「他のUXライターもそうですが、基本的には開発チームのスクラムイベントやフィーチャーに合わせて動くことが多いですね。デイリー、プランニング、スプリントレビュー、リファインメント、レトロスペクティブといったすべてのスクラムイベントに参加しながらチームと協働しています。」
※SmartHRではスクラム開発を導入しています。
スクラム開発の社内実践についてはSmartHR Tech Blogにてたくさん紹介しているのでぜひ読んでみてください。
おうじ「（急に真面目だな…）UXライターとして各スクラムイベントではどういった役割を開発ステークホルダーから期待されているのでしょうか？」
keroyama「スプリントレビューでは画面の文言についてのフィードバックもよく出るので、その文言にした背景の説明や議論のリードを主に行ないます。
プランニングでは具体的にどんな文言を画面に載せるのかを設計したり、機能をリリースするにあたってヘルプページを準備しておくべきかどうかをチームで検討したり。
レトロスペクティブではプロセスの困りごとを議論することが多いですね。
特にUXライターは開発チームに入って日が浅いので、エンジニアやPMと協働するにあたってまだまだ働き方をチームでチューニングしていかないといけないことが多いんです。」
おうじ「開発チームで他職種と協働していくにあたって、具体的にチューニングが必要なことってどんなことなんでしょう？」
keroyama「実際にヘルプページの作成・修正タスクが発生したときにチームとしてどう解決していくべきか、というところが多いですね。
私自身、いまは複数のチームを兼務で担当している状態なので、いつでも即座に作業者になれるわけではありません。チームでヘルプページ作業を担保していくためにいろいろと試している最中なので、『このときのやり方はどうだった？』や『もっとよい進め方はないか？』をよくチームとコミュニケーションしています。」
おうじ「なるほど。開発チームと協働する機会が多い一方、個人で持つタスクとしてはどんなものがあるのでしょうか？」
keroyama「まずはプロダクトの画面に現れる文言を作成するにあたってのリードですね。あえてリードと言っているのは、一人で黙々と作業して決めることはあまりないからです。大抵の場合はチームで一緒にFigmaのデザインモックを触りながら複数パターン検証していきます。大まかな方針をチームで合意してから、最終的に細かい“てにをは”などを個人で仕上げますね。
次に、ヘルプページの作成タスクがあります。プロダクトインターフェースの提供だけではユーザーに伝えきれない仕様や、機能・画面をまたいだ網羅的な説明をヘルプページのコンテンツとして執筆していきます。ユーザーはプロダクトの導線からヘルプページへ遷移してくることも多いので、ただのコンテンツとしてだけではなくプロダクトの一部として機能するように設計していきます。
あとは、全社で活用するライティングガイドの制定・更新タスクなどもありますね。」
おうじ「結構盛りだくさんですね…。8chariさんも動き方としては同じような内容でしょうか？」
8chari「そうですね。概ね同じような内容ではありますが、私のチームの場合だと一緒にマイクロコピーの重要性に対する感度を高めようという活動が頻繁です。私の役割としてはいわば『痛覚を入れる』ようなものでしょうか。」
痛くなければ覚えませぬ
おうじ「痛覚、面白そうな観点ですね。具体的にはどういった活動を行なっているのでしょうか？」
8chari「まずチームに痛覚を入れようと思った経緯からなんですが、私たちUXライターには画面を見て『これはユーザー迷うぞ〜、問い合わせ増えるぞ〜』と予測できるポイントがいくつかあるんです。それらをチームで解決していくにあたって、きちんと全員が腹落ちした状態を作りたいと考えているんです。
専門家が言っている『なんかヤバそう』ではなく、チーム全員が直感する『マジでヤバい』にするには、放置したり改善しないでおくとどんなデメリットがあるのかを全員で体感する必要があります。」
おうじ「先回りして専門家がじゃんじゃん解決してしまうと、痛みやヤバさが伝わりませんものね。」
8chari「次に、具体的に行なっている活動ですが、主にSlackなどで自分の作業を開示しています。Working Out Loudなどと呼ばれる作業法に近いのですが、作業内容はもちろん、自分が危惧していることや、修正していくうえでいま考えていること、迷っていることをあまさずスレッドに書き留めておいて、マイクロコピー設計における考え方をオープンに見てもらっています。」
おうじ「ワークショップなど単発で体系的に伝えるのではなく、いま目の前にある痛みを伝える、と。」
8chari「怪我の予防法を伝えるよりも、いまばっくり開いてる傷を見せたほうが痛そうですからね。うふふ。」
おうじ「（怖い…）つまるところが痛みをチームで体感するという話だと思うのですが、マイクロコピーやメッセージ起因で実際に起こった『痛みのあった』エピソードを聞いてみたいです。」
keroyama「以前、SmartHRのプラン改定に伴ってユーザーへ機能制限を伝えないといけないシーンがありました。重要なお知らせなのでプロダクトにもメッセージを表示していたんですが、そのメッセージでは「とある機能が使えなくなる」ということが強調されるものになってしまったんです。結果、多くのユーザーにネガティブな印象を与えてしまって…。（すぅはっ、すぅはっ）」
おうじ「（またインコ吸いはじめたな…）あー、覚えてます。実際はドラスティックに機能制限されるわけではなくいろいろと回避策や使い方をアレンジする余地はあったんですよね？」
keroyama「そうです。ただ、そのときは仕様と事実を正確に伝えようとするあまり、ユーザーの認識を先回りできていませんでしたね。機能としては妥当なものを出しているので障害というほどではないんですが、少なくともユーザーに確認の手間を取らせてしまったし、社内でも問い合わせ対応コストは増えてしまいましたね。」
おうじ「情報の妥当性や永続性だけでなく、ユーザーのその場その場の認知の仕方にも寄り添う必要があるとは、かなり考慮することが多いですね…。」
開発チームの一員になるべき
おうじ「そういえば、インタビュー開始以前から自然に受け入れていましたが、UXライターが開発チームの一員としてエンジニアやPMと一緒に協働したり、スクラムイベントにもレギュラー参加するのって割と普通のことなんですか？」
8chari「少なくとも、私の経験ではあまりない体制ですね。」
おうじ「へぇーっ、そうなんですね。どうしてSmartHRのUXライターたちはいまのような働き方になったのでしょうか？」
8chari「個人的な背景で言うと、私の場合は『テクニカルライター』が出自なので、当時の働き方や製品開発の進め方をもっとアップデートさせたい、という思いが組織に反映されているかもしれません。
『テクニカルライター』って、要は製品のマニュアル（説明書）を作る人たちなんですけど、マニュアル作成って製品仕様がある程度かたまらないと制作を開始できないことが多く、後工程になりがちなんです。
そうなると必然的に、マニュアルを作っている最中に製品の使いづらい点やつまずきポイントをみつけたとしても、その頃には直接製品を改善できなかったりする。
私たちはユーザーの行動に基づいてそうしたポイントを発見し、補足説明を行なってきました。でも、それってそもそも製品が使いやすかったら補足説明すら不要ですよね。
だからこそ、説明不要な製品を作るために一緒に開発するべきなんです。」
おうじ「背景を聞くと、とても本質的な体制に思えますね。実際にいまの体制になってみて、見えたことやわかったことってありますか？」
8chari「まず、ユーザーの『わからない』を先回りして解決できるという、提供タイムライン上のメリットが大きいということがわかりました。
先ほど『痛み』の話をしましたね。おかしな言い回しですが、ユーザーの痛みって現実にあるんです。でも実際に痛みを感じるのは製品提供タイミングのずっと後。
私たちUXライターはその『将来訪れるであろうユーザーの痛み』を察知しながら成果物を出すことができる。これってサービス提供事業としてはすごいメリットですよ。」
おうじ「落とし穴を未然に防ぐ。ユーザーの離脱率が重要なKPIであるSaaSならではですね。」
8chari「また、UXライターの目線で言うと、開発やユーザーのコンテキストがあるとないとでは成果物の品質が大きく変わってきますね。
私たちは『落とし穴』の事前発見はできるけれども、それを処理するにはユーザーがどうやってその落とし穴に足を踏み入れるのかや、開発する中でどうして落とし穴になってしまったかという情報が必須です。
それを知ったうえで処理方法、もとい、解決方法を考えられることにメリットを感じますね。」
おうじ「たしかに、UXライターの価値を発揮しやすそうな環境ですね！」
ふたりはUXライター（ときどき、テクニカルライター）
おうじ「またそもそもの話なんですが、先ほどの8chariさんの言葉の中に『テクニカルライター』という職種が登場しましたが、UXライターとはどう違うのでしょう？」
8chari「ものすごく一般化した表現をあえてするなら、対象とするユーザーの違い、ですかね。
テクニカルライティングでは『困りごとのある』ユーザーを対象とした文章作成を行ないます。困っているユーザーがマニュアルやヘルプページといった場所にたどり着くことが前提なので、読んでもらうための文章を書くことになります。
一方、UXライティングでは『困る前』のユーザーを対象とした文言設計を行ないます。まだ困る前のユーザーはこれまでの学習経験を用いてプロダクトを順調に触っているので、言葉を事細かに読むことはしないんです。だからなるべく視覚情報としてわかるテキストを設計していく必要があります。ビジュアルやシグニファイア*をデザインしていると言ってもいいかもしれません。」
※シグニファイア = インターフェースが「どのようなことができるか」や「どのような振る舞いをするか」をユーザーへ示唆するサイン、手がかりのこと
おうじ「テクニカルライティングとUXライティングの違いを聞いてまた新しい疑問が湧いてきたんですが、実際おふたりはUXライティングをしている人でありながら、ヘルプページのような『読んでもらう』文章作成もしていますよね？それをするにあたって考え方や役割を切り替えたりしているということですか？」
8chari「私の場合は、切り替えているというよりも、テクニカルライティングをベースにUXライティング領域へジャンプしている、という感覚に近いかも。双方の違いを明確にすると遠そうには見えるんだけど、ユーザーにとっては両方必要なことだし、やるべきことなので。」
keroyama「私は結構切り替えているかも。対象ユーザーの状況やメンタルが違うということは、提供側であるこちらの出力（アウトプット）も変わってくる。
自分でもユーザーとしての経験があるんですが、困りごとのあるユーザーには『怒り』があることも多くて、感情をきちんと理解したうえで寄り添ったテキストを書く必要が絶対に出てきます。
一方、まだ困っていないユーザーに対しては限りなく『透明な』テキストの方が操作のノイズにならなくて良い。フラットであることの方が価値が高いんですね。（すっはっ、すはっ）」
おうじ「なるほど。捉え方は違えど、ユーザーのために両方のアウトプットが必要とされることはとても理解できました。
…そろそろkeroyamaさんの様子がおかしいので今日はこのあたりにしておきましょうか。おふたりともありがとうございました。」
8chari「…ありがとうございました。」
keroyama「むはっ、むほふはっ、はふっ！（ありがとうございました！）」
おわりに 〜誓い〜
言葉は神だ。
僕は誓う。
金輪際、日曜朝に放映している某アニメをnoteのネタにしないと。
正直あんまり観たこともないし、パンチラインを探るためだけに無理してめちゃくちゃ調べる羽目になった。
言葉は神だ。
僕は誓った。
もう二度と元社長を真似て「日本語メタルコーナー」などやるまいと。
前回の記事でやってみたものの見事にスベり散らかしたから。
しかし、言葉は神だ。
スベったことを公言した途端、「楽しみにしていたのに…」という言葉が現れてしまった。
言葉という神が顕界してしまった。
ならば、従う他ないだろう。
本当はいやだけどね。
本当だよ？
というわけで、誰にも求められていない日本語メタルコーナーです。
今回紹介するのは関西発のフューネラル・クラシカル・メタルバンド、夢中夢の代表曲『眼は神』です。
この曲はかのジョルジュ・バタイユがロード・オーシュ（排泄する神）名義で出した奇作『眼球譚』に大いに影響受けた楽曲として有名ではありますが、その歌詞では神の所有について、そして信仰の目的を語ることで締められます。
眼は私の所有する唯一の神
私の信仰はいつも、全ての抑圧から解放されるために存在するのだ
今回の記事では「言葉は神」と繰り返し表現してきましたが、本来、人間が所有するインターフェースすべてに神性が宿っていると僕は捉えています。
眼も、手も、足も、臓腑も、脳も。
それら神たるインターフェースに訴えかけ、成果物を奉納し、ときに怒りを鎮め、ときに悦ばせようとするUXライターたちの活動は、はたして人の業なのか神の業なのか。果ては○リキュアの筋力なのか。
彼らの召使いとして、僕は最後まで見守っていこうと思います。
もしもSmartHRのUXライティンググループに少しでも興味を持ってくださった方はぜひいちどカジュアルに話しましょう！
僕らももがいているぶん、お互いに有意義なお話ができるかと思います。
いつでもお気軽にご連絡くださいね。
/assets/images/6379401/original/f5807ecf-8475-45c3-92cc-7ce2fb8f04d2?1646912499)