はじめに
こんにちは、開発 3 部 CRM チーム所属の玉利です。普段は 買取販売の社内サービスのプラットフォーム(以下、Cosmos)の 1 つのサービスにおいて、フロントエンド開発や UI デザインの作成を担当し、MUIをベースとした独自の UI を作成、開発をしています。本記事では、私たちが取り組んでいる UI デザインの共通化について、その背景や課題、具体的なアプローチ、そして今後の展望などを詳しくご紹介します。
サービスデザイン共通化の概要
Web サービスや業務システムの開発においては、見た目だけでなく、ユーザー体験（UX）の質や開発効率の向上がますます重視されるようになっています。一方で、多くの企業や組織では、サービスごとに異なる UI デザインや実装方針が存在し、管理コストや保守コストがかさんだり、ユーザーが感じる使い勝手にバラつきが生まれたりといった課題に直面しがちです。
そこで Cosmos では、第一歩として「ヘッダー」のコンポーネントを共通化する取り組みを実施し、将来的にはフォームやテーブル、モーダルといった他の UI パーツへと拡大していきたいと考えています 。これによって、全社的に UI/UX を高い水準で揃えつつ、開発現場の効率化を目指しています。
なぜデザイン共通化が必要なのか
サービスごとのUI/UXのばらつき
Cosmos では、買取や販売など複数の業務領域を横断して機能が提供されています。しかし、そのたびに UI 要素をゼロから設計・実装していては、ユーザーが各サービスを利用する際の混乱を招くリスクも高まります。実際に、社内にはさまざまなサービスが使われていて、それぞれ異なるデザインルールやそれに応じた異なるコードベースを持っていました。
開発・保守コストの増大
こうした状況では、デザイナー同士の共通言語が十分に育ちにくいだけでなく、エンジニアにとっても異なるプロジェクトごとに開発・保守の手間がかかってしまいます。その結果、「デザインは見た目の問題だから後回しでいいのでは？」と理解されがちで、なかなか踏み込んだ統一が進まないという問題が起こっていました
共通化する際の課題
既存サービスへの適用コスト
デザインの共通化を実践しようとする際、最も大きな障壁の一つはすでに使われているサービスへの適用です。すでにリリース済みのプロダクトが複数存在すると、それらをすべて統一的なデザインに移行するには相応のコストと労力が必要になります。
そこで Cosmos では、まずは「ヘッダー」のコンポーネントを共通化する取り組みを実施し、将来的にはフォームやテーブル、モーダルといった他の UI パーツへと拡大していきたいと考えています 。これによって、全社的に UI/UX を高い水準で揃えつつ、開発現場の効率化を目指しています。
業務領域ごとのUI要件の違い
例えば、管理系のサービスでは文字サイズを小さくして情報を一覧しやすくしたり、買取の際にはお客様と話しながら同時に作業することも多いため、ボタンサイズを大きく確保する必要が出てきます。また、スマホや PC などデバイスによる画面サイズの違いも考慮しなければならず、それぞれの利用シーンに合わせた UI 設計が求められます。
非デザイナーへの理解促進
「デザイン=見た目」以外の意義が浸透していないと、共通化に向けた投資や工数の確保が難しくなります。実際に、デザインの共通化は見た目の一貫性だけでなく、ユーザーの UX 向上、コードの再利用性、保守性の向上といった多面的な効果を狙っているのですが、その意義を十分に説明しないままだと「ただのリニューアル企画」と捉えられてしまいがちです。
共通化のポイント
共通化にあたって導入、機能的・UX に対してつまづいた部分の教訓として気をつけるべきポイントをいくつかご紹介します。
導入
エンジニアとの連携：小さく始める
相談したところ「導入する時間が取れない」「導入工数は下げたい」といった意見がでました。
大きく導入しようとすると拒絶感や工数が膨らんでしまいます。そのため、小さく共通化を始める方針をお勧めします。共通化しやすい部分や共通化したパーツを取り込んで実装した際に双方のメリットが大きい部分から導入していくと良いです。
デザイナー間の連携：共通部分の特定
何を共通化するかを決めるのはデザイナーです。ただ、各サービスで各ドメインに沿ったデザインを組んでいるのでそれを統合して共通化していくのは至難の業です。そのため、各サービスの UI パーツを照らし合わせて共通化する UI パーツをドメインと関係の少ないものから決める必要があります。ドメインと関係があるものは揃えるかは相談して決めます。
ユーザーへの配慮：違和感の排除
実際に触るユーザが各サービスを移動する際に違和感がないようにしないといけません。ひとつのサービスではヘッダーが左にあり、もうひとつでは上にあるといったようなことが起きると混乱してしまいます。
機能・UX
サービス間のスムーズな移動
共通のヘッダーメニューを導入することで、ユーザーが複数のサービスを行き来するときの混乱を減らします。デザインが統一されていることで学習コストが減る・UX が共通になるので、ユーザーがサービスを移動する際に違和感が少ないようにできます。
レスポンシブ対応の統一
スマートフォンやタブレット端末など、多様なデバイスでの表示崩れを起こさないよう、柔軟にレイアウトを変更しやすくします 。
拡張性への配慮
新たなサービスを開発する際にドメインによって偏ったデザインを取らざるを得ない場合にも柔軟に対応できるようにすべきです。 ただ、考えるべきケースが多すぎる場合もあるのである程度で妥協していく必要があります。
ヘッダー共通化のプロセス
ここからは、Cosmos のヘッダーを共通化するにあたっての具体的なプロセスを解説します。今回のプロジェクトでは、既存のデザイン案を活用しつつ、各サービスへの導線を整理・拡張する方針を取りました。検討中のものもありますがご了承ください。
要件整理
導線設計
ユーザーによって使うサービスが違うので権限によってメニューの表示・非表示を切り替えるなど、ユーザーの権限体系に合わせた導線設計が重要です。
メニュー名
開発時には店舗査定のものに「Store」などコードネームをつけて実装しています。ただメニューの名称においてはコードネームや略称ではなく、「店舗査定」「在庫管理」など日本語の正式名称を用いることで、初見のユーザーでも直感的に理解できるようにします。
デザイン案の作成
デザイン案作成
すでに Cosmos のヘッダーデザインの下地が存在していたため、それをベースに統合案を作成しました。
コンポーネント作成
共通したリポジトリを作成してヘッダーコンポーネントを管理します。Storybook などのドキュメントツールを使って再利用方法・拡張方法を明示し、将来的な保守に備えることが重要です。
現在は検討段階
ボタンサイズや文字サイズ、レスポンシブ対応など、詳細な仕様については随時見直しながら進めています。
コード管理
以下の案がありどちらかの案を選択して配信していきたいと考えています。
npm パッケージで配信
共通化したヘッダーを npm パッケージとして配信し、各サービスからインストールできるようにします。バージョン管理をしやすくし、新機能や修正を継続的に反映可能です。
サブモジュールによる共通化
もしくは Git のサブモジュールとして各リポジトリに取り込む形も検討中で、それぞれのプロジェクト状況に応じて柔軟に選択していきます。
導入と検証
部分導入
いきなりすべてのサービスに適用するのではなく、まずは一部のサービスで導入・検証を行います。その結果を踏まえてデザイン面や機能面の修正を行ったうえで、他のサービスにも段階的に展開していく方針です。
継続改善
ヘッダーだけでなく、各種コンポーネントの共通化の実績やノウハウを踏まえ、随時リファクタリングや UI 改善を進めています。
期待される効果
共通ヘッダーを一部のサービスに導入することで、デザイン上の統一感が増し、ユーザーの戸惑いが減ると期待されています。これにより、ユーザーが複数のサービスを横断するときにも一貫した操作感を得られ、より円滑に業務を進められる見込みです。
ただし、すべてのサービスへ完全移行するには、大規模な既存サービスへの導入コストや調整負荷がかかる可能性があるため、一朝一夕に完了する取り組みではありません。そこで、共通パーツのバージョン管理や拡張性を高めながら段階的な移行を行い、開発プロジェクトの重要タスクとして認識してもらうための社内コミュニケーションを強化していく方針が鍵となると考えられます。
将来の展望・ネクストアクション
今後は、ヘッダー以外の「ボタン」「フォーム」など他の要素にも共通化を拡大していきます。 UI それぞれのドメイン固有の要件を吸収しつつ、再利用しやすいコンポーネント群を整備することで、開発スピードとプロダクト品質の両面でメリットを得られると考えています 。
おわりに
Cosmos におけるデザイン共通化の取り組みは、まだ始まったばかりですが、導入コスト以上の大きなメリットがあると感じています。UI や UX を統一することは、見た目の統一にとどまらず、開発生産性の向上にも大きく寄与します。そして何より、ユーザーが異なるサービスを利用する際の利便性と安心感を高めることにつながります。ただ、共通化をするにあたり失敗しないために導入や機能的なこと・UX に対して気をつける必要があります。
今後も、第一歩となるヘッダーから他要素へ、より多くのサービスに共通化を広げていくことで、サービス提供者・ユーザーの両者にとってよりよいプラットフォームを構築していきたいと思います。
最後に、バイセルではエンジニアを随時募集しています。 興味のある方はぜひ以下の採用サイトをご覧ください。
