「デザインシステムの理想って何だっけ？」　”考える会”で比較してわかったREADYFORに足りない部分

リニューアル時にREADYFOR Elementsをしっかり作成　おかげで開発効率はアップ

大房稜氏：「READYFORのデザインシステムの課題あれこれ」というタイトルで発表します。よろしくお願いします。

まずは自己紹介です。大房稜と申します。TwitterはこのようなIDで、好きなものはReact、HTML、UIデザインで、アクセシビリティおじさんとして勉強中の身です。超重要情報なのですが、初登壇です。よろしくお願いします。

本日のアジェンダです。まず1つ目はREADYFORのデザインシステムです。本日の発表でもデザインシステムの話がいろいろとあったと思いますが、運用を開始してからどんな感じだったのかを話します。2つ目は、デザインシステムの会の発足をしたという話。3つ目はREADYFORのデザインシステムの理想像を定義した話です。4つ目はUIコンポーネント集、READYFOR Elementsですね。運用面での改善の取り組みと、今後の計画についてお話しします。

1つ目の話です。READYFORのデザインシステムの運用が開始されました。2019年の10月にブランド兼ページのUIデザインのリニューアルが実施されて、右の画像のように現在のREADYFORのデザインになりました。

そこからほかのドメインでの新規開発が開始されました。プロジェクト実行者の管理画面や決済フォームのページのリニューアルが開始されました。

READYFOR Elementsを最初にしっかり作成していたので、新規開発ですぐデリバリーができて、開発効率はメチャクチャアップした感じでした。

横断的にREADYFOR ElementsというUIコンポーネント集が利用されていき、広く利用されたからこその課題が見えてきたので、適宜READYFOR Elementsを開発に合わせてFEチームでアップデートしていったり、デザイナーさんとの認識を合わせて別のドメインの開発を進めていったりしました。

ただ、アップデートしていく中で、デザイナーさんとFE全員の間で共有する場を設けていませんでした。そこで、いろいろと細かい困りごとや、今後READYFOR Elementsを含めて、READYFOR全体のデザインシステムの中長期計画をどのように立てようかということで、課題整理と計画のために「デザインシステムを考える会」を2020年の7月頃に発足をしました。

まずはデザインシステムの理想を定義した

次にデザインシステムの会の発足についてお話しします。ここでは、デザイナーとFEメンバー、PMの全員を巻き込んで、現状の困っていることを共有しました。具体的にFEメンバーからは、FEチーム内でのバックログが溜まっていて、相談コストがかかってしまう、というものがありました。ほかにも、コンポーネントの使われ方についてのまとまったドキュメンテーションがないというものもありました。あとは、どういうフローで新規コンポーネントを作成・改善していくかというフローの制定がないので、そういうのがあるといいよねという話もありました。

デザインシステムの現状の課題を更新・アップデートしていく中で、「そもそもREADYFORとしてのデザインシステムの理想って何だっけ？」という意見がありました。当時は「そもそもデザインシステムって何をもってデザインシステムなんだろう？」というのが開発チーム全体に共有がされていなかったので、まずはデザインシステムの定義を最初に決めて、現状と比較して、READYFORに足りない部分を補完していければという方針で、取り組みました。

まずはデザインシステムの理想像の定義をしました。右側の画像の『Design Systems ―デジタルプロダクトのためのデザインシステム実践ガイド』という書籍ですね。これを参考に、デザインシステムであるというもの、デザインシステムで足り得る要素というものを、全員で議論して言語化して、READYFORの足りていない部分は何なのかを洗い出しました。結果、デザイン原則の要素と、ドキュメンテーションの部分が足りていないので、優先度を上げて取り組んでいこうと判断しました。

これは「デザインシステムとは？」というテーマで、ユーザーに一貫したプロダクト体験を届けるためのデザイン指針・見た目・ルールなどの共通言語をまとめた社内資料です。

デザインシステムの中にあるデザイン原則やスタイルガイド、コンポーネントライブラリ、ドキュメンテーションや運用のルールを決めて、チーム内で共有をしました。

READYFOR Elementsの運用面改善のための取り組み

