Wagby Developer Day 2015 終了報告と、他製品比較セッションの内容紹介

第4回目となる「Wagby Developer Day 2015 」は、過去最多となる 251 名の事前お申込をいただきました。当日の出席者も 218 名で、出席率は86.8 %に達しました。ご登録およびご参加いただいた皆様、ありがとうございました!

各セッションのご発表はいずれも感心するものばかりで、ユーザー様ならびに代理店様の Wagby の使い方がますます高度化していることを目の当たりにしました。後日、改めてブログに書かせていただきます。

ひとまず、各セッションの発表資料をダウンロードできるようにしました。参加されなかった方もダウンロードできますので、当日の雰囲気を感じていただければと思います。

資料ダウンロード|Wagby Developer Day 2015

その○×表、ちょっと待った!Wagbyと他社製品の違いについて、正しい比較のポイントを説明します。

今回はジャスミンソフト枠で発表した「他製品比較」に関するセッションについて紹介します。

多くのお客様で、導入製品を決定するための根拠資料として、いわゆる「○×表」を作成されていらっしゃいますが、これでは本当に自社のニーズを満たすことにならない、という問題提起を行いました。

その理由は、「○×表」には次のような(解決の難しい)課題があるためです。

  • 誤っている。実はできる/できないことが、製品カタログを誤読してしまった。
  • 不足している。例えば「ワークフロー」という切り口で「できる/できない」としても、実際にはレベル差が大きい。
  • 将来のバージョンアップを考慮していない。今はできなくても、3ヶ月後には製品がその機能を実装しているかも知れない。
  • 当初は想定していなかった機能追加も必ず発生する。

私の提案は、まず自分たちはどの立ち位置から、製品を探そうとしているかをはっきりさせることです。

f:id:ynie:20151207102108p:plain

ここで、Wagby と相性のいいパターンは次の通りです。

f:id:ynie:20151207102119p:plain

そして、Wagby でなくてもいいというパターンは次の通りです。

f:id:ynie:20151207102129p:plain

補足します。「オブジェクト指向言語を使いたくない」という場合は、製品が提供する独自言語を使う方が良い場合があります。GeneXusはその代表です。一方、Wagbyは汎用言語であるJavaやJavaScriptを使い、独自言語は提供しないという違いがあります。

「外注で、安価な方を採用したい」という場合は、そもそもツールは何でもよいということになるため、オフショア開発との競合もありえます。正直、このタイプの案件はどのツールでも苦労する予感があります。

「パッケージ開発」も実は二種類あります。多くのパッケージソフトは、競合他社との差別化のため、独自の UI を用意しようとします。いわゆる「顔」となる UI です。しかし Wagby はあくまでも汎用的な画面を大量に作成することに向いているため、独自 UI になりません。そこが向かないところです。

しかし一方で、現在すでに多くの顧客が当該パッケージソフトを採用しており、そのバージョンアップ版として Wagby で開発したものを展開する、という場合は、現行画面に近いものを開発できればお客様に不利益は生じません。このパターンであれば Wagby は利用できます。

最後の「SIer」ですが、ここは意外に思われるかも知れません。ポイントは「要件を完全に満たそうとするSIには向かない」ということです。そうではなく、要件をツールに合わせようとする発想に変えていただく必要があります。このような「自動生成ツールの利用を前提としたSI」は、さらに4方式ある、というのが私の見解です。

タイプ 特徴 求める人材
ツール指向 できるだけプログラムを書かずにツールの機能だけで要件を実現する。既存システム連携、複雑な業務ルール、帳票、BIなどもすべてツールを使い、ツールの組み合わせでシステムを構築する。 各ツールの専門家
高生産性開発 自動生成率 80〜90 パーセントを目標とし、残った部分は従来型の開発方式と組み合わせて実現する。現在のSIの延長としてもっともわかりやすい。 ツール専門家と、ツールが生成するコードをカスタマイズするプログラマ
テンプレート指向 業種・業態に特化した(ツール向けの)設計情報をあらかじめテンプレートとして用意する。カスタマイズ性が著しく向上したERPという位置付け。 ERPを設計できる業務知識
内製支援 エンドユーザがツールを使いこなせるように支援する。ツールの使い方から、要件をどのように設計情報に展開するかをコンサルティングする。 ツール&業務コンサルタント

