開発会社に丸投げできる範囲・できない範囲｜任せてよい作業と社内に残る判断、時間がない会社の費用【2026年9月最新】

開発会社には、設計・プログラミング・テストといった作る作業から、要件の文書化や議事録・進捗報告などの進行の実務まで丸投げしてかまいませんが、目的と優先順位、仕様の確定、受け取るときの合格ライン、続けるか止めるかの判断は、国が公表しているモデル契約とその解説で発注側の役割とされているため任せられません。発注側に残る打ち合わせは開発中なら月2〜4時間程度（時給3,000円換算で月0.6万〜1.2万円）で、その時間も出せない場合は、IT顧問（公開されている料金の例で月5.5万円〜・税込）や、整理から引き受ける開発会社（当社の場合、試作で効果を確かめるPoCが300万円〜、既存システムの小規模改修が30万円〜、いずれも税別）で補えます。

この記事では、IPA・経済産業省のモデル契約の条文、裁判例、業界団体の調査をもとに「どこまでなら任せてよいか」を一覧表で線引きし、社内に時間がない会社が外の力で補う方法と費用を比べます。「丸投げはダメ」と言って終わる記事ではありません。任せられる部分を安心して任せるための記事です。

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

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

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項は、発注側が提供した資料の内容の誤りや提供の遅れによって開発会社の作業が遅れたり、納品物に不具合が出たりした場合、開発会社はその責任を免れると定めています。

「データは後で送ります」「その帳票は現場に確認してから」と後回しにしていると、遅れた分は発注側の責任になりえます。ある開発会社は、1件の確認が3営業日遅れるだけでも積み重なれば数週間の遅れになると指摘し、「24時間以内に返す事項」と「社内調整が必要な事項」を最初に分けておくことをすすめています。

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

スルガ銀行が日本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出力、他のシステムとの軽微な連携、既存の処理の修正を30万円〜（税別）でお受けしています。どこまでできるかはシステムの小規模改修の費用にまとめています。

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

• 複数の部門にまたがる案件：部門間でどちらの要望を優先するかは、社内の人にしか決められません。開発会社は社内の合意づくりを代わりにはできません。
• 個人情報・医療情報を扱う案件：預けた先を監督する責任が、法律やガイドラインで発注側に残ります（次の章で説明します）。
• 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開発の契約形態で解説しています。

発注側に残る時間と、時間が出せないときの補い方

発注側に残る打ち合わせは、開発中なら月2〜4時間程度

では、発注側が「決める・渡す・確かめる」ためにどれくらい時間を使うのか。ある開発会社が公開している発注側の打ち合わせ頻度をもとに、月あたりの時間に直し、時給3,000円で金額に換算しました。調査データではなく、公開されている頻度からの試算です（1か月を4週で計算）。

※要件を固める時期の4時間は「週2回×1時間×2週」、24時間は「週3回×2時間×4週」で計算しています。

これは打ち合わせだけの最低ラインで、社内での確認、資料の準備、受け取りのテストにかかる作業時間は含みません。準備や社内確認まで含めた試算は要件が固まっていない段階で開発会社に相談する方法で紹介しています。同じ開発会社は、時間がどうしても取れない場合でも「月1回の進捗確認は死守する」ことを最低限の関わり方として挙げています。

裏を返すと、丸投げしたい会社が本当に確保すべきなのは「決める人の月数時間」です。そこさえ確保できれば、残りの多くは任せられます。

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

その月数時間も出せない、あるいは開発会社の説明を聞いても判断できない、という場合は、外の力で補う方法があります。

③の「それでも発注側に残ること」は、進行管理の外注費用を解説している事業会社の記事で、社内に残すものとして挙げられている内容です。外部の専門家を入れても決めることは残る、という点はモデル契約の考え方とも一致します。

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

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

補い方ごとの費用を、公開されている価格で並べます。税込と税別が混在しているので注意してください。

当社の場合、クラウドの利用料、外部サービスの利用料、ソフトウェアのライセンス料は上の金額とは別にかかります。

数字から分かること

• 最低契約期間まで含めて比べる：上の表のIT顧問サービスでは、いちばん小さいプランでも最低6ヶ月で33万円（税込）です。月25万円のプランは最低12ヶ月なので、1年で300万円（税込）になります。
• 任せる範囲を広げるほど、費用は桁で上がる：社内で月数時間を確保すれば社外への支払いは0円、判断の相談相手を付けると月5.5万円〜、進行管理の実務まで外に出すと月60万円〜です（いずれも上の表の公開価格の例）。それでも、仕様の確定・受け取り・続けるかどうかの判断は、どの形でも発注側に残ります。
• 何を作るか決まっていないなら、④が判断への近道になる：②と③は「決める人の手伝い」で、決めるための材料そのものは作りません。④の試作（PoC）は課題の整理から本開発の提案までを含むため、発注側が決めることを「対象業務・合格ライン・進めるかどうか」に絞れます。

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

