ストレートコンバージョン

そんなに高速開発ができるなら、「現行システムの設計を踏襲」すれば、さらに工数を

圧縮でき、それこそ「全く作らない」開発になるのではないか、と考える人が多いせいか、

いわゆる「ストレートコンバージョン」のようなプロジェクトがあったりしますが、G#的には

あまりお勧めしません。なぜか？

それはコンバージョン、つまり再構築が必要な段階になっているということは、現行システムは

これ以上ないくらいレガシー化が進行していて、ぐちゃぐちゃな状態だからで、それをGXに

したところでどうなるものでもないことが予想できるからというのが一つ。

次に、すでに設計ができているとはいえ、その設計はGXの使用など全く念頭に置かれていない

設計だということ。おそらく、フォームにコントロールを配置し、SQLを記述してデータを読み書き

するのに最適化されているはずです。項目名を唯一無二に揃え、トランザクション画面をその

設計に合わせてカスタマイズするようなことをしていたら、パフォーマンスが低下し、設計通りに

できないということばかりにスポットが当たるのは目に見えています。

こうなると、情報や技術者が少ないという要因も手伝って多少の開発スピードの速さメリットも

すぐに吐き出されてしまいます。

再構築プロジェクトであっても、GXにあうように要件定義・設計をやり直すことが、最初が多少

面倒であっても結果的には効率化されることになるはずです。

現行システムは、画面や帳票などの機能からユーザービューを導き出すヒント程度に活用するのが

適切なのではないでしょうか？

もちろん、計算式などに関しては現行設計を踏襲します。

GeneXus15における構造の業務追随

GeneXus15がついに日本デビューしました。

Evolution○○ではない久々の「メジャーバージョンアップ」ということで盛り上がっておりますが、

それにふさわしい機能がGX15の目玉として実装されています。

「ダイナミックトランザクション」です。

一言でいうと、GXのIDEからDBMSにCreate Viewができる、ということですが、その言葉から想像する

よりかなりすごく、「作らない開発」をまた一歩前進させる可能性があるのです。

つまり、今までの「作らない開発」においては、「異なる構造を一つのユーザービューから発生させる」

ことが苦手でした。

いや、そういうものであると認識していたので、苦手だと考えたこともありませんでした。

例えば、日々の営業実績登録という作業によってそのトランザクションデータと月次集計データを

発生させる場合、何度も書いてきましたが、今まではバッチ処理によって二つの構造に振り分ける

ことを推奨していました。

作らない開発ではない従来型開発手法で考えるなら、「集計画面」のほうはWebPanelとプロシージャ、

場合によってはSDTを使用し、一からプログラミングして実現していたかもしれません。

それが、「ダイナミックトランザクション」を活用すると、トランザクションオブジェクトからCreate Viewを

行ってビューテーブルを作ることができるので、バッチまでもなくすことが可能になるのです。

とはいえ、あまりに自由にCreate Viewをしすぎると、ビューテーブル専用の項目属性名の種類が

増えすぎて管理が難しくなったり、ビューテーブル自体が複雑すぎてパフォーマンスの低下を招いたり

といったことが予想できるため、使い方のガイドラインを決めておく必要があるでしょう。

ちょうど、自由に何でもできすぎるようになってしまった最近のWork With Plusと同様です。

作らない開発の必要性

WorkWithのみを使い、WebPanelを使わないことが作らない開発である、それは妙な

こだわりである、と誤解している人が多いので、なぜ「作らない開発」が必要なのかを

考えてみたいと思います。

教祖的存在Y氏がしばしばGX絡みでプレゼンしていた内容でもあり、1970年代からいたる

ところで言われ続けている、いわゆるデスマを生む問題として、「求められるものと実際に

出来上がったものが違う」というのがあります。

http://dic.nicovideo.jp/a/%E9%A1%A7%E5%AE%A2%E3%81%8C%E6%9C%AC%E5%BD%93%E3%81%AB%E5%BF%85%E8%A6%81%E3%81%A0%E3%81%A3%E3%81%9F%E3%82%82%E3%81%AE

ここで言われているように、原因は「初めから顧客が業務を説明できていなかった」

「要件定義者がそれを訊き間違えた」「要件定義者→設計者→実装者への伝言ゲームで

話がねじ曲がった」などいろいろ考えられますが、意外に大きいのが、「ユーザーは動く

システムを見て初めてやりたかったことに気づく」というものです。

一方で、ユーザーが新しい業務の導入や業務の変更をしようにも、システムの更新が

非常に大変であるために、思うように業務を行うことができない、いわゆる「システムが

業務の足かせ」になる現象もよく言われている問題です。

GeneXusを活用すれば高速開発が可能であるので、「プロトタイプがほぼ動くシステム」と

することができ、求められるシステムを作ることができる、とか、業務の変化に素早く

追随できるシステムとなる、というキャッチフレーズのようなものがあります。

G#的には、これはキャッチフレーズではなく本当なのであるとしていますが、実際には

開発者にもユーザーにも、そんなのは単なるキャッチフレーズであって、やってみると

従来の開発手法とそんなに変わるものではない、と思っている人もいるようです。

それこそ「結局『GeneXus言語』で作らなければならない」とか…

が、それはもう一つの問題を越えられていないために起こっているケースが多いのです。

もう一つの問題とは、時間の経過とともに要件と構造が離れて行ってしまう、というもので

あり、その間を埋めるためにロジックまたはプログラムと呼ばれるものを「作る」必要が

出てくるのです。

構造、つまりデータモデルは開発の初期段階で固まってしまって、変更するには膨大な

工数が必要であり、ロジックのほうが柔軟性があるから変更分はそちらで吸収する、

というのが従来の開発手法の基本的な考え方ですが、それがあるために、一旦

業務要件や仕様の変更が発生すると、開発者は「コピペ」やら「つぎはぎ」やらとにかく

工夫してロジックを作り、システムが稼働する段階では既にレガシー化している状態に

すぐになってしまうのです。

これらの変更は前述のとおり後々になってから発生するため、そのようなスパゲティソースを

何とか工夫して製造、それに対して膨大なテストケースを繰り返す段階では既にデスマに

近い状態となっていることは想像に難くありません。

そんなこんなでようやくサービスインしたシステムも、保守でさらに変更が入るわけですから

構造と要件のかい離は加速、保守開発者も開発時デスマほどではないにしろモチベーション

はダダ下がりになり、初期開発者に愚痴を言ったりするようになります。

この段階になると大量の回避コードの影響でレスポンスも悪化しユーザーの不満が高まる、

それとともにスパゲティソースのブラックボックス化で業務の変革ができない上記「ITの

足かせ」状態となっていることが容易に想像できます。

結果としてシステムは、ある段階までレガシー化が進むと、もう作り直した方が早い、

再構築だ、というコーナーが必ず待っているのです。

GXで高速開発ができるからといって、このかい離状態が従来のままでは、遅かれ早かれ

レガシー化は避けられないので、多少の違いはあれど今までの繰り返しになって

しまいます。

せっかくGXは「構造を要件に追随させる」ことができるのですから、それを有効に活用する

「作らない開発」を適用しないことは非常にもったいないことであり、「作らない開発」を

拡大することはIT業界の健全化につながるはずなのです。