見出し画像

UXライターがプロダクトと向き合っていたらGitHubにコミットできるようになった話

おおつかあぐり

こんにちは！　
SmartHRのカスタマーサポートグループでUXライターとして働いている@aguringo です。

入社から約半年のタイミングで肩書きをUXライターに改め、印象に残る言葉よりも、印象に残らない言葉の価値を追求していきたいと表明後、その仕事っぷりを公に書き記すことをしてきませんでした。オープン社内報やテックブログなどアウトプット自体はしてきたのですが、自分のことを話すよりもインタビューする方が好きで、入社からの1年間を振り返る機会もすっかり逃してしまっていました…

そんななか、先日SmartHRの一員として、ごく個人的ではありますが、エポックメイキングな出来事があったので、紹介させてください。

プロダクトにプラスになることならなんでもやっていいんやで！

その出来事とは、2021年5月19日のリリースでSmartHRのアカウント権限を表す文言のユレを解消したことです。

エンジニアにコード修正を依頼するのではなく、自分でSmartHRのリポジトリにPull request（以下、PR）を出し、Approveをもらって実現しました。難しいコードでもないし、画面変更のインパクトも少ないのですが、入社してからやってきたことが実を結んだカイゼンです。

ちょうど先日、宮田さんが同僚に向けてしていたツイートにも通じるエピソードなので、「SmartHRらしさを体現できたぞ」と自分で自分をホメたいと思います。

ヘルプセンターのコンテンツ編集者が見つけた、プロダクトの文言ユレ

今では業務スコープを拡大し、UXライターとして開発チームに加わりながらプロダクトのUI品質を文言という手段で高める役割を担っていますが、入社時はカスタマーサポートグループ ナレッジユニット所属のコンテンツ編集者でした。

ヘルプページを書く人として入社した私は、プロダクトの理解を深める研修を進める過程で、UI文言のユレや表現が気になる箇所を多く見つけました。

今では画面上の文言に対してカイゼンの要望を受け取る側ですが、当時はその声をどこに持っていったら良いのか、どうしたら修正できるのかも全くわからない状態でした。

しかし、SmartHRでは、ドキュメントを公開して課題感を表明することは簡単にできます。

課題感を整理して伝えれば、仲間に届き、動き出す

課題感をシェアすると、リアクションがあるのがSmartHRの良いところ。

この文言カイゼンで一番力になってもらえたのは、同期入社のPdMのkissyでした。ちょうど彼が担当する権限に関するカイゼンが決まっていたので、文言のユレの解消も「一緒にやろう」と声をかけてくれました。

プロダクト上での説明文なども一緒に考えて、カイゼンに伴う画面のリニューアルをして、概念の定義はユレのない状態になりました。

しかし、カイゼンの対象外の画面もあったため、残り続けました。

ヘルプセンター内では、一部の画面に残ったユレ表記も併記して、同じものを指していることがわかるようにフォローし続ける必要がありました。概念の定義上はスッキリしたはずなのに、ヘルプページ内では文言のユレを意図的に残さなければなりません。それは、私にとっては残念な状態でした。

しかし、プロダクトバックログには、たくさんの「やりたいこと」がある状態。チームは「ユーザーにとって価値のある、動くプロダクトを最速で届ける」という目的で動いているので、優先順位の判断は納得しています。開発チームのプロダクトエンジニアのリソースを使う場合には、待つしかありません。

UXライターはテキストだけでベストを判断するわけではない

「今の自分にできるところまで、やりきった」そう納得し、まずは目の前に広がるUXライターとしてできること、やりたいことを取り組みました。

「プロダクトを良くするためにこれをやりたい！」「こんな文言整理をするとエンジニアの役に立つんじゃないか？」と、挙げるとキリがないのですが、いろんなことをやっていたら、当時は遠い存在だったコード修正ができるようになっていました。

力になったのは以下のようなチャレンジです。（詳細は割愛）

・コンポーネントや操作コンテキスト別にライティングルールを整理。文言ガイドラインとしてドキュメント化
・実装済みコードから、フラッシュメッセージをすべて洗い出して傾向を分析、パターン化
・新しい機能におけるユビキタス言語の整理（物理名をユーザーのメンタルモデルに合わせた名称に翻訳）
・開発中のプロダクトのコンポーネントのメッセージエリアを整理

文言修正をコードベースで進めるきっかけになったのは、目下、開発中のサービス提供前のプロダクトを手がけるチームに入ったことです。

UXライターは"テキスト"という手段を中心に使ってユーザーエクスペリエンスを良いものにする役割ではありますが、テキストそのものだけに注目して最良を目指すわけではありません。テキストを画面のどこに置くか、画面ではなくユーザーが操作する過程のどこに置くかという視点でもテキストをデザインします。

これまでも、デザインモックを利用した文言確認と調整はしていました。しかし、実際に画面を動かしながらユーザーが受け取るフィードバックをすぐに調整するスピード感が欲しくて、プロトタイプを自分も自由に使えるようにするという感覚でローカルの開発環境を構築して触り始めました。

そして、サービス提供前のプロダクトというある種の気楽さもあり、実装済みの文言修正時に「画面キャプチャとテキストで修正指示をするよりもPR出してしまった方が速いや」と、PRを当たり前のように出すようになりました。

このチームでのトライから得るものはとても多く、テキストを書きたい場所を自分で追加する、つまりReactもちょっと書くということもするようになりました。これは、SmartHR UIのおかげです！！

React書いたPR出した日のツイート

自律駆動とは言え、助けはアチコチで受けられる

入社半年noteの中で、

自分で仕事を作りに行ける環境、最高。

と書いていたことなんて、すっかり忘れていたのですが、私がやってきたのはプロダクトを通したユーザー体験を良くするために、自分の業務スコープを気にせずに振る舞うことでした。

その中で一貫してきたのは、以下のスタンスです。

1. 気になったことは声にする
2. いきなり誰かに任せるのではなく、自分ができることを考えてみる
3. 自分がわからないことを解消するための質問をする

UIの負債を減らしたいのは、あくまでも私のやりたいこと。なので、誰かにやってもらおうという発想はありませんでした。

それでも、実際には私はたくさんの助けをもらいました。そして、スキルや経験も身につけることができました。正直、この年になって、まさかGitHub上で遊びではなくリポジトリにコミットできるようになるなんて想像もしませんでした。

新しいことができるようになるのは、とっても楽しいですね。

何より、UXを少しでも良くするための動きができたことがうれしいです。

そして、現在メンバーとして関わっているフィーチャーチーム（前述のチームとは別のプロダクトのチーム）で、このような文言カイゼンを進めていくスキームも作りました。SmartHRの開発組織の中のテーマのひとつであるフィーチャーチームとしての取り組みとしても、結構面白いことができてるんじゃないかなぁと、トライをしているところです。

UXライター、やってみませんか？

UXライティングユニット発足時、UXライターは3名（うち1名はMgr兼チーフ）だったのですが、昨年末から新メンバーを迎えはじめ、4名増えました。

私がさらに業務領域を広げて、開発への新しい関わり方にチャレンジできるようになったのも、仲間が増えたからこそ。しかし、まだ人員は充足していません。ということで、お決まりの募集要項です。どん。


この記事が気に入ったらサポートをしてみませんか？