楽々フレームワークで基幹システムを再構築!「勝てる刷新」へ導いた記録

多くの企業が「古くなった基幹システムをどうにかしたい」と願いながらも、予算の肥大化や失敗への恐怖から一歩を踏み出せずにいます。本稿では、私たちが中堅製造卸売業の基幹システムを刷新した取り組み事例をご紹介します。あえて「全部を捨てない」という選択をすることで、どのように停滞した刷新プロジェクトを軌道に乗せ、次なるデジタル変革への土台を築いたのかを詳しく解説します。

【関連記事】繁忙期でも品質を落とさない!コールセンターBPM改善の記録

レガシー基幹が全体の足を引っ張る

基幹システムの刷新は、現代の企業にとって避けては通れない課題です。しかし、いざ着手しようとすると、想像を絶する困難が立ちはだかります。全国に拠点を展開し、機械部品の製造と卸売を主力事業とするA社も、まさにその壁に突き当たっていました。A社では、約20年前に構築された独自の基幹システムが、受発注、在庫管理、出荷、請求といった中核業務を支え続けてきました。当時は最先端だったそのシステムも、今や「レガシー」という言葉の重みを体現する存在へと変わっています。

老朽化したシステムが強いる「見えないコスト」

A社の現場では、システムの老朽化が日々の業務を蝕んでいました。最も深刻だったのは、操作画面の応答速度の低下です。朝の受注ピーク時になると、ひとつの画面を表示するのに10秒近くかかることも珍しくありません。営業事務の担当者は、顧客と電話で話しながら在庫を確認しようとしても、画面が切り替わるまで沈黙を余儀なくされます。「検索結果が出るまでに会話が止まってしまう」「処理待ちの間に別の作業をしようとして、結局どちらも中途半端になる」といった不満が、現場には渦巻いていました。

また、長年の改修を経て複雑化したシステムは、特定のベテラン社員にしか使いこなせない「属人化」の温床となっていました。新人が入社しても、画面の意味を理解して独力で入力できるようになるまで数ヶ月の教育期間を要します。さらに、基幹システムでカバーしきれない細かな業務を補うために、各部署で独自のExcelシートやAccessデータベースが乱立していました。基幹システムに入力した内容を、わざわざ別のExcelに転記するという二重入力が常態化しており、入力ミスによる誤出荷や請求漏れの発生も、管理職の頭を悩ませる大きな課題となっていました。

現場の切実な声は、単なる愚痴の域を超えていました。「この特定の処理をするときだけ、10年以上前の古い画面に強制的に戻されるのが一番つらい」「どのデータが最新で正しいのか、毎回誰かに確認しなければ進められない」といった状況は、業務の効率を著しく下げていました。レガシーシステムは、現場のモチベーションを削り取る大きな要因となっていたのです。

期待と不安が交錯する「刷新プロジェクト」の始動

こうした状況を打破すべく、A社では経営陣の主導で「基幹刷新プロジェクト」が立ち上がりました。当初の目的は、あくまでハードウェアの保守期限切れに伴う「老朽化への対応」でした。しかし、プロジェクトが動き出し、各部門へのヒアリングが始まると、事態は思わぬ方向へ転がり始めます。

長年不便を強いられてきた現場からは、堰を切ったように要望が噴出しました。「今の使い勝手を変えずにウェブ化してほしい」「スマートフォンからも在庫を見られるようにしてほしい」「周辺のExcel業務をすべて統合してほしい」といった要求が、次々とプロジェクトのリストに加えられていきました。情報システム部門も、「せっかく多額の投資をして刷新するなら、現行の課題をすべて解決し、最新のテクノロジーを盛り込みたい」という心理に陥ります。

結果として、プロジェクトのスコープは際限なく広がり、要件定義の段階で当初想定していた予算の数倍に膨れ上がる見積もりが提示されました。開発期間も数年単位の大計画となり、経営陣からは「これほどの巨額投資をして、本当に成功するのか」「完成する頃にはビジネス環境が変わっているのではないか」という強い懸念が示されました。要件の肥大化は、プロジェクトそのものを頓挫させるリスクとなっていたのです。

要件が肥大化する構造的要因

なぜ、A社の刷新計画はこれほどまでに膨らんでしまったのでしょうか。そこには、多くの企業に共通する構造的な問題が潜んでいました。

