先日開催された「半熟デザインシステム vol.1」に、note社から登壇させていただきました。たくさんの方にご参加していただけて、とてもありがたかったです！オフライン開催ならではの、リアルな取り組みや悩みについてディスカッションできて、登壇しながらもとても勉強になりました。

今回はそのなかでお話しした、noteのデザインシステムの取り組みについて、内容を振り返りつつ、補足できるポイントも合わせてのまとめです。

イベント全体がまとまったレポートは、こちらの記事に書いていただいています👇🏻

デザインシステムを始めたきっかけとチームビルディング

noteでデザインシステムを始めたきっかけは、事業とサービスのスタートから年月が経ち、技術的・デザイン的な負債がたまって、開発にとってつらいポイントが増えてきたこと。デザインの一貫性のなさや、コードベースの複雑さと肥大化などが大きく課題になっていました。それに、マークアップやスタイリングを担当していたデザイナーの退職もあり、エンジニアがコーディングしやすい環境やツールが必要になりました。

現在は、ぼく（@uto-usui）が専任でUXエンジニアとして実装やデザインの相談事を、業務委託のデザイナーが専任でFigmaコンポーネントの整備を、CDOやオブザーバーのメンバーにサポートいただきながら活動しています。

はじまりは、ブランドコミュニケーションやイラストレーターなど、いろいろなメンバーが参加して、デザインシステムをどのような位置付けにするか、原則をはじめ、どのような成果物を作るかを話し合うところからスタートしました。

デザインシステム開発においては、成果物だけでなく、ベストプラクティスの共有であったり、あるべきデザインの議論などに意味や価値がありますが、これをプロダクト開発へフィードバックしていくことが課題になります。

noteのデザインシステムチームでは、週に30分、だれでも出入り自由な雑談タイムを設けて、幅広く質問や相談に答えられるコミュニケーションを取れるようにしています。

その成果として、雑談タイム以外でも、プロダクトのデザインレビューや、チームメンバー以外がコンポーネント開発に貢献してくれるなど、slackのチャンネルも活発になり、コミュニケーションも増え、デザインシステムのプロジェクトを身近に感じてもらえるようになりました。このあたりはみんなの協力あってのものなので、ほんとに感謝しています◎

逆に、プロダクトから生まれてくるものをキャッチアップすることも重要です。プロダクトデザイナーの定例に参加して、こちらの成果物の共有をしつつ、あたらしい画面やカイゼンの進捗と成果を教えてもらっています。プロダクトのあたらしいUIは、コンポーネントライブラリのFimga「赤ちゃんUI」ページに、まとめてためておくようにしています。ここからコンポーネントに抽出したり、プロダクト側のリファクタに繋げたりしています。

また、noteのプロダクト開発チームにはマスターデータはありません。ひとつのFigmaファイルでデザイナーは作業をしてそれぞれの成果物を集約しています。一定期間（現在は半期ごと）で新調して、古いものはアーカイブする運用にしています。

デザインシステムの熟し具合

デザインシステムのはじめの目的はnote.comのプロダクト開発の生産性をサポートしたり、ブランドの一貫性やユーザビリティを最大化したりすることが目的でした。

今期からはnoteのめざす方向性が広がって、デザインシステムに求められる領域も、おのずと拡がることになりました。具体的にはnote.comのドメイン領域から切り離せるような状態が必要になり、サービスを超えて取り回せるデザインシステムを再構築しているところです。

そのためにデザイナーみんなでオフラインワークショップを行って「noteらしさ」「note.comらしさ」を、定義・再確認することになりました。このあたりはそれぞれの年次や取り組んでいる内容によって、印象や考えている角度が微妙に違っていて、色々な発見がありました。ここで得た意見をもとにnote.comのドメイン知識を引き算して、noteらしさをデザインシステムに反映していきます。

コンポーネント群はnote UIとUI Kitというライブラリを定義していて、UI KitはUIパターンとしても機能する、ドメイン知識を前提としたnote.com専用のコンポーネント、note UIは汎用コンポーネント集になっています。この2つに役割を切り分けて開発を進めています。デザイントークンに関しても、同じように2段構えのつくりになっています。

コンポーネントライブラリの実装はStorybook、デザインはFigmaでカタログ化していますが、実装とデザインを深く結びつけると、お互いに使いづらくなることがわかってきました。トークンやコンポーネント名は揃えて、variantsなどの細かいオプションはそれぞれが管理しやすいよう、実装は細やかな粒度や命名で管理、Figmaはデザイナーの使い勝手やわかりやすさを優先するようにしています。

またこれからの試作で言うと、FigmaのModes for variablesを使い、webとアプリのコンポーネントを一元管理・参照して統合できないか検討中です。すでにデザイントークンに関してはプラットフォーム間で共有していますが、コンポーネントもリソースをひとつにできるとさらに開発効率を高められそうだと思っています。

組織や他チームへの説明の仕方、予算の取り方

デザインシステムはnoteにおいて必要不可欠なものとして認識されています。たとえば、noteのプロダクトは長年運用されてきて、技術負債を解消するため別のフレームワークへの移行や、それにともなうコンポーネント開発が急務でした。こういった課題に対してダイレクトにデザインシステムが貢献することを期待されています。

チームとしてはこの必要条件を満たしながら、同時にアクセシビリティ向上やデザインナレッジの充実など、プロダクトのクオリティの底上げや品質向上、開発チーム全体の生産性に寄与したいと考えています。

また、過去のイベント登壇がきっかけで、インターンメンバーの採用につながることもあり、人材の獲得にも繋がっています。逆にチームメンバーの退職があったさいも、あたらしいメンバーをアサインしていて、2年半以上この体制を維持して開発を続けていて、CDOをはじめ、プロダクトチームの理解や協力で、活動を後押ししてもらっています。

デザインシステムチームの存在意義は無くならないと思う（願う）んですが、一方で、成果の測り方は課題になっています。定量的な評価が難しい領域で、開発者それぞれからのフィードバックを集めるくらいしかできないのが現状なのかなと。以前は、「生産性向上」とわかりやすいキーワードをデザインシステムチームの目標に設定して、タスク管理にそのチェックマークを付けたり。わかりやすく成果を俯瞰しやすいようにくふうしていた時期もありました。

まとめと今後の展望

ということで、noteのデザインシステムチームが取り組んできた内容について、各テーマでお話ししたことをピックアップして振り返りました。

イベントに参加していただいた方から、「いい感じに見えるデザインシステムも、各社が苦労や複雑な状況の中で成り立たせていて、まだまだ成長途中なんだって分かって励みになった」というような感想をお見かけしました。

デザインシステムは事業の成長と共に走りつづけてけいくもので、開発や運用の方針や役割は常に変化しつづけていくなあ、というのが正直な当事者の感想です。デザインシステムが解決する課題の変化に対応できるよう、次の目標に向かって持続できる環境・体力作りが大切かなと考えています。

プロダクトの状況により開発は変化してきましたが、ぼくは現在地がいちばん楽しいという実感があり、ますます頑張っていくぞーという気持ちです。またこうやって発信させていただいたり、なにかのかたちでお会いしたり、また、他社さんのそういった話も楽しみにしつつ、デザインシステムを育て（熟し）ていきたいです🍳

それではまたデザインシステムな夜にお会いしましょう！
ありがとうございました◎

おわります。