自社の基幹システム刷新で失敗しない進め方・ポイントとは？

近年における既存の基幹システムの老朽化に伴い、システム刷新を検討する企業が増えてきています。その一方で、「刷新したつもりが、業務効率がほとんど変わらなかった」「多額の投資費用を無駄にしてしまった」といった失敗事例も多く発生しているのが現状です。

そこでこの記事では、システム刷新の必要性や具体的な進め方、失敗しないためのポイントをご紹介いたします。

システム刷新とは、主に老朽化した基幹システムを新しくすることで、業務の生産性向上を図る取り組みを指します。既存の基幹システムの分析からはじまり、ベンダー選定、要件定義、システム実装といった流れで進めていくのが特徴です。

システム刷新は全社で取り組むプロジェクトのため、経営層はもちろん、IT部門や業務部門が連携し合いながら取り組むことがポイントです。

なぜ自社の基幹システムを刷新すべきなのでしょうか？ここでは、2つのポイントで解説いたします。

現在では、自社における既存の基幹システムが老朽化し、業務効率の低下や運用コストの肥大化を招いている事例が多々発生しています。経済産業省が発表した『DXレポート～IT システム「2025 年の崖」の克服と DX の本格的な展開～』によると、2025年時点で21年以上稼働している基幹系システムの割合が6割に上ると推計されているのです。

時代遅れになってしまった、いわゆる「レガシーシステム」を抱える企業においては、下記のような問題や課題が発生しがちです。

基幹システムが老朽化し、本来あるべき業務フローからかけ離れた状態になっていると、組織の硬直化や生産性の低下を招きます。結果、運用コストが肥大化したり、サービス提供のリードタイムが伸びてしまったりするでしょう。

近年、国が積極的に推し進めている「働き方改革」を実現するためにも、基幹システムの刷新は避けて通れない道です。

2018年に経済産業省が発表した『デジタルトランスフォーメーション（DX）を推進するためのガイドライン』を皮切りに、日本でもDXが積極的に推し進められるようになりました。DXとは、簡単にいうと「ITによって人々の生活がよりよい方向へ変化すること」を意味しており、企業においてもその重要性が取り沙汰されています。

DXにより、業務効率化やコスト削減を達成できるだけでなく、データやデジタル技術を活用して新しいビジネスモデルを生み出し、競争上優位を発揮することが可能になります。ただし、実際に実現するには、基幹システムにあるそれぞれのデータがシームレスに連携され、一つの情報として有機的に活用できるようになっていなければなりません。

基幹システムが部門や部署ごとに個別最適化されている状態だと、システム間の連携がうまく取れなくなってしまいます。結果として、データ活用によるビジネス機会を喪失してしまったり、経営判断が遅れたりする原因になってしまうのです。

まず、社内の重要なデータが蓄積されている「基幹システム」の刷新からはじめることで、自社のDX実現に近づけられます。

それでは、システム刷新を具体的にどのように進めればいいのでしょうか？ここでは、基幹システムの導入時に多くの企業が採用する「ERP」を例に、6つのステップに分けて解説いたします。

まずは、自社の既存基幹システムを分析します。既存のベンダーと協力しながら、下記の項目を洗い出しましょう。

• 過去のシステム改修履歴
• 現在の保守・メンテナンス状況
• システムに付随するドキュメント
• 要員の状況
• システム資産・構成
• 処理形式
• データ量・構造

加えて、自社で現在発生している業務課題を洗い出し、それがシステムのどの部分に起因しているのかを究明することも大切。ただし、老朽化・複雑化した基幹システムではなく、業務プロセス自体に原因がある可能性もあることを忘れないようにしましょう。

分析の段階で刷新すべき箇所を事前に明確にしておけば、のちの構想立案のステップでスムーズに進められます。

現状分析が完了したら、次に、「自社はどうあるべきなのか」「どのような方向性でシステム刷新を進めるべきなのか」を明らかにします。具体的には、IT部門、業務部門、経営層の3者間で議論を重ね、今後の方向性を明確にした「構想文書」を作成します。

構想文書においては、予算や機能要求、ベンダーの選定スケジュールといった刷新プロジェクトの大枠をまとめるのがポイント。一つ目に「社内で認識を統一させるため」、二つ目に「検討先ベンダーへ自社の期待を明確に伝えるため」に重要な書類です。

実際に作成する際には、5W1Hのフレームワークを用いて必要な情報を網羅するようにしましょう。

• When：ベンダー選定をいつまでに完了させるのか、新システムをいつまでに稼働させるのか
• Where：刷新プロジェクトをどこでおこなうのか
• Who：誰がプロジェクトにかかわるのか、各業務へ誰が責任を持つのか
• What：具体的に何を作るか、何の機能が必要なのか
• Why：なぜ刷新プロジェクトを実施するのか
• How：どれくらいの予算を検討しているのか

特に構想立案のステップでは、IT部門、業務部門、経営層の3者それぞれの思惑がある点を理解することが重要。たとえば、経営層にとっては「予算と投資対効果」、IT部門にとっては「システム開発における技術的な制約」、業務部門にとっては「自分たちが実現したい業務」のそれぞれを中心に物事を見ているため、一向に議論が進まない、といったことも往々にして起こりえます。

後のステップで計画の認識にズレを生じさせないためにも、それぞれがお互いの業務領域に関心を持ち、納得いくまで議論を重ねることが重要です。

ERPベンダーの選定は、システムの刷新プロジェクトの成功可否を左右するといってもよいほど重要なプロセス。検討をする際には、以下のポイントを中心に確認してみてください。

