ITが重荷になってきており、DXへ進むのが困難（後編）

１．レガシーシステムが刷新できない要因

レガシーシステムの構成は、システムを動かすための主要なものとして、ハードウェア、ソフトウェアがあります。
また、内製、外製のいずれの場合にも、ドキュメントの整備状況が課題になる場合があります。

２．ハードウェア

ハードウェアはメインのサーバーと端末が対象になります。ハードウェアを長く利用されていると、途中で利用している機器の生産中止や部品の供給ができなくなってくるため徐々に保守の継続が難しくなってきます。

レガシーシステムと呼ばれるハードウェアは、当時は最新の設備であったものが、現在は最新型ではない、このような機器で構成されている場合が多くなっているでしょう。
コンピュータの性能向上は皆様もよくご存じの通り成長が続いています。また同時に価格の低減も進んでいますので、レガシーシステムと呼ばれる機器と、最新の機器では性能も価格も差がどんどん大きくなっています。

レガシーシステムと呼ばれる機器は、導入時の価格で運用や保守の料金が算定されます。そのため、導入年数が経過してくると、最新の機器の価格と導入時の価格差が大きくなり、運用や保守のコストにも大きな価格差となってきます。
最新の機器のコスト低減が、運用と保守の費用の差となって表れてくる理由がここにあります。

運用と保守はランニングコストであるため、設備のような一時金として目立った価格ではないため気が付きにくいのですが、ボディブローのように徐々に経費を圧迫することとなってきます。

また開発されたアプリケーションが、最新の機器に容易に変更ができるのであれば、低価格で高性能な機器に変更することでこの課題は解消されますが、特定の仕様の機器を前提に開発された場合には、機器の変更は容易ではありません。

このような点が、ハードウェアが重荷となってくる要因のひとつになると考えられます。

３．ソフトウェア

ソフトウェアは、前提となるハードウェアの条件に従って開発をされています。そのためハードウェアの変更は、開発されたソフトウェアの条件に合致するハードウェアに限定されます。
またサーバーと端末をつなぐネットワークも同様に、接続する構成をもとに開発をされますので、一定の条件の中でネットワークが構成されています。

そのため、ハードウェアの機種の変更や、内部ネットワークをする場合には、ソフトウェアの改修が伴うことになりますが、ソフトウェアの改修ができない場合は、ハードウェアやネットワークの変更ができなくなります。

レガシーシステムの課題は、いろいろとありますが、ソフトウェアの更新が根本課題となっていることが多いのではないでしょうか。

４．ドキュメントの課題

もうひとつレガシーシステムのソフトウェアの刷新を妨げる、隠れた要因をご紹介します。
それはドキュメントに関する課題です。

最初からすべて自社向けに開発をしてきたソフトウェアは、多くの工数と費用をかけて作られていますので、当然長期間に渡り利用をされることになります。

開発を依頼する側では、良いものを作るために、社内の要望をまとめたり、動作の条件を整理したりするのに注力するのですが、最終的なドキュメントの作成はついついおろそかになりがちです。

またソフトウェア開発をするときには、自社で開発する内製と、外部に委託する外製で開発する場合がありますが、内製、外製のいずれの場合もドキュメントの課題を含んでいます。

・外注開発の例

外注を使って開発する場合においても、実際に開発を担当しますと、時間に追われ目先の部分に多くの時間を割くことになってしまいます。
そのため、後から振り返ると次回の新規開発に重要なドキュメントの作成がほとんどできていないことになっていることに気づくこともあります。

しかしシステムが運用されはじめますと、運用の手直しやソフトウェアに不具合があった場合の対応など、この時も目先の部分に時間を割かれてしまい、さらにドキュメントの作成がおろそかになってしまうことになりがちです。

どんどん時間が経過し、目的のシステムが正常に稼働し始めたときには、ドキュメントの整備をするタイミングを失してしまうことになります。
でも現在のシステムに影響があるわけではないため、この時点でも軽視しがちになります。

新規開発では、このような内情を含んでいることが多いため、次回に備えたドキュメントを着実に作成していくためには、担当者のみの管理では非常に難しくなるでしょう。

