ビールパーティみんなでしましょ - 第２回BPMオフ会 に昨日は行ってきました。メモや感想などをテキトーな形式で残します。
まずは勉強会について。日本語としておかしい文面もあるけど、メモ的性格が強いんであんまり気にしないで……
BPM入門第1回 - BPM入門 by 大井さん
- BPM って何がうれしいの？
- フツーに業務アプリケーション（C/S でも web アプリでも何でもいいけど）作ると、お客さんの業務とアプリケーションの機能とのマッピングが難しい。その辺の概念を扱うのが BPM
- BPM = ワークフロー + 何か。
- BPMS を用いたシステム構成
- テキトーな UI + 業務の流れを定義したシステムとスループット分析ツール + バックエンド（永続化やその他のサービス）
- ワークフローの種類
- システムワークフロー - 人が介在しない。プログラムで構造化可能なもの。
- ヒューマンワークフロー - 人が介在する。人の判断が必要。
- Savvion デモ
俺の雑感。
最後の質問にも出てたけど、このテの自動生成ツールは、後から後から沸いてくるお客さんの細かい要望にどこまで答えられるかが勝負所かな？ ただ、それによってツールの使用がややこしくなってもダメだし。だったら、他の BPM フレームワーク使って素組みしてもいいんじゃね？ ってなるのがちょっと怖いかも。
最後の最後ではぶさんが発言してた「ウチは S2Buri つかった高速な開発で生産性 50 倍なんだぜ」な話。こういう開発体制取れるんなら自動生成ツールは不要になっちゃうんだろうなぁ。まぁ、ああいう開発体制取れるためには高い技術力あるのが前提なんだけどさ。ありきたりな意見だけど、個々の組織によって向いてる開発体制とか開発プロセスとかってぜんぜん違うんだろうね（現実そうなってるかどうは別として）
BPM の歴史みたいな話 by 名前失念（すいません……）
すいません。よくわかんかったです……ｗ ものすごく失礼な話だけど、大学のセンセイの講義みたいでしたｗ
- WF から BPMS へ
- 業務を情報処理の観点からみた内訳
- 40% は定型処理で構造化が容易く、プログラムで自動化可能 - ここは BPMS が主に取り扱う領域
- 40% は人と人のコラボレーションや知識の共有 - SNS とか Office とか wiki とか
- 20% は情報の収集・加工 - 検索や BI
- BPM が扱うのは 40% の構造化がやりやすいプロセスのみ。技術の向上により、コンピュータが扱うのは難しいを思われていた分野にもコンピュータを使ったシステムが入り込んできたのがここ数十年の大きな流れ。これからもその流れはどんどん加速する。
ここから俺の雑感のターン。
経営支援にソフトウェアでなんかやらせればイケてることできるんじゃね？ という流れは昔から何度も何度も言葉と手と品を変え繰り返されてきてるわけで。MIS やら DSS やら SIS やら EDP やら。それに沿って業務アプリの一般的な構成も変遷してきてる。汎用機の時代から、VB とかの C/S システムから、Web アプリへ。その辺の延長戦上に BPM やら SOA もあるんだろうかね？ 誰か経営情報システムの発展の歴史と BPM、みたいな感じで整理してくんないかなｗ
あと、実際に業務をやってるコンピュータに詳しくないフツーのユーザがシステム作れればいいんじゃね？ な流れにはちょっと懐疑的。まぁ業務フローの定義ぐらいはギリギリできるかもしれんけど…… EUC （文字コード的な意味でなくて）なんて言葉、今どんだけの人が覚えてるよ？
まーもしかしたらオフィスのねーちゃんがさくさくとスクリプト書けちゃう時代が来るかもわからんけどｗ そうなったらプログラマの仕事も随分変質しそうだ。
ワークフローエンジン紹介第1回 - プチ BPM のすすめ - jBPM紹介とデモ by id:wkzk
- ''色んな意味で''勉強会の流れを変えたすごい人。あと java-ja 大杉。「爆発しろ」って言われなくてホント良かった。
- id:wkzk 的な BPM とは。
- いつ、どこで、だれが、なにをしたか。のフローを管理する。で、その結果おしごとをやりやすくしましょう。
- ↑は BPM のツールをどううまく使うか、とは切り分けて考える必要がある。
- お客さんに BPM 入れようぜ、って提案すると「プロセスを管理しよう、と言われても……」と困ってしまうことが多いらしい。
- いきなりゲンミツに BPM っぽいことしなくてもいいんじゃね？
- まずは、カンリつーより、仕事内容をとりあえず共有しよう、みたいな所から手を付ける。とりあえず、見える何か、を作ろう。
- jBPM のデモ。
- JBOSS Seam の話。
ここから俺の雑感のターン。
やれるところからコンピュータ支援ソフトウェア入れていこうぜ、な話には同意。俺も開発チームに「とりあえず wiki 使ってみようよ」って感じで導入したけど、なんだかんだで浸透したし。まだまだ本格的に活用はされてないけど、一気に変わるってのは中々難しいと思うんで、とりあえず〜的な発想はいいのかも。
ワークフローエンジンと web アプリの連携。エンジンとの連携 API がどんだけ使いやすいか、が肝だろうか？ 連携 API が「連携するための」コードを要求してきても、それをうまく隠蔽できるコードが書ければいいんだけど……中々ねぇ。俺が遭遇したケースだと、エンジン提供の API と連携するコードと、連携して何か処理するコードと、Servlet API がゴッチャになってしまった、なんてのが……
会話した人々
- id:htada 安西先生、S2 使った開発してみたいです…… ファミリーのプロセスのマネジメントがんばってください。
- id:itengineer id ネーミングは難しいですよね
- id:itengineer の同僚のお二方。外に出て色んな人の話聞くってのは勉強になります。
- MySQL の方から来ましたな人 昨日はタクシースルーパターン適用せずに済んだのかなｗ
- id:shikun 書籍感想やらないか
- id:AWAWA すがきやサイコー
最後に
- id:gothedistance とりあえず昨日はおつかれ＆ありがとう。いやホントおたがい変わってねぇなぁ……ｗ しっかし x 年前のあの日に「YOU も blog 書こうぜ」って発言無かったらこうはなってなかっただろうなぁ、と考えるとホント趣深いですわ。
というわけでそんな感じでした。