まず、現場の長期にわたる不満の蓄積があります。長年、改善を後回しにされてきた現場にとって、刷新は「最初で最後のチャンス」に見えました。そのため、現在の不満を解消するだけでなく、将来の理想までを一度に叶えようとする力が働きました。次に、部門ごとに最適化された要求の衝突です。営業、製造、物流、経理の各部門が自部署の利便性のみを追求した結果、システム全体としての整合性が失われ、機能が重複・複雑化していきました。

また、「現行踏襲」という名の思考停止も要因のひとつです。業務ルールそのものを見直すのではなく、古くなった現行システムの挙動をそのまま新システムに再現しようとしたことで、不必要な複雑さが引き継がれようとしていました。さらに、最新のDX(デジタルトランスフォーメーション)を意識するあまり、今のA社の実力や業務フローに合わない高度な機能まで、無理に詰め込もうとする過剰な理想主義も見られました。

「全部を一度に作り直す」というアプローチは、一見すると合理的で美しい理想に見えます。しかし実際には、移行対象が多すぎると開発難易度は飛躍的に高まり、テストの抜け漏れやデータ移行の失敗といった致命的なトラブルを招きやすくなります。特に、移行コストが高い一方で、現状でも大きな支障なく動いている周辺機能まで無理に刷新の輪に巻き込むと、投資対効果は急速に悪化します。

「現実解」への転換

プロジェクトが停滞する中で、私たちがA社に提案したのは、理想論ではない「実行可能な再構築案」でした。システムのすべてを一度に置き換えるのではなく、真に刷新が必要な領域と、現行を活かすべき領域を峻別するアプローチです。

私たちはまず、A社の全業務を「競争力の源泉となる中核業務」「定型的な管理業務」「特殊だが頻度の低い周辺業務」の3つに分類しました。そして、すべての要望を鵜呑みにするのではなく、業務全体を俯瞰した上で刷新対象を大胆に絞り込むことを強く推奨しました。

次章では、この「選択的刷新」を具体的にどう実現したのか。その鍵となった「楽々フレームワーク」の活用と、品質を一切妥協せずに工数を圧縮するための設計思想について詳しく解説します。

楽々フレームワークで実現した「7割刷新」

刷新プロジェクトの停滞を打ち破るために、私たちが提案したのは明確な方針でした。「変えるべき中核業務は楽々フレームワークで再構築し、移行負荷の高い機能は現行を活かしながら連携する」というものです。この「7割刷新」とも呼べる戦略こそが、A社が直面していたコストとリスクのジレンマを解決するための道となりました。

楽々フレームワークの採用

今回のプロジェクトで「楽々フレームワーク」を採用したのは、単なる開発の高速化だけが目的ではありません。基幹システムに求められる高度な品質と、長期にわたる安定稼働を確保するための「導入判断」でした。

楽々フレームワークは、業務システムに必要な画面構成、入力制御、データ連携、ワークフローといった要素が部品化されており、これらを組み合わせて構築する手法をとります。これにより、開発者ごとのスキルのばらつきを抑え、システム全体の品質を一定水準以上に保つことが容易になります。フルスクラッチでの開発は自由度が高い反面、細かなバグが混入しやすく、保守が属人化するリスクを伴います。一方、このフレームワークを使うことで、開発ルールを標準化し、将来にわたって保守しやすいシステムを作り上げることが可能になりました。

「7割」を刷新し「3割」を残す

私たちはA社の業務を徹底的に精査し、刷新の対象を全体の約7割に絞り込みました。この「7割」には、受発注や在庫管理といった、現場が毎日使い、かつ応答速度の改善が劇的な効果を生む中核業務が含まれます。逆に、残りの「3割」として現状維持を決めたのは、年に数回しか使わない特殊な集計機能や、特定の古い帳票出力機能などです。これらは、新システムに作り直すコストに対して得られるメリットが少ないと判断しました。

この「全部を変えない」という決断には、大きな勇気が必要でした。しかし、全置換を避けることでプロジェクトのスケジュールは大幅に短縮され、予算も当初の肥大化した見積もりから現実的な範囲へと収まりました。何より、刷新効果が大きい領域にリソースを集中させることで、品質とスピードを両立させることができました

新旧共存の境界設計

システムの一部を残しつつ新しい基盤を構築する場合、最も重要になるのが「新旧システムの連携」です。私たちは、どちらのシステムがどのデータの主導権(マスター)を持つのか、その境界線を曖昧にせず厳密に設計しました

