この記事で分かること
- 本体カスタマイズは将来保守にも影響する
- 帳票やCSVは周辺開発で補える場合がある
- 業務を標準化すべき範囲を見極める
- カスタマイズ見積の内訳を見る
- 責任範囲を整理する
- スクラッチとの比較も必要
- 安い方法ではなく無理のない方法を選ぶ
まず結論
結論として、パッケージのカスタマイズ費用が高いときに最初に見るべきなのは、システムの古さそのものではなく、業務への影響、保守できる体制、データ量、帳票・連携の複雑さ、今後の変更予定です。まだ動いているから大丈夫と考えがちですが、保守期限や担当者退職、パッケージ不適合が見えている場合は、検討開始が遅れるほど選択肢が狭くなります。
また、見積金額だけで高い・安いを判断するのではなく、その改修が本当に必要か、標準機能や業務変更で代替できないか、本体を変更せず周辺システムで補えないかを整理する必要があります。現行業務をすべてそのまま再現しようとすると、不要なカスタマイズまで増え、将来のバージョンアップや保守にも影響します。
まずは現状を棚卸しし、残す機能、変更する機能、廃止できる機能、周辺開発で補う機能を切り分けます。そのうえで、初期費用だけでなく、保守費用、ライセンス費用、追加改修費用、インフラ費用、現場の運用負担まで含めた総コストで比較することが重要です。
よくある背景・失敗しやすい理由
このテーマで相談が増える背景には、古い基幹システムのブラックボックス化があります。設計書が一部しか残っていない、帳票の意味を説明できる人がいない、サーバーやデータベースの保守期限が近い、パッケージを検討したが標準機能では現場業務が回らない、といった状況です。
現場では業務を止めないためにExcelやAccess、CSV加工で補うことが多く、その場しのぎの対応が積み重なるほど、再構築時の調査範囲とリスクが大きくなります。特定の担当者だけが処理方法を知っている場合、退職や異動によって業務が止まるおそれもあります。
また、見積書の総額だけを見て高いと判断することも失敗につながります。費用には要件定義、設計、開発、テスト、データ移行、教育、マニュアル、プロジェクト管理などが含まれることがあります。対象範囲や前提条件を確認せず、単純に他社と比較すると、後から追加費用が発生する可能性があります。
確認すべきポイント
1. 本体カスタマイズは将来保守にも影響する
本体カスタマイズは、現在の課題を解決できても、将来のバージョンアップや保守に影響します。標準プログラムを直接変更すると、新しいバージョンへ更新する際に、同じ改修を再度反映しなければならない場合があります。
受注画面への項目追加のような小さな変更でも、データベース、検索、帳票、CSV、外部連携など複数箇所へ影響することがあります。現状の使われ方、関係部署、停止できない処理、利用頻度を確認し、費用に見合うかを判断してください。
マクティズムでは、延命で足りる部分と再構築が必要な部分を分けて整理します。本体変更が将来の更新を妨げる場合は、外部サービスや周辺システムで対応した方が、長期的な費用を抑えられることがあります。
2. 帳票やCSVは周辺開発で補える場合がある
不足している機能のすべてをパッケージ本体へ組み込む必要はありません。請求書、納品書、送り状、一覧表、管理資料などは、必要なデータを取得し、帳票専用ツールや外部プログラムで作成できる場合があります。
CSV加工も、ETL、RPA、マクロ、連携用の小規模プログラムで対応できることがあります。本体を直接変更しなければ、バージョンアップ時の影響を抑えやすく、帳票レイアウトの変更にも柔軟に対応できます。
ただし、個人が作成したExcelマクロへ依存すると、担当者の退職後に保守できなくなるおそれがあります。周辺開発でも、仕様書、ソースコード、運用手順を残し、組織として管理できる状態にしておくことが重要です。
3. 業務を標準化すべき範囲を見極める
現行業務をすべて再現しようとすると、カスタマイズ項目は増え続けます。「昔からこの方法で処理している」という理由だけで残る承認、二重入力、重複帳票、手作業の転記は、導入を機に見直すべきです。
一方で、企業独自の受注方法、価格決定、在庫管理、製造工程などが競争力につながる場合、無理に標準機能へ合わせると、顧客対応力や業務効率が低下する可能性があります。
標準化の判断では、「法令や取引条件上必要な業務」「顧客価値や競争力につながる業務」「単なる社内慣行」に分けると整理しやすくなります。標準化によって誰の作業が増減するかも確認し、特定部署に負担が集中しないようにします。
4. カスタマイズ見積の内訳を見る
見積金額の総額だけでは、適切な比較はできません。要件定義、基本設計、詳細設計、開発、単体・結合テスト、データ移行、教育、マニュアル、プロジェクト管理などに分けて確認します。
「一式」と記載されている場合は、対象機能、前提条件、含まれる作業、対象外作業を明確にしてください。また、必ず必要な機能、導入後に追加できる機能、なくても運用できる機能に分けると、初期費用を抑えやすくなります。
単に値引きを求めるより、標準機能への置換、複数要望の統合、実装方式の変更によって費用を下げる方が、品質を維持しやすくなります。相見積を取る場合も、各社へ同じ条件を提示することが重要です。
5. 責任範囲を整理する
パッケージ本体、周辺システム、外部サービス、ネットワーク、サーバーを複数会社が担当する場合、それぞれの責任範囲を明確にする必要があります。
データ連携の障害は、送信元、連携プログラム、ネットワーク、受信先のどこでも発生します。誰が一次調査を行い、どこまで対応し、どの条件で追加費用が生じるかが曖昧だと、復旧が遅れます。
契約前に、問い合わせ窓口、対応時間、保守対象、障害時の切り分け方法を確認し、システム構成図と責任分界点を残しておきます。担当者が変わっても判断できる資料を整備することが重要です。
6. スクラッチとの比較も必要
カスタマイズ費用が積み上がり、スクラッチ開発と同程度になる場合は、パッケージ導入だけを前提にせず比較する必要があります。
複雑な価格計算、特殊な在庫引当、独自の製造工程、取引先別の受発注などが多い企業では、スクラッチの方が長期的に使いやすい可能性があります。ただし、要件整理、開発期間、品質管理、保守会社への依存という課題もあります。
比較時は、初期費用だけでなく、ライセンス、年間保守、バージョンアップ、追加改修、インフラ、運用負荷を含めます。パッケージとスクラッチの二者択一ではなく、標準機能を中心に使い、独自部分だけを周辺開発する方法も検討できます。
7. 安い方法ではなく無理のない方法を選ぶ
初期費用だけを重視すると、導入後に追加改修や手作業が増え、結果として総コストが高くなることがあります。高機能なシステムでも、現場が使いこなせなければ、Excelや二重管理が再発します。
担当者が交代しても運用できるか、操作方法や仕様が文書化されているか、問い合わせ先が明確かを確認してください。特定の担当者や開発会社でなければ修正できない状態は避ける必要があります。
法改正、組織変更、新規事業、外部連携などに対応しやすく、追加改修費用を予測できる構成を選ぶことが重要です。自社の体制で継続して運用できることが、長期的な費用削減につながります。
自社で整理できること・外部に相談すべきこと
社内で整理できるのは、業務範囲、利用画面、帳票、困っている作業、保守期限、利用部署・人数、関連するExcel・Access・CSVです。さらに、外部連携、マスタ、承認フロー、繁忙期の処理、障害時の影響も確認しておくと、検討の精度が上がります。
現場へのヒアリングでは、必要な機能だけでなく、「何のために使っているのか」「なくなると何が困るのか」を確認します。目的が分かれば、別の標準機能や運用変更で代替できることがあります。
影響範囲が複数部門にまたがる場合、データ移行や外部連携がある場合、複数パッケージを比較する場合は、外部の開発会社と現状整理した方が安全です。ただし、最終的な判断基準は自社で持つ必要があります。
判断表
| 状態 | まず検討すること | 注意点 |
|---|---|---|
| 軽微な不具合・一部帳票の変更 | 延命・保守・部分改修 | 本体再構築の前に影響範囲を確認 |
| データ量増加・動作遅延・バックアップ不安 | DB改善・性能改善 | 根本的な業務課題が残らないか確認 |
| パッケージ標準で業務が合う | パッケージ導入 | 帳票・例外処理・データ連携を事前確認 |
| パッケージで足りない機能が明確 | パッケージ＋周辺開発 | 責任範囲と連携仕様を明確にする |
| 独自業務・例外処理が多い | スクラッチ再構築 | 要件整理と段階導入が重要 |
| 判断が難しい | 開発前診断・刷新ロードマップ | 社内稟議や他社比較に使える資料化を行う |
判断表は一般的な目安です。実際には、業種、利用人数、拠点数、データ量、外部連携、セキュリティ要件によって適切な方法は変わります。複数案の費用、期間、リスク、保守性を比較してください。
相談前に準備しておく情報
相談前にすべての資料を揃える必要はありません。ただし、次の情報が分かると、初回相談や見積の精度が上がります。
- 現行システムの概要
- 利用部署と人数
- 画面・帳票・CSVの一覧
- データの種類と件数
- 外部システムとの連携
- サーバーやパッケージの保守期限
- 現在困っている業務
- 検討中のパッケージや提示済み見積
- 想定予算と導入時期
- 今後予定している事業・組織変更
帳票サンプル、CSV、画面キャプチャ、業務フロー図があれば、影響範囲を把握しやすくなります。現場、管理部門、情報システム部門、経営層の要望も整理し、導入目的と優先順位を共有してください。
マクティズムの見解
マクティズムでは、カスタマイズ費用が高いという理由だけで、すぐにスクラッチへ切り替えたり、業務を無理にパッケージへ合わせたりするべきではないと考えています。
重要なのは、費用が高い理由を確認し、本当に必要な改修と、標準機能や業務変更で代替できる改修を分けることです。本体カスタマイズと思われていた要望でも、帳票ツール、外部サービス、データ連携、周辺開発で解決できることがあります。
一方、独自業務が競争力の源泉であれば、無理な標準化は適切ではありません。必要に応じて、スクラッチやパッケージと個別開発を組み合わせた構成も検討します。
費用は、初期開発費だけでなく、保守性、拡張性、運用負荷、障害対応、将来の改修費用を含めて比較します。安く見える方法でも、追加改修や手作業が増えるなら、長期的な負担は大きくなります。
カスタマイズ費用が高いと感じたときは、単なる値下げ交渉ではなく、システムと業務を見直す機会と捉えることが重要です。残すもの、変えるもの、廃止するものを整理し、段階的に検討することが、費用対効果の高い刷新につながります。
よくある質問
パッケージで足りない帳票や連携だけ依頼できますか？
はい。パッケージ本体を活かしながら、帳票、CSV、データ連携、サブシステムを個別に開発する相談も可能です。
概算費用だけでも相談できますか？
はい。ただし、対象範囲、帳票数、データ移行、外部連携によって大きく変わるため、簡易棚卸しをおすすめします。
要件がまとまっていなくても相談できますか？
はい。現状の課題や分かる範囲の資料から、まず何を確認すべきか整理できます。無理に要件を固めてから相談する必要はありません。
仕様書や設計書が一部しかなくても相談できますか？
はい。画面、帳票、データ、業務フロー、操作手順などから現行調査を進められます。
いきなり大きな開発を依頼する必要がありますか？
いいえ。初回相談、簡易棚卸し、開発前診断・刷新ロードマップから段階的に進められます。
パッケージとスクラッチのどちらがよいか相談できますか？
はい。標準機能で合う範囲、周辺開発で補う範囲、スクラッチが必要な範囲を比較します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。DB改善、性能改善、帳票・データ連携、バックアップ自動化など部分改善から相談可能です。
相談後にしつこい営業はありますか？
ありません。まずは現状を整理し、必要な選択肢と進め方をご提案します。
