デザイン承認プロセス:6つのステージ、依頼チェックリスト、テンプレート

最終更新日：2026年10月1日

「ちょっとだけお願いできますか」は、クリエイティブの現場で最も高くつく言葉です。その後ろに続くのは、たいてい本物の依頼と本物の期限です。ただ、それは依頼ではなくメッセージとして届くため、誰かが覚えている間しか存在しません。

これが6人の依頼者分重なると、キューはキューではなくなります。それぞれの依頼者が「次は自分の番」と信じている、個人的な了解の集まりになります。

デザイン承認プロセスには、繰り返しに耐える力も必要です。契約書のサインは1回で済みますが、同じアートワークは、それぞれ違うバージョンを見た人たちによって3、4回判断されます。

壊れるのは、誰も整えていない2か所です。依頼の届き方と、最初のレビューから4回目のレビューまでの間です。

デザイン承認プロセスは、なぜデザインが始まる前に壊れるのですか?

壊れるのは受付です。メッセージとして届いた依頼には状態がないため、その依頼が属するキューが見えません。メッセージは、待機中にも、受理済みにも、3番目にもなれません。あるのは未読か既読だけです。

その結果、声の大きい依頼者が勝ちます。誰にとっても手がかりが声の大きさだけだからです。デザイナーは静かに、そのままキューになってしまいます。さらに、優先度が議論できなくなります。「緊急です」は、何とも照らし合わせて確かめられません。

この最後の問題は、直すのが簡単です。ほとんどの依頼には日付がありますが、理由が書かれているものはほぼありません。

理由を独立したフィールドとして依頼に載せると、2種類が自然に分かれます。「印刷所の締切は7月16日、猶予なし」は期限です。「期日なし、現行テンプレートがモバイルで崩れる」は期限ではありません。どちらも本物の仕事です。割り込めるのは片方だけです。

Quireでは、ゲートはトリアージにあります。依頼者と、そのフィールドの理由がなければ、受付リストから出られません。これで「緊急です」が、確かめられるものになります。

デザインのキューは、コメントできる人が多すぎて、決める人が誰もいないときにも詰まります。RACI、DACI、RAPIDの比較は、以下すべての土台にある「誰が決め、誰が助言するか」の層を扱っています。

デザイン依頼には、作業開始前に何が書かれている必要がありますか?

答えは6つです。6つすべてが揃った依頼は今日から始められます。2つ欠けた依頼は、3日かけて交わす会話になります。

• 何を作るのかを、1行で。「何かローンチ用に」より「Instagramのカルーセル、5枚」のほうが伝わります。
• どこに掲載し、サイズはどれくらいか。サイトのバナー、32pxのアプリアイコン、2メートルのブース用パネルは、同じ言葉の裏にある3つの別の仕事です。
• 誰向けか。社内の関係者ではなく、受け手となる読者です。
• いつ、そしてなぜその日か。日付より理由のほうが多くの情報を持っています。
• 誰がサインオフするか。名前は1つです。
• すでにあるものは何か。ブリーフ、コピー、前のバージョン。足りない材料はすべて質問になり、質問が3日を2週間に変えます。

プロジェクトマネージャーは、これを数字にしています。

要件に関するPMIのPulse of the Profession調査によると、失敗したプロジェクトのほぼ半数(47%)が、要件管理の不正確さが原因で目標に届きませんでした。デザイン依頼は、いわば小さな要件です。曖昧な依頼も同じように失敗し、ただ失敗が早いだけです。

6つのうち1つは、専用のフィールドを持つ価値があります。フィールドにすれば、答えを並べ替えられるからです。日付の裏にある理由はWhy this dateになります。

その隣にさらに2つのフィールドがあります。依頼した人を示すRequested byと、作業が何回戻ってきたかを示すReview roundです。

残りはタスクの説明に書く文章です。テンプレートには6つすべてが、案内先にできるHow to request design workドキュメントとして入っています。

10分で試せます。無料のQuireプロジェクトを始めるか、すでに運用中のプロジェクトを開き、Why this dateというテキストフィールドを追加します。そして、未完了で最も古い5件の依頼に入力してみてください。2件は理由がまったくない、ということになりがちです。それで説得は終わりです。

