手戻りとは？発生する原因と今日から実践できる防止策・削減方法

手戻りとは

手戻りとは、いったん終了した作業工程に立ち返り、やり直すことを指すビジネス用語です。読み方は「てもどり」です。

たとえば、制作した資料を提出したところ方向性の違いを指摘されて作り直す、設計が完了した後に仕様変更が発生して設計からやり直す、といった状況が手戻りにあたります。

手戻りが発生すると、すでに投入した工数が無駄になるだけでなく、やり直しのための工数が追加で必要になります。スケジュールは後ろ倒しになり、後工程にも影響が波及します。

手戻りの言い換え・類語

手戻りと近い意味で使われる言葉には、次のようなものがあります。

社外向けの文書では「手戻り」という表現が通じにくい場合があります。その際は「作業のやり直し」「工程の再実施」といった表現に言い換えると伝わりやすくなります。

手戻りが多いとはどういう状態か

「手戻りが多い」とは、やり直しが常態化している状態を指します。

個別の案件で一度やり直しが発生することは、どの組織にもあります。問題なのは、特定の担当者やチームで繰り返し発生している場合です。この状態は、個人の能力ではなく、仕事の進め方そのものに原因があります。

手戻りが多い組織には、次のような特徴が見られます。

• 作業が完了してから初めて関係者に見せる運用になっている

• 依頼時に完成イメージや判断基準が共有されていない

• 決裁者が最終段階まで内容を確認していない

• 過去の指摘内容が記録されておらず、同じ指摘が繰り返される

手戻りが与える影響

コストの増加

やり直しに要した工数は、そのまま人件費の増加となります。製造業では材料費も発生します。特に、外注費が発生する工程での手戻りは、直接的な追加コストにつながります。

納期遅延

手戻りによって後工程の開始が遅れます。各工程に余裕のないスケジュールでは、一度の手戻りが全体の納期に直結します。

品質低下

手戻りによって失われた時間を取り戻そうとすると、残りの工程を圧縮することになります。検証や確認にかける時間が削られ、結果として品質が下がります。手戻りを取り返そうとした結果、さらに大きな手戻りを招くという悪循環も起こります。

作業効率とモチベーションの低下

やり直しが繰り返されると、担当者は自分の仕事に意味を見出しにくくなります。「どうせやり直しになる」という前提が生まれると、初回の作業の質そのものが下がります。

手戻りが発生する原因

手戻りの原因は、個人の確認不足に見えることが多いものの、実際には仕事の進め方に起因する構造的な問題であることがほとんどです。ここでは主な原因を 5 つに分類します。

原因 1: 認識のズレ

依頼者が求めているものと、作業者が理解した内容が食い違っている状態です。手戻りの原因として最も多く見られます。

認識のズレが生じる典型的なパターンは次のとおりです。

抽象的な指示

「いい感じにまとめておいて」「ざっくりで構わない」といった指示は、受け手によって解釈が分かれます。依頼者の中には具体的なイメージがあっても、言語化されていなければ伝わりません。

完成イメージの不共有

最終的にどのような形になればよいのかが共有されていないと、作業者は自分なりの想定で進めます。提出時に初めて想定の違いが判明します。

前提情報の欠落

その資料が誰に向けたものか、何の判断材料になるのかといった背景が共有されていないと、作業者は適切な判断ができません。

用語の解釈違い

「概要」「たたき台」「ドラフト」といった言葉が、組織や個人によって異なる水準を指している場合があります。

チーム間の認識のずれを構造的に防ぐ方法については、ワークフローの重要性と作成ステップで解説しています。

原因 2: 要件定義・仕様の不備

作業を開始する時点で、何を作るかが固まっていない状態です。

システム開発における要件定義の不足が典型ですが、資料作成や企画立案でも同様の問題が起こります。設計段階で決めるべきことが未確定のまま後工程に進むと、後になって決定事項が覆り、それまでの作業が無駄になります。

要件が固まらない背景には、次のような事情があります。

