基幹システムを刷新する6つのステップとは？失敗を防ぐ進め方と刷新方法

2022/2/28

【2021年最新】基幹システム刷新の6ステップ！失敗しない方法を紹介

基幹システムの導入から年月が経過して老朽化が進んでくると、刷新のタイミングを検討する必要に迫られます。特に長期間システムを使っていると、メーカーのサポートが切れるケースが増えるため、サポート切れのタイミングで刷新の決断をするパターンが最も多いでしょう。

システムが老朽化すると、周辺のインフラやOSなどのアップデートに合わせて改善する開発にコストがかかったり、業務スタイルの変遷に合わせて機能に不満点が出てきたりもします。

しかし、基幹システムの刷新をしようと考えても、社内に有識者がいる企業は少ないため、滞りなく完了させるのは簡単ではありません。本記事では、基幹システムの刷新の必要性を判断する方法から、進め方や注意点を紹介します。

具体的な刷新手順も解説するので、全体像が把握できず不安を感じている方はぜひ参考にしてみてください。

基幹システムの刷新を検討すべきケース

基幹システムの刷新が必要なのは「サポート切れが迫っているとき」だけではありません。下記のケースに当てはまる場合は、刷新を検討しましょう。

1. 今後の事業拡大にシステムの対応が追いつかない
2. システムの複雑化により、保守性が低下している
3. システムが古いため、外部システムとの連携ができない
4. 保守契約・サポートの期限が終了している

現状と照らし合わせて、現行基幹システムの「刷新の必要性」を考えてみてください。

1.今後の事業拡大に対応できていない

基幹システムの稼働期間が長ければ長いほど、実装当時と現在の業務内容は変化してズレが大きくなっていきます。

なぜなら、特に近年ではグローバル化やクラウドの普及によって、多くの企業が事業体制や業務の流れを変えており、それに合わせて基幹システムも変化が求められているからです。例えば、国内のみで事業をやっていた企業が世界各国へ事業展開した場合、現地で利用されている言語や通貨を設定するために、システムに改修を加える必要があります。もしくは、最新のクラウドシステムとレガシーな基幹システムを連携させようとしても、各システムの規格が合わず連携できないことがあります。

今後の事業拡大やテクノロジーの発展により、求める機能と要件のズレはさらに大きくなっていくでしょう。

特に現段階で以下のような対応をしている場合、基幹システムの刷新をおすすめします。

• 新業務専用のシステムを個別で導入している
• 業務の変化に対応するために後から継ぎ接ぎで機能拡張している
• 業務内容の変更にシステムが対応できず業務効率が落ちている
• 基幹システム未対応の業務に対する情報の集計や記録などを手作業で対応している

システムを継ぎ接ぎで拡張すると場当たり的な対応になることが多いため、中身がスパゲティ化（複雑化）してしまい設定内容の可視化が難しくなっていきます。

場当たり的なシステム改修が常態化すると運用や管理のコストがどんどん増大していくので、基幹システムを更新するタイミングでの一本化を検討しましょう。

2.システムの複雑化により、保守性が低下している

システムの複雑化が進行したところに担当者の入れ替えなどが起こると、誰も中身を理解できない「ブラックボックス化」が起こります。

もし現行の基幹システムを最も理解している方が退職や異動などで不在となった場合、ブラックボックス化した部分に手がつけられなくなってしまうでしょう。システム障害が起こっても、早急に対応できない可能性があります。

時間が経てば立つほど保守性が低下していき、システム障害が起こる際には原因特定などで大幅に時間がかかるなどの問題がおきてしまうので、ブラックボックス化が発生している場合は早急に基幹システムの刷新を検討するべきです。

現在のメンバーと信頼できるベンダーで完璧にコントロールできるよう、システムの保守性を再確認しましょう。

3.外部システムとの連携など、改修が要求されている

基幹システムを別のシステムと連携させる場合は、基幹システムに導入されているOSやミドルウェアのバージョンが古いために最新のシステムとの連携ができないリスクがあります。

