こんにちは！株式会社Schoo（以後スクー）新卒2年目の @hiroto_0411 です。エンジニアをしています。

今回の記事では、この半期（約半年間）にわたってリードした「デザインシステムプロジェクト」の振り返りをお届けします。デザインシステム自体の技術的な話だけでなく、プロジェクトをどう設計し、どう進め、どんな壁にぶつかってどう乗り越えたか——プロジェクトリーダーとしての体験談をそのままお伝えできたらと思っています。

この記事で分かること

なぜデザインシステムが今の時代に必要なのか
Schooが抱えていた課題と、プロジェクトを正式に立ち上げるに至った背景
プロジェクトロードマップの設計とこの半期の実際の成果
プロジェクトリーダーとして得たチーム運営の学び

デザインシステムとは

デザインシステムとは、ブランドやコミュニケーションの価値観定義を指針化したデザインプリンシプル、情報アーキテクチャとインタラクションデザインに基づいたコンポーネント定義、アクセシビリティを含んだ規範となるデザインガイドラインといった、デザインアセットの集合体です。

— デジタル庁デザインシステム（DADS）

つまり、ボタンやフォーム、カラーパレットや余白の単位といったUIの構成要素だけでなく、デザインの原則やガイドラインまでを一元管理し、デザイナーとエンジニアの「共通言語」 として機能する仕組みです。誰が実装しても同じ品質のUIが作れる状態を実現するための基盤となるシステムです。

デザインシステムがあるとなぜ嬉しいのか

デザインシステムは「デザイナーとエンジニアのためのもの」と思われがちですが、実はそれだけではありません。その恩恵はプロダクトに関わる全員（あるいは会社全体）に波及します。

デザイナー・エンジニア

デザイナー
- コンポーネントを組み合わせることでUIが作れる。細部のデザインや体験の質に集中できる
エンジニア
- 0からコードを書かずに既存コンポーネントを組み合わせて実装できる。AIを活用したバイブコーディングとの相性も抜群

PM・PdM

PMにとって最大のメリットは、 「プロトタイプ作成の高速化」 です。

プロトタイプ作成の高速化
- 既存のコンポーネントをパズルのように組み合わせるだけで、モックアップが素早く完成する
工数見積もりの精度向上
- ゼロから作るのではなく既存パーツの組み合わせで機能を作れるため、開発コストの予測が立てやすくなる
「何を作るか」に集中できる
- 「ボタンの色はどうするか」といった細かなUIの議論をスキップし、ユーザー体験やビジネスロジックの検討に時間を割ける

マーケティング・ブランディング担当

ブランドの一貫性を守る立場の人にとって、デザインシステムは　「ブランドの番人」 として機能します。

ブランドの信頼性維持
- どの媒体、どのページを見てもフォントや色が統一されていることで、ユーザーに「しっかりとしたサービスである」という安心感を与える
クリエイティブ制作の効率化
- バナーやランディングページ（LP）を作る際も、定義された色やタイポグラフィを流用するだけで、ブランドから逸脱しない制作物が短時間で作れる

ビジネスオーナー・経営層

経営的な視点では、「コストとリスク」 に直結します。

開発コストの削減
- 同じパーツを何度も作り直す「車輪の再発明」がなくなるため、長期的な開発コストが大幅に抑えられる
市場投入スピードの向上
- 新機能のリリースサイクルが早まり、競合に対して優位に立てる
スケーラビリティ
- 組織が拡大し、複数のチームが並行して開発を進めても、プロダクトがバラバラにならない仕組みが手に入る

QA(品質保証)

テスト項目の削減
- コンポーネント単位で品質が担保されていれば、ページごとの細かい表示確認（フォントサイズ・余白など）の負担が減る
アクセシビリティの担保
- システム側でコントラスト比や操作性が考慮されていれば、個別機能での大きな不備を未然に防げる

新規参画メンバー

デザインシステムは 「教科書」 になります。ドキュメントを読めば「このプロダクトのルールや思想」がすべて書かれているため、新メンバーが即戦力化するまでの時間を短縮できる

デザインシステムは単なる「部品集」ではありません。「プロダクトを支える共通基盤」 になるのです。

なぜ「今」必要なのか