• 決裁者がこの段階では関与しておらず、方針が確定していない

• 関係部署への確認が済んでいない

• 前例がなく、何を決めるべきかが整理されていない

• スケジュールが逼迫しており、要件定義に時間を割けていない

要件定義にかける時間を削ると、後工程での手戻りという形でコストが跳ね返ります。上流工程での 1 時間の確認が、下流工程での 10 時間のやり直しを防ぐという関係にあります。

プロジェクト単位で作業範囲を定義し管理する進め方は、スコープマネジメントの目的とプロセスで詳しく解説しています。

原因 3: レビュー・承認のタイミングが遅い

成果物が完成してから初めてレビューを受ける運用では、方向性の誤りが最終段階で発覚します。

方向性に関する指摘は、作業の初期であれば小さな修正で済みます。完成後では、構成そのものを組み直すことになり、作業の大部分が無駄になります。

このパターンの問題は、作業者が完成度を上げてから見せようとする心理にもあります。中途半端な状態を見せたくないという意識が、結果として手戻りの規模を大きくします。

また、決裁者が最終承認の段階で初めて内容を見る体制では、根本的な指摘がそこで出ます。承認フローの設計自体が手戻りを生んでいる場合があります。

原因 4: 情報の分散と属人化

必要な情報が複数の場所に散在している、あるいは特定の個人しか把握していない状態です。

依頼内容がチャットにあり、参考資料はメールの添付ファイルにあり、過去の経緯は担当者の記憶の中にある、という状況では、作業者が必要な情報にたどり着けません。情報が欠けたまま作業を進めた結果、後から前提の誤りが判明します。

過去に同じ指摘を受けていても、その記録が残っていなければ、別の担当者が同じ誤りを繰り返します。

業務が特定の担当者に依存している状態については、属人化の原因とリスク、解消方法で解説しています。

原因 5: 仕様変更

外部要因や方針転換によって、作業の途中で要件が変わる状態です。

市場環境の変化や経営判断による仕様変更は、ある程度避けられません。問題となるのは、変更そのものではなく、変更が関係者に伝わらないこと、そして変更の影響範囲が把握されていないことです。

仕様変更の情報が一部の関係者にしか共有されず、古い仕様のまま作業を続けた担当者の成果物が無駄になる、というケースが頻繁に発生します。

また、変更が積み重なって当初の作業範囲を超えていく現象については、スコープクリープの原因と対策で扱っています。

手戻りの原因を特定するチェックリスト

自組織で手戻りが発生している場合、どこに原因があるかを確認するためのチェックリストです。

依頼・指示の段階 - 依頼時に、完成イメージまたは参考となる類似の成果物を示しているか - 成果物の用途と読み手を伝えているか - 判断に迷った場合の確認先を明示しているか - 必須の要件と、任意の要素を区別して伝えているか

要件定義の段階 - 作業開始前に、決定すべき事項がすべて確定しているか - 未確定の事項がある場合、それを作業者が把握しているか - 関係部署への確認が完了しているか - 決裁者が方針を承認しているか

作業・レビューの段階 - 完成前の段階でレビューを受ける機会があるか - レビューの実施時期が、着手前に決まっているか - レビュー担当者と、確認すべき観点が明確か - 決裁者が早い段階で内容を確認しているか

情報共有の段階 - 依頼内容と関連資料が一か所にまとまっているか - 過去の指摘内容が記録され、参照できる状態にあるか - 仕様変更が発生した際、関係者全員に伝わる仕組みがあるか - 作業の進捗が関係者から見える状態にあるか

該当しない項目が多いほど、その段階に手戻りの原因が存在する可能性が高くなります。

手戻りの原因は仕事の進め方にあります

依頼内容、完了条件、進捗、やり取りの履歴を 1 か所にまとめることで、認識のズレによる手戻りを減らせます。

デモを見る

手戻りを防止する方法

ここでは、依頼する側と作業する側のそれぞれが実践できる方法を示します。組織の仕組みを変えなくても、明日から着手できる内容です。