現代では数多くのクラウドサービスがあり、基幹システムと上手く組み合わせて業務を効率的に回すことができます。例えば、営業支援システム    などを活用することによって、会計処理などを行う基幹システムに連携させて処理ができると、本社に帰ってデータを入力する等の手間がかからず効率的です。

日経XTECHが2008年に行った調査によると   、基幹システムの平均寿命(各企業が限界と判断しリプレースするまでの期間)は13.6年と言われており、10年以上経過しているような古い基幹システムは外部システムとの連携も難しくなってきます。

もし「最新の業務効率化ツール」がリリースされたとしても「基幹システムと互換性がない」という理由で導入を断念せざるをえないかもしれません。

基幹システムは会社の中心であり、屋台骨の役目を果たす存在です。基幹システムのアップデートを怠ることで、他の現行のシステムとの連携に不備が生じる可能性とともに、今後のシステム導入の障壁となってしまう恐れがあります。

4.保守契約・サポートの期限が終了している

現行システムが導入から4〜5年目の場合、システムを支えるハードウェアやミドルウェア、ソフトウェアの保守・サポート期間終了日が近づいている可能性があるので、一度メーカーサポートサイトなどで確認することをおすすめします。

もし保守契約期間が終了している場合、トラブル発生時に迅速な対応ができなくなり大きな損失を生んでしまうかもしれません。

サポートが切れた状態のシステムを運用していると、以下のように予期していないタイミングで業務がストップするリスクがあります。

• サイバー攻撃
• 自然災害
• ヒューマンエラー
• ハードウェアの故障（システム停止）

開発元のサポートが終了しているシステムを使用し続けると、万一の不具合に対応してもらえない可能性があるため、保守・サポートの期限が切れているなら刷新を検討すべきです。
トラブルの発生タイミングを完全に把握することはできません。

システムを購入した際、最大で5年間は保守に入れるものですが、6年目以降はメーカーの判断で保守が終了しかねません。自社の基幹システムが導入から5年以上経過している場合は、メーカー提供の保守がいつまで続くかを考慮しつつ、早めに刷新を検討するといいでしょう。

基幹システム刷新の3つのメリット

「基幹システムを刷新したほうが良いのはわかっているが、今のシステムでも安定して動いてはいる」と考え、刷新をためらう方も多いのではないでしょうか。基幹システムの刷新は、現場で発生しているトラブルなどの現状の課題を  解決するだけでなく、下記のメリットもあります。

1. 事業変革にシステムを合わせる
2. 属人性を回避でき、業務の均質化・効率化につながる
3. 新人教育の高速化  ・人材コストの削減につながる

基幹システムの刷新により業務の効率化を大幅に達成できれば、コストやリソースの最適化によって他のシステムや事業に投資できる余力が生まれるはずです。

1.事業変革にシステムを合わせられる

基幹システムを刷新することで、事業変革にシステムを適合させられます。例えば、既存事業から得た技術を活かして新しい事業を立ち上げる際に、生産管理業務などを連携している他のシステムと柔軟に合わせていくなどのシーンが考えられるでしょう。

事業とシステムがマッチすることで得られるメリットは、以下が代表的です。

• 機能の追加が容易になる
• 開発・保守のコスト削減になる
• 生産性が向上する

実装したくてもこれまで追加できなかった機能も、基幹システム刷新のタイミングで組み込めます。さらに、業務ごとにバラバラであったシステムを一本化できるので、効率の良い管理が可能になるとともに、それぞれのシステムで生じていた運用・保守コストも抑制が可能です。

また、事業にマッチしたシステムを活用することで、新たな企画の立案や開発のスピードアップを期待できます。事業変革にシステムを合わせられることは、基幹システム刷新の大きなメリットです。

2.属人性が回避でき、システムの保守性が増す

レガシーなシステムは操作できる人間が限られており、昔からシステムに携わり理解のある社員しか対応できない業務が発生しがちです。

実際に、COBOLのようなレガシーな言語を扱えるエンジニアは減少傾向にあり、市場においても不足しています。株式会社フロッグが蓄積した求人データをもとに、株式会社ゴーリストが集計した｢5年分の求人ビッグデータから読み解く プログラミング言語トレンド【2021年版】｣を紹介します。

