client-revisions

クライアントの修正

モーション制作で修正ラウンドとスコープの拡大を管理します。修正の定義、SOWでのラウンド数の上限、適切なフィードバックの集め方、曖昧なコメントを実行可能な変更に置き換える方法、スコープ外の作業を変更依頼として丁寧に断る方法を紹介します。

使用する場面

フィードバックが増えているとき、クライアントが「ちょっとした調整」を次々に追加するとき、SOWに修正に関する文言が必要なとき、曖昧なコメント（「もっと目立たせて」など）をファイルに手を加える前に解読したいとき、または依頼が明らかに新しい作業に該当し、変更依頼として返信する必要があるときに使用します。

意思決定ツリー — ファイルに手を加える前に、すべてのコメントを分類する

このスキルの要点は、コメントごとに「これは修正か、新しい依頼か、それとも単に曖昧なのか」を判断することです。プロジェクトを開く前に、それぞれのコメントをこの手順で確認します。

A note arrives.
├─ Is it vague ("make it pop", "feels off")?
│   └─ YES → translate to a decidable choice + ask for a timestamp.
│            Do NOT act yet. Re-classify once it's concrete.
└─ Is it concrete?
    ├─ Does it change something ALREADY approved in brief/board?
    │   (timing, palette colour, approved-copy edit, a fix)
    │   └─ YES → REVISION. Counts against the round cap. Do it.
    └─ Is it anything NOT in the approved brief/board?
        (new scene, +runtime, new concept, new ratio, new asset,
         reversing an approved decision, "let's also try…")
        └─ YES → NEW REQUEST. Send the change-order email. Quote it.
                 Do NOT silently absorb it.

Is feedback scattered across people/messages?
└─ YES → STOP. Send the consolidated-feedback request first; one
         document, all stakeholders, conflicts resolved by the client.

判断基準：コメントが修正なのか新しい依頼なのか判断できない場合は、「これはすでに決定され、承認されていましたか？」と尋ねます。はいの場合は修正です。何かを追加、置換、または覆す場合は、新しい依頼です。

中心となる区別：修正と新しい依頼

この一文をSOWとフィードバック依頼に記載すれば、ほとんどの行き違いを防げます。

• 修正 = 承認済みのブリーフ／ボードにすでに記載されている内容の変更（タイミングの調整、パレット内の色の変更、承認済みの単語の差し替え、不具合の修正など）。
• 新しい依頼 = 承認済みのブリーフ／ボードに記載されていない内容（新しいシーン、再生時間の追加、新しいコンセプト、異なるアスペクト比、これまで提供されていないロゴ、「これも試してみましょう」など）。

修正は上限まで含まれます。新しい依頼は変更依頼として、別途見積もりとスケジュールを提示します。異議が生じてからではなく、第1ラウンドの前に伝えてください。

SOWの修正回数上限に関する文言

契約書／見積書に以下を挿入します。

REVISIONS
This project includes [2] rounds of revisions. A "round" is one
consolidated set of feedback, collected from all stakeholders and
delivered in a single document, then addressed in full.

Included (a revision): changes to elements already approved in the
brief and storyboard — timing, pacing, colours from the agreed
palette, approved copy edits, and fixes.

Not included (a new request / change order): new scenes, added
runtime, new concepts or directions, additional formats or aspect
ratios, new assets not previously supplied, or feedback that
reverses a previously approved decision.

New requests are quoted as a change order before work proceeds and
may affect the timeline. Additional revision rounds beyond those
included are billed at [day rate]. Feedback split across multiple
messages may be treated as separate rounds.

フィードバックが届いたときのワークフロー

1. 作業を止めます。 まだプロジェクトファイルを開かないでください。
2. 一元化します。 フィードバックが分散している、または人ごとに送られている場合は、フィードバック集約依頼（以下参照）を送ります。関係者全員の意見を1つの文書にまとめ、重複や矛盾を整理します。
3. 各コメントを分類します。 上記の区別に従って、修正か新しい依頼かを判断します。
4. 曖昧なコメントを具体化します。 実行する前に、的を絞った質問に置き換えます（以下の翻訳例を参照）。
5. 新しい依頼には変更依頼メールを送ります。 黙って引き受けないでください。
6. ラウンドを記録します。 上限が双方にわかるよう、現在のラウンド数を記録します。

