私たちが取り組んだERPリプレースプロジェクトは、単なるシステム更新ではなく、企業全体の仕組みを見直す挑戦でした。
既存の枠組みにとらわれず、業務・データ・人を再設計する中で、現場の知恵とチームの信頼が結びつき、変革を現実のものとして形にしました。
本記事では、その立ち上げからリリース後までを振り返ります。
【関連記事】「いきなり議事録」導入事例：モバイル版で働き方が変わる！
プロジェクトの立ち上げまで
長年にわたり企業を支えてきた基幹システムが、事業拡大とともに限界を迎えていました。
新しい取引形態や業務スピードへの対応が求められる中、全社改革を支える“次の基幹”の構築が必要とされていたのです。
ここでは、私たちが、このプロジェクトに参画するまでを振り返ります。
顧客企業の概要と課題
支援先は、全国に拠点を展開する産業用資材・機械部品の専門商社です。
東京本社を中心に、名古屋・大阪・福岡に営業拠点を、千葉と神戸に物流センターを構え、
約1,000名の従業員が営業・物流・管理の各部門で業務を担っています。
事業規模の拡大に伴い取引形態が多様化し、既存システムでは対応しきれなくなっていました。
基幹システムは2008年に構築されたもので、当時の要件には十分応えていましたが、 長期運用の中で新しい業務形態への対応が難しくなり、全社的な改革を妨げる要因となっていました。
この課題に対し、ギグワークスクロスアイティのプロジェクトチームは、
「業務を止めずにシステムを移行し、将来の成長を支える基盤を構築する」という目的で支援を開始しました。
主な課題
システム面と業務運用の両面に課題が存在し、部門ごとに分断された運用が全体最適を損なっていました。
- 販売形態の多様化に非対応： リース契約や代理店販売など、複数の取引形態を共通基盤で管理できなかった。
- 営業活動のアナログ依存： 外出先からのアクセスができず、営業担当者は帰社後に受注登録を行う必要があった。
- 在庫・購買管理の遅延： 夜間バッチ処理による日次更新のため、リアルタイム性を欠いていた。
- システム間の連携不足： CRMやEC基盤とのデータ連携がファイル転送に限定され、即時性と整合性が確保できなかった。
- 経営情報の可視化不足： 経営ダッシュボードがなく、部門別や製品別の収益状況を即時に把握できなかった。
- 改修負荷の高さ： カスタマイズが属人的で、修正や機能追加に数か月を要した。
これらの問題は業務効率を低下させるだけでなく、経営判断のスピードや正確性にも影響を及ぼしていました。
こうした背景を受け、経営層は次のような方針を打ち出しました。
- 基幹システムの全面刷新により、業務とデータをリアルタイムで統合する。
- 業務プロセスを見直し、将来の事業成長に耐えうる柔軟な基盤を築く。
この方針を契機に、全社的なシステム刷新プロジェクトが正式に始動しました。
事前の分析と検討チームの発足
2023年秋、顧客企業からの相談を受けたギグワークスクロスアイティは、
まず現行システムの構造と運用実態の把握から着手しました。
要望は「業務を止めずにクラウドへ移行したい」というものでしたが、実際には、旧システム設計が事業モデルの変化に追いつかないという構造的な課題が存在していました。
ソリューション営業部の担当者は当時を振り返り、こう語りました。
「単なるシステム更新ではなく、業務プロセスとデータ構造を再設計する必要があると判断しました」
その後、営業・技術・インフラ・アプリケーションの各領域から専門担当者が集まり、
分析結果をもとに実現性を検討するチームが発足しました。
初期段階では機能刷新の範囲とリスクの特定に注力し、
約1か月をかけて現場ヒアリングと業務フローの可視化を進めました。
社内キックオフ：体制と方向性の確立
11月下旬、検討チームは正式なプロジェクト組織として活動を開始しました。
メンバーは12名体制。PMを中心に、クラウド基盤設計、ERPモジュール、連携API、データ移行、品質保証を担うメンバーが横断的に協働しました。
プロジェクトマネージャーはキックオフの場で次のように述べました。
「これは単なるリプレースではありません。顧客の事業を継続的に支える“次の基幹”を構築するプロジェクトです」
チームは検討初期の段階で方針を明確化し、次の5項目を基本方向として定義しました。
- マルチチャネル対応： 直販EC、リース契約、代理店取引を共通基盤で統合管理する。
- リアルタイム統合： 営業・物流・会計データを即時に連携し、部門間の可視化を実現する。
- クラウド基盤の拡張性： 海外拠点やリモート業務を含めた安定的なアクセス環境を確保する。
- データ可視化と経営支援： BIツールとデータ基盤を活用し、迅速な意思決定を支援する。
- 外部連携の自動化： CRM・EC・MAツールとのAPI連携によって、データ処理をリアルタイムに一元化する。
アプリケーション開発部の担当者は当時をこう振り返ります。
「機能を増やすことよりも、部門間を“つなぐ”構造を設計することが最大の成果だと考えていました」
この方針をもとに、翌月から具体的な要件定義フェーズが開始されました。
プロジェクトの船出
年明け、顧客企業の責任者・ギグワークスクロスアイティのメンバー・協力会社による合同キックオフミーティングが開催されました。
提案資料やデモ環境の準備が整い、チーム全体が本番を意識した緊張感に包まれていました。
インフラ統括の担当者は次のように語ります。
「現行システムを否定するのではなく、これまで積み上げた信頼とノウハウを新しい環境に正しく引き継ぐ―― その姿勢を具体的に形にすることを意識しました」
この日を境に、システム刷新プロジェクトは設計および移行計画の検証フェーズへと正式に移行しました。
ERPリプレースプロジェクト：立ち上げから進行まで
ここでは、プロジェクト推進初期の組織づくりから技術方針の確定、そして進行管理体制が整うまでの過程をまとめます。
共通のゴールを描く：関係者による意識合わせ
ERPリプレースプロジェクトが正式に始動すると、関係者全員による意識合わせが最初の取り組みとして行われました。
営業、物流、会計、情報システムなど、各部門の担当者が一堂に会し、プロジェクトの方向性と目的を確認しました。
プロジェクトマネージャーは冒頭でこう伝えました。
「このプロジェクトの目的は“システムの入れ替え”ではありません。 次の10年を支え続ける“業務の設計図”を作ることがゴールです。」
この方針のもと、議論の重点は「何を作るか」よりも、「なぜ変えるのか」へと移りました。
長年の運用の中で機能追加が繰り返され、修正のたびに構造が複雑化していました。
その結果、部門最適の積み重ねが全体最適を阻み、拡張にも限界を迎えていたのです。
チームはまず、既存機能の全面的な洗い出しから着手しました。
どの業務プロセスが事業の中核を担うのかを明確にし、基幹を支える要素を再定義していきました。
この段階で掲げられた目的は、単なる移行ではなく、「事業構造を再設計する」ことでした。
技術構成の決定
意識統一の後、議論はシステム構成の検討へと進みました。
焦点となったのは、「変化に強いシステム構造をいかに実現するか」という点でした。
フロントエンドには、操作性と反応速度を重視してReact／Next.jsを採用。
バックエンドでは、AWSを軸とするクラウド構成を取り入れ、LambdaとAurora（PostgreSQL）によるサーバーレス設計としました。
さらにGraphQLをデータ連携層に導入し、部署やシステムを横断してデータを一元的に扱えるように構築しました。
この構成を採択した理由は明確でした。
「機能を増やすよりも、相互運用性を高めること」――それが中長期的な安定を生むと判断したのです。
社内外にまたがるサービスが増加する中で、API連携や海外拠点からのアクセスにも対応できる柔軟な仕組みが求められていました。
アプリケーション開発担当者は後にこう振り返りました。
「新しい技術を積み上げるよりも、変化に耐える“柔らかい構造”を作ることを優先しました。」
この決断により、プロジェクト全体の技術基盤が定まり、
フロント、API、インフラ、データ分析の各領域が自律的に連携できる開発フローが整いました。
体制決定とチーム発足
プロジェクト体制は、ギグワークスクロスアイティの中核メンバー約20名を中心に、
顧客企業側のPM／SEチーム約10名、さらに協力会社の技術者が加わる形で構築されました。
総工数は2万時間以上と見込まれ、長期にわたる開発体制が求められました。
特徴的だったのは、役割分担を「機能単位」ではなく「課題領域単位」で分けた点です。
要件定義からテストまでを一貫して担う小規模チーム体制を採用し、現場が自ら課題を判断しながら動けるように設計しました。
プロジェクト管理担当者はこの方針をこう語ります。
「結論を上から降ろすより、現場が理解して動ける体制のほうが強い。 “伝言ではなく、理解で回す”ことを優先しました。」
この自律的なチーム運営は、長期プロジェクト特有の停滞を防ぎ、継続的な進行を支える基盤となりました。
スケジュールと進行
プロジェクトは、業務整理からTo-Be設計、システム開発、テスト・移行、運用安定化の
4フェーズに整理されました。各フェーズの順序を固定しつつも、進捗状況に応じて内容を柔軟に見直す仕組みとしました。
完全なウォーターフォールでは業務変化への対応が難しく、一方でフルアジャイルでは顧客合意のスピードが落ちる。
そのため、要件定義を固定し、以降の工程をスプリント形式で進めるハイブリッド型手法が採用されました。
2週間単位の開発サイクルを設定し、定例レビューで進捗と課題を共有。
リスクを早期に顕在化させ、影響範囲を限定する仕組みを確立しました。
この運用により、開発中に発生した仕様見直しやAPIの変更にもスムーズに対応できました。
レビューを通じてチーム間の情報共有が定着し、全員が同じ認識で動ける環境が整えられました。
こうしてプロジェクトは立ち上げから設計までの礎を固め、次のフェーズとなる開発・移行段階へと歩みを進めていきました。
「10年間の安定運用」を目指して：リリースとその先へ
立ち上げから約2年を経て、ERPリプレースプロジェクトは最終段階に差しかかりました。
これまで積み重ねてきた設計や開発の成果を統合し、安定稼働へと導くための最終工程が始まります。
本章では、リリース直前のテストと運用準備、そして移行・稼働後の成果について紹介します。
テストとリリース準備：最後の仕上げ
システムの全体設計が完了すると、各チームで開発された成果物を統合する総合テストが行われました。
営業、物流、会計、管理といった主要業務を横断し、実際の業務フローに沿った動作検証が中心です。
単なる機能確認ではなく、「実運用と同等の負荷・手順で途切れなく稼働できること」を目標に設定しました。
このテストでは、API経由の連携やリアルタイム在庫更新など、並列処理を多用する新システム特有の動作が重点的に検証されました。
処理性能の計測結果を可視化し、ボトルネックを数値で把握したうえでチューニングを実施。
各担当チーム間の調整が進むごとに、応答速度は着実に改善していきました。
同時に、運用ルールとマニュアル整備も本格化しました。
AWS上の管理ポリシーを再設計し、監査基準に準拠するためのアクセス制御や操作ログ管理を強化。
障害発生時の対応フローやエスカレーション経路を標準化し、担当者が誰でも即時対応できる状態を整備しました。
運用マニュアルの最終レビューでは、各部署の責任者が実際に操作を検証するリハーサルも行われています。
プロジェクトマネージャーはこの段階を振り返り、
「リリース直後の混乱を防ぐのは技術力よりも準備力でした。 全員が正しい手順で動ける状態を作ることが、安定運用への第一歩でした。」
と語りました。
データ移行とリリース
テスト工程と並行して進められたのが、約4TBに及ぶ業務データの移行作業でした。
旧システムではフォーマットが部門ごとに異なり、単純な転送ではデータの整合が取れませんでした。
そのため、移行専用のPythonスクリプトを開発し、AWS Glueを用いた並列転送で業務を止めずに移行する“並列稼働方式”を実現しました。
移行計画は段階的に立案され、2回のリハーサルを実施してから本番に臨みました。
初回のリハーサルでは一部の大型テーブルで書き込み処理が集中し、ストレージI/Oが飽和して遅延が発生。
原因は、旧来バッチ処理の取り込みタイミングと新環境での負荷分散構成が競合していたためでした。
チームは数日を要してログを精査し、バッチ処理の分割方式とスケジュールを再設計。
再試験では処理を分割・分散化し、AWSリソースの自動拡張制御を適用することで処理速度を大幅に改善しました。
結果、転送時間は初回比で約60％短縮され、主要データの整合性も予定通り確認できました。
この再設計が功を奏し、スケジュール遅延を招くことなく本番移行を完了。
リリース当日も想定していた業務中断時間内で稼働を再開し、大きな混乱はありませんでした。
部門間の連携体制と事前リハーサルの徹底が、成功を支える決定打となりました。
リリース後は各部門で初期不具合対応が続きましたが、1か月ほどで安定稼働に移行しました。
重大トラブルは発生せず、移行から日常業務への切り替えも滑らかに進行しました。
成果と顧客の反応
リリースを経て、企業全体のオペレーションは大きく変化しました。
刷新されたシステムは業務をつなぐ「企業の神経網」として機能し、具体的な成果を生み出しています。
- 業務の一元管理
営業・リース・受発注・請求を統合した「デジタル営業ダッシュボード」を新設。
各部門が共通の指標で判断できるようになり、定例会議の資料作成時間は半減しました。 - 在庫と供給精度の改善
在庫データをリアルタイム更新に切り替え、欠品率を1.2％ → 0.08％まで改善。
発注タイミングの調整が自動化され、繁忙期でも安定供給を維持できるようになりました。 - 経営分析の即時化
Power BIとQuickSightを活用し、経営層が拠点別・製品別の利益を即座に可視化。
レポート作成のリードタイムは従来の1/5に短縮されました。 - 働き方の柔軟化
リモートワークや海外拠点からもシームレスにアクセス可能となり、
オペレーションの標準化とモバイル環境での即応性が向上しました。 - 運用自動化による安定稼働
AWS基盤の監視機構を自動化し、データ同期率は99.97％を継続維持。
障害発生時の初動対応も自動化され、24時間稼働の安定性が確立されました。
顧客企業の経営層は、リリース後の報告会でこう総括しました。
「分断していた業務がようやく一本化され、データがリアルタイムに流れるようになった。 “現場が変わった”という実感が社員から上がることこそ、真の刷新の証です。」
刷新後のシステムは、当初の目標である“10年間の安定運用”を見据えながら、今も改善と最適化のサイクルを続けています。
ギグワークスクロスアイティと顧客企業が共に築き上げたこの基盤は、単なるリプレースではなく、「次の10年を支える拡張型の業務基盤」へと進化を続けています。
プロジェクトを通して得たもの
本プロジェクトは、システム刷新の枠を超え、組織のあり方そのものを変える機会となりました。
ギグワークスクロスアイティのメンバーにとって最大の成果は、それぞれが「共通言語で課題を語れる関係」を築けたことでした。
意見の違いを越えて、目的を共有することで現場が自走する体制が生まれ、「伝える」から「理解する」へ――そんな協働の形が社内に根付きました。
また、安易な置き換えではなく“止めずに変える設計”の重要性を実感しました。
変化を前提に考える姿勢は、単なる開発スキルを超えた財産となり、次のプロジェクトにも引き継がれています。
リプレースは終わりではなく、進化の始まりです。
「変化を受け入れる力」こそが、これからの10年を支える土台だと、私たちはこのプロジェクトを通じて確信しています。
この記事を書いた人
