共通基盤デザインシステムInhouseの開発でやっていること
Dec 11, 2021
SUZURIというサービスでデザイナーをやっている putchom（@putchom）です。
GMOペパボ株式会社の共通基盤デザインシステムであるInhouseの開発に携わり始めて1年くらい経ち、現在は開発をリードするまでになったので、どのような経緯でInhouseのプロジェクトに参加し、今リードとしてどんなことをやっているのかを紹介します。
そのために、まずInhouseとは何かを説明します。
Inhouseとは
Inhouseとは、GMOペパボ株式会社の共通基盤デザインシステムです。
デザインシステムとは、ブランドがタッチポイントを活用した体験設計を効率的におこなうために、あらかじめ原則やガイドラインを定めて、その実装としてカラーパレットやコンポーネントライブラリなどのアセットを用意したものです。その上で、各サービスが個別に考えていているような、原則やガイドライン、実装していたアセットのうち、重複しているものをすべてのサービスで使えるように一般化して、あらかじめ用意しておいたものが共通基盤デザインシステムです。ペパボでは、この共通基盤デザインシステムに、「Inhouse」という名前をつけて呼んでいます。
ペパボでは複数のサービスを運営していることから、Inhouseは複数のブランドで使用することを前提とする必要があります。そこで、わたしたちは「Flavor」という仕組みを採用しています。色や形など、ブランドによって上書き可能なデザイントークンをFlavorと呼んでいる変数にまとめておくことで、Flavorを差し替えることでブランドイメージを崩さないデザインができるようになります。
さらに詳しく知りたい方は Inhouseとは - Pepabo Designをご覧ください。
参加からプロジェクトをリードするまで
私はここ数年、SUZURIのデザインシステム及びコンポーネントライブラリである、Nachiguroの開発を行ってきました。
Nachiguroについては昨年こちらの記事にまとめています。
その傍ら、デザイン部から上記のコンセプト、共通基盤デザインシステム「Inhouse」の開発が発表され、社内の各サービスのデザインシステムの開発リソースをできるだけ一元的に集約して、効率化及びブラッシュアップしていくことが示されました。
そこで、社内でいち早くNachiguroにおいて、Figmaのコンポーネントライブラリの設計を行っていた私はその知見を生かすことができると考え、InhouseのFigmaコンポーネントライブラリ作成に取りかかりました。
またNachiguroで、Reactコンポーネントの開発や、Flutterでのモバイルアプリのコンポーネント開発を行っていたため、InhouseのWebフロントエンドの開発にも積極的に参加していきました。
その結果、気づけばプロジェクトそのものをリードすることになり、現在に至ります。
リードすることになってから感じた課題
Inhouseは上記コンセプトのとおり、あらゆるサービスに使われることが重要です。その点でまず私がこのInhouseプロジェクトのリードを任されてから感じた課題は2つです。
- 実際のサービスのメンバーの積極的な参加を促せていない
- 開発スピードが遅い
Inhouseを使うサービス側の当事者意識が低いとメンテナンスもされにくいですし、やらされている感が強くなってしまいます。また、開発スピードが遅いと、いつまでも実装されず、各サービスが各々デザインシステムを構築しなければいけません。
上記2つの課題のボトルネックになっているのはガイドライン策定や開発をInhouseのコアメンバーのみで行っていたことと、明確なロードマップが示されていなかったことでした。
そこで、Inhouseプロジェクトチームでは今年、以下の目標を立て、具体的なアクションを行いました。
- バックログにあるガイドラインのステータスがすべて「確定」になっている
- ガイドラインのうち66%のWebコンポーネントライブラリが実装されている
- 主要なサービスのソースコードにWebコンポーネントライブラリがインストールされている
具体的なアクション
上記の目標をもとに行った具体的なアクションは以下の通りです。
1. 参加しやすい仕組みをつくる
これまで、きちんと外部に公開できるようなガイドラインの決定をコアメンバーが週一回の定例で草案を持ってきて決めていました。
しかし、これでは参加のハードルが高いため、精緻化していなくてもよい、ある程度ゆるめのガイドラインの作成を当面の目標としました。
まず、各サービスからクリティカルパス（申し込みや購入などで辿る経路）に必要不可欠な機能要件やコンポーネントをヒアリングしました。
そこから、バックログを作成して、特に声が多かったものから順番に優先順位づけを行い、下期中に作成するガイドラインリストアップしました。
リストアップされたガイドラインのバックログ
このバックログが上記の、
バックログにあるガイドラインのステータスがすべて「確定」になっている
のバックログです。
さらに、Notion上にガイドラインのデータベース及びテンプレートを作成しました。これにより、ガイドラインの書きやすさが向上し、現在のステータスと担当者を可視化することができました。
ステータスと現在の担当者を可視化したガイドライン
ガイドラインのテンプレート
そして、各サービスの施策が行われる際に、上記でリストアップしたガイドラインの執筆に関係しそうな機能やコンポーネントの設計をデザイナーが行っているのを観測したらすかさず声をかけて担当者としてアサインしていきました。
担当デザイナーが作成したガイドラインの草案を元に、レビュー会でCDOやシニアデザイナーを中心としたInhouseコアメンバーでレビューしています。
このレビュー会では上記の通り、ある程度ゆるくやることを大事にし、仕様や名前付けなどの根幹に関するレビューは行うものの、ガイドラインの文章そのものに関するレビューは行いません。
その結果、シニアデザイナーだけではなく、ジュニアデザイナーを含むより多くのメンバーがInhouseプロジェクトに参加することができました。作業を分担でき、スピードが出ただけではなく、ジュニアデザイナーのデザインシステムに対する解像度が上がり、デザイナー全体の成長も促せたのではないかと考えています。
また、ゆるめでもいいのでスピード感を持ってガイドラインが整備された結果どうなったかというと、名前付けや仕様が細かく記されているため実装コストが著しく下がりました。
これは
上記ガイドラインのうち66%のWebコンポーネントが実装されている
の目標達成にも寄与しています。
2. サービスに導入しやすくする
主要なサービスのソースコードにWebコンポーネントライブラリがインストールされている
を目標に据えたものの、実際にインストールするには10年続くようなレガシーなサービスも多く、開発環境上の問題が立ちはだかりました。
デザイン部に所属するエンジニアがその問題を解決すべく動いていますが、全サービスにインストールするには当然時間がかかります。
また、ガイドライン上は存在するものの、Inhouse側の実装が追いついていないコンポーネントはそもそもライブラリに存在しないのでインストールすることができません。
そこで、「Inhouseのコンポーネントライブラリがインストールされていなければ、Inhouseを使うことはできない」という思い込みを捨てることにしました。
実際に何を行ったかというと、社内のデザイナー全員が集まるイベントで、上記で定義したゆるめのガイドラインを示して「Inhouseのガイドラインを使って、コンポーネントをサービス側でどんどん実装して行きましょう」と提案しました。
サービス側で実装したものがうまくワークして安定すれば、それを将来的にInhouseにバックポートできます。そうすれば他のサービスがそのコンポーネントの実装の恩恵に預かることができて大変お得です。
また、共通のガイドラインをもとにして実装すればインターフェースが揃うためサービス側の開発環境が新しくなってInhouse側からインストールすることになっても、マークアップの変更などのコストも最小限で済みます。
さらに、上記は主にWebコンポーネントの話でしたが、Figmaでプロトタイプを作るためのコンポーネントライブラリの各サービスの整備コストが高く導入しづらいという側面もありました。
そこで、Inhouseのプロジェクトで一元管理されているFigmaのコンポーネントライブラリを複製し、Local Styleを各サービスが用意した設定ファイルを用いて差し替えればそのサービスのコンポーネントライブラリをすぐに作成できるFigmaプラグインを開発しました。
今後やっていきたいこと
1. Webコンポーネントライブラリの開発者を増やす
現在上記の施策によりガイドライン執筆者は増えましたが、実装を行うメンバーは依然として限られているため、より開発者を増やしていきたいです。そのために実装のガイドラインやAPIドキュメントの拡充を進めていきたいと考えています。
2. Pepabo Design のアップデート
ペパボには大切にしている3つのことの1つとして、「アウトプットすること」があります。そして、ペパボのデザインに関する取り組みをアウトプットする、Pepabo Designというサイトがあります。ゆるいガイドライン施策で執筆の敷居は下がったものの、精緻化できておらず、まだ外部にはこの知見を共有できていない状態です。早く外向きに公開できる状態にし、より多くのデザイナーのみなさんとこのPepabo Designのトピックを通してデザインシステムに関する意見交換をしたいと考えています。
3. モバイルアプリへの対応
現在Inhouseの開発はWebのコンポーネントを中心に進めていますが、ペパボではもちろんモバイルアプリも各サービスで開発しています。モバイルアプリでInhouseの各種Flavorを扱いやすいような何かをモバイルアプリのエンジニアと協力して考えています。
