こんにちは！UXライティング部のhebikoです。
わたしはUXライターとして、SmartHRのプロダクト内のUI文言やヘルプセンターのコンテンツ作成に関わっています。この記事では、非エンジニアであるUXライターがGitHub Copilotを使ってプロダクトを改善する様子をお伝えします。
UXライターによるUI文言の改善活動
UXライターは、UIやヘルプページなどユーザーが触れるコンテンツの品質を高める役割を担っている職種です。
UXライターが果たすべき責任範囲として、「プロダクトを主軸にした、サポートコンテンツも含めた広義の情報設計を担う」というコミットメントが現在掲げられています。そして、具体的に取り組むことの中に、「ユーザーがスムーズに業務を完遂できるようにプロダクトを改善する」ことが含まれています（詳しく知りたい方は、SmartHR UXライターの責任範囲を明文化した話｜8chari / はっちゃりを是非お読みください）。
「プロダクトを改善する」の中にはUI改善が含まれており、コミットメントが決まった2024年からUXライターが積極的にUI文言を改善していく活動をはじめました。
SmartHRはどんどん成長しているプロダクトです。そのため次のような文言変更をしたいな、ということがありました。
- プロダクトが成長したことによる文言の見直し
- 前はこの文言でよかったが、現在だと他のプロダクトとより明確に区別するために、別の文言にしたい
- 新しい画面が追加された結果、古い画面と新しい画面で文言が揺れているので、統一したい
- よりユーザーにとって使いやすくなる文言変更
- エラーメッセージを改善したら、もっとユーザーがやるべきことが明確になり、お問い合わせが減る可能性があるので、変更したい
ですが、こういった文言変更を通常の開発プロセスにのせた場合、どうしても他の開発タスクよりも優先度が下がってしまうことがあります。「それならUXライターが製品に直接Pull Requestを出して、コミットしていけばいいじゃないか！」というのが、UXライターが直接UI文言を改善していく活動を始めることになったきっかけです。
UI文言の改善活動における実装スキルの課題
UXライターによるUI文言の改善を加速させるため、これまでさまざまな取り組みをしてきました。各開発チームとのやりとりやレビューの方法などの合意を取ったり、開発環境をUXライターが自身のパソコンで立ち上げられるようにドキュメントを整備したり、そして実際に文言を変更したり。活動していく中で、「UXライターがちょっとした文言なら変更してくれる」という認識が社内にもできてきて、「この文言変更、UXライターで持ってもらえますか？」と言っていただくことも増えてきたように感じます。
しかし、UXライターがUI文言を改善するときに課題もありました。それは、「特定の条件で文言を出し分けたい」というような実装をしたいときに、UXライター側の実装スキルが不足していたことです。「本当はAの条件とBの条件で分けて文言を出し分けたらもっとわかりやすくなると思うけど、UXライターの現在のスキルでは自信を持って実装ができない…」という状況がありました。
GitHub Copilotとの出会い
そんな中、SmartHR社内で2025年1月に、GitHub Copilotの研修が開催されました。
研修を受ける前は「プロダクトを改善するなかで、UXライターが読んでも具体的な処理の内容がわからないコードがあったら解説をしてもらえるようになるかもね」というくらいの期待値でした。 が、研修を受けたあとは、「これは、そもそもプログラムを書かせることが、場合によってはできるのでは…？今までUXライターが諦めていた実装に手を出せるのでは…？」と思えるようになりました。AIは活用方法を知っていることがとても大事ですね。
「UXライターでも、製品改善できるかも…？」と思い始めたタイミングで、ちょうどUXライターが気付いた文言の課題がありました。それは「動作環境外のブラウザからアクセスした場合に表示されるメッセージ」です。
SmartHRの動作環境は、「サポート対象ブラウザ」の「最新版」です。 そのため、これまで「サポート対象で最新版」ではないブラウザ全体に対して「お使いのブラウザは動作環境ではないため、サポート対象外です。」というメッセージが表示されていました。
しかし、これはユーザーから見ると「サポート対象であるブラウザではあるが、最新版ではないからメッセージが出ている」のか、「そもそもサポート対象外のブラウザを使っているのか」がわかりにくいという問題がありました。前者の場合、ユーザーにやってほしいことは「ブラウザをアップデートする」です。後者の場合は「サポート対象のブラウザを使うように、使用するブラウザを変更する」です。つまり、前者の場合はアップデートして欲しいことがわかるようにメッセージを変更するのがよさそうです。
ただしこれはプログラムに処理を追加する必要があるため、今までのわたしだったら「できないかも」と諦めていたタイプの変更です。でも今は違います。GitHub Copilotの力を使ってなんとかできないか？と思い、やってみることにしました。
GitHub CopilotのCopilot Editsを使ってみる
まず、Visual Studio CodeでGitHub CopilotのCopilot Editを開きます。
SmartHRを開いたブラウザが動作環境以外だった場合にメッセージを表示するプログラムファイルを作業セットとして指定し、Copilotに次の指示を出しました。
「ブラウザとしてはサポート対象だが、バージョンが古くてサポート対象外となっている」場合に、「バージョンアップしてね」のメッセージを出せるように分岐を入れたいです。 - サポート対象ではないブラウザを利用している場合：現在のメッセージが表示される - バージョンが古いブラウザを利用している場合：バージョンが古いので更新してほしいというメッセージが表示される
上記の指示だけで、Copilotは既存のプログラムを「サポート対象ではないブラウザ」と「バージョンが古いブラウザ」を判定するように変更してくれました。
ただ、メッセージの出し分けまでは対応してくれなかったため、続けて、下記のように指示を出しました。 （実際には「{ファイル名}」にはブラウザ上にメッセージを表示するプログラムが記載されているファイル名を、「{要素名}」にはメッセージを表示するプログラムの要素名を指定しています。）
現在は「{ファイル名}」の「{要素名}」で「お使いのブラウザは動作環境ではないため、サポート対象外です。」というメッセージを表示しています。
これに対して、次の分岐を入れたいです。
本当は上記に続けて分岐の詳細を書く予定でしたが、間違えてそのまま送信してしまいました。ただ、一つ前のプロンプトでコンテキストがわかっていたからか、これだけで、ブラウザ側でのメッセージの出し分けにも対応できるようになりました。古いブラウザで開いて意図したメッセージが表示されたときは、「ちゃ、ちゃんと表示されている…！」と驚きました。あとは表示するメッセージの表現を調整して完了です。
生成したプログラムはエンジニアにレビューしてもらいました。少しだけ修正がありましたが、ほぼそのままプログラムは採用され、リリースされました。
今では「サポート対象ではないブラウザ」と、「サポート対象だがバージョンが古いブラウザ」で、メッセージが出し分けされるようになっています。
非エンジニアによるプロダクト改善の幅が広がりそう
このように、Copilot Editに自然言語でリクエストを書くだけで、実装ができてしまいました。
もちろんコードをよくわかっているエンジニアによるレビューは必要ですし、そこは今後も変わらないと思います。それでも、非エンジニアであるUXライターが製品を改善するために取れる手段が増えたことは、わたしたちにとって大きな武器の一つになりそうです。
これからも、SmartHRのユーザーによりよい体験を提供するため、一語一句にこだわってやっていきたいと思います。
UXライティング部では、新しいメンバーを募集しています！UXライターの仕事に興味がある方、ぜひカジュアル面談をご検討ください。UXライター部のメンバーと、ざっくばらんにお話できます。
