言われた通りに直したのに、なんでまた修正が来るんだろう。
そう思いながらメールを閉じた夜は、ありませんか？
まだ駆け出しの頃、私はたびたびこんな思いを抱いていました。
デザイン修正が、こんなに腹立つものだとは。。。
一度目に言われなかった箇所を、あとから「やっぱりここも」。
修正内容は「もっと派手に」だけ。
直しても直しても、返ってくるのは「なんか違う」。
こんなに直させる相手がおかしいのか。
それとも、文句を言わず直すのがプロなのか。
私はWeb制作を17年、2026年の今も続けています。
最初は、自分の手が遅いせいだと思っていました。
次に、相性の悪いクライアントに当たっただけだと。
でも、相手が変わっても同じことが起きる。
今だからわかるのですが、原因は作業スキルとは別の場所にありました。
腹立ちの正体を「誰が悪いか」から降ろして構造でほどくと、最後に残るのは、着手前に一人で、クライアントに何も課さずに書ける1行です。
- 言われた通りに作ったのに「なんか違う」になるのは、なぜか
- 腹が立つ相手は、自分なのか、クライアントなのか、別の何かか
- 着手前の1行で、要望を「作れるタスク」に変える手順
記事を書いている人
R（アール）
Web制作の現場で17年（現役進行中）。精密栄養カウンセラー。
個人開発をアプリ6本並行しながら、AIと「作る・届ける」を実験しています。
うまくいったことも、月収2,000円みたいな冴えない数字も、隠さず公開中。
教える人ではなく、少し先で転んで戻ってきた人として、あなたと同じ目線で現在地を観測していけたらと思います。
デザイン修正が腹立つ本当の理由：要望と指示は違う
真面目にやっているのに、なぜかズレていく。
デザイン修正が腹立つほど続くとき、悪者はどこにいるのでしょうか。
思い出してみてください。
仕様書のある案件で、言われた通りに作って大きく外れたことは、意外と少なくありませんか?
慣れと言われたらそうなのかもしれないけど、改善できるのであれば改善したい。
もし、そうできれば、自分だけではなく相手にとってもいいことだと思うから。
仕様書は、クライアントと現場が何往復も対話を重ねて、タスクまで落とし込んだ高解像度の言葉です。
一方、メールで届く「要望」は、まだタスクに落ちていない生の言葉。
同じ「言われた通り」でも、解像度がまったく違います。
そして要望は、「正解の指示」ではなく、クライアントの視座から見えた解決策の一つにすぎません。
誰の・何の問題を解決したいのかは、文面のどこにも書かれていない。
だから文面に忠実であるほど、背後の目的からズレていきます。
真面目さが裏目に出る構造です。
デザインの修正地獄とは？
デザインの修正地獄とは、修正依頼が何往復しても完成に近づかない状態のことです。
原因は作業スキルの不足よりも、まだタスクに落ちていない「要望」を「指示」として受け取ってしまう構造にあります。
背後の目的が確認されないまま作業が始まるため、直すたびにゴールが動きます。
ただ、私がこの解像度差に気づいたのは、失敗の山をひと通り積んだあとでした。
仕様書通りならまだマシだった：17年分の失敗談
偉そうに構造を語りましたが、私自身、同じ場所で何度も苛立ってきました。
メールの文面通りに作って失敗した経験なら、山ほどあります。
不思議だったのは、仕様書のある案件ではそこまで外れなかったこと。
仕様書での失敗は「書いてあった通りです」と言えたのに、メール要望での失敗は、全部自分のせいに感じた。
修正依頼のメールを開くのが嫌になった夜は、真面目に文面通りやった案件ほど多かった。
ところが、発注する側に回ると景色が変わりました。
今度は自分が、生の要望をそのまま投げて現場を往復させていたのです。
担当者との修正が終わったあとに、上長の追加指摘が入る。
あなたの案件でも、担当者の向こうに、別の視座の人がいませんか。
受発注のQ&Aでも「担当者のOKのあとに上司や別部署の指摘が入る」という証言は繰り返し出てきます。
担当者本人にも、全部は見えていない。
わがままというより、生の要望が生のまま届く構造がそうさせている。
人格の問題にすると、相手が変わっても同じことが起きます。
デザインだけの現象でもありません。システム開発の要件定義では「要求をそのまま実装しない」ことが原則とされ、IPAも上流工程の不備が手戻りを生むと指摘しています。隣の業界の常識が、デザインの現場ではまだ、コミュニケーション術や「修正◯回まで・超過は追加料金」という料金の問題として扱われています。
では、構造のせいだと分かったところで、次の案件から何をすればいいのか。
腹立つ夜を減らす手順：着手前の1行で要望をタスクに変える
修正のたびに、最初から回数制限を入れておけばよかったと思ったことはありませんか。
防衛策としては有効です。
ただ、回数を制限しても1回あたりのズレは減りません。
ズレの発生源は要望の解像度で、契約や料金はそこに触れないからです。
触れるべきは、発生源のほうです。
要望が届いたら、作り始める前に、1行だけ書き出してみてください。
「この要望は、誰の・何の問題を解決するために出てきたか」
埋まれば、それがタスクの輪郭です。
埋まらない空欄が出てきたら、そこが聞くべき箇所です。
「ヒアリング力を上げろ」と言われて困るのは、聞く量の問題というより、問いの向きが決まっていないから。
この1行が向きを決めてくれます。書き出す前に要望へ即答しない「保留」の技術も、あわせて効きます。
打ち合わせを増やす交渉も、修正依頼票も要りません。
立場が弱いままでも、今日の案件から一人で始められます。
空欄を埋める視座の切り替え3方向
埋まらない空欄は、視座を切り替えると埋まりはじめます。
私が使うのは3方向です。
- 発注担当者の上司: この成果物を、担当者は誰に見せて、何と説明するのか
- エンドユーザー: 画面の先で、誰が、どんな場面でこれを見るのか
- 予算を握る人: この発注は、何の数字を動かすために通ったのか
視座が変わると、作るものが変わり、提案の通し方も変わります。
「ご要望の通りにしました」の代わりに、「◯◯の課題のためと理解して、こう作りました」と言えるからです。
判断軸を広げるならデザインの判断軸を作る5つのビジネスフレームワーク、通す言葉の型は提案を言葉で通すロジカルシンキングの型へ。1行のあとの進め方は要望を正解に育てる4ステップ（手戻りをなくす方法）にまとめています。
実はこの1行、昔から言われる「視座を上げろ」という抽象的なアドバイスの、具体的な中身でもあります。
視座を上げるとはこういうこと
デザイン修正に腹が立つ本当の原因は、あなたの作業スキルにも、クライアントの人格にもありません。
まだタスクに落ちていない要望を、指示として受け取ってしまう構造にあります。
着手前の1行を書き出した瞬間から、要望はタスクに変わり始め、作るものと提案の通し方が変わります。
結局、見るべきなのはクライアントの良し悪しでも、自分のスキルの多寡でもありません。
届いた要望がどの解像度なのか。自分がどの視座で受け取っているのか。
毎案件、そこを観測することから始まります。
着手前の1行は、その観測を回すための道具です。
私はこの1行を書くようになってから、修正依頼が届いた瞬間の頭の動きが変わりました。
腹を立てる前に、翻訳が始まる。「これは誰の、何の問題だったか」を先に考えはじめてしまう。
次の案件で、着手前に1行、書き出してみませんか。
ただ、視座の切り替えは一人だと回しにくい作業でもあります。
私は視座の変換を補助輪つきで試せる Mangekyoを作って使っています。
状況を入れると役割・抽象度・思考法の3軸で視座を変換し、「通る次の一手」を骨子や想定問答まで出してくれます。
Mangekyo – 視点を増やすAIアプリ (思い込みの外側を、見てみる。)
ぜひ使ってみてください！
