お役立ち情報
現行システム調査が重要と言われる理由。具体的な分析調査方法について解説

システム開発お役立ち情報

公開日:2023.06.08　更新日:2025.09.14

現行システム調査が重要と言われる理由。具体的な分析調査方法について解説

1 現行システムが置かれている状況
- 1.1 2025年の崖
- 1.2 レガシーシステムの老朽化
2 現行システムの調査が必要と言われる理由
3 現行システムの再構築方法
4 まとめ

昨今、企業に導入した現行システムの複雑化や老朽化、レガシー化、肥大化などで、企業の競争力が低下していることが問題視されています。これは各部門に導入されたシステムが、継ぎ接ぎのように、個々に機能拡張されたり、将来のシステム全体の在り方を定義・設計せず、自由にカスタマイズされたりした結果によるものも一部あるかと推察します。

また運用や保守などを行っていくためには、IT人材を確保する必要があります。しかし社会全体が人材不足という課題を抱えている現状においては、IT人材を確保していくことは非常に難しい状況です。

このような現行システムが抱えている問題を解消するためには、再構築したり、新システムに切り替えたりするなどの抜本的な対策が必要と言えるでしょう。

この記事では、現行システムを取り巻く状況、調査や分析、再構築の方法などについて紹介します。

現行システムが置かれている状況

現行システムでは、開発した後に機能追加が繰り返し行われています。そのため、つぎはぎ構造になっていることが考えられるでしょう。そのような状況を放置し、そのまま使い続けることで起こりうる問題を予測したのが「2025年の崖」です

2025年の崖

2025年の崖とは、現行システムを今まで通り継続して使い続けることで企業の競争力が低下する状況を示した言葉です。2018年に経済産業省がまとめた「DXレポート」にて定義されています。DXレポートで挙げられているのは、次のような課題です。

・部門ごとに独自に構築されたシステムが個別に稼働しているため、全社で横断的なデータ活用ができない

・仕様変更や機能追加などが繰り返されてきたことでプログラムが複雑になってしまい、ブラックボックス化している

・現場サイドからの圧力が大きいため、システムの問題解決や業務の見直しができない

これらの課題が解決されないまま継続して使用されていた場合、2025年以降に年間で最大12兆円の経済損失が発生する可能性があるとされています。

参考サイト：経済産業省「DXレポート」

レガシーシステムの老朽化

レガシーシステムとは、開発されてから長い年月が経った古いシステムのことです。開発後に仕様変更や機能追加が繰り返されている場合が多くあります。そのため内部の処理が複雑化していたり使われている技術が古かったりと、さまざまなリスクを抱えている可能性が考えられるでしょう。

しかしシステムを停止させてしまうと業務に影響が出てしまうため、容易に停止することはできません。特に企業活動の根幹を担うシステムがレガシーシステムのため、日々システムが使われている状況です。

また運用や保守のために貴重なIT人材が割り振られており、企業のIT戦略といった将来への投資が滞っている状況も考えられるでしょう。

経済産業省の「DXレポート」では、約8割の企業がこうしたシステムを抱えており、運用や保守のために貴重なIT人材が浪費されているとの指摘があります。このように企業成長の足かせとなっている場合が多いと言える状況です。

現行システムの調査が必要と言われる理由

現行システムを更新したり刷新したりする場合、現行の仕様や問題点、課題などを把握しておく必要があります。これらを正確かつ網羅的に把握していないと「システムを更新したが使い物にならない。」といった事態を招きます。またユーザーがどのような使い方をしているのかも、把握しておく必要があるでしょう。

そのため仕様書や設計書、関係している人へのヒアリングなどを行い、情報を得ることが重要となります。

現行システムは開発されてから長い年月が経っているため、内部がどのようになっているのか誰も把握していない「ブラックボックス化」の状態です。さらに開発時の仕様書や設計書が残っていない場合も多くあります。調査を行う場合は「ブラックボックス化」している部分を一つずつ明確にしていくことが大切です。

現行システムの再構築方法

現行システムが老朽化してくると、保守や運用のために多くのIT人材を投資する必要が出てきます。そのため企業の競争力を高めるためのIT戦略が、滞ってしまうことが考えられるでしょう。現行の課題や問題点を解決しIT戦略を推進していくためには、システムの再構築が解決方法の一つとなります。

再構築とは現行のソフトウェアを流用するのではなく、新しい環境で最初から作り直すことです。再構築することで現行の構造にとらわれることなく、柔軟にシステム開発を進めていくことが可能となります。

現行システムの調査・分析

