開発会社に丸投げできる範囲・できない範囲｜任せる作業と発注側に残る確認・決定の分担表

開発会社には、設計・プログラミング・テストといった作る作業から、要件の文書化や議事録・進捗報告などの進行の実務まで丸投げしてかまいません。ただし、目的と優先順位、仕様の確定、受け取るときの合格ライン、続けるか止めるかの判断は、国が公表しているモデル契約とその解説で発注側の役割とされており、任せられません。発注側に残る作業は「決める・渡す・確かめる」の3種類で、量は少なくても、ここが止まると開発全体が止まります。

この記事では、IPA・経済産業省のモデル契約の条文、裁判例、業界団体の調査をもとに「どこまでなら任せてよいか」を一覧表で示します。そのうえで、業務整理・設計・データ準備・受入・運用の段階ごとに、発注側と開発会社の作業を分担表にまとめ、自社でAIを使って進められる作業や、担当者がいないとき・確認が遅れたときに先に決めておくことも説明します。任せられる部分を安心して任せるための記事です。

「全部任せたい」は自然だが、丸投げした案件で起きていること

社内にシステムが分かる人がいないのは、日本では普通のこと

IPA（情報処理推進機構）の「DX白書2023」によると、情報処理・通信に携わる人材のうちIT企業に所属している人の割合は、日本で73.6%（2020年）、米国で35.1%（2021年）です。日本ではシステムの専門家の7割以上が開発会社の側にいて、発注する側の会社にはあまりいません。

本業が忙しく、社内に詳しい人もいない。そうした会社の経営者や部門長が「開発会社に全部任せたい」と考えるのは、ごく自然なことです。

丸投げした案件で、よく起きること

一方で、何もかも任せた案件では、次のようなことが繰り返し起きています。

• 完成したものが、思っていたものと違う
• 途中で「この機能も必要だった」と分かり、追加費用がかかる
• 納期の直前になって、初めて遅れや問題が分かる
• 完成後に直そうとしたら、手元にソースコード（プログラムそのもの）も資料もなく、別の会社に頼めない
• 社内の担当者が辞めてしまい、なぜその仕様になったのか誰も分からない

一般社団法人日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査報告書2026」では、システム開発の品質・予算・工期の悪化に影響した工程として、「要件定義」（何を作るかを決める工程）を挙げた企業が57.4〜69.0%にのぼりました。作る工程である「設計・実装・テスト」（51.7〜74.1%）と並ぶ水準です。前年度の調査と比べると、工期の悪化に要件定義が影響したとする回答は8.6ポイント増えています（いずれも複数回答）。

「思っていたものと違う」「途中で機能が足りない」は、作る工程より前の、何を作るかを決める段階に原因があることが少なくありません。問題は開発会社に任せたこと自体ではなく、発注側にしか決められないことまで任せてしまったことにあります。追加費用が出る典型的なパターンはシステム開発の追加費用はなぜ発生する？で解説しています。

開発会社に丸投げできる範囲・できない範囲【一覧表】

出典: IPA（情報処理推進機構）公式サイト

外注と丸投げの違いは、作業を外に出すか、判断まで外に出すかです。設計やプログラミングを開発会社に頼むのは普通の外注で、何の問題もありません。失敗につながるのは、発注側にしか下せない判断まで開発会社に預けたときです。

では、どこからが「発注側にしか下せない判断」なのか。IPAと経済産業省が公表している「情報システム・モデル取引・契約書」（以下、モデル契約）の条文と裁判例をもとに整理すると、次のようになります。

※根拠：モデル契約（第二版）第8条・第9条・第11条・第12条・第14条・第27条・第39条、東京高裁平成25年9月26日判決、個人情報保護法第25条、厚生労働省「医療情報システムの安全管理に関するガイドライン」ほか。以下で順に説明します。

まとめると、作る・まとめる・提案するは任せてよく、決める・渡す・確かめるは発注側に残ります。反対に「どう作るか・誰が作業するか」に発注側が直接指示を出すのは、任せすぎとは逆方向の失敗です。

国のモデル契約では、「確定」と「検収」は発注側の責任者の仕事

