プログラムをマクロ（大域的）に分析する

モデルベースの手法でコストをかけずに既存システムを分析する（5）

既存システムの段階的な再構築に向けて

　基幹系のシステムは大きすぎて一度に再構築することが困難な場合があります。特に一枚岩のシステムとして大規模になってきた場合は、システムをパッケージに分けて整理することから始めるのが重要です。一枚岩に見えたシステムも業務が分割されている以上、システムを切り分けることができます。既存システムからインターフェースになりそうなものを見つけ、そこに寄せていきます。一枚岩のシステムがある程度分割したものに整理されると再構築の道筋が見えてきます。

分割し境界を明らかにする

　段階的な開発に持ち込むためには、既存システムをパッケージに分割し、パッケージ間のインターフェースを明らかにする必要があります。インターフェースはデータベースへのアクセスを標準化することで整理します。標準化するといっても新たにインターフェースを作るわけではなく、現在のプログラムの中からデータベースアクセスとしてよく使われるものをピックアップし、それをインターフェースと見なします。

　例えば「このマスターにアクセスするときはこのライブラリをよく使っている」。または「共通系のデータを使うときはこのストアドプロシジャを使っている」など、実現手段は問いません。とにかくデータアクセスを集約していき、それをパッケージのインターフェースとすることで整理を進めます。

　保守作業の時には、インターフェースとなるプログラムを使うように仕向けていきます。このインターフェースが再構築時のインターフェースになっていきます。

　長年保守されているシステムは既に実績のあるライブラリやサブルーチンなどを使って変更リスクを下げるようにしていることが多く見られます。そのような暗黙のルールを見つけ出す方法としても、今回紹介した分析方法が役に立ちます。

図6　インターフェースの再整理

コスト意識のギャップを克服する

　私は同じプロジェクトのシステム開発において、システム開発の発注側と受注側の両方に異なるタイミングで関わったことがあります。このとき発注側と受注側での立場の違いによる、認識の違いに驚いた経験があります。この連載の最後として、立場の違いからくるコスト意識の違いについて触れたいと思います。

立場の違いによるコスト意識の相違

　システムの再構築では、業務が大きく変わることはあまりなく、システムに求められる機能の7，8割は同じというのが一般的です。

　ユーザ企業の立場に立てば、システムを再構築する以上、既存システムの問題点を克服した上に、新たな付加価値がないとお金をかける意味がないと考えます。同時に既存のシステムとほとんど同じシステムは「全く新しいシステムを開発するよりも安くできるはずだ」と考えるのが普通です。少なくとも今までの業務が大きく変わるわけではないので、そこに大きな金額を裂く理由が見つかりません。

　一方開発側にとっては既存システムとほぼ同じといっても、アーキテクチャが変わってしまえば、1から作り直しとなり新規開発とほとんど同じです。

　このことから発注側と受注側ではコストに関して大きな認識のずれが生じます。このコスト認識の差をいかに埋めるかが、既存システム再構築の最初の大きな課題となります。

図7　発注者と受注者の認識

コストのギャップをいかに埋めるか

　コスト意識のギャップを縮めるためには、仕様策定にかかる時間を短縮する必要があります。しかし、精度の低い仕様化では開発工程で手戻りが発生します。そのため短時間で精度の高い仕様を作成する必要があります。

　既存システムの再構築の場合は、仕様のブレを少なくすることができます。もう既に普段行っている業務がベースになるので、そこが大きくぶれることはありません。このメリットをうまく活かすことがコストのギャップを埋めるポイントになります。そのためには既存のシステムと業務がどのように関わり、システムが何を支援すればいいのかを早くつかむことが大事です。

　この連載で紹介した「システムの地図」はその第一歩になります。既存システムの調査に不必要に時間をかけずに、システムの全体像を素早くつかみ、要件定義につなぎます。要件定義の中では既存システムの地図から新システムの地図を作ります。そしてピンポイントで既存システムを調査し、無駄な時間を極力減らします。

　これ以降の要件定義の進め方に興味のある方は「要件定義の勘どころ」を参照してください。

まとめ

　ビジネス系のアプリケーションでは昔から人に依存しない業務の推進が掲げられ、システムの中にビジネスルールが埋め込まれてきました。その結果企業を支えるビジネスルールが人からシステムに移り、現場の担当者でさえビジネスルールがよくわからない状況になっています。

　既存システムを分析する第一の目的はシステムに埋め込まれたビジネスルールを洗い出すことです。そのためには細かなロジックに目を奪われることなく、業務全体を推進するビジネスルールを洗い出すことに注力します。

　5回に渡り既存システムの分析方法を示してきました。この連載を一言で表せば、「システム全体を表すシステムの地図を作成し、業務を推進するビジネスルールを明確にする」です。

　システムの再構築では精度の高い仕様をいかに短時間で作成するかが鍵です。その第1の障害が既存システムの分析になります。その障害を短時間に乗り越えるために、この連載が役立てば幸いです。

情報源

• 要件定義ツール：要件のツボ
• UMLによる記述方法：RDRA
• 書籍：『要件定義マニュアル』 神崎善司 著、秀和システム、2008年10月
• プログラム解析：シナジー研究所　ソフトウェア資産を調査ツールで見える化