システム開発会社の選び方・費用相場ガイド【発注企業向け】｜受託開発・DX・費用相場・契約形態
最終更新日：2026/08/06
目次
業務システムや基幹システムの受託開発から、DX・内製化の支援、ローコード活用、稼働後の保守運用まで、システム開発の依頼先は担当できる範囲も料金の考え方も会社ごとに大きく異なります。だからこそ、発注側が個社を比べ始める前に、費用のおおよその相場観と「何を基準に選ぶか」という物差しを先に持っておくと、判断がぶれにくくなります。
このガイドでは、発注側の視点でシステム開発会社を選ぶための共通の考え方を整理したうえで、地域別のおすすめ記事への入口としてご案内します。
1. システム開発会社とは？受託開発・SES・SIer・DXコンサルの違いと、なぜ今外注が増えるのか
開発会社を選ぶ前に、任せたい仕事と依頼先の役割を分けて考えることが、比較の出発点です。受託開発、SES、SIer、DXコンサルは似た言葉に見えても、任せられる範囲と責任の持ち方が違います。まず地図をつかむことで、自社が外部に求めるものを言語化しやすくなります。
依頼先を見分ける四つの型
| 型 | 主に外注するもの | 依頼時に押さえる見方 |
|---|---|---|
| 受託開発会社 | 業務システムや基幹システムなど、決めた要件に沿う成果物 | 必要な機能を形にして納品してほしい案件に向きます。 |
| SES・客先常駐 | 開発・保守に必要なエンジニアの稼働 | 人材のスキル提供が中心で、完成した成果物そのものを任せる形とは異なります。 |
| SIer | 複数の製品・サービスを組み合わせた導入、連携、運用 | メーカー系、ユーザー系、独立系などがあり、多層の体制で受託することもあります。 |
| DXコンサル・IT導入支援 | 業務整理、デジタル化の方針、ツール選定の助言 | 何を作るか・買うかが固まっていない段階で、判断材料を整える役割です。 |
受託開発は、仕事の完成を目的に成果物を作って納品する契約です。対してSES・客先常駐は、準委任として一定の業務を担う人材のスキルや稼働を得る形であり、完成責任を前提に比較するものではありません。
SIerは自社製品だけでなく、複数の技術やベンダーを束ねてシステムを導入する例も見られます。DXコンサル・IT導入支援は、開発そのものよりも「どの業務を変えるか」「どの手段を選ぶか」を整理する段階に強みがあります。契約類型ごとの責任や注意点は第4章、DX支援・内製化支援の進め方は第9章で扱います。
外注が選択肢になる背景
こうした流れが広がっているのは、単に開発会社が便利だからではありません。自社だけで今のシステムを保守しながら新しい業務改善まで担うことが難しくなり、外部の専門性を使う判断が現実的になっているためです。
- 老朽化・複雑化した既存システムは、維持保守の負担や技術的負債を抱えやすくなります。経済産業省のDXレポートが示した「2025年の崖」は、こうしたレガシーシステムを放置したリスクを問題提起したものです。IPA「DX動向2024ディスカッション・ペーパー」
- DXへの取組は広がる一方、従業員100人以下の企業では、知識や情報の不足が非着手理由として大きく挙げられています。社内に専任の情報システム担当者を置きにくい企業ほど、外部と一緒に検討を進める意味があります。IPA「DX動向2024」
- DX推進人材は、情報通信業以外の多くの業種で不足感が強く、採用だけで必要な体制をそろえることは容易ではありません。IPA「深刻化するDXを推進する人材不足と課題」
ただし、外注は「社内に人がいないから丸ごと任せる」ためだけの手段ではありません。現場の業務知識と意思決定は発注側が持ち、設計・開発・運用の知見を外部と補い合えるかが、依頼後の成果を左右します。
最初に決める外注の目的
比較を始める前に、「何を・誰に外注するのか」を一文で置いてみてください。目的が曖昧なまま会社名や価格だけを比べると、提案の良し悪しを判断しにくくなります。
- 既存の業務を置き換える仕組みを作りたいなら、受託開発を軸に考えます。
- 社内チームの開発・保守の手を補いたいなら、SESの活用範囲を検討します。
- 複数システムの連携や全体導入を進めたいなら、SIerの体制や調整力を確認します。
- 課題はあるが、作るべきものや導入すべきツールが決まっていないなら、DXコンサルやIT導入支援から始めます。
この段階では、依頼先を一つの型に固定する必要はありません。業務整理は支援会社、開発は受託会社、日常の改修は社内と外部人材で分担するように、目的に応じて役割を組み合わせる考え方が役立ちます。費用の見方は第6章、具体的な比較・選定の進め方は後続章で確認してください。
2. そもそもスクラッチ開発すべきか？パッケージ/SaaS・ローコード・内製化まで含めた開発手段の選択
システム開発会社に依頼するとき、本当のゴールは「システムを作ること」ではありません。業務の課題が解決し、その後も無理なく運用し続けられる状態を、できるだけ安く低いリスクで手に入れることが目的で、作るかどうかはそのための手段の一つにすぎません。だからこそ発注の前に、スクラッチで作る以外の選択肢まで机の上に並べ、どれが自社の状況に合うかを使い分ける必要があります。
「作ること」を目的にしない
作れば成果が出るわけではありません。IPAの調査では、本格的なDXで成果が出ている企業は約2割にとどまる一方、承認や集計といった定型業務の効率化では過半数の企業が成果を出していると報告されています（IPA『DX動向2024』）。既製の手段で足りる領域は既製で済ませ、独自に作る投資は競争優位の中核へ集中させるのが定石になります。
作った後のコストも見落とせません。2025年度にIT予算が増えた理由の最多は「既存システム・基盤の刷新・更新・増強」で66.3%を占めました（JUAS『企業IT動向調査2026』）。独自に作ったシステムは、完成した瞬間から維持と刷新の負担が始まります。「そもそも作るべきか」を最初に問うのは、この下流の負担まで含めて総額を見るためです。
五つの開発手段
発注の選択肢は受託スクラッチだけではありません。業務の性質に応じて、次の五つを土台に組み合わせて考えます。
| 開発手段 | 効くとき | 注意点 |
|---|---|---|
| スクラッチ受託 | 競争優位の中核になる独自要件を、自社の業務に合わせて作り込むとき | 費用と、開発後の維持・刷新の負担が最も大きい |
| パッケージ・ERP／SaaS | 会計や勤怠のような標準業務。製品に業務を寄せるFit to Standardで安く早く整う | 独自運用を捨てる割り切りが要る。作り込みすぎると安さと速さの利点が消える |
| ローコード／ノーコードで内製 | 小規模で変更頻度が高い業務。現場が自分の手で直したいとき | 大規模・複雑な基幹には不向き。無秩序に増えるとシャドーITの温床になる |
| SES・ラボ型で体制を借りる | 要件が固まりきらず、継続的に開発し続けるとき | 進行管理と品質の責任は自社に残る |
| DX支援を受けて内製化 | 外注依存から抜け、自社で作り運用できる体制をつくりたいとき | 立ち上がりに時間がかかる（詳細は第9章） |
使い分けの判断軸
手段を選ぶ物差しは、業務の標準度、競争優位性、変更頻度と規模、そして自社のIT体制です。標準的な業務ほど既製に寄せ、独自性が競争優位に直結する部分だけを作り込むのが基本になります。
- 標準度が高い業務（会計・勤怠・経費など）は、SaaSやパッケージで足ります。クラウドを全社または一部で利用する企業は77.7%に達し、標準業務の受け皿は十分に育っています（総務省『令和6年版 情報通信白書』図表8）。
- 競争優位の中核は、標準品では代替できません。ここだけをスクラッチや内製で作り込み、それ以外は既製に任せます。
- 変更頻度が高く規模が小さい業務は、ローコード内製が向きます。外注に頼っていた頃は数万円の小改修でも1週間から1か月待たされたのが、内製化後は表示条件の変更ならその日のうちに反映できたという実践報告があります（Zenn（一人情シスの実践記事））。
- 自社にIT体制がなければ、SES・ラボ型で人を借りるか外注に頼ることになります。デジタル化に取り組む企業は大企業75.5%に対し中小企業は30.1%にとどまり、体制の有無で取れる手段が変わります（総務省『令和6年版 情報通信白書』図表37）。
そのうえで、外注を既定にしないことも軸になります。日本はシステム開発を主に外部ベンダーへ委託する企業が58.6%と過半を占め、自社エンジニア中心は41.3%にとどまります。内製が主流の米国（自社中心91.0%）とは対照的で（総務省『令和6年版 情報通信白書』図表43）、「作るなら外注」という思い込みを一度外して手段を並べ直す価値があります。
作って失敗する典型
手段の選定と上流の設計を誤ると、作ったシステムは使われないまま費用だけが膨らみます。当事者が語る失敗には共通の型があります。
- 安さで選び、範囲を確認しなかった例。当初200万円の契約が、業務ヒアリングや要件修正、テスト運用サポートを「契約外」として次々加算され、最終的に500万円超に膨らんだと当事者が振り返っています（note（久保田一氏））。
- スコープが膨らんだ例。「シンプルな社内文書管理」が高度検索やワークフロー、モバイル対応まで広がり、予算と納期が2倍になったと、10年以上現場でプロジェクトリーダーを務めた筆者が挙げています（note（obara_ai1122））。
- 発注者が要件追加を止められなかった例。旭川医科大学病院のシステム開発は開始後に追加要望が相次ぎ、1000を超える追加要件が出された末に頓挫しました（＠IT）。裁判では大学による一方的な契約解除が問われ、控訴審は大学へ約14億円の支払いを命じています（デイライト法律事務所）。
- ローコードでも設計を省けない例。基幹アプリのローコード刷新で、全体を統括するPMが不在のまま主キー設計やデータ移行ルールが曖昧なまま進み、識別子に不向きなメールアドレスを顧客IDに使う危うい設計に置き換わっていたという記録があります（Qiita（NestRec））。
いずれも技術より前の、手段選定と要件の握り方でつまずいています。安さや手軽さだけで手段を決めず、どこまでが範囲か（見積範囲と責任の分界）を最初に固めることが、埃をかぶるシステムを避ける近道になります。
外注そのものにも、発注者としての責任が伴います。システム開発の外部委託は下請法（現・中小受託取引適正化法）の対象で、発注者は発注書面の交付などの義務を負い、代金の不当な減額や買いたたきは禁じられます（公正取引委員会）。個人データの取扱いを任せる場合は、個人情報保護法により委託先を適切に選び監督する義務も生じます（個人情報保護委員会）。「低リスクで手に入れる」には、作る手段だけでなく、任せた後に自社へ残る責任まで見ておく必要があります。
定型業務は作らず自動化
そもそも独自開発の対象から外せる領域もあります。承認・申請・稟議・進捗管理のように、会社が違っても形の似た定型業務です。
こうした業務は、ゼロから作るより既製のワークフローシステムに載せる方が、早く安く仕上がり運用も安定します。開発手段を具体的に絞り込む前に、定型業務は既製サービスで代替できないかを確かめておくと、作る範囲そのものを小さくできます。このあとに、主要なワークフローシステムを条件別に比較できる一覧を用意しました。気になる製品は資料請求や一括比較から、自社の業務に合うかを確かめられます。
「作る」前に、承認・申請・進捗管理などの定型業務なら既製のワークフローシステムで自動化できる場合もあります。スクラッチ開発の前に、以下のワークフローシステム比較もあわせてご検討ください。
「ワークフローシステム」の製品比較表
※税込と表記されている場合を除き、全て税抜価格を記載しています
-
- 簡単UI・高機能WF
-
-
- 初期費用 要相談 備考
- 共有サーバープラン、占有サーバープラン、占有サーバープラン[クラスタ2台構成]は初期費用0円です。エンタープライズは要件に応じて異なります。
- 共有サーバープラン 20,000円～/月額 備考
- 初期設定が簡単で、20～50名程度の企業に最適なコストパフォーマンスの高いプランです。手軽に利用を開始したい企業向けのソリューションです。最小ユーザー数は20ユーザーです。
- 占有サーバープラン 80,000円～/月額 備考
- 専用環境でセキュリティとパフォーマンスを強化しています。大規模データ処理やカスタマイズが必要な企業向けです。最小ユーザー数は50ユーザーです。
- 占有サーバープラン[クラスタ2台構成] 110,000円～/月額 備考
- 冗長化により高可用性を実現し、業務継続性を重視する企業に最適なプランです。最小ユーザー数は20ユーザーです。最小ユーザー数は50ユーザーです。
- エンタープライズ 510,000円～/月額 備考
- 社外ユーザーを安価に追加できるため、取引先やパートナー企業との連携に適したプランです。コストを抑えつつ、柔軟なユーザー管理が可能になります。最小ユーザー数は500ユーザーです。
- 1年
-
-
-
-
- クラウド型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- 人数無制限！大手向き
-
-
- [クラウド版]初期費用 0円 備考
- 初期費用は発生しません。
- [クラウド版]Standard 300,000円/月額
- [クラウド版]Prepaid 3,420,000円/年額
- [パッケージ版]Standard 初期費用 2,400,000円 備考
- 追加可能な同時ユーザーライセンス数は200アカウントです。
- [パッケージ版]Standard サポートサービス価格 360,000円/年額
- [パッケージ版]Enterprise 初期費用 3,600,000円 備考
- 追加可能な同時ユーザーライセンス数は無制限です。
- [パッケージ版]Enterprise サポートサービス価格 540,000円/年額
- 制限なし
-
-
-
-
- クラウド型ソフト パッケージ型ソフト
- PCブラウザ スマートフォンブラウザ iOSアプリ Androidアプリ
- 電話 / メール / チャット /
-
- 電子印鑑で承認を効率化
-
-
- Shachihata Cloud ワークフロー Lite 月額1,200円 備考
- 税抜、10ユーザー毎
- Shachihata Cloud ワークフロー Standard 月額3,200円 備考
- 税抜、10ユーザー毎
- Shachihata Cloud ワークフロー Advance 月額4,000円 備考
- 税抜、10ユーザー毎
- Shachihata Cloud グループウェア 月額1,500円 備考
- （税抜、10ユーザー毎）
グループウェアをワークフロー基本プランと同時に購入した場合は、月額1,000円（税抜、10ユーザー毎）で購入可能。
- 1年
-
-
-
- クラウド型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- 複雑なワークフロー業務に柔軟に対応
-
-
- 初期費用 要相談
- 料金 要相談
- 制限なし
-
-
-
- クラウド型ソフト オンプレミス型ソフト パッケージ型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- SaaS×AIで効率化
-
-
- フリー ¥0 備考
- 月額ライセンス料 ¥0/名＋タスク実行料金 ¥0/タスク
自分の業務を自動化したい方のために - スタンダード ¥1,200~/名＋¥0.64~5/タスク 備考
- 月額ライセンス料 ¥1,200~/名＋タスク実行料金 ¥0.64~5/タスク
より多くのことを自動化したいパワフルなチームのために - プロ ¥1,600~/名＋¥0.64~5/タスク 備考
- 月額ライセンス料 ¥1,600~/名＋タスク実行料金 ¥0.64~5/タスク
業務フロー全体を変革する企業のために
- 制限なし
-
-
-
- クラウド型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- 中小企業向けDXツール
-
-
- 初期費用 0円 備考
- 初期費用は発生しません。
- グループプラン 3,200円/月額 備考
- 基本プラン（5人まで）です。
- アカウント数変更オプション 800円/1アカウント 備考
- 6人以上のアカウントが必要な場合に基本プランに追加できます。
※5アカウントごとの追加
- 1ヶ月
-
-
-
- クラウド型ソフト
- PCブラウザ
- 電話 / メール / チャット /
-
- 低コスト運用できる
-
-
- 初期費用 0円 備考
- 初期費用はかかりません。
- 利用料金 1ユーザーあたり500円/月
- 制限なし
-
-
-
-
- クラウド型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- 人事×ワークフロー
-
-
- 初期費用 要相談
- 月額費用 要相談
- 12か月～
-
-
-
-
- クラウド型ソフト
- PCブラウザ スマートフォンブラウザ iOSアプリ Androidアプリ
- 電話 / メール / チャット /
-
- 月額220円から
-
-
- 初期費用 30,000円 備考
- 単独利用の場合に発生します。
- 基本料金 2,000円/月額 備考
- ユーザー数10ユーザーまで、ディスク容量1GBまでです。
- 超過料金 2,000円/10ユーザー毎
- 超過料金 1,000円/ディスク容量500MB毎
- 制限なし
-
-
-
- クラウド型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- 導入1,700社以上
-
-
- 初期費用 要相談
- Standard 要相談 備考
- 旅費・経費精算ワークフロー（交通費・旅費精算申請/交通費・旅費仮払申請/立替経費精算/経費仮払申請/会議・交際費仮払申請/支払依頼/海外出張/部門決裁）と、フリースタイルワークフロー（Web申請書/Excel申請書/ナビゲート機能/フリースタイルデザイナー）が利用できるプランです。
- Enterprise 要相談 備考
- 旅費・経費精算ワークフロー（交通費・旅費精算申請/交通費・旅費仮払申請/立替経費精算/経費仮払申請/会議・交際費仮払申請/支払依頼/海外出張/部門決裁）と、フリースタイルワークフロー（Web申請書/Excel申請書/ナビゲート機能/フリースタイルデザイナー）、勤怠管理ワークフロー（就業管理/シフト管理/タイムレコーダー連携）が利用できるプランです。
- 1年
-
-
-
- クラウド型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- Googleサイト上で運用可能
-
-
- 初期費用 要相談
- 無償版 0円 備考
- 広告表示あり・その10ユーザーまで・機能制限あり・サポートなしとなります。
- 有償版 100円/月額 備考
- 1ユーザーあたりの料金です。
- 1年
-
-
-
- クラウド型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- 最短1週間で導入可能
-
-
- 初期費用 0円 備考
- 初期費用は発生しません。
- 利用料金 3,000円～/月額 備考
- 添付ファイル基本10GB込み、10ID単位の料金です。
- 多言語翻訳利用料 30,000円～/月額 備考
- 別途初期費用90,000円が発生します。
- 不明
-
-
-
- クラウド型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- マニュアル不要の稟議
-
-
- 初期費用 0円 備考
- 初期費用は発生しません。
- 利用料金 300円/月額 備考
- 1ユーザーあたりの料金です。
- 導入サポートプラン 100,000円/16時間 備考
- 契約した時間内で、フォーム作成、ワークフロー作成、各種マスターデータ作成などの初期設定をサポートするプランです。
※1フォーム、1ワークフロー作成は8時間程度が目安です。 - 運用サポートプラン 100,000円/月額 備考
- 定期的なマスタメンテナンス業務やフォーム改版などを代行するプランです。
- ストレージ追加プラン 月額1,000円/10GB 備考
- 1ドメイン（契約）に対してストレージ上限の追加ができるプランです。
※標準ストレージ 10GB/1ドメインです。最大ストレージは200GB/1ドメイン（標準10GB＋追加190GBまで）です。
- 3ヶ月
-
-
-
- クラウド型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- 大企業の業務を自由に
-
-
- 初期費用 要相談
- 利用期間 要相談
- 不明
-
-
-
- クラウド型ソフト
- PCブラウザ スマートフォンブラウザ iOSアプリ Androidアプリ
- 電話 / メール / チャット /
-
- 勤怠から工数管理まで
-
-
- 初期費用 要相談
- チムスピ勤怠 400円/1人 備考
- 月額20,000円/50ライセンス～のプランです。
- チムスピ工数 300円/1人 備考
- 月額15,000円/50ライセンス～のプランです。
- チムスピ経費 300円/1人 備考
- 月額15,000円/50ライセンス～のプランです。
- チムスピMix 600円/1人 備考
- チムスピシリーズから2製品が選べるプランです。
月額30,000円/50ライセンス～ - チムスピMix+ 800円/1人 備考
- チムスピシリーズから3製品が選べるプランです。
月額40,000円/50ライセンス～です。
- 1年
-
-
-
- クラウド型ソフト
- PCブラウザ iOSアプリ Androidアプリ
- 電話 / メール / チャット /
-
- 2000人以上もOK
-
-
- 初期費用 0円 備考
- 初期費用は発生しません。
- 1ID 400円/月額 備考
- 基本料金とセットです。
- 基本料金 2,500円/月額 備考
- 基本料金はID単位ではなく、1契約単位になります。フリーフォーム作成、承認ルート作成、申請機能、申請書作成、承認機能、検索・閲覧機能、滞留防止機能、CSV出力、コメント機能、モバイル利用、クレーム報告、文書管理が可能です。
- 制限なし
-
-
-
- クラウド型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- 会社と稟議が共に成長
-
-
- 初期費用 0円
- クラウドサービス基本料金 5,000円/月額/10ID
- 1年間
-
-
-
- クラウド型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- Excelをそのまま電子化
-
-
- 初期費用クラウド版 0円
- 初期費用オンプレミス版 要相談
- 要相談 要相談
- 制限なし
-
-
-
- クラウド型ソフト オンプレミス型ソフト
- なし
- 電話 / メール / チャット /
-
- 最短10分で設定完了
-
-
- 初期費用 要相談
- 月額プラン(後払い) 300円/月額 備考
- 1人あたりの料金です。
- 年額プラン(前払い) 3,000円/年額 備考
- 1人あたりの料金です。月額利用料の２ヶ月分を割り引いた金額です。
- 制限なし
-
-
-
- クラウド型ソフト
- なし
- 電話 / メール / チャット /
-
- Google Workspaceと連携
-
-
- 初期費用 0円
- rakumo ワークフロー 月額500円/1ID 備考
- ご利用には 「Google Workspace（有料版）」 が必要です。
- オプション：Active Directory 連携ツール 600,000円
- オプション：ユーザー詳細 CSV アップローダー 120,000円
- オプション：API オプション 初期導入費：180,000円 APIごとの利用料：15,000円 / 年
- オプション：超過利用時の追加購入 50GB分 （年間15,000円）/150回分 （15,000円） 備考
- ・ローカルファイル添付：添付ファイルが10GBの利用を超過した場合
50GB分 （年間15,000円）
・ZIP ダウンロード：申請書の一括ダウンロードが150回の利用を超過した場合
150回分 （15,000円）
- 1年間
-
-
-
- クラウド型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- 累計ユーザー数20,000名突破
-
-
- AppRemoクラウド ユーザー数50 Standard 741,000円/年間
- AppRemoパッケージ版 ユーザー数50 500,000円 備考
- 年間保守サポート価格は75,000円です。
- AppRemoクラウド ユーザー数400 Standard 2,097,600円/年間
- AppRemoパッケージ版 ユーザー数400 2,280,000円 備考
- 年間保守サポート価格は342,000円です。
- AppRemoクラウド ユーザー数1,000 Standard 4,423,200円/年間
- AppRemoパッケージ版 ユーザー数1,000 5,000,000円 備考
- 年間保守サポート価格は750,000円です。
- 制限なし
-
-
-
- クラウド型ソフト オンプレミス型ソフト パッケージ型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- DX統合パッケージ
-
-
- お問い合わせ お問い合わせ
- 制限なし
-
-
-
- クラウド型ソフト パッケージ型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- シリーズ連携が強み
-
-
- 有料プラン 300円/月額 備考
- ユーザー1名の価格です。
- 500名以上 別途ご相談
- 制限なし
-
-
-
- クラウド型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- Google・Microsoftと連携
-
-
- 初期費用 0円
- Basic プラン 月額費用(1ユーザーあたり)400円 備考
- ・Microsoft 365 または、Google Workspaceと連携します。
・製品サポート、導入利活用支援の費用は含まれています。
・従業員25名未満の企業・団体さまはご相談ください。
- Business プラン 月額費用(1ユーザーあたり)500円 備考
- ・Microsoft 365 または、Google Workspaceと連携します。
・ワークフローの基本機能とチャットツールへの通知や基幹システム等とのデータ連携が可能です。
・製品サポート、導入利活用支援の費用が含まれています。
・従業員25名未満の企業・団体さまはご相談ください。
- Premium プラン 月額費用(1ユーザーあたり)1,200円 備考
- ・Microsoft 365 または、Google Workspaceと連携します。
・ワークフローの基本機能とチャットツールへの通知や基幹システム等とのデータ連携が可能です。
・テストテナントの環境をご提供します。
・製品サポート、導入利活用支援に加え、定期的な運用コンサルの費用が含まれています。
- 1年
-
-
-
- クラウド型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- 人事と繋がる経費精算
-
-
- 初期費用 0円 備考
- 初期費用は発生しません。
- 利用料金 29,000円～/月額 備考
- 月額費用は利用者数によって変わります。
- 制限なし
-
-
-
- クラウド型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- グループウェアと連携
-
-
- クラウドプラン お問い合わせ
- パッケージプラン お問い合わせ
- 制限なし
-
-
-
- クラウド型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- 紙をそのまま画面に
-
-
- クラウド版 500円/月 備考
- 1ユーザーの価格です。
- パッケージ版 50ユーザー60万円～ 備考
- 1ユーザーの価格です。
- 制限なし
-
-
-
- クラウド型ソフト パッケージ型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- マウス操作でかんたん
-
-
- 基本ライセンス 要相談
- クラウド 基本料金 10,000円/月額 1ユーザ料金 500円/月額
- 1年間
-
-
-
- クラウド型ソフト オンプレミス型ソフト
- PCブラウザ スマートフォンブラウザ
- 電話 / メール / チャット /
-
- 業務が360°回る
-
-
- 初期費用 50,000円 備考
- 1 契約での価格です。NI Collabo 360 またはnyoibox のみの場合は0円になります。
- NI Cloud Service 328円～/月額 備考
- 表示価格は1名あたりの値段です。
その他さまざまな追加オプションがあります。 - パッケージ製品 要相談
- 6か月
-
-
-
- クラウド型ソフト パッケージ型ソフト
- PCブラウザ iOSアプリ Androidアプリ
- 電話 / メール / チャット /
-
- オールインワンでDX
-
-
- 初期費用 0円 備考
- 初期費用は発生しません。
- クラウド版 600円/月額~ 備考
- クラウド版のプランです。契約ユーザー数は5ユーザーからです。
- パッケージ版ライセンス 75,000円~ 備考
- パッケージ版のプランです。基本ライセンスは、5ユーザーから利用できます。
- 1ヶ月
-
-
-
- クラウド型ソフト パッケージ型ソフト
- PCブラウザ スマートフォンブラウザ iOSアプリ Androidアプリ
- 電話 / メール / チャット /
価格や製品機能など、見やすい一覧表から、気になる製品をまとめてチェック!
3. どこまで任せるか＝対応工程の設計（要件定義から一括か、実装だけか）
委託先選びの前に、開発工程のどこを自社で決め、どこから支援・委託するかを定めます。要件定義から任せる場合でも、発注者が業務の目的・優先順位・判断者を手放すと、完成後に「想定と違う」状態になりやすいためです。
委託範囲は工程で決める
システム開発は、要件定義から設計、実装、テスト、移行、運用・保守へ進みます。最初に見極めるべきなのは、開発会社へ何を作らせるかだけではありません。業務上の課題を整理する段階から伴走を求めるのか、自社で要件と設計を固めて実装を委託するのかを、工程ごとに決めます。
| 工程 | 主な決定事項 | 発注者が担う役割 |
|---|---|---|
| 要件定義 | 目的、対象業務、必要な機能、優先順位 | 現場の事実と業務上の判断を示す |
| 外部・内部設計 | 画面、帳票、データ、連携、処理方法 | 業務に合うかを確認し、例外を判断する |
| 実装・単体テスト | プログラムや設定の作成、部品単位の確認 | 設計どおりに進めるための判断を返す |
| 結合・システムテスト | 連携、性能、権限、異常時の確認 | 実際の業務条件で確認観点を提示する |
| 移行・運用保守 | データ移行、教育、障害対応、改修 | 運用ルールと受入条件を決める |
ソフトウェア開発工程では、要求分析から仕様記述、設計、実装、評価、配備、保守までを連続した一連の工程として位置づけています。工程を一括で任せるか、要件定義・設計・実装などで区切るかは、社内にある業務知識、判断できる担当者、既存資料の質で決めるとよいでしょう。IPAのモデル取引・契約書も、開発を複数契約として扱う考え方を示しています。契約類型そのものは第4章で確認します。
上流を丸投げしない理由
顧客の要求は、最初から完成した仕様として存在するとは限りません。要求分析では、要求が不完全、曖昧、相互に矛盾することがあると説明されています。現場が「入力を減らしたい」と言っていても、管理部門は証跡を増やしたい場合のように、正しい要望同士が衝突することもあります。
この整理をせずに上流工程を丸投げすると、営業、SE、開発者の間で言葉だけが渡り、背景にある業務上の意図が薄れていきます。画面や機能は仕様どおりでも、現場が使い続けられないシステムになるのはこのためです。要件定義は、必要な機能や性能を明らかにする上流工程であり、完成物の方向を決める分岐点になります。要件定義の内容を誰が決め、誰が承認するかを曖昧にしないことが先決です。
また、上流の判断はテスト時の受入基準につながります。V字モデルでは、要件分析とユーザー受入テスト、設計と各テスト工程が対応づけられます。自社が要件を決めるなら、「何ができれば業務で使えるのか」を受入時に判定する責任も持つことになります。V字モデルを踏まえ、要件ごとに確認方法と承認者を置いておくと、完成間際の認識違いを減らせます。
上流の持ち方を選ぶ
自社に業務責任者と十分な資料があり、対象業務・例外処理・連携先・移行方針まで説明できるなら、要件定義や設計を自社主導で進め、実装以降を委託する選択ができます。その場合は、完成条件が曖昧なまま「作ってみて判断する」としないことが必要です。
一方、業務が属人化している、現行システムの仕様が不明、部門間で優先順位を決められない場合は、上流から開発会社の支援を受けるほうが現実的です。ただし、力を借りることと判断を渡すことは別です。開発会社には論点の整理、業務ヒアリング、選択肢の提示を求め、自社は優先順位、例外の扱い、変更の承認を担います。IPAも、後続の開発範囲外の支援業務をコンサルティングとして依頼できること、発注者側の協力が必要であることを解説しています。IPA「モデル取引・契約書 見直しのポイント」
- 現場の実務を説明できる責任者は誰か
- 業務フロー、帳票、データ、例外処理の資料はどこまであるか
- 部門間で優先順位が割れたとき、誰が決めるか
- 既存データ、外部連携、権限設定の前提を確認できるか
- 完成後の受入テストを、実務担当者と実施できるか
これらに答えにくい場合は、実装だけの委託を急がず、要件整理の支援から始めるほうが安全です。ローコードや内製化支援でも同じで、作成速度が上がっても、業務ルールやデータの識別方法が未整理であれば問題は残ります。
RFPに残すべき判断
実装中心で委託する場合も、発注者は要求を言語化して渡す必要があります。RFPは、開発会社に提案を依頼するための書面で、システム概要、技術的要件、納期などを記載するものです。提案依頼書（RFP）を完璧な仕様書にする必要はありませんが、少なくとも次の判断は発注者側で残します。
- 導入の目的と、解決したい業務上の問題
- 対象部署、利用者、対象外にする業務
- 必須機能と、後回しにできる要望
- 既存システム・データ・外部サービスとの関係
- 移行の対象、利用開始時に守るべき業務条件
- 提案時点で未確定の事項と、その決定者
個人データを扱うシステムでは、委託先に任せきりにせず、委託先の安全管理措置、契約内容、取扱状況を確認する必要があります。個人情報保護法上、委託元には委託先への必要かつ適切な監督が求められます。個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」
工程の切り分けができれば、開発会社へ尋ねるべき内容も明確になります。次章以降では契約、費用、開発会社の見極め方をそれぞれ確認し、この章で定めた委託範囲に照らして比較してください。
4. 請負か準委任(ラボ型)か＝契約形態の選び方（成果物責任・偽装請負・多段階契約）
請負と準委任の分かれ目は、発注側が成果物の完成保証を得られるかどうかにあります。要件が固まった案件なら完成を約束させる請負、要件がこれから動く・作りながら磨く案件なら業務の遂行そのものに対価を払う準委任（ラボ型）が基本の軸になります。どちらが優れているという話ではなく、自社の要件がどれだけ固まっているかで向き不向きが決まります。ここでは両者の法的な違いと、開発手法・工程ごとの使い分け、そして「業務委託」という俗称に潜む偽装請負のリスクまでを、発注側の判断材料として整理します。
請負は仕事の完成に責任
請負は「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払う」契約です（民法第632条）。本質は仕事の完成にあり、発注側は約束どおり動くものが出来上がるという完成保証を得られます。完成しなければ報酬は原則発生せず、納品後に不具合があれば契約不適合責任を追及できます。2020年施行の改正民法では従来の瑕疵担保責任がこの契約不適合責任に置き換わり、修補や損害賠償に加えて報酬減額請求権が救済手段として明文化されました（IPA 情報システム・モデル取引・契約書（第二版））。
完成を約束する構造ゆえに、ベンダーは自らの責任で下請けを使って完成させることもできます。これが多重下請け構造の法的な土台です。なお発注側も、開発を外部委託した時点で情報成果物作成委託の委託事業者として、下請法（現・取適法）上の書面交付などの義務を負う場合があります（公正取引委員会「取適法の概要」）。要件が明確に固まり、成果物と検収基準を先に決められる案件ほど、請負一括は発注側にとって扱いやすい形になります。逆に要件がまだ揺れているのに請負で総額を固めると、追加のたびにどこまでが契約に含まれるかを巡る摩擦が起きやすくなります。見積範囲や責任分界を確かめず安さだけで請けさせ、着手後のヒアリングや要件修正、リリース前サポートを次々に契約外として加算され、当初の見積を大きく上回る額へ膨らんだという当事者の記録もあります（note（久保田一氏））。
準委任は完成義務なし
準委任は、システム開発のような事実行為の委託に委任の規定を準用する契約です（民法第656条）。請負のような仕事の完成義務はなく、受任者が負うのは善良な管理者の注意をもって委任事務を処理する義務、いわゆる善管注意義務です（民法第644条）。専門家として誠実に手を動かすこと自体が債務であり、発注側は完成そのものの保証までは得られません。裏を返せば、ゴールがまだ見えない探索的な開発でも、走りながら方向を修正できる柔軟さがあります。
準委任なら成果連動の報酬設計も可能です。2020年改正で明文化された成果完成型では成果の引渡しと同時に報酬を支払う形が認められ（民法第648条の2）、稼働時間や工数に応じて払う履行割合型と選べます。もう一つの実務的な違いが中途終了時の扱いです。準委任は開発が途中で終わっても、すでに行った履行の割合に応じて報酬を請求できます（民法第648条第3項）。完成を報酬の条件とする請負とは、ここが根本的に異なります。ラボ型はこの準委任を土台に、一定期間ベンダーの開発体制を継続的に確保していく契約形態です。
| 比較軸 | 請負 | 準委任（ラボ型） |
|---|---|---|
| おもな根拠 | 民法632条 | 民法656条・644条 |
| ベンダーの債務 | 仕事の完成 | 善管注意義務にもとづく業務遂行 |
| 完成保証 | 得られる | 得られない |
| 不具合の責任 | 契約不適合責任を追及できる | 原則として善管注意義務の範囲 |
| 中途終了時 | 原則、完成しないと報酬なし | 既履行分を請求できる |
| 向く案件 | 要件が固まった案件 | 要件が流動する継続開発・アジャイル |
開発手法と契約の対応
契約類型の選択は、採用する開発手法と表裏一体です。仕様を先に固めて順番に作るウォーターフォールは、完成物を先に定義できるため請負と相性がよく、要件定義から設計・製造・テストまでを一括で請け負う形を取りやすくなります。一方、優先度の高い機能から作って評価と修正を繰り返すアジャイルは、そもそも最終形を先に確定させない前提なので、完成を約す請負にはなじみません。
IPAのアジャイル開発向けモデル契約は準委任を前提とし、成果物の完成に対して対価を払う請負契約ではなく、ベンダーが専門家として業務を遂行すること自体に対価を払う構造を採ります（IPA 情報システム・モデル取引・契約書（アジャイル開発版））。その代わり発注側はプロダクトオーナーを立て、開発チームが必要とする情報提供や意思決定、社内関係者の調整を適時に行う責務を負います。要件を動かせる自由と引き換えに、意思決定の権限委譲と関与が発注側に求められる点は、契約前に社内で握っておく必要があります。
工程で分ける多段階契約
実務では、開発全体を一つの契約類型で通すとは限りません。IPAのモデル契約は、工程ごとに請負と準委任を使い分ける多段階契約の考え方を示しています（IPA 情報システム・モデル取引・契約書（第二版））。要件がまだ定まらない要件定義工程は準委任、仕様が固まった後の設計・製造は請負、というように、完成保証を求める工程だけを請負にする組み方です。要件が流動する段階を無理に請負で固めないための、現実的な折衷案といえます。
この使い分けを誤ると、発注側の姿勢そのものが法的な火種になります。旭川医科大学病院の病院情報システム開発では、稼働開始後も現場からの追加要望が相次ぎ、出された追加要件が千件を超えても開発が収束せず頓挫しました（＠IT）。続く裁判では、一審がベンダー側の責任を重く見たのに対し、控訴審は発注者による一方的な契約解除を問題視して発注者の請求を退け、逆に発注者へ約14億円の支払いを命じています（デイライト法律事務所）。契約類型の選択とあわせて、要件追加を誰がどう統制するかを決めておかないと、発注側が責任を問われる側になり得ます。
偽装請負と「業務委託」の罠
契約書の表題より、現場の指揮命令の実態が優先されます。請負や準委任として発注しても、発注側が相手先の技術者へ直接指示を出して働かせると、偽装請負として違法になり得ます。職業安定法施行規則は、請負を労働者供給とみなさない要件として、作業の完成に事業主として全責任を負うこと、労働者を自ら指揮監督すること、使用者としての義務を自ら負うこと、自らの設備や専門的技術で作業することを挙げています（職業安定法施行規則第4条）。発注側が技術者を直接指揮するとこの要件を欠き、契約の名前が何であれ、実態は労働者供給と評価されかねません。
ここで気をつけたいのが「業務委託」という言い方です。これは法律上の契約類型ではなく、請負や準委任をまとめて指す俗称にすぎません。業務委託だからという言葉は、成果物への責任があるのか、指揮命令をどちらが持つのかを何も語っていません。契約書の表題ではなく、完成義務の有無と指揮命令の所在という中身で、請負なのか準委任なのかを見極める必要があります。日々の指示を誰が出すのかは、偽装請負を避けるうえでも先に決めておくべき論点です。
5. 委託先タイプの選び分け（得意領域別／大手SIer〜専門特化・オフショア・多重下請けvs自社一貫開発）
委託先は知名度や単価だけでなく、「作りたいもの」と「自社が担える判断・運用」を基準に選びます。第2章で決めた開発手段と案件の難しさを起点に、必要な業務知識、体制規模、責任の持ち方が合うタイプへ絞り込むと、見積額と進め方を比較しやすくなります。
開発手段から委託先を絞る
同じ業務システムでも、既存基幹との連携や大量データ処理が中心なのか、現場の申請・管理業務を素早く改善したいのかで、求める会社は変わります。まず「どの技術が使えるか」ではなく、案件で失敗できない部分を言語化してください。
| 案件の中心 | 優先して見る得意領域 | 候補になりやすい委託先タイプ |
|---|---|---|
| 基幹システム刷新、ERP、複数部門・外部システム連携 | 業務設計、移行計画、統合テスト、長期運用 | 大手SIer、中堅独立系、業界特化型 |
| 顧客向けWebサービス、業務Webアプリ | UI設計、クラウド、継続的な改善、API連携 | 中堅独立系、Web・業務アプリ特化ブティック |
| スマートフォンを使う現場アプリ | モバイルUI、端末検証、バックエンド連携 | モバイル特化ブティック、Web系開発会社 |
| 申請、案件管理、集計などの業務改善 | ローコード設計、権限設計、運用ルール、内製移管 | ローコード特化会社、DX伴走・内製化支援 |
| クラウド移行、監視、障害対応を含む継続運用 | クラウド設計、セキュリティ、監視、保守窓口 | クラウド特化会社、保守運用体制を持つ開発会社 |
ローコードを選ぶ場合も、データの主キー、外部連携、権限、移行ルールまで設計できる相手かどうかを見定めます。画面を早く作れることと、業務システムとして安全に運用できることは別の能力です。ツールの利用料と開発・運用費を分けて比べると、予算の見通しも立てやすくなります。たとえばkintoneの公式料金やPower Appsの公式料金では、利用者数に応じた月額料金が公開されています。
規模と形態ごとの選び分け
会社規模は品質の保証ではありません。案件の不確実性、求める専門性、自社のプロジェクト管理力に対して、過不足のない体制かを見ます。
大手SIer
大規模な基幹刷新、複数ベンダーをまたぐ統合、厳格なセキュリティや監査対応が必要な案件で候補になります。上流から大人数の体制を組みやすい反面、その分のコストが見積もりに反映されやすく、実装が再委託される場合もあります。提案書では、実際に誰が要件定義・設計・開発・運用を担うのかを工程別に把握してください。
中堅独立系
業務システム、業務アプリ、クラウド開発まで幅広く見比べやすいタイプです。技術選定や意思決定の柔軟さが持ち味になりやすい一方、得意領域と要員の厚みには会社差があります。自社に近い業種・規模の実績だけでなく、その案件で投入予定の責任者と技術者の経験をつかんでおくと、判断しやすくなります。
専門特化ブティック
モバイル、EC、データ基盤、特定クラウド、ローコードなど、技術や領域が明確な案件に向きます。課題と採用技術が合えば、少人数でも深い知見を得られます。ただし、基幹連携や24時間対応まで必要な場合は、対応範囲と不足部分を補う体制を先に確かめる必要があります。
オフショア・ラボ型
継続的に開発量があり、仕様・レビュー・受入テストを自社または国内側の責任者が安定して回せる案件で検討しやすい形態です。単価だけで決めず、日本語で要件を橋渡しする担当者、時差を含む連絡方法、品質基準、ソースコードの管理権限などを事前に洗い出しておきます。ベトナムのプログラマー人月単価を40.1万円、ブリッジSEを59.0万円とする調査を参考値として挙げますが、実際は職種や国、管理体制によって差があります。オフショア開発.comの2026年調査
DX伴走・内製化支援
業務部門が継続的に改善し、自社で判断・運用できる状態を目指す場合の選択肢です。このタイプの進め方と見極め方は第9章で扱います。
価格は体制と責任で読む
見るべきなのは総額だけではありません。受託開発は人月単価と工数を軸に組まれるため、見積書では役割別の単価、人数、稼働月数、成果物、変更時の扱いをそろえて比べます。初級SEは60万〜100万円、上級SEは100万〜160万円程度が一般的な目安とされますが、技術の難度や責任範囲によって幅があります。システム開発費用の相場解説
安い見積もりが不適切とは限りませんが、要件定義、テスト、データ移行、教育、リリース後の問い合わせ対応が見積範囲から外れていれば、後から比較不能な追加費用になります。「何を納品すれば完了か」と「誰が判断・検収するか」を明文化し、工程に応じて請負と準委任を使い分ける考え方もあわせて押さえておきます。IPA「情報システム・モデル取引・契約書（第二版）」
多重下請けを見抜く質問
元請けから再委託が重なると、発注者から見た責任者と実際の開発者が離れ、仕様変更や障害時の判断が遅れやすくなります。再委託そのものを避けるのではなく、責任分界と情報共有が管理されているかを見極めることが肝心です。
- 契約相手の社員が、要件定義・設計・品質管理のどこまでを直接担いますか。
- 再委託先は何社あり、各社の担当工程と最終責任者は誰ですか。
- 仕様変更、障害、セキュリティ事故が起きた際に、誰が発注者への一次窓口と判断を担いますか。
- ソースコード、設計書、クラウド契約、本番環境の管理権限は、契約終了後も自社に引き継げますか。
- 開発担当者と、定例・レビュー・受入テストで直接会話できる体制ですか。
個人データを扱うなら、委託元には委託先を必要かつ適切に監督する義務があります。開発会社だけでなく再委託先を含め、アクセス権、データの保管場所、事故時の連絡、監査方法を、契約前に点検してください。個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」
自社一貫開発と保守体制
「自社一貫開発」とは、提案だけでなく設計・実装・品質確認・保守までを同じ会社が責任を持ってつなぐ体制を指します。全員が自社社員であることだけを意味するものではないため、再委託の有無より、窓口・品質責任・技術資産の所在が明確かで判断します。
保守は開発後に付け足す契約ではありません。障害一次対応、監視時間、脆弱性対応、バックアップ、軽微改修の上限、問い合わせ窓口、引継ぎ資料を、開発契約と同時に見ておきます。年間保守費は開発費の約15％程度が目安という解説もありますが、監視や対応時間、改修範囲を含むかどうかで金額は大きく変わります。割合の妥当性より、含む作業を一覧化して比較するほうが実務的です。システム保守費用の相場解説
ここまでの基準で候補タイプを決めた後は、地域別のおすすめ記事で、同じ条件に合う具体的な委託先候補と比較観点をご覧ください。
6. 費用相場は「人月単価 × 規模 × 契約形態」で読む
開発費は総額だけで比べず、「人月単価×必要工数×期間」と契約形態に分けて読むと、自社案件に対する見積もりの妥当性を判断しやすくなります。業務・基幹システムの費用は機能数だけで決まるものではありません。誰が、どの工程を、何人月担当するかを確認し、規模と契約の前提をそろえて比較することが大切です。
費用を決める三つの要素
受託開発費の大半は人件費です。費用全体の約8割を人件費とする解説もあり、まずは「人月単価×必要人数×開発期間」に、サーバーなどの固定費を加える構造として見積書を読みます。発注ナビ「システム開発費用の相場解説記事」、nocoderi「業務システム開発の費用」
| 見る要素 | 見積もりで確認すること |
|---|---|
| 人月単価 | PM、上流SE、開発者など、役割別の単価と配置人数 |
| 規模・工数 | 要件定義、設計、実装、テストの人月と開発期間 |
| 契約形態 | 成果物を固定額で完成させる請負か、稼働工数を精算する準委任か |
人月単価の読み方
国内の人月単価は、上流工程やマネジメントほど上がる傾向があります。たとえばGxO「SES単価の相場ガイド」では、PMは月額100〜150万円、上流対応SEは80〜120万円、SEは65〜90万円、PGは55〜80万円の目安を示しています。別のXincere「システム開発の人月単価」でも、PM90〜150万円、SE60〜100万円、PG40〜80万円とされています。
したがって、「月80〜120万円」といった単価だけで高い・安いと決めるのではなく、その金額が上流SEなのか、実装中心のPGなのかを見極めてください。AI、特定言語、業界固有の業務知識など、必要なスキルによっても単価は動きます。
オフショア開発は、国内単価の3分の1〜半額程度、すなわち国内比で概ね2〜5割減となる場合があるという見方もあります。Xincere「システム開発の人月単価」ただし、仕様伝達やレビューの手戻りで工数が増えると差額が縮むため、単価差だけで判断せず、日本側の管理体制と要件の固まり具合も見ます。
規模別レンジの当てはめ
業務システムの開発費は、小規模50〜300万円、中規模300〜1,000万円、大規模1,000〜5,000万円、超大規模5,000万円以上という規模別の目安があります。対応する工数・期間も、小規模は1〜3人月・1〜2か月、中規模は4〜10人月・2〜6か月、大規模は10〜50人月・6か月〜1年と幅が生じます。みんなのシステム開発「システム開発の費用相場」
スクラッチで業務システムを作る場合は、小規模100〜300万円、中規模300〜800万円、中〜大規模800万円〜数千万円という目安も見られます。nocoderi「業務システム開発の費用」日報のように対象業務を絞った仕組みと、複数部門・複数権限をまたぐ総合管理システムでは、同じ「業務システム」でも必要工数が大きく変わります。
基幹システムは、クラウド型なら月額5万〜30万円程度を軸に導入費を加える形、オンプレミス型なら初期投資が数千万円規模になり得る形として、費用構造を分けて比較します。従業員規模別の初期費用は、50名以下で100〜500万円、51〜300名で500〜3,000万円、301名以上で3,000万円〜1億円以上という目安が示されています。みんなのシステム開発「基幹システムの費用ガイド」
請負と準委任の違い
請負は成果物の完成に対して報酬を定める契約で、見積もりは固定額として読みます。対して準委任は作業の遂行を委託し、月ごとの稼働工数に応じて精算する契約です。要件が固まり、仕上げる範囲を明確にできる工程は請負、要件整理や伴走支援のように作業量が変わり得る工程は準委任という考え方が使われます。LASSIC「準委任契約と請負契約の違い」
見積比較では、請負なら成果物・受入条件・対象外を、準委任なら月額単価・予定人月・体制・報告方法をそろえます。工程ごとに請負と準委任を使い分ける考え方は、IPA「情報システム・モデル取引・契約書(第二版)」も整理しています。
見積もり比較の質問
- この総額は、役割別に何人月を配置した計算でしょうか。
- 要件定義からテストまで、各工程の工数と担当範囲はどこまで含まれますか。
- 請負の場合、完成の判定基準と受入条件はどのように定義されていますか。
- 準委任の場合、月ごとの上限工数と、超過時の判断手順はどうなりますか。
- クラウド利用料やローコード基盤の料金は、開発費と分けて示されていますか。
ローコード・内製化支援では、開発費とは別に基盤の利用料も確認します。たとえばkintoneは1ユーザー月額1,000〜3,000円、Power Apps Premiumは1ユーザー月額2,998円、Power Automate Premiumは1ユーザー月額2,248円の公開料金です。kintone公式料金ページ、Microsoft Power Apps公式価格ページ、Microsoft Power Automate公式価格ページ利用者数、外部連携、権限設計を前提に、月額がどこまで増えるかを試算してから比較します。
コーポレートサイト制作やECサイト構築の単価は、業務・基幹システム開発とは要件と費用構造が異なるため、この章の相場には含めません。該当する場合はWeb制作の選び方、ECサイト構築の選び方を参照してください。追加費用、保守運用費、ベンダーロックインを避ける契約上の確認点は、第7章で扱います。
7. 追加費用・保守運用費と「ベンダーロックイン」を避ける費用ロジック
開発費の総額は、契約時の見積額だけでは決まりません。要件の漏れ、変更の扱い、保守範囲、引き継げない設計が重なると、導入後まで費用が増え続けます。発注前に「何が追加になるか」「誰が判断できる状態を保つか」を決めておくことが、総額と選択肢を守る判断軸になります。
総額が跳ねる三つの場面
追加費用は、ベンダーが不当に請求する場合だけに起きるものではありません。当初の見積範囲にない業務、未確定だった仕様、運用開始前に判明した例外対応を実装するなら、作業が増えるためです。追加開発は人月単価60万〜120万円程度とされ、要件が曖昧な案件では最初の見積の10〜30％、大きい場合には約50％まで膨らむ例も紹介されています。@SOHO「システム開発の追加費用トラブル」
- 要件定義後に「この業務も当然含まれる」と判明し、画面・権限・帳票・連携を追加する場面です。
- 開発中に仕様変更を繰り返し、変更のたびに設計、実装、テストをやり直すケースです。
- リリース直前になって、データ移行、マニュアル、教育、監視、障害時の連絡体制が見積外だったと分かることもあります。
たとえば500万円で始めた案件でも、追加対応が月100万円相当で3か月続けば800万円になります。これは相場の予測ではなく、変更工数を都度積み上げたときの計算です。「軽微な変更」の単価、最低工数、テスト費、リリース作業費を見積時に確認しないと、小さな依頼ほど判断しづらくなります。
追加請求の責任分界
発注側が負うべきなのは、業務目的、利用者、現行の困りごと、例外処理、承認者を決め、確認期限までに判断することです。一方で、要件を実現するための設計上の前提、抜け漏れを発見するための見極め方、変更時の影響と費用を説明することは、開発側にも求められます。要件を渡しただけで完成形が共有されたとは限りません。
| 契約前に決める項目 | 確認する内容 |
|---|---|
| 見積範囲 | 対象業務、画面、帳票、外部連携、移行、テスト、教育、マニュアルの含有範囲 |
| 変更手順 | 誰が依頼し、影響・金額・納期を誰が承認してから着手するか |
| 検収条件 | どのデータ・操作・性能なら完了とするか。未決事項は別表で残すか |
| 追加単価 | 職種別単価、最低請求単位、調査・テスト・リリース作業の扱い |
請負と準委任では費用の増え方も異なります。工程ごとに契約形態を使い分ける考え方や、契約不適合時の整理は、IPA「情報システム・モデル取引・契約書（第二版）」も参照できます。追加作業を口頭で始めず、変更票で範囲・見積・納期・承認者を残す運用にすると、後からの認識違いを減らせます。
保守費を総額で見る
保守運用費は、開発費に含まれるとは限りません。年間保守費の目安としては開発費の約15％、または標準的な契約で10〜15％、手厚い対応で15〜20％以上という紹介があります。たとえばその開発費が1,000万円なら、年150万円前後から200万円程度を別途見込む考え方です。実際の金額は対象範囲で変わるため、割合だけで契約せず、発注ナビ「システム保守費用の相場」、JCC「システム開発の保守・運用費用の相場と内訳」を目安に内訳を比較します。
保守契約で分ける費目
- 障害の受付時間、初動時間、復旧目標、原因調査の範囲
- 監視、バックアップ、OS・ミドルウェア更新、セキュリティ対応
- 法改正や外部サービス変更への追随
- 小改修の月間枠、超過時の単価、改修後のテストと文書更新
- クラウド、ライセンス、外部APIなど利用量で変動する費用
「保守費が安い」提案でも、障害対応だけで改修・更新・文書整備が別料金なら、必要な作業を先送りしやすくなります。その結果、仕様や運用が分からないまま使い続ける塩漬け状態になり、改修や再構築の判断が重くなります。契約時点で年額だけでなく、3〜5年分の保守、利用料、見込まれる改修費を合算して比較するのが実務的です。
ロックインを生む情報不足
ベンダーロックインは、特定の会社を選んだこと自体ではなく、発注側が仕様・データ・運用判断を引き継げない状態から始まります。設計書を省略したまま進めること、独自技術への依存、業務ルールや改修経緯の属人化は、他社の見積や保守を難しくします。価格改定や改修提案を比較できなくなるリスクは、宗創堂「ベンダーロックインとは？」でも整理されています。
内製化は、すべてを自社で開発することではありません。業務ルールと優先順位を自らの手で決め、設計書・データ定義・運用手順を読める状態にし、日常の設定変更と大規模改修を切り分ける選択肢です。ローコードでも、データ設計、外部連携、移行ルールが曖昧なら依存は残ります。
契約時に確保する引き継ぎ物
- 要件定義書、基本・詳細設計書、データベース定義、API・外部連携仕様
- ソースコード、ビルド・デプロイ手順、テスト結果、障害・変更履歴
- クラウド契約、ドメイン、管理者アカウント、監視・バックアップの管理権限
- データの出力形式、移行手順、契約終了時の引き継ぎ支援と費用
納品物、第三者への開示・改修に必要な利用権、文書更新の責任を契約に明記します。主要部分で広く使われる技術や標準的なデータ形式を選べるかも確認材料になります。C3「ベンダーロックインを防ぐには？」が示すように、契約前に成果物と権利を定義するほうが、導入後に乗り換えを検討するより判断しやすくなります。
費用を抑える発注順序
まず第3章で扱う要件の整理を行い、「今回作るもの」と「将来検討するもの」を分けます。次に第4章の契約形態に沿って、仕様が固まった部分と探索が必要な部分を分離します。そのうえで、保守の対象、変更単価、引き継ぎ物を見積・契約書に落とし込みます。会社ごとの提案力や体制の見極めは第8章で確認してください。
対象となるITツールや申請時期によっては、デジタル化・AI導入補助金を検討できる場合があります。2026年度の通常枠にはソフトウェア、クラウド利用料、導入設定、保守サポートなどが該当し得る区分がありますが、対象ツールや要件は公募年度ごとに変わります。申請前にデジタル化・AI導入補助金2026および通常枠の公式案内で最新の公募要領を確認し、補助金ありきで要件や事業者を決めないことが大切です。
8. 失敗しない選び方＝発注準備(RFP)・相見積りで聞くこと・見極めチェック
失敗を減らす鍵は、同じRFPを複数社に渡し、提案内容と実行体制を共通の基準で比べることです。価格だけでなく、自社の業務を理解して要件定義から伴走できるか、誰が実装・保守するかまで見極めると、発注後の認識違いを防ぎやすくなります。
発注前に決める判断基準
会社探しを始める前に、「何を作るか」だけでなく「どこまで任せ、社内は何を担うか」を整理します。基幹刷新、既存業務の改善、ローコードによる内製支援、保守の引継ぎでは、求める相手の役割が異なるためです。
- 事業・業務の目的：処理時間の短縮、二重入力の解消、データ活用など、導入後に確かめられる到達点を決めます。
- 対象範囲：関係する部署、業務、利用者、既存システムとの連携、移行が必要なデータを切り分けます。
- 社内体制：業務判断者、日々の窓口、受入テスト担当、運用責任者を明確にします。IT専任者が少ない場合は、要件整理や運用設計まで支援できる会社が候補になります。
- 優先順位：納期を優先するのか、段階導入を許容するのか、将来の内製化を重視するのかを共有します。
案件が大きくなるほど、上流工程やプロジェクト管理の力量がQCDに影響しやすくなります。特に要件が固まり切っていない基幹刷新では、実装力だけでなく、現場ヒアリングから要件を整理して合意形成を進める力を見極めます。JUAS「企業IT動向調査2026」の分析も、PM・上流工程の組織能力が計画遵守に大きく関わると示しています。
会社を見極める六つの視点
| 確認する視点 | 見るべき内容 | 相見積りでの質問例 |
|---|---|---|
| 得意領域 | 自社と近い業務、規模、既存環境での支援実績 | 「似た業務で、どの課題をどう整理しましたか。今回と異なる前提はありますか」 |
| 対応工程 | 要件定義、設計、移行、教育、運用改善のどこから関われるか | 「要件が未確定の項目は、誰がどの手順で決めますか」 |
| 実行体制 | PM、業務担当、設計者、実装者、保守担当の役割と経験 | 「提案時の担当者は開始後も参画しますか。交代時の引継ぎ方法は何ですか」 |
| 自社開発性 | 再委託の範囲、実装担当の所属、品質責任の所在 | 「体制図に全員の所属と担当工程を示せますか。再委託先の管理方法は何ですか」 |
| 保守体制 | 障害受付、一次対応、原因調査、改修提案、引継ぎ資料の整備 | 「リリース後に誰が窓口となり、業務を理解した担当者へどうつなぎますか」 |
| 対話の質 | 専門用語を並べず、現場の例外運用や判断理由まで聞く姿勢 | 「現場ヒアリングで、確認漏れを防ぐために何を成果物として残しますか」 |
提案書に技術名や開発実績が多くても、自社案件への当てはめが弱ければ判断材料になりません。「一般論として可能か」ではなく、「今回の現行業務・制約・移行条件で、何を先に確認するか」を説明してもらいます。技術者のスキルを見極めたい場合は、担当領域に応じて、情報処理技術者試験や情報処理安全確保支援士などを補助的な目安にできます。ただし、資格の有無だけで案件適合性を判断しないことが大切です。
RFPで条件をそろえる
RFP（提案依頼書）は、発注側の考えを完成させた設計書ではありません。各社が同じ前提で提案・見積りできるよう、目的、制約、未決事項、評価方法をそろえるための文書です。共通のRFPを配布しない相見積りでは、各社が異なる範囲を前提にするため、提案の優劣を正しく比べられません。
RFPに残すべき項目
- 背景と解決したい業務課題、導入後のゴール
- 対象業務・利用者・拠点と、今回除外する範囲
- 現行の業務フロー、帳票、Excel運用、既存システムや外部サービスとの連携
- 必要な機能と、性能、権限、可用性、監査、バックアップなどの非機能要件
- データ移行の対象、品質上の懸念、切替後に並行運用が必要かどうか
- 希望する進め方、社内の意思決定者、定例会や受入テストへの参加条件
- 提案に求める体制図、工程別の成果物、前提条件、未確定事項、リスクと対応案
- 提案の評価方法と提出期限
RFPには、決め切れていない内容も「未決」として記載します。曖昧なまま各社に解釈を委ねるより、提案側に確認事項・選択肢・判断期限を出してもらう方が、発注後の行き違いを減らせます。RFPの代表的な記載項目はRFP（提案依頼書）の解説も参考になります。
基幹刷新の訪問時に聞くこと
数社に訪問してもらう場では、会社案内を聞く時間を短くし、自社案件の不確実性をどう扱うかに質問を集中させます。提案の完成度よりも、問題の捉え方、確認の順序、責任分界の明確さに差が出ます。
- 現行業務の例外処理や属人化を、どのように発見して要件へ反映するか。
- 要件が未確定のまま進められない箇所はどこか。先に誰が決めるべきか。
- 既存データの重複・欠損・表記ゆれを、いつ、誰が、どの基準で整えるか。
- 移行失敗や切替遅延が起きた場合、どの状態まで戻せるようにするか。
- 現場・管理者・経営層で意見が割れたとき、合意をどう記録して判断するか。
- ローコードを使う場合、標準機能、追加開発、社内で変更する部分をどう線引きするか。
- 保守へ移る際に、仕様書、ソースコード、設定値、運用手順、管理権限を誰へ引き継ぐか。
回答が「対応可能です」にとどまる場合は、過去案件の固有情報を伏せたうえで、実際の進め方と成果物の例を求めます。特にデータ移行や外部連携は後半で問題化しやすいため、初期段階から調査方法と判断責任を固めておきます。
品質と脆弱性の確認
品質の確認は「テストします」という回答だけでは足りません。どの要件を、誰が、どの環境で確かめ、問題が出たときにどう記録・修正・再チェックするかを、RFPと提案の両方で詰めておきます。
- 業務シナリオ単位の受入テストを誰が作成し、合格条件をどう決めるか。
- 単体・結合・総合・移行・障害復旧の各テストで、何を証跡として残すか。
- 権限ごとの閲覧・更新範囲、操作ログ、データの保存期間をどう検証するか。
- 脆弱性診断、修正判定、リリース後の脆弱性情報への対応窓口をどう定めるか。
- 障害時の連絡経路、一次切り分け、復旧判断、再発防止報告の流れをどうするか。
Web機能を含む案件では、SQLインジェクション、アクセス制御の不備、クロスサイト・スクリプティングなど、想定する脆弱性への対策を確認項目に落とし込みます。その観点にはIPA「安全なウェブサイトの作り方」を使えます。個人データを扱う場合、委託元には委託先を必要かつ適切に監督する責任があるため、選定時だけで終わらせず、契約後どう点検するかも取り決めます。個人情報保護委員会のガイドラインを基準に、選定、契約、定期的な見直しの進め方を整理しておきます。
比較表で提案を判定する
面談直後の印象だけで決めず、各社の提案を一枚の比較表に転記します。評価者ごとに採点して差が大きい項目を話し合うと、「提案が分かりやすかった会社」と「実務に適した会社」を混同しにくくなります。
| 評価項目 | 確認の基準 |
|---|---|
| 業務理解 | 自社の課題、例外運用、現場の負担を提案へ反映しているか |
| 要件定義力 | 未決事項、確認手順、意思決定者、成果物が具体的か |
| 体制の透明性 | 担当者、所属、再委託範囲、責任者、交代時の対応が明確か |
| 品質の進め方 | テスト、移行、障害対応、セキュリティ点検の手順が現実的か |
| 保守の継続性 | リリース後も業務知識を維持し、改善相談まで扱える体制か |
| 対話と説明 | 不都合な前提やリスクも説明し、質問に具体的に答えるか |
発注先が個人データやプログラム作成を受託する場合は、取引条件を書面で明確にします。情報成果物作成委託には、発注者側の書面交付などの義務や禁止行為が定められています。詳細は公正取引委員会「取適法の概要」で確認できます。選定時に押さえた体制・成果物・連絡方法を発注時の文書にも引き継ぐことが、認識違いを抑える土台になります。
9. DX支援・内製化支援という選択肢（受託開発・ITコンサルとの違いと伴走型）
DX支援・内製化支援は、外部に作業を任せきるのではなく、自社が業務を設計し、改善を続ける力を残すための選択肢です。受託開発、ITコンサルティング、伴走型支援は似て見えても、依頼後に誰が判断し、何が自社側に残るかが異なります。変化の多い現場や競争に直結する領域では、完成物だけでなく、社内で改善を回せる状態まで求めるかを考えます。
三つの支援形態の違い
| 形態 | 主な役割 | 自社に残りやすいもの |
|---|---|---|
| 受託開発 | 合意した要件に沿ってシステムを作り、納品する | 完成したシステム、設計書、運用手順 |
| ITコンサルティング | 課題整理、構想、IT方針や導入計画を助言する | 構想、ロードマップ、意思決定の材料 |
| DX・内製化支援 | 業務改善と開発を進めながら、企画・開発・運用のやり方を社内へ移す | 判断基準、業務知識を反映する仕組み、担当者の実践経験 |
受託開発が適するのは、要件と責任分界を固めたうえで、特定の機能やシステムを外部の専門チームに任せたい場面です。ITコンサルティングは、何を変えるべきか、どの選択肢を取るべきかを決める前段に向きます。DX・内製化支援は、その間を埋めるものではなく、構想を実行に移しながら自社の担当者が判断と改善を担えるようにする進め方です。
伴走型が必要になる場面
現場の運用が変わり続け、最初に決めた仕様だけでは十分でない業務では、納品をゴールにすると改修のたびに社外への説明と判断が必要になります。IPAのDX動向2025では、日本は競争領域を含むシステム調達で外部委託による開発を選ぶ割合が高く、内製化を進める際の最大の課題として人材の確保・育成が挙げられています。
ここでいう内製化は、すべてを自社だけで開発することではありません。業務の優先順位を決める人、利用者の声を要件へ変える人、ベンダーと仕様や品質を協議する人を自社側に置き、外部の技術力を使いながら主導権を持つ状態です。社内に不足する技能を補い、実案件を通じて担当者を育てる伴走型支援は、この移行に使えます。
特に、基幹業務の例外処理、顧客や商品を識別するデータの定義、外部連携、データ移行は、現場と経営が判断しなければ決まりません。ローコードであっても設計が不要になるわけではなく、責任者・データ定義・移行ルールを曖昧にしたまま進めると、後から修正しにくい仕組みになります。
丸投げから共同責任へ
「ベンダーに任せればDXになる」という考え方では、業務上の優先順位や変更判断まで外部依存になりがちです。IPAは、DX人材の不足がIT企業より事業会社で深刻であり、企画・推進の担い手不足がボトルネックになると指摘しています。IPA「DX動向2024―深刻化するDXを推進する人材不足と課題」
伴走型では、支援側が開発やファシリテーションを担い、自社側は業務責任者として優先順位、受入条件、利用定着を受け持ちます。外部委託を続ける場合でも、仕様・ソースコード・本番環境の権限・運用上の例外を誰が把握しているかを可視化しておくと、特定の会社に判断まで固定される状態を避けやすくなります。
作らずに解く選択肢
現場の課題への答えが、必ずしも新規の受託開発とは限りません。申請・承認・台帳管理ならワークフローやSaaS、定型転記なら自動化、部門固有の小規模な業務ならノーコード・ローコードで解けることがあります。IPAのDX動向2025でも、日本でローコード・ノーコードによる市民開発やSaaS活用など現場主体のDXに取り組んでいる企業は8.3%にとどまるとされています。
伴走支援を使うなら、最初から「何を作るか」だけを依頼せず、「既製品・自動化・追加開発のどれで業務を最も無理なく変えられるか」を一緒に検証する進め方が有効です。既製品に実務を合わせる範囲と、独自性のために作り込む範囲を分ければ、開発対象を必要な部分へ絞れます。
自社に残すべき判断力
伴走型支援の成果は、納品時の資料の量ではなく、支援後に自社で次の改善を決めて実行できるかで見ます。少なくとも、業務の目的と優先順位、データの責任者、変更を受け入れる基準、外部パートナーとの役割分担を社内で説明できる状態を目指します。
DX認定制度は、デジタルガバナンス・コードに対応し、DX推進の準備が整っている事業者を国が認定する仕組みです。自社のDX推進体制を考える際の参照点にはなりますが、認定の有無だけで支援の質は判断できません。制度の対象や認定事業者一覧はIPA「DX認定制度について」で確認できます。
10. システム開発会社の選び方FAQと、地域で具体的な会社を探すには
迷いが残る項目は、契約前に「どこまで任せるか」「誰が責任を持つか」を候補各社へ同じ条件で確認することが、選定の精度を高めます。ここでは発注前によくある疑問を整理します。詳しい判断基準は各章で見きわめ、最後は比較しやすい条件にそろえて候補を絞り込みましょう。
要件定義から、実装だけでも頼める？
どちらも依頼できます。業務の課題整理や要件定義から支援を受ける場合は、現場へのヒアリング方法、成果物、意思決定の進め方まで確かめてください。実装だけを切り出す場合は、要件・設計・受入基準が発注側で十分に固まっていることが前提です。依頼範囲の決め方は第3章で確認できます。
請負と準委任はどちらがよい？
仕様と完成条件を定められる工程は請負、要件を詰めながら進める支援や柔軟な稼働が必要な工程は準委任が候補になります。契約名だけで決めず、成果物、変更時の扱い、検収、指揮命令と責任分界を依頼内容に合わせてそろえることが大切です。判断の考え方は第4章をご覧ください。
開発費の相場はどのくらい？
同じ業務システムでも、対象業務、連携先、利用者数、データ移行、セキュリティ、保守条件によって費用は大きく変わります。相場は予算の上限を決める数字ではなく、見積もりの前提を比べるための目安として扱うのが安全です。費用の見方と比較方法は第6章で解説しています。
追加費用や保守費用が膨らまない？
追加費用を完全になくすより、どの変更が追加対象になるかを契約前に見える化することが現実的です。見積書では要件定義、設計、テスト、移行、教育、障害対応、改修、クラウド利用料の範囲と除外項目を洗い出しましょう。保守も月額だけでなく、対応時間、障害時の連絡方法、改修枠、引き継ぎ条件まで比較します。確認項目は第7章にまとめています。
丸投げで使えないシステムにならない？
発注側が業務の優先順位や判断を手放すと、完成しても現場に定着しないおそれがあります。提案段階で、実際に担当する体制、要件確認の頻度、レビュー相手、仕様変更の決め方を聞いてください。再委託の有無だけで判断せず、誰が品質と進行に責任を持ち、発注側と直接すり合わせるかを把握します。体制の見極めは第5章、要件の伝え方は第3章が参考になります。
小さい開発会社に頼んで大丈夫？
会社規模だけでは判断できません。自社と近い業務・規模の支援実績、担当者が継続して関われる体制、障害時の連絡先、属人化を防ぐドキュメントやソースコードの引き継ぎ方をチェックしておきましょう。少人数でも窓口と実務担当の距離が近く、判断が速い会社はあります。一方で、特定担当者が不在になった場合の代替体制は必ず質問しておく必要があります。
地域別記事で具体候補を探す流れ
候補を選ぶ際は、要件、規模、希望納期、対応してほしい工程をそろえ、複数社へ同条件で相見積もりを取りましょう。総額だけでなく、提案内容、体制、見積範囲、保守条件を比較すると、自社に合う依頼先を判断しやすくなります。
具体的な会社は、対応地域ごとのおすすめ記事で絞り込んでください。まずは資料をダウンロードして評価軸を整理し、その内容を添えて問い合わせれば、各社からより比較しやすい提案と見積もりを受け取れます。
目次
おすすめ比較一覧から、
最適な製品をみつける
カテゴリーから、IT製品の比較検索ができます。
2179件の製品から、ソフトウェア・ビジネスツール・クラウドサービス・SaaSなどをご紹介します。
製品の掲載について
