手戻りとは？意味・原因4類型と、顧客と進める案件で手戻りを減らす仕組み【2026】

この記事のポイント（TL;DR）

• 手戻りの意味・読み方・言い換え・英語・「出戻り」との違いは、記事末尾のFAQで短く全部答えます。用語だけ知りたい方は目次からFAQへ飛んでください。
• 前半では、手戻りが個人の段取りの問題ではなく構造の問題であることを、公表統計で確かめます。発注側であるユーザー企業自身の回答でも、2024年度にシステム開発の工期を「予定どおり完了」と言い切れたのは、最も小さい100人月未満の区分で3割台。規模が大きいほど、その割合はさらに下がります。
• 本題は、顧客と進める案件で起きる手戻りを4類型に分けることです。仕様の揮発、確認漏れ、最新版不明、そして顧客の宿題滞留。最後の1つは自社の努力では防げない種類の手戻りで、主要な解説記事では扱われていません。
• 「手戻りは損失だ」で終わらせず、1回いくらかを出す式を載せます。時間単価はJUASが公表している人月単価に接地しますが、式に入れる数値は仮定値です。読者ご自身の案件の数字に差し替えて使ってください。
• 打ち手は3つの仕組みに整理します。決めたことをどこに残すか、合意をどう辿れるようにするか、先方の確認状況をどこで見るか。キックオフの決定項目チェックリストと議事録の書式は別記事にあるため、本記事では重複させずリンクで送ります。
• 「手戻りをなくすと工数が何％減る」といった効果の数値は載せていません。理由は記事の最後に書きます。

---

手戻りとは｜意味と読み方

手戻りとは、いったん終わったはずの作業に問題や変更が見つかり、前の工程に戻ってやり直すことです。読み方は「てもどり」で、「でもどり」ではありません。製造業や建設業の現場で使われてきた言葉とされ、そこからソフトウェア開発、そして制作やコンサルティングを含む広い業務に広がりました。

「やり直し」との違いは、戻る距離にあります。手元で書き直す程度なら、ふつうは手戻りとは呼びません。設計に戻る、要件に戻る、企画に戻るというように、いま立っている工程より前まで巻き戻すことになったときに、この言葉が使われます。IT用語辞典 e-Words も「その工程内では解消が難しいような問題があり、一つ（あるいは、深刻な場合はいくつか）前の工程から改めて作業をやり直すこと」と説明しています。

出典: 株式会社インセプト「手戻り」IT用語辞典 e-Words。2026年9月6日に確認。

つまり手戻りは、作業の失敗を指す言葉ではありません。すでに完了と判断した工程の判断そのものが覆ったことを指します。ここが重要です。作業の質を上げても手戻りは減りません。減るのは、完了の判断が正しくなったときです。

どこからが手戻りなのか

線引きは案件ごとに違いますが、実務では次の3つを満たすと手戻りとして扱われることが多くなります。

1. 完了とみなして次の工程に進んでいた
2. その判断を覆す情報が、後から出てきた
3. 前の工程まで戻らないと直せない

3つ目が満たされない、つまり同じ工程の中で直せるものを、本記事では「差し戻し」と呼び分けます。手戻りは工程をまたぎ、差し戻しは工程の中で完結する、という整理です。細かい違いに見えますが、工程をまたぐかどうかで、かかる時間も、誰に説明が必要かも変わります。

なお、顧客と進める仕事の全体像や、その中で受託側が抱えやすい負荷の構造についてはクライアントワークとは何かを整理した記事にまとめています。本記事はその中の「手戻り」という一点を深掘りするものです。

---

手戻りは「起きて当然」になっている

手戻りは、個人の段取りの巧拙で説明できる現象ではありません。発注側の企業自身が、2024年度、100人月未満の区分でもシステム開発の工期を「予定どおり完了」と言い切れたのは3割にとどまると回答しています。

一般社団法人 日本情報システム・ユーザー協会（JUAS）の『企業IT動向調査2025』によると、2024年度のシステム開発プロジェクトのうち、工期が「予定どおり完了」したものの割合は次のとおりでした。

最も小さい規模区分（100人月未満。100人月弱までの案件を幅広く含みます）でも、「予定どおり完了」と言い切れたのは3件に1件です。規模が大きくなるほど比率は下がります。

ただし、残りがすべて遅延というわけではありません。100人月未満では52.4%が「ある程度は予定どおり完了」で、明確に「予定より遅延」に分類されたのは16.6%です。「予定どおり」と言い切れた案件が3件に1件だった、というのがこの数字の正確な意味です。

そして、この水準は10年前から改善していません。100人月未満の「予定どおり完了」は、10年の起点である2015年度が35.2%、2024年度が31.0%で、4.2ポイントの低下です。ただし単調に下がってきたわけではなく、2016年度・2019年度・2023年度は前年を上回っています。10年間で最も高かったのもこの2016年度（50.3%）でした。報告書はこの推移を「低下傾向」と表現しています。

10年間（15～24年度）の推移では、すべてのプロジェクト規模で「予定どおり完了」の割合が低下傾向にあり、２４年度においても改善の兆候は見られない

出典: 一般社団法人 日本情報システム・ユーザー協会『企業IT動向調査2025』（2025年4月10日） p.32-34。2026年9月6日に原典PDFを取得して確認。

この数字をどこまで自分の話として読めるか