デザイン承認プロセスの6つのステージとは?

6つのステージは、Requested(依頼受付)、In Design(デザイン中)、Internal Review(社内レビュー)、Awaiting Approval(承認待ち)、Changes Requested(修正依頼)、Delivered(納品済み)です。この6つは作業の現在地を示します。判断には別の記録、つまりタスク上の承認を持たせます。両者を分けておくことが、コツの大半です。

Design Pipelineテンプレートでの各ステージの動きは次のとおりです。

Internal Reviewは、チームが飛ばしがちですが、それ自体で元が取れるステージです。承認者との1回目のラウンドを、角丸の半径ではなくアイデアに使えるようになります。

Changes Requestedは、唯一逆方向に進むステージなので、数える価値があります。詳しくは後述します。

この表のすべてのステージは、依頼するチームとデザインするチームという、2つのチームの間の引き継ぎです。部門横断プロジェクト管理のプレイブックでは、その土台にある担当と引き継ぎの層を整理しています。

QuireのDesign Pipelineテンプレートには何が入っていますか?

すぐ使えるデザインのキューです。上記6つのステージ、3つのカスタムフィールド、2つのサブリスト、Creative sign-off承認カテゴリー、2つのドキュメント、ダッシュボードが入っています。QuireのDesign Pipelineテンプレートを開き、Intake: not triagedサブリストに入ると、この主張のすべてが3行に表れています。

Recruiting postersのWhy this dateには「Careers fair is 16 Aug」とあります。Partner co-brand kitは1週間早い締切ですが、「Partner launch has no date yet」とあります。同じキュー、同じフィールドでも、期限と呼べるのは片方だけです。

こうした行を支えているのは次の要素です。

• 3つのフィールド。型が重要です。Requested byはユーザーフィールドなので、キューを依頼者で絞り込めます。Why this dateはテキストです。Review roundは数値で小数なし、そのため並べ替えられます。この3つをどこでも再現できれば、価値の大半は手に入ります。
• サーフェスを示すタグ:web、brand、social、print、email、video。本当に急ぎのものにはrushを付けます。
• Intake: not triaged。まだ受理も見積もりもスケジュールもされていない依頼のサブリストです。その長さがキャパシティのシグナルになります。トリアージのルールが本当のゲートで、すべての項目に依頼者、理由、そして枠か断りのどちらかが必要です。
• Waiting on a decision。承認者のもとで止まっている完成作業のサブリストです。長さではなく、経過日数で読みます。
• Creative sign-off承認カテゴリー。あらかじめ用意されているので、完成した作業を指名された担当者に送り、記録される承認か、修正点のリストを受け取れます。
• 2つのドキュメント:依頼者向けの6つの回答のチェックリスト「How to request design work」と、5ステップの設定ガイド「How to use this template」です。
• Creative Opsダッシュボード。ブロック中のタスクのウィジェットと、6つの状態への分布が見られます。

コピーするのは1分ほどです。テンプレート名の横のドロップダウンを開き、Moreから複製を選び、コピーを置く組織を選びます。

サンプルは、自分のもののように感じ始める前に削除しましょう。そして、何かが2回うまくいかなくなるまで、4つ目のフィールドは足さないでください。記入されるのは3つまで、6つあれば無視されます。無視されたフィールドは、データのように見えるぶん、何もないより悪いのです。

Design Pipelineは、Quireのライブラリにおける段階型パイプラインの定番です。プロジェクト管理テンプレートのまとめでは、残りのテンプレートを有限型、繰り返し型、段階型の仕事に分類しているので、次に必要なテンプレートも見つけやすくなります。

デザイン依頼は、なぜチャットではなくタスク管理ソフトに置くべきですか?

依頼がタスクになれば、メッセージのスレッドにできなかった仕事を、パイプラインのステージが担ってくれるからです。サンプルデータでは、4件が承認者のもとにあり、3件が未トリアージだと、誰でもプロジェクトを開けば分かります。デザイナーに読み上げてもらう必要はありません。

タスク管理ソフトがクリエイティブの現場で果たす役割は、これに尽きます。すべての依頼にステージと担当者と順番があること。チャットのスクロールには、一度もできなかったことです。

