緊急投稿!! 2025年の崖対策について

2025年の崖対策

「待ったなしの2025年の崖、
いかに乗り越えるか」

代表取締役社長
鈴木　孝一

緊急投稿!!
「待ったなしの2025年の崖、いかに乗り越えるか」

(出典: 経済産業省)

本稿は経済産業省から2019年3月に発信されたDXレポート（ITシステム「2025年の崖」克服とDXの本格的な展開）に対して、この具体的な解決策を記述しました。これからの企業のIT化は、ユーザーのかかわり方次第でシステムの良しあしが決まると言っても過言ではありません。DX導入が成功した企業では、システムがビジネスを牽引することになります。そのためにユーザーは、DXを専門家任せにせず、自らが理解可能な進め方で推進する必要があります。最新のIT用語に惑わされず、DXの本質を理解するために、本稿ではブラックボックス化の原因を明らかにした上で、この解決策について具体的な記述をしています。今後企業で中核を担われるユーザーやSIerの方々には必見です。本稿を参考にDX化を実りあるものとして推進していただけましたら幸いです。

本稿は、3章から成り立っています。崖の背景、原因、対策です。レガシーシステム（基幹システム）の問題点の詳細についてお知りになりたい方は、弊社経営陣コラムを参照ください。

1. 崖の背景（なぜITがビジネスの足かせになってしまったのか）

IT導入前の企業の事務作業は、各店舗や本部が事務マニュアルに基づき、これを遂行することで成り立っていましたが、各現場の事情もあり、事務の進め方についてはバラツキが大きかったのです。そこにITが導入されたことで、注文から精算、帳簿管理などの事務作業が大幅に合理化され、同時に統一されました。その後各店で行われていた作業は、事務センターに集約され、コールセンターの利用により店舗の合理化はさらに進みました。90年代に入るとインターネットが普及、さらに携帯電話の浸透から、注文は社員ではなく、コンシューマが直接入力する時代へと大きく変化しました。
システムの側面からみると1960年代からホストと呼ばれる大型コンピュータが導入され、次にサーバと呼ばれる分散コンピュータとPC併用の時代へ、1990年代に入るとインターネットの普及によりWeb技術の利用が拡大、さらにサーバ統合、仮想化技術を経て、ハードは保有からクラウド利用の時代へと一気に進みました。さらにソフトウェアを時間単位で課金するサブスクリプションタイプのサービスも出てきています。

それにも拘わらず何故２０２５年の崖問題は存在するのでしょうか。ITは確実に進化しているではないかと思われる読者が大半かと思いますので、ここを詳しく説明します。ITが進化したのは、IT系の会社に取って売り上げにつながりやすく、コンシューマ受けするところが進化してきました。したがってインターネットから入力されたデータ処理以降の社内事務システムなどには、ほとんど手が付けられませんでした。ハードは、ホストからサーバにダウンサイジングされましたが、アプリケーションはそのまま放置されました。これをメンテナンスできる技術者が2025年でいなくなるという問題です。そんなこと前から気付いていたのに、どうして手を打たなかったのかとお思いでしょうが、それがそう簡単には解決できない理由があるのです。詳しくは経営陣コラムをご覧ください。

長年これで済んだのだからこのままでいいだろう。どこがビジネスの足かせになると言うのか。そのように思われている方が多いかもしれません。残念ながらこれを放置すればシステムが早晩破たんすることは避けられません。その理由は、現在稼働しているレガシーシステムの要件定義は、IT導入前の事務システムがベースであり、実はそこから屋台骨となる企業システムは進化を止めているからです。何か新しいビジネスを始めるにも、4,50年前のビジネスモデルを前提としたシステムでは、これ以上時間とカネをかけても対応が出来ないところまできていることを意味します。

2. 崖の原因（なぜ進化するITでこのような問題が解決できないのか）

DXレポートでの刷新後の基幹システムのポイントは、メンテナス速度の向上とユーザーのかかわり向上の2点としています。メンテナンス速度の向上とは、ビジネスへの追随性の向上を意味し、それがDXの本質とも言えます。システムは足かせどころか、それがビジネスをけん引していかなければなりません。ところが現状のシステム構築は、まず要件定義から始めなければならず、目的が定まったシステムを作成する手法に則ってシステム構築が進められています（ウォーターフォール型）。この手法では要件が途中で変わると手戻りが発生するため、要件の凍結期間が設けられ、凍結はシステム構築完了まで続きます。大きなシステム構築では1年以上を要しますから、DXレポートにあるメンテナンス期間の数カ月を数週間にすべきとの要件は、構築の段階からこれが実現できていないことになります。

と言うことは、要件定義は必要だが、途中での変更には、いつでも応えられるようでなければ、DXレポートの要件を満たしていないことになります。最近では開発単位を小ぶりにして段階的に実施していくアジャイル手法がとられることもあります。残念ながら、その事例の多くが画面周りのアプリケーション開発などが主で、基幹システムでの実績はほとんど聞いたことがありません。なぜなら基幹システムでは、各システムとの連携も多く、段階実施を重ねるに連れ、影響テストの時間が膨らみ、最終的には、従来方式よりも時間がかかってしまう可能性もあるからです。DXレポート要件に応えるためには、要件変更が容易で、影響範囲が限定的で明確、誰が見ても理解できるなどのシステム要件を満たす必要があります。

一方で、システムは作るのではなく、パッケージの導入や、サービス利用でよいのではないかとの声も聞こえますが、これらのシステムの構築手法のベースはウォーターフォール型ですので、これに自社流のカスタマイズを行えば、これまで同様の問題が発生してしまいます。これらの問題解決策としてプログラム言語に問題があるとの話しが出てくることがありますが、開発がいくら早くても、分かりやすくても、これは残念ながら本質的な対応にはなりません。

