企業の基幹系システムを再構築する第一の目的は、システムの“保守性”(拡張性、柔軟性などを含む)の向上にある。しかし、現実にはそれを達成できていない実態が数多くある。今回から、システムの再構築の現場を保守性の観点で見てきた立場から、保守性の向上が実現されない理由と、それを実現するための技法を紹介する。

 システムを作る上で、ITエンジニアは積極的に「共通化」を実施する。共通化とは、多くの機能の中に共通して含まれる処理を、共通プログラムとして実装することだ。これによって「プログラムの数が減り、開発規模も小さくなり、再構築への投資規模を減らし、かつ保守性が高まる」という。残念ながら、これは誤りである。それを実証する事例を紹介しよう。

 ある企業で、再構築の対象となったシステムにおいて、販売管理と生産管理が別々のデータベース(DB)を持っていた。販売管理や生産管理のアプリは、それぞれDBにアクセスする類似した処理が多く、それが保守性悪化の要因とみなした。

 そこでITエンジニアは、「汎用DB更新プログラム」という共通プログラムを作成した。このプログラムは、どんなデータでもDBに保存し、取り出す機能を提供するものだ。

 個々のアプリには、データを読み書きするコーディングが不要になる。修正時にはこの共通プログラムだけ書き換えれば済む。つまり、開発プログラムを作る総量の削減、保守の変更量の削減を実現しているといえる。

 しかし、この共通プログラムは結果的に、プロジェクトが2年で完了する予定を半年延長し、コストを増大させる要因になった。加えて、システムのサービスイン後は、現行システムよりも保守に手間と時間が掛かる問題を引き起こした。

 これはなぜだろうか。現実のプロジェクトにおいては表立って議論されなかった事実が隠されている。

共通プログラムとアプリの深刻な依存関係が生じた

 多くのアプリが要求する機能を一つの共通プログラムにまとめたため、その共通プログラムの機能の定義は、全てのアプリの詳細な設計が終わるまで、完了できなかった。一方、その膨大な機能を持つ共通プログラムは、テストの序盤から多くのアプリで使用されることになるため、多数のアプリよりも早く実装が完了している必要があった。つまり、全部のアプリと共通プログラムが深刻な依存関係を持ってしまうという重大な欠点があったわけだ。

 テスト時にも問題が起こった。各アプリのテストで発見された欠陥への対応として、この共通プログラムに修正が必要な状況が多発した。多くのアプリの機能を集約させているからだ(図1)。

図1●汎用データベース更新プログラムの遅れが、全体の遅れに
図1●汎用データベース更新プログラムの遅れが、全体の遅れに
[画像のクリックで拡大表示]

 テストの序盤では、この共通プログラムに対する変更要請を特別な管理下に置き、いくつかの修正要件を一度に実現してアプリ側のテストへの影響を極小化させた。これでなんとかプロジェクトを進めていた。しかし、サービスインが近づいてくると、この共通プログラムへの修正は禁止事項となった。共通プログラムを変更した後のテストが多くのアプリにおよび、プロジェクトスケジュールを守れなくなるからだ。

 この共通プログラムへの修正が禁止事項となった結果、アプリは共通プログラムを介さずにDBを読み書きするように変更された。サービスインの時点では、この共通プログラムの「多くのアプリのDB更新を一元化する」というコンセプト自体が崩壊していた。