売上が伸びて、表計算と会計ソフトの組み合わせでは受注や在庫が回らなくなってきた。そろそろ基幹システムを入れる時期だと分かってはいるものの、これまで自社にシステムがなかったので何から手を付ければいいのか分からない。開発会社に相談したら「現状の業務フローをください」と言われたけれど、そんな資料は作ったことがない。基幹システム構築を調べる方の多くは、この入口で止まっています。
既存システムの入れ替えと新規構築でいちばん違うのは、参照できる仕様が社内に存在しないことです。入れ替えなら「今のシステムと同じ動きで」と言えますが、新規構築では誰がいつ何を入力し、例外をどう処理するのかを、自社で決めてから発注する必要があります。逆に言えば、業務のやり方を新しく決められる自由がある状態です。この記事では、進め方の5工程、発注前に自社で決める4つのこと、パッケージと個別開発の選び分け、期間と費用の考え方までを発注側の目線で整理します。
この記事のポイント
- 新規構築は現行の仕様がないため、要件定義の前に業務の標準化を決める必要がある
- 工程は企画・要件定義・設計開発・データ整備・並行運用の5つで押さえる
- パッケージか個別開発かは、規模ではなく業務が固まっているかで選び分ける
- カスタマイズを増やすと、パッケージの安さも個別開発の適合度も失う
目次
基幹システム構築の進め方と発注前の準備
まず全体の流れと、自社側でやることを押さえます。新規構築では発注側の作業量が想像より多いので、そこを先に見ておくと計画が立てやすくなります。
刷新と違って新規構築は業務の標準化から始まる
既存システムを入れ替える案件では、現行の画面や帳票が仕様の代わりになります。新規構築にはそれがありません。表計算のファイルと紙の帳票、そして担当者の頭の中に業務が分散している状態から始めることになります。
そこで最初にやるのが業務の標準化です。同じ受注処理でも、担当者ごとに手順が違っていたり、電話で受けた注文をメモで回していたりします。この状態のまま要件を出すと、開発会社は「どれが正しい手順か」を判断できません。誰がいつ何を入力するのか、例外的な取引をどう処理するのかを、自社で決めるところが出発点になります。
この作業は面倒ですが、新規構築の最大の利点でもあります。入れ替え案件では過去の仕組みに引っ張られますが、新規なら業務そのものを整理し直せます。私の感覚では、ここに1〜2か月かけた会社のほうが、その後の要件定義が短く済みます。
構築の流れは5つの工程で押さえる
基幹システム構築の工程は、細かく分けるといくつもの名前が出てきますが、発注側としては5つで捉えておけば十分です。それぞれで自社に発生する作業も並べておきます。
| 工程 | 自社側の主な作業 | つまずきやすい点 |
|---|---|---|
| 企画 | 目的と対象業務を決め、予算と時期の枠を置く | 目的が「効率化」だけで具体的な状態になっていない |
| 要件定義 | 業務の流れを説明し、決めごとを承認する | 部門の担当者が出てこず、決定が先送りになる |
| 設計・開発 | 画面や帳票のレビュー、判断待ちへの回答 | 回答が遅れて開発が止まり、そのまま納期に響く |
| データとマスタの整備 | 取引先・品目のコード整理と初期データの用意 | 重複や表記ゆれを直さないまま登録してしまう |
| 並行運用と稼働 | 現場への説明、手順書づくり、二重運用の期間対応 | 現場が新しい手順を知らないまま稼働日を迎える |
特に見落とされやすいのが、4番目のデータとマスタの整備です。新規構築では移行元のシステムがない代わりに、取引先や品目のマスタを一から作ります。表計算に散らばった取引先名を突き合わせると、同じ会社が3通りの表記で登録されていた、といったことが普通に起きます。
コード体系も先に決めておく必要があります。取引先コードや品目コードの桁数と付け方は、あとから変えると帳票や集計に影響が出ます。開発会社に任せるのではなく、自社の業務で使いやすい形を決めてください。
発注前に自社で決める4つのこと
相談に行く前に、次の4点を決めておくと提案の精度が上がります。逆にここが空白のまま相談すると、開発会社は最大の範囲で見積もるしかなく、金額が膨らみます。
発注前に自社で決めること
- 対象業務の範囲（受注・在庫・請求まで含めるか、会計は既存のまま使うか）
- コード体系とマスタの方針（取引先・品目のコードの付け方、誰が管理するか）
- 決める人（部門ごとに1名、その人たちが週次で判断する体制）
- 稼働させたい時期とその理由（決算期・繁忙期を外す、補助金の締切など）
4つ目の「時期とその理由」は特に大事です。「できるだけ早く」ではなく「来期の期首から使いたい」と伝えられれば、開発会社は逆算した計画を出せます。繁忙期に稼働日を置いてしまい、現場が新しい手順を覚える余裕がないまま切り替えるのは、避けたい失敗のひとつです。
これらを文章にまとめるとき、何を書けばよいか迷う場合は要件定義書テンプレート（Word形式）の項目を埋める形で進めると抜けが見つけやすくなります。プロジェクト概要と目的、現状フロー、構築後のフロー、利用者一覧、機能要件といった順で並んでいるので、新規構築でも順に埋めていけます。
期間と費用の目安の考え方
期間は対象範囲で大きく変わります。受注管理だけなど単一業務なら数か月、販売・在庫・請求まで含めると1年前後、全社規模になるとそれ以上を見ることになります。新規構築では業務の標準化とマスタ整備に時間がかかるため、開発期間だけを見て計画すると足りません。
費用も同様に範囲と作り方で動きます。パッケージ導入なら初期費用と月額の組み合わせ、個別開発なら工数の積み上げが基本です。規模別・種類別の相場感はシステム開発の費用相場と内訳｜規模別・種類別の目安で整理しているので、予算の枠を置くときはそちらを見てください。なお金額や期間はあくまで一般的な目安で、実際の判断は個別の見積もりで確認する必要があります。
予算を組むときに忘れやすいのが、稼働後の運用費です。パッケージなら月額利用料と保守、個別開発なら保守契約が毎年かかります。初期費用だけで判断せず、5年間の総額で比べる視点を持っておくと、あとで「思っていたより高い」となりません。
基幹システム構築でパッケージか個別開発か
次は作り方の選択です。ここは「規模が小さいならパッケージ」と単純化されがちですが、実務ではもう少し違う軸で決まります。
業務が固まっているかで選び分ける
判断の軸は、自社の業務のやり方がすでに固まっているかどうかです。固まっていれば、それに近いパッケージを探せます。まだ変わり続けている段階なら、パッケージに合わせて業務を作るほうが早いこともあります。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| 業務パッケージ | 業種の標準的な流れに近く、早く安く整えたい | 製品に業務を合わせる調整が社内で発生する |
| クラウドERP | 会計や人事も含めて一元化し、法改正対応も任せたい | 月額が続き、カスタマイズの自由度に制約がある |
| 個別開発 | 業務の独自性が競争力になっている | 仕様を決める責任と保守の負担が自社に残る |
実務では組み合わせが多数派です。事業の中核だけを個別開発で作り、会計・給与・経費精算はクラウドサービスに任せる形です。全部を1つの製品で揃えようとすると、どこかの業務が必ず窮屈になります。
選ぶときに聞いてみてほしいのは、「その業務のやり方は、同業他社と違うことに意味があるか」という問いです。意味があるなら個別開発の対象、特にこだわりがないならパッケージに合わせたほうが、費用も期間も保守の負担も軽くなります。
カスタマイズを増やすと両方の弱点が出る
パッケージを選んだあと、現場の要望に応えてカスタマイズを重ねていくと、費用が個別開発に近づく一方で、製品のバージョンアップに追従しづらくなります。安さも柔軟さも失うという、いちばん避けたい状態です。
目安として、カスタマイズが多いと感じた時点で一度立ち止まってください。標準機能で回せない部分が全体の何割あるのかを数え、その割合が大きいなら、そもそもパッケージの選定自体が合っていない可能性があります。製品を変える判断のほうが、結果的に安く済むこともあります。
カスタマイズの要望が出たときは、「業務を変えれば標準機能で回るか」を必ず1回は検討してください。長年の慣習でそうしているだけの手順は、新規構築のタイミングなら変えやすいはずです。
部門単位の改善なら基幹システムを作らない選択もある
相談を受けていて時々あるのが、そもそも基幹システムを作る必要がないケースです。困っているのが特定部門の作業だけで、事業の根幹業務は表計算と会計ソフトで回っているなら、既製のクラウドサービスや部門向けツールで足りることがあります。
判断の目安は、止まったときに事業が続けられなくなるかどうかです。受注・出荷・請求が止まるなら基幹システムの領域ですが、一部の集計が遅れるだけなら、部門向けのツールで十分なことが多いです。買うか作るかの線引きは業務改善システムは買うか作るか？既製ツールと開発発注の選び方で詳しく整理しています。
いきなり全社の基幹システムを作るのではなく、いちばん困っている業務から始めて、あとから広げる進め方もあります。最初の投資を小さくできるうえ、社内に「システムを使って業務を変えた」経験が残るので、次の判断が速くなります。
新規構築で起きやすい失敗と防ぎ方
最後に、新規構築でよく見る失敗を3つ挙げます。どれも発注側の準備で避けられるものです。
ひとつ目は、要件定義を開発会社に任せきりにすることです。現行システムがない分、開発会社はヒアリングから業務を組み立てることになりますが、そこで出てきた案を検証せずに承認すると、稼働後に「実際の業務と違う」となります。決めた内容は自社の言葉で説明できる状態にしてください。
ふたつ目は、マスタの整備を後回しにすることです。開発が進んでいても、取引先や品目のデータが揃わなければテストができません。設計と並行して整備を始め、担当を決めて進めてください。みっつ目は、全業務を同じ日に一斉稼働させることです。受注だけ先に切り替え、在庫と請求は翌月から、といった段階リリースにすると、現場の負荷も障害時の影響も小さくできます。どこまでを対象にするかの線引きそのものは、基幹システムとは？種類とERPとの違い・発注前の判断軸で整理しています。
基幹システム構築についてよくある質問
- Q. 基幹システムは内製できますか？
- A. 社内に開発できる人がいれば技術的には可能ですが、基幹システムは止まると事業が止まるため、担当者が1人だけという体制はリスクが高くなります。作った本人が退職すると誰も直せない状態になりがちです。内製する場合でも、仕様書を残す、複数人で開発する、保守だけ外部と契約するなど、引き継ぎの手当てを前提にしてください。
- Q. 表計算での運用から、いつ移行すべきですか？
- A. 判断のサインは3つあります。同じ数字を複数の場所に入力している、月次の集計に何日もかかっている、特定の人しか処理できない業務がある。どれかが出てきたら検討の段階です。逆に取引件数が少なく、集計も数時間で終わるなら、まだ表計算で回して構いません。
- Q. 開発会社は何社くらいに相談すればよいですか？
- A. 3社前後が現実的です。同じ資料と同じ質問で提案を受けると、前提の違いや得意分野の差が見えます。1社だけだと金額の妥当性が判断できず、5社以上になると比較の手間で本業が止まります。相談前に対象業務の範囲を決めておくと、社数を絞っても十分な比較ができます。
- Q. 稼働までにどのくらい社内の工数がかかりますか？
- A. 範囲によりますが、要件定義の期間は各部門の担当者が週に半日から1日、情シス側の担当者はほぼ専任に近い関わり方になることが多いです。データとマスタの整備は別途まとまった時間が必要です。社内工数を見込まずに計画すると、通常業務との両立ができずに遅れます。