新システム側が業務の主導権を持つ領域では、洗練されたインターフェースと高速な処理を提供します。一方で、既存システムに残した領域との間には、強固な連携インターフェースを構築しました。データの受け渡しタイミングや整合性のチェックルールを詳細に定義することで、「新旧どちらのデータが正しいのかわからない」といった混乱を防ぐ工夫を凝らしました。この境界線の明確化こそが、ハイブリッドなシステム構成を成功させる鍵となりました。

現場を置いてけぼりにしない「業務中心」のプロセス

設計の段階では、単に今の画面を再現するのではなく、A社の複雑な業務パターンを一つひとつ紐解いていきました。全国の拠点ごとに微妙に異なる商習慣や、例外的な処理フローをすべて洗い出し、新しいシステムがそれらをどう吸収すべきかを検討しました。

現場からは、「全部を変えられると操作を覚えるのが大変で逆に混乱する」「今の業務のこの部分は、理屈抜きでこの形でないと回らない」といった切実な声が寄せられました。私たちはこれらの声を無視するのではなく、残すべき業務と変えるべき業務の線引きを論理的に説明し、納得感を得ながら進めました。結果として、現場からは「新画面は操作が統一されていて非常に覚えやすい」という評価を得ています。

また、現場の負荷を下げるための具体的な工夫として、AIを活用した入力補助機能も実装しました。過去の取引データから最適な入力候補を提示したり、摘要欄の文章を補完したりする機能です。これは単なる目新しさのためではなく、入力の迷いを減らし、現場の作業時間を物理的に削減するための実利的な実装として位置づけました。

品質を最優先する開発体制

工数を圧縮しながらも、品質に関しては一切の妥協を排しました。私たちは以下の4つの柱を中心とした品質管理体制を敷きました。

  1. 業務パターンごとの徹底した設計レビュー:単なる機能確認ではなく、実際の業務シナリオに沿って設計に矛盾がないかを検証しました。
  2. 連携仕様の粒度を揃えた定義:新旧システム間、および周辺システムとのデータ連携において、エラー時のリトライ処理まで含めた詳細な仕様を固めました。
  3. 段階的な確認プロセスの導入:単体テスト、結合テストに加え、実際の業務を模した「業務シナリオテスト」を早期から繰り返し実施しました。
  4. システム間連携部の重点テスト:不整合が最も起きやすい境界部分に対して、異常系のケースを含めた集中的なテストを敢行しました。

「品質重視」と「フレームワークによる効率化」は決して相反しません。むしろ、標準化しやすい基盤を活用することで、無駄な実装作業を減らし、その分をより本質的なテストや業務検証に時間を割くことが可能になりました。

A社が必要としたのは、単なる新しい画面ではありません。それは、操作ストレスの解消、作業効率の劇的な向上、そして次なるステップであるCRM連携へと踏み出すための、強固で安定した土台です。そしてシステム刷新において重要だったのは、作る機能の量を増やすことではなく、品質が確実に出る形に勇気を持って絞り込むことでした。

性能改善のその先へ

基幹システムの刷新が完了し、新たな運用が始まってから数ヶ月。A社のオフィスには、以前とは明らかに異なる活気が生まれていました。かつては画面の応答を待ち、沈黙の中で眉間にしわを寄せていた営業事務の担当者たちが、今ではスムーズに顧客と会話を続けながら、流れるように受注処理を進めています。業務のリズムが途切れなくなったことで、職場全体のストレスが劇的に軽減されました。

現場の実感に裏打ちされた性能改善

刷新後の効果は、現場の感覚だけでなく、明確な指標としても現れました。ここで、A社のプロジェクトにおける成果をモデル値として示します。

  • 主要画面の平均表示時間:刷新前の約8秒から、刷新後は2秒未満へと短縮されました。これにより、1日あたり数千回行われる画面遷移の「待ち時間」がほぼ解消されました。
  • 受注登録にかかる平均作業時間:1件あたり15分前後を要していた作業が、6分前後へと半減しました。AIによる入力補助と、画面遷移の最適化が大きく寄与しています。
  • 問い合わせ対応時の検索時間:顧客からの在庫確認や納期回答に要する時間は、10分前後から3分前後へと短縮されました。
  • 月次のデータ手戻り件数:入力制御の強化とチェック機能の実装により、入力ミスによる修正作業が従来比で50%以上削減されました。
  • 新人の独力対応開始までの期間:操作性が統一され、教育コストが下がった結果、新人が実務をこなせるようになるまでの期間が従来の約半分に短縮されました。

