既存システム改修の外注先5タイプ｜費用相場と失敗しない頼み方

数年前に開発会社に作ってもらった業務システムに不具合が出てきた。あるいは現場から「この機能を追加してほしい」という要望が上がってきた。けれども当時の開発会社に相談したら高額な見積もりが返ってきたり、そもそも連絡がつきにくかったりして、頼み先探しに困っている。こうした場面で「既存システムの改修を外注したい」と検索する方は少なくありません。

困りごとの中身ははっきりしているのに、いざ外注しようとすると「誰に、いくらで、どう頼めばいいのか」がまったく見えてこない。これは発注担当者の準備不足が原因ではなく、改修案件そのものが新規開発とは違った難しさを抱えているために起こる、構造的な詰まりです。改修は新規開発よりも小規模でスポット的なことが多く、開発会社に頼むと割高になったり後回しにされたりするミスマッチが起きやすいのです。

検索しても出てくるのは「開発会社の選び方」を前提にした情報ばかりで、「そもそもどんな頼み先があるのか」という選択肢の全体像にはなかなかたどり着けません。その結果、当時の開発会社か新しい開発会社か、という2択で立ち止まってしまいがちです。

本記事では、既存システム改修の外注先を「元の開発会社・新規の開発会社・SES・クラウドソーシング・フリーランス（複業エンジニア）」の5タイプに分解し、改修規模や予算、スピードに応じた使い分けの判断軸を発注者目線で整理します。あわせて改修費用の相場と見積もりの読み方、要件定義書が書けなくても実行できる見積もり前の準備5ステップまで解説します。読み終えるころには、自社の改修規模に合った頼み先の当たりがつき、稟議を通せる費用感をつかめている状態を目指します。

既存システムの改修を外注したいが「どこに頼めばいいか」で詰まる理由

既存システムの改修を外注しようとすると、新規開発のときには感じなかった独特の頼みづらさにぶつかります。多くの発注担当者が同じところで詰まるのは偶然ではなく、改修案件には3つの構造的な事情があるからです。1つ目は当時の開発会社に頼みづらいこと、2つ目は改修が「小さい案件」ゆえに開発会社と相性が悪くなりやすいこと、3つ目は社内に改修できるエンジニアがいないことです。

これらを「自社の事情」ではなく「改修案件に共通する構造」として理解すると、頼み先探しの迷いが整理しやすくなります。まずは詰まりの正体を言語化していきましょう。

当時の開発会社に頼みづらい3つのパターン

最初に検討するのは、たいてい「当時システムを作ってくれた開発会社」です。仕様を理解しているはずなので、改修も任せるのが自然に思えます。ところが、ここでつまずくケースが非常に多いのです。代表的なのは次の3つのパターンです。

1つ目は、高額な見積もりが返ってくるパターンです。改修は元のシステムを調査するところから始まるため、開発会社としては「現状を把握する工数」を見積もりに乗せざるを得ません。当時の担当者が異動・退職していれば、引き継ぎ資料を読み込む時間も追加されます。結果として「こんな小さな修正にこの金額？」と感じる見積もりが出てきがちです。

2つ目は、連絡が取りにくい、あるいは廃業しているパターンです。とくにスタートアップや小規模な開発会社に依頼していた場合、数年のあいだに事業転換や廃業で連絡がつかなくなることがあります。問い合わせフォームから連絡しても返事が来ない、担当営業が退職している、といった状況です。

3つ目は、担当エンジニアの退職でシステムがブラックボックス化しているパターンです。会社は存続していても、実際に作ったエンジニアが辞めてしまい、社内に内部構造を把握している人がいない。この状態では、たとえ元の開発会社であっても改修前の調査に時間がかかり、結局は新しい頼み先と変わらないコストがかかってしまいます。

改修は「小さい案件」ゆえに開発会社と相性が悪いことがある

もう1つの構造的な事情が、改修案件の「サイズ」です。改修は新規開発と違って、ゼロから作るわけではありません。「ボタンを1つ追加したい」「帳票のレイアウトを直したい」「法改正に合わせて計算ロジックを変えたい」といった、限定された範囲の作業であることがほとんどです。

