SmartHRの課題を見つけるためにプロダクトデザイングループではデザイナーの体験入社を始めました

こんにちは。デザイナーの@tyoys00です。会社ではふみやと呼ばれています。本名ではありません。

前回の記事ではたくさんの方からリアクションをいただきました。ありがとうございます。おかげさまでこうして2回目の記事を書く機会に恵まれました。ただ、社内のslackでは最近私と人事の@takinariとの間で以下のようなやり取りが発生していましたのでまだまだ油断はできません。

ぜひ３回目の記事が書けるよう、引き続き応援のほどよろしくお願い申し上げます。

SmartHRではプロダクトデザイナーの体験入社を始めました

さて、話は変わりますがSmartHRではプロダクトデザイナーの体験入社を始めました。これまでもエンジニアポジションでの体験入社は行っていましたがデザイナーでは初の試みです。

エンジニア向けの体験入社制度ができました - SmartHR Tech Blog

（注：現在はエンジニア向け体験入社の一般応募は行っておりません。）

現在、プロダクトデザイングループではプロダクトデザイナーのロールを「UIデザイナー」と「UXデザイナー」の2職種で募集していますが、初回はUXデザイナーポジションでの体験入社を行わせていただきました。

体験入社のプログラムは参加者のご希望を伺ったうえでプログラムを考えさせていただいていますが、今回行った体験入社ではいくつかのプロジェクトのスクラムイベントに参加していただきながら開発の流れやデザイナーの動き方を見てもらったり、企画段階のプロジェクトのリサーチや情報設計などの上流工程を行っていただいたりとかなり実際の業務に踏み込んだ内容を体験してもらっています。

また、体験入社中はSlackで社内メンバーとコミュニケーションを積極的に取っていただいたり、社内wikiにまとめてあるドキュメントを自由に読んでもらったり、シャッフルランチなどの対面でのコミュニケーションにも参加してもらったりとSmartHRのカルチャーを見ていただける機会も随所に用意しています。

体験入社を受けた方からのフィードバック（プロブレム編）

とはいえ、体験入社を行うことの期待値は決してSmartHRの良いところだけを見てもらうことにあるわけではありません。むしろ、SmartHRのダメなところこそを見てもらいたいと考えています。

体験入社後には実際に体験入社を受けてみてどのように感じたかをレポートとして提出いただけるようお願いしています。今回いらしていただいた方からはSmartHRの課題として以下のようなフィードバックをいただきました。

プロダクト面

・ UIが良いという評判はブログやTwitterでなんとなく知っていたが、触ってみるとオープン社内報にあるように「ハウルの動く城」だった。
　
・ 初見は良いのだが、業務の流れを把握してから使おうとするとだいぶ迷ってしまう。課題はUI表現よりも情報設計にあり、良かれと思って作った概念が逆に使いにくさを生んでいそうだった。　
　
・ 一回説明を受けるとその時は理解したつもりで使えるのだが、すぐに忘れてしまって迷子になってしまう。更新が走った後にメニュー移動するのもあいまってさらにわからなさを生んでいた。プロダクトに対して、セールスやエンジニア、QAでさえ疑問に思っているのはさすがに問題かもしれない。
　
・ ○○管理、○○一覧がメニュー上で並んでいてメニューからできることの想像しにくさがある。業務アプリのアンチパターンにハマっているように見えた。
　
・ 初期開発をした際の開発メンバーがチームにいなかったので、何をkeepしたほうがいいのか、何がproblemなのか判断しにくかった。
　
・ セールス、PMたちがユーザーの声を直接聞いて詳しい部分はあるけれど、人やプロダクトが増えてきているがゆえにロール間で情報が欠けてしまったいる印象があった。QAやエンジニアやデザイナーがユーザーをよく知らないまま作っているのがとても勿体無く感じた。要望ベースで画面毎/機能毎に考えているところや、デザインが一部上がってから影響範囲が明らかになっている感じがあったので、利用者の業務の全体像や理想の状態の情報を見える形にするだけでも効果がありそうだと思う。　

開発チームとして

　・バックログが開発者のタスク寄りだなと思った。業務フローの話にも通じるが、ユーザーサイドの背景やビジネス意図を含めるだけでも途中から参加したメンバーがバックログを把握しやすいのではないかと思った。

