design-ops

デザインオペレーションとハンドオフ

デザインチームの有効性を高める運用プロセス――スプリント、ハンドオフ、定例活動、ドキュメント作成、品質保証。

---

デザインスプリント

大きな課題を解決し、エンジニアリングのリソースを投入する前にアイデアを検証するための5日間のプロセスです。Google Venturesで開発されたJake Knappのスプリント手法に基づいています。

スプリントを実施するタイミング

兆候	スプリントが適している場合	スプリントが適していない場合
課題の明確さ	大きな課題があり、解決策が不明確	解決策がすでにわかっている――あとは作るだけ
重要度	高い――方向性を誤ると数か月を失う	低い――後から簡単に軌道修正できる
チームの足並み	アプローチについて意見が分かれている	チームの意見がすでに一致している
時間的な制約	今週中に答えが必要	より長いディスカバリープロセスを実施できる
複雑さ	部門横断的な課題	単一分野のタスク

5日間の構成

日	フォーカス	主な活動	成果物
月曜日	マップ	課題を定義し、2年後の目標を設定して、問題領域をマッピングし、対象を選ぶ	スプリントの問い、問題マップ、対象領域
火曜日	スケッチ	既存の解決策を確認し、各自で解決策をスケッチする	解決策のスケッチ（1人1案）
水曜日	決定	スケッチを発表し、投票する（ドット投票と決定者による選択）。ストーリーボードを作成する	プロトタイプ用のストーリーボード
木曜日	プロトタイプ	テストに必要な範囲で、リアルな外観の仮実装を作る	テスト可能なプロトタイプ
金曜日	テスト	5人のユーザーにインタビューし、全員で観察してパターンを特定する	根拠に基づく実施可否の決定

スプリントチーム

役割	人数	責任
決定者	1	最終決定を下す権限を持ちます。通常はPMまたは創業者です
ファシリテーター	1	プロセスを進行し、時間とチームの活力を管理します
デザイナー	1-2	スケッチを主導し、プロトタイプを作成します
エンジニア	1-2	実現可能性を直感的に確認し、プロトタイプを支援します
ドメインエキスパート	1-2	カスタマーサポート、営業、マーケティングなど、ユーザーをよく知る人です
合計	5-7	7人を超えると逆効果です

スプリントのルール

1. 作業セッション中はデバイスを使わない――集中して取り組みます
2. 一緒に集まり、個別に作業する――グループでのブレインストーミングではなく、各自でスケッチします
3. 決定者が決める――多数決は時間がかかるため、1人が決着をつけます
4. 作り込まず、プロトタイプにする――本番品質ではなく、外観の品質を重視します
5. ユーザーは5人で十分――5人の参加者でユーザビリティの問題の85％が見つかります

---

デザインから開発へのハンドオフ

ハンドオフは、プロダクトチームにおける品質低下の最大の原因です。目標は、エンジニアが推測せずに済むようにすることです。

ハンドオフの成熟度レベル

レベル	説明	症状
1. スクリーンショット	デザイナーが静止画像を送る	エンジニアが間隔、状態、動作を推測する
2. 注釈付きモックアップ	寸法線、間隔の注記	改善されますが、状態やエッジケースがまだ不足しています
3. インタラクティブ仕様	インスペクトモードやコンポーネントへのリンクを備えたFigmaなどのデザインツール	エンジニアは値を取得できますが、動作は文書化されていません
4. 完全な仕様	すべての状態、遷移、エラー処理、レスポンシブ動作、トークン	エンジニアはデザインどおりに正確に実装できます
5. 統合	デザインとコードがコンポーネントシステムを共有し、ハンドオフはドキュメントではなく対話で行われます	共通言語が機能するため、必要な仕様は最小限です

目標：最低でもレベル4。成熟したチームではレベル5を目指します。

完全なハンドオフに含める内容

すべての画面またはコンポーネントのハンドオフでは、以下を網羅する必要があります。

