ITシステムには要求変更がつきものだ。ビジネスを成長・発展させるために、ITシステムに要求変更があるのは健全なことではある。とはいえ、これがITシステムの開発運用を困難にしていることを、ITエンジニアの方々は身に染みて感じているのではないかと思う。

“変更地獄”を避けるために、ビジネスルールを分離する

 そんな経験談を、ロナルド・G・ロス(以下、ロン・ロス)は著書で次のように紹介している。

 ある医療サービス組織のビジネスマネージャの話によると、その組織では、中程度の複雑性しか持たないビジネスルールの変更に適応するためのアプリケーションの改訂にかかった工数が400人日で、期間が4カ月に及んだという。驚くべき話だ。しかし本当の問題は、これをどうやって続けていけるかということではないだろうか。

 さらに深刻な問題は、システム要員は、既存のシステムでは対応が難しいと思われるビジネスのイノベーションに関して、検討の対象にすらしないことが多くなってきたらしい。このマネージャの懸念は、アプリケーションに埋め込まれたビジネスルールの変更にかかりっきりになっているがために、ビジネスイノベーションへの対応に時間を割くことができなくなっているということであった。

 ここから得られる結論。私たちは新しいアプローチを必要としている。今までと同じではもう役にたたない。

(「ITエンジニアのためのビジネスアナリシス」第1章より要約)

 ここで紹介する新しいアプローチとは、こういうことだ。アプリケーションにビジネスルールを埋め込んで、その改訂にITエンジニアの工数の大半を費やすようなことを、続けるべきではない。要求変更の内容を調べてみると、かなりの割合をビジネスルールの変更が占めている。

 であれば、ビジネスアナリシスで作成する成果物から、ビジネスルールを特定して分離してしまおう。そして、アプリケーションプログラムからも分離してしまう。そんなことができるのか、と思われるかもしれない。しかしできる。さまざまな実績がある。