ところが、受託開発を主力とする開発会社の多くは、ある程度まとまった規模の案件を前提に体制を組んでいます。営業・要件定義・設計・開発・テスト・プロジェクト管理という一連の体制を動かすには固定的なコストがかかるため、小規模な改修でも一定額以上でないと受けられない「最低受注額」が設定されていることがあります。

加えて、改修ならではの「初期調査コスト」も無視できません。既存システムがどう動いているかを把握しないと、安全に手を入れられないからです。この調査は作業の大小にかかわらず一定の工数が必要なため、小さな改修ほど「調査コストの比率」が高くなり、割高に感じられます。

さらに、開発会社の内部では大型の新規案件が優先されやすく、小さな改修は後回しにされるリスクもあります。「すぐ直してほしいのに、着手まで2〜3か月待たされる」といった声が出るのは、こうした優先順位の構造によるものです。

つまり「どこに頼めばいいかわからない」という悩みは、発注者の準備不足ではなく、改修という案件の性質と、開発会社のビジネスモデルとのあいだに生じるミスマッチが正体だといえます。この構造を踏まえると、頼み先を1社の開発会社に絞り込む前に、まず「どんな選択肢があるのか」を広げて考えることが解決の第一歩になります。

既存システム改修を外注できる5つの頼み先と使い分け

既存システムの改修を外注する先は、大きく5つのタイプに分けられます。「元の開発会社」「新規の開発会社・受託ベンダー」「SES（常駐・準委任）」「クラウドソーシング」「フリーランス（複業エンジニアへの直接契約）」です。それぞれ向いている改修規模・費用感・スピード・コミュニケーションの取りやすさが異なります。

検索でよく見かける「外注先の選び方」の多くは、暗黙のうちに「外注先＝開発会社」を前提にしています。しかし改修案件では、規模やスピードの条件によっては開発会社以外の選択肢のほうが合うケースが少なくありません。ここでは5タイプを横並びで比較し、自社の改修がどのタイプに合うかを判断できるようにしていきます。

5つの頼み先の比較一覧

まずは全体像を一覧で押さえましょう。下の表は、5つの頼み先を「向く改修規模」「費用感」「スピード」「コミュニケーション」「向くケース」の軸で整理したものです。

この表からわかるのは、中〜大規模で保守まで一体で任せたいなら開発会社系、継続的に体制を持ちたいならSES、小〜中規模でスポット・コスト重視ならクラウドソーシングやフリーランスへの直接依頼、という大まかな住み分けです。以下でそれぞれのタイプを詳しく見ていきます。

元の開発会社・新規開発会社に頼むケース

開発会社に頼む選択肢は、中〜大規模の改修や、改修後の保守まで含めて一括で任せたい場合に向いています。

元の開発会社は、システムの内部構造を理解している点が最大の強みです。保守契約が続いていて、当時の担当エンジニアが在籍しているなら、調査コストを抑えてスムーズに進められます。一方で、先述したように担当者の退職や見積もりの高さで頼みづらいケースも多く、必ずしも第一候補にできるとは限りません。

新規の開発会社・受託ベンダーは、体制が整っていて窓口が明確なため、複雑な改修や複数機能にまたがる改修を安心して任せられます。設計書づくりやテスト、ドキュメント整備までまとめて引き受けてくれる会社も多く、社内にIT人材が乏しい企業にとっては心強い選択肢です。ただし、改修前の現状調査から始めるぶん初期コストがかかり、最低受注額の関係で小規模改修だと割高になりやすい点は理解しておく必要があります。

開発会社系は「品質と体制を重視し、まとまった規模を任せたい」場合の本命ですが、改修が小さいほどコストと体制のミスマッチが出やすい、という特徴を覚えておきましょう。

SESを使うケース

SES（システムエンジニアリングサービス）は、エンジニアが準委任契約で自社のプロジェクトに参画し、作業時間に応じて費用を支払う形態です。改修文脈では、一度きりの修正というより「継続的に手を入れていく必要がある」「社内に開発体制を作りながら改修も進めたい」というケースに向いています。

