デジタルツインによるシステム移行の自動化

新卒社員にCOBOLを習得させて現場に投入していいのか

タイトルからして興味深い記事だが、当然ながら筆者の結論は「否」だ。その理由は「他に学ぶことが沢山ある」ということらしい。だが2ページ目からは無駄なドキュメントの話になったりして、文章全体から言いたいことがよく分からなかった。

個人的には、もっとシステム移行技術はまじめに研究されるべきだと思うし、解析の自動化やAI化といった技術を発展させ、COBOLのようなベーシックな言語は覚えなくても済むような世の中になってほしいと思う。COBOLよりもC#だGoだというのは五十歩百歩であって、コード自動生成や自動検査などこそが真に未来的なシステムだと思う。

もちろん、そこまでの道はまだ遠く、それだけを志向して勉強するのは時期尚早ではあるのだけれど、思いの外早くその時代は来るかもしれないとも思っている。システム移行ではなく自動再構築をする方向性がその答えだ。

現行システムのエミュレータを作ること自体は、原理的には難しくない。難しいのは同じ処理速度、同じか安いコストを満たすことだが、この条件を緩和すれば可能なはずだ。これをまず、現行システムのデジタルツインとして構築する。

これは、メインフレームのハードウェアをエミュレーションで作り、その上に同じソフトを構築することで作成される。但しI/Oなど性能での条件は緩和し、つまりは遅くてもよいことにする。忠実に再現できることが最優先だ。

デジタルツインがあれば、幾らでも並行してテストや解析が可能になる。そこで、これと全く同じ入力出力を行いアーキテクチャが最新である、というシステムができればよいことになる。だが実際にはもう一つ条件があって、将来的な仕様の修正が可能である必要がある。完全なブラックボックスではダメだ。

このためには、いきなり新しいシステムを作るのではなく、デジタルツインの仕様を人間可読な形式で出力する必要がある。つまり、ブラックボックスたるデジタルツインの仕様を仕様記述言語で吐き出すシステムと、仕様記述言語から新しいアーキテクチャにシステム構築をするシステムがあればよいことになる。

仕様を修正したいときは、仕様記述言語になった段階で修正を加えればよい。これは何度でもできるので、システム修正自体も今後は楽になる。その代わり、コンパイルした後のシステム構成は都度変わる可能性が高く、そのためにも対象アーキテクチャはパブリッククラウドになるだろう。

また、仕様記述言語自体も変化する可能性があるが、一度変換ができてしまえば言語間移行だけで十分であり、旧システムをデジタルツインにして解析する必要はない。これも将来的な移行コストを低減する。

仕様記述言語の候補としては、現在既に稼動しているコード自動生成ツールのソースが挙げられるが、まだまだ不足しているだろう。ここの言語設計が、移行コスト低減に直結する。

完璧な仕様記述言語などというものは、バグのないプログラムと同様にあり得ないように思える。だがそこはそこ。システム分割して部分的に適用するなどができれば、そこだけでもエンジニアの負荷が減るというものだ。

ここで一番難しいのは、デジタルツインから仕様言語への変換である。デジタルツインは仕様だけでなく実装を含んでいるから、ソースを解析できたとしてもそれが仕様なのか実装なのかの見極めが困難だからだ。また、システムの機能性能を見越した暗黙の省略、例えばバッチ処理には時間が掛かるだろうからセマフォでなくタイマで引っ掛けようとか、COBOLの十進法の誤差や型変換時の仕様を利用したプログラミングなどを見抜くのは困難だろう。

ここは、コード解析をするのではなく、入力と結果のみを見て仕様を推測する、という手法をとることが考えられる。このために専用のテストデータを用意し、いちいちリセットしながらシステムを動作させる。例えば住民の税額の計算なら、基礎控除の前後、税率が変わる前後で収入を変化させながらデータを流し込んでやる。簡単なシステムならこれだけで完成するし、そうでない場合でも部分的には仕様が完成する。

内部で複雑な操作を行った後に初めて出力するようなものではこの方法は使えない。そのため、中間情報たる内部状態やデータベースの値を使って確認する。これを使うと厳密には仕様だけでなく実装が混じってしまうが、最初は止むを得ない。

システムの分割はもちろんできるだけ細かい方が良いし、外と通信するならそれも解析のための情報として使える。だが完全に無人解析するのは当分先の話になるだろう。

将来的には、これらには一括してAIが補助に使われるものと思う。税なら法律文書があるからそれを参考にするとか、行政サービスならWebの解説を参考にするとかができるようになれば、人の仕事はずいぶん楽になるだろう。