カテゴリ	必須項目
レイアウト	余白（ピクセルではなくトークンで指定）、配置、レスポンシブのブレークポイント、コンテナーの動作
コンテンツ	最終的な文言（ダミーテキストではない）、文字数制限、切り詰めルール、ローカライズに関する注記
状態	すべてのインタラクティブ要素について、デフォルト、ホバー、フォーカス、アクティブ、無効、読み込み中、空、エラー、成功
動作	クリック／タップ、キーボード操作、ドラッグ、スワイプ時の動作。トランジションの詳細
レスポンシブ	各ブレークポイントでのレイアウトの適応方法。再配置、縦積み、非表示、変更される要素
トークン	色、タイポグラフィ、余白の各トークン。生の hex／px 値は使用しない
アクセシビリティ	フォーカス順序、ARIA ロール、スクリーンリーダーへの通知、タッチターゲット、色のコントラスト
エッジケース	長い文字列、空のデータ、エラーからの復旧、オフライン時の動作、権限
アセット	アイコン（SVG）、画像（代替テキスト付き）、アニメーション（仕様またはファイル）

ハンドオフで避けるべきパターン

アンチパターン	問題	対策
「Figma にあります」	コンテキストがなく、エンジニアが意図をリバースエンジニアリングする必要がある	すべてのフレームに動作に関する注記を書く
ハッピーパスのみ	理想的なフローしか設計されていない	ハンドオフ前にすべての状態を設計する
ピクセル単位の仕様	「左マージンは 24px」	トークンを使用する：spacing-md
口頭でのハンドオフ	「スタンドアップで説明します」	書き留められていなければ、存在しないのと同じです
一括ハンドオフ	機能全体を一度にエンジニアリングチームに渡す	スプリントのストーリーに合わせて小分けにして引き継ぐ
エラー状態なし	「エラーは後で考えます」	エラー状態は最後ではなく、最初に設計する

---

チームの定例活動と頻度

基本的なデザイン活動

活動	頻度	所要時間	目的	参加者
デザイン批評会	毎週	45-60 分	構造化されたフィードバックを通じて制作途中の成果物を改善する	デザイナー全員
デザイン・エンジニアリング同期会	毎週	30 分	今後の作業について認識を合わせ、ハンドオフに関する疑問を解消する	デザインリード＋エンジニアリングリード
デザインレビュー	マイルストーンごと	30-60 分	方針についてステークホルダーの承認を得る	PM、デザインリード、エンジニアリングリード、ステークホルダー
ハンドオフセッション	ストーリー／機能ごと	30-45 分	エンジニアリングチームに仕様を説明し、質問に答える	デザイナー＋実装を担当するエンジニア
デザインQA	リリースごと	60-90 分	実装が仕様と一致していることを確認する	デザイナー＋エンジニア
レトロスペクティブ	隔週またはスプリントごと	45 分	プロセスを改善する	プロダクトチーム全員
デザインスプリント	必要に応じて	5 日	大きな課題を解決し、リスクの高いアイデアを検証する	クロスファンクショナルチーム（5-7 人）

効果的なデザイン批評会の進め方

形式： 発表者が背景を共有（2 分）→ グループが黙読して確認（3 分）→ 構造化されたフィードバック（項目ごとに15-20 分）→ 次のステップ（2 分）

批評会のルール：

1. 発表者は求めるフィードバックを明確にする。「どう思いますか？」ではなく、「空の状態のデザインについて助けが必要です」
2. フィードバックは好みではなく原則に基づける。「ボタンの配置が気に入りません」ではなく、「これはフィッツの法則に反しています」
3. 解決策を指示するのではなく、問題を説明する。「ボタンを大きくしてください」ではなく、「ユーザーがこの操作を見逃す可能性があります」
4. 反論しない。発表者は話を聞き、確認の質問だけをする
5. メモを残す。誰かがすべてのフィードバック項目と担当者を記録する

ハンドオフセッションの構成

1. 背景（5 分）— どのような問題を解決するのか？ どのユーザーストーリーか？
2. ウォークスルー（10-15 分）— デザイナーが画面ごとにフローを説明する
3. 状態とエッジケース（10 分）— ホバー、エラー、空、読み込み中、レスポンシブ
4. トークンとコンポーネント（5 分）— 使用するデザインシステムのコンポーネントとトークン
5. 質問（10 分）— エンジニアが不明点を質問する
6. アクション項目 — 実装開始前に明確にする必要がある事項