たとえば、既存システムを使いながら段階的に機能を増やしていく、運用しながら不具合を継続的につぶしていく、といった長期戦の改修では、必要な期間だけエンジニアの稼働を確保できるSESが合理的です。費用は人月単価（エンジニア1人が1か月稼働するための単価）が基準になります。

注意点は、SESは準委任契約のため「成果物」ではなく「作業時間」に対して費用が発生することと、業務の指示・進行管理は原則として発注側が担う必要があることです。社内に進行を管理できる人がいないと、稼働しているのに成果が積み上がらない、という事態になりかねません。継続的な体制を持ちたい企業向けの選択肢といえます。

クラウドソーシング・フリーランスに頼むケース

クラウドソーシングやフリーランス（複業エンジニア）への直接依頼は、小〜中規模・スポット・コスト重視の改修にもっとも適した選択肢です。

クラウドソーシングは、プラットフォーム上で募集をかけて応募者から選ぶ形態で、軽微な修正や単発の改修をスピーディーかつ低コストで進めやすいのが利点です。ただし応募者のスキルや実績にばらつきが大きく、選定とコミュニケーションの手間は発注側で負う必要があります。

フリーランス（複業エンジニア）への直接契約は、特定の技術に強い人材を指名でき、間に入る会社がないぶん中間マージンを抑えられる点が大きな魅力です。直接やり取りするので意思疎通が速く、「この部分だけ直したい」というスポットの依頼にも小回りが利きます。開発会社では最低受注額や後回しリスクで頼みづらかった小規模改修こそ、フリーランス直接依頼の得意領域です。

近年は、こうしたフリーランス・複業エンジニアと発注企業をつなぐマッチングの仕組みも整ってきており、自社に合うスキルを持つ人材を探しやすくなっています。直接依頼のメリットと注意点については、のちほど「小〜中規模改修はフリーランス（複業エンジニア）への直接依頼という選択肢」で詳しく整理します。

既存システム改修の外注費用の相場と見積もりの読み方

頼み先のタイプがイメージできたら、次に気になるのは費用です。改修費用の相場を知っておくことは、稟議を通すうえでも、相見積もりの妥当性を判断するうえでも欠かせません。ここでは規模別の費用目安、見積もりの内訳、そして「同じ改修でも頼み先で費用が変わる仕組み」を順に解説します。

なお、ここで紹介する金額はあくまで一般的な目安です。改修費用は対象システムの状態や改修範囲によって大きく変動するため、最終的には複数の頼み先から見積もりを取って判断することをおすすめします。

改修規模別の費用目安（小・中・大／再構築の分岐含む）

システム改修の費用は、改修の規模と複雑さによって大きく幅があります。一般的な目安は次のとおりです。

• 小規模改修（30万円程度〜）: ボタンや項目の追加、帳票レイアウトの修正、軽微な不具合修正など、影響範囲が限定的な改修。おおむね30万〜数十万円程度が目安です。
• 中規模改修（100万〜500万円程度）: 複数機能にまたがる修正、計算ロジックの変更、外部システムとの連携追加など。調査・設計・テストの工数が増え、数百万円規模になります。
• 大規模改修・再構築（1,000万円〜）: システムの根幹に関わる改修や、古い基盤からの作り直しを伴うもの。新規開発に近い工数がかかり、1,000万円を超えることも珍しくありません。

システム改修の費用は人件費がほとんどを占め、「人月単価×期間×人数」で計算されるのが基本です（システム幹事「システム改修の費用相場」）。設備費や諸経費はおおむね全体の2〜3割程度とされますが、改修の規模・複雑さで大きく変わるため、固定された相場は存在しないと考えておくのが現実的です。

ここで重要なのが「改修か再構築か」の分岐です。改修を重ねるうちにシステムが複雑化し、1回の改修コストがかさむようになると、ある段階で「作り直したほうが結果的に安い」という逆転が起こります。この判断軸については後ほど「改修と作り直しの分岐点」で詳しく取り上げます。