先に限定を書きます。この調査はシステム開発についてのもので、制作やコンサルティングを含むクライアントワーク全般の数字ではありません。 調査対象は東証上場企業とそれに準じる企業（ユーザー企業）で、配布4,500件に対する回収は981社です（同資料 p.3）。ですから「クライアントワークは3件に2件が遅れる」と言い換えることはできません。

そのうえで、この数字が受託側にとって意味を持つ理由が2つあります。

1つは、回答しているのが発注側だということです。受託側が「顧客の都合で遅れた」と申告した数字ではありません。発注する立場の企業が、自社のプロジェクトについて予定どおりではなかったと答えています。遅延は受託側だけが感じている現象ではない、ということです。

もう1つは、QCDが崩れた理由として挙げられている項目が、システム開発に限らないことです。同じ調査では、品質が予定どおりにならなかった要因が次のように報告されています。

回答数は2024年度が169、2023年度が164、2022年度が160です。いずれも各年の合計が100%を大きく超えるため、複数回答形式と判断しています（発表資料には回答形式の明記がありません）。

出典: 同資料 p.34（品質未達要因およびQCD悪化トレンド）。2026年9月6日に原典PDFを取得して確認。

最も多く挙がっているのはベンダーと社員のスキル不足です。その2項目を除くと、想定以上の現行業務・システムの複雑さ（39.6%）に次いで、計画時の考慮不足（39.1%）と仕様変更の多発（27.2%）が並びます。作る力の不足と並んで、現行業務の把握と「何を作るかを決める段階」が挙がっている、というのが表の読み方です。

同じ調査のQCD悪化トレンドでも、同じ傾向が出ています。工期の悪化に影響しているトレンドとして、要件定義の難易度向上が51.0%で10項目中の最多、要件定義の時間不足が35.6%（工期についての回答数202。こちらも合計が100%を大きく超えるため複数回答形式と判断しています）で、いずれも短納期化の17.8%を大きく上回りました。納期が短いことより、決める段階が難しいことのほうが、工期悪化の理由として多く挙げられているということです。

本調査が測っているのはシステム開発ですが、何を作るかが決まりきらないまま着手し、後から決まって前に戻るという構造そのものは、Webサイトの制作でも、資料の作成でも、調査や分析の受託でも観察されます。ただしこれは筆者の実務上の見立てであり、他業種を測定したデータではありません。

「自分の段取りが悪いから」ではない

手戻りが続くと、多くの人は自分を責めます。確認が足りなかった、聞き方が悪かった、先に気づくべきだった。

その反省が無駄だとは言いません。ただ、システム開発でそうであるように、予定どおり終わるほうが少数派になりうる環境で、自責だけを積み上げても改善しません。必要なのは、自分の努力で減らせる手戻りと、仕組みでしか減らせない手戻りを分けることです。

そのために、まず手戻りを分類します。

---

顧客と進める案件で起きる手戻りの4類型

顧客と進める案件の手戻りは、原因の場所で4つに分けられます。仕様の揮発、確認漏れ、最新版不明、顧客の宿題滞留の4つです。前の3つは自社と顧客の双方に起点があり、4つ目だけは発注側に起点があります。

一般的な解説記事が挙げる原因は、仕様の曖昧さ、確認不足、情報の分散の3つに集約されます。この3つは正しいのですが、検索上位の解説記事を確認した範囲では、いずれも自社内の運用改善で片づく前提で書かれています。実際の案件では、自社の運用がどれだけ整っていても止まる種類の手戻りがあります。それが4つ目です。

分類する目的は、原因を知ることではありません。打ち手が類型ごとに違うからです。仕様の揮発にチェックリストは効きますが、顧客の宿題滞留にチェックリストは何の効果もありません。自分の案件でどの類型が起きているかを見誤ると、効かない対策を続けることになります。

類型1: 仕様の揮発

仕様の揮発とは、打ち合わせでは合意していたはずの内容が、時間が経つと双方の記憶からしか参照できなくなり、認識がずれていく状態を指します。現場で口にされるのは「打ち合わせでは決まっていたはずなのに」です。

起きかたには決まった形があります。会議で口頭では合意します。その場では全員が同じものを想像しています。ところが合意の内容が、書かれた場所を持ちません。チャットのどこかには残っているかもしれませんが、後から探せる形では残っていない。数週間後、成果物を出した時点で「そういう話ではなかった」となります。

揮発には3つの形があります。

1. 決めた内容が、そもそも曖昧だった。 「シンプルな構成で」「一般的な形で」。その場では合意できるが、シンプルの中身が双方で違う
2. 決めた内容は明確だったが、記録の粒度が粗かった。 「配色について確認」としか残っておらず、何がどう決まったのかが分からない
3. 決めた範囲が双方で違っていた。 こちらは全体の方針が決まったと思い、相手は一部の例について合意しただけだと思っている

3つとも、成果物を出した瞬間に初めて表面化します。途中で気づく手がかりが、どこにもないのが共通点です。

厄介なのは、双方とも嘘をついていないことです。原因は上の3つのどれかであって、どちらかの不誠実ではありません。「言った・言わない」の争いに発展することもありますが、この問題の掘り下げ方については議事録の書き方と顧客への合意の取り方に譲ります。

見分け方は、やり直しの原因になった決定事項を、いま3分以内に探し出せるかです。探せないなら、それは仕様の揮発です。

類型2: 確認漏れ

