作らない開発とWorkWith

今まで散々「作らない開発」「作らない開発」と連発していましたが、GeneXus的な作らない

開発を一言で言えば、以前の記事のタイトルにある「構造で解決」で終わってしまいます。

では、なぜ構造で解決すると作らなくできるのか？

それは、GeneXusにはWorkWithという万能画面が標準装備されているからです。

裏返すと、GeneXusによる作らない開発＝WorkWithを使ってWebPanelを使わないこと、

と短絡的に考える人も非常に多いわけですが、それは少し違って、まず構造で解決して

そこにWorkWithを適用することで、「作らないことを続けること」ができるのです。

WebPanelは構造を変えるとそれに従って手動で修正を当てなければいけませんが、

WorkWithは、一覧も関連ドリルダウン画面も全て新しい構造に自動で生まれ変わります。

トランザクションは当然構造に追随するので、WorkWithに紐づいている入力画面も自動で

変更される。開発者は(もしあれば)プロシージャの整合性を保つだけでよいのです。

もし、構造を優先しないで、WebPanelを作らない、WorkWithだけで作る、だけの方針でやって

いたら、構造に合わない画面が必要になっただけで簡単に破綻します。

じゃあそういう画面はWebPanel+SDTで作るか、と始まると、次から次へと作る画面が

増えていき、誰も構造を顧みなくなります。なぜなら、どう使われているかわからないから。

つまり、スパゲティ化です。

この微妙にずれた作らない開発をやっているところは意外に多いので、かなりの気合を

持ってコントロールしなければなりません。

構造と画面が直接結びついていると、それらを見ただけで仕様がわかります。

メンテナンスされていない仕様書に悩む必要もなくなるわけです。

業務が変わっても、それに構造を追随させ、画面が自動で再生成されれば、新しい業務に

どんどん対応できます。スパゲティ化しないのでシステムは常にきれいな状態で保たれ、

業務知識が常にKBに取り込まれた状態となる、再構築を必要としないレガシーレスの

システムが出来上がります。

これがまさに、GeneXusでいうところの「未来を守る」ことの真髄です。

ちなみに、WorkWithで自動生成されたオブジェクトやトランザクションのWebFormを改変して

「赤い状態」にすると、結局作る画面が増えていく上に、「どこがどう改変されているか、

もしくはされていないのかすらわからない」恐怖のKBとなっていきます。

だから、「絶対に赤くしてはいけない」のです。

どこかで、WorkWithという名前がついていながら全くトランザクションと関係のない「赤い」

画面がたくさんあるKBを見ましたが、あれはこれからどうメンテナンスしていこうというの

だろうか。。。

影の実力プロジェクト

実は失敗の表彰案件と隠れた実力者案件、なぜこうも違いが出たのか？

期間がほぼほぼ並行していたとはいえ、プロジェクトIのほうが若干スタートが遅く、その若干の

間にプロジェクトNのうまくいっている点、有耶無耶になってしまったが当初計画通りであれば

よかったであろう点のみを抽出した効果が一番大きかったようです。

ストーリーポイント管理の継続、プロジェクト憲章の順守、特に画面を受け入れること＝

WorkWithベースの画面のみでまずは全範囲をカバーすること。

そのためには多少大きな手戻りも辞さないこと…

実際こちらも1サブシステムと言えるくらいの機能を一回作り直していますが、それによって

遅延が発生することはありませんでした。

その機能とは、精算が確定した後に変更分を差額精算する要件が、最初はなかったのですが

後からやはり必要と決まって追加しようとしたところ、できかけていた当初の構造では対応

できないことがわかって、構造を一から作り直したのです。

この「構造を要件に追随させるためには大きな手戻りも辞さない」という概念は、

サービスイン後も継続され、大きなところでは2機能9トランザクションに分かれていたものを

1機能6トランザクションに統合したりもしましたし、小さなマスタの新規作成や廃止はそれこそ

日常茶飯事のように起こりました。

こういう経緯を話すと決まって「そんな変更は最初に想定しておかないから起こるのであり、

それができないのは技術不足。ツールに頼るのではなくそういった技術を持つSEを育てる

のが先決」とか言い出す人が出てきますが、そんなスーパーSEはほとんどいないし、

むしろ私のような並のSEでも成功事例を作れるようになる、というところがポイントなので、

全くお門違いです。

ユーザーですら把握していないような業務の中身と、それがこれから先どう変わっていくか、

まで想定することなどできないからこそ、SIプロジェクトの成功率は30%などという説が出る

くらいうまくいっていなかったのではないか。

というようなことをこのプロジェクトを通して確信したわけですが、一方で今までと同じ罠に

はまったプロジェクトが並行していたわけで、表立って言うのははばかられる空気になって

いたのが非常にもったいなかったのです。

成功事例が成功していないIT業界の不思議

プロジェクトNの途中で私はプロジェクトIの開発にどっぷり入ることになり、プロジェクトNの

話は思い出したように単発の質問を受ける、くらいの関わりしか持たなくなったのですが、

１サブシステムは完全に作り直し、リスケにリスケを重ねた結果大幅なコストオーバーランに

なりながらも現場の踏ん張りによって何とかサービスインにこぎつけたとのことでした。

ビジネス的には完全に失敗、元々アンチが多かったGeneXusのツールとしての評価も低下、

表面上は関係ないとされながらもやめる人が続出、という惨憺たる有様となったわけ

ですけど、カンファレンスでは何と「GeneXusを使った今までにない大型案件をサービスイン」

ということが成功と評価され、表彰されることになったのです。

これには社内外のあちこちで、散々苦労してきたことも少し報われたなー、みたいな最近

流行りのスポ根正当化路線で盛り上がっていましたが、だがちょっと待ってほしい。

こういうのはIT業界あるあるなわけですが、なぜ実質的失敗案件が成功事例として

表彰されるのか？

あるあるなことは当時もわかっており、以前別の会社にいた時も同じようなケースが

あったし、GeneXusに力を入れ始めたころには某スクリプト開発言語初の大型案件という

ことでビジネス的には大失敗しながらも表彰されたプロジェクトを横目で見ていたので、

絶対そういう風にはするまいと反面教師としていたのにこれかよ、という感じでした。

おかげで、プロジェクトNの横で相前後してサービスインしたプロジェクトIは、ノートラブルな

上に99.5%をWorkWithのみで開発、オブジェクト数で数えたら規模もNの2/3はあって十分

大型案件だったわけですが、人数も少なく見かけの規模は相当小さく、誰も何も言って

もらえないわけです。

まあ誰も何も言ってもらえないことにはそんなに気にしていなかったのですが、一旦

そういう表彰を受けるとスピーカーはあちこちにプレゼンに呼ばれるので成功事例として

有名になり、失敗した方法が成功法として伝播していくのは勘弁してほしかった。

何せ今でもそれが続いているのですから…