依頼する側の防止策

完了条件を明示する

何をもって完成とするかを、依頼の時点で言語化します。

「資料を作っておいて」ではなく、「経営会議で使う 10 分説明用の資料。意思決定に必要な数値の比較と、推奨案の提示を含める。A4 で 5 枚程度」と伝えます。

完了条件が明確であれば、作業者は自分で進捗を判断でき、方向性を外しにくくなります。

口頭やチャットで伝えた完了条件は、作業の途中で参照できません。タスクの説明欄に完了条件を記載しておけば、作業者はいつでも確認でき、認識のズレに気づいた時点で修正できます。Asana では、タスクごとに完了条件や判断基準を記載し、担当者と期日とあわせて 1 か所で管理できます。

参考となる前例を示す

過去の類似案件の成果物を示すことが、最も確実に認識を揃える方法です。

言葉での説明には限界があります。実物を 1 つ示すだけで、構成、分量、粒度、表現の水準が一度に伝わります。

判断基準を伝える

作業中に判断が必要になる場面を想定し、その判断軸を事前に共有します。

「情報量と読みやすさで迷った場合は読みやすさを優先する」「迷ったら詳しく書くのではなく、補足資料に回す」といった基準があれば、作業者は都度確認せずに進められます。

未確定の事項を明示する

すべてが確定していない状態で依頼せざるを得ない場合は、どこが未確定かを伝えます。

未確定であることがわかっていれば、作業者はその部分の作り込みを後回しにできます。確定しているものとして進めてしまうと、変更時の手戻りが大きくなります。

作業する側の防止策

着手前に認識を合わせる

依頼を受けた時点で、自分の理解を言語化して依頼者に確認します。

「この資料は○○の判断に使うという理解で合っていますか」「構成はこのような形を想定していますが、方向性としていかがでしょうか」といった確認を、作業に入る前に行います。

この確認に 10 分かけることで、数時間の手戻りを防げます。

早い段階で中間確認を受ける

完成させてから見せるのではなく、骨組みの段階でレビューを受けます。

資料であれば構成案の段階、システム開発であれば画面遷移や項目定義の段階です。方向性の誤りはこの段階でしか安価に修正できません。

完成度が低い状態を見せることに抵抗を感じる場合もありますが、「方向性の確認のため、構成だけの段階でご覧いただきたい」と前置きすれば問題ありません。

不明点を推測で埋めない

わからない点を自分の推測で補って進めると、その推測が誤っていた場合に手戻りとなります。

質問することの負担と、手戻りの負担を比べれば、質問の方が圧倒的に小さく済みます。

指摘内容を記録する

受けた指摘を記録し、次回以降の作業開始時に確認します。

同じ指摘を繰り返し受けることは、記録がないことが原因である場合がほとんどです。指摘の内容と背景にある理由をセットで残しておくと、類似の場面でも応用できます。

組織として手戻りを削減する仕組み

個人の工夫には限界があります。手戻りが常態化している場合、プロセスそのものに手を入れる必要があります。

依頼のフォーマットを統一する

依頼時に必要な情報が揃っていない状態を、仕組みで防ぎます。

依頼フォームを用意し、目的、完了条件、期日、参考資料、未確定事項といった項目を必須にすることで、情報不足のまま作業が始まることを防げます。

Asana のフォーム機能を使うと、依頼を受け付ける窓口を 1 か所にまとめ、必要な項目を必須設定にできます。送信された内容は自動でタスクとして作成されるため、依頼の受け取り漏れも防げます。

口頭やチャットでの依頼を受け付ける運用では、人によって伝える情報の量に差が出ます。フォーマットを固定することで、依頼の質を一定に保てます。

繰り返し発生する業務の手順を標準化する方法は、標準作業手順書 (SOP) の書き方で解説しています。

レビューの時期を工程に組み込む

レビューを「できたら見せる」ではなく、スケジュール上の工程として定義します。