確認漏れとは、成果物を相手に見てもらったつもりでいたが、実際には見られていなかった、あるいは見た人に決定権がなかった状態を指します。現場で口にされるのは「見ていただいたと思っていました」です。

これは3つの形で起こります。

1. 送ったが開かれていない。 メールに添付した、チャットに貼った。相手は受け取ったが開いていない。こちらは「反応がないので問題なし」と解釈して進む
2. 開かれたが読まれていない。 ざっと見て問題ないと返事はもらったが、実際には詳細まで確認されていない。後から詳しい人が見て指摘が出る
3. 確認した人に決める権限がなかった。 窓口の担当者は了承したが、決裁の段階で覆る

3つとも共通するのは、こちらから見て「確認された」と「確認されていない」の区別がつかないことです。沈黙が肯定なのか未読なのかが判別できないまま進むため、後で覆ります。

見分け方は、やり直しの直前に「相手が本当に中身を見た証跡」があったかどうかです。返信のひとことしかない場合、それは確認漏れの候補です。

類型3: 最新版不明

最新版不明とは、作業そのものは正しく行われたのに、材料が古かったために成果物が使えなくなる状態を指します。現場で口にされるのは「その資料、古いほうを見ていました」です。

これは資料が複数の場所に散っている案件で起きやすくなります。メールの添付、チャットに貼られたファイル、共有ストレージのフォルダ、それぞれに似た名前のファイルがあり、どれが正なのかがファイル名でしか判別できない。「最終版」「最終版_修正」「最終版_修正2」という命名は、この問題の症状です。

この類型は、当事者に落ち度がない点で特に消耗します。 指示どおりに作業し、渡された材料を使ったのに、成果物が無駄になる。しかもやり直しの工数は、たいてい自社が被ります。

起きやすいのは、次の3つの場面です。

1. 顧客から複数回に分けて材料が届く。 2回目の送付が1回目の差し替えなのか追加なのかが、本文に書かれていない
2. 社内で誰かが加工した中間ファイルが流通する。 元データより加工済みのほうが手元にあるため、そちらを正だと思って使う
3. 決定が変わったのに、材料が差し替わっていない。 方針の変更は共有されたが、それに合わせた資料の更新が追いついていない

3つ目がとくに厄介です。決定と材料が別々の場所にあると、片方だけが更新されます。 決定事項の置き場所を1つにする話は後述しますが（「仕組み①」）、材料についても同じことが必要になります。

見分け方は、渡された材料が最新かどうかを、作業者が自分で判断できたかです。判断できない状態で渡されているなら、それは個人の不注意ではなく置き場所の問題です。

類型4: 顧客の宿題滞留

顧客の宿題滞留とは、こちらの作業が顧客側の未提出物や未回答で止まっているにもかかわらず、全体の納期は動かないまま時間だけが過ぎ、後になって圧縮された期間でやり直しが発生する状態を指します。現場で口にされるのは「素材待ちで止まっているのに、納期だけ動かない」です。

検索上位の解説記事を確認した範囲では、この類型を扱ったものはありませんでした。 手戻りの解説はたいてい、測定精度を上げる、チェックリストを整える、レビューを早める、ツールを導入するといった対策を並べますが、それらはすべて自社内で完結する改善です。顧客側の作業が返ってこないことに対しては、何の効果もありません。

起きかたはこうです。原稿、素材、データ、あるいは仕様の判断。顧客側が用意することになっている宿題があります。期日を過ぎても返ってきません。催促はしますが、相手にも事情があり、強く言えません。2週間遅れて素材が届いたとき、納期は動いていません。残った期間で作ることになり、確認の回数が減り、その結果として手戻りが起きます。

根本の原因は、待ちが発生したときに全体の予定を組み直さなかったことです。この類型が他の3つと見分けにくい理由は、後の「類型を取り違えると、効かない対策を続けることになる」で扱います。

見分け方は、やり直しになった作業の直前に、自社起因ではない待ち時間があったかどうかです。待ちがあったなら、それは類型4です。

なぜ「待たされています」と言えないのか

類型4が放置されやすい理由は、受託側から言い出しにくいからです。

言えない理由は、たいてい次のどれかです。相手も忙しいことを知っている。関係を悪くしたくない。継続の話が出ている時期で強く言えない。そして、言ったところで納期が動くとは限らないと分かっている。

もう1つ、見落とされやすい事情があります。待ちが発生している時点では、まだ問題が起きていないのです。素材が届けば間に合うかもしれない。だから「いまは様子を見よう」となります。問題が顕在化するのは、圧縮された期間で作った成果物にやり直しが出たときで、そのときには待ちの話は過去のものになっています。

だから、待ちが起きたその場で予定を組み直す取り決めを、着手前に置いておく必要があります。その場で個別に交渉すると、上に挙げた理由がすべて働いて、たいてい言い出せません。

なお、待ちの発生そのものが受託側の構造的な負荷であることは、クライアントワークの構造を扱った記事で契約や法令の観点も含めて扱っています。

自分の案件はどの類型か

分類は、直近3件の案件で数えるのが最も早い方法です。記憶が新しく、事実として確認できるためです。

数え方は次のとおりです。直近3件の案件それぞれについて、やり直しになった作業を思い出せるだけ挙げます。1件ずつ、判別の質問に答えて類型を割り当てます。同じ作業に複数の類型が当てはまる場合は、最も早い段階で起きたものを主原因とします。