モデル契約は、IPAと経済産業省がシステム開発の契約書のひな形として公表しているものです（第二版は2020年12月公表）。第8条は、開発会社の技術と知識の提供に加えて「甲（発注者）によるシステム仕様書の早期かつ明確な確定が重要」と書き、発注側と開発会社の双方に分担作業があるとしています。分担作業を遅らせたり実施しなかったりした場合は、相手に生じた損害の賠償も含めて責任を負う、という定めです。

第9条では、発注側が立てる責任者の「権限及び責任」として、次の9つが挙げられています（業務の言葉に置き換えています）。

1. 何を作るかをまとめた文書（要件定義書）を確定する
2. 画面や帳票など、使う人から見える部分の設計を確定する
3. 受け取るときの合格基準（検査仕様書）を確定する
4. 納品されたものを確かめて受け取る（検収）
5. 途中の資料を承認する
6. 未確定だった事項が決まったあと、文書の追加・修正を求める
7. 仕様の変更を書面で依頼する
8. 外部の製品や無償公開の部品を使ってよいかを決める
9. セキュリティの仕様を採用するかを決める

要件定義についても、第14条は開発会社が「甲による要件定義書の作成作業を支援する」と定めています。つまり、文書にまとめる作業は開発会社に頼めても、確定させるのは発注側という定め方です。受け取るときの合格基準（検査仕様書）も、第27条で発注側が開発会社と協議のうえ作成するとされています。

第二版の公表資料には、検討の過程で、発注側も「プロジェクトマネジメントを行う必要があり」、発注側が従たる役割しか負わないという「誤ったメッセージ」が伝わりかねない、という意見が出たことが記されています。発注側の委員からは、プロジェクトを続けるかどうかを最終的に決める権限は発注側にある、という意見も出ました。発注側は「手伝う側」ではなく「管理する側の一人」という整理です。

なお、モデル契約はあくまでひな形で、実際の契約書は会社ごとに違います。自社の契約書でも、責任者・確定・検収・変更の条項が誰の役割になっているかを確かめてください。

資料やデータを渡すのが遅れると、遅れは開発会社の責任にならない

見落とされやすいのが、発注側が渡す資料です。モデル契約第39条第4項は、発注側が提供した資料の内容の誤りや提供の遅れによって開発会社の作業が遅れたり、納品物に不具合が出たりした場合、開発会社はその責任を免れると定めています。

「データは後で送ります」「その帳票は現場に確認してから」と後回しにしていると、遅れた分は発注側の責任になりえます。返事に期限を付け、期限までに決まらないときの扱いを先に決めておく方法は、後の「確認が遅れたときの影響を先に決める」で説明します。

大手に任せた裁判でも、業務の分析とリスクの判断は発注側に求められた

スルガ銀行が日本IBMに勘定系システム（預金や融資を管理する中核のシステム）の刷新を依頼し、総額約90億円（89億7,080万円）で開発する合意まで結んだ計画が頓挫した事件があります。東京高裁は2013年9月26日の判決で日本IBMのプロジェクト・マネジメント義務違反を認め、損害として約41億7,210万円を認めました。

これは開発会社の側が負けた事件で、「発注側が悪かった」という例ではありません。そのうえで高裁は、企画・提案の段階について、開発会社に説明責任があるとともに、「ユーザーにもシステム開発の対象とされる業務の分析とベンダの説明を踏まえ、システム開発について自らリスク分析をすることが求められる」と述べています（ベンダは開発会社のことです）。

大手に頼んでも、開発会社には「危ないときは止めるよう伝える責任」があり、発注側には「自社の業務を分析し、リスクを判断する責任」が残ります。どちらか一方だけではプロジェクトは守れない、というのがこの判決から読み取れることです。

多くの会社も「決める工程は社内、作る工程は外」で分けている

前出のJUAS「企業IT動向調査報告書2026」（2025年度調査）は、工程ごとの内製・外部委託の実態も集計しています。

• 何を作るかを構想する工程（システム企画）：「ほぼ内製」「内製が多い」の合計が70.9%
• 必要な機能を決める工程（機能要件定義）：同じく46.1%
• 設計・プログラミング・テスト：「ほぼ外部委託」「外部委託が多い」の合計が63.4%

報告書自体も「上流工程は内製、システムづくりは外部委託が実状」とまとめています（上流工程は、何を作るかを決める工程のことです）。さらに、「完全外部委託」を方針に掲げる企業でも、システム企画の45.4%は社内が中心でした（同じ企業群で、設計・実装・テストの外部委託は84.9%）。