実際にやった事例｜何を任せていただき、何を決めていただいたか

守秘の関係で社名は出せません。当社が担当した3件を、「開発会社に任せていただいたこと」と「発注側に決めていただいたこと」に分けて紹介します。

調剤薬局のケース：直し方は任せ、「今のシステムは残す」を決めていただいた

課題：使っている業務システムからデータを書き出し、Excelで加工して、別のシステムや管理表へ手で書き写す作業が毎日発生していました。担当者が休むと業務が止まり、繁忙期には書き写し漏れも起きていました。どこまで直すべきかが決まっておらず、他社からは基幹システムの入れ替えを含む提案も出ていました。

任せていただいたこと：今の作業の流れとデータの確認、直し方の設計、仕組みの開発とテスト。

決めていただいたこと：「既存のシステムは残す」「対象は毎日発生している書き写しの1か所だけ」という、やること・やらないことの線引き。

作ったもの：既存システムはそのままに、データの取り込みと加工、次のシステムへの受け渡しを自動で行う仕組み。新しいシステムは導入していません。

何が変わったか：書き写しの作業と、書き写しのミスを探して直す時間がなくなり、担当者が休んでも業務が流れるようになりました。全社的なシステム刷新にしていれば、同じ困りごとでも半年単位の案件になっていました。発注側に決めていただいたのは、範囲に関する2点だけです。

医療機関のケース：試作は任せ、「対象業務」と「合格ライン」を決めていただいた

課題：蓄積された文書や記録は多いのに、必要な情報を探すのに時間がかかっていました。AIで効率化したい業務の候補は複数ありましたが、どれから手を付けるか社内で決められず、全部を対象にすると費用も期間も膨らんで稟議にかけられない状態でした。

任せていただいたこと：試作（PoC）の設計と開発、現場での検証、結果の整理と本開発の概算見積もり。

決めていただいたこと：候補の中から1業務に絞ること。そして着手の前に、「どの質問に、どの水準で答えられたら合格とするか」を文書で決めること。

作ったもの：手元の資料をAIに読ませ、質問すると根拠となる箇所を示しながら答える仕組み。

何が変わったか：合格ラインが先に決まっていたため、試作の結果を見て、拡大するかどうかを短期間で判断できました。本開発に進む範囲も、現場の言葉と数字で社内に説明できるようになりました。

インフラ企業のケース：つなぐ作業は任せ、「最終判断は人に残す」を決めていただいた

課題：複数の社内システムにまたがるデータを人が突き合わせて確認しており、件数が多く、月末に負荷が集中していました。

任せていただいたこと：各システムからデータを取り出せるかの確認、システム間のデータを自動で照合する仕組みの設計と開発。

決めていただいたこと：つなぐシステムの範囲と、つなぐ先が増えた場合の追加費用の扱い。そして、全件の可否を自動で判定させるのではなく、食い違いがあった分の最終判断は人に残すこと。

作ったもの：システム間のデータを自動で照合し、食い違いがある分だけを人に回す仕組み。

何が変わったか：全件を人が見る運用から、例外だけを人が見る運用に切り替わり、月末に集中していた負荷が平準化されました。途中で業務側の要望が増えても、追加費用をその場で計算できる状態を保てました。

3件とも、作る作業は開発会社が担い、範囲・合格ライン・人に残す判断という発注側にしか決められない事柄は、発注側が先に決めています。丸投げがうまくいくかどうかは、任せた量ではなく、この数少ない判断を手放さなかったかどうかで決まります。

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

出典: AI革命 公式サイト

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

納品物は、契約内容に基づき、GitHubリポジトリ（ソースコードの保管場所）、ソースコード、設計資料などを引き渡します。完成後に別の会社でも直せる状態にしておくことは、丸投げの失敗の代表である「完成後に直せない」を防ぐ手段です。受け取るべき納品物はシステム開発の納品物一覧で確認できます。

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

期間の目安

当社の開発期間は、対象範囲の広さと確認工程の数によって変わるため、ご相談時に内容を確認したうえで目安をお伝えしています。一般的な目安としては、ある開発会社が小規模で1〜3ヶ月、中規模で4〜8ヶ月、大規模で8ヶ月〜1年以上という規模別の期間を公開しており、工期全体の20〜25%を要件定義に充てるのが適切としています。

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

よくある質問

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

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

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

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

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

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

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

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

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

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

Q6. 30万円程度の小規模改修でも、発注側の確認は必要ですか。

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

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

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

「何を決めればいいか」から相談できます

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

このような段階からのご相談をお受けしています。作る作業と進行の実務は当社が引き受け、発注側に残る判断については、課題の整理や選択肢、試作の結果といった「決めるための材料」を用意します。

当社の価格は、既存システムの小規模改修 30万円〜、PoC 300万円〜、本開発は個別見積（すべて税別）で、初回相談は無料です。医療機関・調剤薬局・インフラ企業での開発実績があります。

▶ 受託開発の詳細・無料相談はこちら

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