開発基盤部会 Blog

開発基盤部会 Blog >> 記事詳細

2019/02/15

統合CASEツールの類は何故、廃れたのか?

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

 統合CASEツールというのは、以下のスライド中で紹介している開発支援ツール(IDE、RAD、EUC、CASE、Template & Package)の内の1つになりますが、


 コレら最近は、この辺にも書きましたが、大概、廃れてきています(恐らく、多くの場合、SIの後継は「Template & Package」型の開発支援ツールになると思われる。内製の場合は、EUCツールも含まれる。また、スクラッチ開発自体が減っていく可能性も高い。)。

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

<アウトライン>

  • 柔軟性が低い問題。
  • 生産性がそれ程、上がらない問題。
  • 品質もそれ程、上がらない問題。
  • 何故、こういう仕様になったのか?
  • トレンドの変遷を再考する。



<柔軟性が低い問題>

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

 このため、アーキテクチャ変更が発生した場合、
  • 入力となる、リポジトリ / Excel設計書の入力フォームを変更し、
  • 更に、テンプレート・エンジンの実装を変更する。

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

<生産性がそれ程、上がらない問題>

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

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

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

<品質もそれ程、上がらない問題>

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

 こんな中で、設計書のフォワード(基本 → 機能 → 詳細)を行うと価値の作り込みが出来ず、作業形骸化が発生します(そして、モジュール・レベルは、実装時に覆されることになるでしょう)。このため、昨今の多くの案件では、イベント仕様まで書いて後はコーディングを行います。

 従って、モジュール・レベルのドキュメントはフォワードするのではなく、リバース生成するのがイイかと思います。また、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が息を吹き返す可能性は低い。と言えるでしょう。

<参考>


09:00 | 投票する | 投票数(0) | コメント(0) | ご報告