実装方法よりもルールの単純化が重要

業務とシステムの狭間で思うことは、システムからの立場に立脚している人は、業務の原則論を考える前に、バリエーションに対していかにシステムの仕組みを作るかという実装論に走りがちだということです。

本来、業務設計では出来る限り不確定要素を排除するために、実際に発生する事象の原因を考え、原因を効率的に処理するための原則となるルールを策定します。そこからオペレーション･ルールを策定していきます。

まずは、業務で発生する事象を徹底的に突き詰め、原因を類型化していくことで対応方法の簡素化を図ります。そして簡素化された対応方法に対して、具体的な業務オペレーションのためのルール、つまりそれぞれの対応方法に対して判断項目、判断条件、対応内容を明確に定義していくことで、業務として最適な流れを定義します。

この作業の後に、具体的な”業務支援ツール”としての設計・実装を行うことにより、システムから余分な機能を排除できます。

いざ、実際の現場に向かってみると、曖昧な業務ルールの下で、考えらつく事象に対して対応するためのシステム機能を付加していくことが多いと感じます。その結果、イメージで申し訳ありませんが、つぎはぎの機能の集合体と言ったシステムが出来上がります。その結果は、機能変更を行えない、新しい業務に対応できない、さらには各々の事象に対応するために異なる機能を使うといった、大変使いづらいシステムが出来上がります。

まずは、業務を徹底的に突き詰めて、単純化した業務ルールを定義する。そのことで、システムの出来ばえも大きく変わると思います。

その一方でよく忘れることは、どんなデータに対するどのような処理でも全てこなせる、ワイルドカードの機能を付加しておくことです。業務には必ず例外が発生します。そのような事象に対応するためには、誰に使わせどこまでの機能やデータへのアクセス権を持たせるかは別として、必ず全機能（全データに対して、あらゆる変更が可能）を持ったサブ・システムを構築しておくことで、将来の事象へのとりあえずの対応が可能になります。

新たな事象が、定常化した時点で、追加機能の実装を行うまで、業務的にもシステム的にも、このワイルドカードの機能で対応可能です。

これから新しい業務やシステムを構築される方は、もう一度基本に立ち返って、「業務ルールを徹底的に簡素化する」ことをお勧めします。