数千人でも使えるシステムがほぼ自動生成できる

スターロジックが開発しオープンソース・ソフトウエアとして公開しているルールエンジンescafeFlowのワークフロー設定画面
スターロジックが開発しオープンソース・ソフトウエアとして公開しているルールエンジンescafeFlowのワークフロー設定画面
[画像のクリックで拡大表示]
 BurixはJavaベースで,Flex,S2Flex,Seasar2,Buri(旧称S2Buri。現在の正式名称はescafeFlow),S2Dao,PostgreSQLからなります。またコード生成にはPerlやrubyで書いたスクリプトもあります。スターロジックではこの組み合わせで大規模な基幹系システムを構築しています。大規模に対する開発生産性と品質,そして実行時の安定性や仕様変更への対応力というものをずっと磨いてきました。「ギョイゾー!」で開発されたシステムもその足回りを転用しているので,ハードウエアを増強しさえすれば数千人で使えます。

 Buriはスターロジックがオープンソース・ソフトウエアとして公開しているワークフローエンジンです。業務の流れを示す図をXPDLによる定義としてワークフローを実行できます。

 お客様との打ち合わせは,これだけ決めれば,という要件だけなので,インフォセット一つにつき1~2時間,雑談を入れても半日くらいで済みます。その後は設計に半日,製造とテストに1日程度。

 マニュアルは作りません。Flexで,マニュアルのいらない,わかりやすいユーザー・インタフェースを実現しています。

 HTMLより,Flexのほうが生産性が高いんです。Flexの場合,画面とプログラムが1対1に対応させることができるので,自動生成が簡単なんです。画面はYAML(YAML Ain't Markup Language)の定義データから自動生成するようにしています。

 ただ,まだコストを削減する余地はあります。製造とテストをさらに短縮できる余地があるのはもちろんですが,それ以上に今のところデリバリ(納品)に時間がかかる。お客様のところに行って環境をセットアップする必要があるので。ネットを介してASPで使ってもらうようにすれば,この時間とコストは大幅に削減できます。そうすると価格体系もさらに改善できると思っています。

 ニュースへの反響の中に「カスタマイズの追加料金で儲けるモデルなのか」というコメントがあったけど,僕らはカスタマイズはやりたくないんです。もちろんカスタマイズが容易にできる仕組みにはなっています。ですが正直なるべくコードは書きたくない(笑)。でも個別のオーダーメイドにはこだわりたい。

なぜパッケージではなくオーダーメイドのSIにこだわるのですか。

 ここ数年,情報システム部はコンプライアンスを実現するためにパッケージの導入を進めてきました。その結果,パッケージからこぼれ落ちた業務がたくさん出てきた。

コンプライアンスで増えたExcelでリスクが増大

 こぼれ落ちた業務は現場が非公式にExcelシートを作る。Excelでは,データを誤って削除してしまう,誤ってメールに添付して外部に漏洩してしまうといったリスクがつきまとう。作った人がいなくなったら保守できなくなる恐れもある。コンプライアンスを進めることでリスク低減を実現しようとした結果,逆にリスクが増大してしまうという状況になっている。

 パッケージからこぼれ落ちた部分というのは,これまで誰もシステム化を手がけてこなかった,パッケージ・ベンダーにとっては量産が効かないので採算が合わない,情報システム部門も手間がかかる割には局所的な課題でしかないのでかかわりたくないような面倒くさい領域なんです。仕方がないからExcelを使って現場が頑張っている,いわば“Excel難民”。

 「ギョイゾー!」でそういうExcel難民を救いたいと考えています。落穂拾いなんですけど,山のように落ちてる上に意外と誰も拾おうとしないので,泥臭いけどやり甲斐のある領域だと考えています。