デザインシステムとは｜作る順番と運用の基本

部品と判断を共有する

たとえば、会員登録と問い合わせの両方に「送信」ボタンがあるとします。色と高さをそろえても、通信中に押せるか、入力エラーをどこに表示するか、処理が完了したとどう伝えるかが違えば、利用者は画面ごとに操作を覚え直します。

デザインシステムが共有するのは、そのような判断も含む画面づくりの土台です。デジタル庁は、設計原則、コンポーネント、アクセシビリティを含むガイドラインを構成要素として説明しています。コンポーネントとは、ボタンや入力欄など、繰り返し使うUI部品です。デジタル庁の定義

共有するもの	内容の例	使うときに答えたいこと
原則	入力の負担を減らす、次の操作を明示する	判断が割れたとき何を優先するか
基本値	色、余白、文字サイズ	同じ意味に同じ値を使えているか
UI部品	ボタン、入力欄、通知	どの状態まで実装されているか
利用ガイド	用途、使わない場面、作例	この画面に採用してよいか
運用ルール	担当、変更提案、廃止手順	問題が出たら誰が直すか

最後の運用ルールは、本稿が小規模チーム向けに加えた整理です。見た目の一致だけを成果とせず、次の変更で同じ議論を繰り返さずに済むかを考えます。

UIキットとの違い

UIキットは画面を組み立てる素材、コンポーネントライブラリは再利用できる部品群を指すことが多い言葉です。デザインシステムは、それらを使う理由や条件まで含めて考えます。ただし名称の使い方は組織によって異なり、ファイル名だけで完成度は判断できません。

スタイルガイドとの関係にも幅があります。デジタル庁は、汎用的なデザインシステムを個々のサイトのブランドや情報構造に合わせ、具体的な仕様書へ落とし込むことを説明しています。既成の部品を導入した後にも、自分たちの利用者に合わせる仕事が残るわけです。スタイルガイドの説明

手元にあるもの	すぐに役立つこと	追加で確かめたいこと
FigmaのUIキット	画面案を組む	実装との対応、未作成の状態
コードの部品集	同じ処理を再利用する	用途、利用制約、検証範囲
色・文字のガイド	視覚表現をそろえる	操作やエラー時の振る舞い
上記を結ぶ運用	判断と変更を共有する	担当と利用側の連絡方法

UIやUX自体の意味を先に整理したい場合は、UI/UXデザイン入門を参照してください。本稿は独学の方法やツール選びではなく、チームで再利用するための運用を扱います。

ボタン1個を棚卸しする

TechCreate編集部は2026年9月14日、自サイトの共通ボタン実装を確認しました。見た目を指定するvariantは、標準、削除などの操作、枠線、補助、背景を抑えた表示、リンク風の6種類。サイズも標準、小、大、アイコン用の標準・小・大という6種類でした。

宣言を単純に組み合わせると6×6＝36通りです。これはコードの定義数から編集部が計算した値であり、36通りが実際に利用されている、すべて動作確認済みである、という意味ではありません。さらに無効状態やキーボードフォーカスの表現も定義されていました。

棚卸し項目	今回コードで確認したこと	それだけではわからないこと
見た目の選択肢	6種類	各画面が適切に使い分けているか
サイズの選択肢	6種類	長い文言で崩れないか
無効状態	共通スタイルの定義あり	利用者に理由を伝えているか
フォーカス	視覚表現の定義あり	実画面の操作順が自然か

この棚卸しからわかるのは、共通部品を作った後にも確認対象があることです。「ボタンは完成」と記録するだけでは、後から参加した人は何を安心して使えるのか判断できません。組み合わせの利用状況、確認した状態、未対応のケースを分けて記録すると、次の作業が具体的になります。

今回の確認はソースコードの静的な棚卸しです。利用者テストやアクセシビリティ適合性の認証、導入による工数削減の測定は実施していません。

作る順番を小さくする

最初は、最近変更した画面を少数選びます。フォーム、一覧、詳細画面など、実際の仕事で繰り返す画面が適しています。色違いを探すだけでなく、「同じ修正を別ファイルにも入れた」「エラー表示を毎回相談した」といった重複作業を書き出します。

以下は、公式資料の考え方を小規模チームへ置き換えた編集部の提案です。特定の企業で効果を実証した導入手順ではありません。

順番	作業	終わったと判断する材料
1	頻出画面を棚卸しする	同じ課題が出る画面の一覧
2	原則を短く決める	迷う場面と優先する判断の対応
3	必要な基本値をそろえる	色や余白の意味と参照先
4	頻出部品を整える	通常・エラー等の状態と実装
5	実画面に適用する	既存の操作を保てるかの確認
6	利用方法と担当を残す	作例、制約、問い合わせ先

