さった9月に公開された経済産業省の “DXレポート” は、業界関係者に “2025年の崖” という新たな課題を突きつけたものでしたが、盛り上がっているのは開発の仕事を請け負いたい一部の SIer にとどまっているようです。当のユーザー企業も含め、まだ多くの方が「知らない」という状況です。もしかすると「知りたくない（直視したくない）」という心理も働いているのかも知れません。
この課題は時間が経てばたつほど根本的解決は遠のく一方です。よって先にやり遂げたところが次の成長の足場を固めることができ、回避し続けたところは最終的にレガシーシステムとともに廃業するしかないだろうというのが私の読みです。もし現経営陣が、人手不足と後継者問題で廃業も念頭においているのであれば、システム刷新をしたくないという気持ちはわかります。ただ表面上はこの（内心の）決定をおくびにも出さないでしょうから、これから若手の従業員と、取引先は、企業のそのような動向に敏感にならざるをえません。つまりシステム刷新を避ける = 周囲から廃業の可能性を感じ取られる、という局面を迎えつつあります。
もちろん基幹系の刷新が大事業であることは言うまでもありません。それゆえに、もし刷新するなら最初に「骨太の方針」を定めることを提案します。これがあると、開発時に迷った時、関係者の拠り所となります。
そこで私が提案する方針は次の3つです。
1. 新システムのランニングコストを現在の半分以下にする。
2. パブリッククラウド環境で動作できるようにする。
3. 使い勝手のよさとは、シンプルであることという意識をもつ。
それぞれ詳細を説明します。
新システムのランニングコストを現在の半分以下にする。
最初に断っておきますと、外注を泣かせて人件費を切り詰めるということではありません。テクノロジーを駆使して、コストを削減する仕組みを導入するということです。その仕組みのためにお金を出しても、トータルのランニングコスト削減を実現できることが重要です。
まず現在のランニングコストを見える化することが先決です。これには年間のシステム改修費も含めてください。部分的な改修にどれだけのコストがかかっているのかを知ることが必要です。
よくある質問は、そのような仕組みを導入してしまうと、運用できる人材が限られるのではないか、またはそのような人材は人件費が高いのではないかという懸念です。この回答は次の通りです。まず人件費が高いのはむしろ喜ばしいことで、その分、良い人材に巡り会えます。また、高単価であるということは、他のエンジニアにとって魅力が高まり、この仕組み（技術）を学ぶ人が増えますので、人材難についても自ずと解消されます。安価かつ取り換え可能な人材を大量に配置するのではなく、取り換え難い優秀な人材を少人数集めるのが、ソフトウェア時代の特徴です。この点を是非とも経営陣にはご理解いただきたいと思います。
パブリッククラウド環境で動作できるようにする。
この理由はランニングコスト削減ではありません。いくつかの副次的な成果を狙っています。
パブリッククラウド環境という意図は、OSやデータベース、そしてJavaを含むミドルウェアのバージョン管理とセキュリティ脆弱性の問題をクラウド提供ベンダー（つまり専門家）に任せるということです。特にセキュリティ脆弱性は大きな課題であるため、そこを含めて面倒をみてもらえる PaaS 環境を利用できれば大いに助かります。
このためには、常に最新環境で動作するように、システムをこまめに「手入れ」する必要が生じます。具体的には E2E テストを充実させることで回帰テストの自動化を行い、デグレード回避の仕組みを整えることや、システム全体を停止させることなく、部分的改修（アップデート）を実現するためにマイクロサービスアーキテクチャを導入するといったことが求められます。
このような策によって、耐障害性も向上します。特定のクラウド環境に依存しないような標準技術を意識して使うことで、複数のクラウドプラットフォームでも動作させることができるようにしましょう。もちろん、そのような仕組みを構築した上で、あえて自社サーバで運用するという発想もありです。いざというときにはクラウド環境へ移行できるという選択肢があれば災害時にも安心できます。
蛇足ですが、これからの基幹系は「社内利用なのでセキュリティ脆弱性はあまり心配しなくても大丈夫」が通用しなくなります。特定の古いPC環境でないと動作しないなど、もってのほかです。最新のパブリッククラウドで動作し続ける = とりうる最大のセキュリティ脆弱性対策であり、企業の信用度に直結するということです。
使い勝手のよさとは、シンプルであることという意識をもつ。
現在の基幹システムの多くは、現場の声を重視して UI に多大な投資を行ってきました。これも見直す時期にきています。
まず「大量の入力項目を画面に配置して、オペレータの入力を楽にする」ための UI は、そもそも入力作業そのものをなくすという業務見直しとセットで考えるようにします。期待しているのは「AIベースのOCR技術を導入し、入力作業そのものをなくす」「他部署や外部から入力されたデータの再利用性を高め、入力作業そのものをなくす」「利用者自身がスマホなどでデータを入力できるようにする」といったアプローチとの組み合わせです。大量項目の入力作業そのものを削減し、システムの UI をシンプルに保つことが、結果的に使い勝手の向上になるという意識で UI を設計します。この設計という言葉は、業務フローの理解と改善を含んでいます。
次に RPA は過渡期の技術であるという自覚をもつことです。RPA には現行システムの塩漬けを助長してしまう側面があります。そもそものシステムが刷新され、業務見直しによって業務量そのものが削減できれば、RPA が稼働する領域は自ずと減少しますが、それが正解です。RPA は使い方によっては便利なので今後も有効な技術の一つですが、RPAありきではなく、業務の見直しが先であることに異論はないはずです。
もう一つ、シンプルさを維持するための発想は、複数のツール同士の連携です。データ連携には ETL を、複雑な業務ロジックの実装には BRMS を、データの可視化は分析ツールを使うとして、システムの作り込みを減らすようにします。繰り返しになりますが、このようなツールのライセンス購入費をかけてでも、ランニングコストの削減を重視します。シンプルになれば、大量のシステム保守要員を解放することにつながります。
まとめ：単一の巨大システムから、専用ツール連携を含めたオーケストラ的なシステムへ
この数十年間で多くのユーザ企業は、作り込み過ぎた基幹システムはランニングコストが増大するという法則を身を以て体験してきました。次の刷新で、同じ愚をおかしてはなりません。システム自体もマイクロサービスアーキテクチャ化するとともに、他ツールとの連携で作り込みを減らし、部分的な入れ替えを可能とすることで、「何十年に一度の作り直し」ではなく「毎日の手入れ」によって常に新しいシステムを維持し続けるようにします。
要は、次の刷新を最後と捉え、それ以降は DevOps 体制に移行して、毎日の手入れをアジャイルアプローチで行えるようにする、ということです。別の言い方をすれば、少人数で大規模システムを開発・運用できる体制を構築することです。
ちなみに、これを一気に行うことはリスクが高いので、骨太の方針を掲げたあとは、ロードマップを策定することを提案します。仮に2025年に目標とする体制を構築できること、とすれば、あと6年ちょっと。まだ間に合う、ぎりぎりのタイミングではないでしょうか。
この私案が、みなさまにとって 2025 年の壁を乗り越え、次の成長を担う基幹系を目指すストーリー策定の一助になれば幸いです。
