システム開発の外注は丸投げでよいか——渡してよい作業と、社内に残す4つの判断【2026年版】

「ITが分かる人間が社内にいないので、全部お任せしたいのですが」——これは、当社にいただくご相談のなかで最も多い言い出しのひとつです。そう言ったあとに、多くの方がこう付け加えます。「でも、丸投げすると失敗すると聞きました。何をすればいいのでしょうか」。この記事にたどり着いた方も、同じところで止まっているのではないでしょうか。

先に結論を書きます。丸投げが危ないのは、作業を任せるからではありません。判断まで一緒に渡してしまうからです。要件を文書にする作業も、設計も、実装も、進捗の管理も、外に出してかまいません。しかし、何のために作るのか、どれを先に作るのか、いくらまで出すのか、これで完成と認めるのか。この4つの判断だけは、社内に残す必要があります。

この線引きができると、外注の景色が変わります。専任のIT担当を採用しなくても、週に1時間の会議があれば発注は回ります。開発会社への遠慮も要らなくなります。質問されることは監視ではなく、判断を仰がれているのだと分かるからです。逆にこの線引きがないまま進むと、手戻り・追加費用・現場で使われないシステムという、よくある結末に近づきます。

私はTALENTBASE VIETNAMでCOOを務めています。人材業界の出身で、発注する側とされる側の双方の事情を見てきました。2018年以降、約100社のご相談を受けるなかで確信しているのは、失敗の原因は技術力ではなく判断の空白にあるということです。当社では日本人PMがフロントに立ち、要件の整理と仕様の文書化、進捗管理まで担います。そのうえで週次の定例では、優先順位と完成の判断をお客様に決めていただきます。判断の材料はこちらで用意します。最小構成は日本人PM+2〜3人月の月額約80万円から、1名から最短2週間で始められます。

この記事では、丸投げで実際に起きるトラブル、発注者に求められる協力義務の考え方、渡してよい作業と残す判断の線引き表、そして判断を残したまま任せるための会議と契約の設計を、順に整理します。読み終えたら、次回の打ち合わせで1つだけ聞いてみてください。「優先順位は、誰が決めますか」。その答えで、任せられる相手かどうかが分かります。

丸投げで何が起きるか——判断の空白が生む5つのトラブルと、発注者に残る責任

丸投げという言葉には、責められている響きがあります。ただ、私は発注者を責める立場には立ちません。人材業界の出身で、発注する側とされる側の双方の事情を見てきたからです。専門外のことを専門家に任せたいのは自然な感覚です。問題は任せること自体ではなく、任せ方にあります。

「丸投げ」とは作業ではなく判断を渡すこと

作業を委託することは、外注の本来の姿です。設計も実装もテストも、専門家に任せてかまいません。丸投げと呼ばれて問題になるのは、作業と一緒に判断まで渡してしまう状態です。何のために作るのか、どの機能を先に作るのか、どこまでできたら完成なのか。これらを決めないまま進むと、開発会社は自社の解釈で決めるしかありません。

悪意があるわけではありません。むしろ真面目な会社ほど、決まっていない部分を埋めようとします。しかし業務を知らない人間が埋めた仕様は、現場の実態とずれます。ずれは稼働直前か、稼働後に発覚します。

実際に起きるトラブル5つ

私のところに届く相談を整理すると、丸投げに起因するトラブルはおおむね次の5つに収まります。

当社では、ソースコードをGitで管理し、設計や運用のドキュメントを納品物に含める運用にしています。特別なことではありませんが、これがないと会社を移れなくなります。乗り換えの自由を残すことは、発注者の交渉力そのものです。

発注者にも協力義務がある

システム開発の裁判では、開発会社のプロジェクト管理義務と並んで、発注者の協力義務が争点になってきました。必要な情報を出す、意思決定を先延ばしにしない、中間成果物を確認する。こうした協力を欠いた場合、発注者側の責任が問われることがあると一般に解説されています。個別の事案の判断は事情によって異なりますし、この記事は法的助言ではありません。契約や紛争の判断は弁護士にご確認ください。