全部を外に出すと決めている会社でさえ、何を作るかを決める部分の半分近くは手元に残している、ということです。なお、この調査の回答は比較的規模の大きい企業が中心です。売上高100億円未満の企業では「完全外部委託」の方針が28.6%と全体（18.7%）より高く、報告書は売上高の小さい企業ほど「完全内製化」か「完全外部委託」に振り切る割合が高いと分析しています。工程ごとに社内と外を分ける考え方は、生成AIは内製と外注どちらが得かでも比べています。

丸投げに近い形で頼んでよいケース・丸投げしないほうがいいケース

線引きは同じでも、案件によって「発注側に残る判断」の重さは大きく違います。判断が軽い案件なら、丸投げに近い形で頼んでも問題は起きにくくなります。

丸投げに近い形で頼んでよいのは、決める項目が少なく、判断を誤っても影響が小さい案件です。代表は、今あるシステムに画面や帳票を足すような既存システムの改修です。当社でも、画面の追加・修正、帳票の追加、CSV出力、他のシステムとのデータ連携、既存の処理の修正を、既存システムの改修として100万円〜（税別）でお受けしています。作業別の目安と、費用が高くなる条件はシステム改修の費用にまとめています。

丸投げしないほうがいい案件は、開発会社に頼んではいけないという意味ではありません。発注側が決める項目が多く、しかも重いため、「任せたから大丈夫」にはならないという意味です。

• 複数の部門にまたがる案件：部門間でどちらの要望を優先するかは、社内の人にしか決められません。開発会社は社内の合意づくりを代わりにはできません。
• 個人情報・医療情報を扱う案件：預けた先を監督する責任が、法律やガイドラインで発注側に残ります（次の章で説明します）。
• AIの出力を業務の判断に使う案件：経済産業省の「AI・データの利用に関する契約ガイドライン」は、AIは過去のデータから傾向を学んで作られるため、初めて見るデータに対してどの程度正しく答えるかを前もって保証するのは難しい、と整理しています。性能を保証する場合も「事前に合意した評価用のデータでの正答率」に限る考え方です。「何件中何件合っていれば合格か」「どの情報をAIに渡してよいか」「どこで人が確認するか」は、開発会社が代わりに決められません。決め方は要件定義の進め方【発注側向け】で解説しています。
• 続けるか止めるかを決める人がいない案件：うまくいかない兆候が出ても誰も止められず、費用だけが積み上がります。

丸投げで見落としやすい3つの落とし穴

出典: 厚生労働省 公式サイト

1. 丸投げした先の開発会社も、さらに別の会社に出していることがある

発注側から見えにくいのが、開発会社が作業の一部をさらに別の会社に出す「再委託」です。IPAの「ソフトウェア開発分析データ集2022」では、設計から総合テストまでの作業量のうち外部に委託した割合は中央値で63.4%（562件。真ん中の半数が41.5〜79.4%に収まる）で、50〜90%の高い比率のプロジェクトが多いとされています。

このデータはIPAに提供されたプロジェクトの集計で、比較的規模の大きい開発会社の案件が中心と考えられます。中小規模の受託案件にそのまま当てはまる数字ではありません。それでも、丸投げした先の開発会社が、実際の作業の半分以上を別の会社に出していることは珍しくないとは言えます。

再委託そのものは悪いことではありませんが、誰が実際に作るのかは契約で確かめられます。モデル契約には、再委託について2つの型の条文案があります。

契約書を開発会社のひな形のまま受け入れず、再委託の条項がどちらに近いかを確認してください。個人データを扱う場合は、次に説明する監督の責任が再委託先にも及びます。

2. 任せても消えない責任がある（個人情報・医療情報）

個人情報保護法第25条は、個人データの取扱いを委託する場合、委託先に対して「必要かつ適切な監督を行わなければならない」と定めています。個人情報保護委員会のガイドライン（通則編）は、その中身を①適切な委託先を選ぶ、②委託契約を結ぶ、③委託先での取扱いの状況を把握する、の3つとしています。再委託がある場合は、再委託先への監督が行われているかも確認する必要があります。

医療機関や薬局では、さらに明確です。厚生労働省「医療情報システムの安全管理に関するガイドライン 第7.0版」（2026年6月改定）の経営管理編は、システム事業者に委託する場合も「医療機関等には委託先事業者を監督する責任がある」としたうえで、次のように書いています。

