RDRA支援で様々なシステムを見ていて思うことがある
システムを複雑化させる要因の一つに、システム境界が実態とそぐわないことがある
システムの単位が開発プロジェクトの単位で決まり、そのプロジェクトの制約(納期や予算)からシステムスコープが制約され、システム間のインターフェースが決まる
あるビジネスルールが複数のシステムにまたがる場合、システム間の連携が必要になるたびに条件や情報が重複して実装される。
さらにシステムが分かれることで不要な手処理が発生する
特に近年は納期の要求がきつく、間に合わなければ手処理で対応ということが多く、複雑さに拍車がかかっている
システムスコープの見直しを実装から考えていくと袋小路に入る、なぜならば実現可能な局所的な判断になるからである
システムの関係を見直すにはそのサービスや会社の特性を広く俯瞰して理解していないといけない
システムの拡張や変更はその会社・サービスの特性から発生するからである。
では会社やサービスの特性をどのように可視化するかというと、ビジネス要素とバリエーション(RDRA用語)を俯瞰することである。
つまり、ビジネスルールの元になるビジネス要素とバリエーションは、ビジネス上のパラメータになっており、ビジネスはこのパラメータの組み合わせを変えながら進化する
ビジネスパラメータが俯瞰できると会社やサービスの特性が見える
現場はそれらのバリエーション個々の存在は認識しているが、俯瞰できずシステム機能として複雑さだけが見え、複雑なビジネスルールが存在しているように見えている
結果として複雑なビジネスロジックを生み出している
ビジネスパラメータが明確になるとシステムの変化の範囲も見えてくる。さらに会社やサービスの特性が見えてくることで、ビジネスパラメータそのものを拡張する関心事が分かる
システムの単位を考える時に、対象の機能やサービスが将来拡張される部分か否かが見通せ、より適切なシステムの単位が見える