はじめまして。株式会社SmartHRプロダクトデザイングループ（以下、プロデザ）で開発を担当している小木曽（＠kgsi）です。
SmartHRは、雇用契約や入社手続き、年末調整などさまざまな労務手続きのペーパーレス化を実現するクラウド人事労務ソフトの会社です。組織の中でプロデザは、ソフトウェアのインターフェース設計と改善、ユーザーリサーチから要件定義、フロントエンド実装などの役割を担い、各領域に特化したデザイナーが、部署や役割を越境しながら日々業務に取り組んでいます。
今回は若輩ながら、SmartHRプロダクトデザイングループの連載第1回目を担当します。
なぜ大量データとパフォーマンスに向き合うのか
表題にもある通り、この記事では大量データとパフォーマンスを見据えたインターフェース設計の話をします。
SmartHRは人事労務領域を扱うソフトウェアであり、従業員のデータがたまるほどに価値も高まっていくものです。ありがたいことに、テレワークの普及とともに登録社数とそれにともなう登録ユーザー数（従業員数）は伸びています。
そんな中、目下の大きな課題となっているのが下記の2点です。
- 登録される大量のデータを管理者がいかに操作負荷なく対応できるか。
- パフォーマンスという制約がある中で、どれだけユーザーにストレスを感じずに使ってもらうことができるか。
今回の記事では、課題に向き合う中で、言語化できたインターフェース設計の知見と方針を紹介していきます。
大量データに寄り添うインターフェース設計
インターフェースのデータ操作は、登録されるデータ量にあわせて最適化する必要があります。
たとえば、想定している表示件数が10件の場合と、100件、1,000件の場合では最適な探索パターンは異なります。
登録が10件程度しか見込まれないものであれば、情報を大きく見せ、詳細な情報へのアクセスを促します。一方1,000件以上となった場合、網羅的に情報を見ることは難しくなるため、ひとつの情報の表示領域をせばめて検索機能をつけるなど、設計や見せかたが大きく変わります。
ここからはSmartHRがインターフェースを設計する際に行っている内容を3つお伝えします。
1.操作に制限をつける
SmartHRが扱う人事労務領域は、使いやすいことも大切ですが、正しく、そして間違わずに操作できるインターフェースを設計することが重要です。給与や保険料といった扱う情報はどれも、間違えた場合にインシデントになり得る情報ばかりだからです。
センシティブな情報を処理する際、簡単かつ直感的に実行、処理できることよりも、下記のようなパターンが主だった対応例となります。
- 入力確認やチェックを通すステップを設ける
- データ入力時にはバリデーションをかける
- インターフェースの入力を受け付けずにデータでのみ更新させる
ときとして、OOUI（オブジェクト指向ユーザーインターフェース）などの設計よりも、タスクベース設計のほうがユーザーは操作しやすいこともあります。ひとつの考えにしばられない、柔軟な設計が重要です。
2.登録データ数によってモードを分けない
SmartHRはマルチテナントサービスです。ユーザー（従業員）登録数は数十人から数千人単位までレンジが広く、扱うデータ量の差が大きいソフトウェアとなります。そのため、どちらか一方の規模感に偏って対応すればよい、というわけではありません。
一般的に、〇〇件以上のデータが登録された時は、条件分岐として別の操作モードを用意しインターフェースを切り替える、といったケースも考えられますが、規模に応じたモードの使い分けを行うことで以下のデメリットが生まれます。
- 登録数をトリガーとした場合、ユーザーにモードの切替を強いることになる
- 操作体験が大きく異なり、ユーザーによっては再学習を強いることになる
- モードの違いを作ることで、開発側の負担が増える
そのため、規模（データ数）に応じてユーザーの操作体験を変えることは、基本的に避けるべきだと考えています。
3.運用負荷を考える
新しい機能や画面を追加すれば、当然ですが対象に対しての説明やサポートが求められます。ユーザーに求められるまま複雑なモードを持たせたり、画面ごとに違う操作体験を作ることは、ユーザーにメリットも生まれる一方、負担にもなります。
ソフトウェアは原則利用するユーザーを第一に考えて設計しますが、開発・運用側の負荷を無視した設計は、のちのち必ず崩壊します。
少し極端な例ですが、デスクトップとスマホとでは操作体験が大きく違うため、インターフェースも別々に設計し、最適化させることが望ましいです。しかし、そのあとの運用負荷を考えた場合は、ある程度最適化を犠牲にしたレスポンシブ（可変を前提としたインターフェース）な設計が好まれることもあります。
視覚的な操作体験のみにかたよらず、ほかのチームの声にも耳を傾け、協力してソフトウェア開発に向き合う必要があります。
