集計の概念とWorkWith

少し前に、「GeneXusによる作らない開発の成功事例」として、某コミュニティにてプレゼン

されていたT社のシステム、こちらはプロジェクトIの発展形でありGXによる作らない開発

としては現時点で集大成に近い作り方がされていたと思います。

そのプレゼンの最後で、「100%画面はWorkWithなのですか？」という質問がありました。

私は100%だと思っていたのですが、プレゼン者の回答は違っていて、「運用開始後に

1画面だけWebPanelで作りました。選択した期間の分を集計表示する画面、これだけは

WorkWithでは対応できないため作りました」とのこと。

一瞬、確かにそれはWorkWithではできないな、せめてWorkWithPlusが必要だ、とも

思いましたが、一歩引いてみるとこれはWorkWith主体で開発しようとしたときにすぐに

と言っていいくらい突き当る壁で、実は解決可能なのです。

つまりは…「分析が足りていない」ということ。

というのは、「選択した期間」の集計って必ずしも必要か、という分析です。

「月ごと」とか「週ごと」とか、あるいは「四半期ごと」とか、決まっているのではないのか？

例えば、今回は5/7～5/10を集計したけど、前回は4/5～4/15を集計した、はたまた5/20

～6/10を集計するケースがあるかもしれない、とかいう業務はあまり考えられません。

もしくは担当者Aさんと担当者Bさんではそれぞれどのように集計するか違いがわからない

とか、そういうのも考えられない。

このように、もし「これは作らなければできないかな」という状況に突き当ったら、まず分析に

立ち戻るべきなのです。

そして分析をすればその結果、例えば「これはカレンダー月ではなく当月11日～次月10日

という『月度』での集計だ」という要件が見えてくるはずです。

そうなったらしめたもの、構造を変更し、月度がキーになるマスタとそのリレーション

(参照関係)を持たせれば、WorkWithの一覧もしくはタブで自然に集計を表示できます。

上記の流れは、まず構造があって、それにWorkWithが加わることによって作らずに要件が

実現できる、というのを集計に適用したイメージであるとも言えます。

分析に立ち戻るのは面倒で、我々はつい「作った方が早い」と考えがちですが、

保守運用まで含めた長い目で考えると、「作らない」かつその状態を維持することに価値が

あることが見えてくるはずです。

作らない開発と再編成

構造で解決を真髄とする作らない開発では、WorkWithと並んでGeneXusの機能で

大事なのが再編成という機能です。

よく競合扱いされるWagbyやWebPerformer、OutSystemsなどでは真似ができない最大の

違いがこの機能であり、むしろGXをそれらの競合である「超高速開発ツール」ではなく

GXという独自ジャンルとしているものだと思っています。

とはいえ、この機能は導入時にはそれほど細かく説明されませんし、開発者もそれほど

有効に、かつ頻繁に使っている例はあまり見かけませんでした。

実にもったいない。

再編成機能は、トランザクションを作成すると、それに従って正規化されたDBテーブルを

自動生成する機能ですが、それだけではなく、データ項目を移動させたり追加削除する、

つまり構造を変更すると、再正規化も自動で行い、DBテーブルの変更だけでなくデータの

自動移行までやってくれるという優れものなのです。

キーの総取り換えをしてしまった場合などはさすがに自動移行されませんが、外部キーで

なかったものを外部キーにしたりまたはその逆、マスタの追加削除などは自由自在に

できますし、単なる項目追加や項目の型変更レングス変更などは朝飯前です。

理論上は同じように設計すれば手動でもできるはずですが、実際にやろうとする人は…

まずいないでしょう。一人で開発しているならがんばればできるかな、とも思いますが、

実際はチームで開発するのが一般的であるため、他の人の変更分まで影響します。

自分が開発の途中であるのに、他の誰かが変更したところについて変更スクリプトをもらい、

データ構造を変更して、データのリカバリー方法を教わってそれに従ってオペレーション

して…と考えるだけでも地獄です。この壁はちょっと想像する以上に高いのです。

だから従来の開発では、構造を途中で変更するのを嫌がりますし、まずそもそも途中で

変更しようなどという発想がない。ウォーターフォールの手法ならばなおさらです。

構造を途中で変更＝戻る＝悪だと考える。

