こんにちは、UXライターの8chariです。早いものでSmartHRに入社して1年が経ちました！初めてTech Blogを書くのでドキドキしています。
SmartHRでは、フィーチャーチームでプロダクトを開発しており、開発プロセスの改善を日々行なっています。 この記事では、私が所属しているBチーム*1でヘルプページ作成のプロセスを見直し、チームのボトルネックを解消しようとしている話を紹介します。
特定の業務を担当できるメンバーが限られていて、以下のような課題を感じている方の参考になると嬉しいです。
必要なノウハウや知見がほかのメンバーに広まらない
プロジェクトのボトルネックになっている
担当できるメンバーの負荷が高くなっている
前提
UXライターがいる開発現場はあまり多くないと思いますので、前提を説明します。
SmartHRのUXライターは「言葉の力でプロダクトを、もっとわかりやすく」することをミッションとしています。その仕事の1つに「コンテンツによるユーザーの自走支援」があり、今回の記事で取り上げるヘルプページの作成はここに該当します。
ヘルプページを見なくてもプロダクトを操作できることが理想なのですが、SmartHRが扱う人事労務や人材マネジメントといった業務領域では、業務や関連する法律は複雑で難解です。そのため、ユーザーの理解をサポートするヘルプページは重要で、プロダクトの一部と考えています。
もともと、ヘルプページの運用組織はチャットサポートの中に含まれ、プロダクトのフィーチャーチームとは別の組織でした。こういったグループの立ち上げの経緯もあり、ヘルプページの作成はフィーチャーチームとは別のプロジェクトで管理され、少し離れたところにあったと思います。
そこから、ユーザーの理解をよりサポートできるよう、画面のUIテキストとヘルプページを読む体験を統一するため、UXライターとしてフィーチャーチームに加わりました。画面のUIテキストを担当しながら、ヘルプページの作成も引き続き担当しています。
課題
SmartHRのフィーチャーチームでは、プログラムの実装やエラーメッセージ文言の作成など、開発に関するあらゆるタスクがJiraのプロダクトバックログアイテムで可視化されています。誰でもタスクの進捗を確認できます。
ヘルプページも同様で、フィーチャーチームにUXライターが入ったことで、フィーチャーチームのプロジェクトでヘルプページのタスクを管理し始めました。スクラム開発において、タスクが可視化されている「透明性」を保つことで、チームに合う進め方を探ろうとしていました。
ヘルプページのタスクをフィーチャーチームのプロジェクトで管理するようになったことで、UXライターがどのようにヘルプページを作成しているのかが少しずつオープンになってきました。これに伴い、エンジニアなど、UXライター以外の職能がヘルプページの作成にチャレンジする機会も増えてきました。
一方で、どのタイミングでヘルプページ作成に着手すれば良いかなど、UXライターの判断基準がチームで可視化しきれておらず、タスクの管理方法や運用についてはまだ課題がありました。「透明性を上げているつもりなのに、いまいちメンバーを巻き込めていない気がする」という漠然とした不安があり、この不安をチームに打ち明けました。
チームの誰もがタスクを取れる状況になっていない
ヘルプページのタスクは、プロダクトの開発状況をUXライターがウォッチしながら、ヘルプページに影響のある変更か、いつ頃までに着手しないとリリースに間に合わないかをUXライター1人で検討して判断するという運用になっていました。
加えて、Jiraのプロダクトバックログアイテムは、アクティブスプリントではなく、バックログアイテムにありました。日々進捗を確認するアクティブスプリントにないため、UXライター以外のメンバーがヘルプページのタスクに気づきづらく、「フィーチャーチームのタスク」というよりも「UXライターのタスク」になっていました。
アクティブスプリントになく、UXライター単独でタスクを消化していたため、リファインメントやスプリントプランニングの場で、チームで議論することがほぼありませんでした。透明性を保とうと、ヘルプページの影響調査の結果や進捗状況を共有するためのミーティングを別途設定していましたが、チームで議論するというよりも、UXライターがどのように調査したか、判断したかの結果を報告するという状況になっていたと思います。
UXライターのマンパワーで何とかしようとしている
UXライターは1チームに1人というアサインで、複数名がアサインされることは現状ありません（UXライターがアサインされないチームもあります）。
そのため、SmartHR基本機能のように大規模スクラム（Large-Scale Scrum）で開発していてヘルプページへの影響が大きい場合でも、調査から執筆まで、UXライターが1人ですべてを担当するという状況になっていました。
1つの職能のマンパワーに依存してしまうと、修正漏れや品質低下のリスクも生まれます。当時は日々焦りながらタスクを抱え込むといった状況で、「スクラムの透明性」の本質から外れ、フィーチャーチームとは程遠い健全でない動き方をしていたと反省しています。
本来の目的「顧客に早く価値を届けること」から遠ざかる
UXライターがほぼ1人で進めるプロセスだと、
タスクがあること自体に気づきづらく、フィーチャーチームのメンバーがサポートに入りたくても入れない
タスクの内容からUXライター以外でもできるかどうかを判別できず、タスクを取れない
タスクを取れないので、UXライターがどのように作業しているのかが他の職能に移譲されない（クロスファンクショナルが推進されない）
UXライターが不在のときにタスクが止まる（リードタイムが長くなる）
という状況になり、フィーチャーチームの目的の1つである「顧客に早く価値を届けること」から遠ざかってしまいます。
チームに相談、理想のプロセスを考えた
チームで課題を共有し、ヘルプページ作成のタスクの透明性を上げるため、理想のプロセスを下記のように考えていきました。
現状のプロセスをUXライターが可視化
現状をもとに、理想のプロセスをチームで検討して可視化
理想のプロセスを運用するための詳細を明文化
1. 現状のプロセスをUXライターが可視化
UXWが開発の各フェーズで、ヘルプページ作成に向けて、どのように動いているのかを可視化しました。
「誰が」の部分、ヘルプページに関するタスクのほとんどをUXライターがやっていました。
また、後半になるにつれて、タスクが増えていくことがわかります。
2. 現状をもとに、理想のプロセスをチームで検討して可視化
現状を踏まえて、ヘルプページ作成のタスクがチームに可視化されたところで、どうすれば理想のプロセスになるかを検討しました。
まず、「誰が」の部分については、「UXライター」から「Bチーム」としました。UXライターだけで何とかしようとしていたことが既述した課題を生んでいたので、主語を明確に変えました。
一方で、UXライターがやった方が品質を担保できるタスクもあると考え、「UXライターがやること」という行を追加しました。例えば、ほかの職能がヘルプページへの影響を把握しやすいように「ヘルプページのどのあたりを確認するとよいか、調査の観点出しをリードする」などです。
ヘルプページの作成が開発の後工程にならないようにするために、各フェーズで何ができるといいかをメンバーとブレストしながら洗い出していきました。例えば、
規模の大きいフィーチャーであれば、先にヘルプページへの影響調査用のプロダクトバックログアイテムを切って、ボリュームをチームで見積もる。
UXライター以外もヘルプページのタスクを取りやすいように、チームのリファインメントで調査観点や修正方針、スプリントプランニングで具体的な変更箇所を洗い出しておく。
などです。
これらは、ヘルプページ以外のプロダクトバックログアイテムと同じプロセスにすることを意識しました。ヘルプページ作成のみが別のプロセスになってしまうと、UXライター以外の職能が取り組むハードルが上がり、運用が難しくなると考えたためです。
3. 理想のプロセスで運用するための詳細を明文化
リファインメントやスプリントプランニング、アクティブスプリントでやるべきことが整理され、理想のプロセスについて、チームで認識を合わせることができてきました。
Bチームでは、どの職能であっても会議のファシリテーションができるように進め方や確認観点を明文化したトークスクリプトを用意しています。おかげで、実際に私も定期的にリファインメントやスプリントプランニングを進行することができています。
ヘルプページのリファインメントやスプリントプランニングも同様で、UXライターでないと進行できないという状況にならないよう、リファインメントで何を確認していくか（観点）、何を決めていくか（受け入れ条件）、スプリントプランニングで必要な作業の計画（インクリメント作成）を明文化しました。下記はその抜粋です。
「誰に」「何のために」「いつ」「何を」伝えるためのヘルプページかを考える
誰に
・読者は管理者？従業員？
・読者の機能に対する理解度は？何のために
・機能の全体像や概要を理解してもらうため？
・具体的な操作手順を理解してもらい、正確に操作してもらうため？
・操作につまずきやすい部分をピンポイントでケアしたい？いつ
・プロダクトを操作しているとき？（プロダクトの操作画面から動線リンクが必要？）
・操作につまずいて検索したとき？（検索でヒットしそうなタイトルになっている？）何を
・「誰に」「何のために」「いつ」を踏まえたうえで、どんな情報をどのくらいの粒度で伝えると、ユーザーの負荷をかけずに済む？
・記載すべき免責事項や注意点などはある？（もちろん、ない方がベスト）
このように、チームのメンバーが理解できる形で明文化することが一番難しかったです。明文化できたのは、日頃からモブライティング*2を実施するなどして、プロセスや考慮する観点を少しずつチームにインプットできていたことが大きかったと思います。メンバーとの対話を重ねながら、暗黙知となっていた部分、UXライター以外がヘルプページのタスクをやるために必要なことが明らかになってきました。
実際に運用してみての気づき
理想のプロセスでの運用は始まったばかりですが、すでに良い気づきを得られており、その一部を紹介します。
まず、ヘルプページ作成のタスクを進めるにあたり、UXライターの経験知を言語化する機会が増えました。影響調査の段階からメンバーと議論して進めるため、判断根拠などをメンバーに共有しやすくなりました。これにより、ユーザーに伝える情報を「何をどんな順番で設計するか」という解像度をチーム全体で上げることができ、チームの共有知に昇華できていると思います。
加えて、複数の職能視点でヘルプページに記載すべき情報を考えることができています。考慮漏れのリスクが減ることはもちろん、1人で考えていたときよりもより早く良いアイデアが出る、スクラム開発における創発の効果を実感しています。
また、今までヘルプページの影響調査はUXライターだけが行なっていましたが、調査観点をメンバーにインプットできたことで、UXライター以外のメンバーでも調査を進められるようになってきました。UXライターが不在でもタスクが止まらない状態を実現できており、リードタイムの短縮につながっていると思います。
また、心理的にも良い影響がありました。
最後に
ここまで読んでいただき、ありがとうございました。このプロセスの運用は、まだまだ始まったばかりで、うまくいかない部分が出てきたら随時見直していく予定です。日々プロセスを改善して、より良い状態を目指すSmartHRの開発姿勢が少しでもお伝えできていたら嬉しいです。
最後に、チームに相談したときにメンバーから口々に言われたことを紹介して締めたいと思います！
誰かがチームから見えないところで頑張っていて、他の人が得をしているような マンパワーで解決されている状態は健全じゃない。 僕たちはフィーチャーチームで開発しているのだから、チームで解決しましょう。
この言葉のおかげで、チームで解決できるような仕組みを考えよう、チームを信頼してもっと頼ろうと考えられるようになりました。一緒に日々悩んで動いてくれるメンバーには感謝しかありません。
SmartHRでは、まだまだできていないこと、やりたいことがたくさんあります。SmartHRでの開発に興味を持たれた方、ぜひお話しましょう。エントリーお待ちしております！
https://hello-world.smarthr.co.jp/ https://open.talentio.com/r/1/c/smarthr/pages/45059
*1:基本機能ではLeSS（Large Scale Scurm）を採用しており、A〜Fの6チームが存在します。Bチームは、プロダクトマネージャー、プロダクトエンジニア、プロダクトデザイナー、UXライターで構成されています。
*2:SmartHRでは、複数人で画面上の文言を考えたり、ヘルプページを作成したりするモブライティングを実施しています。（フィーチャーチームでモブライティングをしている話）
