システム改修とは何か、本記事では基本的な部分から外部委託する場合の費用や進め方について、解説しています。
システム改修を自社または外部委託を検討している方に、是非参考にしていただければ幸いです。
目次 [非表示]
1.システム改修とは
1章では、システム改修とは何か解説していきます。
1-1 現状のシステムを使いやすくすること
システム改修とは、現状使用しているシステムを使いやすくするために手を加えることです。
例えば、ユーザーより「このボタンの位置が分かりにくい」、「出力の機能を加えてほしい」などシステムの機能を修正・追加することをシステム改修と言います。
注意していただきたいのは、よく聞くシステム開発は新しく0から作り上げることであり、出来上がっているシステムに手を加える改修とは異なるものである点を抑えておきましょう。
1-2 なぜ改修なのか？
ではシステムを新規開発するのではなく、改修をする理由について解説していきます。
理由としては、新規開発をするよりも改修をする方がコスト的にも抑えることができ、比較的短期間で作業が完了するためです。
また、単に新しく開発をする必要が無いと判断した場合は改修をする流れとなります。
とはいえ、新規で開発をすべきケースもあり、次項で解説していきます。
1-3 改修より新しく開発をした方が良い場合がある
前項で解説した通り、コストや時間など改修をした方がメリットが多いこともありますが、新規で開発をした方が良いケースも存在します。
- システムの見た目や中身の機能面、サーバ環境などほとんどを刷新する場合
- AIなどの新技術を搭載し、最適化されたシステムを構築する場合
- システムの外注業者に相談したところ新規開発をすべきと提案された場合
上記のような場合は新規での開発を行うことをおすすめします。
1-4 システム改修の費用
それでは、システム改修をするのにどのぐらいの費用が掛かるのか…改修するシステムの規模・複雑さによって大きく差が生じますが、一般的には200万円前後と言われています。
下記は外注した場合の1名あたりの単価であり、これらが必要人数に合わせて積み上げられたものが改修費用になります。
規模によっては1名でも改修ができますし、大規模になればエンジニアが数百名必要なケースもあり得ます。まずは、1名あたりの費用感を抑えておくと概算でも費用が見えてくるのではないでしょうか。
| ポジション | 業務 | 人月単価 |
|---|---|---|
| プロジェクトマネージャー （PM） | システム開発全体の進捗管理 | 70万円～200万円 |
| プロジェクトリーダー （PL） | PMの補佐 | 70万円～120万円 |
| システムエンジニア （SE） | 要件定義や仕様書の作成、プログラミング | 初級：80万円～100万円 ※歴5年以降 中級：100万円～120万円 ※歴7年以降 上級：120万円～200万円 ※歴10年以降 |
| プログラマー （PG） | プログラミング | 40万円～70万円 |
あくまで外注した場合の費用感であり自社内で行う場合は自社エンジニアの給与が主にかかる費用です。
2.システム改修が必要になるタイミング
2章では、システム改修が必要になるタイミングについて解説していきます。
2-1 DX推進への一歩
近年は、企業としてDX推進することは当たり前になってきました。DX推進の一歩として、一番手を付けやすいのが既存システムの改修になります。
今、使っているシステムはいつから使っているのか（今の時代に合っていない）…もっとここを改善したら使いやすくなる…など小さいところから手を加えていって、着実にステップアップしていくのが近道です。
既存システムを改修することで、紙ベースの業務をデジタル化したり、手作業で行っていた処理を自動化したりすることができ、業務効率化や生産性向上を実現できます。
特に、以下のような課題を抱える企業では、DX推進を目的としたシステム改修が効果的です。
- 紙の書類やExcelでの情報管理が多い
- 部門間でのデータ共有が困難
- 手作業による処理ミスが頻発
- リモートワークへの対応が不十分
- 顧客データの一元管理ができていない
2-2 バグなどの不具合が頻発
システムを使用していく中で、「データが反映しない」、「入力してもエラーが出て先に進めない」などのバグや不具合の発生時にはシステム改修を行いましょう。
また、システムは長年使用を続けていく中で、動作が遅いなどの不具合が発生することがあります。このようなケースであれば改修を行い、使い勝手を良くしていくことが重要です。
ただ、改修によって別の個所で不具合が発生するケースもあるため、注意が必要です。
2-3 現行システムの使い勝手が悪い
よくあるケースとしては、「ボタンの位置が分かりにくい」、「入力後の確認画面が無い」など不具合ではないが使い勝手が悪いといったタイミングで改修を行いましょう。
「システムを開発したもののユーザー目線では使いづらい」ということはよくあり、業務効率を下げないためにも素早く対応することをおすすめします。
また、新機能を搭載したい場合も改修を検討しましょう。どのくらいの規模なのか、そして内容によっては新しく開発をした方が良いケースもありますが、最終的には信頼するシステムのプロへ相談して決めましょう。
2-4 OSやミドルウェアのサポート切れ
OSやミドルウェアのサポート切れのアナウンスがあった場合は新しいOS、ミドルウェアへのシステム改修を検討しましょう。
サポート切れのままで使用することでアップデートなども提供されなくなり、セキュリティ上の問題が発生する可能性が高まります。
そのため、速やかに改修を進めることをおすすめします。
2-5 法改正への対応
例えば、消費税の増減税、新元号など法改正によりシステムの一部を変更する必要が発生することもあります。その場合はシステムの改修を行いましょう。
直近だとインボイスなど対応がありました。当然ながら法令遵守の観点から対応をすることは必須となります。
2-6 セキュリティ対策
システムのセキュリティ上で脆弱な点があれば即座に対応すべきです。
特に情報漏洩は企業に対して大きな損害を与えてしまいます。システムの脆弱な部分からサイバー攻撃をされればすぐに情報は漏洩してしまいます。
3.システム改修の準備と現状分析
システム改修を成功させるためには、改修作業に入る前の準備と現状分析が極めて重要です。この段階を軽視すると、後々大きな問題となる可能性があります。
そこで、3章ではシステム改修前の準備として何をしたら良いのか解説していきます。
3-1 システム棚卸しの重要性
まずは現在使用しているシステムの全体像を正確に把握することから始めます。
<システム構成の詳細調査>
- ハードウェア構成: サーバー、ネットワーク機器、端末の仕様・設置場所
- ソフトウェア構成: OS、ミドルウェア、アプリケーションのバージョン情報
- データベース構成: テーブル構造、データ量、インデックス設定
- 外部システム連携: API、データ連携、バッチ処理の詳細
<ドキュメントの整備状況確認>
- 設計書: 要件定義書、基本設計書、詳細設計書の有無と最新性
- 運用手順書: 日常運用、障害対応、バックアップ手順
- 過去の改修履歴: いつ、誰が、何を、なぜ変更したかの記録
3-2 業務フロー分析と課題の洗い出し
現在の業務プロセスを詳細に分析し、改修によって解決すべき課題を明確にします。
<業務フロー分析の手法>
- As-Is分析: 現在の業務フローの詳細な可視化
- ユーザーヒアリング: 実際の利用者からの課題・要望収集
- 操作ログ分析: システムの実際の使用状況データ分析
- ボトルネック特定: 業務効率を阻害している箇所の特定
<課題の分類と優先順位付け>
| 分類 | 内容 | 優先度判定基準 |
|---|---|---|
| 機能不足 | 必要な機能が実装されていない | 業務への影響度 |
| 操作性 | 使いにくい、分かりにくい操作 | ユーザー数×頻度 |
| 性能問題 | 処理速度が遅い、応答性が悪い | 業務時間への影響 |
| 安定性 | エラーやシステム停止が頻発 | ビジネスリスク |
3-3 技術的負債の洗い出し
続いて技術的負債の洗い出しをしましょう。長年運用してきたシステムには、技術的負債が蓄積されている可能性があります。
<技術的負債のチェックポイント>
- 古いバージョンの使用: サポート終了間近のOS・ミドルウェア
- 非標準的な実装: 独自仕様やワークアラウンドの多用
- セキュリティホール: 脆弱性のあるコンポーネントの使用
- 保守性の低下: 複雑すぎるコード、ドキュメント不備
<技術的負債の影響評価>
- 短期的リスク: 現在発生している問題
- 中長期的リスク: 将来発生が予想される問題
- 対応コスト: 解決に必要な工数・費用
- 対応優先度: ビジネスへの影響と対応の緊急度
3-4 優先順位の決定方法
これで、改修作業でやることは見えてきました。あとは、限られた予算と時間の中で最大の効果を得るため、改修項目の優先順位を適切に決定します。
<優先順位決定のフレームワーク>
改修項目を以下の4つの観点で評価し、スコアリングします：
| 評価軸 | 重要度 | 評価基準（5段階） |
|---|---|---|
| ビジネスインパクト | 高 | 業務効率化・売上向上への貢献度 |
| 実装難易度 | 中 | 技術的複雑さ・所要工数 |
| 緊急度 | 高 | 現在の問題の深刻さ |
| 投資対効果 | 中 | コストに対する効果の大きさ |
<改修計画の策定>
- Phase 1: 緊急性が高く、比較的簡単な改修
- Phase 2: ビジネスインパクトが大きい主要機能の改修
- Phase 3: 将来的な拡張性を考慮した基盤整備
3-5 現状分析結果の文書化
最後に、分析結果は後の工程で重要な参考資料となるため、適切に文書化します。
<現状分析レポートに含めるべき項目>
- システム概要: 現在のシステム構成と機能概要
- 課題一覧: 発見された問題点と影響度
- 改修提案: 優先順位付けされた改修項目
- リスク評価: 予想されるリスクと対策案
- 工数・予算見積もり: 各改修項目の概算コスト
この現状分析をしっかりと行うことで、その後のシステム改修プロジェクトの成功確率が大幅に向上します。急がば回れの精神で、十分な時間をかけて現状分析に取り組むことをお勧めします。
4.システム改修が始まってからの流れ
システム改修が始まってからの流れについて解説していきます。
4-1 要件定義～運用保守まで
まずは要件定義を行います。
機能要件の定義、非機能要件の定義、制約条件の明確化を行い、それらを文書化します。開発は要件定義で定められた内容を基にPMが管理を行い進めていきます。
※要件定義の詳細は、「要件定義とは？基本設計／詳細設計との違いと進め方を解説」の記事をご参照ください。
次に基本設計、詳細設計を行います。
要件定義を基に実装の方法やシステムのインターフェースなどの設計を行います。これらを基に実装（プログラミング）へ進んでいきます。
※基本設計の詳細は、「基本設計とは？進め方と要件定義／詳細設計との違いを解説」の記事をご参照ください。
※詳細設計の詳細は、「詳細設計とは？進め方と要件定義／基本設計との違いを解説」の記事をご参照ください。
そして実装、テストのフェーズへ進み、設計書を基にプログラミング、テストを行います。特に改修の際に重要となるのがテストであり、その中でもデグレードテストは注意深く行いましょう。
このテストはシステム改修によりソースコードの書き直しが行われた結果、システムに不具合が発生していないか確認するテストです。
改修は既存のシステムを使いやすくするために行われることから、他への影響が懸念されるため特に注意深くテストを行いましょう、主にPGが担当しますが、状況によってSEが担当することもあります。
最後に運用保守を行い必要に応じて改修を実施するなど、システムの安定運用を目指します。
4-2 システム開発のエンジニア別役割
フェーズごとに担当する役割の一覧です。
| 役割 | 主な担当業務 |
|---|---|
| PG （プログラマー） | 実装やテスト工程を主に対応 |
| SE （システムエンジニア） | 要件定義、基本設計、詳細設計、実装を主に担当 |
| PM （プロジェクトマネージャー） | 開発全体の統括を主に担当 |
| PMO （プロジェクトマネジメントオフィス） | コストの調整、プロジェクト管理支援、PMの補佐を主に担当 |
*PM（プロジェクトマネージャー）とPMO（プロジェクトマネジメントオフィス）は、全体の管理がメインとなるため、全てのフェーズに関与していきます。
*SE（システムエンジニア）は、要件定義～実装まで関与しますが、状況によってはテストの以降のフェーズにも関与することがあります。
*PG（プログラマー）は、実装以降のフェーズを主に担当をします。
5.システム改修を始める手段
システム改修を進めるためには外部委託か自社で開発をするかの2択になります。自社の状況に合わせて選択していきましょう。
5-1 外部委託（アウトソーシング）
システム改修のプロに依頼します。
多少の費用は発生するものの、プロの技術で改修を進めてもらえるため、依頼後は待つだけで、きちんとしたシステムが納品されます。
「自社にエンジニアがいない」「自社にエンジニアはいるが、不足している」場合など…は、積極的に外部委託を検討してみましょう。
費用が掛かるので一歩踏み出せない方は、コストを削減する方法はいくつかあります。その中でも一番効果的なのは、オフショア開発とも言われています。
オフショア開発については、「オフショア開発とは？概要やメリット、成功させるポイントを紹介」の記事をご参照ください。
5-2 自社開発
自社内でシステム改修を進めます。
自社内にエンジニアがいる場合は、検討してみても良いでしょう。ただ、改修する難易度やエンジニアが持つスキルでは対応が難しい場合もあります。
自社内で使用するシステムであれば、エンジニアの育成も兼ねて、多少背伸びでも挑戦しみても良いですが、販売中のシステムなど素早く改修する必要がある場合は、外部委託を検討する方が良いでしょう。
5.システム改修のリスクと対策
システム改修は多くのメリットをもたらしますが、同時に様々なリスクも伴います。事前にリスクを把握し、適切な対策を講じることで、プロジェクトの成功確率を大幅に向上させることができます。
そこで5章ではそのリスクと対策を紹介します。
5-1 よくある失敗パターンと原因
システム改修プロジェクトでよく発生する失敗パターンを理解しておくことで、同じ轍を踏むことを避けられます。
<スケジュール遅延>
- 原因: 要件定義の曖昧さ、テスト工程での予期しない不具合発見、リソース不足
- 影響: 運用開始の遅れ、追加コストの発生、関係者への影響
<予算オーバー>
- 原因: 追加要件の発生、技術的な想定外の課題、工数見積もりの甘さ
- 影響: プロジェクト継続の危機、品質妥協の可能性
<既存機能への悪影響（デグレード）>
- 原因: 既存システムの理解不足、不十分なテスト、複雑な依存関係の見落とし
- 影響: 業務停止、データ不整合、ユーザーの信頼失墜
<ユーザーの混乱と反発>
- 原因: 事前説明不足、操作性の大幅な変更、教育・研修の不備
- 影響: 業務効率の一時的低下、システム利用率の減少
<データ移行の失敗>
- 原因: データ形式の不整合、移行手順の不備、バックアップ不足
- 影響: 重要データの消失、業務継続不可
5-2 効果的なリスク軽減策
これらのよくある失敗を避けるためには何をしたら良いのか紹介します。
<段階的リリースの実施>
一度にすべての機能を改修するのではなく、段階的に実施することでリスクを分散させます。
- パイロット版: 限定的なユーザーグループで先行実施
- 段階的展開: 機能単位、部門単位での順次展開
- フィードバック反映: 各段階での課題を次段階に活かす
<包括的なバックアップ・ロールバック計画>
万が一の事態に備えて、迅速に元の状態に戻せる体制を整備します。
- 完全バックアップ: システム、データ、設定情報の完全保存
- ロールバック手順書: 具体的な復旧手順の文書化
- 復旧テスト: 実際にロールバックできることの事前確認
<十分なテスト期間と多角的テスト>
- 単体テスト: 個別機能の動作確認
- 結合テスト: システム間の連携確認
- デグレードテスト: 既存機能への影響確認
- ユーザー受け入れテスト（UAT）: 実際の業務フローでの確認
- 負荷テスト: 本番環境での性能確認
<コミュニケーション計画の策定>
- ステークホルダー管理: 関係者への定期的な進捗報告
- ユーザー教育: 操作方法の事前研修・マニュアル整備
- 問い合わせ窓口: 改修後のサポート体制構築
5-3 緊急時対応体制
改修後に問題が発生した場合の対応体制を事前に整備しておきます。
- エスカレーション体制: 問題の重要度別対応フロー
- 24時間サポート: 重要システムの場合の緊急対応体制
- 代替手段: システム停止時の業務継続手段
「システム改修」まとめ
システム改修は、自社内にある古いシステムを現代に合わせたシステムに改修することです。これはDX推進に向けた一歩でもあり、まずは細かいところ、簡単に手直しできるところから始めると良いでしょう。
- 「社内のシステムが古すぎて、知識ある人がいないけど、外部で対応してくれるのかな…」
- 「システム改修を外部に出すと目が飛び出る金額なんだけど、もっと安くできないかな…」
- 「システム改修の一部分だけを外部で対応してくれるところないかな…」
こんなお悩みありませんか？
弊社はお客様に合わせて様々な体制を組むことが強みでもあり、オフショア開発、ニアショア開発、オンサイト（常駐型）開発、受託開発など…お客様の状況に合わせてご提案いたします。相談は無料！なのでお気軽にお問い合わせください。