開発に近い場所で働きたかった私が、開発チームの一員として働くようになるまで
こんにちは、SmartHRでUXライターをしている＠8chariです。
先日、同僚と「入社前に考えていたこと」を話す機会がありました。入社して2年以上が経って忘れかけていましたが、「異業種への転職、開発メンバーとうまくやっていけるかな…」という当時の不安を思い出しました。
そこで今回は、過去の私と同じように不安な人がいるのではと思い、記事を書いてみます。異業種から転職し、企業文化も開発体制もガラリと変わった私がどうやって開発メンバーと働いてきたか。少しでも参考になれば嬉しいです。
開発との距離が近い環境を求めて
最初に、私がどんな経緯でSmartHRのUXライターに辿り着いたかをお話しさせてください。
私の一番長いキャリアは、プロダクトのマニュアルやヘルプページを書くテクニカルライターです。学生時代は「テクニカルライティング」という言葉すら知りませんでしたが、就活時代に仕事内容を知り、ご縁あってメーカーのグループ会社でテクニカルライターとして働き始めました。
先輩方から多くのフィードバックを受け、「ユーザーにどのように情報を伝えるべきか」を納得いくまで考えた経験は、SmartHRに入社した今も活かされています。また、担当していたプロダクトの開発現場ではアジャイル開発が導入されていました。グループ会社の社員という立場ではありましたが、メーカーのエンジニアと同じ場所で働き、ここでスクラムに触れることができました。加えて、UXや人間中心設計について学ぶ機会を得たのもこの頃です。
7年ほどテクニカルライターとして働いた後、PMOという別の職種を経験しました。PMOとはProject Management Officeの略で、プロジェクトを成功させるために必要な業務を担い、PMの意思決定を支援する職種です。
プロジェクトを推進する楽しさも感じていましたが、テクニカルライターの頃のように自分の手で何かを作ってユーザーさんに価値を届けたくなり、心機一転して別の製造メーカーにマニュアル制作ディレクターとして転職しました。
転職してからは、事業会社の大規模なプロジェクトにやりがいを感じる一方で、課題も感じ始めました。規模の大きな組織ではよくあることかもしれませんが、きっちり分業された体制で、部署の垣根を感じていました。「一緒に1つのプロダクトを作っている」というより、「担当者それぞれが一部分を作っている」という感覚でしょうか。アクセスできる情報も部署ごとに管理されており、見たい情報をすぐに見られないということが少なくありませんでした。
開発メンバーとの距離が近く、ユーザーの要望を早く反映できるプロダクトに関わりたい。この両方を満たすことができ、今までの自分のスキルも活かせそうな職種を探していたときに見つけたのがSmartHRのUXライターでした。
スクラムに精通していなくても受け入れてくれる環境
SmartHRのUXライターは、入社してオンボーディングを受けたあと、担当するプロダクトにアサインされます。複数名で同じプロダクトや開発チームを担当することはありません。アサインされるUXライターは基本的に1人です。
異業種からの転職や、スクラムをはじめとしたアジャイルな開発手法を経験したことがない場合、同じ職種の人がいないチームでスクラム開発に関わっていくことに身構える人もいるかもしれません。私もアジャイル開発のプロジェクトを経験してから月日が経っていたこと、同じ職種の人がいないチームでやっていくことを不安に思っていました。
しかし、SmartHRにはスクラムを正しく理解して活躍できるようになるための環境が準備されています。そのうちの1つが、社内で定期的に開催されているスクラム講座で、スクラムの背景にある考え方やスクラムイベントについて、SmartHRの開発メンバーから学ぶことができます。
テクニカルライターとして働く中でスクラムの基本的な考え方や用語は知っていたつもりでしたが、実務と紐づけながら体系的に学べたことは大きかったです。スクラム講座を通じて、正しく理解できていなかった部分に気づき、開発チームでの動き方を考える土台を準備できました。
加えて、忘れてはならないのがSmartHRのカルチャー「オープンさ」です。社員であれば、ほとんどの情報にいつでも誰でもアクセスできます。また、「こんにちは！この仕様について確認したいです！」とSlackのオープンなチャンネルで気軽に質問することも日常です。そして、その質問にすぐに反応してくれる人たちがSmartHRには集まっていると感じます。
特段珍しくない状況だと思う方もいるかもしれませんが、私の経験を振り返ってみると、必要な情報にすぐにアクセスできて周囲と円滑にコミュニケーションできる環境は当たり前ではないなと実感しています。知りたいと思ったら、自分で何でもすぐに調べて動ける環境、めちゃくちゃ快適です。
開発メンバーとの働き方
こういった環境に支えられながら、どうやって開発メンバーと働いてきたかの具体例を3つ紹介します。
定期的に期待値を調整する
SmartHRでは、新しいメンバーがチームに入る際に「期待値調整」がよく実施されています。
「これをやってほしかったのに…」「いや、自分がやると思っていなかったし…」と、互いの期待値が合っていなくて、すれ違う状況を経験したことはないでしょうか。すれ違いがないように、「自身ができること・やりたいこと」と「チームが新しいメンバーに期待したいこと」をすり合わせることを「期待値調整」と呼んでいます。
特にUXライターという職種は珍しく、「前職でUXライターと働いていたよ」という開発メンバーはほぼいません。そのため、UXライターである私に何を期待していいのか、当時は開発メンバーも手探りだったと思います。私が何ができる人なのかを伝え、周囲からの期待を確認したことで、その後のアクションを考えやすくなりました。
また、期待値調整は一度やって終わりではなく、3ヶ月〜6ヶ月のペースで定期的に実施していました。状況は変わるため、気づかないうちに周囲と期待値がズレてしまうことも考えられます。自分のアクションが開発メンバーの求めるものになっているかを常に意識し、ズレが起きないように気をつけながら動くようにしていました。
Working Out Loudで考えや取り組みをオープンにする
珍しい職種、かつ新メンバーであることを考慮し、自分の考えや取り組みを開発チームのSlackチャンネルに書き込んで周囲に共有していました。
これは、開発に集中しているエンジニアがマニュアルやヘルプページの存在を忘れがち…という苦い経験が前職であったため、とにかく存在感を出すことで「あ、これって8chariさんにも伝えておいたほうがいいな？」と必要なタイミングで思い出してもらえるようにしようという狙いがありました。
SmartHRではフルリモートで働いているメンバーが多いこともあり、互いの作業が見えづらくならないように「今はhogehogeの作業をしています」など、Working Out Loudという「声を出しながら働く」ことが大事にされています。こういった背景もあり、比較的早い段階で大きな抵抗なく自分の考えや取り組みをSlackに書き込んでいけていたと思います。
開発メンバーに直接関係しないことでも、自分が考えていることや取り組んでいることをオープンにしていくと、「こんなことを考えているのは自分だけかもな…」と思っていたことに対して「実は私も気になってた！それ、一緒にやりません？」と声がかかることがあります。
これは、オープンさを大事にするカルチャーがあり、声に出したことを受け止めてくれるメンバーがいるからこそ成立することです。1人では解決が難しい課題について自然と同志が集まってくる環境、めちゃくちゃ仕事がしやすく幸せです。
職能にとらわれずに開発をより良くするために働く
業務範囲を決めすぎず、プロダクト開発に必要なことなら何でもやると考えて動くことも重視していました。「UXライターの8chari」としてではなく、「開発チームの8chari」として動くイメージです。プロダクト開発に関わる一員なので当然といえば当然なんですが、改めて意識するとアクションが変わってきます。
具体的には、交代制スクラムマスターにトライしたことがありました。交代制スクラムマスターとは、期間限定で開発チームのスクラムマスターとなって活動し、スクラムマスターのような動き方ができる人を組織内に増やして開発組織全体をより良くしていくための試みです。
「UXライターがスクラムマスター？」と不思議に思われるかもしれませんが、SmartHRでは「あなたはUXライターなので、それはやらないで」と言われるようなことはなく、「チームやプロダクトをより良くするためなら、誰でも何でもやっていいよ」という考えが根付いています。
実は、入社してしばらくは「やってもいいですか？」と周囲に許可をとる働き方が染み付いていて、「本当にやっていいかな…」と戸惑いもありました。でも、実際にやってみると周囲からポジティブな反応をもらうことができ、「より良くするためなら、本当に何でもやっていいんだ！」と意識が変わっていきました。
また、入社直後は「UXライターという職能に見合う価値を出さなければ…」と肩書きにこだわっていたこともありました。もちろん、UXライターとして期待されている責務は果たす前提ですが、「UXライターであろうとなかろうと、そもそもチームやプロダクトのためになることをやればいい」と思えたことでアクションが増え、開発メンバーとの関係構築にもつながり、チームの一員になれたと実感しています。
必要なスキルはライティングだけじゃない
UXライターとしてライティングのスキルはもちろん重要です。しかし、今までを振り返ってみると、スクラムで開発しているSmartHRにおいては、周囲を巻き込みながらプロジェクトを進めていくスキルが同じくらい重要だと私は思っています。
例えば、私の場合、PMOというプロジェクト推進の仕事をやった経験が今の業務に活かされています。当時、すでに動いているプロジェクトに途中からジョインすることが多かったため、いきなり現れた自分が何ができる人かを周囲に説明し、具体的なアクションをすり合わせる…といった期待値調整に近いことをやっていました。
また、周囲を観察してプロジェクトの課題を見える化し、関係者で議論して解決していける場を設定することも多かったです。これは、考えたことをオープンにし、より良くするための解決策を開発メンバーに提案していく動きに近いです。
入社して比較的早い段階で「職能にとらわれずに開発に必要なことをやる」と思えるようになったのも、今から思えば「プロジェクト推進につながることであれば何でもやる」という働き方をPMOの頃に経験できていたことが後押しになっていると思います。
さいごに
異業種からの転職やスクラムに精通していなかったとしても、チームやプロダクトをより良くしていくために活躍できる土壌がSmartHRにあるとお伝えできていたら嬉しいです。
そして、SmartHRのUXライティンググループには、さまざまなバックグラウンドを持つメンバーがいて、それぞれ自分の強みを活かしながら働いています。自分のやり方でプロダクトの価値を高められることに魅力を感じた方、ぜひ一緒に働きませんか。
お待ちしています！
この記事が気に入ったらサポートをしてみませんか？