フィードバック集約依頼のテンプレート

Subject: Feedback on [project] — Round [N]

Hi [name],

Ready for your notes on V[n]. To turn these around fast and cleanly,
could you send everything in one go:

• Gather feedback from everyone who needs to weigh in and merge it
  into a single list (if two notes conflict, tell me which wins).
• Use timestamps where you can — "at 0:08 the logo feels slow."
• Tell me the problem, not the fix — "the intro drags" is more useful
  than "make it faster," because it lets me solve it properly.
• Flag any must-have vs nice-to-have.

Send it all together and I'll address the full set in this round.
Notes that arrive after, or in separate messages, may roll into the
next round. Thanks!

曖昧なフィードバックの翻訳例

曖昧なコメントにそのまま対応してはいけません。まず、的を絞った質問に置き換えます。

クライアントのコメント	確認する質問
「もっと目立たせて」	「彩度を上げる、テンポを速くする、スケールの変化を大きくする、サウンドを強める、のどれでしょうか？すでに目立っている箇所を秒数で指定してください。」
「何かしっくりこない」	「テンポ、色、書体、メッセージのどれでしょうか？特に違和感がある2秒間を教えてください。」
「もっと高級感を出して」	「イージングをゆっくりにする、余白を増やす、色を抑える、書体を洗練させる、のどれでしょうか？」
「もっと動きを出せますか？」	「カメラの動きを増やす、カットを速くする、動かす要素を増やす、のどれでしょうか？」
「あまり気に入っていません」	「具体的にどの部分でしょうか？また、『気に入った』状態とはどのようなものでしょうか？参考例があると助かります。」
「もっと大きく／力強くして」	「サイズを大きくする、書体を太くする、コントラストを上げる、画面に表示する時間を延ばす、のどれでしょうか？」
「何かが足りない」	「シーン、メッセージ、ブランド要素、勢いのどれでしょうか？タイムライン上の位置も教えてください。」
「もっとインパクトを出せますか？」	「テンポ、色、サウンドのどれでしょうか？求めるエネルギー感がすでに表れている箇所を示してください。」

ルール：あらゆる感覚的な表現を、具体的で判断可能な選択肢に置き換え、タイムスタンプを尋ねます。

スコープ外の作業／変更依頼メールのテンプレート

Subject: [project] — quick note on the new request

Hi [name],

Happy to help with [the new request] — flagging that it sits outside
the approved brief/storyboard, so it's a change rather than a revision
under our current scope.