今回は上記のフィードバックを読み解きつつ、SmartHRの課題を掘り下げて行き、プロダクトデザイナーがどのように課題解決を行っていけるかを考えてみたいと思います。

体験入社から見えるSmartHRの課題たち

外から見えるプロダクトと内から見るプロダクトとのギャップ

UIが良いという評判はブログやTwitterでなんとなく知っていたが、触ってみるとオープン社内報にあるように「ハウルの動く城」だった。
 初見は良いのだが、業務の流れを把握してから使おうとするとだいぶ迷ってしまう。課題はUI表現よりも情報設計にあり、良かれと思って作った概念が逆に使いにくさを生んでいそうだった。

「ハウルの動く城」という表現は、弊社が公開している「オープン社内報」で、PdMの安達が言及した「ハウルの動く城パターン」のことを指した発言かと思います。

（SmartHRのカオスっぷりを説明する安達。本人は切れ切れの才人。）

実は体験入社で見てもらいたい最大のポイントのひとつがこの外から見えるプロダクトと内から見えるプロダクトとのギャップでした。

ありがたいことに面談などでご来社いただいた方の中にはSmartHRというプロダクトを利用したことがある方も少なくありません。しかし、多くの方が触れていただいているSmartHRは従業員ユーザーとして触れるSmartHRであり、プロダクトとしては全体のほんの一部でしかありません（プロダクトの全体像からすると一割にも満たないかもしれません）。

SmartHRの深淵は管理者ユーザーとして触れていただいた時にこそ触れることができ、プロダクトデザイナーが向き合うべき課題はその深淵の中にこそ広がっています。

ただ、通常ご利用いただいている限りはその深淵に辿りくことはまずないので社外の方がSmartHRのハウルっぷりを実感してもらう機会がまずありません。現在のプロダクトが抱える問題点を正しく認識してもらうための機会がないことはプロダクトを知ってもらうことに対しての大きな課題でもありました（これは2Bプロダクトの多くが抱えている課題でもあるかと思います）。

そのため、体験入社という場は社外からは見えずらい会社やプロダクトが抱えている課題を正しく見ることができる場として運用していきたいと考えています。

ユーザー体験の一貫性とドメイン把握

セールス、PMたちがユーザーの声を直接聞いて詳しい部分はあるけれど、人やプロダクトが増えてきているがゆえに、ロール間で情報が欠けてしまったりしている印象があった。QAや開発やデザイナーが、ユーザーをよく知らないまま作っているのがとても勿体無く感じた。要望ベースで、画面毎/機能毎に考えているところや、デザインが一部上がってから影響範囲が明らかになっている感じがあったので、利用者の業務の全体像や、理想の状態が情報が行き渡るように見える形にするだけでも効果がありそうだと思う。

指摘された状況は、先日弊社代表の宮田がブログで書いた「たらいが回る」状況と同じようなことがプロダクトデザインの中でも起こっているのではないかと思います。

「たらい」が2回まわったら新ポジションの合図 - 宮田昇始のブログ

本来、ドメインにおけるユーザーストーリーの把握はプロダクトデザイナーの責務として請け負っていきたい業務なのですが、運用が本格化しているプロダクトであると機能追加に対して開発リソースを当てることが中心になってしまい、全体を俯瞰してのユーザー体験の最適化が後手に回ってしまっている状況に陥っていることは否めません。

なので、各プロダクトごとにユーザー体験を可視化して、最適な体験へとリファクタリングを行うことはプロダクトデザイナーとして取り組むべき急務の課題となっています。

弊社では、「人事労務研究所」という人事・労務業務に精通した部署も立ち上がったので、今後、人事労務研究所をドメインエキスパート集団としたドメイン駆動設計的なアプローチでの開発も行っていけるのではないかとおぼろげながら考えています。その際にプロダクトデザイナーが寄与できることは少なからずあるのではないでしょうか。

デザイナーとスクラム

バックログが開発者のタスク寄りだなと思った。業務フローの話にも通じるが、ユーザーサイドの背景やビジネス意図を含めるだけでも途中から参加したメンバーがバックログを把握しやすいのではないかと思った。バックログがそのまま顧客のリリースノートに反映されるようになるといいなと思う。

SmartHRでは現在、ほぼ全プロジェクトでスクラム開発が取り入れられています。また、今後の開発体制に備えて大規模スクラム（LeSS）を検証するなど、意欲的にスクラム開発をしていこうという空気感を感じます。

