崩壊アクセント

なれるSEを読んでSEになりました(大嘘)

超高速開発ツールの導入が絶対に失敗する3つの理由

f:id:megabyte123:20161105110644j:plain

最近、システム業界で脚光を浴び始めている「超高速で開発できるツール」 正体としては設計をベースにしたコードジェネレータ&自動コンパイラですが、現場の人間として、痛感したこととして「安直な導入は失敗する」という事。 導入しようとしている企業の方、是非この記事を読んでほしいです。 コスト削減だけを狙っても絶対に「コストは増加」する事になります。

※ツール自体は素晴らしい思想・設計で作られていると思います。 ただ、この記事では安直な導入は避け、きちんと理解して使う必要がある、 という事を言いたいだけです。

理由1:インタフェースは手作りする必要がある

企業内でシステムを構築するという事は、 大抵の場合、他のシステムとインタフェースにてデータをやり取りする事になります。 Webシステムの場合、Webサービスが用意されていればマシですが、 大抵の場合、欲しいと思ったWebサービスは用意されていません。 そのため、手作りでインタフェースする仕組みは構築する必要があります。

しかも、超高速開発ツールの場合、大抵DBまでセットでガチガチに作り込んであるので、 それを現物から読み解く必要があります。あーやだやだ。

現物から読み解いた後、設計とコーディングが待っていますよ。
超高速って何でしょうね。

理由2:ユーザの要望はツールの機能を超えてくる

間違いないです。 ツールで実現できる範囲の要望で抑えられれば、 高速開発ツールの恩恵を受けられると思いますが、 理由1のインタフェースの件含め、絶対に収まりません。 新規システムであれば最初は問題ないかもしれませんが、 改修時に連携先のシステムが増えた場合、どうしますか? 超高速開発ツールのサポートが打ち切られたらどうしますか? 現に古いバージョンのノーツとかを使っている会社、 移行で非常に困っていると思いますが。 ああいったCMS的なソフトも一種の超高速開発ツールだと思いますよ。

理由3:大抵の場合手作りの方が早い

・超高速開発ツールに合わせた要件定義と設計
・超高速開発ツールの使い方を教育するための工数
・ツール単体で対応できない箇所の設計
・対応できない箇所の手作り etc...

・・・無駄な工数なんて使わず、最初から手作りで作った方が何倍も早いですよ。 ましてや、超高速開発ツールなんて大抵高価ですよね。 フリーの物を使う?対応可能な範囲が狭くて、手作り量が増えますよ。 パッケージ購入にコスト掛けて、大したもの作れなくて、結局手作りに頼る・・・? それなら、初めから手作りで作りましょう。 エンジニアとしてはそちらの方が変な技術を身に着けずに済みますし、 管理も後の改修も楽でありがたいです。 パッケージのバージョンアップ後に改修する時、 差分で変なエラーとか出て、結局作り直しになるってのも大きなリスクですし。

結論:安直な導入で失敗し、長い目で見ると対応コストが増加する

各システム系の雑誌で注目され、脚光を浴びているためか、意外と上の人は興味を持っている 「超高速開発」ですが、実態としてはエンジニアサイドが使うツールではなく、 ユーザがエンジニアに頼らずに作れるシステムの範囲を広げるためのツールだと 個人的には考えています。 「コードを書かずにシステムを作れるから、工数を削減できる!」 というだけの理由で導入しようと考えている企業は、本当に考え直した方が良いと思います。 後々痛い目にあいます。ほぼ確実に。

ちなみに、私は実際に某大手企業のパッケージを何種類か使っているのでそう感じています。 対応不可能だと口を酸っぱくして言っても無理矢理導入させられ、対応コストで何故か責められる現場の意見でした。