調査内で紹介されている「言語別求人数の推移」によると、COBOLを扱えるエンジニアの求人は近年で大幅に増えています。

言語別求人数の推移

※引用：5年分の求人ビッグデータから読み解く プログラミング言語トレンド【2021年版】｜株式会社ゴ−リスト｜

COBOLのエンジニアが市場で不足しており、人材獲得は容易ではないと想像できます。特定の言語を扱えるエンジニアしか操作ができないレガシーシステムを保有している場合、中身を理解している人材を確保できなければ完全にブラックボックス化してしまう危険な状態です。

エンジニアの欠員もすぐには補充できない可能性が高く、早めに既存システムの設定内容を棚卸したうえで、基幹システムを刷新することで属人性を回避しましょう。

Javaのような最新のオープン言語に切り替われば対応できる人員も増え、保守性が大きく増加するはずです。

3.新人教育の高速化・教育コストの削減につながる

レガシーなシステムの場合、操作方法が複雑なケースが多いです。システム刷新により、慣れ親しんだインターフェースに加えて直感的な操作が可能となります。 画面デザインや操作方法が最新化されれば、新人教育が行いやすいでしょう。

具体的には、レガシーなシステムは、文字や記号による旧世代のCUI(Character User Interface)で作られており、スクロールもできず特定のボタンを押して画面遷移をするような仕組みになっていることが多くあります。近代的なGUI(Graphical User Interface)の画面に変わることで、直感的に操作方法を説明できれば、新入社員がシステム操作を会得するまでにかかる時間は大幅に減少するでしょう。

教育コストが下がることに加え、離職者が出た際の欠員補充・補充に伴う教育もスムーズに行えます。

産労総合研究所が発表した「2020年度 教育研修費用の実態調査」によると、2020年度の教育研修費用の総額の平均は7,370万円にも上ります。システムに関わる研修フローを短縮できれば、経営状況の健全化にもつながるでしょう。

基幹システムの進め方

実際に基幹システムを刷新しようと考えたら、どのようにプロジェクトを進めていくのでしょうか。本章では具体的な進め方のイメージを紹介します。

1. プロジェクトチームの発足
2. 現状システム把握
3. ビジョン策定と課題の洗い出し
4. システム刷新方針検討
5. システム開発・移行
6. 運用開始

基幹システムを刷新するメリットである「事業変革に対応する柔軟性」「属人性の回避」「教育の高速化」の実現は「各ステップの注意点をチェックして進められたか」に左右されます。

1.プロジェクトチームの発足

基幹システムを使うのは特定の部署のメンバーだけではありません。関連する部門の業務上の課題を的確に把握するためには、それぞれの部門からプロジェクトメンバーを出してもらい、生の声を参考にするのが一番です。
全社からメンバーを選抜して、プロジェクトチームを発足しましょう。

【プロジェクトチームを発足するメリット】

• 全社から意見を吸い上げやすい
• 全ユーザー部門への定着化がさせやすい
• 特定の課や部署に負担が集中することを防げる

チームメンバーは実際にシステムを操作しており、刷新に協力的な方がおすすめです。チームに選定されたメンバーは、現場の課題を洗い出してもらうだけでなく、自部門への操作方法を伝える役割もあります。

ただし人数が多すぎるとプロジェクトの進行に影響が出るので、メンバーを厳選して特定の課や部署に人数が偏らないようにしましょう。

2.現状システム把握

集めたチームメンバーで「使い勝手」「システム資産の状況」という2つの面から現状把握をしていきましょう。現状把握が徹底されていないと、プロジェクトのスケジュールやプロジェクト全体に大きな影響が出て、思わぬコストアップに繋がることもあります。

【現状システム把握のポイント】

• 全社の現場の声を抽出する
• 現状のシステム資産の状況を洗い出す
• スパゲティやブラックボックス状態のシステムがないか確認する

現場からのヒアリングとシステム資産の状況のチェック方法を紹介します。

2-1.現場から「使い勝手」についてヒアリングする

システムを使っている現場から、実際の業務中に起こっている問題点を聞いてみましょう。