集計すると、たいていどれか1つか2つに偏ります。偏った先が、いま手を入れるべき場所です。全部に対策を打とうとすると、どれも中途半端になります。

類型を取り違えると、効かない対策を続けることになる

分類が必要な理由は、対策の多くが特定の類型にしか効かないからです。一般的な手戻り対策として挙げられる施策を、類型に照らすと次のようになります。

表の下2行に注目してください。進捗の可視化と催促の頻度は、どの類型にも根本的には効きません。 それでも最初に手をつけられがちな施策です。効果が出ないまま続けると、「対策はしているのに減らない」という状態になります。

もう1つ気をつけたいのは、類型4の手戻りは表面上、類型1〜3の顔をして現れることです。待ちで圧縮された期間では、確認が省略され、決定が曖昧なまま進みます。結果として仕様の揮発や確認漏れとして観測されます。ここで類型1・2の対策を打つと、原因が残ったまま手順だけが増えます。

やり直しの直前に自社起因でない待ちがあったかを、必ず先に確認してください。 これが分類の順序として最初に来ます。

---

手戻り1回はいくらか｜工数を金額に換算する

手戻りのコストは、時間単価とやり直しの工数と発生回数を掛け合わせれば概算できます。多くの解説が「工数が増える」「人件費が膨らむ」と定性的に書くところを、ここでは自分の案件に当てはめられる式にします。

なぜ金額にするのか

理由は2つあります。

1つは、社内でも顧客に対しても、時間の話は通りにくく金額の話は通るからです。「確認に2日かかります」は交渉のカードになりませんが、「この確認を飛ばすと、平均してこれくらいの費用が後で発生します」は根拠のある主張になります。仕組みを整えるための時間を取るときにも、金額のほうが説明しやすくなります。

もう1つは、自分が受けている損失の大きさを、正しく見積もるためです。手戻りは1回あたりが小さく見えます。半日、1日。だから「まあこれくらいなら」と流してしまう。年間で積み上げると、無視できない規模になっていることが多いのですが、数えていないと気づけません。

ただし先に断っておきます。ここで出る金額は、精密な原価計算ではありません。 意思決定のために桁を把握するための概算です。

手戻り1回のコストは3つの変数で出る

手戻り1回のコスト ＝ 時間単価 × やり直し工数（時間） × 発生回数

3つの変数について、それぞれ何を入れるかを決めます。

時間単価。 自社の請求単価を使うのが最も正確です。分からない場合の目安は次節で扱います。

やり直し工数。 作り直しの時間だけを数えないでください。実際には、原因の確認、関係者への説明、作業のやり直し、再提出、再確認まで含みます。作り直しそのものが4時間でも、前後を含めると8時間になるケースは珍しくありません。

発生回数。 1つの案件で何回起きたかです。類型ごとに数えると、どの類型が金額として大きいかが分かります。

⚠️ 以下の例で使う数値はすべて仮定値です。 実際の単価も工数も案件ごとに違います。ご自身の数字に差し替えてください。

仮に時間単価6,000円、やり直し工数8時間、案件あたり発生回数3回とすると、

6,000円 × 8時間 × 3回 ＝ 144,000円

案件1件あたり14万4,000円。同種の案件を年に10件受けているなら、年間144万円が手戻りに消えている計算になります。桁を把握するには十分です。

時間単価をどこから取るか

自社の請求単価が分からない場合の参考として、公表されている統計があります。

JUASの『ソフトウェア・メトリクス調査2025【ガイドブック】』は、スクラッチ開発プロジェクトの工数区分別に外注コストの加重平均単価を公表しています。

報告書は「全体の加重平均単価は96万円であった」と記載しています。なお同資料ではパッケージ利用開発・SaaS利用開発の全体加重平均単価はいずれも144万円で、ここで使うスクラッチ開発はその中で最も低い区分です。単価表の99件がどの年次の内訳にあたるかは公表されていません（同資料は2025年単年145件と2018-2020年累積221件を扱っています）。

出典: 一般社団法人 日本情報システム・ユーザー協会『ソフトウェア・メトリクス調査2025【ガイドブック】』（2025年4月10日） p.3, p.23-25。2026年9月6日に原典PDFを取得して確認。

これを時間あたりに直すには、1人月が何時間かを決める必要があります。1人月＝160時間（1日8時間×20日）は本記事の仮定で、JUASの調査には含まれていません。 この仮定を置くと、全体平均の96万円は1時間あたり6,000円になります。前節の例で使った6,000円はこの数字です。自社の稼働日数・稼働時間が違う場合は、この160という数字から差し替えてください。

ここでも限定を書きます。 この単価はシステム開発の外注コストであり、制作やデザイン、コンサルティングの単価ではありません。標本も、全体で99件、10人月未満の区分にいたっては6件です。自社の単価が分からないときの当たりをつけるための参考値として使い、これを自社の相場だと考えないでください。

小さい案件ほど、1回が重い

上の表で目を引くのは、10人月未満の区分だけが185万円／人月と突出して高いことです。10人月以上の各区分が95万〜109万円で並ぶ中で、10人月未満だけが1.7〜1.9倍になっています。

報告書は、10人月を超えるプロジェクトでは規模による単価の差が小さかったと述べています。裏を返せば、小規模帯だけが別の価格帯にあるということです。

