ユーザー会の設立総会を行いました。私は大阪、東京、沖縄の全三箇所に参加しましたので、その報告を行います。システム開発ができるといっても、どこまでできるのか。いずれも求めるレベルをクリアできていることを確認。最大のポイントである「正しくデータ管理がなされ、アクセス制御が行える」ことをクリアできたところで採用を決定した。開発方法も最初は戸惑ったものの、馴れるとサクサク作っていくことができた。入力した実績数値を部門でまとめ、さらに全体でまとめていく。この作業に時間をとられていた。含めた利用になるため、他社のデータの閲覧制御など、さまざまな工夫をこらしていった。開発途中で発生した問題はジャスミンソフトに都度、改善を求めていった。連携機能などは手作りで、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登場。ノンプログラマーでも分散型アプリケーションを開発できるというものだが、これらはベンダーに囲い込まれてしまう。指定された(有償の)ミドルウェアしか使えない。拡張性の高いERP作成をサポートする方法がないものか?その中でWagbyに出会った。定義ファイルから自動生成されたコードがカスタマイズ可能という視点は重要。いえ、現在のWagbyでもトランザクションデータ登録機能のカスタマイズは難しい。複数モデルを参照し、複数テーブルを同時に更新する。10テーブル以上を想定している。いうバージョンで「1画面で複数モデルを扱えるようにする」「トランザクション境界をカスタマイズしやすくする」となっていたため、Wagbyベースで開発しても(将来的にみて)大丈夫だろうと判断した。Wagbyの利用にあたっては、80%の自動生成を目指した。残り20%は手組みという体制を敷いた。結果、これまで時間をとられていた80%の開発リソースを全力で、20%の顧客ニーズ対応部分に注力できた。これはSIerにとってよいことだと感じている。開発したデモでは、カスタマイズした画面が披露された。Wagby標準ではなく、完全にカスタマイズされたユーザーインタフェースで、複数モデルの情報が一画面に収まっている。操作性もよくできたクライアントサーバ側のシステムにまったくひけをとらない印象。カスタマイズした画面は、全体の数パーセント程度だが、お客様がもっとも重要視する部分である。Wagbyバージョンアップで気になったのは、開発したコードが新しいバージョンに適合するかどうか、ということ。これまでは(R6系の範囲では)トラブルはなかった。バッチ処理も多く作成したが、Wagbyが自動生成したコードを使い回すことで、この部分も従来方式と比較して工数を削減できている。参加者からは「Wagbyはカスタマイズすることで、ここまでできるのかと驚いた。カスタマイズするためにはどのようなスキルが必要か」といった質問が上がりました。精通した技術者が必要。Javaサーバ側の部分はWagbyが同梱しているStruts,Spring,Hibernateの経験がある技術者が対応することで可能である、と回答されました。普及の鍵は、ユーザーの声であることを実感ユーザー会では私が驚くような内容ばかりで、本当にやってよかったと思います。懇親会ではユーザー同士の交流も活発に行われました。業務アプリケーション全般に対する良いアイデアが登場してくるものと期待しています。ところで私は懇親会の席上、大津ユーザー会会長に次のような質問を投げてみました。「Wagbyの機能がどんどん増えると、技術者の仕事がなくなると不安がられることはないか。」それに対する会長のご返事は、とてもシンプルなものでした。「余計なことは気にせず、使いやすいと思うものをつくったらいい。」おっしゃる通りです。実際、ユーザーの皆様は「使いやすいと思ったからユーザーになり、ユーザー会にも参加して」いらっしゃいます。私たちの使命は、ひたすら改善の声を拾い上げ、製品に反映させることです。そのような関係を継続していきたいと、思いを強くした次第です。発表各社様のご厚意により、発表資料は「Wagbyユーザー会」参加者の皆様で閲覧することができます。その思考は、未来設計から。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。