見積もりの内訳と「改修費用が読みにくい」理由

改修の見積もりは、おおむね次のような工程ごとの費用で構成されます。

1. 現状調査・分析: 既存システムがどう動いているかを把握する工程
2. 要件定義: 何をどう改修するかを具体的に固める工程
3. 設計・開発: 実際にプログラムを修正する工程
4. テスト（デグレードテスト含む）: 改修部分と、影響を受ける既存機能が正しく動くかを確認する工程
5. 納品・運用保守: リリースと、その後のサポート

新規開発と比べて改修費用が読みにくいのは、1つ目の「現状調査・分析」のコストが事前に見えにくいからです。設計書が残っていない、ソースコードにコメントがない、作った担当者がいない、といった状況では、システムの中身を読み解くだけで相当な工数がかかります。表面的には小さな修正でも、影響範囲を調べてみたら想定以上に広かった、というのは改修案件では珍しくありません。

このため、初回の見積もりが「現状調査を実施したうえで、改修費用は別途見積もり」という二段階になることもあります。見積もりを受け取ったときは、調査費用がどこまで含まれているか、影響範囲の確認がスコープに入っているかを必ず確認しましょう。

頼み先タイプで費用が変わる仕組み

同じ改修内容でも、頼み先のタイプによって費用は変わります。その違いを生むのが「中間マージン」「体制コスト」「最低受注額」の3つです。

開発会社に頼む場合、見積もりには実際に手を動かすエンジニアの人件費だけでなく、営業・プロジェクト管理・品質保証などの間接コストが上乗せされます。これは品質と体制を担保するための正当なコストですが、小規模な改修ほどこの比率が高くなり、割高に感じられます。SESの場合も、エンジニアの稼働に対して会社のマージンが乗るのが一般的です。

一方、フリーランス（複業エンジニア）への直接契約では、間に入る会社がないため中間マージンが発生せず、エンジニアの稼働に対する費用がそのまま発注額に近くなります。同じスキルレベルのエンジニアが同じ作業をしても、直接依頼のほうがコストを抑えられるのはこの仕組みによるものです。

ただし、これは「直接依頼が常に安い」という意味ではありません。開発会社が提供する体制・品質保証・進行管理を自社で代替できるかどうかが分かれ目になります。改修規模が小さくスポット的で、社内で要件をある程度整理できるなら直接依頼のコストメリットが活き、規模が大きく体制ごと任せたいなら開発会社のコストにも合理性がある、と考えるとよいでしょう。

改修と作り直しの分岐点｜AI活用と「2025年の崖」を費用判断に活かす

ここまで「どこに、いくらで頼むか」を見てきましたが、その前に立ち止まって考えたいのが「そもそも改修すべきか、作り直すべきか」という上流の判断です。改修を繰り返すよりも作り直したほうが結果的に安くなる分岐点があり、ここを見誤ると無駄なコストを積み重ねることになります。

近年はこの判断に影響する2つの大きな潮流があります。1つは経済産業省が警鐘を鳴らす「2025年の崖」、もう1つはAIを活用したレガシーシステムの解析・モダナイゼーションです。見積もりを依頼する前に、自社の改修が「直す段階」なのか「作り直す段階」なのかを判断する材料として押さえておきましょう。

改修を続けるか作り直すかの判断軸

改修を続けるか作り直すかは、次の3つの観点で判断できます。

1つ目はブラックボックス化の度合いです。設計書がなく、作った担当者もおらず、中身を理解している人が誰もいない状態だと、改修のたびに高額な調査コストが発生します。改修するたびに「まず中身を調べる」費用がかかるなら、いずれ作り直しのほうが安くなります。

2つ目は保守単価の上昇です。古い言語（COBOLやVB6など）で作られたシステムは、それを扱えるエンジニアが減り続けているため、保守・改修の単価が年々上がる傾向にあります。対応できる人材が希少になるほど、改修のたびにコストとリスクが膨らんでいきます。