---

ドキュメントの標準

ファイル構成

project-name/
├── exploration/          # Early concepts, discarded directions
│   └── v1-concepts/
├── current/              # Active, approved designs
│   ├── flows/            # User flows and journey maps
│   ├── screens/          # Screen-level designs
│   └── components/       # Component-level specs
├── assets/               # Production-ready exports
│   ├── icons/
│   └── images/
├── handoff/              # Handoff documentation
│   └── [feature-name]/
└── archive/              # Past versions (never delete, move here)

命名規則

要素	規則	例
ファイル	[project]-[feature]-[variant]	taskpilot-onboarding-v2
ページ／フレーム	[flow]-[step]-[state]	checkout-payment-error
コンポーネント	コード内のコンポーネント名と完全に一致させる	Main CTAではなくButtonPrimary
バージョン	セマンティック形式：v1.0、v1.1、v2.0	メジャー＝新しい方向性、マイナー＝反復
レイヤー	説明的な名前にし、「Group 1」や「Frame 47」は使わない	header/nav/menu-trigger

バージョン管理ルール

1. 上書きしない — 新しいバージョンを作成し、古いバージョンはアーカイブします
2. 変更内容に名前を付ける — 単に「v2.1」ではなく、「v2.1 — エラー状態を追加」のようにします
3. 決定事項にリンクする — すべてのメジャーバージョンを、その変更の根拠となった決定事項（Slack スレッド、会議メモ、スプリントレビュー）にリンクします
4. 信頼できる唯一の情報源にする — 機能ごとに正本となるファイルを1つにします。「copy of」ファイルは作成しません
5. 削除せずにアーカイブする — 古くなったデザインは日付を付けてアーカイブに移動します

---

デザイン QA

デザイン QA とは、実装されたものがデザインどおりであることを確認するプロセスです。リリースの前に毎回実施します。

デザイン QA チェックリスト

カテゴリ	チェック項目	ツール
視覚的な正確さ	色がトークンと一致している。余白が仕様と一致している。タイポグラフィが正しい	並べて比較、ブラウザー開発者ツール
状態	すべての状態が正しく表示される：デフォルト、ホバー、フォーカス、アクティブ、無効、エラー、読み込み中、空	手動テスト、Storybook
レスポンシブ	すべてのブレークポイントでレイアウトが機能する。はみ出し、不適切な切り詰め、消失がない	ブラウザーのサイズ変更、実機でテスト
コンテンツ	実際のコンテンツが収まる。長い文字列に対応できている。空の状態がデザインされている。切り詰めが正しく機能する	エッジケースのコンテンツでテスト
インタラクション	アニメーションが仕様と一致している。遷移が滑らかである。タイミングが適切に感じられる	手動テスト、スローモーション録画
アクセシビリティ	フォーカス順序が正しい。スクリーンリーダーが正しく読み上げる。コントラスト基準を満たしている。タッチターゲットが44px以上	axe、キーボードテスト、VoiceOver/NVDA
クロスブラウザー	Chrome、Firefox、Safari、Edgeで正しく表示される	BrowserStackまたは手動
パフォーマンス	画像が最適化されている。レイアウトシフトがない。アニメーションでフレーム落ちがない	Lighthouse、Core Web Vitals

デザイン QA の課題登録

すべての課題には以下が必要です：

**What:** [Element name] on [screen/page]
**Expected:** [What the design spec shows — link to frame]
**Actual:** [What the build shows — screenshot]
**Severity:** [Critical / Major / Minor / Cosmetic]
**Environment:** [Browser, viewport, OS]

重大度の基準：

• 重大 — 機能が壊れている。ユーザーがタスクを完了できない
• 高 — 動作が誤っている。ユーザーはタスクを完了できるが、混乱したりエラーが発生したりする
• 軽微 — 視覚的な不一致。ユーザーの機能面への影響はないが、品質に違和感がある
• 見た目のみ — 細かな指摘。デザイナーだけが気付くピクセル単位の差異

デザインの受け入れ基準

すべてのユーザーストーリーに以下を追加します：

