WorkWithのみを使い、WebPanelを使わないことが作らない開発である、それは妙な
こだわりである、と誤解している人が多いので、なぜ「作らない開発」が必要なのかを
考えてみたいと思います。
教祖的存在Y氏がしばしばGX絡みでプレゼンしていた内容でもあり、1970年代からいたる
ところで言われ続けている、いわゆるデスマを生む問題として、「求められるものと実際に
出来上がったものが違う」というのがあります。
ここで言われているように、原因は「初めから顧客が業務を説明できていなかった」
「要件定義者がそれを訊き間違えた」「要件定義者→設計者→実装者への伝言ゲームで
話がねじ曲がった」などいろいろ考えられますが、意外に大きいのが、「ユーザーは動く
システムを見て初めてやりたかったことに気づく」というものです。
一方で、ユーザーが新しい業務の導入や業務の変更をしようにも、システムの更新が
非常に大変であるために、思うように業務を行うことができない、いわゆる「システムが
業務の足かせ」になる現象もよく言われている問題です。
GeneXusを活用すれば高速開発が可能であるので、「プロトタイプがほぼ動くシステム」と
することができ、求められるシステムを作ることができる、とか、業務の変化に素早く
追随できるシステムとなる、というキャッチフレーズのようなものがあります。
G#的には、これはキャッチフレーズではなく本当なのであるとしていますが、実際には
開発者にもユーザーにも、そんなのは単なるキャッチフレーズであって、やってみると
従来の開発手法とそんなに変わるものではない、と思っている人もいるようです。
それこそ「結局『GeneXus言語』で作らなければならない」とか…
が、それはもう一つの問題を越えられていないために起こっているケースが多いのです。
もう一つの問題とは、時間の経過とともに要件と構造が離れて行ってしまう、というもので
あり、その間を埋めるためにロジックまたはプログラムと呼ばれるものを「作る」必要が
出てくるのです。
構造、つまりデータモデルは開発の初期段階で固まってしまって、変更するには膨大な
工数が必要であり、ロジックのほうが柔軟性があるから変更分はそちらで吸収する、
というのが従来の開発手法の基本的な考え方ですが、それがあるために、一旦
業務要件や仕様の変更が発生すると、開発者は「コピペ」やら「つぎはぎ」やらとにかく
工夫してロジックを作り、システムが稼働する段階では既にレガシー化している状態に
すぐになってしまうのです。
これらの変更は前述のとおり後々になってから発生するため、そのようなスパゲティソースを
何とか工夫して製造、それに対して膨大なテストケースを繰り返す段階では既にデスマに
近い状態となっていることは想像に難くありません。
そんなこんなでようやくサービスインしたシステムも、保守でさらに変更が入るわけですから
構造と要件のかい離は加速、保守開発者も開発時デスマほどではないにしろモチベーション
はダダ下がりになり、初期開発者に愚痴を言ったりするようになります。
この段階になると大量の回避コードの影響でレスポンスも悪化しユーザーの不満が高まる、
それとともにスパゲティソースのブラックボックス化で業務の変革ができない上記「ITの
足かせ」状態となっていることが容易に想像できます。
結果としてシステムは、ある段階までレガシー化が進むと、もう作り直した方が早い、
再構築だ、というコーナーが必ず待っているのです。
GXで高速開発ができるからといって、このかい離状態が従来のままでは、遅かれ早かれ
レガシー化は避けられないので、多少の違いはあれど今までの繰り返しになって
しまいます。
せっかくGXは「構造を要件に追随させる」ことができるのですから、それを有効に活用する
「作らない開発」を適用しないことは非常にもったいないことであり、「作らない開発」を
拡大することはIT業界の健全化につながるはずなのです。