長期に利用するシステムのドキュメントは、次期開発の資料として大変重要になりますが、見過ごされてしまいやすい項目で、注意が必要です。
そのため経営者が、次期開発を見通して、ドキュメントに割く時間を担当者に割り当て、ドキュメントの進捗を第３者の視点で確認することが重要になります。

・内製開発の例

内製でソフトウェアを開発する場合にも、ドキュメントの作成は、次回の新規開発で大変重要となるのにも関わらず、簡易なドキュメントの作成となっている場合も多いでしょう。
プログラムを作成する人も、プログラムの作成に注力してしまい、プログラム内の注釈がおろそかになる場合があります。

また組織では人の異動がありますし、退職で人がいなくなる場合もあります。
長期間利用されているシステムを新たに再構築しようとしても、ドキュメントがしっかり整備していないと、内部の設計が徐々にわからなくなってしまいます。

内製の場合も外注する場合も、新規開発後にシステムの改修がたびたび発生しますと、ドキュメントの更新はさらに困難になってきます。

５．レガシーシステム刷新の課題

レガシーシステムを刷新して更改を行うためには、既存システムの要件を把握する必要があります。
また、レガシーシステムから新システムに移行するための、新システムの要件整理や、新システムと既存業務フローの整合性なども、課題として挙げられます。

６．既存システムの要件整理

まずは当初開発を行った時の開発文書や、開発ベンダーから提供されている仕様書や納品ドキュメントの確認が必要です。

また度々システムの改修が行われている場合は、改修のドキュメント資料も整理します。

現状のドキュメントから、情報が十分に得られない場合は、実際の運用から以下の情報収集に取り組みます。

• 条件分岐を行う時の判断基準
• イレギュラー処理の対応方法
• 業務フローからシステム要件を整理
• 新システムの要件

既存システムの要件の把握の難易度が低い場合には、新システムの要件を整理して次に進めます。
しかし、システムの要件の把握の難易度が高い場合には、新システムへ移行する代替案として次の方法が考えられます。

• 現システムの要件の把握を時間をかけて実施し、最新のシステムへ反映する。
• まったく新たなシステムを導入する前提で、新システムを検討する。

前者は、多くの予算と時間をかけて進めることになりますが、既存システムの利用限界までの間に、十分な時間を確保し、早めに着手して進める必要があります。

後者は現システムの考慮が低くなりますので、業務フローの変更が大きくなる可能性があります。
そのため現在の業務フローを見直し、最善の業務フローを検討し新システムへ新たな業務フローを反映することで、大きな業務フローの変更に対し、社員の納得感が得られやすくなります。

７．新システムの検討

既存システムの要件の確認ができた場合は新システムの要件に反映していくことになりますが、新システムをレガシーシステムと同じようにすべてを一から開発する機会は、費用対効果の観点で少なくなってくると考えられます。

そこでクラウドサービスやERP、業務パッケージソフトなどの候補から、新規開発の負担を減らして、システムを身軽に移行していくことが重要になります。

８．業務フローと検討システムの整合性

レガシーシステムとパッケージソフトを主とした新システムを比較すると、画面まわりや操作の点で大きく異なりますので、利用者の運用に耐えられるかが大きな課題になります。
またクラウドの導入、ネットワークの活用、スマホや最新の端末なども、従来の提供環境も大きく異なってきていますので、新システムへの業務フローの適用作業がさらに複雑化します。

最終的には業務フローと検討システムのフローとの整合性を、どの程度マッチできるかが、導入後の運用に大きな影響を与えますので、この点がポイントになります。

レガシーの既存システムが重荷になっている状態は、費用の側面よりも、内部に隠れている要因が実は重荷になってきていることがあります。
長期間のシステムが重荷になっている場合、様々な側面から新システムへの移行の障害となりそうな個所を洗い出して、課題を詳細化してみてはどうでしょうか。

最後までお読み頂きましてありがとうございます。今回のコラムが皆様の何かのヒントになれば幸いです

コラム更新のお知らせをお届けします。ぜひご登録ください。