こんにちは！デザインエンジニアの藤井（touyou）です。
みなさんはSparkle Designという弊社のデザインシステムをご存知でしょうか？「デザインシステムのデザインシステム」というコンセプトで昨年公開されたもので、今年に入ってガイドラインサイトとReactのコンポーネントライブラリを追加で公開しています。
自分はチームのエンジニアとしてFigmaプラグインやReactコンポーネントの実装に主に携わっており、今までにも次のような記事を公開していました。
これらの記事を見るとわかるように、ReactのコンポーネントライブラリをOSSとして公開するまでの自分の役割としては、自分の技術力を用いてデザインシステムのデザインシステムとしてSparkle Designが成り立つような要素を作っていく、という面が強かったと思います。
ですが、この役割は実は少しずつ着実に変化していきました。
その一端はこちらの記事にも表れているのですが、今回はさらに一歩進んだところも含めていかにしてチームのみんなをGo Beyondさせたのか、というところについて話していければと思います。
ケース1. ガイドラインサイトの実装
まずは先ほど紹介させていただいたガイドラインサイトの実装についてです。
こちらはUIデザイナー二人が実装を主導することになったプロジェクトで、自分はそのサポートとして入りました。時期的には去年の12月ごろからスタートしています。
このプロジェクトではまず自分は技術選定とそのセットアップを行いました。
バイブコーディングで進めていくこと自体は決まっていたので、その時点で、Sparkle Designを組み込んだり、AI向けのガイド（CLAUDE.mdなど）の整備をまず行いました。
そして二人にはGitHubでの開発フローをインプットし、そこから先はAIと対話してもらうといった形で進めていきました。
結果として、最終的には今のガイドラインサイトがあるわけですが、やはりどうしてもレビュー観点は多かったです。この段階ではその度にガイドを調整しつつ、基本はレビューで直してもらいました。ただその往復が微妙なときはこちらで巻き取ってしまうといった動きも多く、正直レビューの往復回数の多さがそのままボトルネックになっている感覚がありました。
途中からはレビュー負荷が高くなってきたためCopilotのレビューを活用してもらい、自分は動作確認に徹しました。この判断はわりとよかったです。最低限のコード品質はCopilotに保証してもらうことで、自分は「動いているか」「体験として気になるか」という観点にすぐ集中できるようになり、レビュー待ちで手が止まる場面は明らかに減りました。
最後は自分が全体チェックをかけたりしていましたが、かくして約5〜6ヶ月でガイドラインサイトを無事公開することができました。
ケース2. コンポーネントの実装
さてガイドラインサイトとReactコンポーネントのOSS化はすみましたが、実はその時点では社内のメンバーに使ってもらうにも少し課題がありました。
何かというとFigma側やガイドラインサイトでは現状45個のコンポーネントが公開されているわけですが、Reactコンポーネントは内部的に使うものを引くと26個、つまり19個のReact実装はなかったわけです。
公開版を絞っていたのは意図的なのですが、社内メンバーに使ってもらうにあたって残りの実装がないというのは少し不便でした。そこで社内用のリポジトリを別途プライベートで作りそちらにコンポーネントを拡充するという形式を取ることにしました。
このタスクもUIデザイナーが実装を主導する形で行いました。
今度のタスクはガイドラインサイトより小さく見えて、かなりルールがありました。できれば公開版にすぐ移せる状態で作っておきたいですし、そのためにはshadcn/ui registry、Figma Code Connect、Storybookのコメントの書き方などOSSとしてのクオリティを上げるために行っていたあらゆる工夫に従ってもらわないといけません。
そこで今回はFigma、ガイドラインの情報、元々公開版開発時に作っていたscaffoldスクリプトをもとにコンポーネント実装ができるスキルを用意しました。さらにこれとセットでレビュー用のスキルも用意しました。
そのスキルを制作しつつ、そのベースとして自分でも一個コンポーネントを作り、そこから調整をしていった形になります。基本はそこからデザイナーがスキルベースで制作してもらいつつ、自分も積極的にレビューに入り、気になるところは積極的にスキルに反映していってガードレール自体をブラッシュアップしていった形になります。
もちろんどうしても初稿のムラはありました。たとえば"use client"の付け忘れでビルドが壊れかけたり、フォーカスリングを背景色の変化だけで済ませてしまっていたりと、最初はスキルに書ききれていなかった観点から粗が出て、そのたびに気づいた点をスキルに書き足していく、という地道な繰り返しでした。ただ中には一発で自分の考えていた理想状態で出てきたものもあり、関わったUIデザイナーや自分含めてコンポーネントとしてのクオリティに集中できたのは大きかったです。
結果的に5人のUIデザイナーが実装主担当になって19個のコンポーネントを約1ヶ月で完成させることができました。その間コンポーネント実装だけでなくSparkle Designのデザイン面でのタスクや案件をこなしながらだったので、本業エンジニアではないことを踏まえなくとも驚異的なスピードです。
つまり何をしたのか？
これらの動きの中で自分は何をしたのかというと、ひたすらにスキル・AIドキュメントを磨く、つまりハーネスを強化し続ける役割に徹していたということになります。
もちろん自分で手を動かした面もありますが、それもハーネスを強化するためで、大きく変えたあとはこれを再現できるようにルール化してハーネスに還元することを常に行っていたと思います。
ただそれで大きく自分の工数を使ったということでもなく、レビュー含め徐々にAIに委託していくことでスピードとクオリティの両方を追い求めていきました。これは自分が楽をできるというだけでなく、自分が気にしている観点をAIが判断できるようにするということなので結果的にこれもハーネスの強化に繋がりました。
まとめ
今回はSparkle Designの2ケースを通して、自分がやってきたことをざっとですがご紹介してきました。
世の中のモデル性能やAIツールはその過程の中でどんどんと移り変わっていきましたが、他の専門性を持った人たちをGo Beyondさせるというコツは一貫して泥臭くハーネスを調整していくことだと思っています。
理解していない人にハーネスだけを渡してももちろんなかなか機能しないわけですが、そこを育てるところに自分の目を光らせる。それだけでなく、その目すらどんどんとハーネスに取り込んでいく。
今のところはこれこそがハーネスエンジニアリングなのかなと思っています。
ぜひみなさんも自分の専門性を移譲する新しい働き方を一緒に切り拓いていきましょう！
Goodpatchではデザイン好きなエンジニアの仲間を募集しています。 少しでもご興味を持たれた方は、ぜひ一度カジュアルにお話ししましょう！
