最近のシステム開発は、既に作られたシステムの保守開発とその更改が中心となっています。ところがこのシステム更改には、しばしば失敗例が見受けられます。その原因の一つとして現行システムの理解不足が挙げられます。理解不足によって要件定義漏れなどが起こり、開発がとん挫してしまうのです。

　このため、システム更改にあたってはまず現行システムの解析が重要となります。現行解析では、どのようなことを行うべきで、実際にどのように実施されているのでしょうか。現時点では、システムの棚卸しのための情報生成やレガシーコードの正確な仕様解析などが自動化できています。一方で、回復した設計情報へのシステム目的や業務情報の付与などは自動化が困難です。自動化できることとできないことの見極めが解析作業を円滑に進めるうえで欠かせません。

　今後はソースコード以外の入力情報を基にした現行解析や、経営者やユーザーにもわかる現行解析へと領域が広がっていくでしょう。

開発の中心は「既存システムの更改」

　厳しい経営環境が続く中、日本国内のIT投資は微増傾向にあるものの、ほとんどの企業は新たな投資には慎重な姿勢を取っています。既存システムの保守・運用コストを削減しながら次期システムの更改に備える、というのが一般的な企業の現在の姿といえます。新規のシステム開発の数はそれほど多くなく、既存システムの更改が開発の中心となっています。

　一方で、既存システムの保守・運用コストが思うように削減できていなかったり、ビジネスの変化のスピードに追随できていなかったりするため、既存システムの更改を検討している企業も少なくありません。

　しかし、実際には思うようにシステム更改が成功しない例もあるようです。システム開発から少し話はそれますが、世の中には既存のものに対する復元や再生に失敗した例が数多くあります。例えば、歴史的な美術作品の復元などがこれに該当します。

　過去に施した復元作業の結果、逆に色彩が変わってしまったり、絵そのものを消失させたりすることもあったようです。これは目には見えてこない絵の具やニス、キャンパスの組成をしっかり分析しなかったことなどにより、絵画に対する最適な復元方法を取れなかったからです。その結果、非常に貴重な絵画が失われているのは非常に残念なことです。

　上の絵画の例と同様に、システム更改でもシステムの仕様として見えている部分だけを対象として開発しても成功にいたることは困難となります。絵の具やニス、キャンパスの組成が絵画を見ただけでは不明なように、システムのすべての仕様も、関係者へのヒアリング、仕様書の確認といった行為だけでは把握できません。