近年、基幹系システムの開発は、ほとんどが再構築です。再構築が抱える悩みの１つは、そのコストパフォーマンスでしょう。
なぜなら、新規業務として追加される業務要件が全体の２割にも満たないのに、コストは全業務分発生するからです。対象業務の情報システムを初めて構築したプロジェクトと比較すると、再構築プロジェクトはいつも割が合わない勘定になります。
リバースエンジニアリングは、その悩みを解決するかもしれません。
業務要件定義をまっさらの状態からスタートするのではなく、既存の業務仕様やソフトウェア構造を可視化した状態からスタートすれば、期間短縮や工数削減が可能です。なによりも、現状と同じ機能が要求される８割に関して、１００点の品質からスタートできるのはリスク管理上大きなことです。
本来であれば、保守フェーズで業務仕様書とソフトウェアが一致しているべきですが、これが１００％できている企業は稀です。動いているものと一致しない業務仕様書は、信頼されず、日を追うごとに陳腐化していきます。
リバースエンジニアリングツールを使えば、この種の陳腐化を解消できるかもしれません。ただし、１つ難しい問題が隠れています。リバースエンジニアリングツールが実施するのはコンパイラに似た言語処理です。言語処理で実現するのは形式の整理であって、意味の整理ではありません。形式が整理されたドキュメントから意味を見出すのは人間の仕事にほかなりません。この部分を最小にするためには、形式的に整理した結果から意味を容易に理解できることが重要です。もっと言えば、整理結果の受け皿になるメタモデルの構造が肝です。
リバースエンジニアリングで業務仕様書とソフトウェアを一致させた先には、おもしろいことが待っています。私なら、業務仕様書から新しいシステム環境のソフトウェアを自動生成します。リバースエンジニアリングとソフトウェア自動生成の組合せが実現すれば、システム基盤を移すことは簡単にできるでしょう。
リバースエンジニアリングの方法論やツールが充実してくれば、いつでも再構築できる時代になるはずです。
