業務委託のメンバーが1〜2人のうちは、雑談の延長で管理が回る。「今週こっちのタスクをお願いします」という一言で動き、質問があればチャットで返す。それで十分だ。
ところが5人を超えたあたりで、管理の手触りが変わる。何かがうまく回らなくなっていると感じても、どこから手を入れればいいかが見えない。この記事では、5人の壁で何が起きるかを整理し、「管理を会話から構造に移す」という考え方を提案する。
全員の状況を把握できなくなる
1〜2人であれば、それぞれの状況は頭の中に収まる。誰が何をしていて、いつ終わる予定か。チャットを少し見返せば確認できる。
5人を超えると、頭の中に入りきらなくなる。「Aさんが○○をやっていて、Bさんは別件で、Cさんはたしか今週から新しいタスクで……」という把握が、担当者の記憶と確認コストに依存したままになる。誰かに問い合わせるたびに担当者は手を止めなければならない。
さらに、業務委託のメンバーは社内のSlack上にはいない。進捗はチャットのメッセージを遡るか、直接確認メッセージを送るかでしか分からない。5人分のチャットを毎日確認するのは現実的ではなく、抜け漏れが発生し始める。
優先順位の整合が取れなくなる
1〜2人のうちは、依頼者が「今週これを最優先にお願いします」と伝えれば整合が取れる。相手の状況も把握できているから、無理な依頼をしていないかの判断もできる。
5人を超えると、全員に個別で優先順位を伝える手間が増える。伝え忘れが起きる。Aさんには「○○を先にお願いします」と伝えたが、BさんとCさんには伝えていなかったために、3人が異なる優先順位で動いてしまう。
また、急な変更が発生したときの影響範囲が広がる。クライアントの都合で1件の仕様が変わると、複数の外注先が担う作業の見直しが必要になる。全員に個別でメッセージを送って変更を伝えるコストは、5人を超えると無視できなくなる。
情報が非対称になる
業務委託メンバーが少ないうちは、全員が同じ情報を持っていることが多い。依頼者がひとつのチャットルームで全員に情報を共有できるからだ。
5人を超えると、個別のやりとりが増え、誰がどの情報を持っているかの管理が難しくなる。Aさんには仕様変更を伝えたが、その変更がBさんの作業にも影響するとは気づかなかった——という事態が起きる。
情報の非対称は手戻りを生む。後から「そんな仕様に変わっていたんですか」と言われると、作業をやり直させることになる。外注先のコストも、依頼者の時間も、両方が無駄になる。
管理を会話から構造に移す
5人の壁を越えるための答えは、「管理を担当者の頭と会話から、構造に移す」ことだ。
構造とは、共有された状態が見えるリストや仕組みのことだ。全員の依頼と進捗が一覧で見える。誰が何件のタスクを持っているかが分かる。優先順位の変更があれば一箇所を更新すればよい。これが整えば、担当者の記憶と確認メッセージへの依存から抜け出せる。
構造を作るための第一歩は、依頼を「チャットのメッセージ」ではなく「タスク」として起票することだ。依頼内容・担当者・期日・ステータスが記録されたタスクが、管理の基本単位になる。
5人超えで整備したい3つの仕組み
具体的に整備すべき仕組みを3つ挙げる。
ひとつ目は、依頼一覧の共有だ。全員のタスクが見える共有リストを持つ。タスク管理ツールで外注先をゲストとして招待し、自分のタスクを確認・更新してもらう。担当者は全員分のリストを俯瞰できる。
ふたつ目は、優先順位の一元管理だ。タスクに「優先度」の項目を設け、変更があれば一箇所を更新する。全員が同じリストを見ているため、変更の連絡を5人に個別送信する必要がなくなる。
みっつ目は、情報共有の場所の統一だ。仕様変更や追加情報は、タスクのコメントに残す。チャットに流れるのではなく、タスクに紐づいて記録されるため、後から経緯を確認しやすくなる。
移行期のポイント
会話ベースの管理から構造ベースの管理に移行する際、全員同時に切り替えようとすると摩擦が大きい。まず1〜2人の外注先で試し、うまく機能することを確認してから他のメンバーに広げるのが現実的だ。
外注先への説明は簡潔にする。「タスクに依頼内容と期日を書くので、確認して作業してください。進捗が変わったらステータスを変えてもらえると助かります」という説明で始める。複雑なルールは後から足す。
外部チームの失敗パターンと回復策
5人超えの外注チームで起きやすい失敗には、いくつかのパターンがある。事前に把握しておくことで、同じ轍を踏まずに済む。
失敗パターンの一つ目は「全員を同じ管理方法で括ること」だ。フリーランサーAはSlackを使い慣れており、フリーランサーBはメールしか確認しない。フリーランサーCは自社開発の別ツールを使っている。この3人に「タスク管理ツールを使ってください」と一律に伝えても、全員が同じ使い方をするとは限らない。
回復策は、最初に「このツールをここまで使えれば十分」という最低限の操作を定義することだ。「タスクを見て、終わったらステータスを変える」という2操作に絞れば、どんなメンバーでも習得コストは低い。高度な機能は後から学んでもらえばよい。
失敗パターンの二つ目は「管理ツールの導入で満足してしまうこと」だ。タスク管理ツールを入れただけで「仕組みが整った」と感じてしまい、実際には誰もステータスを更新しないまま時間が経つ。ツールは仕組みではなく、仕組みを動かすための器だ。
回復策は、最初の2〜3週間は意識的に運用を確認することだ。週に1度、全員のタスクのステータスを確認し、更新されていなければ声をかける。この習慣が根付けば、その後は自走するようになる。
失敗パターンの三つ目は「情報をタスクツールに入れるだけで共有できたと思うこと」だ。タスクを起票しても、外注先がそれを確認していなければ意味がない。「タスクツールに書いたから確認してください」という前提は、外注先がツールを見る習慣がついてから初めて成立する。
回復策は、重要な依頼は起票後に「タスクに追加しました」という一言をチャットで送ることだ。ツールへの導線を維持しながら、見逃しを防ぐ。習慣が定着すれば、この一言も不要になる。