ここで押さえたいのは、法律論そのものよりも実務上の含意です。「全部任せたのだから全部そちらの責任」という前提は、契約上も実態としても成り立ちにくい。だとすれば、任せる範囲を最初に設計しておくほうが合理的です。では、どこまでが作業で、どこからが判断なのでしょうか。

渡してよい作業と、社内に残す判断——線引きの表

ここからが本題です。何を渡し、何を残すのか。結論だけ先に書くと、残すのは4つの判断であり、それ以外の実務はすべて渡してかまいません。専門知識が必要な作業ほど、外に出したほうが速く正確です。

渡してよい作業、渡してはいけない判断

次の表は、開発プロジェクトの主な作業を「任せてよいか」で仕分けたものです。

表を見ると、任せてよい欄のほとんどが「作業」で、残す欄のすべてが「判断」であることが分かります。丸投げという言葉を、判断まで渡すことと定義したのはこのためです。

社内に残す4つの判断

4つをもう少し具体的にします。目的は、システムで解決したい業務課題を1文で言えることです。「受注入力の二重手間をなくす」でかまいません。優先順位は、予算や期限が足りないときに何を後回しにするかの順番です。予算は上限額と、超えるときに誰が判断するかの取り決めです。完成の定義は、検収の基準になります。「現場の5名が1週間、旧システムを使わずに業務を回せること」のように、業務の言葉で書けると強くなります。

この4つは、開発の知識がなくても決められます。むしろ開発の知識があっても、業務を知らなければ決められません。だから社内に残すのです。

IT担当がいない会社でも判断する役割は置ける

「うちにはITが分かる人がいない」というご相談をよくいただきます。必要なのはITが分かる人ではなく、業務を知っている人と、決裁できる人です。この2つの役割は、多くの場合すでに社内にいます。兼任でもかまいませんし、同一人物でもかまいません。

実際にあった例では、業務を知る現場リーダーと、決裁権を持つ役員の2名を「決める人」として指名し、週次の定例に出てもらいました。技術的な説明は当社のPMが日本語で噛み砕き、判断に必要な材料を事前に出す。会議は1時間で終わります。それだけで、仕様のずれは早い段階で見つかるようになりました。決める人がいれば、体制は後から作れます。

判断を残したまま任せる——会議・確認・契約・選定の設計

判断を残すと決めても、意志だけでは続きません。仕組みにする必要があります。必要なのは2つだけです。週次の定例と、中間成果物の確認。この2つがあれば、残りは開発会社の実務に委ねられます。

週次の定例と中間成果物の確認という2つの仕組み

定例は週1回、60分で足ります。議題は固定します。先週決まったこと、今週の進捗、判断を仰ぎたい事項、リスクと遅れ、次週の予定。このうち発注者が本当に時間を使うべきなのは3番目です。判断を仰ぐ事項には、選択肢と推奨案、それぞれの影響(工数・費用・期日)を添えてもらってください。材料が揃っていれば、判断は数分で終わります。

中間成果物は、次のタイミングで確認します。

デモを一度も見ないまま納品日を迎えるプロジェクトは、高い確率で揉めます。動くものを早めに見ることが、最大のリスク対策です。

請負と準委任で、任せ方はどう変わるか

契約形態でも任せ方は変わります。請負は完成責任があり、契約時に決めた仕様が基準になります。仕様が固まっているなら合理的な選択です。一方、準委任(ラボ型開発)は一定の体制を一定期間提供する契約で、月額が先に決まります。優先順位を毎月組み替えられるため、作りながら決めたい案件に向きます。

当社が提供しているのはラボ型です。日本人PMがフロントに立ち、要件の整理、仕様の文書化、進捗管理を担います。最小構成は日本人PM+2〜3人月で月額約80万円から、1名から最短2週間で開始でき、増員は約1週間です。エンジニアは2,000名以上の人財データベースから直接アサインするため、単価も公開しています。実務3年で1,500USD、5年で2,000USD、ブリッジSEで3,000USD(1USD=150円換算が目安)です。

