意外と手強い？ 複数プロダクトのコンポーネント統合、その裏話

はじめに

Bill OneとContract Oneのプロダクトデザイナー兼マネージャーを務めるみそんです。
前回、こちら↓のnoteで私の経験談をシェアしていましたが、

今回は、私が手がける2つの「One」プロダクトにおける、コンポーネント統合の舞台裏について、構築から運用に至るまでのリアルな奮闘記をシェアします。これからコンポーネント構築に挑む皆さんにとって、少しでも参考になれば嬉しいです！

本題に入る前に、Bill OneとContract Oneがどんなサービスなのか、簡単にご紹介します。

Bill Oneは「請求書」、Contract Oneは「契約書」の管理をメインとするプロダクトですプロダクトの詳細については以下のプロダクトサイトをぜひ一度チェックしてみてくださいね！

プロダクト統合コンポーネント - 「One UI」がもたらす3つのメリット

One UIは、Oneプロダクトのデザイナーとエンジニアが力を合わせた結果、開発されました。実現できた背景として、「ユーザー・開発・デザイナー」という3者それぞれに、三者のそれぞれに、 3つのコスト軽減効果が期待でたことが挙げられます。

1. ユーザー：「学習コスト」の軽減

Oneプロダクトのユーザーは、Bill OneやContract Oneを順次導入するケースが多くあります。片方のOneプロダクトを導入し、価値を理解いただいてからもう片方を導入されるようなケースです。

この際、統一された「One UI」により、例えばBill Oneを利用している企業が後からContract Oneを導入する際も、一貫性のあるUIUXのおかげで、新たに使い方を学ぶ負担が軽減されます。結果として、自然な操作感でスムーズに利用を開始できます。

2. 開発：「実装コスト」の軽減

OneプロダクトはアーリーフェーズのSaaSプロダクトとして、迅速なPDCAサイクルが求められます。その中で、One UIの統合は開発スピードを加速させる重要な役割を果たしました。

統合コンポーネントが導入される前は、自由度の低いUIライブラリーを利用していたため、必要に応じて都度個別のCSSを適用する手間がかかり、ボタンスタイルの一貫性の担保が難しいときがありました。
また、各コンポーネントの振る舞いまでは既存のUIライブラリーで制御できず、実装の度にエンジニアとのコミュニケーションが必要となっていました。

そこで振る舞いやスタイルパターン、仕様やデザインガイドラインまで定義し、実装幅を広げた共通のコンポーネントを利用できるようにしたことで、開発効率が向上。工数を削減でき、ユーザーに必要な機能をより早く届けられるようになりました。

3. デザイナー：「画面作成コスト」の軽減

Oneプロダクトのデザイナーが増え、複数人で作るプロダクトの品質担保がますます重要になっています。コンポーネントの構築は、その品質担保の最もベーシックな取り組み。

特に、新たにジョインするデザイナーにとって、充実したコンポーネントとガイドラインは学習負担を大幅に減らします。その結果、プロダクト理解のスピードが上がり、早期に活躍できる環境が整います。

本格的な構築に取り掛かる前に、やっておけばよかったこと

これからコンポーネント構築に取り組む皆さんに、まずおすすめしたいのは、初期段階でデザイナーやエンジニアを含む関係者全員で「方針」を明確にし、「共通認識」を作ることです。この一手間が、後々の判断や議論を驚くほどスムーズにしてくれます。

「なぜ」「何を」作るのか、共通認識を持つ重要性

私たちはこの共通認識の必要性に途中で気づき、構築の最中に「OneのDesign Philosophy（フィロソフィー、デザイン哲学）」を策定することになりました。このフィロソフィーがどのように生まれ、どのように活用されたかについては、こちらのNote記事で詳しく紹介していますので、ぜひご覧ください！

共通認識の効果：議論や判断のスピードが向上

例えば「Button」一つの定義を考える際、デザイナーとエンジニア全員がそれぞれの視点で「理想の形」を追求しようとします。結果として、熱意が議論の白熱を招き、なかなか結論に至らないこともあります。