委託先事業者の過失による情報セキュリティインシデントについても医療機関等が責任を免れることはできず、医療機関等が患者等に対する責任を負う

委託する業務の内容・責任の範囲・役割分担を契約などで明確にすることも求められています。医療や薬局のシステムは、開発会社に任せても、患者に対する責任は医療機関・薬局の側に残ります。 どの情報を、どこに保存し、誰が見られるようにするかは、丸投げできない判断です。

3. 反対に、口を出しすぎると「偽装請負」と判断されうる

任せすぎの反対側にも、越えてはいけない線があります。請負や業務委託の契約では、作業する人への指示は受けた会社が行うのが前提です。モデル契約第11条も、開発メンバーの選定や作業の指示・指揮命令は開発会社が行うと定めています。

発注側が開発会社のメンバーに直接作業を指示すると、契約は業務委託でも実態は人材派遣だとして「偽装請負」と判断されうる、というのが厚生労働省の基準（昭和61年労働省告示第37号）の考え方です。厚生労働省の疑義応答集（第3集、2021年9月）は、発注側と開発会社の関係者が対等な関係にあり、開発会社の技術者が自分で判断して作業しているなら、1つのチームで密に連携しても適正な請負と評価される、という趣旨を示しています。一方で、発注側が個人を特定できる経歴書を求める、特定の人を指名したり断ったりする、といった関わり方は偽装請負と判断されうるので注意してください。

「何を作るか・どの水準で合格とするか」は発注側、「どう作るか・誰が作業するか」は開発会社の役割です。これが、任せる範囲と口を出さない範囲の境目です。契約の種類ごとの注意点はAI開発の契約形態で解説しています。

自分でAIを使って進められる作業と、開発会社に頼む作業

いまは発注側も ChatGPT・Claude・Codex などの生成AIで、業務の整理や資料づくり、簡単な試作まで進められます。開発会社に頼む範囲を考えるときは、「丸投げするか」の前に「自社でAIを使って進める部分」を切り出すと、任せる範囲と費用がはっきりします。

AIで作った下書きや試作は、そのまま開発会社に渡せる材料になります。ただし、AIは自社の例外や既存システムの細かい仕様を知りません。その会社に固有のデータの品質、既存の仕様、権限、例外、正しさの確かめ方、変更したときの責任は、AIに書かせた文書だけでは決まらないため、開発会社と一緒に確かめる部分です。AIを使っても、「この内容で作ってよい」と確定する役割は発注側に残ります。

なお、いま使っている業務ソフトやクラウドサービスの標準機能、提供元が用意している連携機能で困りごとが解決するなら、開発を頼む必要はありません。まず設定や既製の連携で足りるかを提供元に確かめ、足りない部分だけを開発の範囲にすると、費用も発注側の作業も小さくなります。

発注側に残る作業を段階ごとに見る（分担表）

業務整理から運用まで、誰が何をするか

次の表は、開発を業務整理・設計・データ準備・開発・受入・運用の段階に分け、発注側と開発会社の作業を並べた説明用の分担例です。案件によって、段階の長さや作業の量は変わります。

※目安時間は実際の案件で計った値ではありません。「打ち合わせの回数×1回の時間＋社内確認の時間」で置いた、仮定に基づく試算です。社内での資料探しや、現場の担当者への聞き取りの時間は含みません。準備や社内確認まで含めた考え方は要件が固まっていない段階で開発会社に相談する方法で紹介しています。

この試算では、開発中の発注側は週1時間ほどで、時間が増えるのは最初の業務整理と最後の受入です。丸投げしたい会社が本当に確保すべきなのは、決める人の週1〜2時間と、受入の時期に実際に使って確かめる人の時間です。

担当者が不在のときの進め方

専任の担当者を置けない会社では、「決める人」と「窓口になる人」を分けて考えると進めやすくなります。

• 決める人：優先順位・予算・確定・受け取りを決める人。社長や部門長が兼ねてもよく、週1回の確認の場に出られれば足ります。
• 窓口になる人：開発会社からの質問を受けて、現場に聞いたり資料を集めたりする人。システムの知識は要りません。決める人が兼ねても構いません。

