“2025年問題” という提起によって、いよいよ我が社も基幹系刷新を検討せざるをえないかも...しかしトラブルになることはわかっているし、できるだけやりたくない、という気持ち、よくわかります。自身の理解を超える、複雑すぎるものを目の前にしたとき、何から手をつけていいか途方に暮れますよね。
ということで、もし私がこの課題に向き合うとなったときは、次のような基本方針を掲げたいという内容を整理してみました。
DXの支援を最優先とする
毎日のように “デジタル” に関する新技術のニュースが発表される中、自社はどういう立ち位置で、どういう技術を使って（自社の）ビジネスを再定義すべきかは難しい課題です。この再定義のことを "トランスフォーメーション” と呼んでいますが、2025年や2030年という将来を考えた時、企業の売り上げ構成比率の多くは、トランスフォーメーションした側にシフトしているはず、というのが現時点での読みです。これが合っているかどうかの議論はさておき、経営陣がそのような方向性を打ち立てるという前提で、基幹系はDXの支援を最優先とします。
具体的にはどういうことか。まず社内ユーザを想定した、伝票入力というインタフェースの重要性を下げます。その代わり、消費者に直接向き合うであろうスマホアプリのユーザインタフェースへの投資を厚くし、基幹系へのデータ入力は API 経由になることを前提とします。そしてもう一つは、DX側との距離を縮めるため、基幹系はパブリッククラウドで稼働するようにし、かつオートスケール環境で運用します。
もちろん現在の基幹系はほぼ、そうなっていません。よってDXを支援する基幹系はほぼ新規開発になります。どうつくるか、というのは別の議論としますが、この基本方針では既存資産とは別に、新規開発分野がある、ということを明確にします。
既存業務の EOL を明らかにする
企業による DX の推進が進んだとしても、当面は売り上げ構成の大半は既存業務で構成されています。しかしDX化される領域が広がるにつれ、既存業務は縮小され、最後は停止することが想定されます。そこで既存業務を洗い出し、それぞれの End Of Life (EOL) を検討します。この目的は次のとおりです。
- 再開発せずに寿命がくるまで現行を維持するものを取捨選択する。
- 売上への貢献度は低いが残さざるをえない業務の分岐点を見つける。202x 年から、この部分のシステム維持費を増額するとし、利用部門にコスト意識をもってもらう。このアプローチは、結果的にその業務の廃止を早める可能性にもつながる。
- 捨てるものと維持するものに分けたあと、後者について市販パッケージに置換するのか、再開発するのかという議論につなげる。
稼ぐ基幹系へ転換する
DXに近いところで稼働する基幹系はすべからくAPIを提供するでしょうから、このAPIを外部に開放して課金するといったビジネス化を指向することは可能です。そうではない業務も仮に再開発するなら、業務の利用ログから仮想的に「社内ユーザ向け利用料金」を細かく算出し、システムコストを見える化できるようにします。AWS が提供するサービスのように、業務機能ごとに低い料金を設定するというイメージです。これによって基幹系を「売上への貢献」と「（見える化による）経費削減」の両方に対応させます。
私がここにこだわる理由は、現在の基幹系の運用コストが不透明であるがゆえに経営陣からの評判がよくない、という現状を憂いているためです。仮にそのせいで情報システム部の地位が低いのだとすれば実にもったいないことです。ただ、これまで不当に扱われてきたことへの意趣返しで数値化するぞ、ということでもありません。基幹系に関する開発や運用コストの見える化こそが、基幹系自身のDXにつながると考えています。（自分自身もDXの対象にするという発想ですが、これは長くなるのでまた別の機会に書きます。）
もう一つ、基本方針に取り入れたくないもの、があります。それはハードウェアのリース切れや保守切れに伴う、現行システムの焼き直しはしない、というものです。ブラックボックスの状態のまま、例えば COBOL を Java に変えて現行システムを維持する、というのは、私にはどうしても無駄に感じてしまいます。その次元とは別の視点から、基幹系のあり方を捉え直すことが求められているし、今はその絶好の機会である、と考えています。