さらに定義すべきコンポーネントが数十個ある場合、それぞれに60分ずつ議論していたら膨大な時間が必要になります。それでも結論が出ない場合、全体の進みが停滞してしまいます。

このような経験をした私たちは、以下のような共通認識を作りました。

共通認識を作ったことで、最終的にはOne UIの品質も継続的に改善できるようになりました。

実際に行った初期構築のフロー

構築において最初に目指したのは、プロダクト上にすでに存在するコンポーネントの共通化です。まだ存在しないコンポーネントを今後のために定義しておくではなく、まずはあるものを整理し、統合するための営みから始まりました。

このプロセスで最も重要だったのは、「メンバー間のコミュニケーションを通じた意思決定」です。例えば、「Button」の定義ひとつを取っても、以下の4つの観点を満たす必要がありました。

1. これまでの利用状況を把握

   • 今までどのように使われていたか（既存利用の調査）

2. これからのあるべき利用方法を定義

   • 今後どのように使うべきか（先行した他社Practiceの調査し、参考）

3. 品質担保の確認

   • ユーザビリティやアクセシビリティの観点から、最低限の品質を維持できているか

4. 実装と拡張性

   • 実装が簡単であり、かつ拡張しやすい定義になっているか

これらを満たす定義付けをするには、数多くのコミュニケーションが必要です。そのためSlackやMTG等で同期・非同期のコミュニケーションを積極的に行いました。

エンジニアの協力なしでは実現できない

ここまでの取り組みが実現できたのは、この営みに共感し、賛同してくれたエンジニアたちの存在があったからです。幸運なことに、各プロダクトには優秀なエンジニアが多く在籍しており、この活動に積極的に参加してくれました。さらに、自ら率先してプロダクト内の他の開発チームへの展開にも尽力してくれたおかげで、前述した各メリットを実際の形として体現することができました。

現在の運用

現在は共通化されたコンポーネントが各プロダクトでも積極的に利用されていて、実装効率もさらに向上しています。とはいえ、コンポーネントの改善は日々の業務から発生・発見されるので、この改善に向けた運用をメインに行っています。

1. 柱となる方針に従いつつ、柔軟に指針を決めることで運用の効率化を図る

前述した通り、フィロソフィーを定義し日々意識していても、方針だけでは不十分な場面もあります。その都度議論を重ね、必要な指針を決めることで運用の柔軟性を確保しています。

例えば「完璧な定義を目指さない」ことも後から決めた指針の一つです。なぜなら、後から新たな課題や必要な拡張が必ず出てくるため、最初に完璧を目指しても実際にはそれが実現しないからです。私たちは、まずは今直面している課題を解決することに現在の運用として集中しています。
そして、改善のPDCAを回し続けることで、コンポーネント自体も成長させるというマインドで運用を進めています。この柔軟な戦略が、One UIの成長を支える鍵になっています。

2. 継続運用できる形で実施する

以下は、一週間内にある非同期MTGの運用イメージです。
日々の主要業務に支障をきたさないよう配慮しつつ、日々の業務から発生・発見されるコンポーネントの改善を議論し、アップデートしやすい形を意識しています。

One UIを公開しました

初期構築から運用を続けているOne UIを、FigmaのCommunityで公開しました！
開発が実装したStorybookも同時公開中です。

これからコンポーネント構築に挑む方や、Oneプロダクトの仕組みに興味がある方は、ぜひご覧ください。
感想や改善のフィードバックも大歓迎です！Figma Community上でいただいた意見をもとに、さらにアップデートしていきます。

今後に向けて

今後は、One UIのアップデートに加え「OneのA11y」や「Oneの文言ガイドライン」などの公開も予定しています。
これからの展開にも、ぜひ引き続きご注目くださいね！

また、Sansanの全プロダクトデザイナーやPdMの日々の向き合い方について、以下からチェックしてみてください。