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

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

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

それが依頼者6人分になると、キューはもうキューではありません。それぞれが「自分の件が次だ」と信じている、個別の口約束の集まりになります。

デザイン承認プロセスは、繰り返しにも耐えなければなりません。契約書へのサインは一度きりですが、同じアートワークは3〜4回判断され、しかも判断する人がそれぞれ違うバージョンを見ています。

プロセスが壊れるのは、誰も仕組み化していない2か所です。依頼がどう届くか、そして1回目と4回目のレビューの間に何が起きるか。

デザイン承認プロセスとは？

デザイン承認プロセスは、Requested、In Design、Internal Review、Awaiting Approval、Changes Requested、Deliveredの6つのステージで進みます。依頼は書面のブリーフと日付の理由を添えて入り、修正のたびにラウンド数が1つ増え、最終的なOKは指名された1人からの承認として依頼上に記録されます。

ほとんどのチームは、この両端を飛ばしています。

デザイン承認プロセスはなぜデザイン開始前に壊れるのか？

壊れるのは受付の段階です。メッセージで届いた依頼には状態がないため、それが属するキューが見えません。 メッセージは「待機中」にも「受付済み」にも「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つは作業がどこにあるかを追跡します。判断はタスク上の承認として別に記録されます。この2つを分けておくことが、コツのほとんどです。

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行に凝縮されています。

採用ポスターのWhy this dateには「キャリアフェアが8月16日」とあります。その1週間前が期限のパートナー共同ブランドキットには「パートナーのローンチ日は未定」。同じキュー、同じフィールドで、締め切りと言えるのは片方だけです。

この行を実現しているのは次の要素です。

• 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承認カテゴリーは設定済みなので、完成した作業は指名された人に届き、記録付きのOKか修正リストが返ってきます。
• 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日あるなら、たいてい誰かが判断を避けています。

どこを見るべきかは、1つの区別で決まります。

Awaiting Approvalステージはチーム共有のキューで、並べ替えができ、月曜日に確認するのはこちらです。

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

すでにアートワークにピンを打てる専用ツールでファイルを校正していますか？　書き込み用にはそのツールを使い続け、校正リンクを依頼に貼り付けましょう。キュー、ラウンド数、サインオフはタスク上に残り、チーム全員が見られます。

社外のレビュアーは、デザインそのものよりアカウント作成でつまずきがちです。見るだけのクライアントは、アカウントなしでリンクを開けます。必要なら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: Request changesと表示されている2行のうちの1つです。

これはラウンド2にあり、2つの修正点を挙げたコメントが付いています。顧客の引用に役職が抜けていること、そして指標の数値が本文と一致しないことです。

さらにそのコメントは、1回目で承認済みの部分を守ると明言しています。この最後の部分は見た目以上に重要です。決着した判断を蒸し返すことこそ、2回目が5回目になる原因だからです。

クライアントワークでは、修正が自チームの外から届くため、この問題がさらに大きくなります。混乱のないエージェンシーのプロジェクト管理では、レビュアーがお金を払う側である場合のラウンド上限の設け方を解説しています。

誰がサインオフし、判断はどこに記録されるのか？

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

どの判断がその人の担当なのかも、タスク内に明記しましょう。「承認していただくのはロゴの組み合わせで、カラーパレットではありません」と書けば、レビューが脱線する最も多いパターン、つまり誰も聞いていない質問にレビュアーが答えてしまう事態を防げます。

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

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

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

複製したらすぐに変更すべき点が1つあります。サンプルのCreative sign-offには承認者が2人設定されています。プロジェクトの設定で実際のレビュアーを設定して1人に絞ってください。承認者が2人いるデザインは、また承認者がいない状態に戻ってしまうからです。

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

仕組みの詳細は、それぞれ別の記事で解説しています。カスタム状態で組む承認フローと、専用の承認機能です。この記事は、その両方が前提としている層、つまりそこへ流れ込むキューについての話です。

まとめ

ここから1つだけ持ち帰るなら、ラウンドカウンターにしてください。3回目のデザインがデザインの問題であることはほとんどなく、描き直しに費やす1時間はすべて、症状への対処に使われる1時間です。

タスク管理ソフトでラウンドを数えれば、証拠はおのずと上流を指し示します。作業の土台にするには曖昧すぎた依頼です。残りはそこから自然に整っていきます。

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

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

よくある質問

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

クリエイティブ作業が、誰かに依頼されてから指名された1人がサインオフするまでの道筋で、RequestedからDeliveredまでの6つのステージで進みます。QuireのDesign Pipelineテンプレートはステージを状態として備え、入口に依頼用ドキュメント、出口に記録付きの承認を用意しています。

デザイン依頼がバラバラなメッセージで届くのを止めるには？

もっと良い置き場所を用意し、そこを一番速い経路にします。テンプレートには、依頼に必要な6つの答えをまとめた依頼用ドキュメントと、新しい依頼が状態Requestedで入る受付サブリストが付いています。

デザインの修正は何回までが普通ですか？

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

デザイン作業は誰が承認するべきですか？

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

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

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

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

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

適切なデザイン承認プロセスは、チームの仕事の生産性をどう高めますか？

描き直しが減ります。Quireでレビューラウンドを数えると、3回目がどこに集中しているかがわかります。そのブリーフを直せば同じアートワークに二度お金を払うことがなくなり、描き直しに奪われていた時間がデザイナーに戻ってきます。