今更聞けない「労務領域」のデザインって何をしているの？
こんにちは、SmartHR のプロダクトデザイナーをしているうえんつ（@wentz_design）です。
現在は労務領域のプロダクトデザイン業のほか、最近はデザイナーのピープルマネジメント業をしています。
今回の記事では、主に SmartHR の「労務領域」のプロダクトデザイナーがどんなことをしているのか、またどんなところにやりがいがあるかをお伝えできればと思っています。
※なお、「プロダクトデザイナー」が繰り返されると読みづらくなるため、本記事内では「デザイナー」として省略表記しております。
SmartHRの労務領域のプロダクトってどんな人が使っているの？
デザイナーが何をしているか説明する前に、まずは「労務領域」について知ってもらえたらと思います。
労務領域のプロダクトの主なユーザーは、主に企業のバックオフィスとして働いている方々が多いです。労務領域の代表的な業務を見てみましょう。
入社・退職の手続き
給与計算と給与明細の作成
所得税・住民税など税金に関する手続き
健康診断や休職者管理など安全衛生業務
福利厚生に関する業務
様々な業務があることがわかります。さらに、これを従業員の数だけ行うことを考えてみてください。これらが毎月（多ければ毎週・毎日）定常的に発生し、かつ期日や金額の計算のほとんどが法律で定められているため、失敗が許されず極めて大きい責任を負っていることがお分かりいただけるでしょうか。
会社の成長のための従業員への投資や、組織を進化させていくための新しい施策やアクションを持続するには、定常業務ができていてかつ余裕がある状態を実現する必要があります。だからこそ、これらの労務業務を効率的かつ正確に実行するための手段としてプロダクトを提供しています。
法律上、厚生年金保険・健康保険にすべての法人事業所（被保険者1名以上）と、常時使用の従業員が5名以上の個人事業所が加入する義務がありますので、理論的にはその事業者および従業員すべてがユーザーになる可能性があります。
ゆえに、1つのプロダクトや機能が与える影響や責任も非常に大きくなります。例えば、1ユーザーの作業時間を1時間短縮する効率化機能を1社（1名）に提供するよりも、1ユーザーの作業時間を30分短縮する効率化機能を10社（10名）に提供する方が、ユーザー全体の可処分時間の総量は多くなります。
このように、社会全体で見た時の生産性に貢献しやすいため責任や影響が大きくなりやすく、その分「やりがい」も大きいと私は思っています。
労務領域のプロダクト開発でデザイナーはどんな仕事をしているの？
2024年5月現在、SmartHR が提供している代表的な労務領域のプロダクトは以下の通りです。
基本機能（労務サービス、労務データ管理、共通設定など）
届出書類（行政手続きの書類作成・電子申請など）
文書配付（雇用契約など）
年末調整
他新規プロダクト多数
これらのプロダクトを、労務プロダクトユニットのメンバー7名体制で複数の開発チームで分担・兼務しています。開発チーム内でのデザイナーの具体的な業務内容については、「ディスカバリーフェーズ」と「デリバリーフェーズ」と2つの開発フェーズに分けて説明します。
1. ディスカバリーフェーズ
ディスカバリーフェーズは、主に顧客に何を価値として提供するかを決めるフェーズです。代表的な業務は以下の通りです。
ユーザーを理解する
ユーザーの業務理解（ユーザーヒアリングやドメインエキスパートとのやり取りなど）
ユーザーの利用状況やメンタルモデルの分析
要件を整理する
要件定義
情報設計
オブジェクトデータモデリング
このフェーズでは、ユーザーの利用状況や業務フロー、メンタルモデルを明らかにすることが極めて重要になります。なぜなら、前述の通り労務領域の業務内容は非常に複雑であり、場合によっては社会保険・労働保険といった労働にまつわる専門知識を把握したうえで具体的なソリューションを検討する必要があるためです。
そこで、デザイナーはPMやPMMと連携してユーザー理解のために、実際にプロダクトを利用している労務担当者のユーザーや社会保険労務士（社労士）にヒアリングを行ったり、労務業務を経験のある社内ユーザーや労務領域専門のドメインエキスパートのメンバーに協力してもらって、プロダクトのプロトタイプを先行体験してもらいフィードバックをもらうエキスパートレビューなどを実施しています。
加えて、労務領域の基本的なドメイン知識を手っ取り早く包括的に獲得するために、以下の検定・資格を取得しているメンバーもいます。私も両方取得しました。
上記を実際に勉強してみて思ったのは、プロダクト開発を行う上で必要な労務知識が獲得できるだけでなく、自身の「労働」を含めて労務領域を自分ごととして捉えられるようになるので、労働者として知っておいて損はないということです。例えば、労働者向けの制度や給付金・税控除に詳しくなります。
そして、ユーザーリサーチによって明らかになったユーザーの業務フローやメンタルモデルなどに基づく、オブジェクトデータモデルがプロダクトデザイナーの最も典型的な中間成果物になります。オブジェクトデータモデルはプロダクトの構造を抽象的に表すモデルの総称であり、SmartHRではOOUIのオブジェクト図に各属性の型情報を足したER図のようなものになることが多いです。
このモデルを元にワイヤーフレームや具体的な画面ビューを検討しながら、足りないプロパティに気づいたり、さらに細分化して管理すべきオブジェクトを特定するなど、抽象と具体を反復しながら構造をブラッシュアップしていきます。
また、労務領域は前述の通り非常に複雑な業務が混合したドメインであるため、プロダクト上のプロパティやオブジェクトの因果関係も複雑化しやすくなります。そこで、オブジェクトデータモデルをPMやエンジニアなど開発者間の共通言語とすることで、客観的にプロダクトを俯瞰・議論しやすくなり、デザイン上の意思決定を円滑に進めやすくなるメリットがあります。
2. デリバリーフェーズ
デリバリーフェーズは、主に顧客に提供すると決まった価値をどのように届けるかを決めて、実際に届けるまでのフェーズです。代表的な業務は以下の通りです。
要件からUIを設計する
UIデザインデータの作成（モブデザイン）
UIデザインレビュー
プロダクトを開発する
プロトタイピング、マークアップ
ソリューションヒアリング
SmartHR UI の更新・適用
ユーザビリティテスト
プロダクトをリリースする
ユーザーフィードバックの分析
プロダクトの改善検討
このフェーズの特徴としては、ディスカバリーフェーズで特定したオブジェクトデータモデルに基づいて具体的なUIを設計していくため、コンポーネントを使用して画面ごとの詳細を設計したデザインデータが典型的な中間成果物になります。
基本的にはUIのブラッシュアップをしていくことになりますが、ソリューションヒアリングやユーザビリティテストによって、ユーザーのメンタルモデルと一致しないナビゲーション構造になっていることが判明したり、今後の機能拡張を見据えると画面レイアウトに無理が生じるなどの構造に起因する課題が出てくる場合は、オブジェクトデータモデルに立ち返って根本から見直すこともしばしばあります。
労務領域のデザインが難しい・やりごたえがあると思うのはどんな時？
労務領域のデザインをしていて、やりごたえがあるけど難しいと思ったことを3つ紹介します。
1. メインオブジェクトとなる従業員情報のプロパティが膨大かつ個人ごとに異なるため、効率的な操作に工夫が必要
労務領域でメインオブジェクトとして扱う従業員情報は、行政手続きの書類作成といった労務業務だけでなく、組織図の作成や人事評価、配置シミュレーションといったタレントマネジメント領域でも扱うオブジェクトでもあるため、内包するプロパティが非常に膨大になります。
加えて、従業員情報は当然ながら個人ごとに全く異なるため、入社手続きなど一度に大量の手続きを行う場合に作成する書類も基本的に個別に入力する内容が異なるため、ユーザーは従業員ごとに書類を1枚ずつ確認するなどの地道な作業が必要になるため、そうした業務をユーザーが迷わず効率的に実行できるようなインターフェース品質がデザイナーに求められます。
私が最近関わった機能としては、届出書類機能で書類の一括編集する機能があります。これによって、これまで書類ごとに各従業員の情報を1つずつ入力する必要があったのが、CSVファイルをダウンロードして複数名の従業員情報を使い慣れた表計算ソフトなどで入力したものを一括取り込みできるようになり、効率的な書類作成を実現しています。
2. 法改正や制度変更などの外的影響を受けやすい
労務領域の代表的な業務である行政手続きの書類作成では、主に政府が定めた書類様式に対応したシステム設計をしていますが、法改正や制度改正によって書類様式に項目が追加・削除されたり、様式自体が追加・廃止されるといった変更が随時発生します。
そのため、ドメインエキスパートを中心に変更情報を常にキャッチアップしており、変更を察知すると速やかにPMを中心にデザイナーやエンジニアを巻き込んで開発の計画を立てていくことになります。最近あった例だと、令和6年6月に施行される所得税・個人住民税の「定額減税」対応などが記憶に新しいです。
このように、期限に間に合わせつつユーザーの期待に応えられる必要最小限の価値を提供するためには、MVP（Minimum Viable Product）を見極めることが重要になります。こうした背景からも、必要最小限のコストで適切な判断を下すためのユーザーリサーチを行うことや、将来も見据えた理想状態から逆算して、期限までに提供できる要件とユーザビリティ（使用性）を担保したインターフェース品質をコントロールすることがデザイナーに求められます。
3. 外部システムとの連携が前提にあり、当たり前品質の水準が高い
労務業務は、すでにユーザーが利用している多機能な給与計算ソフトや、eGovやマイナポータルといった電子申請にまつわるシステムとの連携が前提になっており、これらのシステムですでに利用されている様式やデータに基づいて適切に対処できることが当たり前品質として求められます。
連携するシステムによっては、通信状態をステータスとして管理することで同期ずれを防ぐ仕組みが必要であったり、都度CSV形式での取り込み方式やAPIの設定が必要など個別対応が必要になることもしばしばあり、項目ごとのデータ型の変換（文字数や異体字など）といったバリデーションや異常系エラーを想定する必要があるなど、非常に泥臭い対応が必要になる場面も多いです。
加えて、外部システムの仕様変更といった外的影響による対応も発生するため、外部ステークホルダーとの適切なコミュニケーションが必要になるケースも少なくありません。こうした調査・調整はデザイナーが直接実行することは頻度として少ないですが、役割を閉じずに積極的に関わる姿勢がデザイナーには求められます。
労務プロダクトのデザイナーにはどんな人がいるの？
SmartHRの「プロダクトデザイン統括本部/プロダクトデザイン本部/労務プロダクトユニット」には、現在以下の7名が在籍しています。
全員それぞれ以下のような個性と強みがあり、相互連携を活かした共創を得意とするユニットです。
うえんつ：私
310：ユーザーリサーチ推進室のボスで、よくzoom背景にPerfumeの背後霊が映る
so：情報設計が得意で、よくスポーツのルールや仕組みの解説をしている
ysym：情報の交通整理が得意で、ヒアリングやファシリテーションがうまい
akasaka：オブジェクトモデリングが得意で、プロジェクトやプロダクトマネジメントにも定評がある
kabetch：Xデザイン学校でUXデザインを学び、最近プロダクトエンジニアから異動してきた
tafumi：デザインエンジニアリングに強みがあり、界隈のコミュニティでよく活動している
労務プロダクトの次の新メンバーはあなたかも？
この記事を読んで、SmartHRの労務プロダクトのデザイナーについて多少なりとも知ってもらえたでしょうか？
プロダクトデザイナーの組織にはこういうのもあるんだなぁ、と記憶の片隅にでも残していただけたら幸いです。
もしSmartHRのプロダクトデザイナーに興味をお持ちいただけましたら、積極的にカジュアル面談や採用をしていますので、以下の申し込みページからお気軽にお申し込みください！
この記事が気に入ったらサポートをしてみませんか？