システム改修には、画面表示を少し直すだけの軽微な修正から、複数機能にまたがる中規模の改修、老朽化したモジュールを作り直すミニリビルドまで、幅広い規模の依頼が含まれます。開発会社の知名度や見積もりの安さだけで選ぶと、既存システムの影響範囲調査やテスト計画が不十分なまま進んでしまい、リリース後にトラブルが発生することも少なくありません。選定の出発点は、自社の依頼がどの規模・種類に近いかを整理することです。
本記事では、システム改修の依頼前に整理すべき自社課題、規模別の3つの種類、開発会社を比較する評価軸、内製・外注・ハイブリッドの選び分け、見積もり依頼書(RFP)とPoC・モックアップの進め方を解説します。これから開発会社を探す担当者の方が、比較の軸をそろえ、自社に合う進め方と依頼先を具体的に絞り込めるよう整理しています。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・システム改修の完全ガイド
システム改修の依頼前に整理すべき自社の課題
システム改修を依頼する前に、まず自社が抱える課題を「対象範囲」「緊急度」「保守契約との関係」の3つの軸で整理すると、必要な進め方や見積もりの依頼先が具体化します。
対象範囲と緊急度を切り分けます
システム改修の依頼内容は、緊急の不具合対応、計画的な機能追加、老朽化したモジュールの作り直しの大きく3つに分かれます。緊急性の高い不具合対応であれば保守契約の枠組みで即応できる体制を優先し、計画的な機能追加であれば要件定義から進める通常のプロジェクトとして扱います。この2つを同じ依頼として一緒に進めてしまうと、緊急対応の遅延や、計画的な改修の要件が固まらないまま着手してしまうといった混乱が生じやすくなります。
対象範囲についても、特定の画面だけを直したいのか、複数の業務にまたがる連携部分を見直したいのかによって、必要な調査工数や関わる部門の数が変わります。依頼前に、変更したい機能の一覧と、それぞれの緊急度・影響範囲をひとつの表にまとめておくと、開発会社への説明や見積もり依頼がスムーズになります。
保守契約内で対応できるかを見極めます
一般的な保守・運用費用は初期開発費用の年額15〜20%程度が目安とされ、小規模システムであれば月額数万円〜10万円前後、中規模システムであれば月額10万円〜50万円程度、大規模・基幹システムであれば月額60万円〜100万円以上になることがあります。この保守契約に含まれるのは、バグ・障害修正やOS・ミドルウェアのセキュリティパッチ適用、稼働監視、操作の問い合わせ対応などが中心です。
1〜2時間程度で終わる表示文言の修正や画像の差し替えといった軽微な変更は無償対応の範囲に含まれることが多い一方、新機能の追加や業務ルールの変更、帳票フォーマットの追加など、数日〜1週間以上の作業を要する変更は保守契約の範囲外として、別途の改修費用が発生することが一般的です。保守契約外のスポット対応には最低作業料金(目安5〜10万円程度)が設定されている場合もあり、実作業が30分程度でも一定の費用がかかることがあるため、依頼前に契約書の対応範囲を確認しておくことが重要です。
システム改修の3つの種類
システム改修と一口に言っても、対象とする規模によって進め方や関わるベンダーの体制は大きく異なります。自社の依頼がどの種類に近いかを把握すると、比較すべき開発会社の絞り込みがしやすくなります。
軽微な修正・パッチ型
画面表示の調整や入力項目の追加、簡単な設定変更など、既存のコードにほとんど手を入れずに対応できる軽微な改修です。作業自体は数千円〜数万円程度で収まることもありますが、保守契約外のスポット対応として依頼する場合は、最低作業料金が設定されているケースもあるため、費用感を事前に確認しておくとよいでしょう。
このタイプは、開発会社にとっても着手判断がしやすい反面、依頼件数が積み重なると社内でどの改修をどのベンダーに依頼したかが分からなくなりやすい面があります。軽微な改修であっても、依頼内容と対応結果を記録に残しておくと、後から似た修正が発生した際に過去の対応を参照でき、同じ確認作業を繰り返さずに済みます。
複数機能改修・中規模型
ECサイトやWEBサービスの機能追加など、複数の画面や業務フローにまたがる改修です。目安として約4〜8ヶ月程度、予算目安として数百万円規模になることが多く、要件定義・設計・開発・テスト・リリース準備という一連の工程を踏んで進めます。関係部門が複数にまたがるため、要件定義の段階で担当者を巻き込んでおくことが重要です。
この規模になると、現場担当者だけでなく、情報システム部門や場合によっては経営層の承認を要することもあります。要件定義の初期段階で、誰が最終的な仕様を承認するのか、変更が生じた場合にどのように追加費用を判断するのかを決めておかないと、開発途中で仕様変更が繰り返され、当初の期間・予算を超過しやすくなります。
モジュール再構築・ミニリビルド型
老朽化した特定モジュールだけを新しく作り直すタイプの改修です。既存コードを活かすパッチ的改修とは異なり、対象モジュールをフルスクラッチで作り直すため、小規模な範囲であっても数百万円〜2,000万円程度の予算感になることがあります。ストラングラーフィグパターンのように、旧モジュールと並行稼働させながら段階的に置き換える進め方が採られることもあります。
ミニリビルドを依頼する場合は、新旧モジュールをつなぐ連携処理(グルーコード)の設計力が開発会社選定の重要な観点になります。連携部分の設計が甘いと、移行期間中にデータの不整合や二重処理が発生しやすくなるため、並行稼働の期間中にどのような検証を行うのか、切り戻しの判断基準をどこに置くのかを提案段階で確認しておくことをおすすめします。
開発会社選定で比較すべき評価軸
候補となる開発会社は、既存システムへの調査力、テスト計画の妥当性、見積もりの透明性、保守体制という軸で比較します。同じ質問を各社へ投げかけ、回答の具体性を比べることで、説明の分かりやすさだけに引っ張られない判断ができます。
調査力とドキュメント対応力を確認します
既存システムの仕様書が整理されていない、あるいは担当者が退職しているといった状況は珍しくありません。候補企業に、着手前の調査工程をどのように進めるか、影響範囲の洗い出しにどの程度の期間を見込むかを具体的に説明してもらいましょう。調査工程を軽視し、いきなり実装から着手しようとする提案には注意が必要です。
テスト計画とリリース体制を確認します
改修対象の機能だけでなく、周辺の既存機能に悪影響(デグレード)が出ていないかを確認する回帰テストの計画を持っているかも重要な比較軸です。単体・結合・総合テストのどこまでを見積もりに含めているか、本番リリース時の切り戻し手順を用意しているかを確認すると、リリース後のトラブルを未然に防ぎやすくなります。
見積もりの内訳と保守体制を確認します
見積書には、調査・設計・開発・テスト・リリース準備の工程ごとの工数と、上級SE・中級SE・プログラマーといった担当者の単価が示されているかを確認します。一般的な人月単価の目安は、上級SEで120万〜160万円程度、中級SEで100万〜120万円程度、プログラマーで40万〜100万円程度とされていますが、会社規模や体制によって幅があります。改修後の保守をそのまま任せられるのか、既存の保守契約とどう接続するのかも、あわせて確認しておくべき項目です。
内製・外注・ハイブリッドの選び分け
システム改修は、すべてを外部ベンダーに依頼する以外にも、自社で対応できる作業を巻き取ったり、ローコードツールと外注を組み合わせたりする進め方があります。予算と社内リソースに応じて、進め方を選び分けることが重要です。
内製で巻き取れる範囲を見極めます
業務フロー分析やテストパターンの作成、マニュアルの執筆、操作研修といった作業は、自社で対応できれば外注費を抑えられます。すべてを内製化しようとするのではなく、開発会社の専門性が必要な設計・実装・テストの中核部分と、自社で巻き取れる周辺作業を切り分けて依頼範囲を決めることがポイントです。
内製化を進める際は、担当者の異動や退職によって知見が失われないよう、業務フローやテスト観点をドキュメントとして残しておくことも欠かせません。属人的な確認作業に頼ったまま内製範囲を広げると、次の改修の際に再び同じ調査を一からやり直すことになりかねません。
ローコードと外注のハイブリッドで進めます
簡単な画面や承認フローの追加であれば、ローコード・ノーコードツールを使って社内で対応し、既存システムの深い部分に関わる改修だけを外部の開発会社に依頼するという役割分担も考えられます。ローコードツールで対応できる範囲は製品によって異なるため、着手前にどこまでを内製でカバーできるかを整理しておくと、外注費用を必要な範囲に絞り込めます。
一方で、ローコードツールで作成した画面やワークフローを、既存の基幹システムとどう連携させるかは別途の検討が必要です。API連携やデータベース接続の設計は専門知識を要するため、ローコードで完結する範囲と、外部の開発会社に接続部分を依頼する範囲をあらかじめ線引きしておくと、後から想定外の追加開発が発生しにくくなります。
見積もり・RFPとPoC・モックアップの進め方
候補企業を比較する際は、口頭の説明だけで判断せず、見積もり依頼書(RFP)と小規模なPoC・モックアップを通じて、実際の対応力を確認することが重要です。
見積もり依頼書(RFP)に盛り込む項目
RFPには、対象システムの概要、改修したい機能や課題、希望する納期、現行システムのドキュメントの有無、想定される外部連携の有無を記載します。あわせて、調査・設計・開発・テスト・リリースの各工程にどの程度の工数を見込んでいるかを提示してもらうよう依頼すると、各社の見積もりを同じ条件で比較しやすくなります。
必須要件と、対応できれば望ましい要件を分けて記載しておくことも重要です。すべてを必須として提示すると、対応できる開発会社が絞られすぎてしまい、比較検討の幅が狭まります。優先順位を明示したRFPを用意すれば、各社が現実的な提案をしやすくなり、見積もり内容の質も高まります。
PoC・モックアップで手戻りを防ぎます
改修内容が既存の画面や業務フローに適合するかは、内部処理を持たない静的なモックアップで事前に確認できます。外部システムとの連携を伴う改修であれば、テスト用のモックを使った小規模なPoCで技術的な実現可能性を数週間程度で見極めることも有効です。本実装に入る前にこうした検証を挟むことで、後工程での手戻りや追加費用の発生を抑えられます。
PoCやモックアップを実施する際は、確認したい観点を事前に一つか二つに絞り込み、合格基準を明文化しておくことが大切です。観点を絞らずに進めると、検証範囲が際限なく広がり、本来は数週間で終わるはずの検証に数ヶ月かかってしまうこともあるため注意が必要です。
システム改修選定の失敗を避ける方法
システム改修の選定でよくある失敗は、金額の安さや対応の速さだけで開発会社を決め、調査工程やテスト計画を省いてしまうことです。目先のコストだけでなく、中長期的な視点も含めて判断することが重要です。
安易な書き換えが技術的負債を増やします
見積もりの安さを優先して、影響範囲の調査を省略した提案を選んでしまうと、改修後に想定外の不具合が発生したり、次の改修の際にさらに調査工数がかかったりすることがあります。パッチ的な改修を繰り返すだけの対応は、短期的には安価でも、内部構造の複雑化(技術的負債の蓄積)を招きやすい点に注意が必要です。具体的な製品・サービスの候補を確認したい場合は、システム改修のパッケージ・クラウド製品一覧を参照すると、比較の材料を整理しやすくなります。
運用ルールと責任者も同時に決めます
改修後の運用ルール、たとえば次の改修依頼の窓口、保守契約との切り分け、ドキュメントの更新担当者を決めずに進めると、改修が完了した後もシステムの状態を正しく維持できません。開発会社の選定と並行して、社内側の責任者と運用フローも明確にしておくことが、選定を成功させる前提になります。
システム改修選定前に確認しておきたいポイント
候補を絞った後も、金額や納期だけでなく、既存システムへの理解度や運用体制まで踏み込んで確認することで、着手後の認識違いを防げます。
少額の改修でも複数社から見積もりを取るべきか
改修金額が小さい場合でも、調査工程の有無やテスト計画の充実度によって費用と品質に差が出ます。可能であれば2〜3社から見積もりを取り、金額だけでなく調査・テストの内容を比較することをおすすめします。ただし、緊急性の高い不具合対応の場合は、比較検討に時間をかけすぎず、まずは既存の保守契約先へ即応を依頼するという判断も必要です。
保守契約中のベンダーにそのまま依頼すべきか
既存の保守契約先は現行システムを把握しているという利点がありますが、必ずしも改修の提案力やテスト体制に優れているとは限りません。継続依頼のしやすさと、調査力・提案力を天秤にかけたうえで判断してください。特に、複数機能にまたがる中規模の改修やモジュール単位の作り直しでは、保守対応と改修提案とで求められる専門性が異なる場合があるため、規模に応じて依頼先を分ける選択肢も検討する価値があります。
PoCにはどの程度の期間・予算が必要か
改修規模にもよりますが、検証範囲を1つの機能や連携に絞ったPoC・モックアップであれば、数週間程度の短期間で実施できることが一般的です。検証の目的をあらかじめ一つに絞ることで、期間と費用を抑えながら必要な判断材料を得られます。複数の観点を同時に検証しようとすると期間が延びやすいため、最も不確実性の高い一点に絞って先に検証することをおすすめします。
まとめ
システム改修の選定では、対象範囲と緊急度、保守契約との関係を整理したうえで、改修の種類を見極め、調査力・テスト計画・見積もりの透明性・保守体制という評価軸で候補を比較することが重要です。
課題整理から評価軸への比較へ進みます
緊急の不具合対応か計画的な改修か、パッチ的な修正で足りるかモジュールの作り直しが必要かを見極めたうえで、RFPとPoCを通じて候補企業の調査力・テスト体制を確認すれば、価格の安さだけに左右されない選定ができます。
既存システムの理解を重視した相談先を選んでください
システム改修は、既存資産をどれだけ正確に理解できるかによって、成果物の品質と将来のコストが大きく変わります。riplaはフルスクラッチ開発の立場から、既存システムの影響範囲調査、パッチ的改修とミニリビルドの判断、ローコードツールや既存SaaSとの連携を含めた低予算での改修提案を行っています。評価軸をさらに詳しく確認したい場合は、システム改修とは？｜考え方・特徴・仕組み・目的を解説もあわせてご覧ください。
▼全体ガイドの記事
・システム改修の完全ガイド
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。