Design acceptance criteria:
- [ ] All states match design spec (link to Figma frame)
- [ ] Responsive behavior verified at 320px, 768px, 1024px, 1440px
- [ ] Keyboard navigation works (Tab, Enter, Escape, Arrow keys)
- [ ] Screen reader announces all interactive elements correctly
- [ ] Design tokens used (no hardcoded colors, spacing, or typography)
- [ ] Loading and error states implemented
- [ ] Edge-case content tested (empty, long strings, special characters)

---

プロセス指標

デザイン運用の健全性を測るため、以下を追跡します：

指標	測定内容	目標	測定方法
引き継ぎの完全性	すべての状態、トークン、レスポンシブ仕様が揃った引き継ぎの割合	>90%	四半期ごとに引き継ぎドキュメントを監査
デザイン QA 合格率	初回レビューでデザイン QA に合格したストーリーの割合	>80%	ストーリーごとに QA の課題を追跡
手戻り率	引き継ぎ後にやり直しとなるデザイン作業の割合	<15%	引き継ぎ後のデザイン変更を数える
スプリント速度への影響	仕様不足がエンジニアリングを妨げる頻度	0件のブロック／スプリント	朝会でブロッカーのタグを追跡
デザイン負債	本番環境に残る、既知の視覚的／操作上の不整合	減少傾向	デザイン負債のバックログを管理
批評への参加	デザイナーが定期的に作品を批評に持ち込む割合	毎月100%	批評の発表者を追跡

---

少人数チーム向けの簡略化した運用

上記のプロセスは、専任のデザインチームを想定しています。しかし、多くの組織にはデザイナーが1人しかいなかったり、より広範な役割の一部としてデザインを担当する人がいたりします。それでも原則は変わりません。実施方法の規模を縮小します。このセクションでは、Leah Buley の「UX team-of-one」フレームワークを参考に、リソースが限られたチーム向けに調整した手法を紹介します。

中核となる考え方

1. 小さな成果に焦点を当てます。 組織を一夜にして変えることはできません。目に見える改善を一つ選んで実現し、その成果を次の取り組みへの弾みにしましょう
2. UX 部門ではなく、ユーザー中心の文化を築きます。 目標はすべてのデザイン業務を自分が担うことではなく、チーム全員がユーザーについて考えるようにすることです
3. 成長マインドセットを身につけます。 スキルを少しずつ伸ばせる機会を探しましょう。調査やテストの実践を始めるのに、許可は必要ありません

ゲリラ手法

予算、時間、正式な調査体制がない場合：

完全なプロセス	ゲリラ版の代替案	これで十分な場合
正式なユーザビリティ調査（ラボ、参加者募集、5 名以上）	3 人を対象にした 15 分間の廊下テスト	初期コンセプト、社内ツール、リスクの低い機能
数週間にわたるディスカバリー調査	1 週間で顧客に 3 件インタビューし、サポートチケットを確認	統計的な確度ではなく、方向性を把握したい場合
デザインスプリント（丸 5 日間）	ミニスプリント：2 日間版（1 日目にマップ作成＋スケッチ、2 日目にプロトタイプ作成＋テスト）	小規模な課題、足並みのそろったチーム、十分な先行調査がある場合
全行程のジャーニーマップ作成ワークショップ	ホワイトボード上の仮説マップ（チームで 30 分、既知のことと推測を区別する）	調査よりも認識合わせが必要な場合
正式なデザイン批評（毎週、デザイナー全員で実施）	Figma のコメントを使った非同期の批評。エンジニア 1 人と PM 1 人が参加	デザイナーが 1 人で、デザインの同僚がいない場合
ガバナンスを備えたデザインシステム	コンポーネント一覧＋命名規則を定めた共有 Figma ライブラリ	小規模なプロダクトで、エンジニアが 1～3 人の場合

関係構築と支持の獲得

1 人、または少人数のチームで働くデザイナーの有効性は、プロセスよりも人間関係に左右されます。

議論の場に加わるための信頼を得る：

