以前「開発支援ツールとは？ その種類と特徴を、まめてみした。」と言うタイトルで投稿させて頂きましたが、今回の「統合CASEツールの類は何故、廃れたのか？」は、ココでの問い合わせを受けて書こうと思い立ち、得意分野なので、手癖で書き上げたモノです（実際、２時間かけずに書き上げました）。

　統合CASEツールというのは、以下のスライド中で紹介している開発支援ツール（IDE、RAD、EUC、CASE、Template ＆ Package）の内の１つに分類していますが、

• IDE : Integrated Development Environment
• RAD : Rapid Application Development
• EUC : End-User Computing
• CASE : Computer Aided Software Engineering

　コレら最近は（、この辺にも書きましたが）、IDEを除いて、大概、廃れてきています。


　故に、コレらを知っている人や実際に触ったことがある人は、結構年配の方ばかりなんじゃないか？とすら思ったりします。以降、何故、コレらの統合CASEツールが廃れていったのか？を説明して行きたいと思います。

＜アウトライン＞

---

＜柔軟性が低い問題＞

　統合CASEツール系は、リポジトリ、若しくは、Excel設計書から、クラス・メソッドのテンプレートを自動生成する。と言う仕組みを採用しています。

　このため、アーキテクチャ変更が発生した場合、

　と言う必要が出て来ます。これには莫大な工数が掛るので、自動生成インフラストラクチャは、基本的に「柔軟性が低く、新しいアーキテクチャへの追随が難しい。」という弱点があります。

＜生産性がそれ程、上がらない問題＞

　ココでも書きましたが、仮に、プログラミング工程の工数が０になったとしても、設計と対応するテストの工数が多い、ソフトウェア設計・開発の工数全体からすると、全体の２割程度しか、工数は削減されないことになります。

　また、ノン・プログラミングであっても、定義作成は必要になるので、プログラミング自体はありませんが、それ相当の定義作成を行っていることになります。このため、プログラミング言語やIDEの難しい知識が不要になっているだけで、工数自体は「０」ではなく、ある程度、工数が掛ると言う事になります。

　また、統合CASEツール系は、D層（データ・アクセス部分）など、100％自動生成のノン・プログラミングの部分もありますが、実装の大部分は、クラス、メソッドのテンプレート生成までで、また、ラウンド・トリップ開発対応も十分でなかったりします。

＜品質もそれ程、上がらない問題＞

　また、昨今、プログラミング部分の複雑性が高まり、昔の設計書フォーマットで書くのが実質的に難しくなってきています。

　こんな中で、設計書のフォワード（基本 → 機能 → 詳細）を行うと価値の作り込みが出来ず、作業形骸化が発生します（そして、モジュール・レベルは、実装時に覆されることになるでしょう）。加えて、IDEの高度化により、「中流工程以降の設計とプログラマの力関係が逆転した。」と言う事も理由の一つに挙げられるかと思います。

　このため、昨今の多くの案件では、「画面・帳票定義書」から、「イベント定義書」まで書いて、後はコーディングを行います。

　従って、モジュール・レベルのドキュメント（詳細設計書）は、フォワード（基本 → 機能 → 詳細）するのではなく、リバース生成するのがイイかと思います。また、SQLなどの品質に拘るなら、コチラに書いたように、別途SQL開発と検証を行えばイイと思います。

＜何故、こういう仕様になったのか？＞

　SIなので、開発自体には、高い柔軟性を要求されます。従って、テンプレート生成ダケに留めて、後は、開発者によりコーディングを行うスタイルとなっています。一方、100％自動生成を行うRAD系のノンプログラミング開発ツールは柔軟性が低いですし、例外処理をアドオン開発しようとすると、生産性が上がりません。

