まだまだ普及には程遠い”超高速開発ツール”だけど、まだまだ誤解も多くて、何度も同じような質問を受けることがあるよ。
・・・という訳で今日は、超高速開発ツールにまつわる7つの疑問に答えていくよ。
“超高速開発ツール”の定義
“超高速開発ツール”の定義が必要だと思うんだけど、この記事の中では、
『何かいろいろ定義をすると、コーディングをしなくても、自動で(主にWebの)アプリケーションを生成してくれるツール。』
てコトにして、話を進めるよ。
ちなみに僕は、“超高速開発”って名前が、誤解や普及を妨げている原因のひとつだと思ってるんだけど、それはまた別の機会にお話するよ。
疑問
1. 本当に高速に開発できるの？
できるよ。それも劇的に。『そのツールがカバーしている範囲』ならね。
たとえば、あなたのプロジェクトが、要件定義に異常に時間が掛かっていたり、他システムとの連携のテストに多くの時間を取られていたとしても、ツールがその工程をカバーしていないなら、高速にならないよ。
せっかく超高速開発ツールを導入したのに、『ツールがカバーしていないところ』で、同じ問題が繰り返されるだけだよ。
2. コードを書かなくてもシステムが出来上がるって、本当？
本当だよ。さすがに、Excelの関数みたいなモノは書くけどね。
ただし『ツールの守備範囲外』な複雑なUI、複雑な処理を実現しようと思ったら、多くの場合、コードを書く必要があるよ。
ただ、この『ツールの守備範囲』ってのが、結構厄介な代物だよ。
もしも、本気で『コードを一切書かずに、高速開発ツールを使うことで、生産性を上げ』ようと思うなら、次のことを守らないといけない。
- 『ツールの守備範囲は何か』を正しく把握する。
- プロジェクトの初期に、『これから作ろうとしているシステム』が、『ツールの守備範囲』だけで実現できるのか判断する。
- プロジェクトの初期に、『ツールの守備範囲』でできない機能は実装しないことを決める。
・・・普通は無理だよね。
どうせ、少しくらいコードを書いたって、スクラッチで作るより遥かに高速なんだから、『一切書かない』とか言わずに、ある程度コードを書くことを許容したほうが良いよ。
3. どうせ使い物にならないんでしょ？
使い物になるよ。ていうか、なってるよ。実際。
気をつけないといけない点は、いろいろあるけどね。それは、他のツールでも一緒だしね。
たしかに、『超高速開発』なんて詐欺くさい名前のツール、『どうせ・・・』って疑っちゃう気持ちは、すごく良くわかるけど。
結局は、使う人次第だよ。興味があったら、別の記事も見てね。
4. でも、お高いんでしょう？
実は、これについて正確に答える自信はないよ。当然、ツールによって違うしね。
『価格はお問い合わせください』なんて、セコい商売やってるベンダーも多いからね。コレも超高速開発ツールに限った話じゃないけど。
Webで知りうる情報を、以下の表にまとめてみたよ。おおよその価格感を掴めると思うけど、ライセンス体系・年間保守料・利用条件とか、それぞれ製品ごとに違うから、詳しくは自分で調べてみてね。
| 製品 | 価格 | URL | |
|---|---|---|---|
| Wagby | 開発者1人 | 1,500,000 | https://wagby.com/purchase.html |
| outsystems | 不明。無制限?年額 | 3,600,000 | http://it.impressbm.co.jp/articles/-/12609 |
| genexus | **** | 不明 | |
| web performer | 5ユーザー | 3,500,000 | https://www.canon-its.co.jp/news/detail/20160627wp.html |
これが高いと感じるか、安いと感じるか、捉え方はいろいろあると思う。開発ツールとして、OSSやVisualStudioなんかと比べると高く感じるよね。
大事なのは『得られる効果に対して適切な価格か？』なので、この金額が『あなたが得られるメリットに対して高い』なら、導入すべきじゃないと思うよ。
僕個人としては、月額課金にするとか、もう少し使いやすいライセンス体系にして欲しいなぁと思うけどね。
5. シロートでも簡単に作れるの？
無理。やめて。お願い。頼むから。
例えば、『クラウドが、優秀なインフラエンジニアのレバレッジを効かすのに機能する』のと同じように、『超高速開発ツールが、優秀なアプリケーションエンジニアのレバレッジを効かすのに機能する』ってなイメージを持ってもらうと良いかもね。
AWS使えば、素人でもサーバー何百台だって立てられるけど、やって欲しくないでしょ？そんな感じ。
6. 結局、カスタマイズだらけになるんでしょう？
まず、『カスタマイズしなくてもいいように、要求をコントロールする』のが大事だと思うよ。
これは、決して『騙せ』とか『誤魔化せ』とか『押さえつけろ』って意味じゃなくね。
『要求のウラに隠れた本当の要求』を掘り出して、『その本当の要求を、高速開発ツールを使ってどうやって満たすか？』ってアプローチにすると良いよ。
なんか、抽象的なハナシになっちゃって申し訳ないけど、そんな感じ。伝わるかな？
ま、それでもカスタマイズが必要なケースはあると思うけどね。そのときは、目一杯コード書いちゃえばいいんじゃない？
7. ツールベンダーがサポートを止めたらどうするの？
その議論、高速開発ツールに限った話じゃないとは思うけど。いつも通り、ベンダーを評価した上で決めればいいんじゃない？
さすがに『ベンダー独自に用意したクラウド環境でしか動かない』と詰んじゃうけど。最悪、ソースコードと実行環境にアクセスできれば、後はどうにかなるよね。
コメント