そうはいっても、実際には従来の開発においても戻ることが度々発生し、その都度どうしたら

戻らないようにできるかと考える繰り返しだったわけで、発想を変えて戻ることを受け入れる

アジャイル開発の概念が出てきた。アジャイルも実際には画面系にしか使われないことが

ほとんどですが、作らない開発の場合は構造にも戻ることを受け入れる発想が必要に

なってくるのです。

一方で、時々見られるのが、自動で変更であるとか自動でデータ移行というフレーズを

信用していなく、自分で手動で一つずつ確かめながらやりたいという人。

そのような人は「オープンソースでなければ信用できない」という人と同じで、GXにあまり

向いていないので、無理して使う必要はありません。そもそも、ソースコードを自動生成する

という時点で信用できないはずですし、もっと遡るとコンパイラも信用できなくなります。

実際のGXの細かなバグ含有率を見るとその意見もわからなくはないですが、少なくとも

私が関わったプロジェクトでジェネレートソースコードを手動で修正しなければならなかった

例はゼロですし、南米中心とはいえ世界中のシステムが毎日ビルドされているという

事実で、使えるツールであるということは認識できるはずです。

話がそれすぎましたが、この再編成機能によって、常にシステムは要件に構造を追随させる

ことができ、保守フェーズに入ってもレガシー化しない、パフォーマンスの良いきれいな

状態を維持することができるのです。

データ項目設計

作らない開発というよりGeneXusそのものの話。

ツール(IDE)の使い方やオブジェクトの作り方についてはよく説明されていますが、割とおざなり

にされるのが、GeneXusらしい設計の仕方の話です。

項目名はKB内で唯一無二であり、オブジェクト指向でいう所のオブジェクト名やテーブル名

などでは修飾されない、という話は有名です。しかし、よく考えるとその話は最初だけに

出てきて、実際使い始めたら「そうしなければ使えない」から仕方なく唯一無二にしている、

ような感が満載のKBをしばしば見かけます。

具体的には、どう考えても同じ意味の項目にテーブル名を含めた項目名を付け、テーブル

ごとに別物扱いにしているケースです。

理由を尋ねると、往々にしてDB設計が最初に手動でなされていて、それに合わせてGXで

開発しようとしらそうするしかなかった、というような話が出てきます。

開発者がGXに不慣れで、そうしてしまったとかならまだこれから改善する可能性は高いの

ですが、厄介なのは「体制がそうなっているから」とか「開発方法論がそうなっているから」

というケース。

どちらも同じようなものですが、体制というのはDB設計とプログラム開発が空間的に

分かれている場合で、開発方法論というのは両者が時間的に分かれている場合、といえば

イメージがつくでしょうか。実際はその併用が多いかもしれません。

項目名が唯一無二、という本当の意味は、唯一無二であることによってデータベースの

どこでその項目が管理されるかが決定され、また唯一無二であることによってその「どこ」

が移動してもかまわない、ということです。

したがって「構造」は項目名によって自由自在に変わるし、変えることができるのです。

とにかく技術者は戻ることを極端に嫌うので、空間的時間的に分かれている場面で

「項目名を、ひいては構造を変えてくれ」なんて言い出そうものならパニックになることは

想像に難くないですし、プログラム開発者、この場合はGX開発者もそれがわかっているので

何も言いださない。これは以前出てきたプロジェクトNの開発者Aのエピソードが典型例です。

また、こうした問題はかくいう私が開発者だったときも発生しているため、開発者の堅い

意志に依存して解決できるものでもないのです。

それこそ体制と開発方法論の問題なので、GXを導入すると検討・決定する段階から、

プロジェクトリーダーやオーナーが決めていかなければなりません。

一方で、テーブルごとにばらばらになった項目はどう扱われるのか？

今まで見たことのあるKBでは、本当にVBのような従来開発手法で作られており、

あらゆるプロシージャにwhere条件でテーブル同士を結合させ、場合によってはSDTに格納、

ウェブパネルで表示編集を行っていました。

まあ、それをやっていたら「SQLを直接書けない」であるとか「画面のパフォーマンスが遅い」

とか、GXへの不満が出てくるのもさもありなんですわな。

問題はもっと別のところにあるのです。