チーム体制の整備後はプロダクト基盤の再構築へ、リリース9年目のプロダクトに「デザインシステム」を導入するワケ

日本一のプロダクトと開発組織を目指す、jinjer社の飽くなき進化 第3回

　サービスの多様化とプロダクトの連携が進む今、「一貫性のあるユーザー体験」は企業競争力の源泉です。特にSaaSでは、プロダクトの見た目や使いやすさに加えて、開発効率や運用の拡張性といった観点からも「設計の共通言語」が求められるようになっています。その手段の一つとして注目されているのが「デザインシステム」です。ブランドの世界観を保ちながら、UI/UXと開発の間に橋渡しし、複数プロダクト間で一貫した体験を提供します。jinjer（ジンジャー）はプロダクトリリースから9年、12以上のHR関連プロダクトを展開してきました。本稿では、なぜ今このタイミングで「デザインシステム」の導入に踏み切ったのか。その背景とプロセス、そして実装する難しさと成果について、取り組みの全貌を紹介します。

なぜ今、プロダクトに「デザインシステム」が必要なのか

　プロダクトの多機能化とチームの分業化が進む今、開発スピードを維持しながら、一貫したユーザー体験を提供し続けるには、「明文化された共通言語」の存在が不可欠です。その鍵を握るのが「デザインシステム」です。

　デジタル庁では、デザインシステムを「WebサイトやWebアプリケーションを作る際に参照するルールのまとまり」と定義しています。しかし、実際の現場で重要視されるのは、その「見た目の整備」以上に、「誰が関わっても迷わずに判断できる状態」をどう作るか、という構造設計の問題です。

　多くの企業が直面するのは、以下のような課題です。

• プロダクト間でUXが分断され、ユーザー体験に一貫性がない
• 部門ごとに情報設計や表現がバラバラで、ブランド体験に一貫性が欠けている
• デザインと開発における実装方針の不整合により、生産性と品質の両立が困難である

　こうした状況を放置すれば、プロダクトにも影響が出てきます。実際当社でも「jinjerらしさ」を社内外で伝えることが困難になり、UXと事業成長の両面に悪影響を及ぼすと判断しました。

　「デザインシステム」とは単なる「ルールブック」ではなく、「プロダクトとチームをスケーラブルに保つための経営資産」であるべきです。組織が成長し、関わる人数やサービス数が増えるほど、全体の整合性を保ちつつ意思決定のスピードを維持するには、明文化されたルールとそれを支える運用が不可欠です。

　jinjerでは、このような課題を正面から見据え、「共通言語としてのデザインシステム」構築に踏み切りました。本稿では、その背景と狙い、導入プロセス、そして実際に現場で得られた変化を、具体的にひもといていきます。

• 参考：デジタル庁「デザインシステムとは」

クラウド型人事労務システム「ジンジャー」シリーズとは

　jinjerのデザインシステムを作るきっかけを説明する前提となる情報として、「ジンジャーシリーズ」について、簡単にご紹介します。ジンジャーは、人事労務・勤怠管理・給与計算などの人事の定型業務から人事評価・サーベイといったタレントマネジメントまで、一つにまとめて管理できるサービスです。

　ジンジャーシリーズでは、人事情報を一つに統合した「Core HRデータベース」にある「正しい人事データ」をもとに、人事労務管理、勤怠集計、給与計算、社会保険手続き、帳票類の作成など、人事にまつわる定型業務の効率化・自動化を支援しています。この構造は、ジンジャーの競争優位の一つですが、同時にUX設計上の課題も抱えていました。プロダクトが増えるにつれ、画面設計やUIルールが個別に最適化されていった結果、同じデータ構造の上にあるにも関わらず、「ユーザーはサービスごとに異なる操作感に直面していた」のです。デザインシステム導入の背景には、この「構造としては統合されているが、体験としては分断されている」状態を改善する狙いがありました。

　そこで私たちは、「上位のブランド設計」と「プロダクト設計」を接続する構造的な仕組みとして、デザインシステムの全体像を再定義しました。

　下図は、その全体像を示したものです。

　左側では、コーポレート・ブランド・ビジュアルといった各アイデンティティから構成される「会社の思想」が示され、それがブランドガイドラインを通じて言語化されています。

　右側では、それらの思想を踏まえて設計された「デザイン原則」「ユーザビリティ原則」「アクセシビリティ原則」が、プロダクトにおける判断基準として機能します。

　そうした原則群を具現化する形で「デザイントークン」「UIコンポーネント」「パターンライブラリ」などが構築され、最終的にそれらが「Zeroheight」によって「全社的に参照可能な設計ガイドライン」として統合されています。

　また、思想設計から実装プロセスにかけては、「Goodpatchとの共同開発体制」を敷き、社内の思想と外部の専門知見を組み合わせる「共創」の形で進めていきました。