「業務をシステムにあわせるべきか、システムを業務にあわせるべきか」という議論がある。
日本ではそれぞれの企業が固有の業務の流れを持ち、それにあわせたシステムを構築するのがもっぱら主流だが、アメリカではシステムはパッケージで提供されたものをそのまま使用、業務をそのシステムの方にあわせる……的な論調を目にしたことがある人も多いだろう。
曰く、業務にあわせてシステムを構築するのは、既存パッケージをカスタマイズするにせよ、フルスクラッチで一から作るにせよ、大変なコストと時間がかかる。曰く、パッケージに業務をあわせれば短い時間で安価に導入でき、競争力が高まる。
それもまあ確かに一理はあるだろう。もちろん、システム導入に当たって、それ以前の業務を無批判に忠実にシステム上に再現するとかいうのはさすがに論外だ。
しかし、基本的には「システムを業務にあわせるべき」だと強く考えている。
少し前の話だが、エスカレーターを歩かないでくださいという張り紙を駅に貼るというニュースがあった。言い分は「エスカレーターの構造はもともと、利用者が歩くことを想定していない」のだという。
それを聞いて、正直なところ「じゃあ歩くことを想定したエスカレーターを設計するべきでは？」と思った*1。そのニュースを見て同じように感じた人はおそらく少なくないのではないか。
もちろん「歩けるエスカレーター」を作るのはきっととてもとても難しいだろう。全く新しいものの考え方も必要になったりするはずだ。でも「右側を歩くのが『常識』（関西は逆）」と認識されていることを 100% 承知の上で、それに目をつぶって「歩くのは想定外」と答えるのは果たして正しい態度だろうか。
業務が企業ごとに異なっている、当然そこには理由があるはずだ。それに目をつぶって「業務にあわせてシステムを作っていたら競争力が上がりませんよ」と答えるのは果たして正しい態度だろうか。
もちろん「既存の業務にあわせることを想定したシステム」を作ることはとてもとても難しい。全く新しいものの考え方も必要だ。
でも技術の力でそこを乗り越えることがきっとできるはずだ。
個人的には web アプリケーションの連携技術を突き進めていく中にその解（の一つ）が眠っているのではないかと考え、研究開発している。先日サイトを公開した「 web 間フレームワーク flowr 」というのがその一つだ。
サイトを公開したことで、BPM を専門としている方達に見つけてもらい、BPM のオフ会にて flowr の話をさせてもらえることになった。
まさに上記の問題に直面している人たちなので、flowr がその解となりうるかどうか（その可能性を秘めているか）について色々ご意見をうかがえるのではないかととても楽しみにしている。