最初からすべての部品を対象にすると、利用実績のない選択肢まで維持することになります。反対に、1画面だけの特殊な要求をそのまま共通化すると、使わない設定が増えます。まず既存部品で対応できるかを確かめ、繰り返し出る課題だけを候補にします。

GOV.UKは新しい部品の提案に対し、多くのチームで役立つ根拠と、既存のものを重複させないことを求めています。この考え方は、少人数でも「作れるから追加する」という判断を見直す手がかりになります。GOV.UKの貢献基準

変更する人を決める

導入後は、誰でも修正を提案できる窓口と、共通仕様へ取り込む判断をする担当を決めます。少人数なら同じ人が兼任して構いません。ただし、提案と判断を区別して記録します。

IBMのCarbonは、コード、デザイン、文書それぞれの貢献を受け入れています。新しい部品と小さな修正で進め方を分け、提案、フィードバック、レビューを通す運用です。部品の維持は、画面を描く人だけでも、コードを書く人だけでも完結しないことがわかります。Carbonの貢献手順

特に注意したいのは、既存の利用方法を変える修正です。たとえば引数名を変更したり、エラー表示の位置を変えたりすると、利用側のコードやテストも影響を受けます。変更した部品の一覧と、使っている画面、移行方法をひとまとまりで記録します。

廃止するときも同じです。古い部品を削除する前に、新規利用を止める案内、代替部品、残っている利用箇所を確認します。日付だけ決めて取り除くと、担当者が変わった画面で移行漏れが起きます。

運用票を1枚残す

次の表は、部品ごとに複製して使うための編集部作成の運用票です。ツールを新しく契約しなくても、既存の文書やリポジトリで管理できます。

項目	記入内容
解決する課題	どの利用者が、どの操作で困るか
採用する場面	確認済みの画面・用途
採用しない場面	未対応の入力形式や複雑な用途
確認した状態	通常、エラー、無効、フォーカス等
管理担当	判断する人と相談先
変更履歴	何を、なぜ変えたか
移行対象	影響する画面、代替方法、残作業

「確認した状態」は実施した内容だけを書きます。自動テストが通っても、キーボード操作や読み上げ、長い文言、狭い画面を確認したとは限りません。部品単体と実画面で確認する項目も分けます。

効果を振り返る際は、登録部品数だけを数えないようにします。利用中の画面数、同じ不具合の再発、修正から利用側へ反映されるまでの日数などが材料になります。導入前の記録がなければ「何割改善した」とは言えません。まず記録を取り始め、同じ定義で追います。

よくある質問

一人開発でも必要ですか

同じ変更を複数箇所へ繰り返しているなら、部品と利用ルールをまとめる価値があります。一方、使い捨ての試作で全画面を整える必要はありません。維持できる範囲から始めます。

Figmaは必須ですか

必須ではありません。設計と実装が対応し、他の人が用途や制約を理解できることが大切です。普段使っている文書やコードの管理方法から始められます。

何個の部品から始めますか

一律の個数はありません。現在の画面で繰り返し使い、修正負担が出ている部分を選びます。利用予定のない部品を増やすと、更新や確認の負担も増えます。

導入すれば操作性は上がりますか

それだけでは保証できません。同じ部品でも情報の並べ方や文言によって使いやすさが変わります。部品の確認に加え、実際の画面で利用者が目的を達成できるかを確かめます。

共通化できない画面はどうしますか

固有の要求として残し、その理由を記録します。ほかの画面にも同じ課題が出たら共通化を再検討します。例外を隠すより、何が違うかを説明できる方が運用しやすくなります。

まとめ

• デザインシステムは、原則・UI部品・使い方を共有する土台です。小規模チームでは、変更する担当と手順も残すと次の判断に使えます。
• TechCreateのボタンは宣言上36通りの組み合わせがありました。定義数と利用実績、検証済み範囲を分けることが、部品の棚卸しで得られる実務上の気づきです。
• 頻出画面から始め、用途、制約、管理担当、移行対象を記録します。部品数を増やすより、使われているものを直し続けられるかを確認することが大切です。

出典・参考

• デジタル庁「デザインシステムとは」
• デジタル庁「スタイルガイド」
• GOV.UK Design System「Contribution criteria」
• IBM Carbon「Getting started」
• TechCreate編集部による自サイト共通ボタン実装の静的棚卸し（2026年9月14日）。見た目6種、サイズ6種の宣言を確認。利用件数、操作性、工数削減率の実測ではありません。