基幹システム再構築の失敗しない進め方とは？現役エンジニアが解説！｜東京のWEB制作会社・ホームページ制作会社｜株式会社GIG

BLOG

ブログ

基幹システム再構築の失敗しない進め方とは？現役エンジニアが解説！

2022-09-11 制作・開発

「2025年の崖」が指摘されはじめてから、DXを念頭に置いた基幹システムの再構築を検討する企業が増加傾向にあります。

基幹システムの再構築にはさまざまなステップがあり、多くのコストが必要となります。しかも仮に失敗すれば、事業活動全体に影響が及び、「全社が機能不全に……」といった事態に発展する可能性があります。

つまり、基幹システムの再構築プロジェクトに失敗は許されません。

では、どうすれば失敗せずに基幹システムの再構築を進めることができるのでしょうか？　今回は、基幹システムの再構築における失敗しない進め方や再構築検討のタイミングなどに焦点をあて、エンジニア目線で解説します。

基幹システムとは

まずは基幹システムのキホンから確認しましょう。基幹システムとは、企業経営の根幹となる以下のような業務を管理するシステムのことを指します。

・販売管理
・購買管理
・在庫管理
・会計管理
・人事管理

これらの業務管理システムが合わさって基幹システムとなり、企業の事業展開を支え続けます。現代社会においては、基幹システムがなければ企業は経営活動を維持することができません。

そのため、企業にとって基幹システムは必要不可欠であり、替えが効かない代物でもあります。

基幹システムはなぜ再構築が必要？

企業経営に欠かせない基幹システムですが、昨今基幹システムの再構築の機運が高まっています。その背景には、経済産業省が2019年3月に発表したDXレポートにて、「2025年の崖」を指摘したことが挙げられます。

2025年の崖とは、複雑化・老朽化・ブラックボックス化した既存のシステムを使い続けた場合、国際競争力の低下や経済の停滞などが想定され、2025年以降に膨大な損失を出すという指摘です。2025年までに予想されるIT人材の引退やサポート終了などによるリスクの高まりなどが、この停滞を引き起こすとされています。

DXレポートでは、古い基幹システムを「レガシーシステム」と呼び、DXの観点からも基幹システムの再構築を促しています。

レガシーシステムがDXの足かせとなっている原因は、システムのブラックボックス化です。筆者も経験がありますが、大企業の基幹システムは本当に複雑です。細かい修正をしたはずが全体に影響を与えてしまうケースも多く、ドキュメントが整備されていたとしても、細部までシステムの全容を把握しているエンジニアは皆無。

こうしたシステムの肥大化や複雑化は、柔軟かつスピード感をもって情報連携を行うDXの実行に悪影響を及ぼします。

また、レガシーシステムによく使われているメインフレームで動作するシステムでは、COBOLなどの言語を使って開発しています。

しかしCOBOLの知識を持つ技術者は年々少なくなってきています。メインフレームのレガシーシステムから新しいシステムへ再構築するためには、COBOLの知識があるエンジニアが不可欠ですが、対応できるエンジニアは今後ますます減っていく見込みです。

基幹システムを再構築するなら、素早い決断が求められています。

基幹システム再構築を検討すべきタイミング

基幹システム再構築のタイミングは、一般的に「業務の変化によって既存システムでの対応が難しくなった時」がタイミングのひとつだといわれています。

業務とシステムが乖離してくると、システムで対応できない業務を従業員がExcelや他のツールを活用して補うケースが多くなります。対応のために本来すべき業務が後回しになることで、生産性の低下にもつながってきます。

システムというものは、本来は業務の生産性や効率性を上げるために存在するべきですが、業務に悪影響を及ぼしはじめたら本末転倒です。

時代の急速な変化にシステムが追い付いていない状態に加え、現場の手間が増えてしまっている状況が発生している場合、システムの再構築を検討すべきといえます。

失敗しない基幹システム再構築の進め方

基幹システムの再構築で失敗しないためには、5つのフェーズを経て再構築を行うのが良いでしょう。順を追って確認します。

手順1. 現行のシステム状況を把握する

まずは現行の基幹システムの状況を把握することが何よりも大切です。現状把握が徹底されていないと、予算やスケジュールなど再構築プロジェクト全体の規模感が掴めません。

現状把握するうえでまず行うべきことは、「現場へのヒアリング」です。それぞれの部署のスタッフに聞き取り調査を行い、業務上のボトルネックや他部門との連携で時間がかかっている業務などをヒアリングしていきましょう。

同時に、システムの棚卸しも行います。ハードウェアやソフトウェアなどシステム資産の現状把握に漏れがあると、再構築時に無駄なコストが発生する可能性があるためです。

ヒアリングとシステム資産の棚卸しは、再構築時の必須ポイントです。

手順2. ビジョンを策定し、課題を洗い出す

次に具体的なビジョンと課題の洗い出し作業に移ります。この際は「システム」「現場」「経営」の3つの観点からビジョンを策定することが求められるため、広い視野が必要です。

・ヒアリングで把握した、業務上のボトルネックやニーズを解決できるか
・急速な時代の変化に対応する柔軟性があるか
・DXに対応でき、他のツールなどとの連携は十分に取れるか
・経営計画は意識できているか
・システムの保守、運用を行う人材は確保できるか

