システム開発の外注で「丸投げ」するリスク｜発注者責任と管理義務を解説

システム開発の外注で「丸投げ」するリスク｜発注者責任と管理義務を解説

「全部お任せしたのに動かない」——システム開発の丸投げが招く深刻なトラブル

「業務システムの開発を外注したのに、納品されたものがまったく使えない。しかも開発会社は『仕様どおりに作った』の一点張り……」

中小工務店・設計事務所の経営者から、こうしたシステム開発トラブルの相談が急増しています。施工管理のクラウド化、見積もりシステムの導入、顧客管理のデジタル化——DX推進の必要性を感じてシステム開発を外注したものの、**「こんなはずじゃなかった」**という結果に終わるケースが後を絶ちません。

典型的な「丸投げトラブル」のパターンは、こんなものです。

• 「要件定義から全部お願いしますと言ったら、見当違いのシステムが出来上がった」
• 「開発途中の確認を求められたが忙しくて放置していたら、完成後に大幅な修正が必要になった」
• 「追加費用を請求されたが、最初の見積もりと全然違う。どこまで支払う義務があるのか」
• 「納品後にバグだらけで業務に支障が出ている。損害賠償を請求したい」
• 「開発会社が倒産して、ソースコードもドキュメントも手元にない」

これらのトラブルに共通するのは、発注者が開発プロセスに関与せず、すべてを外注先に「丸投げ」していたという事実です。

そして多くの経営者が知らない重大なポイントがあります。システム開発の失敗について、発注者側にも法的な責任が問われる可能性があるということです。

この記事では、システム開発の外注における「丸投げ」のリスクと発注者が負う管理義務を、判例をもとに解説します。 中小工務店・設計事務所がDX投資で致命的な失敗をしないために、知っておくべき実践知識をお伝えします。

「ITは専門外だから全部お任せ」——その気持ち、よくわかります

この問題、あなただけのものではありません。

建設業は「ものづくりのプロ」です。現場監督の段取り、職人の手配、資材の管理——こうした実務には絶対の自信がある。しかしITシステムの開発は未知の領域です。

「自分たちには技術がわからないのだから、専門家に全部任せるのが最善だろう」

こう考えるのは自然なことです。実際、工務店の経営者は日々の現場対応に追われていて、システム開発の進捗会議に毎週出席する余裕などありません。

しかし、ここに構造的な落とし穴があります。

建設業に例えるなら、こうです。施主が「全部お任せします」と言って、設計の打ち合わせにも来ず、中間検査にも立ち会わず、完成後に「思っていたのと違う」とクレームを入れる。 建設業のプロであるあなたなら、**「それは施主にも責任がありますよ」**と言いたくなるはずです。

システム開発でもまったく同じことが起きています。そして裁判所も、**「発注者には一定の協力義務がある」**という判断を示しています。

だからこそ、「丸投げ」の何が法的にまずいのかを正確に理解し、最低限やるべきことを押さえておくことが、DX投資を守る鍵になるのです。

結論：発注者には「協力義務」と「プロジェクト管理義務」がある

結論から言えば、システム開発における発注者は、単なる「お客様」ではありません。プロジェクトを成功させるための協力義務を負っており、丸投げによってプロジェクトが失敗した場合、発注者側にも過失が認定される可能性があります。

発注者の協力義務とプロジェクト管理義務

判例が示す「発注者の協力義務」

システム開発の紛争において、裁判所が発注者に認めている義務は主に以下の3つです。

特に重要なのが「協力義務」です。 東京地裁平成16年3月10日判決（旭川医大事件・控訴審は札幌高裁）では、大規模システム開発の失敗について、**「ベンダーのプロジェクト管理義務違反」と同時に「ユーザー（発注者）の協力義務違反」**が認定されました。

この判決のポイントは、**「発注者がITの素人であっても、自社の業務要件を伝える義務、開発への協力義務は免除されない」**という点です。

なぜ「丸投げ」が法的リスクになるのか

システム開発契約は、建設工事の請負契約とは異なる特性を持っています。

建設工事の場合：

• 設計図面があれば、施主が現場に来なくても建物は完成する
• 成果物（建物）は目に見えるので、完成の判断が比較的容易
• 建築基準法など、客観的な品質基準がある

システム開発の場合：

• 発注者の業務知識なしには、正しい要件定義ができない
• 成果物（ソフトウェア）は目に見えないため、完成の判断が困難
• 品質基準は発注者の業務要件に依存する（客観的な基準が少ない）

つまり、**システム開発は本質的に「発注者と開発者の共同作業」**なのです。建設業で言えば、「設計図面がない状態で施工を始めるようなもの」であり、施主（発注者）が設計段階から積極的に関与しなければ、意図したものは作れません。

これを理解せずに「全部お任せ」で丸投げすると、以下のリスクが発生します。

リスク1：要件の食い違い 発注者の業務を十分に理解しないまま開発が進み、完成後に「こんなものは使えない」という事態になる。

リスク2：過失相殺による賠償額の減額 開発会社に損害賠償を請求しても、発注者の協力義務違反を理由に**過失相殺（3割〜5割の減額）**が適用される可能性がある。

リスク3：追加費用の発生 要件の曖昧さから仕様変更が頻発し、当初の見積もりを大幅に超える追加費用が発生する。

リスク4：プロジェクトの頓挫 意思決定の遅れや方針の不明確さにより、プロジェクト自体が頓挫する。

