作らない開発と論理削除

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

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

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

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

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

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

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

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

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

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

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

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

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

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

温床となります。

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

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

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

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

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

任意選択とWorkWith

「なぜ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に

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

なぜSQLを書きたいのか まとめ

こうして見てくると、3人は「本当にやりたいこと」はバラバラなのに、なぜか一つの要望、

というか文句「SQLを直接書きたい」というフレーズに集約されてしまっているのです。

ここにGeneXusの闇があると思うのです。

GeneXusのコンセプトから考えるに、「何をやりたいか」が重要であって「どうやればいいか」

はさほど重要ではなく、むしろGeneXusがカバーするものであるからです。

導入時プレゼンで説明される、「WHATを入力すると、HOWを生成してくれる」というアレです。

にもかかわらず、仕様なり要件が提示されたときに、「どうやればその通りに作れるか」と

考える開発者が相変わらず多いように感じます。

これは、仕様や要件を画面設計と勘違いして提示しているようなケースが多いためですが、

しかるにGXでは画面設計を先にしてはいけないのですが、それは置いておくとしても、

実際にGXに触れる開発者は、「GXを生かして素直に設計するとこうなるよ」というように

対案または代案を示すことが求められるのです。

そのためには、「何をしたいのか」特に「その『場面』においてユーザーはシステムと対峙する

ことによって何をしたいのか」をより正確に把握する必要があるのです。

いろいろな解釈があって困るのですが、この「場面」こそがG#的には「ユーザービュー」である

と考えています。

また、この「どうやれば作れるか」へ進むのではなく「何をしたいのか」に戻して考える

プロセスが、某B社の言う「上流と下流の大接近」、もしくは某T氏の言う「上流SEへの移行」

へのステップとなるはずです。

話をSQLに戻すと、該当するGXの機能を知らないために手っ取り早くSQLで書きたい、という

内容も散見されるので、GX最大の弱点「情報が少ない」にも起因していると思われます。

これは私も含めてさらに情報発信をがんばらなければならないと考えています。