はじめに ― なぜ「相場」が分からないまま発注が始まってしまうのか
先代から会社を引き継いだ直後、多くの後継社長が最初にぶつかる壁のひとつが「システム開発にいくらかかるのか、まったく見当がつかない」という問題です。先代の時代にどんぶり勘定で発注していた基幹システム、担当者の異動でブラックボックス化した受発注システム、あるいは「そろそろ古いから直したい」という現場の声。どれも刷新の必要性は感じているのに、見積もりを取ろうとした瞬間に足が止まります。
理由は単純です。システム開発の値付けには、家電や車のような「定価」が存在しません。同じ「在庫管理システムを作りたい」という依頼でも、要件の広さ、既存業務との整合性、データ移行の難易度、担当する開発会社の体制によって、見積もりは50万円から2000万円まで軽く3桁変わります。しかも先代の時代の付き合いで見積もりを取ると、相見積もりの経験がないまま「この金額が普通なのか高いのか」を判断できず、言われた額をそのまま受け入れてしまうケースが後を絶ちません。
本記事は、事業承継後に初めてシステム開発を発注する立場になった後継社長・後継者に向けて、具体的な金額帯の「早見表」と、その金額がなぜそう決まるのかの構造、さらに見積もりを受け取ったときに自分で相場観を検証する方法を、できるだけ実務に即して解説します。専門用語は最小限にし、必要な言葉には都度かみ砕いた説明を添えます。
多くの後継社長が置かれている状況は共通しています。先代は現場一筋で経営を続けてきたため、システムに関する契約書や見積書をきちんと保管していない、あるいは口頭で発注内容を決めていた、というケースが少なくありません。引き継いだ後に金庫や共有フォルダを整理して初めて「この保守費用、毎月何にいくら払っているのか分からない」「この開発会社との契約範囲が分からない」と気づくことも珍しくありません。相場を知ることは、単に新しい発注を検討するためだけでなく、今すでに払っているコストが適正かどうかを見直すためにも役立ちます。
また、事業承継のタイミングは、システムを見直す絶好の機会でもあります。先代の時代からの惰性で使い続けてきた仕組みを、経営者交代というタイミングを使って刷新する。この発想の転換ができるかどうかが、承継後数年間の業務効率、そして従業員の働きやすさに直結します。逆に言えば、相場観を持たずに動くと、絶好の機会を逆に「高い勉強代を払う機会」に変えてしまうリスクもあるということです。
この記事で分かること
- 業務内容・規模別のシステム開発費用の金額帯早見表
- なぜ同じような依頼でも見積もりが数倍〜数十倍変わるのか、その構造的な理由
- 承継直後に発注しがちな「高すぎる」「安すぎて後で泣く」典型パターン
- 見積もりをもらったときに自分でチェックできるポイント
- 相場を勘違いしたまま発注してしまう典型的な失敗と回避策
- よくある質問（FAQ）
まず結論。規模別の金額帯早見表
細かい構造の話に入る前に、先代から会社を継いだばかりで「まず数字感がほしい」という方向けに、典型的な発注内容別の金額帯を先に示します。これはあくまで一般的な目安であり、業種・データ量・既存システムとの連携有無によって上下することを前提に見てください。
小規模な業務改善・単機能ツール（目安：30万円〜150万円）
- 既存のExcel台帳をWebフォーム化して複数人で同時入力できるようにする
- 紙の申請書をオンライン化して承認フローをつける
- 既存システムに1つの機能（例：CSV出力、通知メール送信）を追加する
この規模は、いわゆる「ノーコード・ローコードツール」で対応できることも多く、開発会社に依頼する場合でも要件が明確であれば比較的短期間・低予算で収まります。ただし「小規模」と思っていた依頼が、話を聞いていくうちに「実は基幹システムとの連携が必要」と分かり、規模が跳ね上がることも多いため要注意です。
具体的な業種のイメージで言うと、例えば従業員20名程度の卸売業で「取引先ごとの掛け率が違う受注入力をExcelでやっていて、担当者しか操作できない」という悩みに対して、入力フォームと簡易な承認機能をつけるだけであれば、この帯の中〜上限あたりで収まることが多いです。逆に「その受注データを会計ソフトにも自動で反映させたい」という一言が加わった瞬間、連携部分の開発が発生し、次の中規模帯に近づいていきます。後継社長が見積もり相談をする際、「これは単独で動くツールなのか、他システムと繋ぐ必要があるのか」を自分の中で切り分けて話すだけで、開発会社側の見積もり精度がかなり上がります。
また、この規模の依頼でよくある誤解が「安いから品質も低いはずだ」という思い込みです。実際には、要件がシンプルで対象範囲が狭いからこそ費用が抑えられているだけで、必ずしも品質が劣るわけではありません。逆に「小規模なのに異常に高い」見積もりが出てきた場合は、開発会社側が要件をノーコードツールで対応できる範囲だと判断できず、フルスクラッチ相当の工数で見積もっている可能性があるため、他社との比較が特に有効な帯です。
中規模の業務システム刷新（目安：300万円〜1500万円）
- 受発注管理システムの新規構築（顧客・商品・在庫・売上を一元管理）
- 勤怠管理・給与連携システムの自社仕様への刷新
- 予約管理・顧客管理（CRM）システムの構築
- 老朽化した基幹システムの一部リプレイス
事業承継後に最も相談が多いのがこの帯です。先代の時代に作った、あるいは購入したシステムが古くなり、担当者の退職と合わせて刷新を検討するケースが典型的です。この規模になると、要件を洗い出す工程（後述）にもある程度の期間と費用がかかり、開発期間は3ヶ月〜8ヶ月程度が一般的です。
この帯に入る典型例をもう少し具体的に見てみます。製造業で従業員50名規模の会社が、先代の時代に情報システム担当者が個人で作ったExcelマクロの生産管理表を使い続けていたが、その担当者が退職し誰も保守できなくなった、というケースです。このような場合、単にマクロを再現するだけでなく、退職リスクを避けるために「誰でも保守できる仕組み」への刷新が求められるため、単純な機能移植よりも設計にコストがかかります。見積もりが想定より高く出た場合、その多くは「今動いているものをそのまま再現する費用」ではなく「今後10年、担当者が変わっても運用できる仕組みに作り替える費用」が含まれているためです。この違いを理解しておくと、見積もりの背景が見えやすくなります。
もう一つの典型例は、卸売・小売業における予約管理・顧客管理システムの刷新です。先代の時代は電話とノートで予約を管理していたが、来店客数の増加や従業員の入れ替わりに伴い、システム化のニーズが高まるケースです。この場合、機能自体はシンプルでも「複数店舗をまたいだ予約の重複防止」「顧客情報の個人情報保護への配慮」といった要件が加わると、中規模帯の中でも上限に近い金額になりやすい傾向があります。
大規模な基幹システム刷新・複数拠点連携（目安：1500万円〜5000万円以上）
- 複数拠点・複数事業部をまたぐ統合基幹システム（ERP相当）の構築
- 生産管理・在庫管理・会計システムを連携させた一体型システム
- 会員数・取扱データ量が多い自社サービス（会員制サイト、業務用アプリ）のフルリニューアル
この帯になると、要件定義だけで数百万円かかることもあり、開発期間も1年を超えることが珍しくありません。承継直後の後継社長が単独で判断するにはリスクが大きい規模であり、外部の専門家（中立的なITコンサルタントなど）を挟んで進めることが多くなります。
この規模の投資判断を承継直後、かつ単独で下してしまうことには特に注意が必要です。理由は、金額の大きさそのものだけではありません。プロジェクトが1年を超える長期にわたるため、途中で事業環境が変わったり、想定していた業務フローが実は現場の実態と違っていたりすることが発覚しやすく、修正のたびに追加費用と工期延長が発生しやすいという構造上のリスクがあるためです。先代の時代の経営方針を十分に理解しきれていない承継直後のタイミングでこの規模の意思決定をする場合は、社内の複数の役職者、できれば現場を長く見てきたベテラン社員の意見も踏まえて、慎重に進めることをお勧めします。
また、この帯の見積もりでは「フェーズ分割」という考え方が重要になります。5000万円の投資を一度に決断するのではなく、まず1000万円規模の第一フェーズで基盤部分を作り、実際に動かしてみてから第二フェーズ以降の投資判断をする、という段階的なアプローチです。これにより、想定と現実のズレが小さいうちに軌道修正できるというメリットがあります。
番外編：既製品(SaaS)導入という選択肢（目安：月額数千円〜数十万円）
「システム開発」という言葉を使っていても、実は既製のクラウドサービス（SaaS）を契約するだけで要件が満たせるケースも多くあります。この場合は開発費用ではなく月額利用料という形になり、初期費用0円〜数十万円、月額数千円〜数十万円という価格構造になります。後継社長が最初にやるべきことは「これは本当にゼロから作る必要があるのか、既製品で足りないか」の見極めです。この判断を誤ると、既製品なら月額数万円で済んだはずの機能に、数百万円をかけて独自開発してしまうという失敗が発生します。
勤怠管理、給与計算、名刺管理、簡易なCRM、経費精算など、業種を問わず共通性の高い業務については、既に多くのSaaSが存在しており、機能も年々充実しています。一方で、自社独自の業務フロー（例えば製造業の特殊な工程管理、業界特有の受発注ルールなど）については、既製品ではカバーしきれないことが多く、この部分だけをカスタム開発するという「ハイブリッド」な選択肢も検討に値します。全部を独自開発するのではなく、汎用部分はSaaSに任せ、独自性の高い部分だけをカスタムで作るという発想を持つと、費用を大きく抑えられることがあります。
なぜ同じような依頼で金額が数倍〜数十倍変わるのか
早見表を見て「結局幅が広すぎて分からない」と感じた方も多いはずです。ここからは、その幅がなぜ生まれるのかを構造的に説明します。事業承継後の後継社長がここを理解しておくと、見積もりの妥当性を自分の頭で判断できるようになります。
要因1：要件の「広さ」と「深さ」
「在庫管理システムを作りたい」という一文だけでは、開発会社は見積もりを出せません。以下のような要素で工数（作業量）が大きく変わります。
- 対象となる商品・拠点・部門の数
- 既存の他システム（会計、販売管理、EC）との連携有無
- 複数人・複数拠点での同時利用が必要か
- 権限管理（誰がどこまで見られる・操作できるか）の細かさ
- 承認フロー・通知・レポート出力など「あると便利」な周辺機能の数
先代の時代の口頭伝承的な業務ルール（「うちはこの得意先だけ特別対応している」など）が後から次々と出てくると、当初の見積もりから大きく膨らむことがあります。これが承継直後の発注で特に起きやすい失敗です。先代しか知らなかった業務の例外ルールが、要件を詰める過程で初めて発覚し、開発会社が「それなら追加で工数がかかります」と言い出すパターンです。
要因2：既存データの状態
システムを刷新する場合、多くのケースで既存データ（顧客リスト、商品マスタ、過去の取引履歴など）を新システムに移す作業（データ移行）が発生します。このデータが以下のような状態だと、移行費用だけで数十万円〜数百万円が別途かかります。
- Excelファイルが部門ごと・年度ごとに分散していて統一されていない
- 表記のばらつきが大きい（同じ顧客名でも「株式会社」「(株)」など表記が揺れている）
- 紙の帳簿しか存在せず、そもそもデータ化されていない
- 誰が正しいデータか分からない台帳が複数存在する
先代の時代からの蓄積データは、良くも悪くも「その会社の歴史」がそのまま反映されています。承継直後にこの整理をせずに刷新プロジェクトを始めると、見積もり時には想定していなかったデータクリーニング作業が後半で発覚し、追加費用と工期延長の両方が発生します。
要因3：開発の方式（既製品カスタマイズか、ゼロから作るか）
開発方式には大きく2つの方向性があります。
1つ目は、既存のパッケージソフトやSaaS、ノーコードツールをベースに、必要な部分だけカスタマイズする方式です。ベースとなる仕組みが既にあるため、開発期間・費用を抑えやすい一方、パッケージの制約に業務側を合わせる必要が出てくる場合があります。
2つ目は、フルスクラッチ開発と呼ばれる、既存の枠組みを使わず要件に合わせて完全に作り上げる方式です。自社の業務に完全に合わせた仕組みを作れる自由度がある一方、当然すべてを新規に作るため工数がかさみ、費用も期間も大きくなる傾向があります。開発を依頼する契約形態そのもの（請負契約か準委任契約か）によっても費用の考え方が変わるため、あわせて請負契約と準委任契約、何がどう違うのかも確認しておくと理解が深まる。
「うちの業務は特殊だから」という理由で最初から後者を選びがちですが、実際に要件を突き合わせてみると、既製品のカスタマイズで十分対応できるケースも少なくありません。方式の選択そのものが金額を数倍単位で左右するため、開発会社に相談する前に「本当にゼロから作る必要があるレベルの特殊性なのか」を一度立ち止まって考える価値があります。
要因4：開発会社の規模・体制・価格帯
同じ要件でも、依頼する開発会社によって見積もりは大きく変わります。
- 大手システムインテグレーター（SIer）：体制が厚く保守・サポートも安定している一方、間に営業・管理層が入るため人件費相当のコストが上がりやすい
- 中小規模の受託開発会社：機動力があり価格も抑えやすいが、会社ごとに得意分野の差が大きい
- フリーランスエンジニア個人：価格は最も抑えられるが、体制・継続性のリスクを考慮する必要がある
承継直後は「先代の代からの付き合いだから」という理由だけで発注先を固定してしまいがちですが、一度は他の選択肢と比較する（相見積もりを取る）ことを強くお勧めします。先代の時代に決まった発注先が、今の会社規模や業務内容に対して適正な価格帯かどうかは、比較しない限り分かりません。
要因5：保守・運用費用の有無
開発費用（初期費用）だけを見て安いと判断してしまうと、後で痛い目を見ることがあります。多くのシステムには、稼働後の保守・運用費用（サーバー費用、不具合対応、機能追加対応など）が別途発生します。これは月額固定費用の場合もあれば、都度発生の対応費用の場合もあります。
初期費用が同じ500万円の見積もりでも、片方は月額保守5万円、もう片方は月額保守20万円ということもあります。5年間のトータルコストで見ると、後者は900万円もの差になります。見積もり比較は「初期費用」だけでなく「5年間の総額」で見る癖をつけることが重要です。
承継直後に起きやすい典型的な失敗パターン
ここでは、事業承継後にシステム発注で実際によく見られる失敗パターンを、具体的なシナリオとともに紹介します。自社に近いパターンがあれば、そのまま自社のリスクとして考えてみてください。
失敗パターン1：先代の付き合いをそのまま継続し、相場を検証しないまま高額発注してしまう
先代の代から付き合いのある開発会社に「そろそろシステムを新しくしたい」と相談すると、先代への義理もあってそのまま発注を決めてしまう後継社長は多くいます。しかしその開発会社が提示する金額が本当に適正なのか、比較しないまま契約すると、市場価格より数割〜倍近く高い金額で発注してしまっていることも実際にあります。
回避策：既存の付き合いのある会社を最初の相談先にすることは問題ありませんが、契約の前には必ず1〜2社の相見積もりを取りましょう。既存の会社に「他社にも相談してみたい」と伝えることは、失礼な行為ではなく、経営判断として当然のプロセスです。良い開発会社であれば、相見積もりを取ることに気分を害することはありません。なお、相見積もりの過程で明らかに相場から外れた対応をしてくる会社を見分けるポイントは、危険な開発会社のサイン10選、承継社長が見極めるポイントにまとめている。
実際にあったケースとして、先代の代から20年以上付き合いのあるシステム会社に見積もりを依頼したところ、同規模の要件で他社の見積もりの1.8倍近い金額が提示されたという相談を受けたことがあります。理由を尋ねると、その会社は長年の付き合いの中で「毎年の保守契約更新+都度の追加開発」というビジネスモデルが定着しており、新規開発の見積もり自体にも従来の関係性を前提にした割高な人件費相当額が組み込まれていたことが分かりました。長年の関係性には、技術面・業務理解面での安心感という価値がある一方、値付けの検証が長期間行われてこなかったリスクも同時に存在するということです。
失敗パターン2：安さだけで選んで、後から機能不足・追加費用が発覚する
相場が分からないまま複数社に見積もりを依頼すると、極端に安い見積もりを出す会社が出てきます。「これでいいじゃないか」と安さだけで決めてしまうと、後になって「その機能は見積もりに入っていなかった」「追加費用が発生する」という事態に陥ることがあります。
安い見積もりには理由があります。要件の解釈が浅く必要な機能が漏れている、後から追加費用で回収するビジネスモデルになっている、あるいは開発体制が薄く品質にリスクがある、などです。極端に安い見積もりを見たときは「なぜこの金額で可能なのか」を必ず質問しましょう。
例えば、中規模の受発注管理システムで、3社から見積もりを取った際に2社が800万円〜1000万円の範囲だったのに対し、1社だけ350万円という提示があったという事例があります。安い理由を確認したところ、その会社は「まず必要最低限の機能だけを作り、その後の機能追加はすべて別途契約」という前提で見積もっていました。最終的にすべての要望を実現するための総額を計算すると、実は他社より高くなる見込みだったことが分かりました。見積もり金額だけを見て安いと判断するのではなく、「最終的にすべての要件を満たすためのトータルコスト」で比較することが重要です。
失敗パターン3：要件を固めずに発注し、際限なく追加費用が発生する
「とりあえず作り始めてもらって、動かしながら直していけばいい」という進め方は、システム開発においては非常に危険です。何を作るかが明確に定義されていない状態で契約すると、開発側は「言われたことだけ」を作り、後継社長は「言わなくても分かってほしかった」というギャップが積み重なり、追加要望のたびに追加費用が発生する構造になります。
これを防ぐためには、契約前に「何を作るか」を文書として固める工程が必要です。この工程を経ずに口頭のやり取りだけで進めてしまうことが、承継直後の発注で最も多い失敗の根本原因です。
このパターンで実際によく起きるのが「言葉の解釈の齟齬」です。後継社長が「顧客管理システムを作ってほしい」と依頼したとき、開発会社は「顧客の基本情報を登録・検索できる機能」を想定して見積もりを出したとします。しかし後継社長の頭の中では「過去の取引履歴も一覧で見られて、担当者ごとの対応履歴も記録できて、メール配信もできる」という、はるかに広い機能まで含んでいたというケースです。この齟齬は、口頭のやり取りだけでは絶対に埋まりません。「顧客管理システム」という言葉一つでも、業種や会社によって思い浮かべる機能の範囲は大きく異なるため、機能を一つひとつ具体的に書き出して合意する作業が不可欠です。
失敗パターン4：現場の声を聞かずにトップダウンで発注し、完成後に使われない
後継社長が「これからはデジタル化だ」という意気込みで、現場に相談せずにシステムを発注してしまうケースです。完成したシステムが現場の実務フローと合わず、結局現場はExcelや紙の運用に戻ってしまい、投資が無駄になります。
現場のベテラン社員は、先代の時代からの業務ルールや「なぜこの手順になっているか」の背景を最も知っている人たちです。発注前の要件整理には、必ず現場のキーパーソンを巻き込みましょう。
このパターンの根の深さは、完成後にしか失敗が判明しないという点にあります。開発の途中段階では、後継社長と開発会社の間だけで話が進み、現場は「上から降ってきたシステムを使わされる」立場になります。稼働後にログインすらされず放置されるシステムに数百万円を投じてしまった、という相談は決して珍しくありません。この失敗を避けるためには、要件整理の段階だけでなく、開発の中間段階でも一度、現場担当者に画面や動作の試作版を見せて反応を確認する機会を設けることが効果的です。
失敗パターン5：見積もりの内訳を確認せず、何にいくらかかっているか分からないまま契約する
見積書に「システム開発費：一式 800万円」としか書かれていない場合、その内訳を確認しないまま契約してしまう後継社長も少なくありません。工程ごと（要件を固める工程、画面や機能を設計する工程、実際にプログラムを書く工程、動作確認する工程など）の内訳が示されない見積もりは、後から「これは想定外」というトラブルの火種になりやすい傾向があります。
まともな開発会社であれば、工程ごとの内訳や、どこまでが今回の作業範囲でどこからが追加費用になるのかを明示した見積もりを提示できるはずです。内訳のない一式見積もりを提示された場合は、内訳を出してもらうよう依頼することをお勧めします。
見積もりをもらったときに自分でチェックすべきポイント
ここからは、実際に開発会社から見積もりを受け取った際、後継社長自身がその場で確認できるチェックリストを示します。専門的な技術知識がなくても確認できる項目に絞っています。
チェックリストA：見積もりの構造を確認する
- [ ] 工程ごとの内訳（要件整理、設計、開発、テスト、導入支援など）が分かれているか
- [ ] 「一式」という表記だけで済まされている項目がないか
- [ ] 初期費用と月額（または年額）の運用・保守費用が別々に示されているか
- [ ] 見積もりの有効期限が明記されているか
- [ ] 見積もりに含まれる「対応範囲」が明文化されているか（後述）
チェックリストB：作業範囲の明確さを確認する
- [ ] 見積もり対象となる機能の一覧が具体的に列挙されているか（「〇〇管理機能一式」のような曖昧な表現でないか）
- [ ] データ移行が含まれているか、含まれる場合はどこまでの範囲か
- [ ] 既存システムとの連携が必要な場合、その連携作業が含まれているか
- [ ] 対象となる利用人数・拠点数・データ量の前提が明記されているか
- [ ] 想定外の追加要望が出た場合の費用の扱い（追加見積もりになるのか、一定範囲まで無償対応か）が説明されているか
チェックリストC：スケジュールと体制を確認する
- [ ] 開発期間の見込みが工程別に示されているか
- [ ] 誰が担当し、どのくらいの頻度で報告・打ち合わせがあるか
- [ ] 完成後の動作確認（検収）をどのタイミングでどう行うかが説明されているか
- [ ] 稼働後の不具合対応・サポート体制と、その費用の有無
チェックリストD：比較のための質問リスト
複数社から見積もりを取った際、金額だけを比較するのではなく、以下の質問を各社に同じように投げかけることで、単純な金額比較よりも実質的な比較ができます。
- 「この金額に含まれていない作業は何ですか」
- 「稼働後、想定外の不具合が出た場合の対応費用はどうなりますか」
- 「似た規模の開発を過去にどのくらい手がけていますか」
- 「開発期間中、こちらが提供すべき情報や決めるべきことは何ですか」
- 「途中で要望が変わった場合、費用と期間にどう影響しますか」
これらの質問への回答の具体性・誠実さは、金額そのものよりも発注先の信頼性を判断する材料になります。曖昧な返答しか返ってこない会社は、契約後にトラブルになりやすい傾向があります。
費用を左右する「要件整理」という工程の重要性
前段で何度か触れましたが、見積もり金額のブレを最小化する最大の鍵は、発注前に「何を作るか」をできるだけ具体的に固めておくことです。この工程が甘いまま見積もりを依頼すると、開発会社側も正確な金額を出せず、結果としてざっくりとした高めの見積もり、あるいは後から膨らむ低めの見積もりのどちらかになりがちです。
具体的には、以下のような情報を事前に整理しておくと、見積もりの精度が大きく上がります。
- 現在の業務フローを工程ごとに書き出す（誰が、いつ、何を、どのように行っているか）
- 現状の課題・困りごとを具体的なエピソードで整理する（「入力が二重になっている」「担当者しか分からない」など）
- 新システムで「絶対に必要なもの」と「あれば嬉しいもの」を分けて優先順位をつける
- 利用する人数・拠点・想定データ量の見込みを出す
- 既存のどのシステム・ツールと連携が必要かを確認する
- 予算のおおよその上限を先に決めておく
この整理を後継社長自身、あるいは社内の担当者だけで行うのが難しい場合は、発注前の相談段階で開発会社に整理を手伝ってもらうことも可能です。多くの開発会社は、正式な見積もり前の無料相談・ヒアリングの機会を用意しています。この段階を「タダで聞けるならとりあえず聞いてみよう」くらいの気軽さで活用し、複数社の話を聞き比べることで、自社にとっての相場感が徐々に掴めてきます。
見積もりの内訳を工程別に理解する
見積書の内訳を見たときに、それぞれの項目が何を意味しているのか分からないと、内訳が示されていても検証できません。ここでは、一般的なシステム開発の工程と、それぞれにかかる費用の目安の考え方を説明します。
工程1：現状分析・要件の整理
現在の業務やシステムを分析し、新システムに何が必要かを洗い出す工程です。中規模のプロジェクトであれば、全体費用の10〜20%程度がこの工程に割かれることが一般的です。この工程を軽視して安く済ませようとする開発会社の場合、後工程で要件の見落としが発覚しやすくなります。
工程2：設計
洗い出した要件をもとに、画面のレイアウトやデータの構造、システム全体の仕組みを具体的に決める工程です。全体費用の15〜25%程度が目安です。この段階で作成される設計書や画面イメージ（モックアップ）を、後継社長自身が実際に目で見て確認できる貴重な機会になります。「思っていたイメージと違う」と感じたら、この段階で必ず声を上げるべきです。プログラムを書き始めてから修正するのは、設計段階で修正するよりもはるかにコストと時間がかかります。
工程3：開発（プログラム作成)
実際にプログラムを書いていく工程です。全体費用の40〜55%程度と、最も大きな割合を占めます。この工程の期間・費用は、機能の数と複雑さに直接比例します。見積もりの中でこの割合が極端に低い場合、逆に他の工程(特にテスト)が薄くなっている可能性があるため要注意です。
工程4：テスト・動作確認
作られたシステムが要件通りに動くかを確認する工程です。全体費用の10〜20%程度が目安です。この工程が薄いと、稼働後に不具合が多発するリスクが高まります。特に、実際の業務データに近い量・パターンでテストされているかは、後継社長からも質問して確認する価値があります。
工程5：導入支援・引き渡し
実際に現場で使い始めるための操作説明、マニュアル作成、初期のデータ投入支援などを行う工程です。全体費用の5〜10%程度が一般的ですが、現場の従業員が多い、あるいはITに不慣れな従業員が多い会社の場合、この工程を手厚くしてもらうことを事前に相談する価値があります。導入後に「使い方が分からず結局使われない」という事態を避けるための最後の要となる工程です。
この5つの工程のうち、どこにどの程度の予算が割かれているかを見積もりの内訳で確認すると、その開発会社がどこに重点を置いているか、あるいはどこかを不当に薄くしていないかが見えてきます。
補助金・助成金という選択肢について
システム開発の費用負担を軽減する手段として、国や自治体が提供する補助金・助成金制度が存在します。事業承継のタイミングで利用できる制度が用意されている年度もあり、対象となる場合は開発費用の一部（実際の負担割合や上限額は制度・年度によって異なります）の補助を受けられる可能性があります。
ただし補助金には申請期間・対象要件・交付までの手続きが定められており、「発注してから申請する」のではなく「申請が採択されてから発注する」という順序が求められる制度が一般的です。この順序を誤ると補助対象外になってしまうため、補助金の活用を検討する場合は、発注の意思決定より前に制度の詳細を確認する必要があります。制度の詳細や最新の申請要件は、年度によって変更されることが多いため、必ず公式の窓口や専門家に最新情報を確認してください。対象になり得る制度の詳細はデジタル化・AI導入補助金（旧IT導入補助金）は先代からのシステム刷新に使えるかで解説している。
相場観を掴むための実践的なアクションプラン
最後に、この記事を読んだ後継社長が次に取るべき具体的なアクションを、ステップ形式でまとめます。
ステップ1：現状の棚卸しをする（社内で完結、費用ゼロ）
まず、今使っているシステム・Excel・紙の台帳を一覧化し、それぞれの「困りごと」を書き出します。この段階では開発会社への相談は不要です。社内の現場担当者と一緒に、1〜2週間程度かけて整理します。何を社内で決めておくべきかは、ガイド「発注前に社内で決めておく3つのこと」も参考になる。
ステップ2：優先順位をつける（社内で完結、費用ゼロ）
棚卸しした課題のうち、「今すぐ解決したいもの」「数年以内に解決したいもの」「いつか解決できればいいもの」に分けます。すべてを一度に解決しようとすると予算が膨らみすぎるため、優先度の高いものから着手する範囲を決めます。
ステップ3：無料相談・簡易見積もりを複数社から取る(費用ゼロ〜低コスト)
整理した内容を持って、2〜3社の開発会社に相談します。この段階では正式契約ではなく、あくまで相場感を掴むための情報収集です。各社の反応・提案の質・金額感を比較します。
ステップ4：本格的な見積もり依頼と条件のすり合わせ
相談した中から本命候補を1〜2社に絞り、正式な見積もりを依頼します。この際、前段で紹介したチェックリストを使って見積もりの内容を精査します。開発会社に相談する前に決めておきたいことは刷新を開発会社に相談する前に、決めておきたい3つのことにまとめている。
ステップ5：契約前の最終確認
契約書・見積書の内容を、金額だけでなく作業範囲・スケジュール・保守体制まで含めて確認し、疑問点はすべて契約前に解消しておきます。契約後に「聞きそびれた」と気づいても、交渉の主導権はこちらにはなくなります。
契約時に後継社長が特に注意すべき条項
見積もり金額の話に加えて、契約書そのものにも承継直後の後継社長が見落としやすい落とし穴があります。金額の相場観と同時に、これらの契約条件も相場を意識して確認することをお勧めします。
知的財産権・データの帰属
開発してもらったシステムのプログラム自体の権利や、蓄積されたデータの権利が、自社ではなく開発会社側に残る契約になっている場合があります。特に「その会社でなければメンテナンスできない」状態を意図的に作り、長期的に保守費用を得るビジネスモデルの会社が一部に存在します。契約書の中で、権利の帰属がどうなっているかを必ず確認しましょう。
契約形態(成果物完成を約束する契約か、作業時間を提供する契約か)
契約の形には大きく2つの型があります。完成した成果物を納めることを約束する型と、決められた時間・体制で作業を提供することを約束する型です。前者は「完成しなければ報酬が発生しない」という性質が強く、後者は「稼働した時間に応じて報酬が発生する」という性質が強くなります。どちらが適しているかは案件の性質によって異なりますが、後継社長としては、自社が依頼した内容がどちらの契約形態になっているかを理解し、特に「完成の定義」がどう契約書に書かれているかを確認することが重要です。
途中解約の条件
長期プロジェクトの場合、途中で経営判断が変わり、プロジェクトを中止・変更したくなることもあります。その場合にどこまでの費用を支払う必要があるのか、契約書に明記されているかを確認しましょう。
検収の基準とタイミング
システムが完成し、実際に問題なく動くことを確認して受け入れる工程があります。この確認作業の基準(どういう状態になれば「完成」と認めるか)が曖昧なまま契約すると、後継社長側が「まだ不十分だ」と感じても、契約上は既に完成扱いになっていて追加対応が有償になってしまう、という事態が起こり得ます。この基準とタイミングを事前に明確にしておくことは、金額の適正さと同じくらい重要な確認事項です。
よくある質問（FAQ）
Q1. 先代の代からの取引先に相見積もりを取りたいと言うのは失礼にならないか心配です
心配は理解できますが、経営判断として相見積もりを取ることはごく一般的な実務であり、失礼にはあたりません。「先代からお世話になっているからこそ、社内の経営判断としてきちんと比較検討したい」という趣旨を丁寧に伝えれば、良識のある取引先であれば問題なく受け止めてもらえます。逆に相見積もりを極端に嫌がる、あるいは強い引き止めをしてくる取引先がいた場合、それ自体が今後の付き合い方を見直す判断材料になります。
Q2. 見積もりが想定より高い場合、金額交渉はできますか
金額そのものの値切り交渉よりも、作業範囲を調整することで費用を抑える相談の方が現実的です。例えば「今回は必須機能だけに絞り、あれば嬉しい機能は次のフェーズに回す」といった形で、範囲を分割して段階的に発注する方法があります。単純な値引き要求は、開発側の採算を崩し、結果として品質や対応の低下につながるリスクもあるため、慎重に進めることをお勧めします。
Q3. 開発会社によって見積もりの前提がバラバラで比較しづらいのですが、どうすればいいですか
各社に同じ資料（棚卸しした業務内容・課題・優先順位のメモ)を渡し、同じ質問リストを投げかけることで、前提条件をできるだけ揃えることができます。それでも各社の解釈に差が出る場合は、「この見積もりに含まれる範囲」と「含まれない範囲」を書面で明確にしてもらい、それをもとに比較するのが最も実務的な方法です。
Q4. 予算が決まっていない状態で相談してもいいのでしょうか
問題ありません。むしろ予算感が分からない段階での相談は、多くの開発会社が想定している一般的な依頼の入り口です。ただし「予算は無制限に出せる」という態度で相談すると、必要以上に高い提案が出てくるリスクがあるため、「概算でこのくらいの範囲で考えている」というおおまかな上限は伝えた方が、的確な提案を受けやすくなります。なお、先代が契約していた既存システムの保守費用が高いのか安いのか分からないまま、毎月払い続けているという相談もよく受けます。この場合はまず、現在支払っている保守費用の内訳(サーバー費用、不具合対応費用、機能追加のための予備費用など)を契約書や過去の請求書から洗い出し、開発会社に率直に開示を求めることから始めるとよいでしょう。開示を渋る、あるいは曖昧な回答しか得られない場合は、他社に同等のサービスの見積もりを依頼して比較検討する価値があります。ただし契約変更や解約には契約書上の条件(解約通知期間など)があるため、慌てて動くのではなく、契約書の該当条項を先に確認してから動くことが重要です。
まとめ
事業承継後のシステム開発発注で後継社長が最も避けたいのは、「相場が分からないまま、言われた金額をそのまま受け入れてしまうこと」です。本記事で示した金額帯の早見表はあくまで目安ですが、自社の依頼内容がどの規模に近いのかを把握し、見積もりの内訳・作業範囲・保守費用まで含めて確認する習慣を持つことで、相場から大きく外れた発注を避けられます。
改めて要点を整理すると、まず自社の依頼内容が小規模・中規模・大規模のどの帯に近いのかをおおまかに把握すること。次に、その金額がなぜそう決まっているのかを、要件の広さ、既存データの状態、開発方式、開発会社の体制、保守費用の有無という5つの構造要因から検証すること。そして、見積もりを受け取った際には内訳・作業範囲・スケジュール・体制の4つの観点でチェックリストに沿って確認すること。この3段階を踏むだけで、相場から大きく外れた高額発注や、安さだけに惑わされた失敗発注のリスクを大幅に減らすことができます。
先代の代からの付き合いを大切にしながらも、経営判断としての比較検討は別軸で行う。この両立が、承継直後のシステム投資を成功させる最初の一歩になります。システム開発は一度きりの買い物ではなく、その後何年にもわたって会社の業務を支える基盤への投資です。焦って決めず、分からないことは分からないままにせず、一つひとつ確認しながら進める姿勢こそが、先代から引き継いだ会社を次の世代へさらに良い状態で渡していくための土台になります。
最後にもう一点付け加えるならば、システム開発の相場観は一度身につけたら終わりというものではなく、技術の進歩や市場動向によって少しずつ変わっていくものでもあります。今回の発注を通じて得た経験や比較検討の記録は、次回以降の投資判断のための貴重な社内資産になります。見積もりのやり取り、選定の理由、稼働後に感じた良かった点・悪かった点を簡単にでも記録しておくことで、次に後継社長自身、あるいはさらに次の世代がシステム投資を検討する際の判断材料として活用できます。先代の時代にはこうした記録がなかったからこそ、今の自分が相場感の分からなさに苦労している、という構造そのものを次の世代に引き継がないようにする。これもまた、承継後のシステム投資における大切な視点のひとつです。