開発会社が代わりにできるのは、質問と確認事項の一覧づくり、選択肢と推奨案の提示、議事録や決定事項の記録、期限付きの確認依頼などです。決める人が判断するまでの準備は、かなりの部分を任せられます。一方で、社内の合意をとること、現場の業務データを集めること、確定や受け取りの判断は代わりにできません。窓口になる人が1人もいないと、開発会社は質問の行き先がなくなり、作業が止まります。

担当者が休んだり辞めたりする場合に備えて、決定事項は議事録と課題一覧に残し、誰が見ても「何が決まっていて、何が決まっていないか」が分かる状態にしておくよう、開発会社に頼んでおくと安心です。

確認が遅れたときの影響を先に決める

先に見たとおり、モデル契約第39条第4項では、発注側の資料の遅れや誤りによる作業の遅れは、開発会社の責任になりません。確認が遅れると、その分の期間と、場合によっては追加の費用が発注側にかかってきます。最初の打ち合わせで次の3点を決めておくと、担当者が忙しい時期でも開発が止まりにくくなります。

1. 返事の期限：開発会社からの確認事項を「すぐ返すもの（例：2営業日以内）」と「社内の調整が要るもの（例：1週間以内）」に分ける
2. 期限までに決まらないときの扱い：開発会社の推奨案で進める、その機能を今回の範囲から外す、保留にして他の作業を先に進める、のどれにするか
3. あとから変えるときの扱い：推奨案で進めた部分をあとで変える場合は、仕様の変更として費用と期間を見積もってから判断する

期限の日数は会社ごとに決めるもので、上の日数は例です。決められなかったときにどうするかを、決める人が先に合意しておくことが大事です。そうしておけば、確認が遅れても「何が止まり、何は進められるか」を開発会社と共有できます。

受入と運用の担当を置く

完成した後の担当も、見落とされやすい点です。受け取り（検収）では、合格ラインに沿って、実際の業務の流れで使って確かめる人が要ります。開発会社のテストは「作ったとおりに動くか」を確かめるもので、「自社の業務で使えるか」は発注側でしか確かめられません。

運用に入ると、利用者の追加や権限の変更、問い合わせの受付、不具合の連絡といった作業が出てきます。誰が権限を変えてよいか、不具合をどこに連絡するかは、受入の前に決めておいてください。保守を開発会社に頼む場合も、社内で連絡を受ける人は必要です。

時間が出せないときの補い方は4つ

決める人の週1〜2時間も出せない、あるいは開発会社の説明を聞いても判断できない、という場合は、外の力で補う方法があります。

外部の専門家を入れても、決めることは発注側に残ります。この点はモデル契約の考え方とも一致します。

選び方の目安はシンプルです。何を作るかが決まっていない段階では、IT顧問や進行管理の担当者を付けても、判断する材料がないため前に進みません。その場合は④のように、決めるための材料づくりから引き受ける開発会社に頼むほうが早く判断にたどり着けます。作るものは決まっていて、開発会社との会話についていけないだけなら②、関係者が多く進行管理の作業量そのものが重いなら③が合います。

社内に担当者を置けるか、週にどれくらい時間を出せるかが分からないまま、開発を頼んでよいか迷っている場合は、その状況のままご相談ください。今の業務と体制を伺い、社内で決めること・任せること・自社でAIを使って進めることを切り分けます。

▶ 社内担当の負担を含めて進め方を相談する

開発会社に丸投げするときの費用の目安

補い方ごとに、費用の決まり方と、どこで金額を確かめるかを並べます。当社以外の顧問や進行管理の料金は会社ごとに大きく違うため、ここでは金額を載せず、確かめ方を示します。

当社の場合、クラウドの利用料、外部サービスの利用料、ソフトウェアのライセンス料は上の金額とは別にかかります。PoCの後は、評価結果をもとに、続ける・範囲を変えて続ける・止めるのどれにするかを一緒に判断します。

費用を比べるときの見方

• 最低契約期間まで含めて比べる：顧問や進行管理の外注は月額で、最低契約期間が決まっていることがあります。「月額×最低契約期間」で総額を出して比べてください。
• 任せる範囲を広げても、決める仕事は残る：判断の相談相手を付ける、進行管理の実務まで外に出す、と任せる範囲を広げるほど社外への支払いは増えます。それでも、仕様の確定・受け取り・続けるかどうかの判断は、どの形でも発注側に残ります。
• 何を作るか決まっていないなら、④が判断への近道になる：②と③は「決める人の手伝い」で、決めるための材料そのものは作りません。④の試作（PoC）は検証内容の整理から評価結果のまとめまでを含むため、発注側が決めることを「対象業務・合格ライン・進めるかどうか」に絞れます。