その大半を担うのが2つのサブリストです。サブリストとは、メインのリストと並べて置く、プロジェクトの保存済みスライスのことです。どちらも全員に見え、承認の列をオンにすれば、各行の結論も見えます。

Waiting on a decisionに3日置かれているなら、たいてい誰かが避けています。

見る場所は、次の区別で決まります。

Awaiting Approval(承認待ち)ステージは共有のキューで、並べ替えができ、月曜日にレビューする対象です。

承認とリクエストのウィジェットは自分専用の受信箱で、自分宛ての承認待ちと、自分が送ったリクエストを数えます。どちらにも当てはまらない人には0と表示されます。チームの問いに答えられるのは、前者だけです。

すでに専用ツールで、アートワークにピンを立ててファイルをチェックしていますか?そのツールはマークアップ用に残し、チェック用リンクを依頼に貼り付けてください。キュー、ラウンド数、サインオフはタスクに残るので、チーム全員が見られます。

社外のレビュー担当者は、デザインそのものよりアカウント作成で止まることが多いものです。見るだけのクライアントは、アカウントなしでリンクを開けます。ご希望なら、1つのサブリストに範囲を絞れます。やり方はクライアントとサインアップなしでプロジェクトを共有する方法をご覧ください。

デザインレビューの1回目から4回目までの間に何が起きますか?

予算は描き直しのたびに少しずつ漏れていきますが、通常の運用ではそれを記録するものがありません。1回目は問題ありません。予算が尽きるのは4回目で、その間を扱うプロセス文書はほとんどありません。

だから数えます。Review roundフィールドが、なんとなくの空回り感を、並べ替えられる列に変えます。1回は普通、2回も問題なし、3回が固まって並ぶなら、それはデザインの問題の顔をした受付の問題です。ブリーフが間違っていて、描き直しでは直りません。

もう半分は、ラウンドの中身です。7社の従業員264人を対象にした研究で、Zhenxing GongとNa Zhangは、支えとなるフィードバック環境が、気分を介して間接的にクリエイティブな成果を高めると明らかにしました。

結論はこうです。「支援的な上司のフィードバック環境を整えることは、創造的なパフォーマンスを高めるうえでかなり重要である」。アンケートデータなので、操作できるレバーではなく相関として読むべきですが、要点は変わりません。フィードバックは作業への反応ではなく、作業の一部です。

そこで、守る価値のあるルールが1つあります。フィードバックは、気持ちではなく変更点を言葉にする。

「ピンとこない」は修正依頼ではありません。「375pxでバッジがカードの外にはみ出している」は修正依頼です。変更点を言葉にできないレビュー担当者は、まだレビューの準備ができていません。そう早めに伝えるほうが、3ラウンド手探りするよりも親切です。

Quireでは、そのフィードバックがファイルと一緒にタスクに残ります。そのため、2回目のラウンドは1回目と同じアートワークの上で始まり、レビュー担当者は別のことを頼む前に、前回何を頼んだかを確認できます。

テンプレートには、ケーススタディの1ページ資料に実例があります。上のリストでCreative sign-off: 変更をリクエストと表示されている2行のうちの1つです。

ラウンド2で、2つの修正点を挙げたコメントが付いています。お客様の声に抜けている役職名と、本文のコピーと合っていない指標です。

そのうえでコメントは、1回目のラウンドですでにサインオフされた部分を明示的に守っています。この最後の点は、見た目以上に重要です。決着済みの判断を蒸し返すと、ラウンド2がラウンド5になるからです。

クライアントワークは、この問題の音量を上げたものです。修正が自分のチームの外から届くからです。カオスのないエージェンシーのプロジェクト管理では、レビューする人が費用を払う人である場合のラウンド上限の決め方を扱っています。

誰がサインオフし、その判断はどこに記録されますか?

判断1つにつき指名された1人で、その判断は依頼そのものに記録します。承認者が2人いるデザインは、承認者がいないのと同じです。テンプレートはCreative sign-offカテゴリーを使うので、判断は部屋ではなく、指名された承認者に紐づきます。

