エーフラット・ジャパンの作らない開発G#

自動生成開発ツールGeneXusを使った「作らない開発」に関するブログ


テーマ:

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業界の健全化につながるはずなのです。

AD
いいね!した人  |  コメント(0)  |  リブログ(0)

テーマ:

WorkWithとトランザクションベースで開発を行っていると、いわゆる「論理削除」が

実現しにくい、ということに気づきます。

 

なにしろ、WorkWithを適用しないデフォルト状態のトランザクション画面では、

確認メッセージも出ずにバッサリと物理削除されてしまうのですから、論理削除など

考えられてもいないことは容易に想像がつきます。

実際、論理削除を有効に、などというプロパティは存在しないし、無理にやろうとすると、

削除処理の寸前にハンドリングしてデータをコピーしておく、というような文字通り

無理やりな対応になってしまいます。

無理やりな対応は小さなスパゲティ化です。

 

とはいえ、「誤って削除してしまった場合に復元できるように」という要件は一定数存在する

わけで、それをどう実現するか?

 

この場合、どうせコピーするなら、同様の項目を持った別テーブルにコピーをした方がよい。

同じテーブルの別レコードとして削除フラグを立ててコピーすると、論理削除の最大の弱点

ですが「削除フラグが立っていない」という条件を常に看なければならなくなり、バグの

温床となります。

 

従来の開発手法では、別テーブルに移す場合にはおそらくそのテーブルを作成する分で

ファンクションポイントが跳ね上がってしまうために採用されづらかったのかと思われますが、

GXにおいてはテーブル作成の簡単さに比較すると削除フラグ条件をあらゆる箇所で

確認することの方がリスクとなるため、このように「逃がす」という手法が採られるのです。

 

こうなると論理削除というよりは、むしろ「削除ログ」の概念に近いかもしれません。

AD
いいね!した人  |  コメント(0)  |  リブログ(0)

テーマ:

「なぜSQLを書きたいのか」を考えていた時に、直接的表現でSQLを書きたいと言われた

わけではないけれども、おそらくこういう時に「もしもSQLが書けたなら…」と思うだろうな、

と想像されたのが「任意選択をしたレコード帳票に出力したいとき」です。

 

任意選択というのは、WorkWithなどで一覧表示したレコードの中から複数を選択して、

それに対して何かする、一般的にイメージしやすいのはSNSにアップしたりメッセージに

貼り付ける写真を選択するようなケースですが、業務システムの場合は帳票出力対象を

選択させるケースでよく見られます。

 

このインターフェースはWorkWithでは簡単に実現できます。MultiRowSelectionプロパティを

設定するだけです。そうすると、ボタン操作などのアクションをしたときに選択されたデータの

入ったSDTコレクションが自動でパラメータに渡って来るので、それをプロシージャなどで

受けて帳票なりバッチなりを実行させればよいのですが、ここになかなか気づきにくい

問題点があるのです。

 

まず、渡されるのが「WorkWithに定義されている項目が含まれるSDT」であるので、

当然ながらWorkWithに含まれない項目はロジックを記述して取りに行かなければならない。

さらに問題となるのはそれが複合キーである場合です。

 

複合キーが複数件選択されているので、それを元にさらに別項目をテーブルから取得しよう

とすると、OracleならばIN句に複合キーを記述できますが、GXは様々なDBMSに対応する

必要があるため、その記述はサポートされていません。となると、選択されたSDTを

ループさせて一件ずつテーブルアクセスを行うロジックを作らなければならなくなります。

選択するのは人間なので、さほどパフォーマンスに影響するほど大量レコードにはならない

はずですが、特にそのロジックと並行していろいろなことをやっているとそれなりに遅くは

なってしまいます。これは、そもそも構造を変更して必要な項目はWorkWithに非表示ででも

含めてしまえば回避できます。

 

次に、やはり渡されるのがSDTであるため、「HTTPのパラメータにはテキストしか渡せない」

という至ってシステム的な制限にどうしても引っかかるということです。

これはセッション変数に退避したり、JSONでテキスト化したりと簡単に回避できる制限なの

ですが、GXが対象とする、「非専門の開発者」にとっては意味不明な制限と回避方法であり、

なんで自動でやってくれないのだろう、と思うところです。

 

さらに、一番目に見えて真っ先に指摘される問題点として、「選択はページごとにしなければ

ならない」というのがあります。1ページ目で何かを選択したとしても、ページ切り替えをして

2ページ目に移ると、1ページ目で選択したものは覚えていてくれない、というアレです。

これに関しては「簡単な回避方法」はなく、極めてゴリッゴリに作らなければ解決できません。

 

これらの問題点には改善の要望は出されているのですが、実現には時間がかかるだろう

ということで、一旦立ち止まって「なぜ複数選択をしたいのだろう?」というところに戻って

考えてみます。

 

そもそも業務システムで、担当者が「任意に複数選択する」というケースは、以前挙げた

「任意の日付間の集計値を出す」のと同様、ほとんどないのではないでしょうか?

大概は閾値のような条件があり、それに合致したものを選択するか、グループのような括り

があり、それに含まれるものを選択するか、その組み合わせになるはずです。

それでも任意選択インターフェースを導入したいのは、単に「旧システムのインターフェース

がそうだから」とか「工数が膨らむからいろいろな条件に対応できる画面にしたいから」という

消極的理由ではないのかと邪推してしまいます。

 

画面数が直接工数に影響しない、加えて画面インターフェースから考えるととたんに工数が

膨らむ、という特性を持つGXでは、上のような場合もまず「何をしたいのか」に戻って考える

方が、全体的な工数、特に保守を含めた工数は低減されるのです。

なので「設計変更を恐れてはならない」のです。

 

また、どうしても任意選択をさせたいケースとして、それこそ写真を選択するケースのように

担当者の「目検」や「主観」が重要になることも全くなくはないため、その場合は最近の

傾向を取り入れ、「お気に入り」や「買い物かご」のようなインターフェースとして、DBに

一旦保存するというのも一考かもしれません。

AD
いいね!した人  |  コメント(0)  |  リブログ(0)

AD

Ameba人気のブログ

Amebaトピックス

      ランキング

      • 総合
      • 新登場
      • 急上昇
      • トレンド

      ブログをはじめる

      たくさんの芸能人・有名人が
      書いているAmebaブログを
      無料で簡単にはじめることができます。

      公式トップブロガーへ応募

      多くの方にご紹介したいブログを
      執筆する方を「公式トップブロガー」
      として認定しております。

      芸能人・有名人ブログを開設

      Amebaブログでは、芸能人・有名人ブログを
      ご希望される著名人の方/事務所様を
      随時募集しております。