2022年もDX（デジタル・トランスフォーメーション）がアチコチで話題になっていましたね。
こんにちは！ 松田軽太です。
DXの大敵はなんといっても紙を主体としてアナログ業務といえるでしょう。
せっかくテレワーク環境が整っているにも関わらず、FAXや郵送される請求書は発注書を処理するためにわざわざ電車に乗って出勤を余儀なくされる経理課などの人たちはうんざりしたことと思います。
DXの敵は大昔に作られた基幹システム
しかしDXの敵はアナログ業務だけではなく、コンピューターシステムにも存在します。
それは大昔に作られて、何十年も稼働し続けている基幹システムです。
コンピューターシステムであるなら、そこで扱われるデータはアナログなハズはありませんよね？
それなのになぜ大昔に作られた基幹システムがDXの敵扱いされるのでしょう。
大企業の基幹システムともなると、その機能を多さ故に再構築にかかる費用は数十億円とか数百億円といった莫大な金額になるのです。
たとえばJALのシステム刷新は開発期間が7年、開発にかかった投資総額800億円を超えています。
その他にも日清食品でも40年、使い続けたメインフレームのシステム刷新に2011年から取り組み2017年に完了したそうです。
日清食品、40年使い続けたメインフレームを撤廃
日清食品がメインフレームを使い始めたのは1977年だ。直近では富士通製の「FUJITSU Server GS21 1400」を利用。
受発注システムなどの基幹システムは40年にわたってCOBOLで「手組み」してきた。長い歴史の中で、社内部門や顧客企業の要望に応じて作り込んだシステムは増える一方だった。
メインフレームで稼働するシステムは約60件、プログラム数は約2万本に及んでいた。
はっきりと開発費の金額は書かれてませんが、2万本のプログラムもある巨大なシステムなので、開発費が巨額であったのは容易に想像できますよね。
巨額な開発費といえば、みずほ銀行の事例を出さないわけにはいかないですね。
有名な事例ですからご存じかもしませんが、開発費は4000億円です。
あまりにも巨額すぎてピンと来ないからなのか、記事の中では「東京スカイツリーの建設費7本分に相当」と書かれています。
これらの企業の古くから使い続けている基幹システムの問題点は「このまま使い続けるにしても誰も全体像が把握できずに運用することができない」ということなのです。
長い年月をかけて、育ててきたためシステム自体が複雑怪奇に巨大化し、おまけに構築した当時の人たちは引退してしまい、誰も全体像が分からなくて、手をつけられないのです。
自動化ツールで書かれたプログラムは人が読むのは難しい
これらの基幹システムは大昔に開発されたCOBOL言語というプログラム言語で書かれていることが多いのですが中には開発の生産性をあげるためメインフレームにもCASEツールと呼ばれる自動生成ツールがありました。
しかしこれらの自動生成ツールで作られたプログラムソースは人が読むには辛いものがあります。
Excelのマクロ機能を使って自動的に書かれたVBAコードを見たことがある人はイメージできるかもしれませんが可読性は絶望的に低いのです。
リビルドとリライトとは？
では基幹システムを全面刷新するには、どのような方法があるのでしょうか。
よく言われるのが「リビルドか？リライトか？」です。
リビルドとは、古いシステムを捨て、現在の業務に合わせて新しく作り直すことです。
リライトとは、古いシステムで使われているCOBOLなどの言語を、イマドキのプログラム言語に翻訳し直すことです。
これだけ読むと、一見、リビルドの方が正解のように見えますよね。
しかしリビルドするための大きな問題は「古いシステムで動いている機能を把握することができない」という部分です。
いくら現状の業務に合わせるとはいっても、人が理解できるのは「入力」と「出力」の部分だけです。
入力は画面や取り込むデータを見れば分かります。
出力は帳票や更新されたデータを見れば分かります。
しかし、その中間でどんな処理がされたのかは想像でしか分かりません。
正しく理解するには膨大なプログラムソースを読むしかないでしょう。
なので、それができない場合はリビルドはリスクが高いのです。
もし社内に古いシステムを設計した人が残っていれば、謎の仕様の意味を聞き出して、今風に作り変えることができますが誰も分からないのであれば、とてもリスクが高いといえます。
ではリライトはどうでしょう。
リライトとはCOBOL言語のような古い言語をJavaなど他の言語に翻訳して置き換えることです。
これであれば機械翻訳も可能なので、運用コストの高いメインフレームから脱することはできます。
とはいえ翻訳しているだけなので、本来、必要としない機能もそのまま移行されてしまいます。
システム内部のブラックBOXが解消されるわけでもなのです。
しかしある意味、そのまま焼き直しているので「今と同じことはできる」というのが強みでしょう。
なので、実際のところはリライトを選択している企業も多いのではないでしょうか？
チャレンジするか安全策を取るのかの判断は難しいところです。
この辺りは自社だけでの判断できないのであれば、悶々と悩まずにベンダーやコンサルに相談して決めるしかないでしょう。
例外処理を調べるには早めにデータ移行してみると良い
リビルドであれリライトであれ、基幹システムを刷新するのであれば、既存データの移行は必要となるのでしょう。
なので新システムのデータベースを定義したら、古いシステムのデータを新システムのデータベースに移行してみるのをオススメします。
新システムのデータベースがまだ手元にないなら、Accessのような手軽なデータベースでもよいで、新システムと同じようにマスタやトランザクションを作ってみるのです。
そこに古いシステムから抜き出したデータを入れてみると、例外的な項目やデータがあって、移行した際にエラーになることがあります。
それがイレギュラー処理の証なので、それを実務担当者や設計者に確認してみるのです。
中には当時、そういう例外処理があったが、今はもう考慮する必要がないという場合も多いでしょうから。
データは嘘をつかないし、うっかり忘れることもないのです。
例外処理の有無を調べるには早めにデータ移行してみると良いでしょう。
いずれにせよ新旧のシステムを照合するしかない
このようにリビルドにはリビルドの課題があり、リライトにはリライトの課題があります。
いずれにせよ必要なのは新旧システムのデータを比較して、新システムで正しく処理されているかどうかを確認するしかありません。
最後の最後は答え合わせという地味な作業になるのです。
