この記事では、パッケージを活かしつつ足りない部分を作りたい企業に向けて、判断すべきポイントを実務目線で整理します。マクティズムでは、いきなり作り直すのではなく、延命・部分改善・パッケージ活用・周辺開発・スクラッチ再構築のどれが現実的かを、現行業務と帳票・データから確認することが重要だと考えています。
この記事で分かること
- パッケージで足りる範囲
- サブシステムで補う範囲
- 帳票・CSV・連携
- 責任範囲
- 費用の見方
- 将来保守
- 導入後の運用
まず結論
結論として、パッケージ＋サブシステム開発という選択肢で最初に見るべきなのは、システムの古さそのものではなく、業務への影響、保守できる体制、データ量、帳票・連携の複雑さ、今後の変更予定です。まだ動いているから大丈夫と考えがちですが、保守期限や担当者退職、パッケージ不適合が見えている場合は、検討開始が遅れるほど選択肢が狭くなります。まずは現状を棚卸しし、作り直す範囲と残す範囲を切り分けることが必要です。
よくある背景・失敗しやすい理由
このテーマで相談が増える背景には、古い基幹システムのブラックボックス化があります。設計書が一部しか残っていない、帳票の意味を説明できる人がいない、サーバーやデータベースの保守期限が近い、パッケージを検討したが標準機能では現場業務が回らない、といった状況です。現場では業務を止めないためにExcelやAccess、CSV加工で補うことが多く、その場しのぎの対応が積み重なるほど、再構築時の調査範囲とリスクが大きくなります。
確認すべきポイント
1. パッケージで足りる範囲
まず、販売、在庫、会計などの基本業務について、パッケージの標準機能と設定だけで対応できる範囲を確認します。機能一覧の有無だけで判断せず、実際の伝票、マスタ、締め処理、承認フローを使った業務シナリオで検証することが重要です。
標準機能に業務を合わせられる部分まで個別開発すると、初期費用だけでなく、バージョンアップ時の再検証や保守負担も増えます。事業の強みや取引条件に直結しない処理は、可能な範囲で標準化する方針を検討してください。
2. サブシステムで補う範囲
サブシステムは、自社独自の見積計算、受注入力、生産指示、検品、帳票出力など、パッケージ標準では対応しにくい業務を補うために利用します。対象範囲を決める際は、その業務が競争力、顧客対応、処理効率に与える影響を確認します。
便利だからという理由だけで機能を追加すると、パッケージとサブシステムの境界が曖昧になり、二重入力やデータ不整合が起こりやすくなります。どちらが各データを登録・更新し、どこまでを正として管理するかを明確にする必要があります。
3. 帳票・CSV・連携
パッケージからサブシステムへデータを渡す方法には、API、CSV、データベース連携などがあります。利用できる方式、実行頻度、連携できる項目、製品側の制限を選定段階で確認し、更新の即時性が本当に必要かも検討します。
帳票については、レイアウトだけでなく、出力条件、計算ロジック、配布先、保管方法まで整理してください。連携失敗や重複取込を検知する仕組み、再実行の手順、文字コードや日付形式も事前に決めることで、導入後の手作業を減らせます。
4. 責任範囲
パッケージの提供会社とサブシステムの開発会社が異なる場合、障害の原因がどちらにあるか分からず、復旧が遅れることがあります。連携仕様の作成、接続試験、問い合わせの一次窓口を誰が担当するかを契約前に整理します。
パッケージ側の仕様変更やバージョンアップで連携が影響を受ける場合もあります。変更情報の共有方法、改修費用の負担、検証環境の提供、障害時のログ確認などを責任分界表にまとめておくと、ベンダー間の認識違いを防げます。
5. 費用の見方
費用を比較する際は、パッケージのライセンスや導入費用と、サブシステムの開発費だけを合計すればよいわけではありません。データ移行、連携基盤、テスト、教育、クラウド利用料、監視、問い合わせ対応なども含めて総額を確認します。
さらに、法改正や業務変更への対応、パッケージ更新に伴う連携改修など、導入後の費用も見込む必要があります。一括開発と段階導入の双方で複数年の総保有コストを比較すると、初期見積もりだけでは見えない差を判断しやすくなります。
6. 将来保守
サブシステムを長く利用するには、設計書、データ項目、API・CSV仕様、変更履歴を維持する必要があります。特定の担当者だけが連携の仕組みを理解している状態にすると、数年後に再びブラックボックス化する可能性があります。
採用する技術の保守期限や開発会社の支援体制も確認してください。パッケージのバージョンアップ方針に合わせて、連携試験をいつ行い、問題が見つかった場合に誰が改修するかまで運用計画へ含めることが重要です。
7. 導入後の運用
導入後は、利用者が複数のシステムを行き来するため、ログイン方法、権限申請、マスタ変更、問い合わせ先を統一的に整理する必要があります。障害時にどちらのシステムまで利用できるか、業務を継続する代替手順も準備します。
連携件数やエラー件数を定期的に確認し、手作業による補正が増えていないかを把握してください。稼働後の課題を記録して改善の優先順位を決めることで、サブシステムが場当たり的な追加開発の集まりになることを防げます。
自社で整理できること・外部に相談すべきこと
社内でまず整理できるのは、業務範囲、画面、帳票、困っている作業、保守期限、利用部署、関連するExcel・Access・CSVです。一方で、影響範囲が複数部門にまたがる、データ移行や外部連携が絡む、パッケージ比較が必要な場合は、外部の開発会社と一緒に現状整理した方が安全です。
社内では、パッケージへ合わせられる業務と、独自性を残す必要がある業務を一覧化し、それぞれの理由と利用部署を記載します。現行の帳票、CSV、外部サービス、データ件数も分かる範囲で整理すると、サブシステムの対象範囲を検討しやすくなります。
複数ベンダーが関わる構成やリアルタイム連携が必要な場合は、技術的な実現性だけでなく、障害対応や将来更新まで含めて外部へ相談してください。構成案ごとの費用、リスク、責任分界を比較できる資料があると、社内合意にも活用できます。
判断表
| 状態 | まず検討すること | 注意点 |
|---|---|---|
| 軽微な不具合・一部帳票の変更 | 延命・保守・部分改修 | 本体再構築の前に影響範囲を確認 |
| データ量増加・動作遅延・バックアップ不安 | DB改善・性能改善 | 根本的な業務課題が残らないか確認 |
| パッケージ標準で業務が合う | パッケージ導入 | 帳票・例外処理・データ連携を事前確認 |
| パッケージで足りない機能が明確 | パッケージ＋周辺開発 | 責任範囲と連携仕様を明確にする |
| 独自業務・例外処理が多い | スクラッチ再構築 | 要件整理と段階導入が重要 |
| 判断が難しい | 開発前診断・刷新ロードマップ | 社内稟議や他社比較に使える資料化を行う |
相談前に準備しておく情報
相談前にすべての資料を揃える必要はありません。ただし、現行システム概要／利用部署・人数／画面一覧／帳票一覧／データ項目／外部連携／保守期限／困っている業務／パッケージ検討状況／想定予算・時期 などが分かると、初回相談の精度が上がります。
マクティズムの見解
マクティズムでは、パッケージが業務に完全には合わないからといって、すぐに大規模なカスタマイズやスクラッチ開発を選ぶ必要はないと考えています。会計、販売、在庫などの標準化しやすい領域はパッケージを活用し、独自性が必要な領域だけをサブシステムで補う構成は有力な選択肢です。
ただし、パッケージとサブシステムを組み合わせれば必ず費用を抑えられるわけではありません。連携箇所が多く、双方で同じデータを更新する構成にすると、テストや障害調査、将来の改修が複雑になります。まず業務とデータの流れを整理し、システムの境界を明確にする必要があります。
特に重要なのは、各データの管理主体を決めることです。顧客、商品、在庫、受注、請求などについて、どのシステムを正とし、いつ、どの方向へ連携するかを定義します。エラー時の再送や重複防止まで設計することで、日常運用での手作業を抑えられます。
また、機能要件だけでなく、パッケージの更新方針、APIの提供条件、ライセンス制約、保守期限も確認します。現在は連携できても、製品の仕様変更でサブシステムが動かなくなる可能性があるため、変更情報の受け取り方と事前検証の体制が欠かせません。
判断時には、パッケージ単体、パッケージ＋サブシステム、本体カスタマイズ、スクラッチ再構築を同じ評価軸で比較します。初期費用だけでなく、業務への適合度、導入期間、運用負担、将来保守、ベンダー間調整のリスクを並べることで、自社に適した構成が見えやすくなります。
マクティズムは、現行業務、帳票、データ、例外処理を確認したうえで、パッケージに任せる範囲と個別開発する範囲を決めることが重要だと考えています。必要に応じて段階導入を行い、効果と連携の安定性を確認しながら対象を広げることで、大規模な一括切り替えのリスクを抑えられます。
よくある質問
パッケージで足りない帳票や連携だけ依頼できますか？
はい。パッケージ本体を活かしながら、帳票、CSV、データ連携、サブシステムを個別に開発する相談も可能です。
要件がまとまっていなくても相談できますか？
はい。現状の課題や分かる範囲の資料から、まず何を確認すべきか整理できます。無理に要件を固めてから相談する必要はありません。
仕様書や設計書が一部しかなくても相談できますか？
はい。画面、帳票、データ、業務フロー、操作手順などから現行調査を進められます。
いきなり大きな開発を依頼する必要がありますか？
いいえ。初回相談、簡易棚卸し、開発前診断・刷新ロードマップから段階的に進められます。
パッケージとスクラッチのどちらがよいか相談できますか？
はい。標準機能で合う範囲、周辺開発で補う範囲、スクラッチが必要な範囲を比較します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。DB改善、性能改善、帳票・データ連携、バックアップ自動化など部分改善から相談可能です。
相談後にしつこい営業はありますか？
ありません。まずは現状を整理し、必要な選択肢と進め方をご提案します。
