今あるユーザ系情報会社とフィージビリティスタディをやっている。その会社がASPで提供している販売あるいは財務会計システムの再構築について、ぼくのいまやり方が適用できるかどうかという検討である。

昨日はその大阪本社に行ってミーティングを行った。メールでそちらに行くのでよろしくと書いたら、みんな気合がはいっているのでそのつもりで来てみたいな返事が返ってきた。

議論の中心はBPM（Busness Process Management）を使うとどう変わるのか、どういういいことが待っているのか、どうやって開発したらいいのかといった基本的かつ根幹にかかわる議論になる。

すぐにツールの使い方や機能の話になることが多いが、ここの会社での議論は考え方だとかコンセプトから入って、そこをみんなで腹に入れようよというスタイルなので気に入っている。

BPMを検討するときの大事なところはここのところで、従来型の延長ではなく、新たな考え方で見ていかないとなかなか理解できない。

こうした詳細についてまた違った記事で紹介しますが、論点を少し書いてみると、今あるパッケージはスクラッチの手組み開発でスタートし、その後カスタマイズやアドオンをしているうちにスパゲッティ化してきたので、それを再構築するというプランである。
そこでは、あくまで今の延長でプログラムを整理し、部品化をして保守性を向上させるというやり方もあるし、まったく新たな基盤に開発コンセプトも変えてしまう、例えばBPMを採りいれるなどをするという選択肢がある。

そういう中でBPMの有効性を検証しているわけだが、BPMはプロセスオリエンテッドだから、もちろんプロセス設計から入る。そこでプロセスを書くのだが、いま動かしているシステムをベースにプロセスを書くと画面中心になるのだ。しかも、画面と画面をつなぐところに手作業のプロセスが入る。さらに、画面の中も実はプロセスになっていることがわかってくる。

いま、内部統制やら業務の可視化の必要性が謳われているが、このときプロセスを書けるかどうかがかなり重要な要素となる。そこで昨日は、ITを使おうが使うまいが、またシステムの作り方をどうするにしても、まずは業務プロセスを整理することをしませんかという提案を行なった。

BPMを実行する場合、一番の肝になるところであり難しいところは、「シンプルで一貫化されたきれいなプロセス」を書けるかどうかです。これができさえすれば、そしてその構造を崩さないかぎり、実現方法はどうやってもかまわないのである。

今度のディスカッションの論点は、まず一度プロセスを書いてみて、それをどう料理していくのかになる。面白くなってきたぞ。

昨日参加した人たちは皆熱心で、よく考えている方ばかりなのでついこっちも熱が入る。久しぶりの“ライブ感”を味わった。

終わって、近くの店で懇親会をしてもらう。そこでもITに限らずサッカーの話だとか大いに盛り上がる。

飲んだとき一緒だったY田クンからこのブログに自分のことを載せてよと脅されたので書かなきゃいけないのだが（笑）、Y田クンが何かいけるかもしれない感じがしたと言ってくれたときはうれしかった。

お互いに違った角度から見て、意見を言い合うという機会は非常に大事で、そこで違う見方をすぐ拒絶するのではなく、一旦受け入れて吟味してみるという姿勢が大事で、昨日はそういった議論ができたように思える。もちろんぼくの方もすごく勉強になった。

しかし、大阪は暑い。それに梅田の駅回りはわけがわからないし、エスカレータで左側に立っていたらどつかれるし、それよりも何よりも周りがみんな大阪弁だし、ああ疲れた。