任せられる会社の見分け方

最後に選定です。判断材料は3つあります。ひとつ、質問の量。要件を聞かずに見積もりを出す会社より、業務を細かく聞いてくる会社のほうが安全です。ふたつ、ドキュメントの扱い。設計書と運用手順を納品物に含めるか、ソースコードとリポジトリを引き渡せるかを確認してください。みっつ、断ってくれるか。当社も、伺った要件に対して体制が合わないと判断した場合は、その旨を率直にお伝えします。何でもできますと答える会社より、できないことを言う会社のほうが信用できます。残った疑問は、次のよくある質問で拾います。

よくある質問

丸投げと外注の線引きについて、実務でよく届く質問に答えます。いずれも、社内にIT担当がいない企業からのご相談で繰り返し聞かれる内容です。

Q1. 要件定義まで任せてもよいですか

書く作業は任せてかまいません。ただし、業務の流れを説明する人と、優先順位を決める人は社内に必要です。この2つがないと、要件定義書は他社の業務を写したものになります。

Q2. 社内にIT担当がいなくても発注できますか

できます。必要なのは業務を知っている人と、決裁できる人です。当社の場合、日本人PMが技術的な説明を日本語で噛み砕き、判断の材料を用意します。週1回60分の定例で回っている案件が多数あります。

Q3. 判断を残すと、こちらの工数はどのくらいですか

目安として週1時間の定例と、工程の節目に中間成果物を確認する時間です。月あたり6時間前後を見込んでいただければ、大きく外れません。

Q4. 丸投げに近い任せ方をすると、費用は上がりますか

多くの場合、直接の見積もりより手戻りで増えます。仕様が決まらない期間の工数は誰かが負担することになるからです。優先順位を先に決めるほうが、結果として安く収まります。

Q5. 最小構成と開始までの期間を教えてください

最小構成は日本人PM+2〜3人月で月額約80万円から。1名から始められ、面談を経て最短2週間で開始、増員は約1週間です。1か月単位でのリプレイスメントにも対応しています。

まとめ: 渡すのは作業、残すのは判断——週1時間の会議で、外注は回る

システム開発の外注で丸投げが危ないのは、作業を任せるからではありません。判断まで一緒に渡してしまうからです。要件の文書化も、設計も、実装も、進捗管理も、専門家に任せてかまいません。社内に残すのは4つだけです。何のために作るのか(目的)、どれを先に作るのか(優先順位)、いくらまで出すのか(予算)、これで完成と認めるのか(検収の基準)。この4つは業務と経営の判断であり、外部が代わりに決めることはできません。

判断の空白を放置すると、手戻りと追加費用、現場で使われないシステム、社内にノウハウが残らない状態、ベンダーロックイン、情報漏えいという5つのトラブルにつながります。裁判でも発注者の協力義務が争点になってきたと一般に解説されています。この記事は法的助言ではありませんが、実務上の含意は明確です。任せる範囲は最初に設計しておくほうが安全だということです。

必要な仕組みは2つで足ります。週1回60分の定例と、工程の節目での中間成果物の確認です。定例では判断を仰ぐ事項に選択肢と推奨案、影響(工数・費用・期日)を添えてもらってください。要件定義書、画面設計、動くデモ、テストの受入基準、納品時のコードとドキュメント。この5つを見るだけで、ずれは早い段階で見つかります。発注側の工数は月あたり6時間前後が目安です。ITが分かる人がいなくても、業務を知る人と決裁できる人がいれば足ります。契約形態の選び方はラボ型開発とSESの違い、仕様変更の扱いは仕様変更の追加費用もあわせてご覧ください。当社は日本人PMがフロントに立ち、要件の整理から進捗管理までを担うラボ型で、最小構成は日本人PM+2〜3人月の月額約80万円から、1名・最短2週間で開始できます。現在の体制と要件をお聞かせいただければ、任せ方の設計を含めた概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。