当社の料金に含まれる範囲や進め方は、受託開発サービスのページに載せています。要件が固まる前の段階からのご相談も受け付けています。AIを使う開発全体の費用感はAI受託開発の費用相場、試作の中身はAIのPoC費用の相場もあわせてご覧ください。

分担の例（説明用）と、当社が公開している事例

ここでは、専任の担当者がいない会社が開発を頼む場面を想定した、説明用の分担例を示します。特定の会社の実例ではありません。

説明用の例：社員30人の卸売業で、受注の書き写しをなくしたい

想定する課題：受注メールの内容をExcelに書き写し、さらに販売管理システムへ入力している。担当は事務の1人で、休むと受注の入力が止まる。社内にシステムの担当者はいない。

この例で発注側が時間を使うのは、主に最初の業務整理と最後の受入です。作る作業と資料づくりは任せられても、範囲・合格ライン・例外の扱いは社内で決めることになります。

当社が公開している事例

当社が受託開発サービスのページで公開している事例には、通信事業で数万件の請求情報を取り込んで集計し、確認する画面を作った例と、薬局で複数店舗・数千人分の記録を管理し、権限と確認の工程を設けた例があります。どちらも社名は出していません。この2件で発注側と当社がどう分担したかは、この記事では紹介していません。

丸投げに近い形で進めるときの流れと期間

出典: AI革命 公式サイト

当社の流れと、各段階で発注側が決めること

当社では、成果物と権利の扱いを契約で定めます。ソースコード、操作手順書、変更内容の記録、データ処理の流れの資料など、何を受け取り、受け取ったものをどこまで自由に直せるかを、契約の前に確かめてください。完成後に別の会社でも直せる状態にしておくことは、丸投げの失敗の代表である「完成後に直せない」を防ぐ手段です。受け取るべき納品物はシステム開発の納品物一覧で確認できます。

各段階の詳しい内容は、受託開発サービスの進め方に記載しています。

期間の目安

開発期間は、対象範囲の広さと確認工程の数によって変わるため、ご相談の際に内容を確認したうえで目安をお伝えしています。発注側の確認の返事が早いほど、期間は延びにくくなります。

丸投げしたい会社ほど、いきなり大きく発注せず、小さな範囲で任せ方を確かめてから広げるのが安全です。区切り方はシステム開発を段階的に発注する方法で解説しています。

よくある質問

Q1. 「丸投げOK」とうたう開発会社に頼んでも大丈夫ですか。

うたい文句そのものより、「決めるための材料を用意してくれる会社」か「決めることまで先に進めてしまう会社」かを見分けてください。後者は、完成後に「思っていたものと違う」が起きやすくなります。最初の打ち合わせで、①何に困っているかを聞いてくるか、②「それは今回やらなくていい」と範囲を削る提案をするか、③完成後の保守・運用の費用を最初に示すか、④受け取るときの合格ラインを誰がいつ決めるかを説明できるか、の4点を確かめると見分けやすくなります。選定時の確認項目はAI開発会社の選び方にまとめています。

Q2. 社長は決裁だけにして、現場の担当者に任せる形でも問題ありませんか。

問題ありませんが、担当者が「どこまで自分で決めてよいか」を先に文書で決めておいてください。たとえば「追加費用が発生する変更」「スケジュールが延びる変更」「新しく個人情報を扱う変更」は社長の決裁、それ以外は担当者の判断、というように線を引きます。こうしておくと、担当者が毎回社長の確認待ちで止まることも、担当者の一存で費用が膨らむことも防げます。開発会社にも、この線引きを最初に共有しておくと話が早く進みます。

Q3. すでに丸投げ状態になっているプロジェクトは、どこから立て直せばいいですか。

次の順番で進めると、状況を早く把握できます。①契約書で、責任者・確定・受け取り・再委託の条項を確認する。②開発会社に「確定している仕様」と「まだ決まっていない事項」の一覧を出してもらう。③まだ決まっていない事項のうち、発注側が決めるものに期限を付ける。④受け取るときの合格ラインを決める。⑤そのうえで、続けるか・範囲を縮めるか・止めるかを判断する。止まってしまった案件の損失の考え方はAI開発の失敗はどこで起きるかで解説しています。