次章で、これらの要件をどのように解決したらよいかの実例を説明いたします。

3. 崖の対策（進化するITにも盲点がある）

最新のITは、PCやスマートフォン端末からの入力に対して、結果を返すリアルタイム処理を中心に進化してきました。その裏にはデータ管理システムがあります。これがデータベース（DB）です。DBの役割は、外部からのランダムな要求に、該当データを検索してレスポンス良く応えなければなりません。さらに座席予約や決済などデータの整合性を担保する機能も備わっています。ところが2025年問題となっているのは、日々入力されるデータを蓄積し、事務毎の締め日に合わせて行う処理や、日次、月次、四半期などの営業管理や管理会計処理など、いずれも蓄積された大量データに対して、多段階で加工を施す必要がある処理です。これらの処理では、投入されるデータ毎に結果が求められるものではなく、全件処理後の結果が求められることが多いのもその特徴です。処理途中のデータによるデータ同期は不要で、スループットの向上が求められるためDBの利用は向いていません。従ってユーザー要件のシステム化をアプリケーションと独自のデータ管理で行ってきたため、この領域の技術進化は遅れてしまいました。

また、この領域のアプリケーションは古くから稼働しており、メインフレームやオフコンを供給しているベンダーのエンジニアによってユーザー企業のために個別に構築され、ビジネスの要請に合わせて部分的な改修を繰り返してきたものです。また、改修にあたっては、機能やデータの棚卸をしないまま、直近の要請に最低限の労力で対応することが優先されてきたため、プログラムにアドホックな処理を追加することが繰り返されてきました。これが、基幹システムがスパゲッティ化してきた原因です（詳しくは経営者コラム：基幹システムのスパゲティー化の真犯人を参照ください）。ユーザーにはその仕組みや内容がわからずブラックボックスとなっているため、改修要請に対するITベンダーの対応（実現可能/不可能の判断、改修方法、改修コスト）が合理的であるか判断できません。今後、DXを見据えた更改を行うにあたっては、この轍を踏むことを避けなければいけません。

以上から、2025年の崖については、新しいIT技術の対応が盛んなリアルタイム処理よりも、それ以外のシステムにおいて問題が深刻であるといえます。しかも実際に、AIや機械学習はリアルタイムデータではなく蓄積されたデータで成り立つわけですから、DXを進める上ではこれら蓄積データをいかに活用できる状態にしておくかが重要になってきます。この問題を解決する手段の一つが、基幹システムのフロー処理で利用されているファイルシステムの自由度向上です。システム要件定義では、序盤でデータ項目内容やデータ項目長などファイルレイアウトの決定が行われます。システム構築中に、レイアウトレ変更を行うことは容易ではありません。これが可能となれば要件定義の自由度が格段に上げられるばかりでなく、プログラムによる暫定的な回避処理を行う必要がなくなります。

また意外と知られていないのが、事務処理とプログラミングの関係です。人が介在する事務処理では、全体をコントロールしやすい業務処理完結単位で作業が進められています。このようなプログラムでは、入力データごとに多段階で処理を選択しながら、最終的な処理結果を出力する記述が一般的です。したがってあるデータに対して処理工程をトレースすることが容易ではありません。少し特殊な処理を行いたい場合、マニュアルでもわからず、データの入力の方法が分からず調査するということはよくあります。メンテナンスを行う度に複雑さが増すため、システム処理全体への影響試験に時間がかかるのはそのためです。今後のビジネスでは対象顧客ごとに、AIによる判断などの活用を考える必要がありますが、従来の記述方式ではシステムへの組み込みはきわめて困難です。

それではどのような記述を行えば、この問題を乗り越えられるのでしょうか。その答えは現在の人ベースの業務処理完結単位にあります。これをまずコンピューターベースの単一処理に分解して記述することです。コンピューターベースの記述では、人が行う合理性を気にする必要がありませんから、処理を分解することでの面倒など気にする必要がありません。さらに必要がない処理ならば取り払うことも容易です。このような処理分離型の記述では、処理を行う前処理として、ターゲットを明確にする処理が必要になります。ここが従来のシステム処理とは大きく異なる点です。これによって処理ターゲットが明確になり、ターゲットのいない処理は不要と判断できますので、システムの棚卸が随時行えることになるのです。

さてここまで2025年の崖を乗り越えるための作法や技術に触れてきました。最後にユーザーとシステムのかかわりについて簡単に触れておきたいと思います。単純にSIerがユーザー部門に移っただけでは、これまでの問題はなんら解決できません。システム提供者とユーザー（利用者）とでは明らかに役割が違います。ユーザーの目的は、システムを使って企業活動を効果的にコントロールすることです。ビジネス変化への対応を、プログラミングでこなしていては、もはや間に合いません。その為にはプログラミングに頼ることなく、外部からの指示でシステムがコントロールできるようにしなければいけません。システム提供者は、必要のなくなった処理やデータの整理を行い、システムを常日頃整理しておく必要があります。必要があれば新たな仕掛けも用意する必要があります。ビジネスに柔軟に対応出来、かつコントロールが可能なシステムとすることが、次世代のシステム要件として求められることになります。前述しましたAIや機械学習による判断を、システムに組み込むためにも有効となります。2025年の崖対応は、企業にとってピンチではなくチャンスです。この機会を前向きにとらえて、基幹システムを厄介者から、次世代に通用するビジネスを牽引する仕掛けにしていきましょう。本稿がみなさまの会社の基幹システムDX化の一助となれば幸いです。