デザインシステムの根本的な目的は 「一貫した高品質なユーザー体験の提供」 にあります。どの機能を使っても、どの画面に遷移しても、同じ品質・同じ操作感で使えること。これがユーザーからの信頼につながります。

加えて、バイブコーディングが急速に普及するなか、AIに 「プロダクトの思想にあったデザイン」 を生成させるには、AIが参照できる高品質なコンポーネントの基盤が必要です。デザインシステムは、AIへのインプットとなるコンテキストの1つとしても、今まさに不可欠な存在になってきています。

実はSchooではデザインシステムを作るチームは以前から存在していました。ただ、あくまで「有志」で業務と並行して進める形だったため、どうしても本業が忙しくなるとデザインシステムの優先度は下がりがちで思ったような進捗が出ていない状況でした。

その状況を変えるため、正式なプロジェクトとして、担当メンバーとリソースをしっかり確保した上で推進していく体制へと切り替えることになりました。今回、そのプロジェクトリーダーを担わせていただきました。

実際に公開されているデザインシステムの例

国内外でデザインシステムを外部公開している組織は増えています。

SmartHR Design System: 国内SaaSの代表例。コンポーネント・トーン&マナーまで網羅的に公開
デジタル庁 DADS: 行政サービスのUI統一を目的としたデザインシステム
Material Design（Google）: Googleのプロダクト全体を支えるデザイン言語

こういった外部公開の取り組みは「採用ブランディング」にもなりますし、社外のエンジニア・デザイナーからの信頼獲得にもつながります。

プロジェクト計画と成果

キックオフまでの準備

正式なキックオフの前に、まずデザイナーとエンジニアにそれぞれ1on1などのMTGでヒアリングを行いました。
前からプロジェクトに関わっていたメンバーや部分的に存在していたデザインシステムを利用していたメンバーに、「やりたいこと・実現したいこと」・「課題感・モヤモヤ」 を丁寧に聞いてみることで現状と理想の差を把握してメンバーが実現したい内容と会社がこのプロジェクトに求めているところの共通点を探しました。

ヒアリングは以下のように「エンジニア・デザイナー」、「やりたいこと・実現したいこと」・「課題感・モヤモヤ」の4象限に分けてマッピングして共通点などを探りました。

このヒアリングを通してメンバーの理想と課題が明確になりました。
理想の姿

コーディングの効率化：UI実装に関するエンジニア負担を低減し、デザイナーが細部に拘れる状態
FigmaとコードがリンクしてUI更新フローがシンプルかつ効率的な状態
プロダクトを超え、社内に浸透し、外部にも公開できる状態

繰り返したくないこと

目的・ゴール・ステークホルダー・責任範囲・優先度が不明瞭な状態

ヒアリングの後、少人数で集まり対面ワークを実施しました。
「ありたい姿の明確化」からはじまり、ゴール・マイルストーンの設定、WBSの作成、Jira整備まで一気に行いました。
ここをしっかりと整理したことで、プロジェクトにおいて理想と現実のギャップがどこに発生しているのか？なぜ発生しているか？をある程度知ることができました。

対面ワークで行ったことは以下になります。

AsIs（現状）とToBe（目指す姿）の整理

目指す姿と現状のギャップを把握しどこに問題があるか特定する

先程整理した内容をもとに、さらに会社の目指したい姿とも重ねてもう一度整理しました。

ここで意識したのは、「プロジェクトが成功した状態」を具体的に言葉にすることでした。デザインシステムのプロジェクトは、完成の定義が曖昧になりやすく、ゴールが霞んだまま進んでしまいがちです。そこで「今どういう状態か（AsIs）」と「プロジェクトが成功したときにどうなっているか（ToBe）」を対比で整理し、チーム全員が同じゴールイメージを持てるようにしました。

	AsIs（今の状態）	ToBe（プロジェクト成功の定義）
実装フロー	デザイナーはUIデータを作るまで、エンジニアはそれを見て一から実装している	AIを活用しながら実装でき、職能問わず共通コンポーネントを使って高品質なUIを素早く作れる
UI一貫性	各プロダクトのページで新旧デザインが混在しており、UIの一貫性がない	すべてのプロダクトで最新の共通コンポーネントが使われ、Schooブランドの統一感がある
コンポーネント管理	サービス間で変数名やコンポーネントの単位がバラついている	命名ルールが統一され、プロダクトをまたいでも同じ言葉で話せる
AI活用	AIを実際の開発フローに導入できていない	実際のコードを参照しながらバイブコーディングができる（職能問わず）