3つ目はOS・ミドルウェアのサポート終了です。基盤となるソフトウェアのサポートが切れると、セキュリティリスクが高まり、いずれ改修だけでは対応しきれなくなります。

これらが重なってきたシステムは、経済産業省のDXレポートが指摘する「2025年の崖」のリスクに直面しているといえます。同レポートでは、レガシーシステムを放置した場合、2025年以降に最大で年間12兆円もの経済損失が生じうると試算されています（経済産業省「DXレポート（サマリー）」）。21年以上稼働する基幹システムが2025年には約6割を占めるとも指摘されており、レガシー化は多くの企業にとって他人事ではありません。

改修費用が回を追うごとに膨らんでいる、対応できるエンジニアが見つかりにくい、基盤のサポートが切れる、といったサインが出ているなら、目先の改修だけでなく「作り直し」も含めて頼み先に相談することをおすすめします。

AIによるレガシー解析・モダナイゼーションで変わる改修コスト

「作り直すしかないが、中身がわからなくて怖い」という悩みに対して、近年大きく状況を変えつつあるのがAIの活用です。

レガシーシステムの最大の壁は、設計書が残っておらず、古い言語のコードを読み解けるエンジニアもいない、という「可視化の難しさ」でした。ここにAIが入ることで、ソースコードを解析して設計書や仕様書を自動生成し、システムの中身を可視化できるようになってきています。

実例として、富士通は2026年3月にソースコードから設計書を自動生成するAIサービスを提供開始し、設計書生成の時間を従来の約30分の1まで短縮できるとしています（富士通プレスリリース（2026年3月30日））。また、AIを活用したコード解析でレガシーシステムの課題を解決する取り組みも各社で進んでいます（日経クロステック Special「2025年の崖を乗り越える AIを活用したコード解析」）。レガシーモダナイゼーション市場全体でも、AIを活用したモダナイゼーションの加速が直近の最大のトレンドとされています。

こうした流れは、改修・作り直しのコスト構造を変えつつあります。これまで「中身がわからないから手が出せない」とあきらめていたシステムでも、AIによる解析で現状把握のコストが下がれば、改修も作り直しも判断しやすくなります。頼み先を選ぶ際には、こうしたAIを活用した解析・モダナイゼーションに知見があるかどうかも、コストを抑える観点で確認しておくとよいでしょう。

なお、システム改修の基本的な考え方やタイミングについては、システム改修とはもあわせて参考になります。

失敗しない既存システム改修外注の進め方｜見積もり前の準備5ステップ

頼み先の選択肢と費用の考え方がそろったら、いよいよ発注の準備です。改修外注の成否は、見積もりを依頼する「前」にどれだけ情報を整理できているかで大きく変わります。要件定義書が書けなくても問題ありません。発注者として準備すべきことには型があり、それをそろえるだけで見積もりの精度も、相見積もりの比較しやすさも格段に上がります。

ここでは「困りごとの洗い出し」から「保守体制の取り決め」まで、見積もり依頼前の準備5ステップを順に解説します。

見積もり依頼前にそろえる情報

見積もりを依頼する前に、次の4つを整理しておきましょう。これらがそろっていると、頼み先は正確な見積もりを出しやすくなり、認識のズレによる失敗を防げます。

1. 困りごと・改修要望の洗い出し: 「何が困っているか」「どうなってほしいか」を箇条書きで書き出します。専門用語は不要で、「この画面の検索が遅い」「月末の帳票が法改正に合っていない」といった現場の言葉でかまいません。
2. 現状資料の収集: 当時の仕様書、設計書、ソースコードの所在、システムにアクセスするためのアカウント情報などを集めます。資料がそろっているほど現状調査のコストが下がり、見積もりも安くなります。資料が一切ない場合は「資料がない」こと自体を伝えるのが大切です。
3. 改修範囲の明確化: 「どこを直すか」「どこは触らないか」の線引きを考えます。範囲が曖昧だと見積もりが膨らみがちです。
4. 優先度の整理: 改修したい項目が複数ある場合、「必須」「できれば」「将来的に」の3段階で優先度をつけます。予算の都合で全部はできない場合でも、優先度が明確なら段階的に進められます。

