Business Logic

いろいろな業務アプリケーションのユーザーインターフェースを設計していると、「動詞 → 目的語」というシンタックスの壁をどうしても打ち破れないことがあります。不自由な操作性であることは分かっていても、モードを作らざるを得ないのです。それは例えば次のような場合です。

  • タスクによって処理対象となるオブジェクト集合が異なる場合。この場合、タスク選択はアプリケーションの選択と同じような位置づけとなる。
  • タスクによって、ユーザーに提示すべきオブジェクトのプロパティやメソッドが大きく異なる場合。この場合、先にオブジェクトを提示しようとすると、情報量が多くなり過ぎてユーザーインターフェースが破綻する。
  • 対象オブジェクトが(ユーザーのメンタルモデルにおいて)存在しない、あるいは対象オブジェクトがひとつだけで選択の必要がなく、アクションの引数指定としての入力操作がタスクの大部分である場合。例えば切符の券売機。
  • ユーザーの創造的な作業を禁止し、一定の順序で限定的な操作をさせたい場合。つまりウィザード。
  • データの整合性やセキュリティの都合上、トランザクションを一元化する必要がある場合。そのためには、モードの中で決まった項目だけを入力させて、モードから出るタイミングとトランザクションのタイミングを一致させるのが望ましい。

これらの状況が、業務アプリケーションにおいては結構多く発生するのです。

考えてみれば、それは当然のことなのです。なぜなら、そもそも業務というのは一定のタスクのことであり、決められたことを決められた手順で行うことだからです。その業務手続きをオンラインで行えるようにしたのが業務アプリケーションですから、ビジネスロジックのほとんどがタスクに依存してしまうのです。その結果、タスクを選択してからでないとオブジェクトを選択できないような作りになり、システム全体がモードのごった煮みたくなってしまうのです。

これを打破するためには、業務手続き自体をもっと自由にするか(これは企業ガバナンス的にあり得ない方向性ですが)、もしくは、業務アプリケーションの役割を「業務手続きのオンライン化」から「業務のオンライン化」に変えていく必要があるのではないかと思います。

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>