業務システム改修の選定ポイント/選び方/種類

業務システム改修は、まず自社の困りごとに合う依頼形態を選び、そのあとで発注先を比べると進めやすくなります。比べる観点は、発注先の調査力、費用、契約条件です。単価だけで決めず、調査・テスト・保守の範囲まで同じ条件で確かめます。

改修の全体像や他の検討事項は、次のガイドで確認できます。

▼全体ガイドの記事
・業務システム改修の完全ガイド

業務システム改修を発注する前に整理すべき自社の課題

依頼先を探す前に、困りごとを一文で説明できるよう整理しておきます。課題が明確であれば、合う依頼形態と比べる項目を絞り込めます。

属人化・ブラックボックス化の進行度の確認

現状を把握しないまま変更を重ねると、別の機能に不具合が広がるおそれがあります。そのため、変更の担当者や時期、理由を社内で追えない場合は、改修より先に記録と影響範囲を整理しておく必要があります。

見積もりのたびに「調査しないと分からない」と言われる場合は、仕様資料が不足している可能性があります。そこで、現行仕様を洗い出す作業を、改修前の作業として見積もりに含めてもらいます。

改修費用と保守費用の境目の確認

小さな変更でも都度請求される、または月額保守の対象が契約書で分からない場合は、費用の範囲を発注側で整理しておく必要があります。

運用保守費用は、初期開発費用の年額5〜15%程度が目安とされています。ただし、実際の判断は個別契約の対応範囲と照らして行います。

過去1年の改修依頼を、保守の範囲で対応したものと、スポット請求になったものに分けます。スポット依頼が多ければ保守範囲の見直しを検討し、少なければ都度依頼を続ける選択肢もあります。

ポイント

変更の経緯を社内で追えない、または改修費と保守費の境目が契約書で分からない状態なら、依頼先を比べる前に整理を終えておくのが目安です。

業務システム改修の3つの依頼形態

スポット改修、月額保守、内製・伴走を、改修頻度と社内の役割に沿って並べた図解。
改修頻度と社内で担える範囲が、依頼形態を選ぶ手がかりになります。

依頼形態は、改修の頻度と社内で担える範囲に合わせて選びます。主な選択肢は、次の3つです。

  • スポット改修:改修の頻度が低く、案件ごとに発注したい場合に合います。
  • 月額保守の活用:定期的な小規模改修を、保守契約の範囲で進めたい場合に使えます。
  • 内製・伴走:社内担当者が主導し、外部の設計支援や技術支援を受ける形です。

スポット改修型と月額保守活用型の違い

スポット改修は依頼のたびに見積もるため、改修の頻度が低い場合に検討しやすい形です。ただし、最低作業料金が5万〜10万円程度に設定されることもあり、小さな依頼が続くと割高になる場合があります。

月額保守を活用する場合は、発注側が、月◯時間までなどの無償対応の範囲と、超過後にスポット扱いへ切り替わる条件を確かめます。

過去の類似改修にかかった期間と費用を記録しておくと、次の見積もりを比べる材料になります。また、保守契約では、無償範囲を超える条件も事前に合意しておきます。

内製・伴走型におけるローコード/ノーコードの活用

内製・伴走型では、社内が中心となって進め、開発会社から設計や技術の支援を受けます。たとえば、マスタ追加や入力画面の調整などは、ローコード/ノーコード基盤で対応できる場合があります。

候補となる基盤は業務システム改修のパッケージ・クラウド製品一覧で紹介しています。ただし、既存システムとの連携が複雑な場合は、専門会社の関与も残しておきます。

発注先を比較する評価軸

業務システム改修の発注先を、影響範囲の調査、回帰テスト、複数人の対応体制、資料共有で確認する図解。
単価以外の確認項目をそろえると、各社の進め方を比べやすくなります。

短納期を優先して回帰テストを省くと、改修後に不具合が出るおそれがあります。そのため、発注先は単価だけで決めず、影響範囲の調査とテストの進め方を比べます。

影響範囲調査とテスト体制の具体性の確認

「影響範囲を調査する」と説明されたら、対象画面・帳票・バッチ処理をどう特定するかを聞きます。さらに、資料の有無を踏まえた調査工数の根拠も確認しておくと、追加費用を想定するうえで役立ちます。

回帰テストで自動化する範囲と、テスト項目や結果の報告形式も確認します。結果が記録に残れば、次回の改修で確認すべき範囲を引き継ぎやすくなります。

個人依存かチーム体制かの確認

特定の技術者に頼る体制では、その担当者が不在になると引き継ぎが難しくなる可能性があります。そのため、複数人で対応できるか、設計書や変更履歴が共有されているかを、契約前に確かめておきます。

「担当者が急に対応できない場合、どう引き継ぐか」と尋ねると、体制の具体性が見えてきます。さらに、複数名でのレビューや資料共有の方法まで説明できるかも、比べる材料になります。

ポイント

発注先は単価だけで決めず、影響範囲の調査、テストの範囲、担当者が不在でも引き継げる体制を同じ基準で比べます。回帰テストを省く提案は、短納期を優先していないかを確かめるのが目安です。

費用・契約条件を比較する評価軸

費用は、改修費と保守費を分けたうえで、各見積もりに含まれる作業範囲まで比べます。たとえ金額が同じでも、対象とする作業が違えば、実質的な負担は異なります。

スポット費用と運用保守費用を別々に確かめる質問