着手時点で、中間レビューの実施日と確認観点を決めておきます。工程として組み込まれていれば、作業者がレビューを求めるかどうかの判断に迷うことがなくなります。

レビューや承認をタスクとして設定し、前のタスクが完了した時点で自動的に次の担当者へ割り当てる運用にすれば、確認の工程が省略されることがなくなります。Asana ではルールを設定することで、この流れを自動化できます。

決裁者を早い段階で巻き込む

最終承認の段階で初めて決裁者が内容を見る体制は、大きな手戻りを生みます。

方向性が決まる初期の段階で、決裁者の確認を取る工程を設けてください。この 1 工程を追加することで、後工程での全面的なやり直しを防げます。

情報を一か所に集約する

依頼内容、参考資料、過去のやり取り、決定事項を、関係者全員が参照できる場所にまとめます。

情報がチャット、メール、個人のローカルフォルダに分散している状態では、作業者が必要な情報にたどり着けません。案件ごとに情報が集約されていれば、前提の誤りによる手戻りを減らせます。

Asana では、1 つのタスクに依頼内容、参考資料、関係者とのやり取り、進捗状況をまとめて記録できます。情報を探す時間が減るだけでなく、必要な情報を見落としたまま作業を進めることも防げます。業務プロセス全体を一元管理する方法は、ワークフロー管理のユースケースで確認できます。

仕様変更の伝達経路を決める

変更が発生した際、誰が誰に、どのような手段で伝えるかを事前に決めておきます。

変更の伝達が個人の判断に委ねられていると、伝え漏れが発生します。変更内容を記録する場所を決め、関係者に通知が届く仕組みにすることで、古い仕様のまま作業が進むことを防げます。

タスクに変更内容をコメントとして記録すれば、そのタスクに関わる担当者全員に通知が届きます。誰に伝えるべきかを都度判断する必要がなくなり、伝え漏れを防げます。担当者と期日を明確にした運用の具体例は、タスク管理のユースケースで確認できます。

指摘内容を蓄積する

レビューで出た指摘を記録として残し、チームで参照できるようにします。

同じ指摘が繰り返されている場合、それはチェックリストに加えるべき項目です。個人の記憶に依存させず、組織の知識として蓄積することで、担当者が変わっても品質を保てます。

タスクのコメント欄にやり取りを残しておけば、指摘の内容とその理由が記録として残ります。類似の案件に着手する際に過去のタスクを参照すれば、同じ指摘を受ける前に対応できます。プロジェクト終了後に学びを整理し、次に引き継ぐ進め方は、レトロスペクティブの進め方と手法で解説しています。

手戻りコストを最小化し、設計品質を最大化しましょう

設計段階での 1 つ の修正が、後工程での手戻りを防ぎます。Asana を活用すれば、設計・生産技術・品質保証の各部門がリアルタイムで連携し、潜在的なリスクをフェーズの早い段階で確実に特定できます。

Asana を無料で試す

業種・工程別の手戻り対策

システム開発における手戻り

システム開発では、上流工程での手戻りほど影響が大きくなります。要件定義の誤りが実装後に発覚した場合、設計からコーディング、テストまでをやり直すことになります。

主な発生要因 - 要件定義の段階で、利用者の実際の業務が把握されていない - 仕様書の記述が曖昧で、開発側と発注側の解釈が異なる - 画面や帳票のイメージが固まらないまま実装に入る - テスト段階で初めて利用部門が成果物を確認する

対策 要件定義の段階でプロトタイプや画面イメージを作成し、利用部門の確認を得ることが有効です。文書だけでの合意は、解釈の差が残りやすくなります。作業範囲を文書として固める際は、スコープマネジメント計画のテンプレートが利用できます。

アジャイル開発のように開発サイクルを短く区切る手法は、手戻りの規模を小さく抑える考え方に基づいています。1 回のサイクルで作る範囲を限定すれば、誤りが判明した際のやり直し範囲も限定されます。

