新型コロナの影響でテレワークが広まった2020年春。「ハンコを押すために出社した。」の広告キャンペーンがSNSで話題になったのが、クラウド人事労務ソフト『SmartHR』だ。登録企業はすでに4万社を超え、労務管理クラウド3年連続シェアNo.1（※1）を誇る。

シェアのみならず、ユーザー満足度もNo.1 (※2)。こうした高評価の理由の一つには、どんな会社のどの社員が見ても迷わず使える直観的な操作性が挙げられる。

SmartHRはなぜ「操作性」によるユーザー体験の速さ向上に着目したのか。また、開発の裏側にはどんな工夫があるのか。同社でプロダクトデザイナーとして働く金森悠さんに聞いた。

※株式会社マクロミル（委託調査）2020年12月 クラウド型人事労務システムを運用・管理中の1,800名
※デロイト トーマツ ミック経済研究所「HRTechクラウド市場の実態と展望 2020年度」
（参考）SmartHR、労務管理クラウドとして3年連続シェアNo.1を獲得　〜 「気持ちよく働ける会社」の実現に貢献、満足度もNo.1(※2)に 〜

「生産性」を提供するサービスゆえの「操作性」へのこだわり

リリースした2015年からしばらくは、雇用契約や入社手続き、年末調整など労務管理の業務効率化のみを実現するシステムでした。当時は競合も少なく、先行者利益も得られたと思います。

その後、勤怠管理システムや給与計算システムと連携、さらに蓄積した人事データや業務効率化によって生まれた時間を生かすべく、人事評価や従業員サーベイといった人材マネジメント機能も付加するなど年々機能を拡充してきました。

ただもちろん、機能が多ければ多いほどいいとは考えておらず、「その機能が本当にユーザーの業務を効率化できるかどうか」に重きを置いています。

そもそも『SmartHR』が人事労務担当者や従業員の既存の業務を効率化するためのプロダクトなので、われわれが行っているすべての開発行為が速さにつながっているといえます。

そうした中で、特にユーザーの体験速度の向上のためにこだわっていることの一つが、「誰でも初見で迷わずに使える操作性」です。

私たちは会社全体として「ユーザーの課題を達成できるプロダクトデザイン」を重要視していますが、それは、私たちのサービスが「ユーザーの生産性を高めることによって」対価を得ているものだから。だからこそ、有限の時間を少しも圧迫しないよう「使い勝手の良さ」にもこだわっているのです。

利用者の「こう動くはず」を裏切らない、驚き最小限を目指す

開発時には「利用者のメンタルモデルとプロダクトの挙動をどう合致させるか」を徹底的に考えます。メンタルモデルとは、利用者が無意識に思い描く「この場合はこうなる」というイメージのこと。例えば、ボタンがあるのに押せなかったり、スクロールバーをスクロールできなかったりすると、多くの人は「思っていたのと違う」というストレスを感じますよね。

はい。私は、ユーザーと『SmartHR』の間に、層のようにいくつも存在するインターフェースを「界面」と呼んでいます。

具体的には、利用者の前にあるキーボードやマウスの操作画面、その先にあるブラウザやOS、HTML、データやAPIの層……など。そうした各「界面」で、メンタルモデルとシステムの仕様をどう合わせるかを調整しているのです。

メンタルモデルと合致すれば、初見の画面であっても構成をパッと把握でき、すぐに使い始められますよね。ヘルプページやマニュアルを見ないと使えないような画面と比べると、ユーザー体験において圧倒的な「速さ」を生み出せるはずです。

はい、目指すのは「驚き最小限」のプロダクトです。私たちは、革新的なものを作ったり、目新しいデザインを誇示したりしたいわけではないんです。作りたいのは、ユーザーにとって本当に使いやすいもの。

となると、自然とユーザーが日常的に目にしているものや使い慣れているUIになる。ボタン一つとっても、多くの人が思い描くイメージにできるだけ合致させます。OSやブラウザが用いるような表現をあえて選ぶ傾向にありますね。

SmartHRではどちらかというと、単純な「速さ」より、ユーザーが使える最低限の「当たり前品質」をきちんと満たすことを重視しています。

もちろん、表示スピードや処理速度などのパフォーマンスも意識しますが、そもそも私たちはtoCサービスのようなコンマ何秒を争う世界にはいません。処理速度を追求するあまり、利用者のメンタルモデルと大きく食い違うものになれば、結果的に操作のスピードは遅くなってしまう。それでは本末転倒です。

