機能が増えても、使いやすさは譲らない。ユーザー起点のSmartHRのプロダクト原則

根本的な課題は2つあり、その両方が重なった結果「システムを頑張って使う」状態に陥ります。

1つ目は、「従業員目線が最初から設計に組み込まれていない」という設計思想の問題です。従来のバックオフィス向けシステムは管理部門が使う前提でつくられており、従業員が直接入力する文化はごく最近になって生まれました。

2つ目は、「人がシステムにあわせる」ことによる構造的な使いにくさです。企業ごとに異なる運用ルールをひとつのシステムで網羅しようとすれば、機能拡張による複雑化は避けられません。パッケージソフトやSaaSの宿命とも言えます。

大きく3つの弊害が考えられます。

1つ目は、名もなき業務（問い合わせ対応）のコストです。マニュアル作成や使い方に関する細かな質問対応など、全社でみれば膨大なコストが発生します。

2つ目は、そもそも従業員が使いこなせなければ、導入目的は達成されません。システムが浸透し切らずに一部で紙運用が残るとなると、せっかくのシステム投資も「お金を払っただけ」で終わってしまいます。

3つ目は従業員エンゲージメントへの負の影響です。私は「使いにくいシステム利用を強いるのは、ストレスのかかる環境を強いること」だと考えています。

たとえば、企業が「従業員を大切にする」と掲げながら、清掃の行き届かないオフィス環境だったとしたら、従業員は言葉と実態にギャップを感じ、会社への不信感を抱く人もいると思います。

ソフトウェアも同様で、複雑で使うたびにストレスのかかるシステムを日常的に使うことで蓄積される負の体験は、従業員エンゲージメントを徐々に削っていきます。

SmartHRというサービスが、従業員に直接入力してもらう「フロントシステム」として誕生したという、ビジネスモデルの成り立ちに由来しています。

SmartHRが登場する以前は、紙で人事・労務の情報を集め、担当者が一括してシステムに入力し、給与明細も紙で配布するのが一般的でした。そうした「管理者が使うこと」を前提に設計された従来のシステムにおいて、従業員目線の使い勝手はあくまで付加価値（Nice to have）になりがちです。

しかし、従業員本人が使うことを前提とするSmartHRにとって、誰でも迷わず使えるユーザビリティは、付加価値（Nice to have）ではなく、サービスを成立させるための「絶対条件（Must）」だったわけです。

まさに SmartHRがいま真正面から向き合っているテーマです。これまでは顧客ニーズに応えるべく、猛烈なスピードで機能ラインアップを拡張し、人員を増強してきました。ただ、プロダクトの多角化と組織の急拡大が進んだいま、高度なユーザー体験を提供し続けるには、現場の熱量に頼るだけでなく、より強固な共通指針が必要だと考えました。
そこで、「SmartHRらしい worker-friendly」をすべてのプロダクトで等しく実現できるよう、私たちが考える「いいプロダクト」の定義を言語化しました。それが、5つの「プロダクト原則」です。

 プロダクト原則は、「短期的な売上」と「中長期的なプロダクト価値」を同じ土俵で議論するための「共通言語」です。

成長著しいフェーズでは、「市場へのインパクト（＝売上）」が議論の中心になりがちです。一方、プロダクトの信頼性やクオリティは重要だとわかっていても定量化しづらく、投資判断の優先順位を上げにくいという課題がありました。

そこで、プロダクト原則という明確な「評価軸」を設けました。「この開発は原則を守るために不可欠」といったように、中長期的なプロダクト価値の向上を議論し、評価できるようになります。

 5つのなかでもっとも優先順位が高いのが「信頼性」です。SmartHRは給与計算やID管理など、停止すれば顧客業務そのものを停滞させるミッションクリティカルな領域を担っており、信頼性は不可欠な土台です。

AI進化によって開発スピードが上がり「いかに早くつくるか」を問われるいまこそ、「本当に顧客の大切なデータを守り抜けるのか」を自らに問い直す必要があります。どんなに開発が加速しても決して譲ってはならない「楔（くさび）」として、信頼性を第一に掲げています。

「いま入力したこの情報を、誰が閲覧でき、どこに保存されるのか」をユーザーが迷いなく把握できている状態——それが、私たちの考える「透明性」の理想形です。

