昨日、
超高速開発のツールと、支援・自動化する工程の一覧表めっけ
http://blog.goo.ne.jp/xmldtp/e/94fb0fa5854e156ffe98c1732075920f
を書いたら、予想外に反響が大きかった。
その一方で、表題の件について、ググってもあんまりでていない。
これは、意外と超高速開発、ニーズがあっても知られていないこと、多いんじゃないかと思って、
意識あわせのために、超高速開発のキホンを書いてみる。
■GeneXusとMagicの根本的な違い
超高速開発には、2種類ある。GeneXusとMagicの根本的な違いはここに起因する。
・ソースを自動生成するもの
例:GeneXusや、富士通InterDevelop
上記エントリの第一桁が「設計コード生成型」と書かれているものである。
・実行環境が提供され、その実行環境上で動かすもの
例:Magic
上記エントリの第一桁が「設計・実行エンジン型」と書かれているものである。
ただし、思っている以上、この1つに差はない「かも」しれない。理由は
・たしかに、「設計コード生成型」はソースを生成するので、
そのソースを修正して、自由に書くこともできるが、
そうすると、次の生成時、修正部分が書きつぶされてしまい
保守性が悪くなるのであまりしない。
つまり、どちらも、自由に書き換えるということはしない。
・「設計・実行エンジン型」はツール開発会社が、エンジンをマルチプラットフォーム
に対応しないと、他プラットフォームでは動かないことになる。
それはそのとおりなのだが、じゃ、「設計コード生成型」は生成コードがすべての
プラットフォームに対応できるかといわれるとわからない。
ってことで、2つの型の差より、メーカーのサポートの差のほうが大きいかも?
ただ、価格体系は異なる。「設計・実行エンジン型」は開発環境、実行環境わけて
課金が可能である。Magicはそうみたい。(GeneXusはオープン価格)
■守備範囲の違い→生産性
上記エントリを見るとGeneXusのほうが守備範囲が広い
や~自動生成の範囲が広くていいね!
と思うかもしれないが、それだけ、広い範囲を覚えなきゃいけないということでもある。
というとで、注意していただきたいのだが、
超高速開発を行うと、生産性が劇的に上がるというのは、クラウドにすると、コストダウンが
実現すると考えるくらい、危ない考えだ。
生産性は、上がるかもしれないが、初期の場合、ツール学習コストがかかる。
また、要求仕様は結局、ツールを入れてもさして変わらないことがおおい。
そして、要求抽出がクリティカルパスになりやすい。
そのため、(保守性は上がっても)新規開発では、生産性は劇的には上がらないこともある。
ということで、学習コストを下げたい場合、わざと守備範囲の狭いツールを使うことがある
Magicは、こっちむきなのだろうか・・・
■ツール利用者の違い
ツールの利用者は、
・企業の業務担当者
・企業の情報システム部
・受託会社
のどれか?が重要。
後述する本によると、Magicは、ユーザー企業のほうまで含んでいる
(もちろん、受託会社も含んでいる)
ただ、GeneXusは、受託会社はもちろん対象だが、情報システム部が、そこまでの
コストをかけて、学習したほうがいいかどうかは、考慮すべきところ。
■そして・・・
超高速開発なら、やっぱりこの本でしょう!
超高速開発が企業システムに革命を起こす
http://www.amazon.co.jp/dp/482229627X
上記の「後述する本」は、これ。
Magicの事例(富士通テン)と、ツール説明、
GeneXusの事例(介護事業者)とツール説明のほか、
サピエンス、Xupperなど、著名なツールの紹介と事例が載っている。
まあ、133ページまではお題目として置いておいて、
とくに、199ページからのツール紹介は、価値があると思うよ!
超高速開発のツールと、支援・自動化する工程の一覧表めっけ
http://blog.goo.ne.jp/xmldtp/e/94fb0fa5854e156ffe98c1732075920f
を書いたら、予想外に反響が大きかった。
その一方で、表題の件について、ググってもあんまりでていない。
これは、意外と超高速開発、ニーズがあっても知られていないこと、多いんじゃないかと思って、
意識あわせのために、超高速開発のキホンを書いてみる。
■GeneXusとMagicの根本的な違い
超高速開発には、2種類ある。GeneXusとMagicの根本的な違いはここに起因する。
・ソースを自動生成するもの
例:GeneXusや、富士通InterDevelop
上記エントリの第一桁が「設計コード生成型」と書かれているものである。
・実行環境が提供され、その実行環境上で動かすもの
例:Magic
上記エントリの第一桁が「設計・実行エンジン型」と書かれているものである。
ただし、思っている以上、この1つに差はない「かも」しれない。理由は
・たしかに、「設計コード生成型」はソースを生成するので、
そのソースを修正して、自由に書くこともできるが、
そうすると、次の生成時、修正部分が書きつぶされてしまい
保守性が悪くなるのであまりしない。
つまり、どちらも、自由に書き換えるということはしない。
・「設計・実行エンジン型」はツール開発会社が、エンジンをマルチプラットフォーム
に対応しないと、他プラットフォームでは動かないことになる。
それはそのとおりなのだが、じゃ、「設計コード生成型」は生成コードがすべての
プラットフォームに対応できるかといわれるとわからない。
ってことで、2つの型の差より、メーカーのサポートの差のほうが大きいかも?
ただ、価格体系は異なる。「設計・実行エンジン型」は開発環境、実行環境わけて
課金が可能である。Magicはそうみたい。(GeneXusはオープン価格)
■守備範囲の違い→生産性
上記エントリを見るとGeneXusのほうが守備範囲が広い
や~自動生成の範囲が広くていいね!
と思うかもしれないが、それだけ、広い範囲を覚えなきゃいけないということでもある。
というとで、注意していただきたいのだが、
超高速開発を行うと、生産性が劇的に上がるというのは、クラウドにすると、コストダウンが
実現すると考えるくらい、危ない考えだ。
生産性は、上がるかもしれないが、初期の場合、ツール学習コストがかかる。
また、要求仕様は結局、ツールを入れてもさして変わらないことがおおい。
そして、要求抽出がクリティカルパスになりやすい。
そのため、(保守性は上がっても)新規開発では、生産性は劇的には上がらないこともある。
ということで、学習コストを下げたい場合、わざと守備範囲の狭いツールを使うことがある
Magicは、こっちむきなのだろうか・・・
■ツール利用者の違い
ツールの利用者は、
・企業の業務担当者
・企業の情報システム部
・受託会社
のどれか?が重要。
後述する本によると、Magicは、ユーザー企業のほうまで含んでいる
(もちろん、受託会社も含んでいる)
ただ、GeneXusは、受託会社はもちろん対象だが、情報システム部が、そこまでの
コストをかけて、学習したほうがいいかどうかは、考慮すべきところ。
■そして・・・
超高速開発なら、やっぱりこの本でしょう!
超高速開発が企業システムに革命を起こす
http://www.amazon.co.jp/dp/482229627X
上記の「後述する本」は、これ。
Magicの事例(富士通テン)と、ツール説明、
GeneXusの事例(介護事業者)とツール説明のほか、
サピエンス、Xupperなど、著名なツールの紹介と事例が載っている。
まあ、133ページまではお題目として置いておいて、
とくに、199ページからのツール紹介は、価値があると思うよ!