目先の「速さ」を追求するよりも、着実にゴールにたどり着くために一つ一つのことをしっかりやっていく。それが結果的に、ユーザー体験全体の「速さ」につながると思うのです。

そのために、チームでは開発に関わるすべての人が同じ目線でプロダクトの先にある価値を意識した開発を行えるよう、「共通言語」を増やすことを心掛けていますね。例えば、デザイナー職でなくても『SmartHR』をデザインできるようにするための「SmartHRデザインシステム」や、すべてのSmartHRプロダクトで利用されているUIコンポーネントライブラリ「SmartHR UI」など、組織として「デザインしていくため」の共通言語を作り続けています。

また最近は「UIモデリング」や「OOUI」という言葉も浸透してきていますが、当社でもUIのみならず、アプリやシステムで扱うオブジェクト同士の関連や状態遷移などを表す「概念モデル」も作成します。プロダクトマネージャーとデザイナーそれぞれが概念モデルを作ることによって、認識にずれが起きていないかを確認しています。

SmartHRの最大の特徴は、プロダクトやユーザーのことを文字通り「徹底的に考えること」。そして、それを全員が認識していることです。

具体的には、営業をはじめチャットサポート、カスタマーサクセス、ソーシャルメディアなど、ユーザーの声を拾えるチャネルが多く存在し、日常的に生の声を聞いています。また、週に 1 度の全社会議でも集まった声を社員みんなで共有し合っています。

さらにユーザビリティテストを行う際は、映像を社内で共有し、テスト主催者以外も見られる状態にしています。そのため、普段コードを書いているエンジニアの口からも自然とお客さまの社名が出てきますし、それだけではなく「この会社の方はこんな使い方をしているから、ここが課題になるよね」という会話が自然に起こります。

だからこそ、全員が「自分たちのプロダクトが何に貢献しているのか」という共通の意識を持ち、情熱を持って仕事に取り組むことができるのです。

分断しない組織と越境するエンジニアが、「速さ」と「良いプロダクト」を生む

ユーザー体験に「速さ」をつくることを目的としてしまっても仕方ありません。まずは、本質的なデザインをすることの方が大事で、速さはその結果としてついてくるものだと思います。

その上で重要なのは、エンジニアが自身の役割に境界線を設けないことかなと。デザインは本質的に、複数の専門領域にまたがりながら波及していく「学際的」なもの。例えば「あるボタンの色を変える」となったとき、コード上で色を変えるだけでなく、アクセシビリティや視認性の観点からコントラスト比の確認も必要です。

また、「色の変更ではなく、ボタンのラベルを変えれば良かったのでは？」というライティングの話になるかもしれないし、その裏の情報設計や仕様を見直して「そもそもボタンって必要なんだっけ？」という話が出てくるかもしれない。だから、ボタンの色や形といった“表層”だけにこだわっていても仕方がないんですよね。

学際的の逆は集学的。例えば、医療の世界では、一人の体を診るために専門分野の異なる複数の医師や専門スタッフが集合し、それぞれの専門分野を全うされると思います。でも、プロダクトデザインの現場はそれでは回りません、積極的な他部署との協力や連携はもちろんのこと、専門的な領域を持つ人と人の中間領域への侵食が不可欠なんですよ。

大事なのは社内で分断を起こさないことだと思います。メンバー間の溝は部署や職能、役割ですぐに生まれてしまうものなので、メンバーの役割や範囲は限定し過ぎない方がいい。

本来エンジニアの役割はプロジェクトによって変えるべきだと思うんです。私はプロダクトデザイナーという肩書きなので、「デザインツールで画面を作っている」と思われがちですが、普段の業務は9割5分コードを書いており、一般的に皆さんが思われるようなデザインの仕事は、今はほとんどしていません。エンジニアもデザイナーも肩書にとらわれずに幅広い範囲に関心を持ち、越境しながら開発していくことが大事だと思います。

最近はエンジニアの分業化や専業化が進み、UXリサーチやUXライティングなどの専門的な言葉も聞くようになりました。ただ、システム開発が学際的であることを分かった上で専門性を発揮しなければ、良いプロダクトは生み出せないのではないでしょうか。

この考え方は今の社会や時代にはやや逆行している面もありますが、わたしたちはもっと本質的なプロダクトデザインやシステム開発をしているという自負がありますし、今後は私たちの考え方ややり方を本流にしたいと思っています。そのための努力を続けていきたいですね。

取材・文／古屋江美子　撮影／吉永和久　編集／河西ことみ（編集部）