プロジェクトチームに参画のメンバーが窓口となり、それぞれの部署のスタッフに聞き取り調査を実施し、業務上のボトルネックや他部門との連携で時間を要している業務がないかをヒアリングしてください。

2-2.現状のシステム資産の状況・状態をチェックする

現在運用中のシステム資産以外にも死蔵しているものがあるかもしれないので、刷新する前に棚卸しして確認してください。

【代表的なシステム資産の例】

• 業務に使うパソコンなどのハードウェア
• 基幹システムを始めとするソフトウェア
• パッケージソフトウェア等のライセンス

システム資産の把握に漏れがあると、現行資産に存在する機能を再開発してしまうなど無駄が発生する可能性があります。また、同時に各種システムのスパゲティ化している部分についても、設計を確認しておきましょう。

膨大な規模があり、把握に時間がかかってしまう場合は、TISの資産棚卸しサービスの利用もご検討ください。

• 使っていない資源がたくさんある
• 設計書がない（もしくは古い）
• コピー新規で作られた類似プログラムが多数存在する

上記の状況でも資産をクリアにするために、TISでは数々のマイグレーション案件で培ったプログラム自動変換ツールを使用して、各種システム資産をインプットにさまざまな分析結果をご提供することが可能です。

資料は無料でダウンロードいただけますので、ぜひお役立てください。

＼システム資産の棚卸／
資産棚卸サービスの活用を検討されている方はこちら！

3.ビジョン策定と課題の洗い出し

収集した現状のデータを元に、具体的なビジョン（どのような資産にしていくか）と課題の洗い出しに移ります。

「システム」「現場」「経営」この3つの観点からビジョンを策定し、協議を重ねてください。

【ビジョン策定でクリアにするべきポイント】

• 業務上の困りごとやニーズを解決できているか
• DXに対応し、他ツールとの連携が取れるか
• 自社でシステムの保守と運用を行う人材は確保できるか
• 今後の業務の変化に合わせた開発スピードは担保できているか
• 経営計画を意識できているか
• 時代の変化に対応する柔軟性があるか

現場の要求を組み込めば即戦力のシステムが完成しますが、基幹システムは10年以上使われることが多いので長期的な利用を想定した目線も重要です。担当者が退職しても運用できる保守性や、今後導入するかもしれないツールとの互換性も意識しておきましょう。
また、刷新のタイミングで大幅なシステムのグレードアップを行ったとしても、更に1年後や2年後には業務の変更に伴って細かな改善点が発生するはずです。
その際の「システム改修の対応スピード」は、情報システム部門はもちろん、全社の業務の流れに影響します。システム管理の簡易性を高めて、柔軟性を担保しておきましょう。

4.システム刷新方針検討

システムのビジョンが固まったら、具体的な刷新方法（どのように理想を実現するか）の検討に移ります。大きく分けて3種類の方法があるので、自社の状況に合わせて最適な方法を考えてみましょう。

【基幹システムの刷新方法】

1. 一から再構築する（リビルド）
2. 既存資産を活かしつつ新環境に移行（マイグレージョン）
3. 保守・運用の範囲内で改修やバージョンアップを行う

基本的にはベンダーに状況を伝えれば、選択肢を含めてベンダーが最適な方法を提案してくれます。ただし、自社でも最も良いと思われる方法の検討をつけておいたほうが、想定スケジュールや予算、自社の方針をベンダーが考慮して提案してくれる可能性が高まるでしょう。

どのような方法が最適か、自社の経営方針や事業変革によって実現したいことと照らし合わせて検討してみてください。

4-1.一から再構築する（リビルド）

ビジョン策定の結果、大幅な改善が必要でありシステムの根本設計思想から刷新が必要な場合は一から再構築する「リビルド」がおすすめです。
建築に例えると、リビルドは土地（ハードウェア）から家（システム）まですべてを新しくする方法です。

【リビルドの特徴】

• 基幹システムを根本から作り直せる
• 移行業務が最も大変でリスクも高い
• 開発コストが高い
• 開発期間が長い