しかし一方で、デザイナーのスクラムへのコミットメントはまだまだ最適解には程遠い状況です。デザイナーがスクラムの基本から学び直していくべきか、デザインと開発のスプリントを分離してスクラムイベントのみ共有していくべきかは模索段階にあります。

また、バックログが開発者のタスク寄りになっていることは、もしかするとユーザーからの要望がバックログのチケット化されていく過程の中で、要望に含まれていたユーザーの本来の意図が隠蔽されてしまっている状況があるのかもしれません。

ここにも前述のユーザーシナリオの全体像が可視化できていない状況と同じ課題感が潜んでいるように思えます。BusinessとTechnologyとCreativeの三位一体を表す「BTCモデル」という概念がありますが、ここで扱われる「Creative」は顧客に寄り添うという点において「Customer」として捉えることもできる対象です（プロダクトマネジメントトライアングルの「User」に相似した要素です）。

バックログやスクラムイベント上では、BusinessとTechnologyはすでに可視化されているので、デザイナーが「Customer」の視点を体現して反映させることができるかどうかがスクラムにデザイナーが参加していることの意味に繋がるのかもしれません。

課題からデザインする

以上、体験入社から見えたSmartHRの課題を掘り下げて考えていきました。

課題を掘り下げていく中で、私たちが現在抱えている課題もより明確になったかと思います。私たちプロダクトデザイングループが体験入社を始めた理由もここにあります。

私たちが体験入社を行うのは決して現在の必要となるリソースに対する穴埋めの採用のためではありません。体験入社を通じて、私たち自身が気づいていない現在の開発プロセスやプロダクトデザイナーの働き方に対しての課題を見つけてもらいたい・見つけることができる人と一緒に働きたいと考えています。

誰もが知るとおり、プロダクトデザイナーの主要な役割はプロダクトの外観を整えることにあるわけではありません。プロダクトデザイナーに対してはリサーチによる業務ドメインの詳細情報の可視化と社内の各ロールが同じフィールドで話せるようになるための場の形成を行っていくことも期待値として持っています。

情報を集めてプロジェクトメンバーの共通認識やコミュニケーションを促すための場を設計していくことはプロダクトデザイナーが開発メンバーのひとりとして担うべき責務のひとつです。

プロダクトデザイナーは、プロダクトが抱える課題を発見・解決し、ユーザーに届ける価値を最大化するために存在します。プロダクトの価値のためならあらゆるものをデザインするべきです。使える技術はなんでも使い、ロールに捉われることなく、必要であればチームや組織もデザインし直していきます。

そのためにはまずSmartHRの課題を発見していかなければなりません。ぜひ体験入社を通じて私たちがまだ気付けていない課題を見つけていただけたらと思います。

私たちが気づいていない課題を発見してください

この記事で体験入社に興味を持ってくださった方へのご連絡です。

プロダクトデザイナーの体験入社は現時点では一般での公募はしておりません。選考の過程で、双方が会社や事業のことをより深く知りたい・知ってほしいとなった際にご提案させていただきたいと思っています。

なので、まずはぜひカジュアルにお話ししましょう。カジュアル面談への申し込みのリンクをこちらに用意しましたので気軽にご応募ください。ぜひ、SmartHRの課題を発見してください。

私たちにはあなたが必要です。

最後に。

これはあなたに向けた私信です。

私たちデザインチームはまだまだ課題だらけのチームです。メンバーも少なく、スキルセットも均一ではありません。

ですが、私たちの成長がプロダクトの成長に繋がり、事業の成長に繋がる。ひいては、ユーザーの皆さんがSmartHRを使っていることを意識することすらないほどの心地よい利用体験に繋がっていくと本気で信じています。

弊社の企業Valueの一つである「自立駆動」という価値観では「100の問題を50人で2問ずつ解く組織」を目指すことを宣言しています。

私たちデザインチームも同様です。

ひとりひとりが特異なスキルで特異な価値を発揮する。その総体で大きな価値を紡ぎあげる。

私たちはそんなチームをデザインしようと動き始めています。そして、そのチームでもって組織そのものをデザインし直していこうとしています。

私たちにはあなたが必要です。

ぜひ、ご一緒に働けることをお待ちしております。