アプリケーションモダナイゼーションにおける現行踏襲の本当の意味
アプリケーションモダナイゼーションをやっていると、ほとんどのパートナーから聞かれるのが、「現行踏襲」という要件。理由は、現在のアプリケーションと同じロジックを実装しないと、業務に支障がでるからです。業務側から見てみると、新システムに移行したら昨日までやっていた業務と異なるデータが表示されるのは困るわけで、当然といえば当然です。なので、新しい機能を追加するとか削減するとかではなく、今まで通りという意味で「現行踏襲でお願いしたい」となるわけです。
そうなると、IT側としては「現行システムのソースコード」を解析し、ロジックとして同じ答えにするべく頑張ります。なぜなら、今動いているものこそが「正」であり、メンテナンスされていない仕様書だけではロジックの補完はできないからです。コードを解析してそれを仕様書とし、詳細設計書としていきます。
しかし、その「詳細設計仕様書」が正しい解釈であると、どうやって検証したのでしょうか？いわゆるWaterfallの開発手法では、各工程で「完成品質」を担保し、元の工程に戻らないコトを前提としているのはご存知の通りです。上記のように、ソースコードを解析した詳細設計書が正しいコトを前提にその後を進めてよいのもでしょうか？
私が実際に見たり聞いたりしたところでは、このやり方は大概失敗しています。
ソースコードの解析が完了せず、仕様書として完成できない状態になってしまう。後工程である開発・テストに大きく影響してしまいます。リスクがコストとして跳ね上がり、プロジェクトが停止する傾向にあります。
技術者が旧システムのデータ構造、アプリケーション構造を参考に仕様書を作成しているために、データ構造もアプリケーションの構造もほぼ同じものが出来上がっておりきます。「アプリケーションモダナイゼーション」を声高々に叫んだはずなのに、アプリの更新保守には今までと変わらぬ工数・時間が掛かります。なんのために高額の費用をかけて書き直したのか、わからないと。
業務として「本来すべきではなかったロジック」も移行してしまい、業務の不正を是正するチャンスを逃してしまいます。
何が悪かったのでしょうか。
そもそもなのですが、業務側の現行踏襲の意味と IT側の現行踏襲の意味が違うのではないでしょうか。業務側は「今までのデータと同じモノとして見れれば良い」と思っているのですが、IT側は「全てのロジックをそのまま移行する」なのです。現行踏襲すべきな対象が、データとロジックと、違うのです。不要なロジックが相当残っているのではないかというのは業務側も理解しており、そういうのをスリム化してより良いシステムにして欲しい訳なのですが、 IT側としては、どのロジックが使われているか使われていないのかの判別ができず、文句言われるくらいなら... ということで、ロジックを全部移築してしまうのです。
不要なロジックを如何にスリム化するか。アプリケーションモダナイゼーションという観点で述べると、データモデルの再構築とロジックの再構築はどうしても必要となります。ではゼロから再設計するにはどうすればよいのか？長大な分析と設計が必要不可欠なのではないか？結局、「現行踏襲」という、ロジックの再作成になってしまうのではないでしょうか？
いいえ。それでは本当にお金がいくらあっても足りません。もっと効率的に再構築する方法が一つだけあります。それが「ルール駆動開発」です。人工知能における機械学習が、今までのデータを利用してロジックを導き出すように、いままでの「データ」を使って「人の記憶・想像力」を利用してロジックを作っていく方法なのです。「データの利活用」は行動分析等の方面ばかりに注目が行っていますが、旧来のシステムのモダナイゼーションにも使って良いですし、それによるロジックの断捨離ができるのであれば相当な効果が生まれるのでは？と思うわけです。
業務側は、例えば創業以来の過去50年分の全てのデータ・ロジックが必要とは思っていません。今の業務が回れば良いだけです。
是非、ルール駆動開発についてを御覧ください。