2023年版｜0→1フェーズのプロダクト開発における、とあるUXライターの働き方
SmartHRは2023年8月22日に「スキル管理」機能の提供をスタートしました。私にとっては2年前にリリースした「人事評価」に続いて、0→1開発の3度めの体験となりました。
先日、スキル管理のチームで「0→1をスクラムでやってみた -スキル管理機能の作り方-」というイベントを実施し、プロダクトマネージャー（以下PM）、エンジニア、デザイナー、QAエンジニアと一緒に、各職能がどこで専門性を発揮し、同時にチームとしてどんな協業をしたかを振り返りました。そこでは、LTが7分間だったり、参加者の興味はUXライターとは限らなかったりしたため、駆け足な内容でした。（イベントの資料とアーカイブ動画は記事の最後にあります）
ここでは、イベントでは語りきれなかった、2年前にはやりきれなかったこと、さらに理解が深まったことについて、「0→1フェーズのプロダクト開発における、とあるUXライターの働き方」のアップデート版としてまとめます。
そもそも0→1のUXライターはどんな意識で働いているか
SaaSプロダクトの立ち上げ時は「リリース日」というデッドラインに間に合わせることが制約と想像しがちですが、それ以前に「リリース日を決められる状態」を作ることが最初の壁です（提供開始日が決まらないと売り始められないため）。そのため、MVP（Minimum Viable Product）、ユーザーに価値を提供できる最小限の機能の範囲、つまり何をどこまで作るかを決める必要もあります。
SmartHRでは開発に着手してからリリースまでの不確実性を減らしながら、リリース日を決定します。もちろん、なるべく早くリリースするための意思決定の中心となるのはPMです。しかし、UXライターにも開発者の一人としてできることがあります。私がなるべく早く価値あるプロダクトを届けるために意識したことが、以下の3点です。
イテレーションを意識した自律駆動をする
開発速度に寄与しそうな知見を持っていたら、採用確度は気にせず共有する
リリース後の拡張性を「言葉」で俯瞰する
1.イテレーションを意識した自律駆動をする
イテレーション（Iteration）とは、 アジャイル開発における「設計→開発→テスト→改善」のサイクルのことです。
先ほども触れたように、リリース時に「どこまで作るか」やタイムボックスを管理し適応することに、UXライターが貢献できることはほとんどありません。しかし、開発中のプロダクトの「使いやすさ」のイテレーションには貢献できます。
積み重なるインクリメントをキレイな線にする
工数の見積もりをしやすくするために、開発チケットはできる限り小さく切られるようになります。そうなると、チケット単位のインクリメントの受け入れ要件は”仕様”になりがちです。
しかし、ユーザーはインクリメント単位でプロダクトを使うわけではなく、あるユーザーストーリーは複数のインクリメントの集積です。インクリメントの1つ1つは、点としてしっかり完成していても、線にした時に不自然なことがあります。そこで、私はユーザーストーリー単位でプロダクトが動くようになったタイミングで、操作をしながら「使いやすさ」を検証しました。
検証の結果、必要と判断したUIの修正（主に文言とちょっとしたコンポーネントの置き換え）は、エンジニアのタイムボックスを使わずに、自分で実装しました。
もし、この工程をエンジニアのタイムボックスに頼らざるを得ない場合には、別のアプローチを考えた方が良いと思います。リリースまでのリードタイムが長くなってしまします。代替案としては、Figmaを使って実装前にプロトタイプで検証をするなどが考えられそうです。（中間生成物としてデザインファイルをしっかり作り込むことにはなってしまいますが…）
2年前に書いた記事では、実装ができるようになったことで
画面を 「見る」と 「操作する」の見え方の違いを意識できるようになりました
と書きましたが、より意識的にスクラムチームの一員としてアジャイルとUXの両立のために自分が貢献することに注力しました。
2.開発速度に寄与しそうな知見を持っていたら、採用確度は気にせず共有する
これはSmartHRの開発組織ならではかもしれませんが、仕様やUIの検討時に「すでにある使えそうなもの」がある場合には、積極的に案を出していきました。
SmartHRでは、プロダクトエンジニアは開発チームと組織がイコールですが、PM、プロダクトデザイナー、QA、UXライターは職能ごとの組織に所属しています。そのため、メンバーの担当プロダクトが変わる機会はエンジニアに比べると多いです。
また、私たちUXライターは、すべてのプロダクトのヘルプページが書けるよう、入社後の研修として全プロダクトの最低限のインプットをしてから、担当が決まります。
さらに私の場合は、少人数で複数プロダクトのヘルプページを作成していた時代から在籍していたこと、アサイン変更の機会も多かったことから、ほとんどのプロダクトを担当したことがあり、把握している領域が広いです。
SmartHR Design Systemも車輪の再発明をしないための仕組みですが、既存プロダクトの仕様やUIの流用も開発スピードを上げるのに効果的です。また、ユーザーに操作に関するメンタルモデルができあがっていることが多いので、「わかりやすさ」の観点からも有益だと考えられます。
もちろん、不適合なケースもあるので、PBRで一つの意見として情報共有をして、技術的な判断な判断はエンジニアに任せました。
3.リリース後の拡張性を「言葉」で俯瞰する
2年前と現在とで一番大きな違いはここだと感じています。
オブジェクトを「言葉」に置き換えて、違和感を言語化する
スキル管理機能は初期に、スキルを裏づけるものとして「技能」「資格」「研修」というオブジェクトを管理するように考えられていました。私がチームに正式参画する前の話です。「どうもしっくりこないので、意見を聞きたい」とPMから相談を受け、私は「しっくりこない」を言語化しました。
まず、ファクトである「資格」「研修」は、スキルの裏づけとして自然だけれど、そこに「技能」が並ぶことに違和感があるのではないかと指摘。また、「スキル」と「技能」を別の概念として使い分けるのは認知負荷が高いを考え、オブジェクトは「スキル」「資格」「研修」にして、「スキル」に「資格」、「研修」を関連づけられるようすることを提案しました。
もう一例挙げます。
スキル管理機能では、従業員に対し保有資格などの情報の提出をリクエストし、提出されたデータを登録できます。初期リリースでは「管理者が依頼して従業員が応じる」というユーザーストーリーを実現することのみで確定でした。
SmartHRには、「依頼」オブジェクトを扱う機能が複数あります。それは、人事・労務担当者が、年末調整に関する情報提出や雇用契約書類の合意を「依頼」する業務を効率化するアプリケーションだからです。これらの業務は必ず起点が人事労務担当者で、それは今後も変わりません。
一方、スキル管理機能は、将来的には人事・労務担当者起点だけではなく、従業員起点の情報の提出というユーザーストーリーにも対応することも見込んでいました。そのため、初期リリースのスコープでは、ユーザーストーリーをオブジェクトモデルに変換した時に「依頼」オブジェクトの方が自然に感じられますが、拡張性を考え「申請」としました。
ドメインを「言葉」を整理して可視化する
ユビキタス言語は人事評価機能でも作りましたが、今振り返ると、当時は理解が浅かったなと感じています。ユビキタス言語の有用性については、別の記事にまとめているので、興味のある方はそちらをご覧ください。
スキル管理機能のユビキタス言語は、以下のような工程で作りました。
モデル(物理名)を気にせず、概念をまとめる
コードを参照し、モデルを洗い出して論理名を整理
オブジェクトに対するアクションや、画面の名前を定義
最初は用語集作りを変わらないアプローチで、ユーザーストーリーに出現する概念に名前をつけていきました。この時点では、物理名はオブジェクト図を見て埋めていきました。
次に、実装がある程度進んだところで、コードを参照しながら、物理名を修正。ユビキタス言語のドキュメントでは、見出しをつけてグルーピングをしていましたが、このタイミングで見出しをオブジェクトごとに変更しています。そして、オブジェクトとそのプロパティに名前をつけていきます。エンジニアを始めとする開発チームにレビューを頼んだのも、このタイミングでした。
以降は、エンジニアが実装後に物理名を追記し、UXライターが論理名を埋めていく運用に変更しました。
オブジェクトの論理名の整理ができた段階で、オブジェクトに対するアクションテキスト（コード上では同じ「create」でも「登録」なのか「追加」なのかがオブジェクトごとに違う）を追記しました。加えて、画面の名前も決めて記載していきました。
ドキュメントには、実装予定の概念も仮置きしておきます。実装済みの言葉と検討中の仮の言葉を合わせて整理することで、共通項が見出だせるなど名付けしやすくなるというメリットがあります。
プロダクトの未来を言語化する
スキル管理機能のリリースにあたっては、UIやヘルプページといったアプリケーションの操作を助けるライティングだけでなく、マーケティングに関するライティングも手掛けました。
タレントマネジメント領域のプロダクトの価値は、業務効率に留まりません。顧客は「目の前の膨大な業務を効率化したい」という自覚は持っています。しかし、福利厚生や報酬以外のアプローチで、従業員がより良いパフォーマンスを発揮するための業務は、日本ではまだまだ伸びしろがあり、課題意識を持っている人も多いとは言えません。
PMがユーザーヒアリングや調査を経て課題を見つけ、そのソリューションとして考えたプロダクトの価値の言語化も、常にコンテキストを共有しているからこそ、スムーズにできます。新しいプロダクトをリリースする場合には、リリース時の機能説明だけではなく、そのプロダクトが実現したい状態を伝え、市場を作ることも大切です。そしてその役割も、0→1に関わるUXライターが担うのにふさわしい立場だと、私は考えています。
課題
0→1のUXライターとして、スキル管理機能で私が主にやったことは以上です。
多くの場合、これらは別々の専門職が分業するでしょう。そして、分業するならば、1チームに1人の専任がいる状態はリソースが余ってしまいます。
しかし、開発チームに所属し常にコンテキストを共有できている状態で、それを各用途に合わせて伝わる言葉に変換できる人がいるのは、組織のアジリティを高めるんじゃないかと考えています。特に、0→1のフェーズでは有効でしょう。
大きな課題は、人材の再現性の低さです。組織が大きくなれば、人材の育成は不可欠で、再現性が求められます。正直なところ、社員が1000人を超えた今のSmartHRでは、ロールモデルにならない再現性の低い人材は、組織の成長と相容れないんじゃないかとも感じています。
正直なところ、「では、どうすれば良いのか」という問いに対する回答をまだ私は持ち合わせていません。
他にはどんなUXライターがいるのか気になりませんか？
ここまで、SmartHRで0→1をやってきたUXライターとして私がやったことを紹介しましたが、SmartHRのUXライターは当然私だけではありません。さまざまな出自で、得意領域を持ったUXライターが活躍しています。
それを知っていただく機会として、2023年11月1日に、SmartHRのUXライティンググループとして初めての単独イベントを企画しています。（本イベントは終了しました）
オフラインイベントとして、公開記事では知ることのできないメンバーの話が聞けます。私以外のUXライターに興味がある人は、ぜひご参加ください（人数に限りがあるため抽選制です）。
企画者の私は、進行を担当します。軽い懇親会もあるので、懇親会では、私のお話もできます。ご興味ある方は、ひとまず応募してみてください。応募締め切りは今日10月26日（木）の18時までです!!
イベント終わっちゃったので、カジュアル面談をどうぞ！
SmartHRのUXライターの求人情報はこちら
この記事が気に入ったらサポートをしてみませんか？