そもそもGeneXus開発者であってもGXで何ができるかわかっていない…
このことに気づくまでかなり長い時間がかかってしまいましたが、今思い返すと初めて
数社のGX開発者と共同で開発を行ったプロジェクトNがその哲学？の原点でした。
その前に「作らない開発」方式を適用して完了していた小規模案件プロジェクトMとその
総括により、大規模案件のプロジェクトNにおいても作らない開発方式で対応可能と
主要メンバーは踏んでいました。いやスーパーカツカツスケジュールのプロジェクトNでは
それ以外の方式ではスケジュールもコストも到底達成不可能という消去法的な決定で
あったかもしれませんが…
ともあれ、プロジェクトNにおいても「作らない開発」を標準とした開発方針となりました。
すなわち、
1.提示された画面の許容
2.課題は三日で決める
3追加機能は認めない
というかの有名なGXプロジェクト憲章がここに定められたのです。
これは、プロジェクト管理方式としての作らない開発です。
一方で、実際の開発作業としての作らない開発は、まだ黎明期だったということもあって、
A.WebPanelを(極力)作らない
B.WebFormを(極力)弄らない
C.構造で吸収する
程度しかルールがなく、そもそもなぜこのルールが必要なのかを、ユーザーではなく、
開発者に伝えるのに非常に苦労したことを鮮明に覚えています。
特にCは全く伝わっていなかったことがプロジェクト終盤のころに次々発覚するわけですが、
それは後ほどの話です。
AとBは何が問題なのか？
AとBを崩したい理由として印象深かった例は、
1.WorkWithのコード検索欄(ヘッダ）の横にそのコードの名称を表示したい
2.レベル明細を二つ画面に置き、その二つの間でレコードを移動させたい
3.レベル明細が200行程度あるので絞り込み検索をしたい
といったようなもの。
確かにAとBを厳守するとできないのであるが、1は一覧に名称を表示するか、前の画面も
WWにしてタブで表示すれば名称も表示できます。
2は移動先のIDをプロンプトで選択させればグリッドを並べなくてもできますし、3はそもそも
絞り込む項目が実はキー項目なのではないか？といろいろ分析するわけです。
これらは、先に画面を設計してしまってその通りに作らなければならない、という強迫観念に
とらわれていることによるものである、とだんだん気づいてきました。
GXではせっかく「実用に耐えうるプロトタイプ画面」が自動生成されるのですから、上に
あげたような分析・再分析にそれを使用し、本当の要件を明らかにしていくのがうまい
使い方だと思っています。しかるに、画面設計をしないのです。