第一回 Wagby ユーザー会に参加して

2011年11月に Wagby ユーザー会の設立総会を行いました。それから5ヶ月が経過し、いよいよ第一回のユーザー会(勉強会)がこの 4 月に開催されました。私は大阪、東京、沖縄の全三箇所に参加しましたので、その報告を行います。

スミセイ情報システム株式会社様のケース(大阪)

お客様向けのシステム構築を行うが、自社のシステムはExcelばかり...そんな「紺屋の白袴」を脱するべく、さまざまなツールを探し、Wagby に出会った。

"作らない" でシステム開発ができるといっても、どこまでできるのか。社内で精鋭を集め、徹底的に Wagby を評価したところ、機能面・開発保守面・環境面いずれも求めるレベルをクリアできていることを確認。最大のポイントである「正しくデータ管理がなされ、アクセス制御が行える」ことをクリアできたところで採用を決定した。開発方法も最初は戸惑ったものの、馴れるとサクサク作っていくことができた。

最初のターゲットシステムは「作業実績管理」。これまで現場が Excel で入力した実績数値を部門でまとめ、さらに全体でまとめていく。この作業に時間をとられていた。特に今回のシステム化の鍵は権限管理。協力会社を含めた利用になるため、他社のデータの閲覧制御など、さまざまな工夫をこらしていった。開発途中で発生した問題はジャスミンソフトに都度、改善を求めていった。

月締めバッチ処理や、Excel 連携機能などは手作りで、Wagbyとうまくつなぎあわせることで完成。カットオーバーから半年が経過したが、数百人の利用規模でシステムトラブルが一度も発生していない。今後は適用業務を拡大していくためさらに Wagby 開発体制を整えていきたい、とのこと。

参加者からは「開発体制の整備について詳しく伺いたい」「カスタマイズのポイントはどこか」など、活発なご質疑がありました。

株式会社エフ・エフ・ソル様のケース(東京)

金融系のお客様に、Wagby でシステムを開発し、運用までをサポートしていくという仕事において、Wagby に期待したのは非機能要件の充実性。ユーザー管理やログ管理をはじめとするさまざまな要件は、お客様からみれば"当たり前"かも知れないが、実際に案件毎に手作りしていくのは大変なところ。Wagby はその部分が充実しているのが高い評価につながった。他にも自動生成ベースでありながら、カスタマイズ可能という点で安心感があった。SIerとして「作る価値より、使う価値」を高める視点でお客様と向き合おうとしている。

Wagbyではバッチ処理部分は手作りとなっているが、Wagbyの定義を工夫することでバッチ処理連携が行いやすいという設計方法を発見した。また「Wagbyの帳票機能は便利だが、帳票ファイルを個別のPCにダウンロードさせない方法」など、業務系ならではの工夫も行っていった。全体ボリュームからみればわずかなカスタマイズでも、顧客満足度を著しく高めることができた。

参加者からは「バッチ処理連携の考え方がとても参考になった」など、Wagbyのマニュアルでは表現されていない設計手法に賞賛の声が上がりました。

株式会社リウデン様のケース(沖縄)

社内向け原価管理システムの開発事例。開発者は営業担当者であり、自らの本業である営業の傍ら、半年ほどで構築した。まったくカスタマイズなしで、すべてWagby定義ファイルのみで実現。システム化にあたっては、見積作成の際に、原価を明確にすることで、安値受注を避ける仕組みを導入した。利益率が明示され、各種重要数値が色分けされるなど、ユーザーインターフェースに細かい気配りがされている。また各工程完了毎にメールを送信する機能は好評。現在は十数名が利用している。

参加者からは「多くの中小企業では、担当者任せの見積作成を脱し、受注精度と利益率を高めたいと考える経営者は多い。このシステムを外販してはどうか。」との声があがりました。各社それぞれ方式は違えど、思いは一緒。Wagbyなら実現できそうだと感じたようです。

株式会社ODNソリューション様のケース(沖縄)

これまで蓄積してきた汎用系パッケージのWebアプリケーション化をWagbyベースで実施している。これまでさまざまな手法を検討してきたが、結果的にWagbyはもっとも理想に近い環境であった。

