【本当に高速？】超高速開発ツールについての疑問に答える【本当にコードを書かない？】

まだまだ普及には程遠い”超高速開発ツール”ですが、まだまだ誤解も多く、何度も似たような質問を受けることがあります。

という訳で、今日は、超高速開発ツールにまつわる7つの疑問に答えてみます。

“超高速開発ツール”の定義

その前に”超高速開発ツール”の定義が必要だと思いますが、この記事の中では、

『設計に関する情報を定義をすると、コーディングをしなくても、自動的にアプリケーションを生成してくれるツール。』

てコトにして、話を進めます。

ちなみに僕は“超高速開発”という名前が、誤解や普及を妨げている原因のひとつだと思っているのですが、それはまた別の機会にお話したいです。

疑問

Q. 本当に高速に開発できるの？

はい。できます。それも劇的に。ただし『そのツールがカバーしている範囲なら』という条件付きで。

例えばあなたのプロジェクトが、要件定義に異常に時間が掛かっていたり、他システムとの連携のテストに多くの工数を取られていたとしても、ツールがその工程をカバーしていないなら、その工程は高速になりません。

ツールによっては、得意とする領域・想定する工程が微妙に違うので注意が必要です。ツールを選定するときには、解決したい課題と、ツールの守備範囲を慎重に見極める必要があるでしょう。

見極めを誤ってしまうと、せっかく超高速開発ツールを導入しても『ツールがカバーしていないところ』で、同じ問題が繰り返されてしまう』ことになります。

Q. 本当に、コードを書かなくてもシステムが完成するの？

概ね事実です。ただし『ツールの守備範囲外』な複雑なUI、複雑な処理を実現しようと思ったら、多くの場合、コードを書く必要があります。

ここで「ツールの守備範囲とは？」という疑問が新たに生まれます。

これが案外厄介な代物で、「守備範囲」は、ツールによって異なります。つまり、「何が自動で、何がコードを書く必要があるのか」は、ツールによって異なるということです。

もしも本気で『コードを一切書かずに、高速開発ツールを使うことで、生産性を上げようとする』なら、次のことを守らないといけません。

• 『ツールの守備範囲は何か』を正しく把握する。
• プロジェクトの初期に、『これから作ろうとしているシステム』が、『ツールの守備範囲』だけで実現できるのか判断する。
• プロジェクトの初期に、『ツールの守備範囲』でできない機能は実装しないことを決める。

・・・普通は無理です。

どうせ、少しくらいコードを書いたとしても、すべてスクラッチで作るよりも遥かに高速・高生産性を実現できるのだから、『一切書かない』というような無駄に厳格なルールを作らずに、ある程度コードを書くことを許容するほうが現実的です。

Q. どうせロクに使い物にならないんでしょ？

使い方次第です。本当に使い物にならないなら、すぐに廃れています。

「とにかく導入してしまえば全ての問題を解決してくれる」ツールではありません。注意しなければいけない点はたくさんあります。ただし、それは、他のあらゆるツールも一緒です。

確かに『超高速開発』という名前の響きが詐欺臭いから『どうせロクに・・・』って疑ってしまう気持ちは、すごく良くわかりますが。。。

結局は、使う人次第です興味があったら、別の記事も見てください。

超高速開発ツールはエンジニアの未熟さを覆い隠すためのものではない

超高速開発ツールに関する誤解の１つに「未熟なエンジニアでも高い生産性でシステムを開発できる」というものがあります。・・・「あります」などと言い切ってしまったが、少なくとも私の

www.cycle-g.info

Q. でも、お高いんでしょう？

実は、これについて正確に答える自信はありません。当然、ツールによってピンキリです。

一部を除いて「価格はお問い合わせください」というベンダーが大半です。超高速開発ツールに限った話じゃないですが、なぜ価格を開示しないのでしょうか。

海外製品は価格を開示していることが多い印象ですが、日本の製品はほとんど開示されていないです。価格競争に巻き込まれたくないから？日本のユーザーは価格交渉しないから、言い値を設定し易くするため？

Webで知りうる情報を、以下の表にまとめてみました。おおよその価格感を掴めると思いますが、ライセンス体系・年間保守料・利用条件とか、それぞれ製品ごとに違うので、詳しくはご自分で調べてみてください。

これが高いと感じるか、安いと感じるか、捉え方はいろいろあると思います。開発ツールとして、OSSやVisualStudioなんかと比べると高く感じるでしょう。

大事なのは『得られる効果に対して適切な価格か？』なので、この金額が『あなたが得られるメリットに対して高い』なら、導入すべきじゃないと思います。

僕個人としては、月額課金にするとか、もう少し使いやすいライセンス体系にして欲しいなぁと思いますが。

Q. シロートでも簡単に作れるの？

無理です。頼むからやめてください。お願いだから。

例えば、『クラウドが、優秀なインフラエンジニアのレバレッジを効かすのに機能する』のと同じように、『超高速開発ツールが、優秀なアプリケーションエンジニアのレバレッジを効かすのに機能する』というようなイメージを持ってもらうと良いと思います。

素人でもEC2でサーバーを何十台でも、即時立てられるけど、やって欲しくないでしょ？そんな感じ。

Q. 結局、カスタマイズだらけになるんでしょう？

まず『カスタマイズしなくてもいいように、要求をコントロールする』のが大事です。

これは、要件定義決と称して『相手を騙せ』とか『誤魔化せ』とか『要求を押さえつけろ』って意味ではありません。

『要求のウラに隠れている本当の要求』を掘り出して、『その本当の要求を、高速開発ツールを使ってどうやって満たすか？』ってアプローチにすると良いです。

平均的な企業の、平均的な業務システムなら、このアプローチを取ることで無駄に仕様が複雑化したり、そのせいでカスタマイズが増える　ということを避けられると思います。

とはいえ、やはり、それでもカスタマイズが必要なケースはあります。そのときは割り切って、目一杯コード書いてしまえば良いのではないでしょうか？

Q. ツールベンダーがサポートを止めたらどうするの？

その議論／その疑問は、高速開発ツールに限った話じゃないと思いますが。

他のツールを選定するときと同じように、ベンダーを評価した上で製品の採用を決めれば良いでしょう。

さすがに『ベンダー独自に用意したクラウド環境でしか動かない』と詰んじゃうけど。最悪、ソースコードと実行環境にアクセスできれば、ロックイン問題はどうにかなります。

404 NOT FOUND | pick-it

www.cycle-g.info