要件定義書を完成させる必要はありません。この4つを整理した「困りごとメモ」があれば、頼み先のほうで要件定義を肉付けしてくれます。逆に、これらを丸投げすると「言った・言わない」のトラブルや、想定外の追加費用につながりやすくなります。

複数タイプへの相見積もりで失敗を防ぐ

準備した情報をもとに、必ず複数の頼み先から見積もりを取りましょう。ここでのポイントは、同じタイプ内で比べるだけでなく、異なるタイプを並べて比較することです。

たとえば「開発会社1社」と「フリーランス（複業エンジニア）1名」の両方から見積もりを取ると、中間マージンや体制コストの違いが金額に表れ、自社の改修にどのタイプが合うかが見えてきます。開発会社の見積もりが高く感じても、保守やドキュメント整備まで含まれているなら妥当かもしれません。逆にフリーランスの見積もりが安くても、進行管理を自社で担えなければ実質コストは変わらないこともあります。

相見積もりは単に「安いところを選ぶ」ためではなく、「自社の改修にどのタイプが適しているか」を判断するための材料です。同じ困りごとメモを各社に渡すことで、見積もりの前提がそろい、比較がフェアになります。

改修ならではの注意点

最後に、改修案件だからこそ気をつけたい3つの注意点を押さえておきましょう。

1つ目はデグレードへの備えです。デグレードとは、改修した部分は直ったのに、別の正常だった機能が動かなくなってしまう現象です。改修では「直す部分」だけでなく「影響を受ける既存機能」のテストも欠かせません。見積もりにデグレードテストが含まれているかを確認しましょう。

2つ目は影響範囲の事前確認です。「この機能を変えると、どこに影響が出るのか」を頼み先と事前にすり合わせておくことで、想定外の追加費用やトラブルを防げます。影響範囲を曖昧にしたまま着手すると、後から「ここも直さないと動かない」と費用が膨らみがちです。

3つ目は改修後の保守体制の取り決めです。改修して終わりではなく、その後の不具合対応や追加改修を誰が担うかを最初に決めておきます。とくに特定のフリーランスや個人に依頼する場合は、その人がいなくなったときに困らないよう、改修内容のドキュメント化や引き継ぎを契約に含めておくと、ベンダーロックイン（特定の頼み先に縛られて身動きが取れなくなる状態）を避けられます。

小〜中規模改修はフリーランス（複業エンジニア）への直接依頼という選択肢

ここまで見てきた判断軸を踏まえると、小〜中規模でスポット的な改修において、フリーランス（複業エンジニア）への直接依頼が有力な選択肢になることが見えてきます。開発会社では「最低受注額で割高」「小さい案件は後回し」になりがちだった領域こそ、直接依頼の得意分野です。

ただし、どんな改修にも万能というわけではありません。直接依頼のメリットと注意点の両方を理解したうえで、自社の改修に合うかを判断することが大切です。ここではその両面を公平に整理します。

直接依頼でコストと柔軟性が上がる仕組み

フリーランス（複業エンジニア）への直接依頼が、小〜中規模改修でコストと柔軟性の面で優位になるのは、主に3つの理由からです。

1つ目は中間マージンの削減です。開発会社を介する場合、エンジニアの人件費に営業・管理・品質保証などの間接コストが上乗せされます。直接契約ではこれらが発生しないため、同じスキルのエンジニアに同じ作業を頼んでも、コストを抑えやすくなります。

2つ目はスポット契約による柔軟性です。「必要なときに、必要な分だけ」依頼できるため、小さな改修を頼むのに大きな体制を動かす必要がありません。改修したい項目が出てきたら、そのつど稼働を確保する、という機動的な進め方が可能です。

3つ目は専門性の指名です。改修対象の言語や技術に強いエンジニアを直接指名できるため、ピンポイントで最適な人材に頼めます。特定のフレームワークやレガシー言語に詳しい人を、開発会社の体制とは関係なく選べるのは直接依頼ならではの強みです。