この事実は、直感と逆の示唆を与えます。「小さい案件だから、手戻りしても大したことはない」と考えがちですが、同じ8時間のやり直しでも、小規模案件のほうが金額として重い可能性があります。185万円／人月を、同じく160時間／人月の仮定で割ると、1時間あたり約11,563円。先ほどの計算式に入れると、

11,563円 × 8時間 × 3回 ＝ 277,512円

同じ手戻りの回数と工数でも、金額はおよそ2倍近くになります。しかも小規模案件は総工数が小さいため、同じやり直しが案件全体に占める比率も大きくなります。10人月の案件（同じ仮定で1,600時間）で24時間のやり直しが起きれば、それは全体の約1.5%にあたります。

繰り返しますが、この標本は6件です。この数字を根拠に「小規模案件の単価は185万円だ」と主張することはできません。ただし、小さい案件の手戻りを軽く見積もる習慣を疑う理由としては十分です。

式に入らない3つの隠れコスト

上の計算式は、やり直しの作業時間しか数えていません。実務では、式に入らないコストが3つあります。

1. 待ち時間。 やり直しが決まってから、何をどう直すかが確定するまでの空白です。原因を確認し、判断を仰ぎ、方針が決まるまでの間、手は止まっています。この時間は作業時間としては計上されませんが、納期は消費されます。

2. 切り替えコスト。 別の案件に移っていた作業者を、元の案件に戻す負荷です。前提を思い出し、資料を開き直し、どこまで進んでいたかを確認する。この立ち上がりの時間は、作業時間の見積もりにはまず含まれません。

3. 次回見積もりの安全率。 手戻りが続いた相手との案件では、次の見積もりに余裕を上乗せします。これは合理的な判断ですが、上乗せした分だけ価格競争力は落ちます。手戻りのコストは、その案件の中だけでなく、次の受注機会にも波及します。

3つとも金額に換算しにくいため、この記事では式に含めません。ただし、式で出た金額は下限であると理解しておいてください。

数えるときは、類型ごとに分ける

年間の合計だけを見ても、どこに手を入れるべきかは分かりません。数えるときは、類型ごとに分けてください。 たとえば年間の合計のうち類型4が6割を占めているなら、チェックリストの整備にどれだけ時間を使っても、その6割は残ります。

数えるには記録が要ります。 やり直しが起きたときに、原因の類型と、かかった時間を一行だけ残してください。3か月続ければ、自社の手戻りの構成が事実として見えます。推測で対策を選ぶ状態から抜けられます。

---

「手戻りが多い人」は、本当に個人の問題か

手戻りが多い状態は、本記事の立場では、その人の能力ではなく担当している案件の構造で説明できると考えます。同じ人が別の案件では手戻りを起こさないなら、原因は人ではありません。

「手戻りが多い人」という言葉は、検索でもよく調べられています。関連する解説の多くは、確認が甘い、先読みができない、質問が下手といった個人の資質に原因を求め、対策として先読み力や自己研鑽を挙げます。

その指摘が的外れだとは言いません。ただし、個人の努力で減らせる手戻りと、努力では減らせない手戻りは、はっきり分かれます。

表のとおり、個人の努力が効くのは上半分だけです。しかも「部分的に」です。自分がどれだけ丁寧に議事録を取っても、それが相手に届いて相手も同じものを見ていなければ、認識のずれは残ります。

ここを取り違えると、消耗します。効かない努力を続け、それでも手戻りが起きるので、さらに自分を責める。まず、いま起きている手戻りが上半分なのか下半分なのかを判別してください。 下半分なら、必要なのは努力ではなく取り決めです。

もう1つ付け加えると、「手戻りが多い人」の中には、難易度の高い案件を任されている人が一定数います。要件が固まっていない、関係者が多い、決裁者が遠い。そういう案件は構造的に手戻りが起きやすく、それを担当している人の手戻り件数は当然多くなります。件数だけを見て評価すると、難しい仕事を引き受けている人ほど低く見られることになります。

評価する立場で見るときの注意

チームの状況を把握する立場なら、手戻りの件数ではなく類型の内訳を見てください。

内訳を見ると、その人の問題なのか案件の問題なのかが分かれます。類型1と2に偏っているなら、確認の取り方に改善の余地があります。類型3と4に偏っているなら、その人がどれだけ努力しても減りません。置き場所の設計と、顧客との取り決めを変えないかぎり、担当者を替えても同じことが起こります。

件数だけで評価すると、もう1つ副作用があります。手戻りを報告しなくなることです。表に出ない手戻りは、記録に残らず、類型の集計もできなくなります。数え始めるときは、件数を評価に使わないことを先に伝えてください。

---

仕様変更・スコープの追加費用をどう扱うか

仕様変更による手戻りは、対応範囲の取り決めが曖昧なままだと、多くが受託側の負担になりがちです。防ぐには、追加費用が発生する線引きを、変更が起きる前に決めておく必要があります。

前掲のJUAS『企業IT動向調査2025』では、品質が予定どおりにならなかった要因として仕様変更の多発が27.2%（2024年度・回答数169・複数回答）を占めていました。仕様変更は手戻りの主要な引き金の1つです。

ただし、仕様変更そのものが悪いわけではありません。作りながら分かることはありますし、事業の前提が変わることもあります。問題になるのは、変更が「変更」として扱われないときです。

スコープクリープという現象

スコープクリープとは、正式な変更手続きを経ないまま、対応範囲が少しずつ広がっていく現象を指します。1つひとつは小さな依頼です。「ついでにこれも」「ちょっとだけ直して」。個別に断る理由がないため受けます。それが積み重なり、気づいたときには当初の想定を大きく超えています。

