ぶり祭り行ってきました。
ぶり祭りに参加させて頂きました。
聞くところによると相当な応募があった中での抽選で、参加出来たのは相当ラッキーなことだったようです。基本的に宝くじどころかアイスですら「あたり」が出たことのない僕にはとてもとてもありがたい話です。
反面、そのせいで近日中に死ぬんじゃないかとドキドキですｗ でも、抽選に選んで頂いたということはつまり、参加できなかった人がいるという事。なので参加させて頂いた身として、残念ながら参加できなかった人たちに少しでもぶり祭りの内容を伝えさせて頂く、という責任を果たさないと死ねませんしねｗ
内容は思っていた以上に濃く、これを書くのにもそれなりに時間を要する有様＞＜・・・と思っていたら、id:nobeans氏が秀逸なマトメをしていて、加えてそれをid:makotanが華麗にマトメていた（http://d.hatena.ne.jp/makotan/20081120#p2）ので「なんか細かく書かなくてもいっか〜」と肩の荷がおりた思いですｗ
で、先に統括的なものを書いてしまうと、SIerの主業務である業務システム開発でBuriを使うメリットというのは相当あると思われる事、そしてBuriを使うには相当「Buriを使う為ではない努力」しなくてはならないという事、ですね。ついでに言うと、要件定義＝下流工程なんだぜ、というのも「なるほど、そっか！」と思わせられる点でした。
では、僕的なマトメ。
前編
羽生さんから提示されたAgendaは以下のようなものでした。
そして実際存在したAgendaは・・・
- 昼の部
- 夜の部
- Buriの敷居について
昼の部：Buriに至る経緯を知ろう
ここの内容は、楽々ERDレッスンとWeb+DB Press Volume.33に書かれているよ、とおっしゃってましたが。。。要約してしまうと「Buriがあるからといったところで、「業務システム」へのアプローチを何度も何度も見直してきたからこそ、Burixは完成したんだぞ」ですね。
「BPM」とか「BPR」を今まで深く知ろうとはしてこなかったのですが(脳ミソ的な事情により)、BPMの位置づけがこのBPRの継続をサポートする為のツールという事から考えてそれなりの意識改革ではあったんだけれども、それ以外はRDBMS、VisualBasic、Javaの登場などテクノロジの革新があって本来すべき「業務」というものへのアプローチが止まっている時期があったよね、というお話だったと理解。
それを、業務システムの歴史、遍歴とコードの書かれ方、設計技法の成り立ちなどを絡めてとても分かり易くお話しされていたのは、さすが羽生さんという他ないですね。
「業務」へのアプローチを止めてしまって、テクノロジを追求したところで結局デスマは減ったの？顧客満足度は上がったの？お客様がIT化の恩恵を受けられたの？っていう点に意識を向けていないなんて、とても不誠実なことなのではないか、というメッセージを受け取った気になりました。僕なんかが最近TwitterやWassrやこのBlogで「Buriムズイ＞＜」とか「敷居高いって＞＜」と言っていましたが、それはBuriを使うのが難しいんじゃなくて「お客様の業務」に対して全然理解を示そうとしていないってだけなんじゃないのか？と。
お客様の抱えている課題は、当然単純なものである筈がないのです。単純であれば、お客様自身が自分で何とかしてしまえる。しかし課題を解決するのは単純な仕事ではないから、僕らのような業務システムを作る人間たちにコストを支払って解決を依頼してくる、と。
コンピュータ操作のリテラシの有無でお客様をどうこう言うっていうのは勿論論外なんですが、それを仮に百歩譲ったとして、お客様がシステムというものに何を望んでいるのか。カッコイイUIはたぶん本質では無くて、何かを判断する為の材料を抜き出してくれるレポーティングシステムという要素だったりする。でもUIだって立派に業務の一部。なので、テクノロジは勿論大事だけど、もっとお客様が望んでいるモノとは何か、解決したい課題とは何か、課題のある業務とはそもそも何なのか、という事に対して意識を強く持っていないとBuriを使う以前に何も改善していけないんじゃないか？
そうする事で、お客様の望んでいるモノに対して、もっと誠実に接していけるのではないか？
そこで、今改めて、今あるテクノロジできちんと業務システムを作るという事を考える必要があり、業務システムとは何かを見直す必要があり、それを踏まえて初めて「Buriってどうなの？」という事を考えられる下地になる。
と、ここまでヘビーではなかったかも知れませんが、僕は結構重く受け止めた内容でした。
昼の部：Buriの基本を知ろう
羽生さんがおっしゃられた「Buriを知るのに必要な知識」はコチラ。これらに自信がなければBuriに手を出しちゃダメだって。(手を出しちゃいましたが、何か＞＜)
多ー＞＜
でも、Buriを動かすだけならとても簡単。前回の僕のエントリでも取り上げたBuriAutoSelectProcessorとそのさらに奥にあるSimpleBuriProcessorとStandardBuriProcessorで用意されているtoNextStatusを呼ぶだけ。パラメータが何気に「Object」で定義されていて、「オイ、こりゃ何渡せば良いんじゃい＞＜」となったりする訳ですがｗ、そこは前回までの僕のエントリを見て頂くということでｗｗｗ
実際Buriのアレコレは、java-jaのWikiに「ぶり祭り in java-ja」で使われた資料がダウンロードできるので、ぜひ見てみて下さい。僕もBuriのトッカカリを得る為に結構な回数読み返しました。
ちなみにここで羽生さんがおっしゃられていた名言。
「非正規化されたプロセスを、状態という観点で正規化したものがBuri非正規形のプロセスを状態という観点で正規化するのがBuri」との事。ナルホド！！
Buriで使うXPDLで書かれるフローは、基本的に1つのエンティティに対して1つのプロセスだけを記述するようにしているんだそうです。この場合のエンティティというは×申請書とか○○依頼書のような書類をイメージすると多分近いと思います。で、ここで、http://kamawada.com/~masanori/blog/のmark-wadaさんから、たとえば「申請→発注」という業務の一般的な流れがあった場合、1つのフローにならないの？との質問が。
で、その答えは「ならないし、しなくてOKな筈」でした。
理由は「申請」のフローが完了すればその申請書はちゃんと発注に使える申請書になっている筈で、結果的に大きなフローの中ではきちんと繋がっているから、という事みたいです。つまりBuriの為に書くXPDLは業務フローと言いつつ、完全な業務フローじゃなくてBuri専用の実装だってことですね。
また、マスタ・メンテナンスなどで普通のDaoで更新した方が良いのか、Buriを通じて更新した方が良いのか、という質問もありました。
これは履歴を管理してくれるという点、決めてしまえば考えなくて良い点、の2つからBuri使っちゃえ、との事。
昼の部：escafeFlowEditorことBuriエディタについて
escafeFlowEditorってわりと誰も呼んでないｗｗｗ
という訳でBuriエディタですが、これはかわいい。加えて、JPEdと比べて凄くシンプルな作りになってました。本当に、Buriで使うパラメータ以外をそぎ落としたという感じですね。
これがOSSで公開されたそうです。コチラ（http://www.escafe.org/escafeFlowEditor/）ゴールを「Buriで使えるXPDLを作れる」に設定して現在開発中だそうです。ActionScriptに自信がある方はイカガでしょう？
XPDL書く！とかJPEdで！とか言うと敷居が上がってしまいますが、このBuriエディタならそれほど身構えずに使えそうです。営業の人が出先でお客様を相手にラフ・スケッチを起こすといった用途だけでも全然使っていけると思います。
ちなみにこのBuriエディタにはスイムレーンを書く機能がない、とのこと。でも、フローをぐるぐる回せなくなっちゃうからいらないよね、と個人的には思ってしまう訳ですｗ
Buriを使う場合の設計の肝を知ろう
ここで僕がちょっと質問を。
既存のシステムでBuriを適用させた事はありますか？という質問に対して、「ない」との事。新規にERDなどを起こし直せる案件じゃないとBuriの良さを引き出せない、という事ですね。それはBuriがどうこうっていう以前に「全体の最適化」を常に念頭においておかないと、部分適用で効率化しようとしてもほとんどのケースで実現できないから、だそうです。
というか、それ以前に腐ったERDのシステムは、その上にBuriを載せようが何をしようが、絶対納期も品質もヒドイ事になるじゃんか、とｗ
また、「スイムレーン要らなくね？っていうか、スイムレーン書いちゃダメだよね」といった面白い話に発展してました。人間は空欄に不安を感じるというように、スイムレーンを作ると要らない仕事を作ろうとしちゃうよね、と。
ギョイゾー！に感動しよう
ギョイゾー！本当に凄い！！
本当に、羽生さんと橋本さんのやりとりから30分もしないうちに、UIとDBがどちらもきちんと動いているものが完成してましたもの！
終わった後、いまいち盛り上がらなかったのは個人的に思うのは、開発者な人はすでに「BurixStudioってどう作られてるんだろー？」という脳みそになっていたからじゃないかなーと思ったり。
それはさておき、このギョイゾー！のデモで羽生さんが橋本さんからどんな「お仕事してるんですかー？」と話しながら描いたフローが、ギョイゾー！がジェネレートした画面に常に表示されている事、これが凄く衝撃的でした。お客様が、お客様の業務のどのポイントにいるのか、を意識できるこのちょっとした工夫って相当すごいことなんじゃないか、と。
加えて、羽生さんが書いていたフローを見れた、というのもかなり貴重でしたね。
羽生さんは、まず橋本さんから聞くお仕事の流れから、中心となるエンティティを探そうとしていました。
とあるWebサービスの申し込みを管理する機能、というシチュエーションで話をしていたので、「申込書」を中心のエンティティとなるものとして設定し、それのフローとしてBurixStudioでフローを書いていく、といった流れ。これはBuriを使った設計のキモの1つだと思った次第です。
ちなみに、自動生成は確かに凄まじい破壊力を持ったツールだけれども、でもちゃんとテストとか確認はするよとの事。(Ognlの書き忘れとか、そういった事がいまのところゼロにはできないから、というのが理由だそうです。まぁ人が作って人が使うものなので、完全自動化はなかなか難しいですね)
でも、○○申請書を管理するシステムをｎ人月だから×円、といったやり方をしているトコロと比べると圧倒的な生産性ですよ。
一般的には2〜3週間くらいかかるかも、みたいなモノが30分かからないんですから。やはり、黒船。
昼の部マトメ
という訳で、Buriを堪能した昼の部でした。
Buri、というのはそれを使ってシステムを作ろうとする人間とシチュエーションがかっちりはまれば、物凄い効果的なツールだという事がよく分かった内容でした。そこでスタロジなんかは「業務システム専業」を宣言し、元請にこだわってBuriが最大限の効果を上げられるシチュエーションを作り上げてきたのだなぁ、と。そして、「状態という観点からの正規化」を出来る人がいて、となればBuriは業務システムを扱う限りほぼ最強なのではないか、と。(TwitterのようなサービスをBuriで作るのはたぶん「間違ってる」ｗ)
そこで、結局はフローの品質が重要になってくるんですね。だからフローがまともに書けないとBuriを使っても効果は出ない、と。でも、フローがまともに書けないなら何でプログラム作れてるの？というほどに、業務システムにとってフローは大事なのだからやはりフローを意識しないとダメですね。
そして、業務システムはフローだけでなくデータモデルもとっても重要なのですが、Buriが状態管理をしてくれているおかげで、ERDから「削除フラグ」「更新日」「作成日」「更新者ID」「作成者ID」等といったカラムを要らなく出来る、と。こうして今でいうところの概念モデル、設計モデルに近いERDをそのまま実装で使えるように出来るというメリットによって削減できるリスク、等を考えれば、やはりBuriの持つ効果は凄いです。Buriが凄いからスタロジはBurixStudioなんてお化けツールを作ってしまう訳で、ギョイゾー！なんて黒船を作りだせちゃう、と。
そんなBuriを作ったid:makotanはやっぱ凄いですよね。
あの羽生さんが、Buriを理解するのに２年くらいかかった、とか言ってましたけど、それだけ凄いモノなんですよね。
それをOSSで公開するなんて、本当お二人は凄い。お二人にだったら抱かれても良い！(まぁ丁重にお断りされましたけどｗ)というくらい、凄いなぁ、と。
夜の部ｗ
id:makotanに来年のSeasarConferenceでBuriについて話してね、とｗ
頑張らねば＞＜
あと、高卒DQNエンジニア(高卒いらなくね？的なorz)としてid:t_ishidaに担がれそうになった僕的に、要件定義とか上流工程ってでっかい企業の偉い人たちがやるんだーと思っていたふしがありましたが(とは言え、担当した事はあるのでそこまで卑下してもいませんけど)、冒頭でも書いたようにその要件定義という工程に本腰入れているコンサルティング・ファームの中の人は要件定義を上流工程なんて思っていないんだぞ、という話を聞いたのが結構衝撃的でした。
「要件定義は下流工程」なんだそうですよ。
お客様の経営課題に対して意思決定に参加できないでしょ、と。
なるほどなぁ、と。
マトメ
参加出来て本当に良かったですね。
会場には、id:kunit氏、id:shot6氏、id:yone098氏なんかもいまして、なんて言うか「これなんてSeasarConference2008Autumn？」みたいな感じでしたけどｗ
このぶり祭りで得られた刺激を糧に、Buri入門記をより頑張らないと！と思った一日でありました。