　また、基幹システム開発のシステム開発ライフサイクルは、ウォーター・フォール・モデルが採用されることが多いと思います。ウォーター・フォール・モデルでは、アクティビティやフェーズ間に「終了 - 開始関係（FS）」があり、これで段階的詳細化を行います。簡単に言うと、前工程のアウトプットをインプットにして後工程が進むので（、検収された）、設計工程の設計書を使って開発工程のプログラムを生成しようという発想に（、当時は）、なり易かったのだと思います。

　これに適合するのが、コレらの統合CASEツールとなりますが、

1. 設計思想が、上記のような前行程の設計書の流用と、乖離の防止なので、プログラミングの容易性は、あまり考えられておらず、
2. 開発を行っていることが大手企業の場合が多く、その適用先の自社の案件が確約されている垂直統合型スキームでは、企画 / 設計 / 開発に関する努力をしなくなり、企画レベル、仕様レベルの品質が上がらない。

　という問題もあり、開発者からの評判は、
　すこぶる悪いモノが多いと思います。

＜トレンドの変遷を再考する。＞

　しかし、こう行った、統合CASEツールはトレンドの変遷により廃れてきています。具体的には、以下の様な、トレンドの変遷があったのだと思います。そういうことで、今後、統合CASEツールを称するような開発スタイルは、受け入れられなくなって行くモノと思われます。

• 情報システムの高度化
　多くは、情報システムの高度化に起因していると思われます。


• アーキテクチャの多様化
　古くは、メインフレーム上でCOBOLのバッチとオンラインを動かすぐらいのアーキテクチャしかありませんでしたが、昨今は、C/S2層、3層、Webアプリケーション、WebAPI、クレームベース認証、RDB、NoSQLなどなど、多様なアーキテクチャに対応する必要があります。


• プロダクト・ライフサイクルの短縮
　競争激化により、各種プロダクトのライフサイクルが以前と比べて短くなっています。コレらは、開発に使用される開発言語やランタイム、フレームワークにも適用され、アップデートが頻繁になり、追随する必要性も出て来ましたが、変更されたアーキテクチャへの追随と同様に、統合CASEツールが対応するのは難しい問題領域です。


• プロトタイピングやアジャイル開発の浸透
　統合CASEツールは、そもそも、ウォーター・フォール・モデルのシステム開発ライフサイクルをターゲットに開発された開発支援ツールですので、プロトタイピングやアジャイル開発には適合しません。しかし、情報システムの高度化によって、アジャイルなどの新しいシステム開発ライフサイクルが導入される機会は、今後、増加し続けて行くモノと思われます。


• サプライサイドからデマンドサイドへのシフト
　基本的には、有限の期間と予算で、あるスコープを新規に開発するのがプロジェクトです。しかし、情報システムの高度化によって、スコープが確定していない状態でプロジェクトが開始され、要件定義フェーズの重要性が高まったり、その後の仕様変更が続いたり、そういうウォーター・フォール・モデルが適合しないプロジェクトが増えてきていると思います。


• ベンダの存在意義
　しかし、期間と予算は変わらないので、ベンダ（サプライサイド）から見てリスクは上がる一方で、対応したくない。という気持ちも解りますが、コモディティ化の激しいICT界隈ではデマンドサイドに追随しないとベンダ（サプライサイド）は存在意義を失いかねないのもまた事実です。故に、アジャイルなどの新しいシステム開発ライフサイクルを導入するプロジェクトは、今後、増えて行くものと予想されます。


• ベンダ側の都合
　統合CASEツールの自動生成メカニズムは、前述の「ウォーター・フォール・モデル前提」以外にも「ランタイムを納品・サポートしなくて済む。」、「プログラム著作権譲渡契約にも対応できる。」という商習慣上のベンダ側の都合がありました。しかし、最近では、OSSライセンスを適用すれば済むようになってきています。

　と言う事なので、「アーキテクチャが単純（単一）になり、ライフサイクルも長くなり、」などの、現在のトレンドに逆行する変化が無ければ、今後、統合CASEが息を吹き返す可能性は低い。と言えるでしょう。

＜参考＞