このプロジェクトの目的を定義

ヒアリングとその結果の分析を通じて、このプロジェクトの目的を次のように定義しました。

デザイナーとエンジニアの「共通言語」を作り、一貫した高品質なユーザー体験を提供する

具体的には、以下の状態を実現することを目指しています。

担当者のスキルや社歴によらず、誰もが一定以上の品質とスピードで実装できる
schoo.jp全体でUIの一貫性があり、どの画面でも同じ品質・操作感で使える
UI/UXやブランディングへの意識がデザイナー以外にも広まっている
「Schooらしさ」がプロダクトや組織全体に浸透している

ゴールのフェーズ分け

フェーズ分けで意識したのは、「今期の終わりに何が完了していれば成功か」を明確にすることでした。デザインシステムはスコープが広く、すべてを一度にやろうとするとやるべきことがぼんやりとしてしまいます。フェーズを区切ることで、今期に集中すべき範囲が絞れ、メンバーが「自分が今やるべきこと」に迷わず動ける状態を作れます。また、フェーズを超えるたびに成果を確認できるため、プロジェクトのモチベーション維持にも効果的でした。

「一気に完成させる」より「段階的に価値を積み上げる」ことを意識し、プロジェクトのゴールを 3フェーズ に分けて設計しました。

フェーズ	時期	ゴール
Ph.1 種まき期	今期（この半期）	Figmaにコンポーネント一覧が揃い、ライブラリ選定・開発環境整備が完了し、実装のベースが完備されている
Ph.2 実装期	来期〜再来期	コンポーネントライブラリとFigmaが同期し、Schoo.jpの全サービスがデザインシステムに紐づいている
Ph.3 開発サイクル革命期	それ以降	職能問わずバイブコーディングでフロント実装ができ、デザインシステムを外部公開できる状態

フェーズごとのタスク分割

各フェーズで完了させるタスクを事前に洗い出し、メンバーのアサインと責任範囲を明確にしました。特に今期行うタスクはある程度詳細に分割し、それをそのままタスクとして実行できる粒度に分割しました。来期以降は組織の状態やプロジェクトの進行具合によって変わるため細かくは分割しませんが、ある程度の目安は作成しました。

ex. )
Ph.1 種まき期の主要タスク

汎用コンポーネントの策定・Component化（利用者側Web/App、管理ツール）
コンポーネント・デザイントークンの命名ルール策定
コンポーネントライブラリの技術選定・ディレクトリ構成検討
ライブラリ開発環境整備（モノレポ管理ツール導入）
アクセシビリティチェック（デザイン面・開発面）
各チームのFEスタックヒアリング
Code Connectを使ったFigma-コード連携の検討

Ph.2 実装期の主要タスク

Figma→コンポーネントライブラリのフロー整備・自動化
コンポーネントライブラリの完成
Schoo.jpの全プロダクトへのライブラリ接続

Ph.3 開発サイクル革命期の主要タスク

バイブコーディング向けオンボーディングドキュメント整備
外部公開に向けたドキュメント・ガイドライン整備

結果

この半期の主要成果

Ph.1「種まき期」として設定したゴールをほぼ達成し、Ph.2に向けた土台が整いました。

Figmaのコンポーネント一覧が作成された
開発基盤が整った
コンポーネント・デザイントークンの命名ルールが明確になった
アクセシビリティの方針が明確になった
Code Connectをはじめとした、Figmaの各種機能の利用方針が明確になった

この半期は私が思っている以上に順調に進み、細かな問題は発生したものの大きな問題は発生せずに、当初の目標を達成できました。メンバーの皆さんに心から感謝しています。
振り返ってみると「成功した要因」があったかなと思うのでその分析をしたいと思います。また、振り返っていく中で、成功したプロジェクトだからこそリーダーとして「もっとできたことがあったのでは！」と思っていることについても紹介しようと思います。

プロジェクトの成果とその要因

うまくいった点

全員が目標とそのメリットを実感しており、今期のゴールの認識が揃っていた