次にREADYFOR Elementsの運用面での取り組みです。現状で困っていることをすぐ解決したいということで、READYFOR Elementsの運用面での改善に取り組みました。

まずやったことは、FEチーム内で困りごとをヒアリングしてブレストしました。例えば、スタイルガイドで気になる部分を洗い出してみて、そこで出たものをElements用の課題管理シートに積んで、コストの低いものはFEチーム内で定期的に開かれるもくもく会で、個人ベースで解消しています。

他にも、当時はデザイナーさんからフロントエンドエンジニアへ実装を依頼する前のチェックリストがなかったので、それを作成しました。

こんな感じですね。よくあるものだとは思うのですが、クリッカブル範囲が明確だよとか、ボタンのhover・active・visitedなどのデザインが用意してあるよとか、そういったものです。

運用面の取り組みとしてもう1つ、コンポーネントの仕様の明文化をしました。READYFORのページのデザインはFigmaで作成しているんですが、それとREADYFOR Elementsとの間でデザインの差異が起きていました。

プルリクエストベースでレビューしてもらって、「このようにデザイナーさんと確認して更新しました」となったときに、FEチームの別のメンバーから「ほかのドメインだとこういう仕様でもともと開発していたけれど、どっちが正しい仕様なんですか？」という指摘があり、まれに議論が起きていました。

そこで、Storybook内にドキュメンテーションと実装をまとめて確認できたら便利ということで、その方針に決定して、取り組みました。

このときは、ドキュメントを書くかどうかは検討中でした。現状のコンポーネントの仕様で起こる「どっちが正？問題」の議論が起きた際には、適宜1つのドキュメントにまとめて、後にStorybookに移植をしていく予定です。

今後予定しているREADYFORの取り組み

今後の計画です。デザインシステムの軸は、当時はまだREADYFORでのデザイン原則の策定がなかったので、先ほどのデザイン原則というのを現在進めている状態です。

デザイン原則は、一言で言うと「プロダクトの目的を実現するためのデザインの行動指針」なので、READYFORでは、「誰もがやりたいことを実現できる世の中」というビジョンと、「想いの乗ったお金の流れを増やす」というミッション、READYFORらしい要素を踏まえて、デザイン原則を明文化していくことを現在取り組んでいます。先ほどの資料のこの部分ですね。「デザイン原則」の部分です。

もう1つのREADYFOR Elementsを軸として、優先度が高いのが、コンポーネントのルールの仕様の明文化です。これは、Storybookのマークダウンと一緒に実装が書ける「MDXフォーマット」というものがあって、それでコンポーネントとドキュメントをまとめる方針で取り組んでいます。

ご存じの方もいると思うのですが、もともとStorybookのアドオンとしてあったaddon-docsがあります。最新のStorybookだと、それが統合されていて、コンポーネントの仕様をまとめて誰でも実装とともに確認できるので、便利です。他にもアクセシビリティがStorybookのアドオンとして入っていて、そこでデザイン面でのアクセシビリティのチェックもできます。

最後にまとめです。デザインシステムを作成・運用してみてよかったことは、最初のリニューアル時に汎用的に作成していたおかげで、ほかのドメインでの開発の効率化はけっこうできていたということです。しっかりと広く使えていたからこそ、いろいろと課題が見えてきたと思っています。

多方面を巻き込んだコミュニケーションの大切さを実感

学びは、現在のREADYFORのようにデザインシステムの専任がいない場合は、ちぐはぐな運用をしてしまうので、まずはデザインシステムの定義やスタイルガイド・UIコンポーネント集以外のドキュメンテーションや運用のルールの要素の部分など定義や運用のルールの方針だけでも優先度を高くガツッと決めたほうがいいということです。

とはいえ、進めていく中で多方面を巻き込んでいくことになるので、コミュニケーションコストがけっこうかかってしまいます。なので、多方面を巻き込んでコツコツでも進めていくことが大事だなと思いました。

デザイン原則とかのデザイン指針の方向性がガツッと決まったので、今後はアクセシビリティの面でもチェックリスト化を進めていきたいと思っています。

本日の発表はこれで終わります。ご清聴ありがとうございました。