たかふーのブログ このページをアンテナに追加 RSSフィード Twitter

2009-12-24

今年の棚卸:「Buriは今のSIerではオーバースペックなミドルウェアである」

今年はBuriでスタートした1年でした。

Seasar Conference 2009 Whiteでは大きな部屋でお話をさせて頂けたり、buri-ja勉強会も2回ほど開催させていただけたり、僕の2009年を語るにはBuriは欠くことができない大きな存在でした。

さて、今年一年(と言っても後半半年間はBuriどころじゃない微妙な日々を送っておりましたが><)Buriと接してみて、Buriとは何かというものを今井なりに掴めた気がしております。

2009年もあと僅か、今年の棚卸の意味も込めてBuriについて書きます。


結論を先に書いてしまうと、表題に書いた通り

Buriは今のSIerではオーバースペックミドルウェアである

という表現に尽きます。


Buriは「ワークステートエンジン」であり、業務ロジックからIF文を無くそうとした場合、恐ろしく強力なアイテムになります。これは、間違いありません。

具体的には、Buriが持つ3つのテーブル(残り6個は飾りです!偉い人には(ry)でアプリケーションが使うすべてのテーブルの状態を管理します。それだけで、テーブルからXXフラグや状態を表す区分が消えます。ではどうやってレコードの状態を判別するのかというと、BuriのテーブルとアプリケーションのテーブルをJoinしてSELECT文で取得します。

入力データの状態遷移に強い関心を持つ業務向けのアプリケーションでは、このアプローチは非常に有効です。コードからIF文が消え、状態を判別する為にSQLのWHERE句を頑張らなくても済み、かつUPDATE文を自分で書く事なく状態の更新をしていく事ができます。

IF文の無いコードと簡単なSQLは、テストの難易度が比較的低くなる筈ですから品質に良い影響を与えます。(もしかしたら、XPDLで書かれるフローが視覚的に良い影響を与えてくれるかも知れませんが、実はBuriの強みはそこではないと考えるようになりました。)

しかしこのアプローチの結果、某オンライン・ショッピング・サイトのように「結構やばい事態が発生したので、特定の日付以降の注文を無効にしたい」といった場合、Buriを使った場合はBuri固有のテーブルに直接手を入れるか、Buriのフローでイレギュラーな状態遷移を実現した上で対象の全レコードBuriAPIに投げるか、結構手間のかかる作業が発生するようになってしまいます。


僕は某社とはBuriを通じてしか接していなかった*1ので詳しくは全く分からないのですが、ギョ◯ゾー!という脅威のサービスの根幹にBuriが使われていたと聞いています。

それを踏まえてBuriできちんとビジネスを回せていたという事はどういう事かと妄想してみると、いくらBuriを使って高機能なジェネレータを作ったところで前述のイレギュラーなUPDATEの実行やフローの改ざんを毎回やっていたのでは手間がかかりすぎて仕方がない筈で、そこできちんとそこをカバーする品質管理があった上でのBuriだったのではないか、と考えた訳です。

イレギュラーな対応が発生するという事は、要求・要件から始まりコード・テストの各工程の品質に何かしら問題があるという事で、それをきっちり解消しておけなかったから例外的な何かが発生して、それが故にイレギュラーと呼ぶ訳ですが、そういった事態を完全に撲滅できていない現場は、やはりまだまだこの部分で不十分なところがあると言わざるえません。

そこにBuriを載せても、若葉マークさんがF1をドライブするのと変わらないのではないか、と。(その点、某社にはF1をドライブできる人が揃っていたと思いますよ、本当に。)


という訳で、Buriにとっかかるハードルは高いのですが、それを実案件で使うのはさらに高いハードルがあると言えます。いくらBuriが、IF文をなくしフラグをなくす事で生産性向上に強力な後押しをしてくれると言ったところで、システム開発全体を見ればそんなものはごく一部の話です。そのごく一部の為に、とっつきにくい状態遷移とその管理の考え方を普及させて、かつBuri以外の部分でBuriの優位性を損なわないようにするには、そうとうな苦労が伴なうと思います。

というか、Buriを使って成功する案件は多分Buriを使わなくてもきっと成功します。もちろん、工数といった部分でどれほどのコストがかかるか、という部分に結構大きな差が出てくるでしょうが。。。


となると、Buriを使う以前に解決しなければならない課題が多くあることに気づきます。「XPDLを書く前にExcelでも良いので業務フローをしっかり書けるようになりましょう」とか「正規化したERを書けるようになりましょう」とか「お客様の望むシステム像をちゃんと捉えましょう」とか、そのあたりをしっかりやって初めてBuriが活きてくる。

そこまでできていなければ、Buriを使ってもきっと有効に使う事は難しいだろう、と。

そういった意味を込めて、「Buriは今のSIerではオーバースペックミドルウェアである」と表現した次第です。


「偉そうに言ってお前はどうなんだ?」とdisられそうなので白状しますが、いまいはまだBuriを実案件で使えてません><

メンバーへの落し込みとか、開発プロセスの変更とか、そのあたりを解決できなかったので投入を躊躇し続けています。

こんなんでBuriについて語ってごめんなさい><

*1:いまいを某社メンバーと思っていた、という方が結構いますが、実はビジネス上の接点はゼロです。そもそも今井なんかあの方々の足元にも及びません><