基幹システムは数十年単位で使われる代物です。目先の現場要求ばかりを組み込むのではなく、長期的な利用を想定した目線も必要です。今後導入するかもしれないツールなどの互換性を意識しておくことも必要でしょう。

手順3. 開発方針を決める

ビジョンが固まってきたら、具体的な開発・移行方針の検討作業に入ります。大きく分けて2種類の方法があるので、自社の状況に合わせて最適な方法を選びましょう。

【ゼロから再構築する方法（リビルド）】

ビジョン策定により、システムの設計自体を大幅に変える必要が生じた場合には、ゼロから再構築することになるでしょう。

ゼロから再構築する手法には、「スクラッチ開発」と「パッケージ開発」の2通りの開発手法が存在します。

スクラッチ開発とは「パッケージソフトウェアを使わずに、ゼロからシステムを構築する手法のこと」を指し、パッケージ開発は「パッケージソフトウェアを、自社の運用に適した形でカスタマイズする手法のこと」を指します。

採用する手法によって、策定したビジョンや予算、現場の要求を解決できるかが変わってきます。社内での十分な検討が必要でしょう。

【新環境に移行する方法（マイグレーション）】

現行のシステムを活かした形で、新環境に移行する方法を「マイグレーション」と呼びます。

「ゼロから作り直すほどではないが、改修したいポイントがいくつかある」という状況の場合、マイグレーションでシステム全体の生産性や保守性を向上させることも可能です。

なお、近年注目されているクラウド環境への移行もマイグレーションに含まれます。

手順4. システムを開発・移行する

開発方針が確定すると、いよいよシステム開発・移行作業のスタートです。この際は、開発会社やプロジェクトチームと密に連絡を取り合うことが大切です。

マイグレーションする場合には、現行システムの仕様把握や利用状況の明確化は欠かせません。マイグレーションなら作業はすんなり終わると思われがちですが、油断は禁物です。

移行スケジュールを過小に見積もってしまうと、手戻りの量によってはスケジュールに大幅な遅延が発生してしまいます。ある程度の余裕を持ったスケジュールを組むように心がけましょう。

また、新システムが完成したらデモ環境を用意して移行テストを行いましょう。移行テストはシステムの品質を担保する重要なフェーズです。「クリアすべきライン」を作成し、品質の目標をチーム全体で明確化しておくことが重要です。

手順5. システムを保守・運用する

開発・移行作業が終了すれば、保守・運用フェーズに移ります。本番運用開始からしばらくは問い合わせが殺到するので、チームのメンバーを中心に対応に追われるでしょう。影響を最小限に抑えるため、以下のような対応をしておくのも有効です。

・何名かの現場スタッフにデモの段階で触れてもらう
・改善箇所を事前に周知しておく
・予想される問い合わせ内容を事前にリストアップする
・問い合わせ内容をチーム内で共有する

混乱が長引くと社内に不満が溜まってしまう恐れがありますので、上記のポイントを中心に保守・運用方針も明確化しておくことが大切です。

基幹システムの再構築で失敗しないための注意点

基幹システムの再構築には多額の予算も必要なので、失敗は許されません。失敗しないためにも、最低限の注意点はしっかり確認しておきましょう。

注意点1. 経営・事業計画からゴールを設定する

経営計画や事業計画などを含めた会社の将来的なビジョンを確認し、そこから落とし込む形で基幹システム再構築の目的・ゴールを設定するようにしましょう。

基幹システム自体は、会社のビジョンを実現するための仕組みや手段にほかなりません。

会社のビジョンによっては、現状の業務フロー自体を変更する必要も出てくるでしょう。それを見据えてシステムの再構築を行わなければ、業務にそぐわないシステムになってしまう可能性があります。

ライフサイクルである10年後のビジョンを反映させた「目的・ゴールの明確化」が大切です。

注意点2. 再構築のメリットをすぐに感じられないことも

新しい基幹システムに移行したとして、すぐに全従業員が再構築のメリットを感じるとは限りません。部門によっては「従来の基幹システムの方が良かった」などの不満が出ることも十分にあり得ます。

ですが、そういった不満がなるべく出ないよう、事前に調整しておくことも必要です。進め方の部分で「ヒアリングは必ず行いましょう」と書きましたが、きちんとヒアリングを行うことで、部門間でバランスの取れた基幹システムを再構築することができます。

それでも、すべての経営陣や従業員が新システムを使いこなすまでには、想像以上の時間を要する可能性があることも意識しておきましょう。

注意点3. 開発会社の選定が重要

再構築する際には、開発会社の選定は重要な作業となります。DXも念頭に置くと、単なるシステム移行だけでは2025年の崖をクリアできません。あわせてDXも最大限行いたい場合は、ビジネスモデルなどの知識がある開発会社を選ぶことが求められます。

ただし、ビジネスモデルなどの知識がある開発会社だからといって、丸投げするのはNG。開発会社に一任してしまうと、自社が求めているビジネスモデルとの認識にズレが生じる可能性があります。その場合、自社に合わない基幹システムが出来上がってしまうので注意が必要です。

また、基幹システムにおいては開発・移行だけではなく、その後の保守・運用面も考えたうえで、適切な依頼先を探すことも重要です。