さった2013年7月25日、東京・六本木ラフォーレミュージアムで開催された「Wagby R7発表会」は無事に終了しました。翌日の「Wagby Developer Day 2013」とあわせた総申込者数は240名を超え、うち初日の発表会の申込者数は200名ほど。実参加者は160名超172名でした。ご登録ならびにお越しいただいた皆様、ありがとうございました。講演後は多くの方から「期待している」というお声をいただき、スタッフも大いに気合いが入っています！
さて当日ご来場いただけなかった方、および、会のあとにこのイベントを知ったという方向けに、私の発表骨子を記載します。以下、長文ですが、Wagby R7発表会で私が何をお話したのかを、できるだけ忠実に再現します。
ご挨拶
本日は私にとって特別な日です。もちろん Wagby R7 を皆様の前でご披露させていただけるという記念日ですが、もう一つ意味があります。それは何かというと、Wagby の歴史にヒントがあります。
当社が Wagby R5 という製品を市場に投入したのが2006年、その2年後となる2008年に R6 を発表しました。スマートフォン対応などを行った2010年頃から「次は R7 を出します。」という話をお客様にしていました。しかしそこからが長く、そろそろ私は嘘つきよばわりされてもおかしくないほどです。今日の発表会で、私は嘘つきではないことが証明された、その記念日という意味であります。
Wagbyの導入実績は223社となりました。「6年間 Wagby をやってきて、まだ223社か。」というお声はあると思います。ただ、この数字は別の側面からみると面白いのです。ご存知のように今、エンタープライズシステムの新規案件は、なかなか出てこない状況です。多くの案件は、とうに寿命を超えたシステムを延命させるための保守業務です。しかし Wagby は製品の性格上、既存システムの保守では利用できません。つまり223社が「新規システム開発」に Wagby を選択されたということです。
そして出荷ライセンスは448本になりました。1社で複数ライセンスをご購入いただくこともあるので、ライセンス数の方が多くなっています。
二年前にはユーザー会を設立致しました。これまでのべ10回、勉強会を実施しています。勉強会ではWagbyの利用紹介にとどまらず、Wagbyをどう改善すべきかという意見交換を積極的に行っています。さったユーザー会では始めて、お客様の工場見学会も実施しました。ヘルメットをかぶった記念写真があります。今、参加企業は91社になりました。すべての組織がご加入いただけているわけではありませんが、このように（参加企業様の）お名前をご紹介できるというのは、私たちにとって大きな力になっています。
なぜWagbyをつくったのか？
本日はWagbyをまだ使ったことがないという方も多数、ご出席されていらっしゃいますので、この機会になぜ私がWagbyを作ろうと思ったのか、その動機をR7発表の前に少しお話させてください。
"PC-8001" を知っている方、（この会場に）どのくらいいらっしゃいますか？ ありがとうございます。私と同世代ですね。私は13歳のとき、当時通っていた中学校の理科の先生が管理していたPC-8001を使い倒し、プログラミングの面白さに夢中になりました。思春期の男子はこの時期、バイクや車やら音楽やら、何かに興味を集中させるものですが、私のようにマイコン、当時はパソコンと呼んでいませんでした、に反応した層は決して少なくありませんでした。
また当時のメディアは、若き日のビル・ゲイツやスティーブ・ジョブズを頻繁に紹介していました。海の向こうの盛り上がりを直接知って、「ソフトウェアは世界を変える」ことを目の当たりにし、薫陶を受けてきたこの世代は、自分もそういうことをやってみたいという気持ちが高まっていきます。
社会人になった私は迷わずIT業界に就職しました。最初に入った会社では、さまざまな技術を学ぶ機会をいただきましたが、それだけではありませんでした。プログラミングという技術をどうやってお金に変えるのか、そこで私ははじめて「人月」という仕組みを知ります。人月については今もいろいろな議論があります。私自身は、当時の先輩に紹介された「人月の神話」を読んだことが、この問題を深く考えるきっかけになりました。多くの方が（この本の内容を）ご存知かと思いますが、一言で表現すると "10人月というプロジェクトは10人投入すれば1ヶ月で完成することを意味しない。にもかかわらず火を噴いたプロジェクトに人を投入して解決しようという例が後を絶たない。" という問題を提起しています。プログラムが大好きであった私にとって、この問題をプロジェクト管理という手法ではなく、ソフトウェア技術そのもので解決できないのか？という漠然とした思いが芽生えました。
Javaとの出会い
そうこうしている中でJavaと出会いました。次世代の基幹系はCOBOLからJavaへという流れが加速する過程で、フレームワークが大流行します。StrutsやSpringといったフレームワークの上で稼働するソースコードは、誰が書いても似たようなものになります。品質一定とは、まさにエンタープライズアプリケーション向きです。そうであれば、このコードはパターン化できるのではないか、パターン化できれば自動生成も可能ではないか？ そのように考えた技術者は私だけではありませんでした。当時は知りませんでしたが、このように業務をパターンとして捉え、パターンの組み合わせでアプリケーションを構築するための手法として、DSL (Domain Specific Language) ドメイン記述言語、つまり業務に特化した言語を使うという考え方がすでにあったのです。Wagbyを発表した時点で、同じようなコード生成を行うソフトウェアは数多くありました。Wagbyもそのうちの一つ、というものでした。
そこで私も沖縄からいよいよ東京にでてまいりまして、最初はSIerの方々にWagbyを紹介して回りましたが、あまり評判が芳しくない。もちろん当時のWagbyの機能が低いことが直接の原因でしたが、さらにヒアリングを重ねていくと別の要因が見えてきました。仮にWagbyにこうこう、こういう機能があったとしても、やはり採用しないという。その理由は"自動生成"に対する不信がありました。1980年代にCASEツールや4GLを試された経験者ほど、自動生成されたソースコードは可読性が低い、また仮に読めたとしても変更してしまうと、もう自動生成できない。すべてをツールで完結させるという発想ではなく、開発者がカスタマイズできる担保がなければ、この手のツールは採用できないということでした。なるほど、私たち自身も技術者の視点から、その意見にはまったく同意できました。そこでWagbyの目標は早い段階から可読性の高いコードを生成し、かつカスタマイズ可能な枠組みにする、ということになっていきます。これは最新のR7にも受け継がれている思想です。
一方で、エンドユーザ様向けのノンプログラミングツールという市場があります。また、Wagbyと同様にソースコード生成型ツールの市場もあります。しかしこの二つの市場は分断されているように感じました。両方の立場の人が使える一つのツールがない。そこに着目し、Wagbyは類似製品には珍しく、エンドユーザからもSIerからも問合せがくる、という二兎を追うことにしました。
（R6までのWagbyで）アプリケーションの基本仕様をExcelで作成し、さらにJava技術者がEclipseでコードカスタマイズを行うというスタイルを提案する。こう決めたのは良かったのですが、これをどう説明するかで大変、苦労しました。自動生成という言葉を使って説明する限り、なかなかWagbyの本質を理解していただけない。マーケティングで悩む時期が続きました。
そのような時に、日経コンピュータ2012年3月で「超高速開発が日本を救う」という特集記事が出ます。なるほど、"超高速開発"という切り口があったかと、いたく感銘を受けた私は以後、この言葉を使ったマーケティング活動に切り替えます。記事中には十数種類のツールが紹介されていたのですが、ありがたいことに二社、Wagbyを使ったという事例が紹介されました。
この記事に書かれている内容を簡単に説明すると、工数削減という発想は攻守の両面で有効であり、工期短縮、品質安定化、コスト削減という効果に直結するというものです。私の理解では、これまでSI業界で "工数削減" という切り口を訴えることはタブーでした。どの会社も人月単価で競争しており、それが最終的にオフショア開発へ行き着くのは周知の通りですが、それでも工数削減は言わなかった。この記事はここに踏み込むことがSIの新しい道が拓けることを、具体的な成功事例を挙げて示しました。このあと、当社への問合せは急増しました。やっぱり、まだWagbyは知られていなかったということですが、しかしそこには本当に巨大な市場開拓の余地があるということも改めて気付かされました。
さて、これは当社の独断による、Wagbyの市場での位置づけを示した図です。
Excelマクロを使ってデータベースとやりとりを行う「Excelデータベース」や、Webブラウザ上でフォームの設計が行える「Webデータベース」など、エンドユーザ向けのツールも多くありますが、これらは基幹系の領域に踏み込もうとはしていないように感じています。そうではなく、基幹系とはデータ連携ツールなどを介して、データをやりとりするという発想です。一方、Wagbyと同じく基幹系・ソースコード生成型のツールも「生成されたコードをどこまでカスタマイズさせることを許すか」という点で温度差があります。Wagbyはカスタマイズ領域を広くとっている分 Java 開発者の活躍の場を用意しますが、さらに定義情報だけでも十分な機能をもったアプリケーションが生成されることから、いわゆる簡単開発を望む現場の利用者でもお使いいただけます。両方の境界をまたいだ事例が豊富にあるのはWagbyの強みです。
R7 デモンストレーションと機能紹介
（いよいよ定義とビルドを一体化して Web ブラウザで実現する「Wagby Designer」と、R7 ビルドされたアプリケーションのデモ。R6との違いや、新機能「ポータル画面」や「スマートフォン対応の高度化」などを説明しました。下の図は、当日発表したポータル画面を紹介したスライドです。）
価格
Wagbyの隠れた特徴の一つに、機能に差がない、同一のWagbyを大規模から小規模まで使えるライセンス体系を提供していることがあげられます。（以下、省略）
なお、この発表会を記念して、本日から9月30日までの期間に、R7を先行発注していただいたお客様に対して、半額でのご提供を行うというキャンペーンを開始します。詳細はWagby販売代理店へお問い合わせください。
出荷スケジュール
まず、この9月30日に「R7 Preview」を出荷します。これは新しい Wagby Designer と、ユーザーインタフェースの刷新が含まれます。新機能のすべては含まれず、また現行 R6 のすべての仕様を吸収できていないものであるため、Preview 版という位置づけになりますが、これで開発を行うことができます。
12月20日に「R7 Release Candidate」を出荷します。これは現行 R6 の仕様をすべて満たすもので、また R6 からの移行ツールも含まれます。年末・年始を挟み、年明けの1月15日に「R7正式版」として固めます。この版から、運用サポートの対象になります。
よって年内中に本番稼働する案件については現行のR6を推奨しますが、年明け以降の本番運用であればR7ベースで開発スケジューリングを行うことができます。なおR6は、R7正式出荷後も引き続き安定版として不具合修正を続け、かつ販売も継続します。
正式版出荷以降、R7のバージョンアップは四半期に一度のペースで実施されます。また R6 の保守はかねてよりご説明していたように「R7正式出荷タイミングから5年間」ということで、2019年1月まで実施させていただきます。
Wagbyの活用方法
ご存知のように、エンタープライズアプリケーション開発分野には多くの困難があります。「一括発注方式で、正確な見積もりはできない。」「仕様は途中で変更されることが当たりまえ。」「パッケージに業務を合わせることは難しい。」などです。これらの問題を解決するために、今 3つの新しい潮流があると感じています。それぞれ「要求開発」「アジャイル」そして「超高速開発」です。アジャイルと超高速開発は重なるところが多いですが、私の理解では、アジャイルとは"動的に計画する"という、プロジェクトの進め方全般を指します。一方で超高速開発は、手組みではなく高速開発を実現するツールを使うという思想を指します。ウォーターフォールか、アジャイルかということではなく、どちらの進め方でも利用できるものです。
そしてWagbyの立ち位置は超高速開発を実現するためのツールです。具体的な活用方法として3つを紹介します。一つは「（エンドユーザによる）Wagbyを使った内製」です。これはプログラマを自社で抱える必要がないということで、現実的な解となっています。次は「ERP + Wagby」です。業務をERPに合わせるのではなく、ERPと自社業務の差異をWagbyで開発するのです。ERPには直接、手を入れないため、ERPのバージョンアップが行いやすくなります。そして三番目は「Wagbyでスクラッチ開発」です。Wagbyが生成したソースコードを活用し、足りない部分だけを開発するようにします。これによってプロジェクト全体の品質を維持するとともに、プロジェクト費用を削減します。これは大規模案件ほど有利になります。
実はこの3つのアプローチにそれぞれ取り組まれている代理店様がいらっしゃいます。明日（注：翌日の7月26日）のWagby Developer Day 2013で各社様が、この具体的な内容を発表致します。
Wagbyを使えば経営とITの距離を縮められる
私からの最後のメッセージです。経営者とIT従事者の距離は本当に離れていると皆、わかっていることですが、これを解決することができていません。Wagbyは最終的に、この問題に対応したいと考えています。
企業経営者はIT従事者を評価できていないのではないか。ここからは私の仮説です。ITはコストがかかる割に、現場からは「使えないシステムを押し付けられた」という不満の声が多いことに経営者はとまどっています。そもそも、ITにかかるコストの算出根拠がよくわからない。ハードウェアはどんどん進歩し、安くなりました。しかしソフトウェアの価格は変わっていない。人月単価を減らしても工数そのものは以前と変わっておらず、人月単価削減はソフトウェアの品質向上や、機能向上と必ずしも直結していません。そのような開発そのものに対する不信感が根底にあるのではないか、ということです。それでもIT従事者の立場としては、やはり経営者に褒められたいのです。"君たちのおかげで社内が活性化したよ、良くなっているよ、どうもありがとう。" という一言が欲しい。そのために、経営者にどのようなアピールをするべきでしょうか。
この状況を打開する最初の一歩、それが「開発スピード」です。 "社長、今までの10倍のスピードで開発します。" と提案してみてください。これを実現できれば、感心を通り越して、間違いなく感動されます。
もちろん私はスピードがすべてを解決するとは言っていません。しかし双方の言い分に隔たりがあり、事態が硬直化している状況で、IT 従事者が自らの技術革新によって経営層を動かす「最初の一手」として、開発スピードの改善は有効だと考えています。これによって、仕様が曖昧だったことがあとで明白になっても、作り直す時間が手に入ります。そのためにはソースコードを捨ててもいい、という環境が必要なのです。この「やり直しの勇気」が手に入る、ここに価値があるのです。このメリットは大きいと、なぜ私が言い切れるのか。それはWagbyユーザー会で得られた知見だからです。どのプロジェクトも、準備万端でシステム開発ができているわけではない。手戻りはゼロにはなりません。しかしWagbyによる開発スピードの向上によって、失敗を乗り越える力が手に入った、というのです。
ここにWagbyの大きな可能性があります。Wagbyを使えば、情報システム部門、利用部門、開発者が共通のゴールを持つことができます。今、これらの立場にある方々はそれぞれの主張があって、共通のゴールを持つことが現実にはとても難しくなっています。ツールによってこの問題の解決に踏み出したい、それが私たちの願いです。
私の最後の発表スライドは「超高速開発に踏み出そう！」です。
私のこの発表のあと、実際に超高速開発でどうビジネスが変わるのか、変わったのかという具体的な話が（事例として、代理店様による発表が）続きます。どうぞそのお話を伺って、超高速開発のメリットを感じていただきたいです。Wagbyの提供を通して多くのプロジェクトが少しでも成功に近づくように、これが今や私たちの活動の原点になっています。
本日は長時間、私の講演を聞いていただき、ありがとうございました。
P.S.
Publickeyでも本発表会の記事が公開されました。こちらもあわせてお読みください。
「Springをベースに、PCとスマホ用の業務アプリケーションを自動生成する「Wagby R7」、ジャスミンソフトが発表」
http://www.publickey1.jp/blog/13/springpcwagby_r7.html
