「外注先が何をしているか分からない」という状態は、外注先の問題ではないことが多い。依頼したタスクの粒度が大きすぎて、外注先も「何が完了で何が途中か」を報告しにくい状況になっていることが原因だ。
この記事では、進捗が見えない構造的な理由と、それを解決するための3つのステップを整理する。
進捗が見えない本当の原因
「LP制作をお願いします」という依頼は、外注先にとって1件の大きなタスクだ。完成まで1週間かかるとすれば、依頼者は1週間何も見えない状態で待つことになる。3日目に「今どうですか」と聞いて、「構成を考えています」と返ってきても、それがどの段階なのか判断できない。
この問題の根本は、タスクの粒度が大きすぎることだ。「LP制作」という1つのタスクは、実際には「構成作成」「コピーライティング」「デザイン」「コーディング」「修正対応」という複数の工程からなる。工程ごとに進捗が見えれば、「今日は構成が完了した」「明日からデザインに入る」という報告が自然に生まれる。
Step 1：依頼をタスクレベルに分解する
大きな依頼を、一人が1〜2日で完了できるサイズのタスクに分解することが最初のステップだ。
タスクの分解例：「LP制作」を「①ターゲット・訴求ポイントの整理（0.5日）」「②構成案3案の作成（1日）」「③構成案の確認・フィードバック（依頼者）」「④コピーライティング（1日）」「⑤デザイン（2日）」「⑥修正対応（1日）」のように分ける。
分解することで、外注先は「今どのタスクをやっているか」を伝えやすくなる。依頼者は「どのタスクが終わったか」を一覧で確認できる。「何をしているか分からない」から「今日は④を終わらせた」が見えるようになる。
分解のポイントは「確認できる成果物がある単位」にすることだ。「構成案3案の作成」は確認できる成果物がある。「LP制作の準備」は何が成果物か曖昧だ。成果物が明確なタスクに分解することが重要だ。
Step 2：各タスクの完了条件を決める
タスクを分解しただけでは不十分で、各タスクの完了条件を決めることが次のステップだ。完了条件がないと「完了」の基準が人によって変わる。
完了条件の例：「構成案3案の作成」の完了条件は「A4サイズ1枚の構成メモを3パターン提出」とする。「デザイン」の完了条件は「デザインツールのリンクをコメントに貼付け、修正受け付け可能な状態」とする。
完了条件を明示することで、外注先は「どこまで仕上げれば完了なのか」を迷わなくなる。依頼者は「完了基準を満たしているか」を確認するだけでよくなる。「完了しました」の後に「あ、そういう意味だったんですね」という手戻りが減る。
Step 3：進捗確認の頻度とフォーマットを決める
タスクの分解と完了条件の設定ができたら、進捗確認のサイクルを設計する。これが3つ目のステップだ。
確認の頻度は、プロジェクトの長さと外注先のタスク数による。1週間のプロジェクトであれば中間（3日目）と完了前（6日目）の2回が目安だ。複数の外注先が複数のタスクを動かしているなら週次の定例確認が有効だ。
確認フォーマットは、タスク管理ツールのステータス確認か、週次テンプレートでの報告かを決める。タスク管理ツールを使っていれば、ステータスを見るだけで確認が完了する。テンプレート報告を使うなら「今週完了したタスク・来週予定のタスク・ブロッカー」の3項目で十分だ。
3ステップを実装したときの変化
タスク分解・完了条件・確認サイクルの3つが揃うと、「外注先が何をしているか分からない」という状態は解消する。
依頼者は「今日時点でどのタスクが完了しているか」をリストで確認できる。外注先は「次に何をやるか」がタスクリストを見れば分かる。確認のためのメッセージを送り合う必要がなくなる。
この構造が整うと、外注先との信頼関係も変わる。依頼者が不安から確認を繰り返すのではなく、仕組みを通じて状況を把握できるため、外注先に安心して任せられるようになる。
タスク分解の実践例：業種別のケース
タスク分解の考え方は共通でも、実際の分解は業種や依頼内容によって変わる。いくつかの具体例を挙げる。
コンテンツ制作の場合：「記事10本の作成」という依頼は「①テーマリスト確認（共有）」「②1本目の構成案作成」「③構成案の確認（依頼者）」「④1本目の本文執筆」「⑤修正対応」「⑥残9本を同じフローで進行」という形に分解できる。最初の1本を丁寧に進めることで、以降の認識ズレを防ぐ。
ウェブ制作の場合：「サイトリニューアル」という依頼は「①現状サイトの課題整理」「②新サイトのワイヤーフレーム作成」「③デザインカンプ（PC版）」「④デザインカンプ（SP版）」「⑤コーディング」「⑥テスト・修正」のように分解する。各工程が終わった時点で確認を入れることで、後工程への影響を最小化できる。
経理・事務作業の場合：「月次の経費精算処理」という定期業務は「①月初に経費データの受け取り確認」「②データ入力・チェック」「③差異の確認（依頼者）」「④完了報告」という形に分解する。毎月同じフローを踏むことで、作業の抜け漏れが減る。
分解しすぎることの弊害
タスクを細かく分解しすぎると、今度は管理コストが上がる問題が生じる。10個のタスクに分けた結果、依頼者がすべてのタスクの確認に追われ、外注先も「この依頼、細かすぎて作業が止まりやすい」と感じてしまうケースがある。
分解の適切な粒度は「1タスクに1確認ポイントがある」程度だ。確認が必要なタイミングにタスクの区切りを置き、確認が不要な作業内容は同じタスクにまとめる。分解の目的は「確認できる単位を作ること」であり、「作業を細かく管理すること」ではない。
進捗確認の質を上げる問いかけ
タスクが分解されて確認のサイクルが設計されていても、「確認」の中身が浅いと問題の早期発見につながらない。確認の質を上げる問いかけのパターンを持っておくことが重要だ。
「進捗はいかがですか」という問いは、「問題ない状態」の確認にしかならない。より情報が得られる問いかけの例として次のものが有効だ。「今週予定していたタスクのうち、完了しているのはどれですか」「来週完了するか不確かなタスクはありますか」「現時点で依頼者に判断を求めたいことはありますか」。
これらの問いは、外注先が「問題ない」と思っていても実は積み残しがある状況を引き出しやすい。定期チェックインの冒頭でこれらを確認することで、問題が小さいうちに対処できるようになる。
「分からない」を言いやすい環境を作る
外注先が「分からない」を言えない環境では、認識のズレが後になって表面化する。「こんなことを聞くと仕事が取れなくなるのでは」という心理が、外注先の質問を抑制することがある。
「作業を始めてみて、不明点が出たら気軽に確認してください」という一言を、依頼ごとに添えることが重要だ。質問が来たときに素早く丁寧に答えることで、「このクライアントには聞きやすい」という信頼関係が生まれる。その信頼関係が、後の「分からない」の早期共有につながる。