1990年代から2004年まで、ERP導入が盛んだった。業務をパッケージに合わせることができるか、が難しい。アドオンするとパッケージのアップデートができないという問題があり、最適解ではなかった。

2005年から2007年にSOA対応ERPが登場。アドオンの8割を占めるといわれたデータ連携は解消できると期待した。しかしながら残り2割はトランザクションデータ登録機能(伝票入力)のカスタマイズであり、業務アプリケーションでは重要なところ。これはSOAでは解決できないテーマであった。

2008年にカスタマイズ可能なERP登場。Microsoft Dynamics シリーズや Salesforce など。ノンプログラマーでも分散型アプリケーションを開発できるというものだが、これらはベンダーに囲い込まれてしまう。指定された(有償の)ミドルウェアしか使えない。

拡張性の高いERP作成をサポートする方法がないものか?その中でWagbyに出会った。定義ファイルから自動生成されたコードがカスタマイズ可能という視点は重要。とはいえ、現在のWagbyでもトランザクションデータ登録機能のカスタマイズは難しい。複数モデルを参照し、複数テーブルを同時に更新する。10テーブル以上を想定している。しかし次の R7 というバージョンで「1画面で複数モデルを扱えるようにする」「トランザクション境界をカスタマイズしやすくする」となっていたため、Wagbyベースで開発しても(将来的にみて)大丈夫だろうと判断した。

Wagbyの利用にあたっては、80%の自動生成を目指した。残り20%は手組みという体制を敷いた。結果、これまで時間をとられていた80%の開発リソースを全力で、20%の顧客ニーズ対応部分に注力できた。従来の開発ではできなかった方法であり、開発側・顧客側双方の満足度が高まる。これはSIerにとってよいことだと感じている。

開発したデモでは、カスタマイズした画面が披露された。Wagby標準ではなく、完全にカスタマイズされたユーザーインタフェースで、複数モデルの情報が一画面に収まっている。操作性もよくできたクライアントサーバ側のシステムにまったくひけをとらない印象。すべて JavaScriptCSS で構築している。カスタマイズした画面は、全体の数パーセント程度だが、お客様がもっとも重要視する部分である。

Wagbyバージョンアップで気になったのは、開発したコードが新しいバージョンに適合するかどうか、ということ。しかしこれまでは(R6系の範囲では)トラブルはなかった。バッチ処理も多く作成したが、Wagbyが自動生成したコードを使い回すことで、この部分も従来方式と比較して工数を削減できている。

参加者からは「Wagbyはカスタマイズすることで、ここまでできるのかと驚いた。カスタマイズするためにはどのようなスキルが必要か」といった質問が上がりました。画面のカスタマイズは JavaScript に精通した技術者が必要。Javaサーバ側の部分はWagbyが同梱しているStruts,Spring,Hibernateの経験がある技術者が対応することで可能である、と回答されました。

まとめ:Wagby 普及の鍵は、ユーザーの声であることを実感

ユーザー会では私が驚くような内容ばかりで、本当にやってよかったと思います。懇親会ではユーザー同士の交流も活発に行われました。このような中から、Wagby あるいは業務アプリケーション全般に対する良いアイデアが登場してくるものと期待しています。

ところで私は懇親会の席上、大津ユーザー会会長に次のような質問を投げてみました。

Wagbyの機能がどんどん増えると、技術者の仕事がなくなると不安がられることはないか。」

それに対する会長のご返事は、とてもシンプルなものでした。

「余計なことは気にせず、使いやすいと思うものをつくったらいい。」

おっしゃる通りです。実際、ユーザーの皆様は「使いやすいと思ったからユーザーになり、ユーザー会にも参加して」いらっしゃいます。私たちの使命は、ひたすら改善の声を拾い上げ、製品に反映させることです。そのような関係を継続していきたいと、思いを強くした次第です。

なお、発表各社様のご厚意により、発表資料は「Wagbyユーザー会」参加者の皆様で閲覧することができます。
http://wagby.com/users/index.html

次回は6月の「Wagby Developer Days」です。こちらも盛り上げていきますので、よろしくお願いします!
http://wagby.com/wdd2012.html