このいずれか(もしくは複数)を軸とした「自動生成SI」を提案し、ユーザ企業がこれを受け入れられるかどうかが、普及の鍵になります。

具体的な製品との比較方法

ここまで説明したところで、機能網羅による○×表ではない切り口を説明します。

ある一点について、各製品の違いを見極める

例えば「トランザクション処理」を題材とします。出荷伝票の新規登録に応じて、伝票に含まれる(複数の)明細項目に記載された各商品の在庫を減じるというものです。モデルをまたがるトランザクションなので、どの製品であってもカスタマイズコードの作成になります。この記述レベルを知ることで、製品の特性を理解します。

ある製品は、独自言語で記述するでしょう。日本語文章のような言語になっているものもあれば、アイコンを並べることでプログラムができる、という方式もありえます。SQLで実現するものもあるでしょう。

そもそもトランザクションに未対応という製品もあります。トランザクションとは、単に両方のモデルを変更すればいい、というものではありません。ロック制御と、一方が失敗したときに確実に両方ともロールバックできることが必要です。この要件を満たしていないものは、トランザクション不可となります。一般的に、1画面=1テーブル操作に限定した製品は、エンタープライズアプリケーションには向きません。

ちなみに Wagby では、数行のスクリプトで実現できます。トランザクションの開始や終了の宣言、ロック処理やロールバック制御もすべて Wagby 内部で対応するため、開発者のコードは数行で済みます。文法は(独自言語ではなく)JavaScript です。

wagby.com

製品への機能追加が行えるか

自動生成SIの最大の特徴は、実装したい機能をカスタマイズで対応するのではなく、自動生成エンジンを鍛える(改修する)ことで、パラメータ設定によりその機能を実現できるようになることです。これまで、多くのユーザ企業では目の前のツールの機能だけを前提に、不足している機能は自前でカスタマイズしたがる傾向がありました。しかしWagbyは違います。そのような声を積極的に受け入れ、ツールのバージョンアップによって「できるだけプログラムを書かない」スタイルを維持できるように努めます。

私見では(当社も含めて)国内ツールベンダーはこれを受け入れる傾向があるようです。海外製品は難しいのではないでしょうか。そのため海外製品では、それを担ぐ国内代理店が、代替案を出せるかどうかを確認するとよいでしょう。

保守の考え方

エンタープライズアプリケーションは長寿命です。利用し続けている間、どのような形でツールベンダーと付き合いを継続するか、も考える必要があります。保守契約を締結しなければ製品そのものが動作しなくなるか、というのは重要なポイントの一つです。

その他:Wagbyの特徴

Wagbyがアピールしている、その他の特徴は次のとおりです。

  • 生成されるソースコードの変更可能ポイントが多い。
  • できるだけ最新の Java 技術を取り込む方向で進化している。
  • SQL は書かない。
  • オープンソース技術を基盤としている。
  • 自社ですべて完結させない。他社製品・サービスとの連携を推奨する。
  • クラウドでも自社サーバでも運用できる。

まとめ

本セッション参加者は、Wagbyのこの機能が他社と違う、という具体的な部分を伺いたかったのかも知れません。しかし私は、そのような違いは表層的で、かつ各製品とも進化する中で埋められる程度の違いでしかない、と考えています。しかし根本的なアーキテクチャは簡単には変えられません。その根っこの部分を抑えて、自社と相性のいい製品を選択することが大切だというお話をさせていただきました。この視点が、何らかのヒントになれば幸いです。