これらの数値は、単に「速くなった」ことを示すだけではありません。浮いた時間を、顧客への手厚いフォローや複雑な案件の検討に充てられるようになったことこそが、真の成果です。現場からは「前より速いのはもちろん、何より使いやすいと感じる。システムが自分の仕事を邪魔しなくなった」という声が上がっています。

経営への影響

情報システム部門や経営層にとっても、今回の刷新は大きな安心材料となりました。特に、新旧システムを連携させた複雑な構成でありながら、切り替え後の致命的なトラブルが皆無だったことが高く評価されました。

これには、開発工程における徹底したテストが功を奏しています。データ整合性の確認はもちろん、境界値テストや例外ケースの網羅、そして実際の業務を想定したシナリオテストを念入りに行いました。管理職からは「品質を最優先したことで、最も懸念していたシステム切り替え直後の混乱が最小限で済んだ。この安定感が最大の価値だ」という言葉をいただいています。

また、新旧連携部分のテストを重点的に詰めたことで、将来的な機能拡張に対する不確実性も払拭されました。品質を重視して構築したシステムは、運用の安定性だけでなく、変化への耐性も兼ね備えています。

刷新は次のステージへ

A社のプロジェクトは、基幹システムの刷新で終わるものではありません。新たな基幹システムが完成したことで、「次の改革」が現実味を帯び始めました。その筆頭が、CRM(顧客関係管理)システムとの高度な連携です。

これまでのレガシー基幹ではデータの取り出しが困難で、顧客ごとの詳細な購入履歴や要望を営業活動にリアルタイムで活かすことができませんでした。しかし、今回の刷新によってデータの構造が整理され、他システムと連携するための強固なAPI基盤が整いました。

今後の展望として、A社では以下の取り組みに着手しています。

まず、顧客情報と基幹情報のリアルタイム接続です。基幹の在庫・出荷データとCRMを連携させ、営業担当者が外出先からでも最新の納期状況を顧客に回答できる環境を構築します。次に、問い合わせ対応の高度化です。サポート部門が過去の修理履歴や購入パターンを基に、先回りした提案を行える体制を整備します。さらに、蓄積された良質なデータを分析し、需要予測や最適な在庫配置のシミュレーションに活用することで、AI活用のさらなる拡大を目指します。

このように、刷新で終わらずCRM連携という次のフェーズへスムーズに進めたのは、ひとえに「品質ある土台」を作ったからに他なりません。基幹刷新はゴールではなく、企業が真のDXを推進するためのスタートラインです。

楽々フレームワークがもたらした価値

最後に、今回の取り組みにおける楽々フレームワークの役割を振り返ります。このフレームワークの最大の貢献は、開発の効率化以上に「実装品質の平準化」にありました。標準化されたルールで構築されたシステムは、将来的に担当者が変わっても構造を把握しやすく、継続的な改善が可能です。

速度、安定性、そして保守性。これらすべての要素が高い次元でバランスされたことで、A社は「レガシーの呪縛」から解き放たれました。このプロジェクトの真の価値は、古いシステムを新しくしたことそのものではありません。変化の激しい市場環境において、次なる変革に即座に対応できる「品質ある武器」を手に入れたことにあります。

私たちが提供する価値とは

今回の取り組みを要約すると、以下の3点に集約されます。

  1. 全体最適を阻む壁の排除:レガシー基幹の問題は、単なる古さではなく、データの分断や現場の疲弊といった「全体最適を阻害すること」にありました。これを直視することが刷新の第一歩となりました。
  2. 楽々フレームワークによる品質と効率の両立:すべての機能をフルスクラッチで構築するのではなく、定評あるフレームワークを活用して標準化を進めたことで、工数圧縮と高い実装品質を同時に実現しました。
  3. 次なる変革への土台:連携部分を含めた徹底的な設計と検証により、刷新直後からCRM連携という次のフェーズへ進める「品質ある土台」が完成しました。

基幹刷新は、決して「全部を捨てるか、我慢して使い続けるか」という二択ではありません。重要なのは企業の将来を見据え、変えるべき部分を確実に見極め、そこに最高品質の技術を投入することです。

複雑な業務パターンを丁寧に読み解き、現場の使い勝手を損なうことなく、品質を軸にした現実的な解を設計し、実装する。この伴走こそが、私たちギグワークスクロスアイティが提供する最大の価値です。私たちはこれからも技術の力で企業の歩みを支え、不確実な未来を確かなものへと変えていくパートナーであり続けます。

この記事を書いた人

ビジネス・テクノロジスト 貝田龍太