再構築では、現行システムの仕様や使われ方を把握しておく必要があります。現行に存在していた機能が再構築後には使えなくなったのでは、再構築の意味がありません。また再構築後に使いにくくなったという事態も避けるべきです。そのため現行の機能やユーザーの使い方、データの流れなどを詳細に調査したり分析したりすることが重要となります。

現行システムの調査や分析を行う場合、ドキュメントを参照することが多いでしょう。ここで注意すべきは、ドキュメントが必ずしも正確であるとは限らないということです。

本来であればシステムの機能追加などで改造が行われると、ドキュメントも追従して更新する必要があります。しかしシステムの更新は行ったが、ドキュメントの更新が行われていない場合が多いのも事実です。

そのため現行の調査や分析は、ドキュメントだけでなくソースコードも参照することが必要になります。さらに調査や分析した結果はドキュメント化し、現行の仕様として残しておくのが良いでしょう。

新システムの要件定義

再構築の要件定義は新規に開発する場合と比較すると、あいまいになる可能性が高いです。現行の仕様を踏襲する形となるため、ユーザーからは「現状の仕様のままにしてほしい」といった要求しか出てこないことが多くあります。

しかしその言葉のままに進めてしまうと、新システム完成後に「以前はできたのに再構築後はできなくなった」というクレームの対象になることが考えられるでしょう。そのためユーザーと開発側で認識を一致させる必要があります。正確で詳細な要件定義を行うことが重要です。

必要な機能と不要な機能をユーザ目線とシステム専門家目線の両方から洗い出す

要件定義を行う際、現行システムの使用状況を踏まえるのが良いでしょう。現行に搭載されている機能でも、実際ユーザーが使っていない機能は不要です。不要な機能を盛り込むと、その分システムが複雑化してしまいます。現行に存在している機能をすべて踏襲するのではなく、必要な機能と不要な機能を分類して不要な機能は廃止することが大切です。

一方、現行システムに無くても、ユーザーが要望している機能があれば追加すべきでしょう。ユーザーからのヒアリングにより、新規に追加した方が良い機能があるかどうかを見極めることが大切です。

システムを実際に利用する部門・担当者の参加

要件定義の際には、実際にシステムを使っている部門が再構築に参加することが重要となります。実際に現行システムを利用してきた知識や経験などを、新システムに反映するためです。利用状況はドキュメントからは適切に把握することができません。

システムを使っている部門がプロジェクトの初期段階から参加することで、次のようなリスクを減らすことが可能となります。

・新システムが要件を満たさない

・使い勝手が悪い

・利用状況に沿わない仕様になっている

新システムで再構築

再構築は、現行システムの開発ベンダーではなく新しい開発ベンダーが担う場合があります。新しい開発ベンダーの場合、現行システムの仕様に関して不明点などが発生する可能性もあるでしょう。そのような場合に備えて、現行システムを担当した開発ベンダーに協力してもらう必要があります。

ベンダー同士の取り纏め

新システムの再構築プロジェクトには、新システムを担当する開発ベンダーだけでなく、現行システムを担当した開発ベンダーにも参画することが大半です。現行システムを担当した開発ベンダーに協力してもらう場合、次の業務があります。

・現行仕様の解析サポート

・現行のデータを移行するためのプログラム作成

・段階的に新システムをリリースする際の現行システム側のカスタマイズ

また現行システムと新システムのベンダー同士では利害関係が影響してくるため、ベンダー間のやり取りは発注するユーザー企業が取りまとめるのが良いでしょう。

各種リスクの対処

システムの再構築では、数多くのリスクが隠れ潜んでいます。プロジェクトを開始する際はあらかじめ潜在リスクを洗い出し、それらの対処法を決めておくことが重要です。そうすることで実際にリスクが発生した場合、適切に対応することが可能となります。

また洗い出したリスクや対処方法に関しては、プロジェクトの関係者間で共有しておくことも大切です。

まとめ

今回は現行システムの取り巻く状況、調査や分析、再構築の方法などについて紹介しました。システムの再構築で重要となるのが現行システムの調査と分析になります。仮に表面上でしかシステム構成やシステム状況を把握しないまま、再構築プロジェクトを開始してしまうと、仕様の漏れや不備、認識の不一致などが発生してしまいます。プロジェクトの終盤で発覚した場合、後戻りするにも膨大なコストと時間が必要となるでしょう。残念ながら、このようなケースは多く見られるのが現状です。

新システムへの再構築を滞りなく行い、仕様の食い違いや機能の漏れなどが無いようにするためには、詳細な調査と分析を怠ることなく、システム専門家を入れながら作業を進めるようにしましょう。