EDPシステムの環境適応力を高めるために、ある種の情報をプログラムコードの中に埋め込むことを避け、設定ファイルやデータベース上に保存することがある。システムパラメータとかコントロールデータと呼ばれるものだ。
コントロールデータの内容は、接続先データベースの識別子のようなものから、多段階配賦計算の処理条件を指定するテーブルにいたるまで、用途も複雑さもさまざまだ。コントロールデータがうまく設計されていると、処理の多様さは、コントロールデータをいかに設定するかという問題に還元され、プログラムにはシンプルなロジックのみが残される。そのため、機能の柔軟性が高まるだけでなく、多くの場合、プログラムのメンテナンスも容易になる。
コントロールデータの設計はカスタムメイドのシステムにおいても大事だが、パッケージシステムでは死活的だ。カスタムメイドのシステムに比べ、パッケージシステムは遥かに多様な業務環境に適応し、また継続的にバージョンアップされなければならないからだ。企業向け業務アプリケーション分野では特にそうだ。
コントロールデータの設計に際して考慮すべき事項は色々あるが、最も重要なのは、コントロールデータごとに、どういう立場の人が設定するのかを明確に想定することだと思っている。この視点から僕は、コントロールデータを以下のように分類して考えている。
- アプリケーション導入者向け
- アプリケーション運用者向け
- システム稼動環境管理者向け
- 開発者向け
このうち、ユーザが関知するのは最初の二つだ。これらの設計の良し悪しによって、ユーザからみたシステムのわかりやすさ・使いやすさは大きく左右される。企業向けパッケージシステムの設計ではとくに、導入者向けと運用者向けのコントロールデータ項目を的確に切り分けることが大事だ。
柔軟性を確保しようとすると、パッケージのコントロールデータ項目は膨大な数になる。
しかし、個々の導入企業にとっては、どの値を設定すべきかが導入時に決まってしまい、運用時には選択の余地が無い項目も多いはずだ。
あるいはこんな状況もある。例えば10個のコントロールデータ項目があってそれぞれに2～3個の選択肢があるとしよう。可能な組合せは膨大な数にのぼることになる（例えば2の10乗)。しかし、特定の企業で実際に発生し得る組合せは数通りに限られてしまうことが明らかだ。
システムの運用時にこれらのコントロールデータ項目を逐一設定することをユーザ（アプリケーション運用者）に強いたなら、運用の手数はかかるわ設定ミスは増えるわで不興を買うことは受けあいだ。
一番目のケースに対しては、個々のコントロールデータ項目について、導入者向け、運用者向けのいずれであるかを判断して、登録画面や登録権限を分けるという手法で対処できる。
二番目のケースの解決策としては、実際に発生する値の組合せを（導入時に）登録しておくパターンテーブルを設け、運用時には個々のコントロールデータの値ではなく、パターンを選択するという設計が考えられる（この場合、そのパターンテーブルは導入者向けコントロールデータということになる）。
また、コントロールデータの設計アプローチも、運用者向けと導入者向けでは異なる。運用者向けコントロールデータは、運用者が馴染みやすいよう、業務の現場の言葉で表現すべきだ。例えば、部品在庫区分であれば、ユニット、在庫部品、受入即出庫部品、現場直送部品などである。逆に導入者向けコントロールデータは、できるだけ業務のカラーを排除し、そのデータによってシステム処理がどう制御されるのかをクリアに表現するようなレベルまで分析・細分化すべきである。例えば、部品受入れ時に在庫数を更新すべきか否かをイエスかノーで示すような区分として設計する。
導入者向けコントロールデータは凝ったものになることがあり得る。例えばリベート計算システムならば、複雑な計算式を記述できるような式言語をサポートする必要があるかもしれない。
しかし、（式言語のように）実装の視点からは複雑なコントロールデータであっても、導入者の視点からは、シンプルでやりたいことを直截簡明に指定できるよう設計すべきなのは当然である。
別の言い方をすると、導入者向けコントロールデータは、個々の項目の設定内容によってシステムの動作がどのように影響を受けるのか、明々白々(transparent)にわかるよう、設計すべきであるということだ。
運用者向けコントロールデータは高水準、導入者向けコントロールデータは低水準、と言ってもよい。どちらが上等かということはでなく、ユーザー業務に近いか遠いかという意味である。
もちろん、すべての場合に等しくこのような設計が適切である訳ではない。例えば小規模企業用の会計パッケージソフトウェアでは、箱から出してインストールすればすぐに使えることがとても重要だ。そうでなければ誰も買わない。そんな商品においては「導入者向けコントロールデータ」という概念そのものがナンセンスに響くに違いない。
とはいえ、そんな場合でも、上記のような指針に沿ってコントロールデータを二分化できる可能性には注意を払う価値があるかもしれない。というのは、二分化を通じて抽出された低水準コントロールデータを「導入者向け」とするか「開発者向け」とするかは、設計戦略というより商品戦略の問題だからだ。そうしたコントロールデータの設定権限を導入者（＝ユーザー企業のメンバー）に開放するなら「導入者向け」、しないなら「開発者向け」というだけの話だ。開発者向けとしたにしても、システム処理のシンプル化というメリットは享受できる。開発者はプログラム・コードを修正することができるという点を勘定に入れれば、二分化の損益分岐点は当然変わってくる。式言語の解釈・実行ルーチンを作るより、プログラム中にじかに式を書いたほうが安くつくかもしれない。しかし、二分化じたいは検討してみる価値があると思う。
コントロールデータの設計に関しては、これ以外にも色々な設計原則や経験則がありそうな気がする。またいずれ、考えがまとまってきたら、書いてみたい。
