最近は週休5日のフリーランスとして、知り合いベースで、プロダクト立ち上げのお手伝いや顧問的なお仕事をしつつ、趣味仕事としてクラフトビネガードリンクを作ったり、家にサウナを作ったり、Web3プロジェクトに関わったりしています。

その中の一つとして、古巣クックパッドの「クックパッドPC版 デザイン改修プロジェクト」にデザインエンジニアとして参加しました。
PC版が大規模に改修されるのは実に7年ぶり。それ相応にデザイン負債も溜まっており、その返却が主題となるプロジェクトです。

このnoteは3部作のエンジニアリング編であり、プロジェクトの概要についてはPM 倉光さんが、デザインについてはデザイナー 市原さんが書いていますので、あわせてどうぞ。

エンジニア視点でみるデザイン負債

今回のプロジェクトでやったことは「表現のアップデート」です。あくまでデザインの一貫性向上や、レガシーな印象を払拭することを目的としており、プロダクトの使い勝手や体験について大きな変更はしていません。

このBefore/Afterだけを見ると、「CSSちょっと変えたらシュッといけそう…？🤔」とも思えそうです。ただ、長い年月をかけ、複雑に絡み合い、何層にも積み重なったCSS群を有する大規模サービスではそうもいきません。

それは言い換えると、長年の歴史によって「表層と構造が密結合」している状態です。この状態では「表現だけをシュッとアップデートする」のは難しく、まずは密結合を適切に剥がすことが必要になります。

それがエンジニアリング観点でのデザインシステムの役割の一つであり、今回のプロジェクトでいえばデザインシステム「Apron」の導入です。

ここからは「なぜ表層と構造が密結合してしまったのか？」について歴史から考察し、そこからデザインシステムの役割について考えてみます。
なお、便宜上「負債」と表現していますが、事象として捉えているだけであり、そこにネガティブな気持ちは一切ありません。

クックパッドを10年支えるデザインシステム

クックパッドPC版は現在のコードベースであるRuby on Railsに移行してから、約15年が経過している歴史あるサービスです。世界最大のモノリシックなRailsアプリケーションであり、そのリポジトリは「cookpad_all」と呼ばれています。

そのcookpad_allには、まだその言葉自体が一般的でなかった10年近く前からデザインシステムが存在していました。それがCSSフレームワーク「Sara」です。

Saraは今でいうユーティリティファーストのような思想であり、「エンジニアがクックパッドっぽいUIをすぐ作れる」ことに重きをおいて設計されていました。
ノンデザイナーがUIデザインするために、素材とパーツを提供するDIY型デザインシステムといえます。ざっとこんな特徴がありました。
（なお、Sara立ち上げには関わっていないため、Saraのコードや使われ方を見た上での推察となります）

今でこそ多くのデザイナーが活躍するクックパッドですが、当時はほんの数名しか居なかったという組織事情もあり、このような設計になったのではないかと推察します。その設計思想はハマり、当時は多くの新規サービスがcookpad_all上で開発されていたこともあり、Saraは活発に利用されていきました。

2018年には主にCI/BIをスコープにしたデザインシステム「Citrus」が誕生しましたが、cookpad_allではSaraが引き続き現役を続け、誕生から10年経った現在に至ります。

フェーズと役割の変化

この10年の間にクックパッドのサービス開発は、PCからモバイルに主戦場を移していきました。事業的にも「レシピサービスのクックパッド」だけでなく、多くの事業・ブランドが立ち上がりました。そして組織も移り変わり、デザイナーの数も増え、デザイン基盤チームが作られました。

そんななか10年選手となったSaraは、その役割とクックパッドのフェーズとが徐々に噛み合わなくなったことで、次のようなデザイン負債をはらむようになりました。

これらが冒頭に触れた「表層と構造の密結合」の正体であり、エンジニアリング観点でみた今回プロジェクトは、いかにこれらと折り合いをつけつつ、Apronに徐々に代替わりさせるのかが考えどころでした。

総じてSaraはサービス拡大フェーズにおいて、セルフサービス型で開発速度を上げるためのデザインシステムだったと言えます。対して、クックパッドPC版が円熟期となった現在、新しいデザインシステム「Apron」に求められるのはどんな役割でしょうか。

デザイン強度を上げつつ、取り除きやすい

エンジニアリング観点でみたSaraとApronの大きな違いは、Apronは原則ユーティリティクラスや抽象コンポーネントを提供せず、単体でUIとして機能する具体度の高いコンポーネントのみを提供していることです。

またSaraとは違って、サービス開発者にコンポーネントの拡張はさせず、そのままアプリケーション内で使うことを想定しています。これによってデザインの一貫性や強度を担保しつつ、いつかApronがデザイン負債化したときにも、取り除きやすくなります。

またApronが提供するコンポーネントやデザイントークン (カラー変数など) の名前には全てプレフィックス (.apr-buttonなど) をつけ、grepし易さにも気を使っています。地味ですが、大規模サイトにおいてgrepしやすさは取り除きやすさに直結します。

トレードオフとして、この「コンポーネントを拡張させない」アプローチは、デザイナーにデザインする時点でApronの活用を考慮することを求めます。そうでないとエンジニアがApronを使って実装することが難しく、デザインシステムの価値が発揮できません。
そしてなにより、Apron自身にも提供コンポーネントの質と量が求められます。そこで重要となるのが、デザインシステムのメンテナーとなるデザイン基盤チーム (デザイン推進部) の存在です。

総じて、Saraは開発速度を求めたセルフサービスなデザインシステムでしたが、Apronはデザイン強度を求めたメンテナー介在型のデザインシステムといえます。
Figma Schemaなどデザインシステム系のカンファレンスを見ると同様の事例は多く、また発表自体にも組織論が多いのはメンテナーの重要性を表していると言えます。

開発速度を求めたデザインシステム、デザイン強度を求めたデザインシステム、どちらにも正解・不正解はなく、対象となる組織・サービスのフェーズ次第です。

ただ共通して言えるのは、すべてのデザインシステムはいつかは負債になる、ということです。特に円熟期を迎えた組織・サービスにおいてデザインシステムを導入する際には、将来の取り除きやすさを考えてみるのも大事そうです。

レガシーCSSと向き合う

ここまでは概念的な話でしたが、実際の開発としてはひたすら地道な作業が続きます🛠

10年モノのCSSを一気に改善するのは現実的でなく、一歩一歩着実に進めていく必要がありました。いずれもCSSという技術の特性上、年月のたった大規模サービスでは共通した話なのではないかなと思います。

cookpad_allの事情を多分に含むのでさらっと書きましたが、どれも地味ながらなかなか大変😇 歴史的経緯がチョットワカルOBとして、ときにエスパーしながら、地道に進めました。

結果として、目安に取っておいたLightHouseのスコアにも改善が見られたようでなによりです。
特に、デッドコード削減やリファクタリング、アクセシビリティ対応などは、大規模サービスだからこそインパクトも大きかったようです。

おわり

今回は元社員がフリーランスとして、デザイン負債の返却に取り組む、というちょっと変わった構図のプロジェクトでした。

新卒時代に慣れ親しんできた「Sara」、立ち上げに関わった「Citrus」、そして新たなデザインシステムの「Apron」と、デザインシステムの変遷を目の当たりにしてその分かりが少し深まった気がします。

僕はこのプロジェクト限りでクックパッドをまた離れてしまったのですが、10年にわたって複数のデザインシステムを運用してきている会社もなかなか無いと思うので、ぜひ興味あるかたは市原さん (@ichinii3) にコンタクトしてみてください！👋