厄介なのは、どこで線を越えたかを後から特定できないことです。だから追加費用の話を切り出すタイミングを逃します。「いまさら言えない」となり、そのまま持ち出しで対応することになります。

線引きは、変更が起きる前にしか決められない

対応範囲の取り決めは、着手前に決めるものです。変更が起きてから決めようとすると、たいてい交渉になり、多くの場合は受託側が譲ります。

後述する3つの仕組みが機能する前提として、着手前に確定させておく点が3つあります。

1. 何が対応範囲外か。 ここが空白のまま進んだ案件では、追加の依頼が「変更」ではなく「当然の範囲」として届きます。列挙の作法はキックオフミーティングの進め方と決定項目に譲ります
2. どこからが追加の相談か。 修正の回数、作業量、あるいは影響する工程の数など、双方が事実として確認できる基準にします。「大幅な変更」のような主観的な表現は基準になりません
3. 誰が変更を依頼できるか。 窓口を1つにします。複数の担当者から個別に依頼が届く状態は、それ自体が手戻りの原因です

なお、業務内容や報酬を書面で明示することは、取引によっては法令上の義務でもあります。フリーランスとの取引における明示義務や、その運用状況の公表データについてはクライアントワークの契約と法令の整理で扱っています。

これらを実際にいつ・どう決めるかは、案件の立ち上がりの設計そのものです。

---

手戻りを減らす仕組み①｜決めたことと材料を、双方から見える1か所に置く

仕様の揮発（類型1）と最新版不明（類型3）に共通して効く仕組みは、決めたことを記録することではなく、決めたことと材料の正の在り処を、双方が同じ1か所で参照できる状態にすることです。記録するだけでは足りません。

多くの現場は、すでに記録しています。議事録は書いていますし、チャットにも残っています。それでも仕様の揮発は起きます。理由は3つです。

1. 記録が自社側にしかない。 顧客は自分のメモを持っており、内容が違う
2. 記録が探せない。 3か月前のどの会議で決めたかを思い出せないと、記録があっても参照できない
3. 記録に「決まったこと」と「話しただけのこと」が混ざっている。 どれが合意事項かが後から判別できない

何を残すかではなく、どこに残すか

決めるべき項目そのものは、キックオフミーティングの進め方と決定項目に一覧があります。ここでは重複させず、置き場所の条件だけを扱います。

置き場所が満たすべき条件は4つです。

1. 双方から見える。 自社だけが見える場所は、記録ではなく備忘録です
2. 後から検索できる。 案件名や語句で辿り着けること。時系列にしか並んでいないチャットは、この条件を満たしません
3. 決定と未決定が区別されている。 「これは決まった」「これはまだ」が形として分かれています
4. 1つしかない。 複数の場所に決定事項が散っていると、それ自体が類型3（最新版不明）を生みます

この4条件は、決定事項だけでなく材料の置き場所にもそのまま当てはまります。 決定と材料が別々の場所にあると片方だけが更新される、というのが類型3の3つ目の場面でした。決定事項を1か所に集めるときは、その決定が指している材料も同じ場所から辿れるようにしてください。

条件を満たす道具は複数あります。共有ドキュメント、案件ごとの共有ページ、専用のワークスペース。重要なのは道具の種類ではなく、上の4条件を満たしているかどうかです。

決定の粒度を上げる

置き場所を用意しても、書かれている内容が曖昧だと揮発します。

たとえば「デザインの方向性を確認」と書いてあっても、何が決まったのかは分かりません。次のように書き分けます。

右の列に共通するのは、何が決まっていないかも同時に書かれていることです。決まったことだけを書くと、書かれていない部分について「当然そうなると思っていた」が発生します。

粒度を上げるコストは、1行あたり十数秒です。手戻り1回の金額と比べれば、比較するまでもありません。

決定事項は、後から読む人が判断できる粒度で書く。 これは議事録の書き方の問題でもあるので、次の仕組みに続きます。

---

手戻りを減らす仕組み②｜合意を、後から辿れる形にする

確認漏れを防ぐ仕組みは、合意した事実そのものを、日付と主体つきで辿れる形にすることです。「送った」ではなく「相手が確認して合意した」までを、記録として残します。

議事録の具体的な書式、必須項目、テンプレート、そして認識の食い違いが起きたときの遡及手順は議事録の書き方と顧客への合意の取り方にまとめています。ここでは、手戻りを減らすという目的に絞って、3点だけ扱います。

1. 決定事項と未決事項を分ける

議事録を時系列の記録として書くと、決定事項が本文に埋もれます。埋もれた決定事項は、後から探せません。

決定事項、未決事項、宿題（誰がいつまでに何を）の3つを、本文とは別に切り出す。 これだけで、後から参照する速度が変わります。手戻りが起きたとき、原因になった決定を数分で特定できるかどうかは、この構造にかかっています。

宿題については、3つの要素を必ず揃えてください。誰が、いつまでに、何をです。どれか1つでも欠けると追跡できません。とくに「誰が」を自社と顧客の双方について書くことが重要です。顧客側の宿題が書かれていない議事録は、類型4が起きたときに、待ちがいつから発生していたかを示せません。

「先方でご確認いただく」ではなく「◯◯様に、9月20日までに、A案とB案のどちらで進めるかをご判断いただく」と書きます。前者は宿題に見えて、実は誰の宿題でもありません。

