最初に何をすべきか知りたい企業にとって、最初から大きな開発を決める必要はありません。まずは現行業務・帳票・データ・連携・保守状況を整理し、延命、部分改善、パッケージ活用、周辺開発、スクラッチ再構築のどれが現実的かを見極めることが重要です。
マクティズムでは、作り直しありきではなく、棚卸しは要件定義の前に行うべきであることを重視して進め方を整理します。
この記事では、基幹システム再構築の最初に行うべき「現状棚卸し」の進め方を整理します。何から手を付ければよいか分からず検討が止まっている企業の担当者に向けて、最初の一歩の具体的な踏み出し方をお伝えします。70記事シリーズの最終記事として、すべての出発点となるテーマをまとめます。
この記事で分かること
- 基幹システム見直しで確認すべきポイント
- 延命・部分改善で済むケース
- パッケージ活用や周辺開発を検討すべきケース
- スクラッチ再構築を検討すべきケース
- 相談前に準備しておく情報
まず結論｜すぐに作り直す前に現状を整理する
基幹システムは、受注・出荷・在庫・請求・生産・会計連携など、複数の業務にまたがります。そのため、表面上の不具合だけを見て判断すると、後から帳票、データ移行、外部連携、現場運用で想定外の問題が出ることがあります。
まず必要なのは、現行システムの全体像を把握することです。特に、どの業務が止まると困るのか、どの帳票が実際に使われているのか、どのExcel・Access・CSV運用が周辺に残っているのかを確認するだけでも、再構築の方向性はかなり明確になります。
棚卸しは要件定義の「前」にやるべき作業
多くの企業は、再構築の検討を「どんなシステムを作りたいか」から始めますが、正しい順序は「今どうなっているかを知る」が先です。現行の業務・システム・データ・帳票・連携・例外処理を棚卸しし、全体像を把握してから、残す・直す・作り直すの判断に進む。この順序を守ることで、要件定義の精度が上がり、見積の信頼性が高まり、プロジェクト全体のリスクが下がります。
完璧な棚卸しを目指さない——80%で次に進む勇気
棚卸しは大切ですが、100%の完全な棚卸しを目指すと、棚卸し自体がプロジェクト化して動けなくなります。目安として、業務の80%を把握できれば次のステップに進んで構いません。残りの20%は要件定義や開発の過程で発掘されますが、80%の土台があればその発掘にも対応できます。棚卸しは完璧を目指す作業ではなく、次の判断を可能にする材料を集める作業です。
このテーマでよく起きる問題
このテーマでよく起きる問題は、技術的な問題に見えて、実際には業務整理の不足から起きていることが多いです。たとえば、同じ機能でも部署ごとに運用が違う、帳票は同じ名称でも用途が違う、CSVの出力タイミングが担当者依存になっている、といったケースです。
この状態でパッケージを入れたり、スクラッチで作り直したりすると、開発途中で追加要件が増え、費用と期間が膨らみやすくなります。
棚卸しでよくある失敗は、システムの構成だけを調べて業務の実態を確認しないケースです。画面やテーブルの一覧はあるが、実際にどう使われているか、どの例外処理が生きているかが分からない。システムの調査と業務の調査を両輪で行わなければ、棚卸しの価値は半分以下になります。
また、棚卸しをIT部門だけで完結させようとする失敗も多くあります。業務の実態を知っているのは現場であり、現場のキーパーソンへのヒアリングなしに正確な棚卸しは不可能です。棚卸しは全社的な活動として位置づけ、現場の参加時間を確保してください。
さらに、棚卸しの結果を文書化せずに頭の中にとどめてしまうケースも問題です。文書化されていない情報は、担当者の異動で消失します。棚卸しの成果物は、再構築プロジェクトの全期間を通じて参照される基本資料であり、組織の資産として文書で残す必要があります。
自社で確認できるチェックポイント
棚卸しで確認すべき項目は、次の領域に分かれます。
- 現在のシステムで実際に困っている業務を1つずつ書き出す
- 画面・帳票・CSV・バッチ・Excel補完作業を棚卸しする
- 利用部署、利用人数、締め処理、止められない業務を確認する
- サーバー、データベース、外部連携、バックアップの状態を確認する
- 現行システムを残す部分、直す部分、作り直す部分を分ける
- パッケージで足りる業務と、周辺開発が必要な業務を分ける
- 初期費用だけでなく、保守・追加改修・移行リスクも比較する
現状棚卸しの実践チェックリスト
【業務の棚卸し】主要業務の流れ（受注→出荷→請求など）を一枚の図にする。各業務の担当者・頻度・所要時間を記録する。例外処理や手作業の補完を洗い出す。【システムの棚卸し】画面・帳票・バッチの一覧と利用状況。データベースの種類・サイズ・テーブル数。外部連携（CSV・API・EDI）の一覧。サーバー・OS・ミドルウェアのバージョンと保守期限。【データの棚卸し】マスタの件数と重複状況。データの保持期間と移行対象の範囲。データの汚れ（不正値・文字化け）の有無。【運用の棚卸し】保守体制と担当者。障害の頻度と対応手順。バックアップの方法と復旧テストの実施状況。
棚卸しの期間は、中小企業であれば1〜2週間、中規模企業で2〜4週間が目安です。専門の開発会社に依頼すれば、効率的にヒアリングと文書化を進められます。数十万〜数百万円の投資で、再構築プロジェクト全体の精度を大きく高める、最も費用対効果の高い作業です。
棚卸しを外部の開発会社に依頼するメリットは、自社だけでは見えない比較の視点が入ることです。「他の企業ではこの業務をこう効率化しています」「このデータの持ち方は将来の拡張を妨げます」といった、業界横断の知見は社内調査では得られません。棚卸しを依頼すること自体が、外部の知見を取り込む機会になります。
延命・部分改善で対応できるケース
棚卸しの結果は、再構築だけでなく部分改善の判断にも直接役立ちます。
- 対象業務が限定されている
- 帳票やCSV連携の一部改善で足りる
- データベース改善やバックアップ自動化で安定運用できる
- 利用者が限られており、現場への影響が小さい
- 将来の全面刷新までの橋渡しとして改善したい
棚卸しの結果、全面再構築が必要ではなく部分改善で足りると分かることも珍しくありません。その場合、棚卸しの費用は「不要な大型投資を避けるための保険」として十分に元が取れます。また、棚卸しで得た業務の全体像は、どの改善を先に行うべきかの優先順位付けにもそのまま使えます。
棚卸しは、答えを出す作業ではなく、問いを明らかにする作業です。「何が分かっていて、何が分かっていないか」が見えれば、次のステップ——要件定義、見積取得、方式選定——のいずれも、格段に精度高く進められます。
棚卸しの成果物は、業務フロー図、システム構成図、画面・帳票一覧、データ概況、保守状況の5点セットが基本です。これらがそろった状態は、どの開発会社に相談しても話が通じるレベルであり、見積の精度も一段上がります。
パッケージ活用・周辺開発・スクラッチ再構築を検討すべきケース
棚卸しの結果は、構築方式の選定にも直結します。
- 保守期限が近く、現行環境を長く使えない
- 開発会社がなく、改修や障害対応が難しい
- Access・Excel・古いDBではデータ量や運用に限界がある
- パッケージ標準機能が業務に合わない
- 周辺システムや帳票が増え、全体像が分からない
- 今後も機能追加や外部連携が増える見込みがある
パッケージ活用が向くケース
棚卸しで業務が標準的と分かれば、パッケージ移行の可能性が高まります。逆に例外処理が多ければ、パッケージでは吸収しきれないことが見えてきます。
周辺開発で補うケース
棚卸しで課題の優先順位が見えれば、最も効果の大きい部分から周辺開発で改善するロードマップが描けます。
スクラッチ再構築が向くケース
棚卸しで業務の複雑さの全容が見えれば、スクラッチの見積精度が上がり、段階導入の切れ目も設計しやすくなります。
マクティズムの見解
マクティズムの見解として、基幹システム再構築で最初にやるべき現状棚卸しでは「何を作るか」より先に「何を残すか、何を直すか、何を作り直すか」を決めることが重要です。
特に、棚卸しは要件定義の前に行うべきであることを意識しないまま進めると、パッケージを入れても周辺Excelが残ったり、スクラッチで作っても現場が使いにくかったりします。相談段階では、資料が完全にそろっていなくても問題ありません。画面、帳票、運用メモ、担当者の記憶を集めるところから始めるべきです。
棚卸しは、70記事シリーズのすべてのテーマに共通する出発点です。どの記事のテーマであっても、最初にやるべきことは現状を知ることだと繰り返し書いてきました。棚卸しは地味で面倒な作業ですが、この一歩を踏み出した企業と踏み出さなかった企業では、その後の検討の質と速度に歴然とした差が生まれます。私たちは、この最初の一歩のお手伝いを最も得意としています。何も決まっていなくて構いません。まずは話を聞かせてください。そこからすべてが始まります。
相談前に準備しておく情報
棚卸しの相談では、実は何も準備がなくても始められます。棚卸し自体が「何を知るべきかを知る」ための作業だからです。強いて言えば、サーバーやシステムの構成が分かるメモ、主要な帳票のサンプル、困っている業務の名前があると、棚卸しの計画を立てやすくなります。ですが、何もない状態からでもお手伝いできます。それこそが棚卸しの目的です。
実務では、棚卸しを「開発前診断」というサービスとして提供し、1〜2週間の短期間で業務・システム・データの全体像を把握して、次のステップの選択肢を報告書にまとめる形をおすすめしています。
棚卸しの成果物は、再構築プロジェクトだけでなく、その後の保守・改善・次の刷新に至るまで、何年にもわたって参照される組織の知的資産です。棚卸しに投じた数十万〜数百万円は、その資産を生む種銭であり、システム投資全体の中で最もリターンの大きい支出です。
70本の記事を通じてお伝えしてきた基幹システム再構築の知恵は、すべてこの最初の一歩——現状棚卸し——から始まります。業務を知り、データを知り、人を知り、制約を知る。その先に、自社に合った最善の道が見えてきます。迷ったら、まず棚卸しから。それが、70記事を通じた私たちの結論です。
棚卸しは、業務の流れ図を描く、システム構成を確認する、画面・帳票・連携を一覧にする、データの状態を確認する、保守と運用の現状を記録する、の5ステップです。1日1ステップでも、1週間で一巡できます。その1週間が、数年分の検討を前に進める力になります。
棚卸しの成果物を社内で共有する場を設けてください。業務の全体像が一枚の図で見えるようになると、「知らなかった」「うちの部署ではこう使っている」といった発見が部門間で共有され、再構築への機運が自然と高まります。棚卸しは調査であると同時に、社内の意識統一の場としても機能するのです。
最後に改めてお伝えしたいのは、棚卸しという最初の一歩は、今日からでもできるということです。困っている業務を3つ書く。主要帳票のサンプルを集める。サーバーの構成メモを確認する。どれも1時間あればできる作業です。その1時間が、数年分の検討を動かす力になります。まずは手を動かしてみてください。そして、整理が必要だと感じたら、いつでもご相談ください。棚卸しのお手伝いこそが、私たちの最も得意な最初の仕事です。
よくある質問
要件がまとまっていなくても相談できますか？
はい。分かる範囲の業務内容、現在困っていること、使っている画面や帳票から整理できます。完璧な資料よりも、現状の困りごとを早めに共有することが大切です。何も準備がない状態から始めるのが、棚卸しの目的です。まず話を聞かせてください。
すぐに全面再構築する必要がありますか？
いいえ。延命・部分改善で足りる場合もあります。まずは残す部分、直す部分、作り直す部分を切り分けます。はい。棚卸しの結果、全面再構築は不要と分かることもあり、それ自体が価値ある成果です。
パッケージとスクラッチのどちらがよいか判断できますか？
はい。業務が標準機能に合うか、帳票や例外処理をどう扱うか、将来の保守性まで含めて比較します。棚卸しの結果が方式選定の材料になるため、方式は棚卸し後に一緒に検討します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。データベース改善、帳票・連携、バックアップ自動化など、段階的な改善から始められる場合があります。はい。開発前診断として、数十万〜数百万円でお受けしています。
相談後にしつこい営業はありますか？
ありません。現状を確認したうえで、必要な進め方を整理します。無理に大きな開発を勧めることはありません。棚卸しは70記事すべての出発点です。ここから始めれば、必ず前に進めます。