丸投げを防ぐ——発注者が最低限やるべき5つの管理義務

では具体的に、発注者は何をすればよいのでしょうか。ITの専門知識がなくても実行できる、最低限の管理義務を5つに整理しました。

1. 要件定義に「業務の責任者」を参加させる

要件定義とは、「このシステムで何を実現したいか」を決める工程です。ここに現場の業務責任者が参加しないことが、丸投げトラブルの最大の原因です。

開発会社は「システムを作る技術」は持っていますが、「あなたの会社の業務の流れ」は知りません。 見積もりの出し方、工程管理のルール、協力業者との連携方法——これらはあなたの会社にしかわからない情報です。

具体的にやること：

• 要件定義の打ち合わせには、実際に業務を行っている担当者を参加させる
• 現在の業務フローを書面で整理して開発会社に提供する
• 「こういう場面でこう使いたい」という利用シーンを具体的に伝える

2. 中間成果物を必ず確認する（検収義務）

システム開発は通常、複数の工程に分かれています。各工程の成果物を確認せずに次に進めることは、「中間検査なしで工事を進める」のと同じです。

具体的にやること：

• 設計書の説明を受けたら、業務の流れと合っているか確認する
• プロトタイプ（試作画面）が出来たら、実際の業務で使えるか試す
• 「わからないから大丈夫です」と言わず、わからないことは質問する

3. 進捗会議に定期的に参加する

月に1回でもいいので、進捗確認の場を設けましょう。 開発が計画どおり進んでいるか、問題が発生していないかを把握することが重要です。

具体的にやること：

• 最低でも月1回の進捗報告を受ける（対面でなくオンラインでもOK）
• 進捗報告の議事録を残す（メールでの報告でも可）
• 問題が報告されたら、放置せず速やかに対応方針を決める

4. 意思決定を先延ばしにしない

開発中には「AとBのどちらにしますか？」「この機能は必要ですか？」といった確認が頻繁に発生します。この回答を先延ばしにすると、開発が止まり、スケジュール遅延の原因になります。

裁判でも、**「発注者の意思決定の遅延がプロジェクト失敗の一因」**と認定されたケースがあります。

具体的にやること：

• 開発会社からの質問・確認事項には、1週間以内に回答する
• 自分で判断できない事項は、判断できる人に速やかにエスカレーションする
• 「どちらでもいい」場合は、理由を添えて開発会社に判断を委ねる（丸投げとは異なる）

5. 契約書の内容を理解してからサインする

当たり前のことのようですが、「よくわからないけどプロが言うんだから大丈夫だろう」とサインしてしまう経営者は非常に多いのが現実です。

最低限確認すべき契約条項：

契約書の確認が難しい場合は、IT分野に詳しい弁護士や、DXに精通したコンサルタントに相談することをお勧めします。

発注者がやるべき5つの管理義務

こんな工務店・設計事務所は要注意

以下に当てはまる場合、「丸投げリスク」が高い状態です。早めの対策をお勧めします。

• 現在、システム開発を外注しているが、進捗会議に一度も出席していない
• 要件定義を開発会社に「全部お任せ」している
• 契約書の内容を理解しないままサインした
• 開発会社からの質問や確認に、1ヶ月以上返答していないものがある
• 「ITのことはわからないから」を理由に、すべての判断を外注先に委ねている

「今さら言われても、もう契約してしまった」という方もご安心ください。 契約途中からでも、上記の管理義務を実践することでリスクを大幅に低減できます。

特に中小工務店・設計事務所にとって、システム開発の投資額は経営に直結する重大な判断です。「ITは専門外だからわからない」で済ませるのではなく、建設業のプロとしての管理能力をシステム開発にも応用する——その視点が、DX投資の成否を分けます。

まとめ

まとめ

システム開発の外注で「丸投げ」することは、発注者自身の法的リスクを高める行為です。

この記事のポイントを整理します。

• 発注者には「協力義務」「検収義務」「プロジェクトマネジメント義務」がある ——判例上、ITの素人であってもこれらの義務は免除されない
• 丸投げによりプロジェクトが失敗した場合、発注者にも過失が認定される ——損害賠償請求が3〜5割減額されるリスクがある
• システム開発は「発注者と開発者の共同作業」 ——建設工事とは異なり、発注者の業務知識が不可欠
• 最低限やるべきことは5つ ——要件定義への参加、中間検収、進捗確認、迅速な意思決定、契約内容の理解

「ITがわからないから全部任せる」のではなく、「ITがわからないからこそ、管理の仕組みを作る」。 これが、DX投資を成功に導く発注者の姿勢です。

中小工務店・設計事務所のDX推進は、業務効率化やコスト削減の大きなチャンスです。しかし、進め方を誤れば数百万円〜数千万円の損失につながりかねません。

「自社のDX推進を、どこから手をつければいいかわからない」「外注先の選び方や契約の進め方に不安がある」——そうした悩みをお持ちなら、建設業のDXに特化した専門家に相談してみてください。スタジオ・マショでは、中小工務店・設計事務所のIT活用・DX推進について、現状診断から実行支援までトータルでサポートしています。また、システム開発のパートナーとしてアトリエ・バイナリのような、建設業界の業務を深く理解した開発チームと連携することで、「丸投げ」ではなく「共創」によるDX推進を実現できます。

まずは現状の課題を整理するところから。お気軽に無料相談をご利用ください。