近年は、こうしたフリーランス・複業エンジニアと発注企業をつなぐマッチングの仕組みも整っており、自社の改修に合うスキルを持つ人材を効率的に探せるようになっています。たとえばWorkee（発注者向け）のように、フリーランスエンジニアとのマッチングに特化したサービスを利用することで、直接依頼の候補探しにかかる手間を減らせます。

直接依頼の注意点と備え方

一方で、直接依頼には備えておくべき注意点もあります。これらを理解したうえで対策すれば、リスクを抑えながら直接依頼のメリットを活かせます。

1つ目は属人化のリスクです。特定の個人に依存すると、その人が対応できなくなったときに困ります。改修内容をドキュメントに残してもらう、複数人で対応できる体制を意識する、といった備えで属人化を緩和できます。

2つ目は契約形態の確認です。請負契約（成果物に責任を持つ）なのか準委任契約（作業時間に対して支払う）なのかで、責任範囲や費用の考え方が変わります。改修の内容に応じて適切な契約形態を選び、成果物の範囲や検収の条件を明確にしておきましょう。

3つ目は指揮命令への留意です。業務委託（フリーランスへの直接依頼）では、発注者が個人に対して従業員と同じように細かく指示・管理すると、偽装請負と見なされるおそれがあります。あくまで成果や作業範囲を委託する形を保ち、勤務時間や働き方を一方的に指示しないよう注意が必要です。

4つ目は改修後の引き継ぎです。改修が終わった後、別のエンジニアや社内でメンテナンスできるよう、改修箇所や仕様をドキュメント化しておくことが大切です。これは前章でも触れたベンダーロックイン回避と同じ考え方で、直接依頼でも忘れずに取り決めておきましょう。

これらの注意点は、裏を返せば「準備の型」を整えれば対応できるものばかりです。先述した見積もり前の準備5ステップで困りごとや改修範囲を整理しておけば、直接依頼でも認識のズレを最小化できます。社内に開発リソースがなく、まとまった体制ごと任せたい場合は開発会社やTechBandのようなWeb開発の受託も選択肢になりますが、小〜中規模でスポットの改修なら、直接依頼が現実的でコスト効率の高い選択肢になります。

まとめ｜既存システム改修は「規模に合った頼み先選び」で詰まりが解ける

既存システムの改修外注で「誰に、いくらで、どう頼めばいいかわからない」と詰まってしまうのは、発注者の準備不足ではなく、改修案件の性質と開発会社のビジネスモデルとのミスマッチが原因でした。この構造を理解すれば、頼み先を1社の開発会社に絞り込む前に、選択肢を広げて考えられるようになります。

本記事のポイントを振り返ります。

• 頼み先は5タイプある: 元の開発会社・新規の開発会社・SES・クラウドソーシング・フリーランス（複業エンジニア直接契約）。中〜大規模で保守一体なら開発会社系、継続体制ならSES、小〜中規模でスポット・コスト重視なら直接依頼、という住み分けで考える
• 費用は規模と頼み先で変わる: 小規模は30万円〜、中規模は100万〜500万円、大規模・再構築は1,000万円〜が目安。同じ改修でも中間マージンや体制コストで費用は変わる
• 「直す/作り直す」の判断を先に行う: ブラックボックス化・保守単価上昇・サポート終了が重なるなら、AIによる解析・モダナイゼーションも視野に入れて作り直しも相談する
• 見積もり前の準備が成否を分ける: 困りごと・現状資料・改修範囲・優先度を整理し、異なるタイプを並べて相見積もりを取る。デグレードや保守体制の取り決めも忘れずに

次の一歩は、まず自社の困りごとと改修範囲を「困りごとメモ」として整理することです。そのうえで、改修規模に合った頼み先のタイプを2つほど選び、同じメモを渡して相見積もりを取ってみてください。改修規模に応じて頼み先を選ぶという視点を持てば、「どこに頼めばいいかわからない」という詰まりは確実に解けていきます。