HRシステムが扱うのは、マイナンバーや家族構成といった機微な個人情報、エンゲージメント調査などのデリケートな情報です。入力時に「このデータ、誰かに見られないか」という不安を感じるのは、ユーザーとシステムの間に「情報の非対称性」があるからです。

そのギャップを埋め、「迷いと不安を排する情報設計」をスタンダードにすべく、現在、開発現場での徹底を進めています。

「効率性」は業務システムの当たり前の価値ですが、ここで問いたいのは「作り手の論理ではなく、使う側の論理で考えているか」です。機能ごとに開発チームが分かれていると、その機能内だけで使いやすさを追求する局所最適に陥りがちです。

しかし、ユーザーは複数の機能を横断して使います。機能ごとにUIが異なり、画面を何度も往復させる設計は、ユーザーの時間を奪っているのと変わりません。大切なのは、「ユーザーが1つの仕事をやり遂げるまでのスムーズさ」を優先することです。

「ユーザーが1つの仕事をやり遂げるまでのスムーズさを優先する」先ほどお話しした"機能拡張と使いやすさのジレンマ"を乗り越えるためにも、効率性という視点は手放せません。

機能を増やすことそのものより、「提供する価値」をアップデートし続けるという決意に近いですね。

もともとSmartHRには「世の中にあるもののコピーをつくっても意味がない」という文化があります。しかし、組織が急拡大するなかで、そうした野心的な姿勢は、意識的に言葉にし続けなければ薄れてしまいます。だからこそ、あらためて「新規性」を定義する必要がありました。作り手が「こうなったら最高じゃない？」とワクワクしながら挑戦しなければ、画期的な発明は生まれません。

ただ、その「遊び心」が机上の空論になっては意味がありません。営業やカスタマーサクセスと開発チームが一体となって顧客への解像度を極限まで高め、そこに作り手のワクワクが備わって初めて、「誰もが驚く、誰もが欲しかった価値」が見えてくる。

そんな姿勢をスタンダードにすることで、SmartHRを「常に最新で、もっともworker-friendlyな存在」に進化させ続けたいと考えています。

せっかくご契約いただいた以上、一刻も早く「楽になった」という実感を届けたい。これは、導入から価値を感じるまでの時間「Time to Value」をいかに短くするかを、開発側も責任をもつという決意です。

どんなに多機能でも、初期設定が複雑で使い始めるまでに数か月かかるようでは、顧客に負担を強いているのと同じです。スムーズに使い始められない理由がプロダクト側の課題にあるなら、開発が自分ごととして解決すべきです。

たとえば、テンプレートやAIによる設定の自動化や、既存システムからのスムーズなデータ移行など、導入直後の期待感を損なわず、現場への浸透を最短距離で支えることを、プロダクトの品質として定義しています。

3つの価値があると考えています。

1. 生産性の底上げ：「システムを使うための付随業務（マニュアル確認や問い合わせ）」を最小化し、全員が本来の業務に集中できる環境をつくる
2. 業務の高度化：現場のマネージャーが自らデータにアクセスし、スピーディに判断・改善できる状態を実現
3. 従業員の信頼醸成：ストレスのないツールを提供することは、会社が従業員を尊重しているというメッセージとなり、エンゲージメントの土台となる

さらに、より広い視点でいえば、業務システム全体の期待値を引き上げるという価値もあります。従来のシステムは、多少の使いにくさは「仕方のない」ものとして受け入れられがちです。そうしたなかで「worker-friendly」なシステムを提供し続けることは、「使いにくいものは使いたくない」と声を上げられる社会にもつながると考えています。

 以前、SmartHRを導入していたとある企業で、システム統合のためにSmartHRからの切り替えを検討されていました。しかし、移行先のシステムがあまりにも使いにくく、従業員から猛反発が起きた結果、SmartHRを使い続けるという判断が下されたことがありました。「従業員が使いにくいシステムに対して声を上げた」という印象的な事例だと感じています。

大切にしたいのは多様性です。極端にいえば、あらゆるものをデジタル化させるのが正解ではなく、企業にとって紙がもっとも効率的な場合は紙でもいいと思っています。
1つの正解を押し付けるのではなく、ベーシックな基盤の提供と、それぞれの企業の事情や特性に寄り添うことを両立していきたいですね。SmartHRはこれからも、個々の企業にとって最適な働き方を共に考える存在であり続けていきたいと思っています。