Here's what it takes:
  • Work: [what's involved]
  • Cost: [amount / day estimate]
  • Timeline impact: [+X days / new delivery date]

If you'd like to go ahead, reply "approved" and I'll add it and update
the schedule. If you'd rather keep to the original scope and budget,
no problem — we'll proceed as planned and can revisit this later.

Either way works for me; just let me know which you prefer.

トーンに関する注意：協力的な姿勢を保ち、非難するような言い方は避けます。進めるか、保留にするかを選べるようにし、金額を提示して、スケジュールへの影響を伝えます。目的は「できません」と言うことではなく、トレードオフを明確にすることです。

実例

良い例 — 曖昧なメモを明確にしてから、的確に対応する：

クライアント：「イントロに違和感があります。」→ あなた：「テンポ、色、メッセージのどれでしょうか。また、特に気になるのはどの2秒間ですか？」→ クライアント：「ロゴが出るまでの最初の3秒が長く感じます。」→ あなたはロゴの登場タイミングを調整し（範囲内の修正です）、第1ラウンドとして記録します。質問ひとつで、感覚的な意見が具体的で範囲内の修正になりました。

アンチパターン — 範囲の拡大を黙って引き受ける：

クライアント：「気に入りました！正方形版も作って、短いエンディングシーンも追加できますか？」→ あなたは黙って両方を作り、余分に2日を費やした結果、プロジェクトは遅延し、利益も出なくなります。

うまくいかない理由：新しいアスペクト比と新しいシーンはどちらも「新たな依頼」であり、修正ではありません。それなのに変更依頼書なしで引き受けると、クライアントに作業範囲の拡大は無料だと思わせ、前例を作り、利益を失うことになります。解決策：変更依頼のメールを返信し、費用とスケジュールへの影響を提示して、クライアントに選んでもらいましょう。「もちろん対応できます。必要な作業はこちらです」と伝えるのは、断ることではありません。

よくある間違い

症状	原因	対処法
修正がいつまでも続き、「最終版」にならない	上限を定めていない、または上限を提示していない	第1ラウンドの前にSOWで上限を明記し、N+1ラウンドでその上限を提示します
指示が食い違い、やり直しが繰り返される	個人ごとのフィードバックに対応した	統合したドキュメントを1つ提出してもらい、クライアント側で意見の食い違いを解消してもらいます
「ちょっとした調整」で利益がなくなる	新たな依頼を修正として受け入れた	すべての指摘を分類し、新たな作業には費用を明記した変更依頼を出します
「もっと目立たせて」に対応したのに、まだ違う	曖昧な指摘を文字どおりに実行した	ファイルに手を加える前に、判断可能な選択肢とタイムスタンプに置き換えます
承認済みのシーンを作り直す	承認の段階で確定していなかった	各段階を書面で確定し、確定済みの段階を再開する場合は新たな依頼として扱います
フィードバックが何日も小出しに届く	提出期限をひとつに定めていない	1ラウンドにつきドキュメントは1つとし、後から届いた指摘は次のラウンドに回します
クライアントが細かく請求されていると感じる	変更依頼を「できません」と伝えている	拒否ではなく、選べるトレードオフ（進めるか、保留するか）として提示します

成果物の仕様 — 適切な修正対応で作成するもの

成果物はファイルではなく、メールや契約書の文言です。適切な対応では、次の状態を実現します。

• 作業開始前に、SOWで「ラウンド」を定義し、ラウンド数の上限を定め、修正と新たな依頼を区別します。
• 各ラウンドのフィードバックをひとつの統合ドキュメントにまとめ、ラウンド番号とともに記録します。
• 曖昧な指摘は、実行前にタイムスタンプ付きの判断可能な質問に置き換えます。
• 新たな依頼には、作業内容、費用、スケジュールへの影響を記載した変更依頼メールを送り、黙って引き受けることはありません。
• すべてのメールで選択肢とトレードオフを示し、協力的な姿勢を保ちます。

完了前のチェックリスト

• SOWにラウンド数、「ラウンド」の定義、修正と新たな依頼の区別が記載されています。
• フィードバックが統合されています（関係者全員の意見を1つのドキュメントにまとめ、意見の食い違いを解消済み）。
• すべての指摘が分類されています：修正／新たな依頼／要確認の曖昧な指摘。
• 曖昧な指摘を、限定された選択肢と指定を求めるタイムスタンプに置き換えています。
• 新たな依頼を、費用とスケジュールへの影響を記載した変更依頼として送っています。
• 現在のラウンド番号が記録され、双方から確認できます。
• 承認の段階を書面で確定し、再開は新たな作業として明示しています。
• クライアントへのメールすべてに選択肢があり、非難するような口調を避けています。

クイックリファレンス

状況	対応
個人ごとにフィードバックが小出しに届く	フィードバックの統合を依頼し、ラウンドをやり直します
「もっと目立たせて」	具体的な選択肢に置き換え、タイムスタンプを尋ねます
クライアントが第4ラウンドを依頼する	SOWの上限を提示し、日単価で追加ラウンドの見積もりを出します
「新しいシーンをひとつだけ追加して」	変更依頼メールを送ります。新たな作業です
承認済みの決定を覆す	修正ではなく、新たな依頼です
新しいアスペクト比が後から追加される	変更依頼を出します。形式が別なら、成果物も別です
関係者2人の意見が食い違う	作業開始前に、採用する指摘をクライアントに選んでもらいます

参考ファイル

• references/sow-clauses.md — SOW の改訂セクション全文、承認ゲートの文言、「ラウンド」の定義の各バリエーション。
• references/email-templates.md — フィードバックの集約、変更依頼、追加ラウンド、承認停滞に関するメールテンプレート。
• references/feedback-translator.md — 曖昧なフィードバックから具体的なフィードバックへの変換表を拡充したものと、クライアント向けの「解決策ではなく問題を伝える」ためのアドバイス。