3種類の方法の中で最も大規模なもので、システムに根本的な問題がある・もしくは業務を大きく見直すためリビルドせざるを得ない状況でなければ、コストパフォーマンスが良いとは言えません。

リビルドには「スクラッチ開発」と「パッケージ開発」の2つの方法があります。

• スクラッチ開発：完全オリジナルでゼロから開発する方法
• パッケージ開発：既存のソフトウェアなどを雛形にして再開発する方法

スクラッチ開発よりパッケージ開発のほうが開発範囲が少なく済みますが、作りたいシステムの要件を叶えられるかはベンダーに相談が必要です。パッケージ開発は経理や勤怠管理などの定型的な業務、スクラッチ開発は他社とは差別化を図りたい経営資源を集中する業務で採用されることが多いです。

4-2.新環境に移行（マイグレーション）

既存のシステムを活かしたい場合は「マイグレーション」を採用すると良いでしょう。

マイグレーションはリビルドとは異なり、システム資産を活かして新環境に移行するような方法です。

【マイグレーションの特徴】

• リスクやコストを抑えながら現状システムの老朽化に起因する課題を解決できる
• 元となるシステムがあるので、刷新スピードが早い
• 既存のシステムをそのまま移行するため業務への負荷が少ない
• 有識者が少なくても移行を進めることができる

現場で使われているアプリケーションの機能を変更せずに、システム環境（プログラム言語、オペレーションシステム、ミドルウェア、インフラ）のみの刷新できます。近年注目されるクラウドマイグレーションも含まれる手法です。

例えば「1から作り直すほどではないが、改修したいポイントがある」という状況の場合、まずはマイグレーションでシステム全体の生産性や保守性を向上すると良いでしょう。

並行して新環境基準で機能を改修・統合を進めていけば、無理なく策定したビジョンを実現できるはずです。

再構築（リビルド）とマイグレーションの違いについては「マイグレーションと再構築の違いとは？ システム部門が知っておくべき３つのポイント 」で詳しく紹介しています。

4-3.保守・運用の範囲で改修やバージョンアップを行う

現在の基幹システムに保守性や開発の生産性向上が求められておらず、かけられる予算に制約がある場合は、改修やバージョンアップを行うのみで良いでしょう。

【改修・バージョンアップの特徴】

• 予算を抑えられる
• 現在の業務にほとんど影響がない
• 次回の刷新タイミングで大幅な改善が求められる可能性がある

社内の都合で細かな問題に目をつむり、最低限のバージョンアップで次に繋げることも不可能ではないかもしれませんが、根本的な解決にはなりません。
多くのレガシーシステムではメーカーサポートの期限切れが問題となり、期限ギリギリで慌てて移行しています。バージョンアップで済ませて刷新を先延ばしにすると、適切なスケジュールの確保が後手後手に回り、プロジェクトが失敗するリスクも高まるので、余裕のあるうちにスタートしてください。

経済産業省が発表した「2025年の崖」^※1 問題の影響もあり、今後はさらにDX化は加速していくでしょう。同発表によると約7割の企業がレガシーシステムがDXの足かせと感じています。

※1 2025年の崖
DX化の失敗によって国内で年間12兆円の損失が生まれるとする試算のこと

競争力を維持するためにはどこかのタイミングで「リビルド」か「マイグレーション」を行わざるを得ないタイミングがやってきます。DX化のタイミングなどに合わせて、システムの刷新も行うのがおすすめです。レガシーからオープンシステムに移すことで、互換性の担保やシステム連携などのしやすさが増すので、DX推進の足枷にもなりにくいでしょう。

5.システム開発・移行

決定した刷新方法に合わせて、システムの開発をスタートしましょう。
要件定義を行い、システム刷新を行うベンダーとプロジェクトチームで密に連絡を取ってください。

【要件定義のポイント】

• 業務課題の改善箇所の明確化
• 整備すべきインフラの定義
• 削除すべき機能
• 見積もりの妥当性
• 品質保証やサポート対応の相談

マイグレーションを選択する場合は、現行基幹システムの仕様説明や、利用状況の明確化も欠かせません。システムが完成したらデモ環境を用意して移行のテストを行い、チームで進捗を共有して本番の運用に備えます。

