さった7月29日に行われた超高速開発コミュニティ モデリング分科会のイベント "制限時間１時間で実装せよ - モデリングと開発のスピード感を目撃しよう" は刺激的でした。
当日は渡辺座長の司会のもと、会場で開発テーマを公募し、6つの（まったく異なる）業務アプリのテーマが提案されました。参加者全員の多数決の末に決まったのは、風力発電設備の保守管理に関わる業務、というテーマでした。今度はこのテーマについて「こういうモデルになるのではないか」「このモデルで、この機能（要件）は実現できるのか」を、またその場で議論します。モデルは何度も書き換えられるため、ぼーっとすると話についていけなくなりそうでした。10を超えるモデル（と関係性）を固めた後、6つの超高速開発ツールによる実装が開始されました。制限時間は1時間ということで、どの担当者も真剣です。実装の担当者がどういう風に進めるかを目の前で確認でき、いろいろ質問もできる機会など、そうそうありません。
今回、ご参加いただいた超高速開発ツールは次のとおりです。（当日の発表順）
- SAAP - 三光システム。姫路からのご参加でした。Accessを使っています。(修正:2017.8.1 リンク先変更)
- X-TEA - ディービーコンセプト。座長の渡辺さんが提供しています。
- TALON - HOIPOI。実行エンジン型です。
- 楽々フレームワーク - 住友電工情報システム。15年以上の実績。
- OutSystems - bluememe。ポルトガルのソフトです。
- Wagby - ジャスミンソフト。うち。
どのツールも1時間でここまでできる、ということをアピールできていました。「まったく同じテーマ」かつ「ようい、ドン」のスタートであったため、各ツールの違いがわかりやすかったです。個人的には OutSystems がもっともオシャレ感が漂っており、見せ方の工夫は重要だと改めて感じました。今後の Wagby 開発にとっても参考になりました。
この企画はコミュニティならでは、といえます。ツール実装ベンダーと利用者（SIer/エンドユーザいずれも）がモデリングという共通の「ものさし」をもって議論でき、その場でそれぞれの実装イメージを確認できるイベントなど、これまで聞いたことがありません。ハッカソンに近い雰囲気ですが、プログラマーでない方（業務担当者）が一緒に参加できるのが醍醐味でしょう。次回の企画もあるということなので、より多くのベンダーが参加することを期待しています。
デザインパターンの必要性
私が Java 初学者のとき、ちょうどオブジェクト指向のためのデザインパターンというアイデアが登場し、大いに盛り上がりました。プログラマーのノウハウをパターンとして洗い出し、名前をつけることがいかに重要かを学びました。
さて今回のイベントを通して、モデリング分科会の有志で「業務アプリケーションのためのデザインパターン」を整理できるのではないか、という気持ちになっています。私一人では重荷ですが、これだけの経験者が集えば...という期待をもったところです。
コミュニティでのこれまでの活動から、「設計情報（リポジトリ）」の共有化は不可能と悟りました。実装ツールと表裏一体なので、コンバージョンも容易ではありません。せいぜい共有できるのは DDL 程度です。しかしどのツールを使おうとも、設計情報に含まれる「業務パターン」は存在します。これはツールに依存しないものです。オブジェクト指向のためのデザインパターンとの関係を対比させると、位置付けがはっきりします。
例えば今回のイベントでは「親 - 子 - 孫モデル構造」の扱いが各ツールで異なることがわかりました。しかしこの構造そのものは、さまざまな業務アプリケーションで頻出します。また「テンプレート化されたデータをコピーして登録を簡素化する機能」も登場しました。他にも「入力チェック」や「変更履歴」など、よくあるテーマといえます。これらに業界で共通する名前をつけることができれば、設計の役に立つだけでなく、初学者にとっても理解しやすくなります。（オブジェクト指向のためのデザインパターンはまさにそのような役割を担っていました。）
そうすれば、ツールの違いも「こういうパターンを利用できるようになっている」「利用するための設定はこうである」「UIはこのようになっている」という視点から差別化できることでしょう。
もちろんこれまでも類似の発想はありました。しかし一社でアピールしても普及させることは難しく、また、業務パターンもどちらかというとUI寄りであったり、もしくは特定業務に寄った部品であったりしました。今回の私の提案はコンポーネント（部品）ではなく、再利用可能なパターンとして提供することです。
実は Wagby はそのようなパターンを意識しているのですが、「（業界を横断した、汎用性をもった）名前をつける」ことができていません。たたき台は提供できますが、それをさらに洗練させ、一般化し、適切な名前をつけるには、一社では難しいと感じています。もちろんその成果は無償で提供されるべきものです。学会などでの発表としても使えるのかも知れません。
業務アプリケーションのためのデザインパターンが広まれば、多くの技術者が特定ツールへ依存することなく、モデリングの設計能力を高められることにつながるのではないかと考えています。その設計情報を使って、慣れたプログラム言語で実装することもできます。ただ学ぶほどに、ここまでパターン化しているのでれば、そのパターンをパラメータの設定だけで済ませたいと気づくことでしょう。その先に各社がそれぞれのツールの能力を披露する機会があります。
COBOL時代を含め、数多くの業務アプリケーションが開発されてきました。50代から60代のエンジニアは、自らが現役であるうちに、その設計ノウハウを若手に伝えたいという気持ちをお持ちです。しかし業務知識とプログラミング言語の間が広すぎて、意思疎通が難しいということがわかってきました。超高速開発ツールは業務知識を設計情報で表現することができますが、その設計情報の互換性がありません。設計情報のさらに一つ下のレイヤで、ツールに依存しないパターンを導くことで、この問題を解決できないでしょうか。