• まずチームの差し迫ったニーズに応えます。地道な作業でも、信頼関係の構築につながります
• 説明するより、実際に見せましょう。問題を明らかにする簡単なプロトタイプは、UX の成熟度についてのプレゼンテーションより価値があります
• UX の取り組みを、リーダーがすでに重視している指標（コンバージョン、サポートチケット、継続率）に結びつけます

権限に頼らず影響を与える：

• 推奨事項を命令ではなく実験として提示します。「決める前に、ユーザー 3 人でこれをテストできますか？」
• 相手に合わせた形式で調査結果を共有します。エンジニアには Slack の要約、リーダーにはダッシュボード、PM には注釈付きスクリーンショットを使います
• 自信を持って結果を提示しつつ、協力を促します。「分かったことはこちらです。これはあなたの担当領域にどのような意味がありますか？」

少人数チーム向けに調整した定例

通常の定例	少人数チーム向けの代替案	頻度
毎週のデザイン批評	隔週の「デザインランチ」 — デザイナー以外も含め、関心のある人に作業中のものを見せる	2 週間ごと
デザイン・エンジニアリングの同期	15 分のスタンドアップに「このスプリントで予定しているデザインはこちらです」を追加	スプリントごと
正式なデザインレビュー	マイルストーンの前に、1 ページの意思決定ドキュメントを PM と共有。承認は非同期で行う	マイルストーンごと
デザイン QA スプリント	PR テンプレートに QA チェックリストを追加 — マージ前にデザイナーが確認する	ストーリーごと
レトロスペクティブ	チームのレトロスペクティブにデザインに関する質問を 1 つ追加：「デザインと実装が食い違ったのはどこですか？」	スプリントごと

簡略化した引き継ぎ

完全な仕様書を用意するのが現実的でない場合：

1. 文脈に沿って注釈を付けます。 別の仕様書は作らず、Figma のフレームに直接、動作に関するメモを追加します
2. 曖昧な点を優先します。 明白なことまで仕様にする必要はありません。エンジニアが推測することになる状態、遷移、例外ケースに焦点を当てます
3. 一度説明し、質問を記録します。 15 分の説明会と、Figma のコメントで回答したエンジニアからの質問一覧があれば、十分な場合が多いです
4. 共通の語彙を早めに築きます。 エンジニアとコンポーネント名やトークンの使い方について合意できれば、引き継ぎのたびに説明する言葉を減らせます

小さな成功の力

非公式な形でも、自分の貢献を記録し、伝えましょう。

• 「新しいフローを3人のユーザーでテストしたところ、2人が保存ボタンを見つけられませんでした。ボタンを移動した結果、そのフローに関するサポートチケットが40％減りました」
• 「前提マップから、ユーザーが料金についてどう考えているかのデータがないことがわかりました。2件のインタビューを行った後、エンジニアリングが着手する前に料金ページを再設計しました」
• 「PRにデザインQAのステップを追加したことで、今四半期に、リリースされていたはずの視覚的なバグを12件発見しました」

小さな成功は積み重なります。その一つひとつが、次にデザインへの投資について話し合う機会を作りやすくします。

---

よくある間違い

間違い	失敗する理由	より良い方法
スプリントマップの日を省略する	チームが間違った問題を解決するためのものを作る	月曜日のマップ作成と目標選定が最も価値のある日です
孤立してデザインする	引き渡した成果物がエンジニアリングの実情に合わない	毎日または毎週、デザインとエンジニアリングの同期を行う
デザインQAのプロセスがない	時間とともに視覚的な品質が低下する	リリース時だけでなく、すべてのストーリーでQAを行う
ドキュメントを作りすぎる	誰も読まない30ページの仕様書	曖昧な点を仕様書に記載する。残りは共有コンポーネントシステムで対応する
ドキュメントが不足している	「Figmaを見ればわかります」	エンジニアから質問が出るなら、仕様書は不完全です
引き渡しを一度きりのイベントとして扱う	仕事を壁の向こうへ放り投げることになる	引き渡しは、実装を通じて続く対話です
レトロスペクティブがない	同じ間違いを繰り返す	具体的なアクション項目と担当者を決めて、隔週でレトロスペクティブを行う
デザイン批評を承認の関門にする	批評が政治的なものになる	批評は成果物を改善するためのものであり、承認するためのものではありません