レガシーシステムのマイグレーション

今回のお話は昔話から
以前務めていた会社は結構大き目の会社で自前で情報システム部門を持ち、システムのほとんどを自前で作るようなパワフルな会社でした。
2000年代頃は既に内製が厳しい時代だったので相当先進的だったと思います。
そんな会社ですら2020年代に入るとエンジニア人材の確保が困難になり、今まで作ってきた内製システムの管理コスト(100以上)が膨大になり内製化を諦めます。
システムは作って終わりではなく制作したツールのサポート終了などが予定されている場合は、サポート終了までにマイグレーションと呼ばれる「新しいツールによるシステムの作り直し作業」が必要になります。
その会社でマイグレーションツールとして選ばれたのはローコードツールでした。
ローコードツールはプロコードで構築するよりは工数が少ないというふれこみでしたが、結論から言うと社内のエンジニアはプロジェクト進行を担当し開発は外部業者に委託していたようです。
それでも何年もかかっていましたからローコードって本当にマイグレーションに向くのかな?というのが当時の正直な感想です。

しかし逆に言えば他人(他社)が構築したシステムを再構築するというのは相当難易度が高いとも言えます。
・仕様の確認
・プログラムの確認(確認した仕様通りに作られているか)
・不要な機能はどれか
・現在の業務に照らし合わせ本来必要な機能は何か
これがセオリーな進め方になりますが、それに加えて
・そもそもドキュメントが残ってない
・プログラムが動作しない
・古い言語のため読み解けない
・せっかく作り直すのだからと今まで我慢していた機能要求をユーザー様が盛りすぎる
・本来削除していい機能なのか悪いのか誰も判断できない
・結果コストと期間が膨らみ、社内稟議が通らない
などなどのトラブルが発生します。

従ってよつばがお勧めするのは「スクラップ・アンド・ビルド」です、一回更地にしましょうというヤツです。
もちろんデータは移行するのが前提ですが、古い仕様など拘っていても良い事など何ひとつありません。
車に例えるとエンジンもシャーシも内装も全て昔の仕様のまま新しくして欲しいというようなもので、最新技術で見た目だけ同じにしませんか?と言うのとどちらが良いでしょうか
車だと「音がー」とかあると思いますがシステムはそんな拘り必要ありませんしね。
是非マイグレーションをご検討される際は「捨てる勇気」も併せてお持ち頂けると良いと思います。

【今回の補足】
・レガシーシステム : 元々制作したツールがサポート終了しているシステムのこと、「動いているからいい」は少々危険な考え方で例えばOSのアップデートがきっかけで動かなくなってしまう事も可能性としてあり得ます。
・マイグレーション : (元々制作したツールがサポート切れを迎えるため)新しいツールによるシステムの作り直し作業。
・内製 : 社内で使う業務系システムを外注せず社内の人材だけで開発する方法、メリットはもちろん価格的コストと時間的コストを大幅に圧縮できること、リスクは人材確保と仕様継承です。
・プロコード : c#などのいわゆる「ザ・プログラミング」という昔からあるシステム構築方法
・ローコード : プロコードがほとんど全てを「コーディング」するのに対して「ちょっとだけ」コーディングすればシステムが構築できる基盤のこと。
・コーディング : プログラムコードをゴリゴリと書く作業、おそらく書いた事が無い方からするとプログラマさんがヒーヒー言いながら徹夜して書き上げるイメージかなと思います、全く違うとは言いませんが風評被害かなぁとも思います。