UXライターからエンジニアへのスキル移譲をシステム思考で振り返ってみた
これは、SmartHR AdventCalendar2023の6日目の記事です。
ここ半年間は自分で書くよりも、開発チームのエンジニアが書いたものをレビューする機会のほうが多かったように思います。どうすればエンジニアにUXライティングのスキルを移譲できるだろうか？そんな問いを開発チームと探究した半年でした。
ありがたいことに、これまでUXライターが担当していたヘルプページの作成・修正を、エンジニアが主導できるまでにスキル移譲が進みました。
この記事では、何が良い要因だったのかをシステム思考の因果ループ図で振り返ります。
第1段落と第2段落は背景や実施内容について触れているので、結論だけ知りたい方は読み飛ばして第3段落だけ読んでいただいても大丈夫です！
なぜUXライティングのスキルをエンジニアに移譲する必要があったのか
2023年6月、文書配付機能の専任UXライターだった私の異動が決まりました。7月から私は人事評価機能を担当することになり、文書配付チームではエンジニアがUXライティングを担うことになりました。
それまで文書配付チームでは、UXライティングのスキル移譲にはほとんど取り組んできていませんでした。UI文言を一緒に考えることはあっても、ヘルプページについては完全に未経験の状態でした。しかもユーザーの期待度が高い機能を開発中だったため、スキル移譲にリソースを割いて大丈夫なのか？本当に自分たちでUXライティングをやれるのか？といった不安がチーム内に漂っていました。
文書配付チームの場合は、私の異動をきっかけにスキル移譲を進めることになりましたが、ちょうどUXライティンググループ全体としても開発現場におけるライティングスキルの支援をやっていこうという方針が打ち出されたタイミングでした。
なぜUXライター自身がライティングせず、開発チームのライティングスキルを支援するのか？と疑問に思った方がいるかもしれません。その背景には、チームを適切なサイズに保ちたいという開発組織全体の方針があります。人数が増えていけば、コミュニケーションコストが高まり、デリバリー速度が落ちてしまうことが考えられます。
それならば、開発チームの外に専門チームを作り、開発チームの依頼を受けてUXライターがライティングするようにしたらいいのでは？と思った方もいるかもしれません。
SmartHRの開発組織では、「デリバリー」を、機能がリリースされるまでではなく、ユーザーがその機能を使いこなしてその成果を享受するところまでだと考えています。そのため、わかりやすいUI文言やヘルプページもデリバリーにおける重要な要素だと捉えています。よく「ヘルプページもプロダクトの一部」と言ったりします。操作手順のヘルプページなどはプロダクトのリリースと共に公開するようにしていたりもします。
もし開発チームが依頼をしてUXライターが文言やヘルプページを制作する場合、いくつかのデメリットが考えられます。まず、仕様について把握していないUXライターに1から仕様をインプットしなければなりません。どうしてもコミュニケーションコストが高くなります。他にも、依頼するタイミングが遅れてしまった場合、ヘルプページが完成するまで機能のリリースを待つことになります。他のチームの業務進捗を気にしなければいけないので、開発チームの認知負荷も高くなります。
つまり、開発チームの人数を適切にしていきたい、一方でプロダクトの一部である文言やヘルプページも変わらず開発チームから提供していきたい、という2つを両立するため、開発チーム内のエンジニアもライティングを担えるようになろうという方針なのです。
UXライティンググループではこの開発組織全体の方針を実現するために、開発現場におけるライティングスキルの支援を中心業務の1つにおいています。
（開発チームにスキル移譲を進めた先で、UXライター自身が注力していく課題については、近日中にUXライティンググループマネージャーが書いた記事が公開される予定なのでお楽しみに。）
エンジニアへのスキル移譲のためにやったことと起きたこと
異動が決まったタイミングでは、先述の通り、ユーザーの期待度が高い機能の開発が進行していました。機能開発の優先度は落とせません。
そこで、異動までの1か月間は私のリソースでできることから取り組みました。まずは、どういった状態をめざせると良いかの言語化と整理。このときは、エンジニアがUXライターの全タスクを引き継ぐ必要はなく、チーム外のUXライターに適切に頼れる状態をめざそうと考えていました。そのため、操作の手順や注意事項など伝えたい内容を箇条書きで整理した「構成」を書けることをゴールに設定しました。
構成を書くことに対するハードルを下げるため、ヘルプページのパターンを解説する会や構成作成の考え方のドキュメント化やモブ形式でのライティングなども実施しました。
あとは、チームを離れた私が文書配付チームに適した方法を模索するのは難しいだろうと予想できたため、文書配付チームの中で「UXライティング大臣」の募集をしました。UXライティング大臣には、エンジニアのakhtさんと10moeさんが立候補してくれました。
異動後は、UXライティング大臣と隔週30分のミーティングを開催し、作戦会議をしながらスキル移譲のための取り組みを進めています。機能開発に伴って追記や修正が必要になったヘルプページの洗い出しや作業内容の詳細化をする「ヘルペリファ（ヘルプページに関するタスクのリファインメント）」というミーティングも始まりました。
ちなみに、異動前後あわせたなかで私の一番の功績は、UXライティング大臣という役割を立てたことだと思っています。UXライティング大臣のお二人は、チームに対する働きかけをしながら、たくさんの嬉しい誤算を巻き起こしてくれました。
例えば、akhtさんはUXライティングの必要性をエンジニア目線で捉えたドキュメントをまとめ、チーム向けに公開してくれました。さらに、そのドキュメントをもとに「UXライティングやっていき会」をチームに向けて開催してくれました。
それまでは「構成を書ける状態をめざそう」と話していましたが、この会では「書きながら理解していきたい」「実際に書いてみたい」という意見が出ました。
書いてみたいという気持ちになれたことで、その前工程である影響範囲の洗い出しやヘルペリファといったプロセスに対する関心も高まったように思います。
10moeさんは、第一回目のヘルペリファが終わったタイミングでヘルペリファ用のスクリプトを作ってくれました。スクリプトがあれば、誰でもスクリプトを読みながらリファインメントの進行を担当できます。早めにベースとなる仕組みができたことでヘルペリファ自体の改善もチーム主導でできるようになりました。
あと、ヘルペリファを自分たちで進められると、詳細化したチケットを見たときに「なんか書けそう」と思えるようで、修正をやってみるというきっかけになりました。修正をやってみるようになったことで、勉強会のような機会を作らずとも、レビューを通じて考え方をインプットできるようになり、これもスキル移譲を進める要因に繋がったと認識しています。
スキル移譲の因果ループ図を書いてみた
「システム思考で振り返ってみた」ということで、ここからがようやく本題です！スキル移譲のポイントを発見するため、文書配付チームでやったことや起こっていたことを振り返り、因果ループ図にまとめてみました。
文書配付チームがわずか半年で、ヘルプページの作成や修正を主導できるようになった背景には下記のようなポジティブなループがあったのではないかと思います。
エンジニアがUXライティングのタスクを実践することでエンジニアからの質問が増え、UXライターの言語化がはかどったループ。
UXライターが言語化したことで、エンジニアがわからないこと（UXライターにとって暗黙知になってること）の言語化が進んだループ。
エンジニアに対してUXライティングのタスクの再現性を保つポイントが見えてきた結果、仕組み化に繋げやすくなり、実践に還元されたループ
そして、このループには大きく2つのツボがあると考えます。
質問による再現性の発見
タスクに慣れてくると、人は思考回路をスキップし始めます。ただ、そのスキップされてる思考回路にこそ、再現性が隠れています。では、スキップされる思考回路をどう明らかにするのかというと、実践の中での質問が重要です。
初めてヘルペリファしたときに、10moeさんから「途中で、いきなり影響調査が始まり、何を調べているかちょっとついていけなくなりました」という質問をもらいました。その質問で、私は無意識に飛ばしてしまっていた思考回路があることに気づきました。
この無意識に飛ばしてしまった思考回路を言語化し、それをさらにヘルペリファのスクリプトに落とし込みました。これにより、再現性が高まり実践がはかどるという好循環が生まれました。
人事評価のチームでもこの気付きからヘルプページのタスクの運用方法を刷新しました。結果、洗い出しから修正まで同じくエンジニア主導で実施できる状態になっています。
実践のための実践
何かを理解するときには詳しい人に質問をして理解を深めます。しかし、理解が浅すぎると不明点すら捉えられず、質問しづらいものです。実践をやっていくと、自分が理解できていないことがなんなのか、判断をどこで迷うのかが見えてきます。そういった意味では、作業への解像度を上げる実践もまた、再現性を見つけるためのツボになります。
文書配付チームのメンバーは、わからないことがあると、放っておかずにレビューやヘルペリファの場もしくはSlackなどで質問してくれます。やってみるほうがどうすればできるようになるのかという思考が働くといった意見もありました。
スキルを実践できるようになるためにタスクを実践してみることが大事！
一緒により良い実践を探究することが何よりも大事
最近、スキル移譲のために私にもっとできることはないかを探すため、日本語教師の専門性に関する書籍を読み漁っています。そこで「省察的実践」について知りました。省察的実践は対人関係専門職と呼ばれる職種（教師や看護師、医師など）のなかで研究されている概念だそうです。
教科書的な正解を目の前のクライアント（生徒や患者さんなど）にそのまま当てはめればよいわけではなく、暗黙知や言語化されていない専門性をどのように高めていくかという視点で語られます。そんな省察的実践のなかに、「行為の中の省察」という考え方があります。
ショーン『省察的実践者の教育』を院生らと読み深める場が「省察的実践者の教育」になっていた話を読んだときに以下のような文章が出てきました。
そして、この後生じた、私とＡさんおよび他の院生らとのやりとりは、ショーンがいうところの、「コーチと学生との間で交わされる対話」（p.138）であり、ショーンがその際に大事になるとする、「相互的な〈行為の中の省察〉」（p.139）は、この例でもまさに起きていたのだろうと思う。つまり、私が引っかかりを覚えて「ん？ Ａさん、そこ、どう読んだ？」と尋ねたとき、私（コーチ）の中では「行為の中の省察」が生じている。
この一文を拝見し、省察的実践の本質は「教える・教わる」ではなく、よりよい実践を模索していく実践者として共に対話することにあると気づきました。
文書配付チームでスキル移譲が進んだのは、UXライティング大臣はじめ文書配付チームのメンバーがまさにこの姿勢で関わってくれたからだなあと感じています。スキルを教わる・教えるではなく、どうすればスキル移譲が進むだろう？と一緒に考えてくれたチームに感謝が止まりません。
UXライティング大臣お二人の視点から書いた記事がテックブログにて公開されているので、ぜひそちらも合わせて読んでみてください！
この記事が気に入ったらサポートをしてみませんか？