全2回　リスクという観点から考えるシステムリプレースへの取り組み方 《連載:第2回》 システムリプレースに必要な考え方と社内との関わり方

システムリプレースを失敗させないためには、既存の業務をそのまま踏襲するのでなく、いくつかの観点に分類する考え方が有効です。また導入によって影響のある部署のユーザーから導入時にいかに協力を仰げるかも重要なポイントです。

ITサービス運用でお困りなら、ITサービス管理ツール「SmartStageサービスデスク」へ

システムリプレースのリスクを最小化するための基本方針

システムリプレースに伴うリスクを解消するために、企業は何を考えるべきでしょうか。最も重要なことは、そのシステムが対象としている業務の“棚卸”を行うことです。システムは必ずしも導入前の要件すべてを導入後に求める必要はなく、必要によって、業務プロセスを見直すことも必要です。

具体的には、「変えなくていいもの」「変えたいもの」「既製品を利用できるもの」「新しく作るもの」の4つに分類し、メリハリをつけたシステムリプレースの方針を策定していくとよいでしょう。ここでは特にクラウドを利用したシステムリプレースのあり方を考えることにします。

まず「変えなくていいもの」については、Re-Host（Lift＆Shift）のアプローチが有力な選択肢となります。つまり既存のシステムをそのままクラウドに移行するということです。リプレースの工数を最小限に抑えると共に、その後の運用フェーズでのハードウェアのライフサイクル管理やOSのアップデートなどの作業負荷を軽減することができます。

２つめの「変えたいもの」については、Re-Platform（Lift＆Shape）のアプローチをとります。対象システムのコアアーキテクチャまでは変更しないが、クラウドからPaaS（Platform as a Service）として提供されている機能を最大限に活用し、システムのモダナイゼーションを図るのです。このアプローチで重要なのは、システムを「どう変えるのか」を設計する初期段階から業務現場のユーザーを巻き込んでおくことです。アジャイル開発などの手法も積極的に採用し、ユーザーの納得を得ながら共にモダナイゼーションを進めることで、業務現場に浸透させることができます。

３つめの「既製品を利用できるもの」については、Re-Purchase（Replace-Drop＆Shop）のアプローチに基づきSaaS（Software as a Service）の積極的な活用を検討します。ここでも情報システム部門などが独断専行するのではなく、ユーザーと共に選定を進めることが業務現場に浸透させる上での重要な要件となります。

そして４つめの「新しく作るもの」については、Re-Architect（Re-Writing、Decoupling Application）のアプローチを展開し、自社の競争力強化や新たなビジネスの源泉となる機能やサービスを実現していきます。システムリプレースを機に最も注力したい部分です。

なお、時代遅れとなり役に立たなくなったシステムについては「捨てる」という判断を下すことも重要なポイントです。メリハリを効かせた方針策定によって限りあるリソースを有効活用することが、システムリプレースのリスクを最小限に抑えることにもつながります。

システムリプレースにあたって社内とどう調整するか

SAP ERPをはじめ、基幹システムの大掛かりなリプレースを行う場合、その影響範囲は社内のあらゆるところに及びます。基幹システムに限らず、システム導入にはシステムのユーザーとの調整や関わり方が重要であることは言うまでもありません。

一般的に導入時にはプロジェクトを組んでさまざまな関係者を交えた体制を組むとはいえ、必ずしも業務部門が協力的で平和裏にプロジェクトが進むとも限りません。そのため他部署との調整や説明をどれだけ行えるかも導入成功に大きく左右します。

その中で、情報システム部門としては、突発的なシステムリプレースにも対応できるように、日頃から業務部門の関係者と密接な関係性を作っておくとうまくいくケースも多く見られます。

極端な例ではありますが、ある製造企業が基幹システムの大規模なリプレースプロジェクトを行うにあたって、システムに理解があり、以前からシステム関連で相談していた社員をバイネームで指名し、なんとか頼み込んで情報システム部門に引き入れたというエピソードもあります。その結果業務部門の目線から、ユーザーへのテストや業務用件の洗い出しをスムーズに進めることができたといいます。

またこの企業では、各部署からの協力を仰ぎやすいよう、経営層がプロジェクト体制の責任者になりました。これは、そもそもシステムリプレースが同社の経営計画として重要な課題として挙げられ、盛り込まれていたという背景もあるため、どんなシステム導入にも普遍的に適用できるわけではありません。

しかし社内を説得しやすい人間を配置し、プロジェクトの意義を理解してもらうことは、システム導入の要件定義や、テスト、ユーザーへの定着までにおいて、ぜひ考えるべきことの1つであるでしょう。