業務上のルールが変わったときには、アプリケーションシステムの処理内容を調整する必要が生じる。そのさいプログラムを手直しすることなくユーザ自身の手によりシステムを調整できた方が望ましいという場合は多い。パッケージソフトのように多数の企業に導入することが想定されているシステムにおいてだけではなく、単一の組織で使用されるシステムでも業務ルールが変わることはごく普通に想定される。開発期間や費用とのトレードオフに注意するのは当然であるが、アプリケーションシステムにフレキシビリティを盛り込むことは重要である。以上のことはシステム設計者の間で広く理解されていると思う。
一方で、十分に認識されていないかもしれないのは、フレキシビリティに制約を設けることの重要性である。たとえ開発にかかる期間や費用の問題をさておいても、アプリケーションシステムはフレキシブルであればあるほど良いというものではない。フレキシブルすぎるとシステムの設定変更手続きが複雑化してユーザの手に負えなくなる。フレキシビリティがかえって業務上の隘路をつくってしまう。事実上ほとんど変更されないような点についてはフレキシビリティを排除するとともに、本当にフレキシビリティが必要とされる機能についても、そのなかみに制約を設けることがだいじなのだ。
じっさい、業務条件が変わるといっても、その変更は一定の枠というか制約条件の中での変更であることが多い。たとえば、そこそこの規模の会社の決算業務では、ほぼ例外なく「配賦計算」というものがでてくる。簡単化して言うと、配賦計算とは単一の「配賦元」の数値を複数の「配賦先」に割り振ることである。たとえば、総務部で支払った本社ビルの賃借料を、そのビルに入居している各部門に対して使用床面積比で配分して負担させる、といったぐあいである。「配賦元」の金額をどう把握するか、配賦先を何にするか、配分比の元データとして何の数値を使用するか、配賦元と配賦先がループしたらどうするか、等々、配賦計算に関する可変要素は多い。会計パッケージを売ったことのある方なら、配賦機能の詳細についてお客さまから重箱の隅をつつくような質問攻めにあったことがあるかもしれない。有能なシステム設計者であればあるほど、いっそのこと、四則演算やら関数やらを使った計算式をユーザが自由に設定できるしくみを作ればどうか、といった思いに駆られる。そうすれば、すべてユーザまかせにできるではないか。
しかし配賦計算には配賦計算なりの制約条件がある。もっとも目立つ制約は、すべての配賦先に配賦された数値を合計すると配賦元のもともとの数値と一致しなければならない、という条件である。この制約条件を満たすためには、計算上で端数が発生した場合にはどこかの配賦先で調整することが必要だ。上述した「計算式をユーザが設定する」方法を採ると、端数調整のための計算式もユーザが書くことになるだろう。つまり、この場合、業務上の制約条件を満たす責任が、システムではなくユーザに委ねられていることになる。
考え方にもよるだろうが、私は、これはあまりほめられた責任分担ではないと思う。業務上変わることのない制約条件が存在するなら、それを満たす責任はシステムに負わせるべきではないだろうか。そうした見方に立つと、配賦計算において「計算式をユーザが設定する」という仕様は、フレキシビリティ過剰というべきだろう。業務において不変の制約はシステムが保証し、可変な要素はユーザに委ねる。こうした不変要素と可変要素の切り分けが、アプリケーションにフレキシビリティを持ち込む際に肝要だと思うのである。
業務における不変要素を見つける作業はアプリケーション設計の醍醐味でもある。不変要素はいつでも明らかなかたちで認識されているわけではない。何を不変要素とみるのかは、ユーザやアプリケーション設計者による業務理解そのものでもある。隠された不変要素を見つけ、すっきりとした仕様が得られたときの喜びは格別だ。
以上、アプリケーション設計者の立場から問題を眺めてきたが、ユーザの立場からみると、これは「何でもできます」という宣伝文句に動かされるのは危険だということだ。何でもできるというのは本当か？といった面もあるが、本当に何でもできたらかえって困る、ということもあるのだ。