総費用が1,000万〜5,000万円規模の場合、月額保守費用はおおむね4.1万〜62.5万円以上が目安とされます。

手厚い支援では月額50万〜150万円程度の例もあるため、軽微な改修がどこまで含まれるか、対象外となるスポット単価はいくらかを、契約書で確かめます。

見積もりは、画面数や想定工数、影響範囲をそろえたシナリオで依頼します。そのため、同じ条件で比べると、金額の差が単価によるものか、作業範囲によるものかが見えてきます。

契約条件としてのSLAと業務範囲の文書化

対応時間、月額内の作業範囲、緊急対応の扱いは、口頭で説明されただけでは後に解釈が分かれるおそれがあります。そのため、費用区分とSLAを契約書や合意文書に記載できるかも確かめます。

過去に困った事例を伝え、その場合にどの条項で対応するかを尋ねます。具体例に沿って確かめると、SLAが実務で機能する内容かどうかを判断しやすくなります。

ポイント

費用は改修費と保守費を分け、作業範囲をそろえた見積もりで比べます。月額保守の無償範囲を超えた場合の扱いや、SLAの具体例への対応を契約前に文書で残せるかが、判断の目安になります。

PoC・小規模検証を使った発注先選定の進め方

同じ課題と条件を候補先に示し、見積もりと進め方を比べ、小規模なPoCの結果から本改修への移行を判断する流れ。
検証の出口条件を先に決めると、結果を本発注の判断につなげられます。

提案書だけで候補を決めきれない場合は、小規模なPoCやプロトタイプで、実務への対応力を確かめます。また、複数社に同じ課題を示せば、進め方を比べられます。

候補先には同じ課題と条件を示し、見積もりと進め方を出してもらいます。提案の速さに加えて、質問の的確さや、事前にリスクを指摘する姿勢も確認します。

要件定義フェーズだけを先行発注する方法

本改修の前に、要件定義だけを30万〜50万円程度で先行して依頼する方法があります。この方法なら、影響範囲や進め方の提案を見てから本発注を決められます。

抽象的な資料のまま進めると、要件の解釈違いにつながります。そのため、提出される資料で、影響する画面・帳票・バッチ処理、回帰テストの範囲、残課題やリスクが具体的に示されているかを確かめます。

タイムボックスの設定と本発注の判断

検証期間は、対象業務サイクルの2倍以上を目安にし、最長3か月以内に結論を出す期限を設けます。そのうえで、本改修へ進む条件と撤退する条件を、発注先と先に合意しておきます。

期限がなければ、検証が長引いて判断を先送りしがちです。そこで、判断日をカレンダーに記し、その日までの結果で決めるルールを関係者で共有しておきます。

ポイント

提案書だけで決めきれないなら、小規模な検証で実務への対応力を見るのが目安です。その際は、検証期間の上限と本発注へ進む条件を、事前に決めておきます。

全面刷新への切り替えを判断する基準

依頼先を選ぶ前に、課題が改修で解決できる規模かどうかを確かめます。全面刷新に近い場合は、改修を前提にした比較を見直します。

コストの逆転現象・業務変更度合い・会計上の解釈による判断

複数社から作り直しを勧められたら、改修と刷新の費用や工数が逆転していないかを確かめます。そのうえで、業務フローを維持できるか、BPRを伴うか、修繕費と資本的支出のどちらに近いかを整理します。

改修の範囲は発注先によって見立てが異なるため、社内にも判断の基準を持っておきます。同じ依頼への各社の意見を自社の基準に照らせば、提案の妥当性を検討できます。

複数の発注先から得るセカンドオピニオン

一社の見立てだけで刷新を決めず、改修を得意とする会社と、刷新も扱う会社の双方に相談します。判断理由を並べて比べると、提案の偏りが見えてきます。

「刷新か改修か」だけでなく、判断の根拠も尋ねます。どのコードやデータ構造を見て結論を出したかを聞くと、調査に基づいた提案かどうかを見極められます。

業務システム改修導入前に確認しておきたいポイント

候補を絞ったら、既存ベンダーとの関係と内製の担当範囲を契約前に決めておきます。この2点は、依頼後の責任分担に関わるためです。

既存の保守ベンダーに依頼すべきか迷う場合の考え方

既存ベンダーは内部構造を把握しているため対応が速い一方で、他社との価格や提案の比較が不足しがちです。そこで、年に一度、小規模な依頼を別の会社にも相談してみると、契約の妥当性を確かめられます。

内製化の限界の事前設定

ローコード/ノーコードによる内製は、画面や項目の変更に適しています。ただし、複雑な基幹連携やセキュリティ要件には専門知識が必要になるため、外部へ依頼する範囲を決めておく必要があります。

たとえば、認証・権限管理、外部システムとのAPI連携、大量データ処理は、専門開発の対象として切り分ける候補になります。担当範囲をはっきりさせておけば、内製側が無理に抱え込む事態を防げます。

まとめ

選定は、自社の課題を整理し、スポット改修・月額保守・内製伴走から合う形態を選ぶ順で進めます。発注先は、調査・テスト、費用区分、SLAを比べたうえで、小規模検証も使って対応力を確認します。

複数社が改修の範囲を超えると判断した場合は、全面刷新も選択肢に含めます。

riplaはフルスクラッチ開発の立場から、改修か刷新かの検討、既存システムを活かす改修、既存システムと連携する構築を支援しています。

▼全体ガイドの記事
・業務システム改修の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。