VisionalのHRMOS（ハーモス）事業部 デザイナーの三田です。人材管理クラウド「HRMOSタレントマネジメント」のプロダクトデザインをしながら、HRMOSにおけるデザインシステムの運用改善を担当しています。
1つのサービスに複数プロダクトが存在するなど規模の大きい開発を行うチームで、デザインシステムを導入しているところは多いと思います。HRMOSでも「Polyphony」というデザインシステムを導入。複数のプロダクト群から成るHRMOSの体験を統一するために生まれました。
デザインの属人性を排し、全体の体験に一貫性を持たせるためにデザインシステムは効果を発揮します。一方でデザインシステムの運用には時間がかかるため「作ったはいいけど、継続的にプロダクトづくりに使われるための運用体制ができていない」という課題をお持ちの方もいるのではないでしょうか。
HRMOSでも同様の課題が発生し、解決のため運用改善を担う「Polyphonyチーム」が誕生しました。
今回はPolyphonyチームで行った「よりデザインシステムの効果を最大化するため」の取り組みをまとめていきたいと思います。デザインシステムをもっとプロダクトづくりに活用したい方の参考になれば幸いです。
人財活用プラットフォーム「HRMOS」シリーズは、採用管理や従業員データベース、目標・評価管理、1on1支援など、様々なプロダクトから構成されています。
HRMOSのデザイナーは、プロダクトごとにアサインされています。そのため、プロダクトごとにデザインや管理方法が属人化し、アウトプットの品質にバラつきが生まれていたことが大きな課題になっていました。
課題解決のためにUI Kitの整備から始め、デザイン原則やコンポーネントの定義をまとめて、2020年の3月にデザインシステム「Polyphony」が誕生しました。
完成したばかりのPolyphonyはボタンやフォーム、アイコンなど基本的なコンポーネントが用意されたもので、それ以降は随時必要なコンポーネントや仕様ドキュメントを、タスクに余裕のあるデザイナーが作っていました。
しかし、プロダクトのデザイン業務の合間にPolyphonyを更新する体制になっていたため、時間の捻出が難しく、Polyphonyの新しいコンポーネントの定義や既存コンポーネントの改善は思うように進んでいませんでした。
そこで、デザインシステムの運用と改善を担当する「Polyphonyチーム」が発足。Polyphonyを利用する機会が多かった私を含むデザイナー4名、エンジニア2名がアサインされ、サイドプロジェクトとして動き始めました。
Polyphonyチームでデザインシステムの運用と改善を進めるために行ったことを紹介します。
1つ目は、「プランニング（Planning）」という、タスクの分解と見える化、アサインを行う時間を設けたことです。チームを立ち上げた当初は、隔週のミーティングでのタスクの完了報告のみで、各人のプロダクト側のタスク状況に合わせたアサインや、タスクの進捗確認はできていませんでした。そのため、気づけば「本業が忙しく、タスクの進捗が鈍いまま1ヶ月が過ぎてしまった」ということもありました。
そこで、まずは週に1度プランニングの時間を設けて各人の業務状況を把握。そのうえで進捗を確認し、タスクを進めるのが厳しそうな人には他のメンバーがいつでもヘルプに入れる体制にしました。
2つ目はレトロスペクティブ（Retrospective）という振り返りの時間を設けたことです。1ヶ月を1つの期間として、期間終わりに全員で「良かったこと」「悪かったこと」「改善のアイデア」を出し合います。その中で優先度の高いものや改善の余地があるものを、「やること」として次のスプリント以降で実行し、開発プロセスを改善します。
先ほどプランニングで「ヘルプに入れる体制づくり」ができたと紹介しましたが、その改善もレトロスペクティブでのアイデアから生まれました。
3つ目は「Polyphony Time」の策定です。デザインシステムのコンポーネントやスタイルの定義はプロダクト全体に影響を与えるため、チームで意見を出し合い慎重に行わなければなりません。
そのためPolyphonyチームでミーティングが必要な機会は多くあるのですが、メンバーの予定が合わず時間を押さえるのが難しい課題がありました。
そこで毎週水曜の3時間は「Polyphonyにコミットする時間」と決め、他のミーティングは原則入れないようにしました。結果的にミーティングが組みやすくなっただけでなく作業の時間も捻出され、チームで進捗を出せるようになりました。
ここからはPolyphonyチームで実施したデザインシステム浸透の取り組みを、プロセスと合わせて1つ紹介します。
Polyphonyチームのミッションの1つに「Polyphony利用者に、スキルに依存しない一定の品質が担保されたUI/UX基盤を提供する」というものがあります。そのため、デザインシステムの改善だけでなく、属人化を防ぐためのチームへの浸透にも責任を持っています。
なかでもインパクトが大きかった取り組みが、デザイン原則の再定義です。
デザイン原則自体はPolyphony発足当時から定義されていたのですが、レビューの場でデザイン原則に基づいた議論が出てこないなど、業務内であまり活用できていませんでした。チームでデザイン原則を再定義、明文化することで、一人一人がデザイン原則を自分ごととして捉えられ、業務に活かせる状態を目指しました。
Polyphonyには3つのデザイン原則と5つのテーマがあり、テーマは原則に収束されます。当初はそれぞれの原則やテーマを表現する言葉はあったものの、その言葉が指すイメージや程度が可視化・すり合わせできていなかったので、まずはその認識をチームで合わせることから始めました。
まず、テーマごとにメンバー全員でどのようなイメージを持つか、それぞれがイメージするサービスや画像素材を貼ってムードボードを作りました。
ムードボードでイメージを合わせつつ、次にテーマを実践するうえで、すべきでない行動（Don’ts）すべき行動（Dos）を洗い出し、言語化を進めていきます。
最後にそれを文章化して、各テーマがどのようなことを意味するのか、シャープかつ正確に表現しました。
このように一つ一つのデザイン原則とテーマを定義し直し、開発チーム全体に共有。日頃から原則を意識できるようにZoomの背景・ロゴも作成しました。
結果としてデザイン原則やテーマが開発チームに浸透し、認識もメンバー間で揃ったので、レビュー時にもよくテーマが使われるようになりました。
デザイン原則の再定義は1つの例ですが、ルールやコンポーネントを定義して、開発チーム全員が自然と使えるよう、チーム内に浸透させるところまでPolyphonyチームが担当しています。
最初に説明した通り、HRMOSは複数のプロダクトにまたがるため、プロダクト間の一貫性を意識していないと体験がバラバラになってしまいます。複数のプロダクトが組み合わさって初めて新しい価値が生まれるので、体験を統一させるためのシステムをつくるPolyphonyチームの仕事は、非常にインパクトの大きいものだと思っています。
現在、PolyphonyはHRMOSシリーズの各プロダクトに使用されています。しかし、HRMOSシリーズ内でプロダクトごとにあるべき設計やスタイリングは異なります。
例えば、目標・評価管理のプロダクトは人事がメインユーザーのため、B向けの業務システムの設計が向いている可能性もありますし、逆に1on1のプロダクトは全社員がユーザーのため、C向けの誰もが使いやすいデザインのほうがユーザーにとって使いやすいかもしれません。
各プロダクトの特性に最適化され、あたかもユーザーに1つのプロダクトのような体験を提供するデザイン。その一方で、毎日使いたくなるような情緒的価値もあるデザイン。それが両立できる状態をPolyphonyでこれから実現していきたいです。