この記事では、パッケージ検討中だが業務に合わず困っている企業に向けて、判断すべきポイントを実務目線で整理します。マクティズムでは、いきなり作り直すのではなく、延命・部分改善・パッケージ活用・周辺開発・スクラッチ再構築のどれが現実的かを、現行業務と帳票・データから確認することが重要だと考えています。
この記事で分かること
- 標準機能で回らない帳票がある
- 例外処理が多い
- 現場の操作性が変わりすぎる
- カスタマイズ範囲が膨らむ
- 周辺システムで補える場合がある
- スクラッチ再構築が現実的な場合もある
- Fit&Gapを早めに行う
まず結論
結論として、パッケージが業務に合わないときの選択肢で最初に見るべきなのは、システムの古さそのものではなく、業務への影響、保守できる体制、データ量、帳票・連携の複雑さ、今後の変更予定です。まだ動いているから大丈夫と考えがちですが、保守期限や担当者退職、パッケージ不適合が見えている場合は、検討開始が遅れるほど選択肢が狭くなります。まずは現状を棚卸しし、作り直す範囲と残す範囲を切り分けることが必要です。
よくある背景・失敗しやすい理由
このテーマで相談が増える背景には、古い基幹システムのブラックボックス化があります。設計書が一部しか残っていない、帳票の意味を説明できる人がいない、サーバーやデータベースの保守期限が近い、パッケージを検討したが標準機能では現場業務が回らない、といった状況です。現場では業務を止めないためにExcelやAccess、CSV加工で補うことが多く、その場しのぎの対応が積み重なるほど、再構築時の調査範囲とリスクが大きくなります。
確認すべきポイント
1. 標準機能で回らない帳票がある
帳票は単なる印刷物ではなく、取引先ごとの指定様式、現場の検品、出荷指示、請求照合など、後続業務の起点になっていることがあります。そのため、パッケージの標準帳票に必要な項目がない場合は、レイアウト変更だけで解決できるのか、データ項目の追加や計算処理まで必要なのかを切り分けなければなりません。
まずは帳票ごとに、誰が、いつ、何の判断に使っているかを確認します。利用目的が重複している帳票は統合し、取引条件などの理由で残す必要がある帳票は、外部帳票ツールや周辺システムから出力する方法も比較すると、パッケージ本体の改修を抑えやすくなります。
2. 例外処理が多い
得意先別の締め処理、特注品の引当、返品時の在庫評価、分納や遡及単価の処理など、例外業務が多い会社では標準フローだけで運用できないことがあります。ただし、すべての例外をそのまま新システムへ移すと、カスタマイズ費用が増えるだけでなく、将来の更新も難しくなります。
例外処理は、発生頻度、処理時間、誤りが生じた場合の影響、法令・契約上の必要性で分類してください。低頻度で影響が小さいものは運用で補い、高頻度または事業上重要なものだけをシステム化することで、投資範囲を合理的に決められます。
3. 現場の操作性が変わりすぎる
機能要件を満たしていても、入力順序、検索方法、一覧性、キーボード操作などが現行システムと大きく異なると、処理時間や入力ミスが増える可能性があります。特に、短時間に多くの伝票を処理する部門では、クリック数が少し増えるだけでも月間の業務負担に大きな差が出ます。
製品デモでは代表的なシナリオだけを見るのではなく、実際の担当者に普段の伝票や例外ケースを操作してもらうことが重要です。教育で吸収できる変化と、業務効率を恒常的に下げる問題を分け、必要に応じて入力支援画面などの周辺開発を検討します。
4. カスタマイズ範囲が膨らむ
選定初期には小規模な調整で済むと考えていても、要件を詳しく確認すると、マスタ項目、承認フロー、帳票、外部連携などへ改修が連鎖することがあります。初期費用だけでなく、バージョンアップ時の再検証、追加ライセンス、保守費用まで含めなければ、導入後の総コストを正しく比較できません。
カスタマイズ項目は「競争力に直結する」「法令・契約上必要」「既存慣行を残したい」のように理由を付けて優先順位を決めます。必須改修が標準機能と同程度まで広がる場合は、パッケージに固執せず、周辺開発やスクラッチ再構築も同じ条件で比較すべきです。
5. 周辺システムで補える場合がある
会計、在庫、販売などの中核機能はパッケージを利用し、自社固有の見積計算、製造指示、帳票作成、データ照合だけを周辺システムとして構築する方法があります。標準機能の更新性を維持しながら独自業務を残せるため、本体を大幅に改修するより現実的な場合があります。
一方で、データの二重入力や連携エラーを防ぐ設計が欠かせません。どのシステムを正とするか、データをいつ同期するか、エラー発生時に誰が復旧するかまで決め、APIやCSV連携の仕様と責任分界点を明確にしてください。
6. スクラッチ再構築が現実的な場合もある
独自の受注方式や生産管理が事業の強みになっており、複数のパッケージを比較しても重要業務の多くが適合しない場合は、スクラッチ再構築が候補になります。パッケージに大量の改修を加えるより、必要な範囲を設計し直した方が、運用と保守の見通しを立てやすいこともあります。
ただし、現行機能をすべて再現する前提では費用と期間が膨らみます。業務を見直したうえで、受発注、在庫、請求などを段階的に切り替え、移行期間中のデータ連携や二重運用まで含めたロードマップを作ることが重要です。
7. Fit&Gapを早めに行う
Fit&Gapは、機能一覧に丸や三角を付けるだけでは十分ではありません。実際の業務シナリオ、使用するデータ、帳票の出力結果まで確認し、標準機能で対応できる範囲と、設定、運用変更、追加開発が必要な範囲を具体化します。
候補製品を絞り込んだ段階で、現場担当者、情報システム部門、経営側が同じ判断基準を共有してください。契約後に重大なGapが判明すると撤退しにくいため、概算費用だけでなく、対応方法と残存リスクを契約前に確認することが大切です。
自社で整理できること・外部に相談すべきこと
社内でまず整理できるのは、業務範囲、画面、帳票、困っている作業、保守期限、利用部署、関連するExcel・Access・CSVです。一方で、影響範囲が複数部門にまたがる、データ移行や外部連携が絡む、パッケージ比較が必要な場合は、外部の開発会社と一緒に現状整理した方が安全です。
判断表
| 状態 | まず検討すること | 注意点 |
|---|---|---|
| 軽微な不具合・一部帳票の変更 | 延命・保守・部分改修 | 本体再構築の前に影響範囲を確認 |
| データ量増加・動作遅延・バックアップ不安 | DB改善・性能改善 | 根本的な業務課題が残らないか確認 |
| パッケージ標準で業務が合う | パッケージ導入 | 帳票・例外処理・データ連携を事前確認 |
| パッケージで足りない機能が明確 | パッケージ＋周辺開発 | 責任範囲と連携仕様を明確にする |
| 独自業務・例外処理が多い | スクラッチ再構築 | 要件整理と段階導入が重要 |
| 判断が難しい | 開発前診断・刷新ロードマップ | 社内稟議や他社比較に使える資料化を行う |
相談前に準備しておく情報
相談前にすべての資料を揃える必要はありません。ただし、現行システム概要／利用部署・人数／画面一覧／帳票一覧／データ項目／外部連携／保守期限／困っている業務／パッケージ検討状況／想定予算・時期 などが分かると、初回相談の精度が上がります。
マクティズムの見解
マクティズムでは、パッケージが業務に合わないという理由だけで、すぐにスクラッチ再構築へ進むべきではないと考えています。最初に確認すべきなのは、合わない業務が会社の競争力や取引条件に直結しているのか、それとも長年の運用が慣習として残っているだけなのかという点です。業務を標準機能に合わせられる部分まで個別開発すると、初期費用だけでなく、保守や将来の変更にかかる負担も増えます。
一方で、受注方式、価格計算、生産指示、在庫引当などが事業の強みであり、標準化によってサービス品質や処理能力が下がるのであれば、無理にパッケージへ合わせることも適切ではありません。その場合は、中核部分をスクラッチで構築する、またはパッケージを基盤として独自業務だけを周辺システムで補う構成を検討します。
判断する際は、現行の画面や機能一覧だけでなく、実際に使われている帳票、Excel、CSV、データ、例外処理を確認することが重要です。ヒアリングだけでは把握できない属人運用や手作業が見つかることもあるため、業務とシステムの両面から現状を整理し、残すもの、標準化するもの、廃止するものを分けます。
また、刷新方法は一つに決め打ちせず、延命・部分改善、パッケージ導入、パッケージと周辺開発の併用、スクラッチ再構築を同じ評価軸で比較します。費用、導入期間、業務への適合度、移行リスク、保守性を並べることで、経営判断や社内稟議に必要な根拠を示しやすくなります。
大規模な基幹システムほど、一括切り替えが最善とは限りません。止められない業務やデータ連携を見極め、効果が出やすい領域から段階的に導入することで、現場の負担と切り替えリスクを抑えられます。マクティズムは、特定の方式を前提にするのではなく、現状調査とFit&Gapを通じて、自社にとって無理のない刷新範囲と順序を定めることが重要だと考えています。
よくある質問
パッケージで足りない帳票や連携だけ依頼できますか？
はい。パッケージ本体を活かしながら、帳票、CSV、データ連携、サブシステムを個別に開発する相談も可能です。
要件がまとまっていなくても相談できますか？
はい。現状の課題や分かる範囲の資料から、まず何を確認すべきか整理できます。無理に要件を固めてから相談する必要はありません。
仕様書や設計書が一部しかなくても相談できますか？
はい。画面、帳票、データ、業務フロー、操作手順などから現行調査を進められます。
いきなり大きな開発を依頼する必要がありますか？
いいえ。初回相談、簡易棚卸し、開発前診断・刷新ロードマップから段階的に進められます。
パッケージとスクラッチのどちらがよいか相談できますか？
はい。標準機能で合う範囲、周辺開発で補う範囲、スクラッチが必要な範囲を比較します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。DB改善、性能改善、帳票・データ連携、バックアップ自動化など部分改善から相談可能です。
相談後にしつこい営業はありますか？
ありません。まずは現状を整理し、必要な選択肢と進め方をご提案します。
