第2回BPMオフ会がオフ会史上最大規模になりそうな予感にwktkしています。みなさんありがとうございます。当日はカーナビすらついてねぇへろへろの軽自動車で出陣しますので、ちと狭いけど横浜・湘南方面の方々は後ろに3人様無理矢理コースで最大4名様までご乗車になれますので、安心してビールパーティーしてください！
というわけで、そろそろBPMについて一言いっておくことにします。
BPMに興味をもったわけ
自分が所属している所の抱える事業のお悩みについて考えていたら、BPMっていうのは相性がよさそうだなと感じたところから始まっています。大きく分けるとこの２つ。
- コンサルしてもITまで落としこまければSIerとしてダサいけど、そこまでいかない
- システム開発は業務可視化を構造的に行うことが求められるけど、粒度がバラバラ。
私が所属している本部は業務コンサルをコアに様々なビジネスを展開していますが、やはり弊社はSIerなので「コンサルでおわり？システム化までビシッと提案しないなんてキミにはがっかりだ」とDISられてしまいます。しかしながら、これが縦割り組織の弊害なんでしょうが、コンサルティング部局と開発部局が全然トゥギャザーできておりません。いくらコンサル部局が「YOUたちやっちゃおうYO！」ってけしかけても開発部局のほうが力が強いです。彼らは彼らでビジネスしてますし、コンサル部隊が勝手に発注出すのもいかがなものかと。
もちろんこれは彼らだけのせいじゃなくて、コンサル側にも問題があります。わけのわからん案件になるのかならないのかもハッキリしないお仕事をいきなり投げても、そりゃ投げられた側はお前何いってんだっけ状態になるわけで。彼らが満足するような形、負担をかけないような形まで要件を固めることはなかなかできなかったりする。業務フローはとってもシンプル、業務アルゴリズムはとっても死ねる。なんてことはしょちゅうじゃんorz
I will close with a metaphor that sums it up best, the failitator diagram represents the swan swimming gracefully on the lake, the automator diagram represent the swan’s not so graceful legs thrashing under water. You can’t have one without the other.
人間系の業務フローは優雅な白鳥だがバックエンドのシステム系フローは必死で足を掻いているんだ。それはコインの表と裏だよっていう話を、海の向こうでしている。変わらないよ、日本もアメリカも。
もう１つは開発側の話のですが、お客さんですら「だいたいこんな感じなんだけど」みたいなもやっとしたご要望を伺った時は、基本的に業務フローとして登場人物と何をやるのかを流れを整理する所からはじめます。これはかなりハイレベルなもんなんで、実際にはもっとブレイクダウンしないといけないのですが、このブレイクダウンがもはや伝言ゲームのようなものですから「聞いた人の解釈」で歪曲されちゃうこともあったりして。これとこれをこういう視点で分析しなさいって所まで落とし込んでいる会社はほとんどないと思う。こういう記法を使えはあっても。
SIerは「プロセスをカタチにすること」が本分だと思っていますので、いろんな意味でプロセスを主軸に物事を考えなくてはならないなぁと思っていた所にBPMっていう概念があったので、へぇーと思ったところがきっかけです。
ベンダー各社の動向
SAPを皮切りに、ほとんどのソフトウェアベンダーはBPM/SOAという方向へ舵を切っています。
ここ2年ぐらい各社製品ラッシュだったといっても過言ではないんだけど、ほとんどがSOAっていう考えで全社的な基盤を作りませんか、だって個別に連携取ったらシステムが増えるごとに連携が必要になりますよねって感じで売り込んできている。これは話としては正しくてインターフェイスの違いは吸収しないとにっちもさっちもいかなくなるのは明白で、ハブ＆スポーク型でシステムの統合を考えていくってのは賛成。まぁこういうのはEnterprise以外はあんまり欲しがらないよね。
なんていうかな、システム体系をPOJO化していくイメージかな。特殊なAPIに依存せず何かを知っている必要はないあの世界をシステム全体という目線でやりませんか、特殊な言語やプロトコルに依存せずに本来作るべき所だけを作りましょうよというのが典型的なセリングストーリーであり、私はこういうPowerpointを書くことが大得意ｗ 語りまくるよーｗ
Process does REALLY matter
私はずっと内製回帰したほうがいいと思っているんだけど、内製回帰のはじめの一歩は「自社の業務プロセスの構造化」だと思っています。ここが崩れると全部崩れると思う。
構造化って言っているのは端的に言えば、戦略から階層化して落とし込みましょうって話と、自社の業務を皆さんが同じ尺度で分析できるようにして最低限ツブをそろえましょうってこと。個人レベルの話になるとBPMはビールパーティーみんなでしましょが真実だと思いますが、企業単位に目を向けたときに技術の変遷が恐ろしく早いこの業界において作り手でない多くの方々はどうやって自社のIT資産をManageしていくのかを考えると、BPMというのはかなり相性が良いと思ってます。
別にBPMで開発がなくなるとかそういう飛躍的な議論はしたくないし、そんなの無理だし。ただ、開発っていうものがユーザーに喜ばれるような方向へ向かおうよ、BPMって切り口で議論したら色々わかることあるはずだよって確信に近い何かがあるってのが今の正直な気持ち！
ってなわけで、第2回BPMオフ会参加お待ちしてますよ！まだまだ定員の半分ぐらい！飲み会だけでも来ちゃいなYO！むしろそれこそBPM！！
