Wagbyを使ったことがないが、どういうものか興味がある、という方を対象に文章を書いてみました。現在、業務システム設計に携わっているエンジニア向けです。
最初のポイント
Wagbyを活用するために、システムへの要求と、Wagbyの機能を結びつけるための設計能力をもったシステムエンジニアがプロジェクトの初期段階から関わることを推奨しています。これによって要求を早い段階で (1) Wagbyの標準機能で実現できること (2) カスタマイズによって実現できること (3) Wagbyの機能そのものを拡張すること、の3つに大別します。この段階で、おおよその工数積算も可能になります。
WagbyとDOAの関係
開発対象のシステムを「構造」と「振る舞い」という視点で整理します。その中心となるのは「DOA (Data Oriented Approach) 」であり、プログラムとデータは独立するという概念です。データの「構造」を整理し、これを「モデル」として表現します。次に、モデルの生成を時間軸で整理します。例えば「見積書」から「売上伝票」がつくられ、さらに「請求書」がつくられる、という業務であれば、自ずと各モデルの生成に順序があることがわかります。その生成過程において見つかるルールを「振る舞い」として抽出します。例えば「見積書」の「見積番号」を「売上伝票」に転記するというようなものが振る舞いの一種です。このように抽出された設計情報をWagbyに入力することで、システムの雛形がつくられます。従来、「振る舞い」はプログラムによって表現されるものでしたが、パターン化された振る舞いはWagbyによって自動生成されるようになっているため、開発が不要となっています。つまりWagbyの「ノンプログラミング性」は、パターン化された業務ルールの再利用によって支えられています。
コードをなるべく書かない、という思想を共有できるか
Wagbyを使った場合でも、ウォーターフォールで開発するという考え方は変わりません。ただ、工期は圧縮するように意識します。例えば従来方式で1年と見積もられたプロジェクトを、4ヶ月で達成させる、というような目標を立てます。このときのお薦めは、これを3回繰り返すというものです。4ヶ月の3サイクルだと結局1年ということになるのですが、2回のブラッシュアップの機会がある、というのがポイントです。1回目のサイクルを通して、はじめて気付いた改善点というのが必ずあります。Wagbyの利点は、仕様の再設計が行いやすいということです。プログラムの多くは自動生成されたものであるため、捨てることにためらいが生じません。そのために、プロジェクト内で「コードをなるべく書かない」という思想を共有する必要があります。
経験上、この発想が受け入れられるかどうかが、プロジェクトの成否を握ります。これは開発に関わる技術者だけでなく、発注側であるお客様（エンドユーザー）にもご納得いただく必要があります。それは面倒だ、言われたものをつくっていた方が変な交渉をしなくてすむ、という考え方もあるでしょう。しかしその発想では、高速開発を達成できません。
オーダーメイドから、レディメイドへ
あちこちで語られることですが、システム開発は一品物のオーダーメイド型から、再利用できる基盤を活用したレディメイド型へと移っています。Wagbyはまさに、そのための基盤という位置づけです。
ここまで読まれて興味をもった方は、是非とも wagby.com からトライアルキットをダウンロードしてお試しください。トライアルキットは無記名、無償でどなたでも入手いただけます。
https://wagby.com/download.jsp#trial