Q4. ソースコードを受け取る契約にしておけば、丸投げでも安心ですか。

安心材料の1つですが、それだけでは足りません。ソースコードが手元にあっても、なぜその仕様にしたのかを説明した設計資料や、動かすための環境の情報がなければ、別の会社が引き継ぐのに時間がかかります。受け取ったものを自由に直したり使い回したりできるか、という権利の範囲も契約で確認が必要です。ソースコード・設計資料・引き継ぎ資料をセットで受け取る形にしてください。

Q5. 生成AIで要件定義書を作れば、発注側の手間はなくなりますか。

文書を作る手間は減りますが、確定させる責任は残ります。生成AIはもっともらしい文書を短時間で作れるため、自社の業務の例外や、現場でしか知らない手順が抜けていても気付きにくい点に注意が必要です。「この内容で作ってよい」と承認する前に、実際にその業務を担当している人が読み、例外の扱いや件数が実態と合っているかを確かめる時間は確保してください。

Q6. 既存システムの一部を直す改修でも、発注側の確認は必要ですか。

必要ですが、確認の量は少なくて済みます。最低限必要なのは、①どの画面・帳票・処理を変えるのかの指定、②動作確認に使うサンプルデータ、③完成後に実際の業務の流れで使ってみてから受け取ること、の3つです。ただし、画面やCSV出力を追加すると「誰がそのデータを見られるか」も変わります。患者や顧客の情報を含むデータを出力する改修では、見られる人の範囲を発注側で決めてください。

Q7. 社内にシステム担当者が1人もいない会社でも発注できますか。

発注できます。必要なのはシステムの知識ではなく、①業務の流れ・件数・例外を説明できる人と、②優先順位と予算を決められる人です。同じ人が兼ねても構いません。専門用語で要望を書く必要もなく、「毎日この作業に何時間かかっている」「この帳票を手で書き写している」といった業務の言葉で十分です。当社では、要件が固まる前の段階からご相談をお受けしています。複数社に同じ条件で見積もりを頼みたい場合は、システム開発の相見積もりとRFPテンプレートが使えます。

Q8. 発注側の作業がまったくない形で請け負ってくれる開発会社はありますか。

発注側の作業をゼロにはできません。仕様の確定、受け取り、業務の資料やデータを渡すこと、続けるかどうかの判断は、どの開発会社に頼んでも発注側に残ります。「すべてお任せで大丈夫」と言われた場合は、確定や受け取りを誰がいつ行うのかを確認してください。減らすことはできます。確認事項を選択肢と推奨案付きで出してもらう、返事の期限と決まらないときの扱いを先に決める、業務の書き出しや手順書の下書きを自社でAIを使って作る、といった方法で、決める人の時間を短くできます。

社内担当の負担を含めて、進め方を相談できます

• 開発会社に任せたいが、社内に専任の担当者を置けない
• 見積もりや提案を見ても、どこまで任せられる内容なのか分からない
• 何を作るかが決まっておらず、開発会社に何を伝えればよいか分からない

このような段階からのご相談も歓迎です。作る作業と進行の実務は当社が引き受け、発注側に残る判断については、課題の整理、選択肢と推奨案、試作の結果といった「決めるための材料」を用意します。発注側の作業をゼロにはできませんが、週ごとにどの程度の時間が要るか、どこを自社でAIを使って進められるかを一緒に切り分けます。

初回相談は無料・30分・オンライン（Google Meet）で、要件が決まっていなくても大丈夫です。相談後に、依頼範囲の候補・進め方・費用の目安をまとめた相談メモをお送りします。当社の価格は、既存システムの改修 100万円〜、PoC 300万円〜、本開発は個別見積（すべて税別。クラウドや外部サービスの利用料などの実費は別）です。相談の申し込みには、秘密情報や本番環境のパスワード、実際の顧客データを書かないでください。

▶ 社内担当の負担を含めて進め方を相談する

関連記事：要件が固まっていない段階で開発会社に相談する方法／要件定義の進め方【発注側向け】／AI開発会社の選び方／AI開発の契約形態／システム開発の追加費用はなぜ発生する？