移行テストはシステムの品質を担保する重要なフェーズなので、品質目標を明確化しておき「クリアすべきライン」を作っておきましょう。プロジェクト計画にテスト品質のチェックを盛り込んでおき、厳しく管理できるようにしてください。

なお、特にマイグレーションの場合は「スケジュール」に注意してください。「マイグレーションは自動変換だから早く終わる」といった思い込みから、移行のスケジュールを過小に見積もってしまうことがあります。実際は自動で変換できなかった部分を手作業で移行する必要があるため、手戻りの量によってはスケジュールに遅延が生じます。

確実にスケジュール通りに終えられるよう、システムの棚卸しなどベンダーのリスク管理への姿勢を確認してください。スケジュール管理のポイントについては「うまくいくマイグレーションとうまくいかないマイグレーションの違いとは」でご紹介しています。

無料でご覧いただけますので、ぜひご活用ください。

＼うまくいくマイグレーション／
基幹システムのマイグレーションを検討されている方はこちら！

6.運用開始

デバックなどの準備が完了したら、運用をスタートします。運用開始から暫くは問い合わせが殺到するので、プロジェクトチームのメンバーを中心に操作の説明などにあたりましょう。

【運用開始直後の問い合わせ対応のポイント】

• 改善ポイントを事前に周知して混乱を防ぐ
• 何名かの現場スタッフにデモの段階で触れてもらう
• 予想される問い合わせ内容を事前にリストアップする
• 問い合わせ内容をチーム内で共有する

最初の混乱が長引くと社内に不満が溜まってしまう恐れがあります。スムーズに移行できるように、上記のポイントを中心に準備してください。

基幹システム刷新の失敗を防ぐ3つのポイント

刷新のステップを踏んでいく中で、特に重要なポイントは3つあります。

1. 現状把握の徹底
2. 適切な刷新方法の決定
3. 品質・費用・納期（QCD）の観点

3点を意識して進めていけば、「サポート切れまでに移行が終わらなかった」「コストがどんどんかさんでいった」「実現したかったシステムが作れなかった」といった失敗が発生するリスクをおさえられるでしょう。

1.現状把握の徹底

現在の業務を効率化するには「業務で発生している非効率な作業を整理すること」、今後の事業変革に対応するためには「システムに柔軟性を持たせて移行すること」が重要です。
現状を細かく分析して、良い点と改善が必要な点を正確にチェックしておきましょう。

【現状把握を怠ると起きる問題点】

• 限られた部署で使われていた機能を不要と思って削除してしまう
• 現状の問題点を未解決のまま次回の刷新まで先送りにしてしまう
• 発言権の強い部署だけに都合が良いシステムに偏ってしまう

これらの問題を未然に防ぐためにも、プロジェクトチームは全社から均等に募ってヒアリングし、システム資産については「資産棚卸しサービス」を利用するなど、時間をかけて正確に調査を進めてください。

2.適切な刷新方法の決定

基幹システムの刷新方法は1つではなく、社内のニーズや状況に合わせて適切な方法を選ぶことが重要です。
ベンダーから提案を受けた際、その妥当性を正確に判断する必要があります。

以下にそれぞれの移行方法を整理しました。

リビルドによって理想的なシステムをじっくり構築していくのが一番ですが、予算・納期と得られる効果を考えると現実的でない場合が多いため、実際には「一部はマイグレーションし、一部はリビルド」という手法をとることもあります。

3.品質・費用・納期（QCD）の観点

基幹システムを刷新する際は、QCDの観点から内容や方法、ベンダーを比較検討してください。優れたシステムを求めるあまりに費用がオーバーしてしまったり、納期が数年後になってしまってはプロジェクトが立ち行きません。
ベンダーの提案について「品質」「費用」「納期」の3つの観点から点数を付け、総合得点が高い最もバランスの取れたものを選ぶ必要があります。

ただし、「品質」「費用」「納期」の3点は連動することがある指標でもあります。例えば、マイグレーションの場合、自動変換ツールの品質はベンダーによって異なります。品質によって「手作業や不具合による手戻りの量」が左右されるため、品質の良いツールを持っているベンダーだと工数が少なくおさえられ、費用が安く、納期は短くなると考えられます。