今回プロジェクトが順調に進んだ要因として一番大きかったと思う
プロジェクト開始時に、目的・目標を長期と短期で全員が認識を揃える場を設けた
今期やるべき事、なぜやるのかが明確になった
チームが自律的に動けていたのはゴールとメリットの言語化を最初の段階で行えた影響が大きかったと感じる
アクセシビリティチェック用のFigmaプラグインを独自に作成するメンバーなど、タスク外の自発的な改善行動が生まれた
プロジェクトの意義が腹落ちしていると、「自分で良くしよう」という動きが自然に生まれる

タスクの詳細分割

各タスクを「完了/未完了」と言える粒度まで細かく分割した
粒度が粗いと「なんとなくやってる」状態が生まれ、進捗が不透明になる
「どこで詰まっているか」を週次で把握でき、素早く手を打てた

役割と責任の明確化

ロールと責任範囲をキックオフ時点で揃えた
「誰が決めるか」の曖昧さは意思決定の遅延と責任回避を生む
意思決定の場面で迷いが少なく、プロジェクトの推進力が落ちなかった

週1定例

毎週火曜日の30分MTGで進捗確認と認識を揃える場の作成
エンジニア・デザイナー間の認識齟齬を無くし、お互いの信頼感を高めることができた

難しかった点と対処

調査タスクの工数読み

課題: 「調べてみないとわからない」タスクが想定より大幅に時間超過
対処: 調査そのものを1タスクとして明示し、工数バッファを事前に確保した
学び: 不確実なタスクには「調査フェーズ」という名前をつけるだけで工数精度が上がる

他職能の判断をどう依頼するか

課題: デザインやエンジニアリングの専門的判断が必要な場面で、どう振る舞うべきか迷った
対処: 「技術的にどちらが正しいか」ではなく「このプロジェクトへの影響は何か」を軸に整理し、専門判断は該当メンバーに委ねた
学び: プロジェクトリーダーに必要なのは全知ではなく、「プロジェクト視点での判断」

学び

プロジェクトを振り返っての学び

順調なときこそ、その要因を考える

順調に進んでいるとき、それを当然として流してしまいがちになる
うまくいっている理由を言語化できると、次のプロジェクトにも再現できる

共通の目標とメリットがチームを自律的にする

「誰かに言われたからやる」より「自分がやりたいからやる」状態が、チームの推進力を大きく変える
そのためには、ゴールとそれぞれにとってのメリットを言語化して共有することが不可欠
ゴールとメリットの言語化は、プロジェクトリーダーの最初の仕事

プロジェクトの目指す姿を意識し続けること

ゴールと現状のギャップを定期的に整理し、優先すべきことを迷わず判断できる状態を維持することが大切
今回は順調だった分、「さらに一歩前進できた部分があったのでは」と振り返っている
余裕がある時こそ、再度プロジェクトの大目的をチームで揃えて順調であっても何かしらの変化を起こしてみるべきだったかなと思う
- 今期の目標を調整してみる、チームメンバーの理解を深めるためのワークショップをやってみる、現状の課題を深掘りしてみるなど

プロジェクトを社内外に知ってもらうことが組織への貢献につながる

デザインシステムの取り組みを営業・広報など他職種の方に紹介する機会があり、そのときにお客さんからのフィードバックや質問に対して、「こういう取り組みをしているから高品質なんです！」とお客さんに伝えられるかもという視点をもらった
プロジェクトの内容を言語化して届けることは、プロダクトの信頼性や採用ブランドにもつながる
プロダクトの価値を社内外へ伝えることも、リーダーの役割の一つだと認識するようになった

まとめ

この半期、「種まき期」として設定したゴールを達成し、デザインシステムの基盤を整えることができました。

今後は Ph.2「実装期」 として、FigmaとコードのUI同期を進め、Schoo.jpの全サービスへのライブラリ接続を目指します。そして最終的には、職能を問わずバイブコーディングでフロントエンド実装ができる「開発サイクル革命」の実現と、デザインシステムの外部公開を目標に進んでいきます。

デザインシステムは、エンジニアやデザイナーだけのものではなく、会社全体の共有財産です。このプロジェクトの取り組みが、スクーのプロダクト開発のあり方を少しずつ変えていけることを楽しみにしています。

読んでくださった方に、何か一つでも学び・気づきがあれば嬉しいです。最後まで読んでいただき、ありがとうございました！

Schooでは一緒に働く仲間を募集しています！