システムリプレースとは その意味や必要なケースをパターン別に解説
システムリプレースとは、社内システムを新しく作りかえることです。レガシーシステムを用いている企業が、今後も安定して事業展開をするのに必要な手続きと言えます。基本の考え方や必要な準備、2つのリプレースパターンを、IT業界経験10年以上のシステムエンジニアが説明します。
目次
システムのリプレースとは 意味から解説
システムリプレースとは、長らく稼働を続けてきた社内システムを、現行の業務に合致し、今後の会社の経営方針などに則って事業展開をスムーズに進めていくために新しく作りかえることです。
一般的には、現行のシステムを、ハードウェア等も含めてすべてを丸ごと入れかえることを言います。
一方で、ハードウェアなどはそのままの構成で、社内システムを搭載しているOSやDBMS（データベース管理システム）などのバージョンアップのみ行うことをシステムの「マイグレーション」と呼んでいます。
システムのリプレースが必要な「攻め」のケース
システムリプレースが必要になるケースは色々と想定できますが、「攻め」と「守り」のケースに分けて考えることができます。
攻めのケースの具体例
攻めのケースとは、具体的に次のような場合です。
- 企業や事業の拡大でシステムが現状に合わない（事業推進先行による判断）
- 今後の事業戦略に沿ってシステムを戦略的にリプレースする（戦略先行による判断）
攻めのケースのメリット
攻めのケースでは、現在のコロナ禍のような状況でも事業をさらに加速させることができ、インターネットを利用したオンライン展開などを図ることもできます。
現在「デジタルトランスフォーメーション（DX）を早急に進めなければ、競合他社に大きく引き離されてしまうリスクがある」とかなり強めの啓発が行われています。
DXとは、AIやIoTなどの先進的なIT技術を活用して企業の事業展開を推進することです。しかし、DXにすぐにでも取り組める準備が整っている事業者は、まだまだ多くはない印象です。
DXを推し進めるためには「ITを活用する前提で事業を作る必要」があり、まさにシステムのリプレースはそれを実現するものです。
システムのリプレースが必要になる「守り」のケース
守りのケースの具体例
守りのケースは、次のようなパターンを言います。
- 老朽化による故障が起きると事業を継続できない（事業推進上のクリティカルな判断）
- 保守ができる会社や担当者がいない（予防的な判断）
守りのケースのメリット
守りのケースでは、現行の事業を継続させることができる点が挙げられます。
マイクロサービスと呼ばれる小さなサブシステムに分割をしながら、システム全体を構成していく「マイクロサービスアーキテクチャ」が流行する2012年以前に構築され、運用が続けられている業務システムが稼働している企業が存在します。
例えば、私がシステムの保守を担当している企業の中にも、2008年ごろより稼働している社内システムを利用されている顧客が実際にいます。ですが、今から10年以上前の、古い手法で構築されたシステムの保守を継続するのは簡単ではありません。
時間の経過とともに、当時開発したITベンダーが予算や人員の都合で保守できなくなった、そのシステムの仕組みを理解している社内の人間がいなくなった、といったケースが珍しくないからです。
システムリプレースを行えば、システムを開発する高いスキルを持ったシステムエンジニアによって、再び保守を継続できる体制の構築ができます。
「守り」のシステムリプレースに悩む経営者は多い
日本情報システム・ユーザー協会の「デジタル化の取り組みに対する調査2018」（PDF方式：1.65MB）では、以下のような「レガシーシステムの存在がデジタル化の足かせになっているか？」というアンケートの結果を公開しています。
ドキュメントが整備されていない、レガシーシステムとのデータ連携が困難、影響が多岐にわたるため調査に時間がかかる、有職者がいない、システムがブラックボックス化しているなど、どちらかと言えば守りの部分に関する項目がかなりの高いポイントを獲得しています。
これは、システムリプレースの必要性を感じている企業の多くは、システムリプレースをやらなければならない問題として認識はしているけれども、思うように進めることができない悩みを抱えている表れだと言えます。
システムのリプレース前に注意すべき手順
実際にリプレースを始める前に気をつけなければいけないことについて、次の3つを紹介します。
- 要件定義をおざなりにしない
- ITベンダーに丸投げしない
- スケジュールやコストを十分に検討する
要件定義をおざなりにしない
要件定義とは、リプレース後のシステムがどのような姿になるかを明確に想定した上で、どのような作業が発生するかを項目として定義することを指しています。
システムのリプレースを実行する上では、この要件定義をおざなりにしないようにしましょう。おざなりにしてしまうケースとして非常に多いのが、現状と同じ業務モデルやビジネスモデルの上で、システム上で動作するアプリケーション（パソコンの画面上で動作するシステムのこと）だけを組み替えるといった内容のものです。
システムのリプレース案件は、予算の関係などで、フェーズを分けて進行していく場合も多いかと思います。
このとき、第一フェーズで現行と同じシステムを最新のITインフラ環境やプログラミング言語に乗せ換えるだけに範囲を限定し、第二フェーズで新機能の追加に対応していこうと考えがちです。
しかし、そもそもベースの部分を現行のシステムと同じ内容にする場合、現行の仕組みと同様の様々な制約が課されることになります。そのため、今企業にとって本当に必要なことができなくなってしまうリスクなどが拭えません。
反面、完全に新しいものに刷新するとなると、上手くいかなかった場合にその責任を誰が取るのか？といった問題の整理に悩まされることになります。
この辺りの擦り合わせを社内およびITベンダー間で十分に擦り合わせことができなければ、完全な意義のある刷新が実現することはないことでしょう。
リスク回避的な選択をすれば、結果的に現行の仕組みと同じ仕組みのシステムに収束しがちです。
要件定義では、これらのメリットデメリットなどを加味した上で、現状のビジネスにおいて最も必要とされているものが何かを考え、具体的な項目に落とし込むスキルが求めらます。
ITベンダーに丸投げしない
企業側にITの専門家がいない、一方でITベンダー側には開発案件をなんとか受注したいという思惑がある、といった影響からか、これまでシステムの開発関連についてはベンダーに丸投げするのが当たり前という風潮があります。
しかし、ITベンダー側に任せきりにしてしまうと、システムのリプレースはたいてい失敗します。ITの開発は知的生産とも呼ばれ、結局は情報を頭の中で整理して、それらを設計書やプログラミング言語という形に落とし込みながら開発を進めていかなければいけません。
そのため、企業側の求めるシステムや予算・スケジュールといった都合と、ITベンダーのシステム構築上の都合を擦り合わせてお互いに理解を深めること、つまりコミュニケーションが最も大切なタスクとなります。
決して、ITベンダーに丸投げすることなく、システムのリプレースを成功に導くために、お互いに一丸となってプロジェクトを進めていく体制を構築することが大切です。
これは、ITベンダー選びの基準としても言うことができます。お互いにコミュニケーションがスムーズに取れるかどうかがプロジェクトの成否に直結するため、ITベンダーを選ぶときは、事業戦略の立案や今後の展開など、企業運営に携わる上流の部分から企業側の立場に立った上で、親身になって話を聞いてくれるかどうかを見てみましょう。
信頼関係が既に構築できている会社をベンダーとして起用する形も、プロジェクトを成功させるためには良い選択だと個人的には思います。
もちろん、技術力や実績の面も必要要件です。ITベンダー各社には開発手法やプログラミング言語など、それぞれに得意領域があることが一般的です。
各社の得意領域が時代の流れやITトレンドを押さえているかどうかは、十分に検討をした方が良いでしょう。
例えば、現在であればインターネットの技術を用いた業務システムを構築できるかどうかが1つの判断基準です。プログラミング言語にも開発工数を抑えやすい開発言語とそうでない開発言語、処理速度（パフォーマンス）が速い開発言語や遅い開発言語など千差万別な状況です。
過去の開発実績を確認する際には、ITベンダー各社が得意とする開発技術領域が何かや、それらの技術の特性を検討した上で、ITベンダーの選定を行えると理想的です。
スケジュールやコストを十分に検討する
システムのリプレースを進めるにあたって、スケジュールも十分に検討をする必要があります。
IT開発は、建築業界でよく利用されるウォーターフォール開発プロセス（上流行程から下流行程まで流れるようなスケジューリングを行い、プロジェクトを推進していく方法）を取ることが多くあります。
最近ではアジャイル開発プロセス（市場の状況やユーザーの考え、経験則に基づく随時改善など、諸々の連続的かつ急激な変化に対応するため、開発期間を短く区切りながら、反復的に開発を進める方法）と呼ばれる新しい開発手法も注目を集めるようになってきました。
システムリプレースのスケジュールでは、開発対象や状況に応じて上記の各開発プロセスを組み合わせながら構成していく方法が一般的です。
ただ、リプレースのスケジュールを組むとき、当初から多くの予算が割けないケースが多く、年度を跨いだフェーズ分けによって開発予算を捻出する方法がよく用いられます。
また、開発が進む際にも、市場や社内などの経営環境の変化が常に進んでいくこともあり、中々長期的なプロジェクトの計画を立てることが難しくなっています。
どのように進めるかについては各企業の判断によりますが、リプレースの開発規模は大きくしすぎないか、段階的なリプレースを検討した方が柔軟な経営環境の変化に追従ができるでしょう。
ただし、当然ながら、全体像として、中長期での社内システムがどうあるべきかについての青写真を描くことは必要だと思います。
企業側が個別にこれらを作成することが難しい場合は、ITベンダーに相談をしながら内容を詰めていく必要があるでしょう。
全部まるごとリプレース（フルリプレース）するパターン
実際にシステムのリプレースには、大きく分けると全部まるごとリプレース（フルリプレース）と、段階的なリプレースの２パターンがあります。
全部まるごとリプレースのポイント
全部まるごとリプレース（フルリプレース）とは、既存のシステムを一括してリプレースする場合に用いられる手法です。
当初から大きな予算が必要になり、決裁ルートが長くなったり、予算獲得が難しかったりすることがあります。また、開発工期も長くなり、開発完了時には当初の予定と想定が変わっている場合も少なくありません。
全体の規模感的に1年以内で完了できそうなコンパクトなシステムであればいいですが、プロジェクトが長期化しそうであれば、ITベンダーと契約内容をどこまで決めるか、十分に話し合ったほうがいいでしょう。
長期開発プロジェクトの開発内容について、たとえば詳細な契約を結んでしまうと、予定が変更になったときにトラブルに発展する可能性もあります。
全部まるごとリプレースのプロセス
IPA（情報処理推進機構）の「システム再構築の落とし穴とその対策 ～プロジェクト（失敗）リスクと対策の共有～」によると、リプレースのプロセスは以下の流れになっています。
- ハードウェア更改…ハードウェアを移行し、プログラムが動作しないなどの最低限の影響を修正する
- リホスト…現行と同じプログラム言語で、新しいプラットフォームへ移行する
- リライト…2を新しいプログラミング言語で実装し直す
- リビルド…新しいシステム仕様に基づいて3で利用したプログラミング言語で実装し直す
大規模なシステムを一気に移行するのはリスクが高いため、上記のような4段階のプロセスを経るのが安全です。
ただし、予算を圧縮するために、いきなりのリビルドの行程に着手することも可能です。場合によっては、1.2.3のプロセスまでにとどめることをシステムのマイグレーションと表現するケースもあります。
なお、一般的な開発プロセスとして、上記の1～4の各行程では以下のプロセスをたどります。
- 要件定義（何を実現するかを整理しタスクを定義）
- 設計（仕様書の作成）
- 実装（システムの構築）
- テスト（仕様書とシステムの内容が同じか確認）
全部まるごとリプレース（フルリプレース）のよくある失敗例
- プロジェクトメンバーが、急遽プロジェクトから離脱しないといけなくなってしまい、引き継が不十分でとん挫してしまう
- 仕様変更をしたいのに、詳細な契約を結んでいるため仕様変更ができない
- ITベンダーの技術力が不足しており、不具合が多く埋め込まれてしまったり、開発プロジェクトの進行に遅れがでて前に進まない
全部まるごとリプレース（フルリプレース）の成功事例
- 既存システムが古すぎて段階的な移行ができないため、全部丸ごとリプレースを実施する選択を行った。プロジェクト規模も2年を超えて大規模化し、困難を極めたがITベンダーとの密なコミュニケーションを継続できたおかげでリプレースを最後まで実施できた。
- 要件定義と仕様検討の段階でITベンダーと信頼関係が築けていたおかげで、柔軟な仕様変更等に対しても、お互いに納得の上でプロジェクトを進めることができた。
全部まるごとリプレース（フルリプレース）まとめ
| 方法 | 全部まるごとリプレース（フルリプレース） |
|---|---|
| 特徴 | ・既存のシステムを一括してリプレースする場合に用いられる手法 ・大きな予算が必要 ・開発工期が長くなりやすい ・1年以内で完了できそうなコンパクトなシステム向け |
| よく使われるシーン | ・様々な理由から既存のシステムの拡張が難しい場合 ・既存システムの老朽化が進んでおり、新しいハードウェアへの再構築が難しい場合 |
| 具体的なプロセス | １．ハードウェア更改 ２．リホスト ３．リライト ４．リビルド 大規模なシステムを一気に移行するのはリスクが高いため、下記の順で行うのが比較的安全 |
| スムーズに進めるコツ | ・ITベンダー企業と十分に仕様を擦り合わせる ・無理のないスケジュールと進捗の管理を行う ・予期しないメンバーの交代等への各種リスク管理を徹底する |
段階的なリプレースをする方法
段階的なリプレースのポイント
段階的なリプレースとは、リプレースに優先順位をつけて開発フェーズを分けながら、段階的にリプレースを実施する手法です。
2～3年に及ぶ長期計画の内容まで詳細に契約を結んでしまうと、その間の経営環境の変化への追従が難しい場合があります。
そのため開発内容を細かく区切り、契約を段階的に進めるこの手法は、比較的多くのケースで用いられています。
ただし、要件定義や見積を作成する機会が増えるため、場合によってはフルリプレースよりもITベンダーと密にコミュニケーションを取る必要があるでしょう。
段階的なリプレースのプロセス
ケースバイケースではありますが、ハードウェア更改、リホスト、リライト、リビルドまで一気に行う場合もあれば、リビルドにいきなり着手するケースもあります。各リプレースの行程では、要件定義、設計、実装、テストとフルリプレースと同様です。
段階的なリプレースのよくある失敗例
- 新規要件や要件変更が大量に出て、打ち合わせの時間ばかりが増え、プロジェクトのスタートが大幅に遅れた
- 柔軟な仕様変更に対応しようとしたために、見積作成や要件定義の行程がかなり増えてしまい、ベンダーとのコミュニケーションがうまくいかなくなった
段階的なリプレースの成功事例
- 特定のサブシステムがメモリ消費量超過によって最近頻繁にダウンするようになってきたので、搭載メモリ容量を追加して今後発生する問題発生を未然に防いだ
- 柔軟な経営環境への適応ができたため、次のフェーズにうまくつなげることができ、大きな成果が出た
段階的なリプレースのまとめ
| 方法 | 段階的なリプレース |
|---|---|
| 特徴 | ・開発案件を切り分け、段階的にリプレースする方法 ・予算をおさえやすく、着手しやすい ・年度をまたげば当年度と翌年度の2年分（場合によっては3年以上もあり）の予算からシステムリプレースの予算を捻出できるため予算獲得面で有利 ・経営環境の不確実な変化に対応できる ・プロジェクトをシンプルにできる |
| よく使われるシーン | ・既存システムを部分的にリプレースしていけるケース ・大規模な予算獲得が難しいケース ・現代のように経営環境が予測困難に変化しやすいケース |
| 具体的なプロセス | １．ハードウェア更改 ２．リホスト ３．リライト ４．リビルド 開発難易度によってはいきなりリビルドから始めるケースもある |
| スムーズに進めるコツ | ・基本的にはフルリプレースと同じ ・よりITベンダー企業と密なコミュニケーションを取る ・要件定義や見積の作成などをその都度、迅速に実施する |
システムのリプレースを実施したあとは
システムリプレースは、企業の事業展開の始まりであり、ITベンダーからすれば運用保守の始まりです。大きなIT企業に保守を依頼すると、予算面でかなり高額になるケースがしばしばあります。その分、品質の良いサービスを提供してくれるのが魅力です。
一方、地域の中小IT企業は、予算や仕事の進め方の部分で柔軟に対応してくれることが多いです。しかし、人員不足に陥っている企業に依頼すると、サービス面で不安が出てくる可能性があります。
そのため、大企業・中小企業を問わず十分な信頼関係を築ける地域に根付いたIT企業とのタッグを組むことができれば、その後の運用保守を含めて、長期的かつ戦略的な事業展開が可能になると考えています。
ITベンダーとの関係が成功・失敗の分かれ目
システムのリプレースは、一つひとつの企業の状況によってベストな手順が変わるため、他社のケーススタディはあくまで参考に過ぎません。
何より重要な鍵を握るのは、企業としっかり向き合い、お客様企業のことを深く理解してくれるITベンダーの存在です。
私は、これからの事業展開を一緒に考えていけるパートナーとしてのITベンダーの重要性がますます増大すると感じています。
これからの時代を歩む中小企業にとって必要なものは、デジタルトランスフォーメーションを実現するIT環境です。
その手前段階として、それらのシステムを作ったり組み合わせて提案できたりするITベンダーとの信頼関係をどう築いていくかが最も大切な要素の１つでしょう。
日本社会や地域をより良くするサービスを提供する企業に寄り添えるITベンダーとして、共に歩める関係をどうやって築いていくことができるかについては、次の時代を歩む必要がある私たちの世代にとっての大きな課題であるようにも感じられます。