オフショア開発では、言語と商習慣の違いにより認識のズレが生じやすくなります。仕様書の記述をより詳細にする、図表を多用する、定期的な同期の頻度を上げるといった対応が必要です。

製造業における手戻り

製造業では、手戻りが材料費の損失に直結します。工程が進むほど、投入された部品や加工のコストが積み上がるためです。

主な発生要因 - 設計段階での検討不足により、製造工程で問題が判明する - 図面と現場の認識が一致していない - 検査基準が明確でなく、合否の判断が担当者によって異なる - 設計変更が製造現場に伝わらない

対策 設計段階で製造部門の意見を取り入れる体制が有効です。設計者だけで図面を確定させると、製造現場で初めて実現困難な点が判明します。

品質管理の観点では、各工程での検査基準を明文化し、合否の判断を標準化することが手戻りの削減につながります。

クリエイティブ制作における手戻り

デザインや映像、ライティングなどの制作業務では、評価基準が主観的になりやすく、手戻りが発生しやすい特性があります。

主な発生要因 - 依頼者の好みが言語化されておらず、提出後に初めて判明する - 決裁者が制作の途中段階を見ておらず、完成後に全面的な指摘が入る - 修正の指示が「もっとよく」のように具体性を欠く - 関係者が多く、意見が集約されていない

対策 着手前に、参考となる既存の制作物を複数示し、好みの方向性を確認します。言葉よりも実例での合意が確実です。

修正指示については、何をどう変えるのかを具体的に伝えることを依頼側のルールとします。抽象的な指示は、修正の繰り返しを招きます。

手戻りの削減効果を測る

対策の効果を確認するには、手戻りの発生状況を数値で把握する必要があります。

記録すべき項目

• 手戻りが発生した工程

• やり直しに要した工数

• 発生の原因 (認識のズレ、仕様変更、要件の不備など)

• 発生時点 (どの段階で判明したか)

分析の観点

どの工程で多いか 特定の工程に集中している場合、その工程の前段階に原因があります。

どの原因が多いか 認識のズレが多いのであれば依頼の方法を、仕様変更が多いのであれば要件確定のプロセスを見直す必要があります。

いつ判明しているか 判明が遅いほど手戻りのコストは大きくなります。発生自体を減らすことと並行して、早期に発見する仕組みを整えることが重要です。

数値として把握できていれば、対策の前後で比較でき、どの施策が効果を持ったかを判断できます。感覚的に「減った気がする」という評価では、施策の継続判断ができません。

測定と改善を継続的に回す考え方については、PDCA サイクルの意味と 4 つの手順を参考にしてください。

まとめ

手戻りとは、いったん完了した作業を後の工程での指摘や変更によってやり直すことを指し、読み方は「てもどり」です。コストの増加、納期遅延、品質低下、モチベーションの低下といった影響をもたらします。

発生の原因は、認識のズレ、要件定義の不備、レビュー時期の遅れ、情報の分散、仕様変更の 5 つに分類できます。いずれも個人の注意不足ではなく、仕事の進め方に起因する構造的な問題です。

個人レベルの対策としては、依頼時に完了条件と判断基準を明示すること、作業開始前に認識を確認すること、完成前の段階で中間レビューを受けることが有効です。

ただし、手戻りが常態化している場合は、個人の工夫では解決しません。依頼フォーマットの統一、レビュー工程のスケジュールへの組み込み、情報の一元化、仕様変更の伝達経路の整備といった仕組みの側から手を入れる必要があります。

手戻りの発生状況を記録し、どの工程でどの原因により発生しているかを把握することで、対策の優先順位が見えてきます。

依頼内容と完了条件をタスクに記載し、レビューを工程として組み込み、やり取りの履歴を 1 か所に残す。この 3 つが揃っていれば、手戻りを生む条件の多くは取り除けます。Asana は、依頼の受付から完了までを同じ場所で管理できるため、認識のズレや情報の分散による手戻りを減らせます。

よくある質問