• 同業種・業界での導入実績はあるか
• 自社の機能要求を満たせるか
• 自社で設定した予算・納期で進められるか
• サポート体制は充実しているか
• 他システムとの連携性は優れているか

とくにERPは、長期間の使用を前提に導入するため、ベンダーと信頼関係を築けそうかといった点も考慮することが大切です。また今後、自社の事業が拡大したりIT技術が進化したりする可能性も踏まえ、柔軟性のあるアーキテクチャであるかどうかも視野に入れて検討しましょう。

要件定義のプロセスにおいては、主に機能要件と非機能要件を中心に定めます。

機能要件とは、システム刷新において必ず実装・搭載すべき機能の詳細のこと。たとえば「経営情報を一覧で確認できるダッシュボード画面がほしい」「社内の各種帳票を自動作成できるようにしたい」といった、メインの要求です。

一方で非機能要件においては、可用性や性能、保守性など、機能要件以外で定めるべき要件を決定します。先ほどの経営ダッシュボードの例でいうと「管理画面のトップから直接データへアクセスできるようにする」「クリックしてからダッシュボード画面を表示させるまでの時間が3秒以内」といった、潜在的な要求です。

ここでのステップでは、ベンダーと協力しながらともに作り上げていく姿勢が重要。一方的に要件の詳細を伝えるのではなく、「なぜその機能が必要なのか」といった理由も併せて伝えることで、お互いの共通認識を深められます。

要件定義が終わったら、いよいよシステム実装です。ここでは一般的に、「設計」と「プログラミング」の2つの段階に分けておこないます。

設計においては、要件定義書の内容にもとづき「外部設計」と「内部設計」を実施します。外部設計は、エンドユーザーの視点にもとづき作成する仕様のことで、実際の使い勝手に直結する大事な部分です。

一方の内部設計は、開発者視点でおこなうのが特徴です。「システムがスムーズに動作するために何の言語を使用すべきか」「機能をどのように分割すべきか」といった内容を決定します。

そして最後のプログラミングの段階では、作成した設計書にもとづき、プログラマーが実際にコードを書いてシステムを形作っていきます。

システム実装時におけるプログラミングと並行して、作成したプログラムや機能が正常に動作するかどうかを逐次テストします。仮にテストを実施しないと、あとから不具合が見つかった際に、大きな手戻り工数が発生したり、取り返しのつかない事態になったりしてしまうために、重要な工程です。

システム開発におけるテスト工程は、以下のステップに分けられます。

• 単体テスト：ユニットごとに正しく機能しているかをチェックする。
• 結合テスト：ユニット同士を組み合わせ、それが正しく動作するかどうかをチェックする。
• システムテスト：システムが要件定義の通りに動作するのかをチェックする。
• 運用テスト：実際の本番環境へリリースして、稼働状況や動作に問題がないかをチェックする。

テストをおこなう際のポイントは、テスト用の設計書や仕様書をしっかりと作成することです。「チェック者がどのような観点でチェックをおこなうのか」「どのような判断基準で合否を出せばよいのか」といった点を具体的に記載することで、テスト工程での作業がうまく進みます。

業務改革は「BPR（Business Process Reengineering）」ともいわれ、既存の業務プロセスを分析し、業務フローや組織を再構築する取り組みを指します。基幹システム刷新が「システム」を主な改善対象としているのに対し、業務改革では「業務プロセス」に重きをおいて改善活動をおこなうのが特徴です。

業務改革を伴わない基幹システム刷新は、いわば「基礎がない状態での家づくり」のようなもの。非効率な業務に合わせてシステムを刷新しても、業務効率化は達成されません。

たとえば、「マスタデータのコード体系がバラバラになっている」「実在庫と帳簿在庫がまったく合わない」「調達リードタイムが長い」といった状態が発生しているのであれば、それはシステムの問題ではなく、業務プロセス自体に問題がある可能性が高いです。

システム刷新プロジェクトを成功させるためにも、まずは業務部門が中心となって、今ある業務プロセスを見直せないかを一度検討してみてください。

超上流工程とは、システムの構想立案からベンダー選定、要件定義までの一連のプロセスを、川の流れにおける「上流」のさらに上、「超上流」にたとえて表したものです。この工程がうまくいくかいかないかは、プロジェクトの成功可否を左右するといっても過言ではありません。

たとえば、システム刷新の構想立案において「予算はこれくらいで、機能はこれこれを搭載する」と決めていたのにも関わらず、実装段階に入ってから「追加のアドオン開発が必要になって予算オーバーになった」といった事例がよく発生します。また、「ベンダー選定をミスしてしまい、業務効率がなされずに運営や保守コストがかさんでしまった」といった例もあります。

これらは、超上流工程の段階における詰めが甘かったといわざるをえません。

システム刷新の失敗をなくすためにも、経営層からITシステム部門、事業部門までが緊密に連携し合い、超上流工程の段階で自社がどのような基幹システムを作り上げるべきなのかをしっかりと議論する必要があります。

この記事では、システム刷新の概要や重要性、具体的な進め方を解説いたしました。基幹システム、特にERPを導入する際は、多くの予算と人員を割く必要があるため、失敗するわけにはいきません。

システム刷新を成功させるには、業務改革を先におこなうことに加え、「超上流工程をきちんとおこなう」ことがポイントです。以下のホワイトペーパーでは、具体的な超上流工程の進め方を解説していますので、よろしければご参照ください。