5,000万円規模の開発を検討する経営者・情シスにとって、最初から大きな開発を決める必要はありません。まずは現行業務・帳票・データ・連携・保守状況を整理し、延命、部分改善、パッケージ活用、周辺開発、スクラッチ再構築のどれが現実的かを見極めることが重要です。
マクティズムでは、作り直しありきではなく、最初に決めるべきは機能一覧ではなく、対象範囲と優先順位であることを重視して進め方を整理します。
この記事では、5,000万円規模の基幹システム開発に踏み出す際、着手前に必ず決めておくべきことを整理します。この規模を任される担当者と、投資の最終判断を行う経営者が、同じ前提に立つための内容です。
この記事で分かること
- 基幹システム見直しで確認すべきポイント
- 延命・部分改善で済むケース
- パッケージ活用や周辺開発を検討すべきケース
- スクラッチ再構築を検討すべきケース
- 相談前に準備しておく情報
まず結論｜すぐに作り直す前に現状を整理する
基幹システムは、受注・出荷・在庫・請求・生産・会計連携など、複数の業務にまたがります。そのため、表面上の不具合だけを見て判断すると、後から帳票、データ移行、外部連携、現場運用で想定外の問題が出ることがあります。
まず必要なのは、現行システムの全体像を把握することです。特に、どの業務が止まると困るのか、どの帳票が実際に使われているのか、どのExcel・Access・CSV運用が周辺に残っているのかを確認するだけでも、再構築の方向性はかなり明確になります。
最初に決めるのは機能一覧ではなく「範囲と優先順位」
5,000万円規模の開発が迷走する典型は、欲しい機能のリストづくりから始めてしまうことです。機能要望は集めれば際限なく膨らみ、総花的な要件が予算と期間を圧迫します。最初に決めるべきは、対象業務の範囲（どこからどこまでを作り、どこは残すか）と、要望が衝突したときの優先順位の物差し(業務停止リスクの回避が先か、効率化が先か、など)です。この二つが固まっていれば、機能の取捨選択は後からいくらでも判断できます。
「決められる体制」を先に作る——判断の遅れが最大の敵
この規模の開発では、仕様の判断が毎週のように発生します。決定権者が曖昧だったり、多忙で会議に出られなかったりすると、判断待ちのたびに開発が止まり、期間とコストが静かに膨らみます。着手前に、日常の判断を行う実務責任者、部門間の対立を裁く決定者、経営として節目を承認する場、という三層の意思決定の仕組みを名前入りで決めてください。5,000万円の成否は、技術より先に、この体制で決まります。
このテーマでよく起きる問題
このテーマでよく起きる問題は、技術的な問題に見えて、実際には業務整理の不足から起きていることが多いです。たとえば、同じ機能でも部署ごとに運用が違う、帳票は同じ名称でも用途が違う、CSVの出力タイミングが担当者依存になっている、といったケースです。
この状態でパッケージを入れたり、スクラッチで作り直したりすると、開発途中で追加要件が増え、費用と期間が膨らみやすくなります。
この規模でよくある失敗は、現場の要望をすべて聞こうとして要件が確定しないまま開発が始まることです。善意の聞き取りが仇になり、後から仕様変更が相次いで、費用は膨らみ品質は下がります。要望は聞き尽くしてよいのですが、採否の判断は範囲と優先順位の物差しで機械的に行う。この冷静さを保つ仕組みが必要です。
また、発注側の担当者が通常業務と兼務のまま孤軍奮闘するパターンも危険です。5,000万円規模では、要件の確認、データの整備、テストの参加など、発注側にも相当の作業が発生します。専任に近い時間を確保できる担当と、その負荷を認めた業務分担を、契約前に社内で確定させておくべきです。
さらに、開発会社との役割分担を「全部お任せ」にしてしまうと、業務を知らないまま作られたシステムが納品されます。業務の知識は発注側にしかありません。任せる部分と、自社が主体的に関わる部分の線引きを、最初の合意事項にしてください。
自社で確認できるチェックポイント
契約に進む前に、次の点を社内で確認しておくと、開発が始まってからの混乱を大きく減らせます。
- 現在のシステムで実際に困っている業務を1つずつ書き出す
- 画面・帳票・CSV・バッチ・Excel補完作業を棚卸しする
- 利用部署、利用人数、締め処理、止められない業務を確認する
- サーバー、データベース、外部連携、バックアップの状態を確認する
- 現行システムを残す部分、直す部分、作り直す部分を分ける
- パッケージで足りる業務と、周辺開発が必要な業務を分ける
- 初期費用だけでなく、保守・追加改修・移行リスクも比較する
この規模ならではの決めごとの棚卸し
基本のチェックリストに加えて、対象範囲と対象外の明文化、優先順位の物差し、三層の意思決定体制と名前、発注側担当者の稼働確保、そして「成功の定義」（稼働日を守ることか、業務時間の削減か、属人化の解消か）を確認してください。成功の定義が曖昧なプロジェクトは、稼働はしたのに誰も満足していないという結末を迎えがちです。数字で測れる目標を一つでも掲げておくと、途中の判断も稼働後の評価もぶれません。
スケジュールには、要件定義と移行・テストに厚めの期間を確保してください。5,000万円規模の典型的な配分は、要件定義に2〜3割、設計・開発に4割、テスト・移行・定着に3割です。開発の比率が高すぎる計画は、後半の検証が薄い危険な計画だと読めます。
開発会社との定例会議の設計も、最初に決めるべきことの一つです。週次の実務定例と月次の運営会議を分け、実務定例では課題と決定を、運営会議では進捗・リスク・費用を扱う。会議体の役割が明確なら、判断は然るべき場に自然と集まり、持ち帰りの山で開発が滞ることを防げます。
延命・部分改善で対応できるケース
なお、5,000万円という規模が本当に適正かどうかも、着手前に一度立ち止まって確認する価値があります。
- 対象業務が限定されている
- 帳票やCSV連携の一部改善で足りる
- データベース改善やバックアップ自動化で安定運用できる
- 利用者が限られており、現場への影響が小さい
- 将来の全面刷新までの橋渡しとして改善したい
対象範囲の中に「実は使われていない機能の再現」や「統廃合できる帳票」が含まれていれば、業務側の整理で投資額を圧縮できます。逆に、範囲を欲張って薄く広げるくらいなら、今回は中核業務に絞って確実に仕上げ、残りは第二期に回すほうが、成功の確度は上がります。
この判断のために、契約前の現行調査・開発前診断に数十万〜数百万円を投じることは、5,000万円を守るための最も割のよい保険です。
期間の目安は1年〜1年半です。長丁場になるため、四半期ごとに経営へ進捗と課題を報告する節目を計画に組み込み、問題の早期発見と軌道修正ができる形にしておくことをおすすめします。
パッケージ活用・周辺開発・スクラッチ再構築を検討すべきケース
構築方式によって、最初に決めるべきことの力点は次のように変わります。
- 保守期限が近く、現行環境を長く使えない
- 開発会社がなく、改修や障害対応が難しい
- Access・Excel・古いDBではデータ量や運用に限界がある
- パッケージ標準機能が業務に合わない
- 周辺システムや帳票が増え、全体像が分からない
- 今後も機能追加や外部連携が増える見込みがある
パッケージ活用が向くケース
パッケージを核にする場合、最初に決めるのは「標準に合わせて業務を変える覚悟の範囲」です。カスタマイズの上限額を先に決めておくと、適合検討の際の判断が速く、費用の膨張も防げます。
周辺開発で補うケース
現行基幹を活かして周辺を固める構成では、本体と新規部分の責任分界と、将来の本体刷新時に周辺を活かせる設計方針を最初に決めます。5,000万円を将来の布石として設計できるかが問われます。
スクラッチ再構築が向くケース
スクラッチの場合、最初に決めるのはデータモデルと業務フローの骨格です。画面の見た目の議論は後回しにし、データの流れの合意に序盤の時間を投じることが、後半の手戻りを防ぐ最大の要因になります。
マクティズムの見解
マクティズムの見解として、5,000万円規模の基幹システム開発で最初に決めることでは「何を作るか」より先に「何を残すか、何を直すか、何を作り直すか」を決めることが重要です。
特に、最初に決めるべきは機能一覧ではなく、対象範囲と優先順位であることを意識しないまま進めると、パッケージを入れても周辺Excelが残ったり、スクラッチで作っても現場が使いにくかったりします。相談段階では、資料が完全にそろっていなくても問題ありません。画面、帳票、運用メモ、担当者の記憶を集めるところから始めるべきです。
5,000万円規模のご相談で私たちが最初に確認するのは、機能の要望ではなく、決める仕組みがあるかどうかです。体制が弱いと感じた場合は、開発の前に体制づくりからご一緒することもあります。発注側と開発側は、要望を出す人と応える人ではなく、同じ計画を守る共同運営者であるべきだというのが、この規模の案件を重ねてきた私たちの結論です。
相談前に準備しておく情報
この規模の相談では、対象業務の全体像、解決したい経営課題、想定体制、希望時期と予算の確度が分かると、初回から計画の骨格を一緒に描けます。社内の合意形成がこれからの段階でも、経営説明用の材料づくりからご支援できます。
実務では、契約前の現行調査と開発前診断で範囲・優先順位・体制の三点を文書化し、経営が承認できる計画書に仕上げてから開発契約へ進む二段構えをおすすめしています。急がば回れが最も金額に効く規模だからです。
そして、この規模では「言いにくいことを早く言う」関係が何より効きます。遅れの兆し、仕様の綻び、体制の無理。悪い知らせほど早く共有される座組みを、最初の会議で一緒に作りましょう。
範囲と優先順位と体制。この三つを固めて始めた5,000万円は、途中で嵐に遭っても目的地を見失いません。準備された投資は、金額の大きさに比例して、組織を成長させる経験にもなります。
進め方は、経営課題の確認、範囲と優先順位の文書化、体制の確定、診断による計画づくり、開発契約、の順です。この順序自体が、5,000万円を守る設計図です。
もう一つ、稼働後の運用体制も契約前に構想しておいてください。誰が問い合わせを受け、誰が改修の要否を判断し、保守費はいくら確保するのか。作って終わりの計画は、稼働した瞬間に無防備になります。5,000万円の資産を活かし続ける体制まで含めて、初めて計画は完成します。
これらの決めごとは一見遠回りに見えますが、開発が始まってからの一週間の停滞は、準備段階の一か月に相当する損失を生みます。始める前の丁寧さは、この規模では常に黒字の投資です。
また、決定事項は必ず議事録に残し、次回会議の冒頭で確認する運用を徹底してください。言った言わないの応酬は、この規模のプロジェクトが最も消耗する無駄です。記録の習慣一つで、会議の生産性と関係の健全さは大きく変わります。
準備を尽くした計画に、5,000万円は必ず応えてくれます。
よくある質問
概算費用だけ相談できますか？
はい。ただし、画面数、帳票数、連携数、データ移行、並行稼働の有無で大きく変わるため、現状整理を行うと精度が上がります。はい。この規模では、範囲と前提を固める診断を経てからの精度ある見積をおすすめしています。
要件がまとまっていなくても相談できますか？
はい。分かる範囲の業務内容、現在困っていること、使っている画面や帳票から整理できます。完璧な資料よりも、現状の困りごとを早めに共有することが大切です。経営課題の整理からで構いません。要件はその後に一緒に組み立てます。
すぐに全面再構築する必要がありますか？
いいえ。延命・部分改善で足りる場合もあります。まずは残す部分、直す部分、作り直す部分を切り分けます。はい。診断の結果、第一期を絞って段階的に進める計画へ組み替えることもよくあります。
パッケージとスクラッチのどちらがよいか判断できますか？
はい。業務が標準機能に合うか、帳票や例外処理をどう扱うか、将来の保守性まで含めて比較します。パッケージ・周辺開発・スクラッチの組み合わせ方針も、最初の計画づくりで一緒に決めます。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。データベース改善、帳票・連携、バックアップ自動化など、段階的な改善から始められる場合があります。はい。第一期を部分改善として切り出し、効果を見て第二期を判断する形にも対応します。
相談後にしつこい営業はありますか？
ありません。現状を確認したうえで、必要な進め方を整理します。無理に大きな開発を勧めることはありません。体制づくりの相談からでも歓迎です。決める仕組みが、この規模の成功の半分を占めます。
