既存業務システムの改修は実業務の改善から。改善までのステップと注意点
システムの老朽化という問題を抱える企業は少なくないようです。IT技術は日進月歩の進化の早い分野ですので、ただでさえ技術刷新をせまられるスピードが早いはずです。ここには、日本企業のシステムとの関わり方という構造的な問題も関係しています。社内にシステム部を持たず、開発や改修は基本的に外注の日本企業には、システムに関するノウハウが蓄積しにくいようです。
この記事では、既存システム改修の進め方と注意点についてまとめてみました。
既存システムの改修が必要なケースとは
出典：経済産業省 デジタルトランスフォーメーションに向けた研究会
上記の調査は、約 8 割の企業が「レガシーシステム」を抱え、約 7 割が「レガシーシステム」というデジタル化の足かせを抱えている現状を明るみにしています。
DX（デジタルトランスフォーメ―ション）とは、デジタル化によって人々の暮らしをより良い方向に変化させることをいいます。企業はビジネスの版図をより拡大したいのに、既存システムが足かせになって、DXを実行できずにいるケースが多々あるのです。以下より詳しく説明していきます。
システムがレガシー化した場合
レガシーシステムとは「技術面の老朽化、システムの肥大化・複雑化、ブラックボックス化等の問題があり、 その結果として経営・事業戦略上の足かせ、高コスト構造の原因となっているシステム」と定義されます。レガシーシステムが足かせだと感じる理由には、
「ドキュメントが整備されていないため調査に時間を要する」
「データ連携が困難」
「影響が多岐にわたるため試験に時間を要する」
などがあります。技術面は老朽化しながらもシステムは肥大化・複雑化し、改修の費用対効果が実に低いのです。
ブラックボックス化している場合
レガシーシステムの問題の本質とは、技術の老朽化以上に「自社システムの中身がブラックボックスになってしまった」ことにあります。つまり、自社システムの中身が不可視化し、修正不可能な状況に陥ったことが問題なのです。
同資料によれば技術が古いとレガシー化するわけではなく、適切なマネジメントによりメンテナンスをおこなってきた場合は、ブラックボックス化しにくいといいます。しかし、開発から経過時間が長いとレガシー化の確率は上がり、仮に最新のクラウド技術を適用しても、時間の経過と共にレガシー問題が発生し得るという側面にも言及しています。
世の中の変化に対応するため
出典：経済産業省 デジタルトランスフォーメーションに向けた研究会
システム改修が必要なタイミングには、世の中の変化もあります。例えば、年号が令和になったり消費税が10％になったり、働き方改革で時間外労働の上限規制が設けられたりといった変化に、システムを対応させなければならない場合です。レガシーシステムでも、このような小規模改修は可能です。レガシー化についてもう一点言及します。上図は日本特有のユーザー企業とベンダー企業の関係性を表したものですが、同資料はこの関係性も、レガシー化の一因を担っていると分析します。日本は外部ベンダー企業に開発を委託することが主流なため、ノウハウはベンダー側にのみ蓄積されてしまうからだというのです。
システム改修の進め方
システムの改修は、新機能の追加やユーザーインターフェースの変更なども含みますが、いってみればユーザーの要望通りにすることです。ユーザー側から見たシステム改修の最も大きなメリットは、「既存のシステムをそのまま活用できること」です。コスト面、エンドユーザーの負担から考えても既存のシステムをそのまま使えると安心感があります。
以下、システムを改修する際の3つのステップについて紹介しますので、参考にしてください。
ヒアリング、現状把握
システムエンジニアによるヒアリングや現状把握は、システム改修において最も重要なフェーズだといえるでしょう。もしここで理解のズレがあると、開発途中の手戻りが生じることがあるのです。発注者はシステムエンジニアと打ち合わせをおこなう際に、既存システムの現状についてしっかり共有しましょう。また、改修の要望についても具体的に伝えましょう。ここでの内容が反映され見積もりが出るため、重要なフェーズです。
設計・開発
費用やスケジュールを確定させるのが「設計」です。開発では設計書に基づき、システム改修をおこないます。主にはプログラミングですが、完了後は単体テスト、結合テストなどを実施し無事に改修が完了したら、次に動作検証をおこないます。もし不具合があれば、修正をかけていきます。納品時にはユーザーテストをおこないますので、ユーザー自ら希望通りの仕上がりかチェックできます。
デグレードテストをおこなう
システム改修では既存システムのプログラムを書き換えますが、書き換えたことによりこれまで正常に動作していた部分が動かなくなってしまうことがあるのです。そのようなことがないかを確認するためのテストが、デグレードテストです。
デグレードテストはシステム改修の最終段階であり、必ずおこなわれます。プログラムの修正前と同じ環境を準備し、同じ結果が出れば、改修が完了していることになります。
システム改善の注意点
デジタルトランスフォーメーションの実現のためにはシステムの改修が必要ですが、レガシー化している場合のシステム改修は、莫大なコストと時間を要します。また、改修後のシステムでも、経年劣化による再レガシー化の可能性も、既に述べた通り存在します。
コストやリスクを抑制しつつシステムの改修をおこなうためには、どうすれば良いでしょうか。
ゴールイメージの共有
デジタルトランスフォーメーションの普及により、頻繁に新たなデジタル技術が登場すると考えられます。DX時代のシステムは、柔軟かつ迅速に社会のビジネス・モデルの変化に対応できる仕様になっている必要があります。このような視点を持たず、レガシーシステムの改修が単に自己目的化してしまっては、DX に対応不可で且つ、再レガシー化の恐れがあるものが完成してしまいます。ですので、改修に関わる全ての人がゴールイメージを共有することが必要です。
情報資産の仕分け
システムの刷新においては、不要な機能を廃棄していくことも大事です。レガシー化したシステムは肥大化と複雑化を重ねているので、情報の仕分けで軽減を図りましょう。情報という資産（リソース）は廃棄することに勇気が要るため、強い反対にあうこともあるでしょう。
前出の経済産業省資料には、情報資産分析の結果、半分以上が利用されておらず業務上止めても問題ないシステムだと判断され、廃棄に至った例もあったと記されています。このように、廃棄という選択肢もあるのです。
実業務の改善も同時におこなう
システムの中身や改修の方向を整理するのと同時に、実業務も見直してみましょう。時代は働き方改革の真っ只中にあり、業務改善で実業務の効率化を図ることはどのような企業にも求められている内容です。システムを新たに導入する場合でも、実業務の見直しは必須のステップです。業務改善を事前にしっかりとおこなうからこそ、システム化するべき部分が明確化できるのです。「業務改善を事前にしっかりとおこなう」ことは難しくとも、是非システム改修の機会を活かし、業務改善も並行しておこないましょう。
まとめ
先端技術としてのAIやVR（仮想現実）などが、企業の新サービスに導入されたというニュースを良く聞きますが、実際は多くの企業が古いシステムを長期間稼働させています。実際まだまだ使えますし、新システム導入のためにシステムが停止してしまうかも知れないリスクは取れないからです。新システム開発のコストも膨大です。既存のシステムを上手く活用していくしかないのですが、後世のためにも、システムに関するノウハウは可能な限り集約しておきましょう。