2. 送付ではなく合意で締める

議事録を送って終わりにすると、確認漏れは残ります。送付は一方通行だからです。

相手からの返答を、合意の記録として残す。 「相違ありません」の一言でも構いません。重要なのは、その返答がいつ誰から来たかが分かる形で残ることです。返答がない場合の扱い（たとえば「◯営業日以内にご連絡がなければ、この内容で進めます」）を最初に取り決めておくと、沈黙の解釈で揉めることがなくなります。

3. 決定の変更履歴を残す

一度決めたことが、途中で変わるのは当然です。問題は、変わったことが記録に残らないときです。

決定が変更されたら、前の決定を消さずに、いつ・何が・なぜ変わったかを追記します。消してしまうと、後から「そんな話は聞いていない」となったときに、経緯を示せません。変更の履歴は、責任追及のためではなく、次の判断のときに前提を思い出すためにあります。

---

手戻りを減らす仕組み③｜先方の確認状況を見えるようにし、待ちの扱いを先に決めておく

顧客の宿題滞留と確認漏れを構造的に減らすには、こちらから見て「相手がどこまで確認したか」が分かる状態をつくる必要があります。催促の頻度を上げても、この状態は得られません。

ここまでの2つは、自社の運用で実行できる仕組みでした。この3つ目だけは、顧客と共有する場所そのものを変える話になります。

沈黙の意味が分からない、という問題

資料を送ってから返事が来るまでの間、こちらには情報がありません。相手がまだ開いていないのか、開いたが判断に迷っているのか、社内で確認中なのか、そもそも届いていないのか。どれであっても、こちらから見える景色は「沈黙」で同じです。

だから催促のタイミングを誤ります。早すぎれば急かしていると受け取られ、遅すぎれば納期に響きます。そして待っている間、こちらの工程は止まったまま、納期だけが近づきます。これが類型4の入口です。

確認状況が見えると、何が変わるか

相手がどの資料をどこまで見たかが分かると、対応が変わります。

• まだ開かれていない場合 — 催促の内容が「ご確認ください」ではなく「届いていない可能性がありますので、念のため別の経路でもお送りします」になります。相手を急かす形にならず、こちらの落ち度の可能性を先に置けます
• 開かれたが返答がない場合 — 判断に迷っている可能性が高いので、選択肢を絞って提示し直します。「ご確認をお願いします」ではなく「A案とB案でしたら、納期の観点ではA案をおすすめします。ご判断が難しい点があればお聞かせください」のように、返しやすい形にします
• 一部だけ見られている場合 — 見られていない箇所に判断が必要な情報が含まれていないかを確認し、そこだけを抜き出して再提示します。全体をもう一度送り直すより、相手の負担が小さくなります

いずれも、沈黙を沈黙のまま扱わずに済むようになります。催促の回数を増やさずに、待ちの原因を特定できます。

待ちを、予定に反映する取り決め

確認状況が見えるだけでは、類型4は完全には解決しません。待ちが発生したときに、全体の予定を組み直す取り決めが必要です。

実務では次のように決めておきます。顧客側の宿題が期日から一定日数を超えて遅れた場合、その時点で残りの工程の日程を双方で再確認する。この取り決めがないと、遅れは自動的に受託側の作業期間の圧縮として吸収されます。

言い出しにくいと感じるかもしれません。だからこそ、着手前に「そういうときは一度相談する」と合意しておくことが効きます。着手前なら、双方にとって公平な取り決めとして受け入れられやすくなります。

既存ツールの組み合わせでも満たせるが、場所が分かれるほど崩れる

ここまでの条件を、既存のツールの組み合わせで満たすことはできます。共有ドキュメントで決定事項を管理し、ストレージで最新版を1つに保ち、メールやチャットで確認を取る。実際に多くの現場がそうしています。

ただし、場所が分かれるほど、類型3（最新版不明）のリスクは上がります。決定事項はドキュメント、資料はストレージ、やりとりはチャット、確認状況はどこにもない。この状態では、どこを見れば正解が分かるかが案件参加者ごとに違ってきます。

クライアントワークOS Terasuは、この4つを1つの案件ワークスペースにまとめる道具です。顧客と共有するページ、資料、決定事項、そして先方の確認状況が、案件ごとに同じ場所に並びます。決めたことがどこにあるかを探す往復と、沈黙の意味を推測する時間が減ります。

道具を変えなくても、置き場所の条件を満たせるなら、それで構いません。重要なのは条件のほうです。

---

4類型と打ち手の対応表

ここまでの内容を1枚にまとめます。自分の案件で起きている類型を特定したら、対応する行だけ実行してください。

表の右端の列で分かるとおり、類型4だけは自社の判断だけでは実行できません。着手前の合意が要ります。逆に言えば、着手前にこれを合意しておかないと、後から手当てする方法がほとんどありません。

---

それでも手戻りが起きたときの動き方

手戻りが起きたときに最初にすべきことは、謝ることでも原因を説明することでもなく、やり直しの範囲と期限を確定させることです。範囲が決まらないまま作業を始めると、二度目の手戻りが起きます。

着手前に確認する3点