逆に品質が悪ければ修正のために納期も長引き、結果として費用がかさむリスクまであるでしょう。費用や納期を見るために、最重要指標である「品質」を見るべきです。

【品質を確認するポイント】

• 担当者が自社の業務内容にどれだけ精通しているか
• 同業他社の刷新事例はあるか
• ISOなどの品質管理基準を満たしているか

推測をできるだけ排して、QCDを満たしている根拠を明確にしてから実行に移りましょう。

＼オープンマイグレーションシステムの資料を無料ダウンロードしませんか？／

TISの基幹システムマイグレーション事例

TISが展開する「オープンマイグレーションサービス」は、30件を超えるマイグレーションに取り組み、計画変更・本番障害0件を達成してきました。
コストや納期の観点から、マイグレーションでの刷新を考えている担当者の方は、本章で紹介する金融業界・I社様のマイグレーション事例をぜひご参考ください。

I社では、基幹システムのマイグレーションをTISに依頼した結果、複雑なシステム構成だったにも関わらず、事故のない高品質の移行プロジェクトを2分の1のコストで抑えることができました。

もともとI社は、他社にて基幹システムを導入していましたが、サポート切れが迫ってきたことから、新システムへの移行を検討。既存ベンダーに見積り依頼をしたものの、予想を上回る高額な見積もりが出てしまいました。

さらに、品質を担保する指標が計画に盛り込まれておらず、重要なシステムの移行だっただけに、I社は決定し切れず、TISの子会社と取引があったことから、TISへ相談することになりました。当時、I社が抱えていた問題は以下の通りです。

• システム構成が複雑で、移行方法を決めかねていた
• 既存ベンダーからは大規模なプロジェクトであるため、高額な見積りが提示された
• 既存ベンダーの提案はテストの精度が不明瞭であり、品質面で懸念が残った
• 保守切れが迫る中で既存ベンダーのスケジュールに不安を感じていた
• 既存ベンダー以外はシステム規模の大きさ等から提案をもらうことができなかった

こうした課題に対して、TISは以下の点で評価いただける提案内容を提示し、マイグレーションを行うパートナーとして選んでいただきました。

1. 品質担保の指標を提案段階から明示
2. コストを当初想定の1/2に縮小
3. 保守切れに確実に間に合う適切なスケジュールの提示

課題になっていたI社のシステム構成は、複数のサーバーを経由してプログラムを処理させる複雑なものでした。全てのサーバーを対象にテストを行うとコスト・期間共に大きく追加となってしまう状況でしたが、TISはテスト対象を一部に絞り、対象外となったサーバーは結合テストで巻き取る方針を提示。コストも期間も縮小でき、品質面も担保したままプロジェクトを遂行することができています。

結果として、危惧していた本番障害もゼロ、保守切れに間に合う予定通りのスケジュールでマイグレーションが完了しました。

基幹システム刷新の事例はこちら！
◆基幹システムのマイグレーション｜TISが担当した金融業界の事例

まとめ

基幹システムの刷新は全社に影響する一大プロジェクトなので、慎重に進める必要があります。基本的には情報システム部門主導で進めることになりますが、全社から意見を吸い上げることを忘れてはいけません。

また、ベンダーから提案を受ける際は以下3つを確認し、「品質」「費用」「納期」について納得の行く提案かを考えてみてください。

• 刷新方法の妥当性
• 品質担保の姿勢（指標）
• 実績

見積もりが高額だったり、自社で検討していた刷新方法での実現を断られたり、少しでも懸念が残る場合は、相見積もりを取るなどして妥当性を検討しましょう。再構築を提案されても、実際は「一部をマイグレーションし、一部を再構築する」という方法がとれる可能性もあります。

＼オープンマイグレーションシステムの資料を無料ダウンロードしませんか？／

その他ブログのご案内

オープンマイグレーションサービスについて、ブログを通してメリット、ユースケース、取り組み方のコツなどをお伝えしています。

• オープンマイグレーションサービス　ブログ一覧はこちら