どの判断が本人の担当なのかも、タスクに書いてください。「承認していただくのはワードマークのロックアップで、カラーパレットではありません」と書けば、レビューで最も多い脱線を防げます。誰も尋ねていない問いに、レビュー担当者が答えてしまうことです。

手順は短いものです。依頼を開き、Creative sign-offで承認をリクエストすると、その担当者に届きます。担当者は承認するか、変更をリクエストします。

どちらの場合も、答えは依頼に残ります。変更のリクエストは作業を1ラウンド前に戻すので、Review roundが1つ上がります。

1つの設定で、サインオフが本物のゲートになります。プロジェクトの設定の状態で、承認が保留中のあいだ完了をブロックするオプションをオンにします。すると、承認者が承認するまで、何もDeliveredに進めません。

複製した直後に変更しておくことが1つあります。サンプルのCreative sign-offには承認者が2人います。プロジェクトの設定で実際のレビュー担当者を設定し、1人に絞ってください。承認者が2人のデザインは、承認者がいないのと同じに戻ってしまうからです。

承認はPremium以上のQuireプランで利用できます。6ステージのパイプラインを支えるカスタムの状態は、Freeを含むすべてのプランに付いています。詳細は料金ページをご覧ください。

仕組みについては、それぞれ個別の記事があります。カスタムの状態で組み立てる承認フローと、専用の承認機能です。この記事は、その両方が前提にしている層、つまりそれらにつながるキューを扱っています。

重要なポイント

1つだけ持ち帰るなら、ラウンドカウンターを選んでください。3回目のラウンドに入ったデザインは、ほとんどの場合デザインの問題ではありません。描き直しに費やす1時間は、症状を治療するために使う1時間です。

タスク管理ソフトでラウンドを数えれば、証拠は自然に上流を指します。作り始めるには曖昧すぎた依頼です。あとはそこから続きます。

Design Pipelineテンプレートには、カウンター、受付リスト、6つの回答の依頼ドキュメントがすでに揃っています。次の一歩は小さなものです。いま依頼が届いているチャンネルに依頼ドキュメントを貼り付け、今週の依頼のうち6つすべてに答えられるものがいくつあるか確かめてみてください。

Quireに登録してパイプラインをコピーし、次のデザイン依頼を流してみましょう。

よくあるご質問

デザイン承認プロセスとは何ですか?

クリエイティブ作業が、誰かの依頼から、指名された担当者のサインオフに至るまでの道筋です。多くのチームは途中だけを持ち、両端がありません。QuireのDesign Pipelineテンプレートはその両方を備えています。先頭には依頼ドキュメント、末尾には記録される承認があります。

デザイン依頼がバラバラなメッセージで届くのを防ぐには?

もっと良い場所を用意し、そちらを速いルートにします。テンプレートには、依頼に必要な6つの回答をまとめた依頼ドキュメントと、新しい依頼が状態「Requested」で入る受付サブリストが付いています。

デザインの修正は何ラウンドが普通ですか?

1回は普通、2回も問題ありません。3回になるなら、多くは作業ではなくブリーフが間違っています。Review roundフィールドが、それを感覚ではなく並べ替えられる列にします。

デザインは誰が承認するべきですか?

1つの判断につき、指名された1人で、どの判断が自分の担当かを把握している人です。Quireの承認カテゴリーは、判断をチャンネルではなく1人の担当者に紐づけます。

社外のクライアントはQuireでデザインをどうレビューしますか?

見るだけのクライアントは、サインアップ不要の共有リンクを開きます。ご希望なら1つのサブリストに範囲を絞れます。決める立場のクライアントは、指名された承認者としてプロジェクトに参加するので、サインオフは依頼に記録されます。

タスク管理ソフトでデザイン承認プロセスを運用できますか?

はい。Quireでは、各依頼がタスク、各ステージが状態、サインオフがタスク上の承認になるので、キュー、ラウンド数、判断が1つの記録に収まります。

きちんとしたデザイン承認プロセスは、チームの仕事の生産性をどう高めますか?

描き直しが減ります。QuireでReview roundを数えると、3回目が集中している場所が分かります。そのブリーフを直せば、同じ作業に二重に支払うことがなくなり、描き直しに消えていた時間がデザイナーに戻ります。