1. どこまで戻るのか。 設計まで戻るのか、要件まで戻るのか。範囲を口頭で「直しておきます」と受けると、後から範囲が膨らみます
2. 判断が変わった理由は何か。 前提が変わったのか、伝わっていなかったのか、決裁で覆ったのか。理由によって、次に打つ手が変わります
3. 納期はどうなるのか。 やり直しの工数を、どこから捻出するのか。全体の納期を動かすのか、他の工程を圧縮するのか。ここを曖昧にしたまま作業に入ると、圧縮は自動的に自社が被ります

3つとも、作業を始める前に確認してください。作業を始めてしまうと、交渉の余地がなくなります。

確認は口頭でも構いませんが、内容は文字にして相手に返してください。その場で言いにくい場合でも、次のように事実の確認として書けば角が立ちません。

本日ご相談いただいた件、下記の理解で進めます。相違があればご指摘ください。 ・修正の範囲: トップページの構成のみ（下層ページは現行のまま） ・お戻しの期日: 9月25日 ・以降の工程: 元の予定から3営業日後ろ倒しとなります

この3行があるかないかで、次に「そういう話ではなかった」となったときの状況が変わります。やり直しの合意が、次のやり直しの火種にならないようにするのが目的です。

次の合意に変換する

手戻りは、そのまま損失として終わらせることもできますが、次の取り決めの材料にもなります。

やり直しが確定したタイミングで、同じことが起きないための取り決めを1つだけ提案します。1つだけ、というのが重要です。複数を一度に持ち出すと、相手には手続きの増加としか映りません。

たとえば類型2（確認漏れ）が原因だったなら、「今後は、こちらからお送りした資料について、◯営業日以内にご確認の返信をいただく形にさせてください」という1点です。手戻りが起きた直後は、相手にとってもその必要性が実感として理解されているタイミングです。この時期を逃すと、同じ提案は通りにくくなります。

記録として残す

やり直しの経緯は、決定事項の記録に残してください。何が原因で、どこまで戻り、どう決め直したか。

理由は2つあります。1つは、同じ議論を繰り返さないため。もう1つは、類型を数えるための材料になるためです。「自分の案件はどの類型か」で直近3件を数える話をしましたが、記録がないと数えられません。記録が積み上がって初めて、自社の手戻りがどの類型に偏っているかが事実として分かります。

---

効果の数値を書いていない理由

この記事には、「この方法で手戻りが◯％減る」という数値が出てきません。意図的に書いていません。

手戻りの発生率は、案件の性質、顧客の意思決定の速さ、契約の類型、関係者の数によって大きく変わります。特定の運用を導入した前後で何％減ったという数値を、条件を揃えずに提示すると、読者を誤らせます。

出せるのは、公表されている統計と、その統計がどういう母集団についてのものかまでです。それ以上の数値を出すなら、条件を揃えた比較が必要になりますが、本記事はそれを持っていません。持っていないものを推定で書くより、書かないほうが誠実だと判断しました。

金額換算の節で示した式も同じ理由で、読者ご自身の数値を入れるための道具として設計しています。式に入れた6,000円や8時間や3回は、すべて仮定値です。読者ご自身の案件では、どれも別の数字になります。

---

よくある質問（FAQ）

---

まとめ

手戻りは作業の質の問題ではなく、完了の判断が覆ったことです。だから作業の精度を上げても減らず、決め方と残し方を変えたときに減ります。

手戻りは個人の段取りだけで説明できる現象ではありません。JUASの『企業IT動向調査2025』では、100人月未満のシステム開発でも工期を「予定どおり完了」と答えたのは31.0%（回答数694）で、明確に「予定より遅延」としたのは16.6%です。10年の起点である2015年度（35.2%）と比べると4.2ポイントの低下で、報告書はこの推移を「低下傾向」と表現しています。この調査はシステム開発について発注側の企業に尋ねたものであり、クライアントワーク全般の数字ではありません。ただし工期悪化の理由として要件定義の難易度向上が51.0%（工期についての回答数202）で最上位に挙がっている点は、システム開発以外の受託業務を測ったデータではないものの、顧客と決めながら進める仕事に共通する構造として読む価値があります。

顧客と進める案件の手戻りは、4つに分けられます。仕様の揮発、確認漏れ、最新版不明、顧客の宿題滞留。前の3つは自社の運用改善が部分的に効きますが、4つ目は着手前の取り決めがないとほぼ手当てできません。

コストは、時間単価とやり直し工数と発生回数を掛けた式で概算できます。時間単価が分からない場合の参考として、JUASの『ソフトウェア・メトリクス調査2025』が公表するスクラッチ開発の加重平均単価96万円／人月（99件）があります。1人月＝160時間という本記事の仮定を置くと、1時間あたり6,000円です。ただしこれはシステム開発の外注コストであり、160時間という換算も、式に入れる数値も、すべて本記事の仮定です。

打ち手は3つです。決めたことを双方から見える1か所に置くこと、合意を日付と主体つきで辿れる形にすること、そして先方の確認状況が見える場所をつくり、待ちが出たら予定を組み直す取り決めを着手前に置くこと。決めるべき項目そのものはキックオフミーティングの進め方と決定項目に、議事録の書式と合意の取り方は議事録の書き方にまとめています。顧客と進める仕事そのものの構造はクライアントワークとはを参照してください。

手戻りが起きたら、謝る前に、どこまで戻るのか・理由は何か・納期はどうなるのかの3点を確定させてください。そして経緯を記録に残してください。記録が積み上がって初めて、自社の手戻りがどの類型に偏っているかが事実として分かります。