このコラムは、株式会社エル・ティー・エスのLTSコラムとして2016年2月に掲載されたものを移設したものです。
ライター
最近、カスタム開発、パッケージ開発※1に続く新たな開発方法として「超高速開発」という言葉を聞くようになりました。超高速開発とは、コード自動生成ツールやテスト自動化ツール、そしてBPMS/BRMS※2といった開発支援ツールを利用することで、設計やプログラミング、テストといった開発工程の一部を効率化し、これまでと同様のシステムを、より迅速かつ低コストで開発する手法の総称です。これらの開発支援ツールを総称して「超高速開発ツール」と呼んでいます。
※2：Business Process/Rule Management System
超高速開発とはどのような開発手法か
超高速開発ツールと一口に言っても、その特徴は様々です。一般的に言われるツールの種類としては以下のようなツールが挙げられます。
① コード生成型
設計情報からプログラミングや画面生成を自動化するツール
（主としては画面、プログラム、データベース生成の自動化ツール）
② 実行エンジン型
あらかじめ用意されたテンプレートを元にアプリケーションを生成するツール
（イメージは設定が柔軟なパッケージソフトウェア、「RPGツクール」）
③ BPMS/BRMS（Business Process/Rule Management System）
プロセスモデリング、業務ルール記述に画面やデータを付加しシステムを開発するツール
これらの他にもテスト実行支援ツール、ユーザーインターフェス（UI）作成ツール、EAI等が存在しますが、今回、LTSが調査したのはこの中では設計・コード生成型と言われるツール群です。日経コンピュータをはじめとする企業IT関連誌で取り上げられるツールもこの設計・コード生成型が中心です。
超高速開発を活用するメリット
ツールによって違いはありますが、一般に超高速開発には以下のようなメリットがあると言われます。
① ユーザー企業の要件を反映させやすい
クラウドサービス、パッケージソフトウェアのような機能制約がない。開発ツールによる制約がないわけではないが、その範囲内では自由なシステム開発が可能。
② 高い生産性
特に詳細設計の一部から、開発（プログラミング）、単体テストの工程を劇的に効率化可能（ただし、効率化の範囲はツールに依存）。
③ 高い拡張性、保守性
開発後の機能追加（拡張）や変更への対応が容易。
②の「高い生産性」について、JUAS（日本情報システム・ユーザー協会）の調査データがあります。この調査結果では他の開発手法との比較で工期に大きな差はありませんが、費用においては優位との調査結果になっています。
補足：JFSは画面数と帳票数に着目したJUAS独自のスケールで「JUAS Function Scale」の略
このような費用の優位性が出る理由としては以下のようなことが考えらます。
- 稼働が膨らみやすい詳細設計～開発～単体テストの作業を効率化できるため
- ツールの支援により設計時の論理不整合やコーディングミスを最小化できるため
- 業務設計者とエンジニアを分離する必要がなく、スリムな体制を維持できるため
今回、LTSでは幾つかのツールのデモを見たり、試用してみたりしましたが、どのツールもかなり魅力的に感じました。業務設計がしっかり出来ていれば、設計者（ビジネスアナリスト）が、画面とその遷移、処理の論理、情報（データ）の項目の定義といった設計情報を入力していくことで、かなり効率的な開発ができそうです。
超高速開発の他のソリューションとの比較
先ほどのJUASの調査での比較ではウォーターフォール（WF）開発とアジャイル開発と超高速開発を比較していますが、これは少し軸が違うものを比較しています。「超高速開発」を一つのソリューションとして見た場合、比較対象となる言葉はむしろパッケージ開発やカスタム開発となるでしょう。一般にカスタム開発は要件の実現性、つまり柔軟性に優れ、パッケージ開発は出来あいのソリューションを活用することで迅速性や効率性に優れるという特徴があります。超高速開発はその中間に位置すると考えるとしっくりきます。
柔軟性に関して言えば、超高速開発も一定のツールの制約は受けますので、カスタム開発と同等の柔軟性とまでは言えません。一方で、機能や仕様の変更に大きな制約があるパッケージ開発と比べると、超高速開発ツールでの開発における機能実現の柔軟性は圧倒的に優位です。
迅速性に関して言えば、超高速開発はカスタム開発の工程の一部を自動化したものですから、カスタム開発と比べると高い迅速性を誇ります。一方で、パッケージ開発と比べた場合、パッケージソフトウェアにカスタマイズやアドオンを行わないという前提であれば、迅速性はパッケージソフトウェアの方に分があります。コード生成型のツールであれば一定のシステム設計やテストは必要になってしまうためです。ただしパッケージソフトウェアにカスタマイズやアドオンが必要となった場合はその規模に応じてパッケージ開発の迅速性の優位は低くなっていきます。
ここまでをまとめると以下のような図になります。
実は高速じゃない「超高速開発」
ここまで超高速開発の特徴を紹介してきましたが、私はこの「超高速開発」というネーミングに疑問を持っています。今のところ超高速開発の適用事例でうたわれるメリットの大半は、ユーザーの要望を自由に実現できるという柔軟性に関するものが主流です。また、先ほど紹介したJUASの調査結果を鑑みると一定の規模の開発ではほとんど短縮効果はないことが見て取れます。つまり言うほど「超高速」ではないのです。これがなぜかと言えば、次のような説明になります。
「高速」になるのはもっぱら詳細設計からプログラミング、一部のテストです。ところがシステム開発で本当に時間がかかるのはこの工程ではなく、システムを企画し、要件定義を行う工程です。そしてこの工程は開発規模に応じて負荷が高くなるため、一定の規模になれば超高速開発はさほど「高速」ではなくなるのです。「超高速」という言葉は手間のかかるコーディングやテストといった「狭義の開発フェーズ」に煩わされていたエンジニア目線での言葉で、システム開発プロジェクト全体から見れば必ずしも「超高速開発」とは言えないことがあります。
超高速開発のメリットはQCD（品質、コスト、納期）で言えば、実は納期（D）が早くなることよりも、ユーザーの要望の実現度の高いシステム、つまり高い品質（Q）のシステムを低コスト（C）で開発できることです。もちろん超高速開発で納期も早くなりますが、これはどちらかといえば旧来のカスタム開発と比べての話です。かつて企業の業務支援システムの開発ではカスタム開発が主流でしたが、一から詳細設計を行い、コードを組み、テストをしなければならないため作業負荷が高く、2000年位を境にカスタム開発は減り、パッケージ開発が主流になりました。
しかしソリューションの機能制約が大きいパッケージ開発では現場ユーザーの要望を満たすことが出来ず、新しいシステムがむしろ旧システムより使い勝手が悪かったり、無理なカスタマイズで費用や工期がかさんだりという事態も頻発しました。
私は超高速開発の最大の功績は、柔軟性が高いカスタム開発の良さを低コストと許容可能な迅速性で実現し、システム開発の世界にもう一度カスタム開発という手法を復活させたことだと考えています。その最大のメリットを経営や業務の目線で語れば「超高速」であることではなく柔軟で使い勝手の良いシステムを構築できることにあります。これまでのカスタム開発を超えたという意味で、「超カスタム開発」という感じでしょうか。
今のところ大半の超高速開発ツールが対応できるシステムの規模には限界があり、大企業の基幹システムのような超大規模開発への対応は限定的※3です。そこをのぞけば、柔軟性に優れた超高速開発は、今後かなり有力な選択肢になります。日本では現場のユーザーの声が強く、パッケージソフトウェアの仕様に従った現場業務の変更はなかなか受け入れられない土壌があります。ですから日本においては要求実現の柔軟性を一定範囲で担保できる超高速開発はとても合理的な選択肢です。
・・・と、ここまで超高速開発のメリットを中心にお話してきましたが、実はLTSにおける今回のシステム導入では、超高速開発ツールの適用は見送りました。続く「システム開発の新たな可能性を開く超高速開発 後編：パッケージ開発か？超高速開発か？」では、超高速開発の注意点と、パッケージ開発と比較した際の向くシーン/向かないシーンについてLTSでの判断も交えながらお話してみたいと思います。
◆関連書籍のご紹介◆
BPO（ビジネスプロセスアウトソーシング）の効果が出なかったり、システム開発がトラブル続きだったりと、ビジネスプロセスマネジメントが上手くいっていないと多くの課題を引き起こします。
2015年7月に刊行した『ビジネスプロセスの教科書―アイデアを「実行力」に転換する方法』では、このような問題を解決するために、ビジネスプロセスとは何か、どのようにマネジメントすれば良いのか等をわかりやすく解説しています。また、著者がこれまでにお客様企業の現場で経験してきたビジネスプロセス変革の事例も多く紹介しています。ユーザー企業側で組織変更、情報システム導入、アウトソーシング活用といったビジネスプロセス変革を行う予定のある方はもちろんシステム開発やアウトソーシングベンダーの担当者の方も必見です。
