異なるメンタルモデルを観察してデザインしよう
「Money Forward Design Advent Calendar 2024」の2日目の記事です。
この記事は、バックオフィスSaaSのプロダクトにおける重要な"従業員"というデータをどうデザインするか？に対する観察と見解です。
"従業員"が存在するプロダクトはたくさん。
マネーフォワード クラウドには、"従業員"が登場するプロダクトが数多く存在します。
マネーフォワード クラウド給与
マネーフォワード クラウド勤怠
マネーフォワード クラウド社会保険
マネーフォワード クラウド人事管理
マネーフォワード クラウド年末調整
マネーフォワード クラウドマイナンバー
マネーフォワード クラウド経費
マネーフォワード クラウド債務支払
マネーフォワード クラウド請求書（請求書Plus）
マネーフォワード クラウド個別原価
…など
"従業員"は、サービス基盤とも言えるデータです。勤怠管理や給与計算、経費精算や請求と支払い手続き、社内の原価管理など。これらの仕事は、申請や承認、データ保管などオペレーションに伴う社員間のコミュニケーションも含みます。"従業員"というデータは、会社そのものを動かし続けるために必要不可欠な存在です。
"従業員"の氏名は、カジュアルに変えて良いデータとは一概に言えない。
労務担当者は、従業員の氏名は無闇に変更したくないと思う傾向があります。理由は、労務担当は従業員の情報を行政機関に関わる手続きに使うためです。氏名と聞けば、「手続きに使う、戸籍に登録されている氏名（姓と名）ですよね？」と
労務担当者はイメージするわけです。
「漢字が難しくて読み方を聞かれるから、氏名を平仮名にしよう」や「グローバルメンバーが多い職場なので、英語表記にしたい」と勝手に変更したら、労務担当者が行う手続きに支障を来します。
データ１つとっても、そこにある価値が何か考える。
結婚というライフイベントは、人の名前を変えることがあります。名前が変わった従業員は、「結婚前の名前を使い続けたい。」と言うかもしれません。しかし、そこには「システム上の"姓"のデータを、旧姓にしたい」といった意図はないでしょう。この従業員の要求は、例えば「同僚に名前が変わったことを知られ、波風を立てたくない」だったり「旧姓が気に入ってるから変更したくない」といった内容が推測できます。
オブジェクトの検討では、データの少しの違いも考える必要がある。
要件は「社内のコミュニケーションツールで旧姓を表示できる」といった内容に落ち着きそうです。さらに、具体的な要件にしていくと"ビジネスネーム"や"ニックネーム"のように、従業員の意向を尊重した名前を柔軟に扱えるデータの開発が検討されそうです。そこに価値があるからです。UIのプレゼンテーションを考える前に、データとしてどうなるか？の検討から開発メンバーと擦り合わせることは大事です。
視点を変え、最適な要件を検討する。
"氏名"のような一見誰でもわかりそうなデータでも、みんなが同様に認識するとは限りません。むしろ、”氏名”のような一般的にも見聞きする情報だからこそ、認識が様々あるのでしょう。
認識のされ方の把握は、"従業員"を扱う１つの視点のみで捉えていては難しいです。ここで、「旧姓をそのまま使いたい」という声を軸にしたユーザーストーリーを考えると、登場人物も明確になるし考えるべき課題も見えてきます。
「戸籍の氏名は、変更できる人を限定できる。」
「コミュニケーションに使うユーザーの表示名は、ユーザー自ら設定できる。」
結果として、上記のような権限の制御まで要件になるかもしれません。要求を鵜呑みにすると事故や課題が生じることもあります。用途が異なるデータなら、混ぜるな危険です。
"従業員"のすべてを知る人は存在するのか？
人を把握して管理するって、果てしないです。例えば、"金前（kanemae）さん"という従業員がいたとしましょう。
金前さん
トップセールスマン
２児の親
宇宙オタク
アマチュアダンサー
金前さんの同僚なら、金前さんのセールスマンとしての優秀さを知っているでしょう。しかし、2児の親の顔まで知り得るでしょうか？ダンス教室の先生は、金前さんのダンステクニックと大会での成績は知っているけど、会社での活躍や報酬は知り得ません。金前さんのすべての顔を知っている人はいないのです。極端な話、家族でさえ100%は知らないでしょう。しかし、それでも社会はうまく回っています。
「経費申請した内容の内訳と総額は？」
「PJでの稼働工数は？」
「年末調整で還元された額面は？」
「育休期間は？」
「8桁の保険者番号は？」
「入社時の履歴書の在り処は？」
「新入社員の交通ルートは？」
「利用しているツールのアカウント情報の権限制御は？」
このような質問があったら、満点で回答できる人は極めて少ないでしょう。「人は、他人のすべてを知り得ない」という実態は、バックオフィス領域における"従業員"の管理においても同様の可能性が高いだろうと私は考えています。
会社の運営は役割があり、アクセスできる権限も異なります。従業員のデータに多くアクセスできる権限を持つ人たちは、従業員のすべてを把握しているのでしょうか。
人事部の本部長のようなポジションまたは経営層
アクセスできる従業員のデータ数は、多い（殆どすべて）。
現場の一人ひとりの日常業務に関わるデータを見て、解釈することは難しい。
事業者として従業員のデータを扱う仕事は多い（行政機関に関する手続きやデータ開示を行う）。
現場の管理監督者
アクセスできる従業員のデータ数は、少ない（一部のみ）。
現場の一人ひとりの日常業務に関わるデータを見て、解釈することができる。
事業者として従業員のデータを扱う仕事は少ない（行政機関に関する手続きやデータ開示は行わない）。
一人社長だったり従業員数が少ない場合を除き、多くの会社では上記のような実態があるように思います。会社の現場には役割があり、情報のアクセス権も制御されています。それは勿論、仕事や期待値が異なるためです。すると当然、扱いたい従業員のデータ項目も異なります。また、従業員本人との関係性や距離感により、データの解像度は高くも低くもなります。もちろん、AIによるデータ活用が進めば、状況も変わっていくでしょう。例えば、BIツールのような仕組みで膨大なデータの整理と可視化が解釈しやすくすることも可能かもしれません。
役割の違いでアクセスできるデータに違いがあっても、多くのオペレーションが成り立っている会社は多いです。それは、会社の組織による仕事の分担と連携が機能しているからと思います。言い換えると、バックオフィスの業務領域を理解し、適切にデータへアクセスできるようにすることが現状の利用者に歩み寄るデザインになるのかもしれません。効率化はもちろん「気が利くね！」と言われるような工夫も織り交ぜながら。
必要以上にデータへアクセスしたくない人もいる。
これまで、私も利用者にインタビューする機会が何度もありました。以前、社内ネットワークや備品を管理してくれているサポートエンジニアさんから「従業員のデータは、むしろ見たくないものが多い。人の給与情報は特に知りたくない。」と聞いたこともあります。なぜ知りたくないのか？というと、知ってしまった人と対面すると「この人、こんなに頑張ってるのに給料はあれくらいなのか」のようなことが頭に浮かんでしまって嫌なのだそうです。似たような声は、他の人からも聞くことはありました。データへ沢山アクセスできることが、必ずしもポジティブな状況を生むとは限りません。
利用者の仕事を観察し、データのあり方を整理する。
そもそも「従業員を管理する」といったレベルで捉えるだけでは、要件定義は難航します。マネーフォワード クラウドの利用者属性の代表例に人事部や経理部の方々が挙げられます。この両者が連想する「従業員を管理する」という仕事もプロダクト上の課題も異なります。
ABOUT FACE インタラクションデザインの本質（アラン・クーパー）では、「表現モデルがユーザーのメンタルモデルに近ければ近いほど、ユーザーはアプリケーションを使いやすく、理解しやすくなる。」と語られています。
では、従業員を扱う人たちの「従業員を管理する」というメンタルモデルってどんなものでしょう？私が利用者の属性を持つ方々から見聞きしたところでは、人事部の視点では「異動や入退社を成り立たせること」、経理部の視点では「経費精算する人のログインと、申請を承認するフローを設定すること」がイメージされている印象を受けることが多いです。
仕事の役割が異なれば視点も異なり、扱う従業員のデータの捉え方も異なります。利用者のメンタルモデルらしいと思われること自体、バイアスがあるかもしれません。だからこそ、プロダクトデザイナーは、それぞれの利用者の視点と認識を観察し、UIデザインにおけるオブジェクトやモデリングの検討が進める必要があります。
「労務担当が、そう言っていたから」と、現状の利用者のデータの扱い方を鵜呑みにしてはいけません。利用者の現状のオペレーションがそうなっているだけであり、それが理想的なデータの扱いではない可能性もあるからです。
我々プロダクトデザイナーは、道具として本来どのようにデータを扱えたら良いか？PdMと議論し、日々の業務でデザインを進める必要があります。
マネーフォワード クラウドで"従業員"をデザインするには。
現状のマネーフォワード クラウドは、強みとする戦略が裏目になり、データがバラバラになって利用者の手間が増えているという課題があります。
「同じマネーフォワードのサービスを使っているのに、複数箇所でマスタ設定をしなくてはならないのは面倒だ」というご意見をいただくことが増えました。
同一人物の金前さんの従業員データがいくつもバラバラに存在するようでは、多重メンテナンスが必要になります。この解消には、マネーフォワード クラウドの”従業員”をサービス基盤となるオブジェクトとして、よりよい形を目指していく必要があります。
視点が異なれば見え方も変わるという事象は、人の情報を扱う開発では如実に現れます。人に関するデータを作ることは、複雑で難しいです。このようなデータについて考える活動が、マネーフォワード クラウドのようなプロダクトのサービス基盤づくりにおける特徴の一つかもしれません。同様な開発をしているプロダクトデザイナーやPdMの方々とも、ぜひ意見交換してみたいですね。
まだアドベントカレンダーは続きます！
