はじめに
前回レガシーシステムの解決法として、あえて書き換えにほとんど触れずに記事を作りましたが、 今回は書き換えをやっていくぞ!という記事を書きたいと思います。
IT企業の現場の方であれば本来はこちらをやりたいのではないでしょうか? どうやってリプレイスまでもっていくか、何にリプレイスするか?など記載したいと思います。
古いからリプレイスしたいです!→なぜ?
前にも似たようなことを書きましたが「古いから」「わからないから」は「御社の都合でしょ?」 となりますよね。
それでも強行することはできるとは思うのですが、継続してもらえるかは別問題となってしまいます。 相手にそれなら・・・となってもらうためには相手へのメリットが必要でしょう。
例えば
- 今後端末を変えても導入の手間・費用がかかりません
- 操作の手順が少なくなり業務効率化になります
- ランニングコストが下がるため、XX年後を比較すると安くなります
など、何かしらの提示がなければ同意してもらえないものです。
なにでリプレイス開発すればよいか?
ほとんどの場合、COBOLやVBAでの開発が行われたシステムに課題を持っている方が多いと考えています。
その上でリプレイスするのであれば基本的にフレームワークでの開発を行うこととして、
①ローコード・ノーコードフレームワークを使用する。
②C#.Netなど企業が提供しているフレームワークを使用する。
③OSSのフレームワークを使用する。
それぞれ課題があり、自社にマッチした方針をとる必要があります。
①ローコード・ノーコードフレームワークを使用する。
基本的に開発者の確保がしやすい。
ライセンスなどの費用が発生する。 これまでできていたことを完全再現できるとは限らない。
②.Netなど企業が提供しているフレームワークを使用する。
開発ツールとしてVisual studio、その他Activereportなどのツールも使用でき多種要件に対応できる。
それに伴いライセンスなどの費用が発生する。
C#の開発者は比較的多い方である。
③OSSのフレームワークを使用する。
費用が安い反面、プログラムに対する深い知識を要するため学習コストがかかる。
Webアプリケーションなどであれば開発経験者は多く、昨今では多くの企業でフレームワーク開発 が多いことから、技術者の確保はしやすいものと思われる(ただし地域差がある)
まとめると
①ローコード・ノーコードフレームワークを使用する。
比較的業務ロジックを含まないアプリで、自社に技術者が少ない・いない場合。 イニシャルコストが発生が、将来的な人員確保の容易性の観点としては有利。 どちらかというと新規開発のスピードにメリットを感じる。
②.Netなど企業が提供しているフレームワークを使用する。
やや規模の大きいアプリで、.Net経験者が社に既にいる場合。
こちらも、リプレイスというよりは多数のプロジェクトで活用していく前提であれば コストメリットを感じるが、基本的には安くなる提示は難しそうであるため、①と同様コスト以外に メリットを訴えていく必要がありそうである。
③OSSのフレームワークを使用する。
現在ライセンス費用が発生しているような状況であればコストメリットを提示できる。
所属している技術者に経験がない場合、特に初動では開発期間が必要となる。
レポートやスプレッドといった機能を実現するツールには乏しい面があるため、開発期間が必要。
アプリケーションの形態はどのようにするか?
要件次第にはなりますが、例えばクロスプラットフォームで動作させたいかつスプレッドやレポートのような機能を有さないのであれば Webアプリケーションでしょう。
操作が複雑であるため、PCでの操作が必須であればその通りデスクトップアプリケーションにする必要があり ます。
何を申し上げたいかというと、書き換えができるからと言ってモバイルが一番いいのだ、Webアプリケーション が一番良いのだ!ではなくて、利用者はどれであれば一番使いやすいか?と重視すべきと考えます。
とは言え、体制面も踏まえ現在持ちうる武器と与えてもらえる武器が限定されてしまうのは中小企業では宿命でしょう。
まとめ
レガシーシステムのリプレイスは、技術的な選択肢だけでなく、コスト、保守性、ユーザー体験など多角的な視点で検討する必要があります。
それぞれのアプローチには利点と欠点がありますので、自社のニーズに最適なソリューションを選ぶことが重要だと思います。