基幹システムを再構築するには？手法と失敗を防ぐポイントを解説！
こんにちは。Wakka Inc.のWebディレクターの安藤です。
企業の競争優位性を保つためには、基幹システムの再構築が急務と言われています。
しかし、ビジネスの根幹を支える基幹システムは止めることが許されないため、リスクのある再構築にはなかなか踏み切れない方も多いのではないでしょうか。この記事では基幹システムを再構築する上で知っておきたい
- 基幹システムを再構築するメリット
- システム再構築の手法
- 失敗を防ぐポイント
について詳しく解説していきます。システム再構築を成功させるために、ぜひ参考になさってください。
基幹システムの構築ならWakka Inc.
基幹システムの構築を得意としたエンジニアが多数在籍しており、システム全体の設計から構築まで丁寧にサポートします。基幹システム構築のちょっとした疑問から お見積もり依頼まで、お気軽にお問合わせください
基幹システムとは
そもそも、基幹システムとはどういったものを指すのでしょうか。まずは基幹システムの定義や、混同しやすいERPや情報系システムとの違いを確認しておきましょう。
基幹システムの定義
企業のビジネスで、根幹となる業務を支えるのが基幹システムです。
わかりやすくまとめると、システムが止まるとビジネスが継続できなくなってしまい、企業経営にとって大きな打撃となるのが基幹システムと言えるでしょう。
したがって、基幹システムには安定性の高い堅牢なシステムが求められるのです。企業の業種によっても変わりますが、一般に次のようなシステムが基幹システムと呼ばれます。
- 販売管理システム
- 生産管理システム
- 在庫管理システム
- 物流システム
- 財務会計システム
- 人事給与システム
基幹システムは、企業がビジネス活動をする上で欠かせないシステムであることがわかるでしょう。
ERPや情報系システムとの違い
基幹システムと同様によく聞かれるのがERPや情報系システムです。ERPや情報系システムは、基幹システムとどう違うのでしょうか。
ERP
ERPとはEnterprise Resource Planningの略で、直訳すると企業が持つ資源の統合的な管理という意味合いになります。
日本語では統合基幹業務システムと呼ばれるように、複数の基幹システムがひとつのパッケージシステムになったものです。
情報系システム
情報系システムは、日々の業務でコミュニケーションや情報共有を円滑にするためのシステムです。次のようなシステムやツールが該当します。
- メールシステム
- グループウェアシステム
- スケジュール管理ツール
- Web会議・チャットツール
すべての社員や関係者が共通で使うプラットフォームのため、止まってしまうと業務に影響は出ますが、代替手段を用いて業務を継続できるのが基幹システムとの違いでしょう。
基幹システムの再構築が必要な理由
基幹システムの再構築が急務であるとの声が最近よく聞かれます。基幹システムの再構築はなぜ必要なのでしょうか。
ひとつずつ見ていきましょう。
システムのレガシー化
前述したとおり、基幹システムは企業の重要な業務を支えているため、安定性が高く堅牢であることが求められます。そして、システムが稼働している間は常に運用・保守の業務が発生します。
業務の使い勝手を向上させ、不具合を改善するために、保守業務によってシステムの改修が重ねられていくのです。
長年、改修が重ねられた結果、いわゆるスパゲッティーコード*と呼ばれる複雑で難解なソースコードになることが多く、保守業務の難易度は年々高まります。
保守業務を担当できる技術者も時間の経過とともに減っていき、やがてシステムがブラックボックス化してしまう恐れもあるでしょう。
ブラックボックス化したシステムは今後、企業がITに投資するにあたって、様々な点で足かせになる可能性があります。脱レガシー化によって、IT投資の足かせを解消することが求められているのです。
※スパゲッティーコード……=スパゲッティープログラム。命令が複雑に入り組み、処理の流れや構造が把握しにくくなっているプログラム。
ランニングコストの増大
ランニングコストの増大も、レガシー化が進む中で起きてくる問題です。長年の保守業務によって、複雑で難解になったシステムを改修するのは簡単ではありません。
改修を加えることで、思わぬところに影響が及ぶリスクが高くなっているため、調査やテストにかける工数がかさんでくるのです。
さらに、システムの安定稼働期を過ぎると障害対応も増えてくるでしょう。稼働年数が長くなるほど、運用・保守にかかるランニングコストが増大するのです。
DX推進の足かせ
今、レガシー化した基幹システムが、DX推進の足かせになっている問題があります。
DXを推進する上で多くの課題がありますが、レガシー化した基幹システムがDX推進の足かせになっているのは、中でも早急に解決すべき大きな課題でしょう。
課題を克服してDXが推進できなかった場合には、2025年以降、年間最大12兆円の損失が生じると言われています。この試算は経済産業省のDXレポートで公表されているもので、レポートの中では「2025年の崖」と表現して警鐘を鳴らしています。
参考：経済産業省『DXレポート』
そして、2025年の崖を回避する対策のひとつが基幹システムの再構築なのです。
DXの推進により、企業が競争上の優位性を確立するためには、基幹システムの再構築が必要と言えるでしょう。
基幹システムの再構築とDXの推進は深く関わりのあるテーマです。もしご興味があれば下記の記事も合わせてお読みください。
基幹システムを再構築するメリット
ここまでは、基幹システムの再構築が必要な理由を解説してきました。
ところで、基幹システムの再構築にはどのようなメリットがあるのでしょうか。このパートでは、基幹システムを再構築するメリットについて解説します。
データの可視化と一元管理
再構築の手法にもよりますが、個別の業務システムごとではなく、基幹業務全体で一貫したシステムに再構築すれば、データを集約して一元管理できます。
例えば、複数の業務システムで同じ内容のマスターデータを保持するなどが挙げられます。一貫したシステム再構築が実現できれば、マスターデータの保持方法を最適化でき、一元管理できるようになるのです。
マスターが一元管理できればデータの不整合を防げ、メンテナンスの手間も省けるため、業務も効率化できるでしょう。
またデータを一元管理すれば、特定のシステムにログインしないとデータが参照できないといったことがなくなり、データの可視化と全体共有が進みます。
システム運用業務の負荷軽減
現状の業務に合わせて基幹システム全体を再構築できれば、複雑になっていたシステムが簡素化されます。
システムが簡素になることで、システム改修などの保守業務で障害を起こすリスクが減るため、システム運用業務の負荷軽減が期待できるのです。
また、システムに利用される技術が再構築によって新しくなると、保守作業に対応可能な技術者も多くなります。
既存機能の見直し、新機能の追加、バージョンアップなどの大がかりな開発が発生しても、開発ベンダーに依頼できる可能性が高くなるでしょう。
新しい技術への対応
新しいハードウェアやOS、ミドルウェアをもとに基幹システムを再構築すると、新しいデジタル技術の活用が促進されます。
レガシー環境では利用できなかった様々な新しいデジタル技術との接続が、システム環境が新しくなることで可能になるからです。
例えば、IoTを利用して収集されたデータやAIで分析したデータなど、DX推進に役立つデジタル技術を活用できれば、企業の競争優位性を確立するのに役立てられるでしょう。
新しい技術に対応できることは、DXを推進する上でも大きなメリットになります。
マイグレーションと再構築の違い
ここからは、実際にシステムを再構築する際の手法について解説します。システムを再構築する手法は大きく分けて下記の2つがあります。
- マイグレーション
- 再構築（リビルド）
それぞれの手法について見ていきましょう。
マイグレーションとは
マイグレーション（Migration）とは、直訳すると移住、移転などを意味します。
つまり、現行システムのソフトウェアやデータなどを、そのまま別の環境へ移行するのがIT用語でいうマイグレーションです。
マイグレーションは、システムの稼働環境を別のサーバーなどに移行しますが、ソフトウェア資産はそのまま利用するのが特徴です。
例えば、大型のメインフレームで稼働していた基幹システムのソースコードを、UNIXやWindowsといったオープンプラットフォームへ移行するなどが挙げられるでしょう。
現行システムのソフトウェア資産をそのまま流用できるため、開発コストを抑えられ、品質も担保できるのがメリットです。
ただし、現行システムの資産を流用するため、柔軟な設計変更はできず、基本的には現行システムの課題も抱えたままになります。
再構築（リビルド）とは
再構築（リビルド）とは現行システムの資産を流用するのではなく、新しいシステム環境に適合したシステムを1から再設計・再開発する手法です。
例えば、COBOLなどメインフレームのプログラム言語で構築されていた現行システムを、Javaなどのオブジェクト指向言語やローコードツール（ノーコードツール）を使用して再構築することが挙げられます。
1から再設計・再開発をするため、現行システムの再構築といっても、開発ボリュームは新規システムの開発と同等と言えるでしょう。
現行システムの資産を流用しないため、新しいシステム環境に適合し、かつ最新の業務要件を取り込んで柔軟に設計できるのがメリットです。
ただし、前述したように開発ボリュームが新規開発と同等のため、開発コストもマイグレーションと比べて膨大になるデメリットがあります。
マイグレーションと再構築の違い
ここまでご紹介したマイグレーションと再構築（リビルド）の特徴や違いを、比較表でまとめました。
| 比較項目 | マイグレーション | 再構築（リビルド） |
|---|---|---|
| 手法概要 | 現行システムのソフトウェアやデータなどを、そのまま別の環境へ移行する | 1から再設計・再開発を実施し、新しいシステム環境に適合したシステムを構築する |
| 移行環境 | 現行システムとは別の新しい環境へ移行する | 現行システムとは別の新しい環境へ移行する |
| 既存のソフトウェア資産 | プログラムはそのまま移植する | プログラムは再利用せずゼロから開発する |
| 既存の データ移行 | プログラムをそのまま再利用するため、単純な移し替えになるケースが多い | 仕様の見直しが多いと複雑な変換が必要になる |
| 安全性 | 【高い】 既存のプログラムを移植するため、現行システムと同等の品質を担保しやすい | 【低い】 プログラムは新規開発なので、現行システムと比べ品質が劣化するリスクがある |
| 開発費用 | 【安い】 設計・開発の工程が大きく省けるため、開発費用を抑えられる | 【高い】 プログラムは新規開発なので、新規システムを開発するのと同等の開発費用がかかる |
| 仕様変更の自由度 | 【低い】 既存のプログラムを移植するため、ほとんど仕様変更はできない | 【高い】 1から再設計・再開発するため、業務に合わせてある程度の仕様変更はできる |
| 適した目的 | ・OSやミドルウェアのバージョンアップに伴う移行 ・重要性の高いシステムの安全な移行 | ・業務要件の見直しに伴うシステムの刷新 ・DXの推進に向けたデジタル技術の積極的な活用 |
どちらの手法を選ぶのが適切かは、システム再構築の目的によって変わります。目的を明確にした上で「どちらが目的を果たすのに適しているか？」を慎重に比較検討なさってください。
システム再構築の失敗を防ぐポイント
システムの再構築は、現行システムをベースに開発を進めるため、安易に考えがちです。
しかし、実際には思っているほど簡単ではないため、慎重に進めないと失敗は避けられません。このパートではシステム再構築を進める際に、失敗を防ぐポイントについて詳しく解説します。
現行システムの仕様調査
システム再構築のプロジェクトを進めるにはまず、現行システムの仕様調査が必要です。
現行のシステムに実装されている機能を洗い出し、それぞれの機能の仕様と振る舞いについて詳細に把握しておかないと、再構築するシステムの仕様が決められません。
現行システムの仕様を調査する際には、まず仕様書や設計書などのドキュメントを参照することが多いでしょう。
しかし、注意しておきたいのはドキュメントの正確性です。
長年利用されてきたシステムは、保守作業やシステム改修などでドキュメントも改定が繰り返されているでしょう。
ドキュメントが常に正しく更新されていれば問題ないのですが、実際にはソースコードとドキュメントの状態が一致していないことが多いのです。したがって、ドキュメントだけに頼って仕様を調査するのは危険です。
- ソースコードと設計書を突き合わせて記載漏れがないかチェックする
- ソースコードを解析して詳細な設計内容をドキュメント化する
などの工夫で、再構築の対象を精査することが重要です。
現行システムの利用実態把握
現行システムの利用実態を調査して把握しておくことも欠かせません。なぜなら、システムの仕様だけを把握していても、次のような実態は見えてこないからです。
- 現行システムに実装されている機能のうち、いくつかはユーザーがほとんど使っていない
- 仕様書にシステムの性能要件が記載されているが、実際にはさらに良い性能で稼働している
現行システムの開発当初は要件に含まれていた機能が、実際に稼働してみるとほとんど使われないケースはよくあります。
使われていない機能は新システムでもそのまま構築するのではなく、本当に必要な機能か見極める必要があるでしょう。不要な機能であれば、廃止も検討するべきです。
また、仕様書にシステムの性能要件が記載されている場合、たいていは許容される限界値が定義されています。
例えば、ある機能の処理時間が1分以内と定義されていても、実際の処理は10秒で終わるなどはよくあることです。
実態を把握せず、仕様書の性能要件にしたがって新システムでは30秒かかる処理として再構築してしまうと、ユーザーからは、「前のシステムより性能が悪くなった」と評価されてしまうでしょう。
利用実態を把握できてはじめて、本当の要件が見えてくることもあるのです。
現行システムを調査する際には、システムの仕様だけではなく、利用実態もしっかり調査して把握しておくことが重要です。
業務要件の再定義
再構築するシステムの要件定義は、新規システムに比べて曖昧になる可能性が非常に高いので要注意です。
すでに稼働しているシステムがあって、実際に業務で利用されているため、ユーザーにヒアリングしても「現状の仕様をそのまま踏襲してほしい」といった程度で済ませてしまうことが多いからです。
要件を正確に定義せずに現状の仕様を踏襲しようとすると、人によって解釈が変わってくることもあるでしょう。
すると、認識の不一致が原因で重要な要件がゆがめられ、最終的にユーザーが求めている要件を満たせないかもしれません。
ユーザー企業と開発ベンダー間、開発ベンダーのプロジェクトメンバー内で認識の不一致が生まれないよう、現行システムから要件が変わらなくても、しっかり要件を再定義することが重要です。
業務部門の参加
要件定義の早い段階でシステムの利用実態を把握し、適切に業務要件を再定義するためには、業務部門のプロジェクト参加が必要です。
長年運用してきたシステムの利用実態は、ドキュメントに記録されていないことも多く、システム部門が調査しただけでは正確に把握するのが難しいからです。
業務部門のユーザーに開発の上流工程から参加してもらうことで、
- 利用実態からかけ離れたシステムを構築してしまう
- ユーザーとの認識不一致により、要件を満たさないシステムを構築してしまう
などのリスクを減らせるでしょう。
開発ベンダーのコントロール
システム再構築の際は、現行システムと新システムで開発ベンダーが変わることも多いでしょう。
開発プロジェクトは新システムのベンダーが中心になって進めることが多いのですが、新システムのベンダーだけでは解決が難しい課題が出てくることもあります。
課題解決のためには現行システムのベンダーに協力を依頼することも必要でしょう。したがって、システム再構築プロジェクトには現行システムのベンダーも参加し、プロジェクトに協力してもらうことが必要です。
新システムのベンダーの課題解決に協力してもらうだけでなく、
- 新システムへのデータ移行プログラムを構築する
- 新システムが段階リリースになった場合は現新システム間の中継処理を構築する
など、現行システムのベンダーでないと担当できない業務が発生することも出てくるでしょう。
現行システムと新システムで開発ベンダーが変わる場合、ベンダー間の利害関係が影響してくるため、ベンダー同士の調整に任せず、ユーザー企業（自社）が中心となってコントロールするのが重要です。
リスクマネジメント
システムの再構築には、実際にやってみないと見えないリスクが数多く存在します。
したがって、考えられるリスクをプロジェクト開始時に洗い出し、システム部門・業務部門・開発ベンダーなどの関係者間で共有しておくことが重要です。
また、洗い出したリスクは共有しておくだけではなく、顕在化したときの対応方針を関係者間で協議して、あらかじめ合意しておくべきでしょう。合意しておくことで、
- リスク対策に必要な予算の確保
- 関係者間で協力してリスクを減らす対策の実施
- リスクが顕在化した際の対応の明確化
など、リスクが発生した際のプロジェクトへの影響を最小限に抑えられるのです。
現行システムの深い理解と十分なリスク対策が成功のカギ
システム再構築でよくしてしまいがちなのが、現行システムを表面的にしか理解しないままプロジェクトを進めてしまうことではないでしょうか。
現行システムを深く理解せずに進めることで、プロジェクトの終盤になって詳細仕様の漏れや認識の食い違いが判明し、リカバリーのために多大な追加コストがかかるケースは非常に多いのです。
失敗を防ぐために、現行システムを入念に調査して深く理解しておくことは欠かせません。また、想定されるリスクを洗い出して事前に対策を講じておくことも大切です。
現行システムの調査と事前のリスク対策で、ぜひシステムの再構築を成功に導いてください。
【あわせて読みたい】おすすめ関連資料
●すぐに使えるRFPテンプレート｜システム開発用
＞システム開発のRFPについて、情報を埋めるだけで簡単に作成ができるテンプレートです。
●すぐに使えるRFPテンプレート｜サイトリニューアル用
＞サイトリニューアルの際に、テンプレートの情報を埋めるだけで簡単にRFPが作成できます。
●DX進め方ガイドブック
＞DXプロジェクトを検討している担当者の方に向けて、失敗しない社内体制の構築から開発リソース確保までを網羅して解説しています。
▼参考記事
学生時代にWebサイトを自作したことがきっかけでWebの世界に。制作会社でデザイン、WordPressテーマ開発の実務を経て、テクニカル・ディレクターとして大規模サイト構築のディレクションを経験。2021年からWakka Inc.の日本拠点でWebディレクターとして参画。最近はブロックエディタになったWordPressをもう一度、勉強しています。
