システム開発の「丸投げ」はなぜ失敗するのか｜発注者が関与すべき場面

「専門家に任せたのだから、あとは完成を待つだけ」。システム開発の丸投げは、納期遅延や想定と違うシステムの完成、最悪の場合は訴訟につながります。この記事では、丸投げが失敗する典型パターン、開発会社に任せてよい領域と発注者が決めるべき領域、週次確認やデモで関わる方法、発注者の協力義務が問われた裁判例を紹介します。

丸投げが失敗につながる典型パターン

システムは、発注者の業務を形にするものです。業務を一番よく知っているのは発注者であり、開発会社は聞かなければ分かりません。丸投げが失敗する流れは、おおむね次のどれかです。

• 要件が決まらないまま進む: 担当者が忙しく質問への回答が遅れ、開発会社が推測で作る。完成後に「こうではない」となる
• 現場の意見が入っていない: 情報システム担当や経営者だけで仕様を決め、実際に使う現場が受入テストで初めて触って反発する
• 途中で要望が膨らむ: 進捗を見ていなかった反動で、終盤に要望が一気に出て、納期と費用が崩れる
• 判断が遅れて止まる: 開発会社から確認事項が来ても、社内で誰が決めるか決まっておらず、作業が止まる

IPA（情報処理推進機構）の情報システム・モデル取引・契約書（第二版）の解説でも、請負契約にすると発注者側に「丸投げ」「ベンダにすべてお任せ」という意識が強くなる場合があると指摘されています。その結果、発注者社内の関係者の調整が曖昧になり、要件の見落としが生じやすくなるとしています。

任せてよい領域と、発注者が決めるべき領域

丸投げを避けるといっても、発注者が技術の細部まで口を出す必要はありません。役割を分けて考えます。

技術の選定は開発会社に任せてよい領域ですが、セキュリティの水準や、将来の運用体制に関わる方針は、発注者も説明を受けて確認しておくべきです。

週次確認・デモ確認・現場の意見の吸い上げ

発注者の関与は、仕組みとして予定に組み込むと続きます。

週次の定例

週1回、30分〜1時間の定例を設け、進捗、課題、発注者への確認事項を確認します。確認事項には回答期限と担当者を決めます。定例の進め方は進捗管理と定例会議でも解説しています。

動く画面でのデモ確認

資料や設計書だけで判断せず、動く画面を見て確認します。2〜4週間に1回程度、作った部分のデモを見せてもらうと、認識のずれを早く見つけられます。

現場の意見の吸い上げ

実際に使う現場の担当者を、デモや受入テストに早めに参加させます。意見は窓口担当者が集約して優先度を付け、開発会社に一本化して伝えます。現場の声を聞く場を設けておくと、稼働後に「使われないシステム」になるリスクも下げられます。現場が忙しい場合は、代表者を1〜2人に絞り、デモの日程を早めに押さえておくと参加してもらいやすくなります。

発注者の協力義務に関する裁判例

裁判所は、システム開発は開発会社だけでは完成できず、発注者にも協力する義務があると考える傾向にあります。開発会社が進行を適切に管理する「プロジェクトマネジメント義務」を負う一方、発注者は必要な情報の提供や意思決定などに協力する「協力義務」を負う、という整理です。

代表例が、大学病院の電子カルテ開発をめぐる札幌高裁平成29年8月31日判決です。Westlaw Japan の判例コラムによると、裁判所は、発注者が仕様凍結の合意後に大量の追加要望を出したことや、発注者の責任とされていたデータ（マスタ）の作成を怠ったことを協力義務違反と認め、一審の判断を変えて発注者側にのみ支払いを命じました。協力義務には、決められた作業を行うことだけでなく、合意に反する追加要望で開発を妨げないことも含まれると判断されています。

一方で、発注者と開発会社の双方の不完全な履行が重なったとして、責任を分け合う形で解決された裁判例（東京地判平成16年3月10日など）もあります。どちらに責任があるかは事案ごとに判断されますが、「お金を払っているから発注者は何もしなくてよい」とはならないことが分かります。

契約書でも、発注者の役割は明文化されることが一般的です。モデル契約書は、発注者と開発会社それぞれの分担作業を別紙で定め、自分の分担を遅らせたり実施しなかったりした場合は、相手方に生じた損害も含めて責任を負う、という条項を置いています。契約書に書かれた「発注者の作業」は、署名前に社内で実行できるか確認しておきましょう。

丸投げを防ぐために発注前に決めておくこと

関与の仕組みは、開発が始まってからでは作りにくいものです。発注前に、社内で次のことを決めておきます。

• 責任者と窓口: 最終判断をする責任者と、開発会社とやり取りする窓口担当者を決める。兼務なら、プロジェクトに使える時間を上長と合意しておく
• 決裁のルート: 仕様の確認や変更の承認を、誰がどこまで決められるか。毎回役員の決裁が必要だと、開発が止まる
• 参加する現場の担当者: デモや受入テストに参加する部署と人を決める
• 発注者側の作業の一覧: データ準備、資料提供、受入テストなど、自社で行う作業と時期

これらは、開発会社を選ぶ前に決めておくと、提案を比べる際の前提にもなります。

受託開発の現場から

ある受託開発会社は、発注者の関わり方について次のように話しています。

• 業務委託には2つの中身が混ざっている。 専門ノウハウの提供と、発注者のリソースの代わりに作業する部分です。どの割合を開発会社に任せるかを考えないまま全部を委託すると割高に見える、という説明です。
• 「よしなに」で決まってしまうリスク。 開発会社に構築を頼む場合でも、インフラの設計やセキュリティの調整について発注者が方針を明確に示さないと、開発会社の判断だけで決まってしまう、という指摘です。
• 発注者は体験と価値の定義に集中する。 要件定義の分担については、「ユーザー体験・主要画面・ビジネス価値は発注者、内部実装は開発会社」という切り分けを繰り返し示しています。
• 発注者の担当作業を提案書に書く。 同社の提案書では、画面モックの確認と仕様承認、データ準備、受入テスト、検収を発注者の主担当と明示し、週1回90分の打ち合わせ枠や関係部門の同席をお願いしています。業務ルールや運用方針は開発会社が決めず、確認事項として発注者に判断を求めています。

まとめ

• 丸投げは、要件の未確定、現場の不在、終盤の要望の膨張、判断の停滞で失敗しやすい
• 目的、業務ルール、優先順位、受入の判断は発注者が担う
• 週次の定例、動く画面でのデモ、現場の参加を予定に組み込む
• 裁判例でも発注者の協力義務が認められており、任せきりは発注者自身のリスクになる

本記事は一般的な情報提供を目的としたもので、個別の契約や法的判断については弁護士などの専門家にご相談ください。

自社でどこまで関わればよいか見通しを立てたいときは、FastProposal の無料AI相談で案件を整理し、進め方と費用の目安を確認するところから始められます。