大規模再構築の体制作りに不安がある企業にとって、最初から大きな開発を決める必要はありません。まずは現行業務・帳票・データ・連携・保守状況を整理し、延命、部分改善、パッケージ活用、周辺開発、スクラッチ再構築のどれが現実的かを見極めることが重要です。
マクティズムでは、作り直しありきではなく、発注側の体制不足が失敗要因になることを重視して進め方を整理します。
この記事では、1億円規模の基幹システム再構築を成功させるために、発注側がどのような体制を組むべきかを整理します。この規模の投資判断を担う経営層と、プロジェクトを背負うことになる責任者・推進メンバーに向けた内容です。
この記事で分かること
- 基幹システム見直しで確認すべきポイント
- 延命・部分改善で済むケース
- パッケージ活用や周辺開発を検討すべきケース
- スクラッチ再構築を検討すべきケース
- 相談前に準備しておく情報
まず結論｜すぐに作り直す前に現状を整理する
基幹システムは、受注・出荷・在庫・請求・生産・会計連携など、複数の業務にまたがります。そのため、表面上の不具合だけを見て判断すると、後から帳票、データ移行、外部連携、現場運用で想定外の問題が出ることがあります。
まず必要なのは、現行システムの全体像を把握することです。特に、どの業務が止まると困るのか、どの帳票が実際に使われているのか、どのExcel・Access・CSV運用が周辺に残っているのかを確認するだけでも、再構築の方向性はかなり明確になります。
1億円規模の失敗要因は、技術ではなく発注側の体制にある
大規模再構築の失敗事例を分析すると、原因の多くは技術ではなく、発注側の意思決定の遅れ、部門間の対立の放置、要件を確定できる人の不在といった体制の問題に行き着きます。開発会社は業務の答えを持っていません。自社の業務をどうしたいかを決められる体制がなければ、どれほど優れた開発力も空回りします。1億円の投資の最初の使い道は、システムではなく、この体制づくりです。
経営直轄のプロジェクトとして設計する
この規模の再構築は、全部門の業務に影響し、部門間の利害調整が必ず発生します。情報システム部門だけに背負わせると、他部門への調整力が足りずに要件が漂流します。経営トップまたは役員をプロジェクトオーナーに置き、月次で進捗と課題を経営会議に上げ、部門間の対立はオーナーが裁く。この経営直轄の構図を最初に宣言することが、現場の協力を引き出し、判断の速度を保つ土台になります。
このテーマでよく起きる問題
このテーマでよく起きる問題は、技術的な問題に見えて、実際には業務整理の不足から起きていることが多いです。たとえば、同じ機能でも部署ごとに運用が違う、帳票は同じ名称でも用途が違う、CSVの出力タイミングが担当者依存になっている、といったケースです。
この状態でパッケージを入れたり、スクラッチで作り直したりすると、開発途中で追加要件が増え、費用と期間が膨らみやすくなります。
よくある失敗は、優秀な担当者を専任に任命したものの、その人の元の業務が減らされず、実質的に二足のわらじになるケースです。大規模プロジェクトの発注側作業は、要件確認、データ整備、テスト、教育準備と膨大で、片手間では必ず破綻します。専任化とは辞令ではなく、業務の引き継ぎまで完了して初めて成立します。
また、現場のキーパーソンをプロジェクトに入れず、管理職だけで要件を決めてしまう失敗も定番です。例外処理や暗黙のルールは現場にしかなく、稼働後に「実際の業務と違う」と発覚してからの修正は高くつきます。各部門から業務を語れる実務者を巻き込み、その負荷を部門の業績評価でも認める仕組みが必要です。
さらに、数年に及ぶ期間中の異動・退職への備えも欠かせません。特定の個人の記憶に依存した推進は、その人の離脱で計画ごと漂流します。決定事項と経緯を記録し、複数人で共有する運営を最初から徹底してください。
自社で確認できるチェックポイント
体制を設計する前に、次の点を確認しておくと、必要な布陣が具体的になります。
- 現在のシステムで実際に困っている業務を1つずつ書き出す
- 画面・帳票・CSV・バッチ・Excel補完作業を棚卸しする
- 利用部署、利用人数、締め処理、止められない業務を確認する
- サーバー、データベース、外部連携、バックアップの状態を確認する
- 現行システムを残す部分、直す部分、作り直す部分を分ける
- パッケージで足りる業務と、周辺開発が必要な業務を分ける
- 初期費用だけでなく、保守・追加改修・移行リスクも比較する
大規模体制ならではの棚卸しポイント
基本のチェックリストに加えて、プロジェクトオーナーを担える役員の存在、専任化できる推進担当の候補と業務引き継ぎの可否、各部門のキーパーソンの名前、意思決定の三層（実務・調整・経営）の設計、そして数年間この体制を維持できるかの見通しを確認してください。外部の力を借りる場合も、丸投げ先ではなく、自社体制の不足を補う位置づけ（PMO支援、要件定義支援など）を明確にすることが、主導権を保つ条件です。
体制には、品質とリスクを冷静に見る役割も組み込んでください。進捗会議は「順調です」の報告に流れがちですが、遅れの兆候や課題の滞留を数字で示す係がいるだけで、問題の発見は数か月早まります。耳の痛い報告が歓迎される文化を、オーナー自身が率先して作ることが肝心です。
推進メンバーの選定では、「業務に詳しい人」と同じくらい「部門を越えて信頼されている人」を重視してください。大規模再構築は利害調整の連続であり、あの人が言うなら協力しようと思われる人物がプロジェクトの中心にいるかどうかで、要件の合意の速さがまるで違ってきます。
延命・部分改善で対応できるケース
なお、1億円規模の投資を一括で背負う前に、リスクを下げる構え方も検討に値します。
- 対象業務が限定されている
- 帳票やCSV連携の一部改善で足りる
- データベース改善やバックアップ自動化で安定運用できる
- 利用者が限られており、現場への影響が小さい
- 将来の全面刷新までの橋渡しとして改善したい
全体を一括契約するのではなく、現行調査・要件定義までを第一段階として契約し、その成果物で開発規模と体制の実力を確かめてから本開発へ進む二段階契約は、この規模の定石です。また、業務単位の段階リリースを組み合わせれば、一度に抱えるリスクと現場負荷を分散できます。
投資の分割は、開発会社を見極める機会にもなります。第一段階の仕事ぶりで、数年を託せる相手かどうかを判断できるからです。
期間の目安は2〜3年、体制の規模は発注側だけでも専任・準専任をあわせて数名以上が一般的です。この人件費もプロジェクトコストの一部として最初から予算化しておくと、途中で「人が出せない」という事態を防げます。
パッケージ活用・周辺開発・スクラッチ再構築を検討すべきケース
体制の力点は、構築方式によって次のように変わります。
- 保守期限が近く、現行環境を長く使えない
- 開発会社がなく、改修や障害対応が難しい
- Access・Excel・古いDBではデータ量や運用に限界がある
- パッケージ標準機能が業務に合わない
- 周辺システムや帳票が増え、全体像が分からない
- 今後も機能追加や外部連携が増える見込みがある
パッケージ活用が向くケース
大規模パッケージ導入では、業務を標準に合わせる変革の推進力が問われます。体制には、システムに詳しい人より、業務の変更を各部門に浸透させられる人を厚く配置してください。
周辺開発で補うケース
段階的な周辺開発の積み上げで刷新する場合は、数年にわたる全体設計を守り続ける司令塔が要になります。各段階の担当が変わっても方針がぶれない、設計思想の番人を置いてください。
スクラッチ再構築が向くケース
スクラッチの大規模再構築では、要件を確定させる力がすべての土台です。業務を横断して仕様を裁ける実務リーダーを各領域に置けるかが、体制設計の中心課題になります。
マクティズムの見解
マクティズムの見解として、1億円規模の基幹システム再構築で失敗しない体制づくりでは「何を作るか」より先に「何を残すか、何を直すか、何を作り直すか」を決めることが重要です。
特に、発注側の体制不足が失敗要因になることを意識しないまま進めると、パッケージを入れても周辺Excelが残ったり、スクラッチで作っても現場が使いにくかったりします。相談段階では、資料が完全にそろっていなくても問題ありません。画面、帳票、運用メモ、担当者の記憶を集めるところから始めるべきです。
1億円規模のご相談で私たちがまず見るのは、システムの要件ではなく、お客様側の推進力です。足りない部分があれば、それを補う支援や、体制が整うまで開発を始めない判断も含めて率直にお伝えします。この規模の失敗は会社の数年を奪います。だからこそ、受注のために体制の弱さから目をそらすことはしない、と決めています。
相談前に準備しておく情報
この規模の相談では、経営として解決したい課題、想定している期間と予算の幅、社内で確保できそうな体制、過去の大型プロジェクトの経験の有無が分かると、初回から体制設計と進め方の骨格を一緒に描けます。体制に不安がある状態のご相談こそ、価値があります。
実務では、契約前に現行調査と体制診断を行い、範囲・段階・体制を経営が承認できる計画書に仕上げてから、二段階契約で本開発へ進む形をおすすめしています。大きな投資ほど、始め方の丁寧さが結果を分けます。
そして、長い道のりを共に歩む以上、良い時も悪い時も事実を共有し合える関係を最初に築くことを、何よりも大切にしています。体制とは組織図のことではなく、この信頼の設計のことだと思うのです。
強い体制で完走した再構築は、システムとともに、変革をやり遂げた人材と部門を越えた協力の経験を会社に残します。1億円の投資の本当のリターンは、案外そちらのほうが大きいのかもしれません。
体制づくりは、オーナーの確定、専任の確保、キーパーソンの巻き込み、意思決定の三層設計、記録と共有の運営ルール、の順で進めてください。この五つがそろえば、開発を始める準備は整っています。
また、プロジェクトの節目ごとに、現場への説明会や進捗の社内発信を計画に組み込んでください。数年に及ぶ取り組みでは、直接関わらない社員にとってプロジェクトは見えない存在になり、切替直前に突然の変化として受け止められます。継続的な発信は、稼働時の受け入れ土壌を耕す、体制づくりの一部です。
外部パートナーの複数活用（開発会社とは別に助言役を置くなど）も、この規模では選択肢になります。ただし役割の重複は混乱の元になるため、誰が何に責任を持つかの整理を先に行ってください。
体制は一度作って終わりではなく、フェーズの移り変わりに合わせて増強と交代を計画するものです。要件定義期は業務の実務者を厚く、テスト期は検証の人手を厚く。山場に合わせた人の配置換えまで描けていれば、体制設計は合格点です。
最後に、体制づくりに完璧はありません。走りながら弱点に気づき、補強していく柔軟さも含めて体制です。大切なのは、弱点を認めて手を打てる率直さを、プロジェクトの文化として最初に根づかせることです。
強い体制とは、間違いを早く見つけて直せる体制のことです。その柔らかさを備えた組織にとって、1億円の再構築は乗り越えられる挑戦になります。
準備に費やした時間は、必ず完走の力に変わります。焦らず、しかし止まらずに、体制という土台から積み上げていきましょう。
よくある質問
要件がまとまっていなくても相談できますか？
はい。分かる範囲の業務内容、現在困っていること、使っている画面や帳票から整理できます。完璧な資料よりも、現状の困りごとを早めに共有することが大切です。経営課題と体制の現状からで構いません。要件の整理はその後で十分間に合います。
すぐに全面再構築する必要がありますか？
いいえ。延命・部分改善で足りる場合もあります。まずは残す部分、直す部分、作り直す部分を切り分けます。はい。診断の結果、第一期を絞った段階計画に組み替えることは、この規模ではむしろ標準的です。
パッケージとスクラッチのどちらがよいか判断できますか？
はい。業務が標準機能に合うか、帳票や例外処理をどう扱うか、将来の保守性まで含めて比較します。方式の選択は体制の強みとも関わるため、体制設計とあわせて一緒に判断します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。データベース改善、帳票・連携、バックアップ自動化など、段階的な改善から始められる場合があります。はい。現行調査や要件定義支援を第一段階として切り出す二段階の進め方に対応しています。
相談後にしつこい営業はありますか？
ありません。現状を確認したうえで、必要な進め方を整理します。無理に大きな開発を勧めることはありません。体制の不安を含めて率直にお聞かせください。そこからが本当の計画づくりです。
