高品質のソフトウェアを効率よく開発すること、保守改訂が容易なソフトウェアにすることが重要であることは、プログラムが出現した当初から認識されていた。これが深刻になったのは1960年代末である。コンピュータが広く用いられるようになるのに伴い、プログラマが不足してきた。システムの規模が大きくなるのに伴い、システムが複雑になり、システムの品質を維持することが困難になってきた。NATOは1969年にソフトウェアエンジニアリング会議を開催した。Enginnering)が必要だとしたのである。この指摘もあり、1970年代には、ERDやDFDなどの図法、ウォータフォールモデルなどのシステム開発技法など、現在でも広く利用されている手法が発表され、次第に洗練されるようになった。日本でも、1980年にソフトウェア産業振興協会(当時)がソフトウェア・シンポジウム(第1回)を開催するなど、官民によるソフトウェア工学振興が進んだ。状況はますます深刻になり、通商産業省(現経済産業省)は1987年に『高度情報化社会を担う人材の育成についての提言』(1987年4月)を発表。2000年には97万人のソフトウェア技術者が不足すると警告し、人材の育成、開発技術の高度化が必要であると提言した。本ページは、「ソフトウェア工学」の学術的な内容ではない。日本一般的な大企業でのシステム設計やプログラミングに従事する実務者が、そのときどきにおいて話題にし、取り組んだ概念や手法を展望する。個人的な体験、見聞に偏っている。研究者等が新概念や新手法を提唱した時期である。実務者に広く普及するには、かなり時間がかかった。Sarson)、DFD提案。Diebold)、情報資源管理の提唱。UML0.9公開、翌年1.0になる。1960年代フローチャート日本の大企業が本格的にコンピュータを導入し始めたのは1960年代中頃である。当時は初期のFORTRANは既に普及していたが、事務処理の分野では、COBOLの利用が始まったばかりであり、大部分のプログラムはアセンブラが使われていた。アセンブラは記号言語で解読が困難だけでなく、C=A+Bのような処理にも数ステップを必要とした。ロジックを明確にしたり他人に示したりするのが困難である。それで、コーディングする以前にフローチャートを作成していた。その記述粒度は、コンパイラの1ステップを一つの図にする程度が一般的だった。当時は、業務を記述する図法は普及しておらず、情報システムの処理の流れもフローチャート形式で記述しており、ゼネラルフローチャートと呼ばれていた。1960年代の後半になるとCOBOLが普及してきた。COBOLの1ステップを1つの図にするようなフローチャートは作業量の割には効果がない。それでプログラマの間ではフローチャート不要論が出たのであるが、フローチャートのほうが視覚的に理解しやいし、教科書的にはフローチャートが文書化として必須だとされており、(渋々ながら?)作成していた。プログラミング作法そもそもCOBOLは、プログラムを文書として表現することを意図した言語である。現実には、その目的が達成できているプログラムは少ない。理解しやすく、保守改訂を容易にするために、ガイドラインを作成した。項目名の統一プログラムにより、TOKUISAKI、KOKYAKU、CUSTOMERとなっていたのでは困る。コートや名称も、TOKUISAKI-CODE、TOKUISAKI-NAMEのように-CODEや-NAMEで統一したい。ジャンプ先のラベル名も共通用語にしたい。それを徹底するために、標準用語集を作成したりファイル定義をライブラリ化したりした。字下げのルール例えばIF文、特に入れ子のIF文での字下げの標準化が重要だった。COBOLでは、THEN、ELSE、END-IFなどが省略可能であり、「.」の有無により処理が異なるので、字下げとともに、省略の是非を標準化することが必要だった。又聞きであるが、米軍のIT部門の事務室に「.」だけの額が掲げられていたという。ミサイル発射実験の失敗で大きな損失を蒙った。プログラムの「.」が不適切で誤動作したのが原因だという。これらの標準は、「作ったのだが実践されない」ことが多く、特に外注での徹底が大変だった(これは現在でも同様である)。1981年にカーニハン、プルーガ著、木村泉訳『プログラム作法』は、FORTRANによる技術計算を対象にしたものであったが、プログラマでの必須図書になった。この頃になるとPL/Iが普及してきた。当初はIBMユーザが主であったが、国産メーカーもPL/Iをサポートするようになっていた。COBOLよりもPL/Iのほうが「プログラミング作法」を実現しやすいので、主要言語をPL/Iに切り替えた企業がかなりあった。PL/Iの機能にポインタがあったが、当時は「ロジックをわかりにくくする」といわれ、使用を制限する規則にすることが多かった。それなのに、C言語ではポインタ利用が当然になっている。「プログラミング作法」も時代により変化するのだ。構造化プログラミング構造化プログラミング、GOTO命令有害説、モジュール化などの理論は1960年代末頃に提唱された。当初から反響をよんだ実務的な手法として実践されたのは1970年代に入ってからである。これらは、それまで個人的な職人芸であったプログラミングを理論的・体系的な技術に変えたパラダイムシフトであった。プログラミングでの表面的な変化を列挙する。サブルーチン階層化やモジュール化の考え方に基づき、個々のモジュールをサブプログラムとし、それらをつなげた全体の流れをメインプログラムとするようになった。従来はプログラムを1つのモジュールとして記述していたため、500ステップ以上になる長いプログラムが多かったが、「ソースリストは1枚の印刷用紙(60行)以内とする」ようになった。これはデバッグや修正を容易にするのに役立った。サブプログラムはサブルーチンともいう。技術計算では方程式の求根や行列計算など汎用的なサブルーチンは多く市販ライブラリもあったが、事務処理では他のプログラムでも使えるのは日数計算や定率償却計算などの少数に限られた。そのため、再利用よりも構造化によるわかりやすさを目的にすることが多かった。GOTOレスの記述GOTO命令有害論は、その頃、GOTO命令の乱用によるスパゲッティ状のプログラムに悩まされていた保守作業を救うために歓迎された。GOTO命令をなくすには、かなり教育が必要だった。GOTO命令をなくすには、WHILE命令やUNTIL命令などのループ命令がが必要になるが、ループ命令の初期設定や打切り条件の間違いが多かった。対して右の「GOTOなし」では、READ命令を2か所で記述するが、これは人間の思考法と異なる。「GOTOなし」しかも当時のCOBOLでは、CONTINUEやBRAKEなどループ内からの脱出命令が不備だったので、複雑なIF構造になることもあり、「戻りのGOTOは禁止するが、前向きのGOTOは柔軟に」というような不完全な取扱いもあった。従来のフローチャート記法がGOTO命令の使用を増長していると指摘された。フローチャートで繰り返し記号が正式に導入されたのはかなり後になってからであるが、当時でも自作の記号を使っていた人が多かった。ワーニエ法などGOTOが書けないフローチャート図法が提案されたが、実際に記述すると体裁が悪いとか修正がしにくいなどの理由で、あまり普及しなかった。集計処理、マスタファイルとのマッチング処理などのパターンがあるが、せいぜい20程度のパターンにまとめることができる。モジュール化によりメインプログラムが簡素になったこと、GOTOレスの記述を普及したいことなどから、標準パターンを体系化して、それぞれにスケルトンとなるプログラムを提供し、それを修正することによりプログラムを作成するのが流行した。当時はプログラムを紙カードに穿孔する時代であり、スケルトンの利用には限界があったが、1980年代後半になりTSSでプログラムを作成するようになると、生産性向上に大きく貢献した。ソフトウェアライフサイクルとウォータフォール型開発技法ソフトウェアライフサイクルやウォータフォールモデルの概念は以前からあったらしいが、実務者が実践するようになったのは、IBMの各種マニュアルが整備され国産メーカーもそれを取り上げるようになった1970年代中頃である。コンピュータ導入当時のシステム化対象業務は給与計算や財務会計など論理も処理手順も明確だったが、この頃になると、適用業務が複雑になってきた、それに伴い、システム化要件があいまいなままにシステム開発に入り、大きな手戻りが発生することが頻発されるようになった。そこにこのような概念が出てきたのはIT部門にとって朗報であった。前工程が承認されない限り後工程には入らないというお墨付きを得たのである。ところが、経営者や利用部門は、タテマエでは同意するが、現実には手戻り要求が多かった。承認手続のために時間がかかり、結局は納期に追われることも多かった。このような要件不備問題は現在も変わっていない。プロセス中心アプローチ1970年代までのシステム開発では、ゼネラルフローチャートでも明らかのように、プログラムが中心であった。容量制約からプログラムは複雑な処理ができず、中間ファイルが多かった。Approach)と呼ばれる)。POAは、手作業での処理と類似しており、当初のシステム開発アプローチがPOAであったことは自然の成り行きであろう。POAでは業務環境の変化に直結してプログラムの改訂が必要になるし、それによりデータファイルの変更が必要になる。環境変化に弱い欠点がある。Approach、データ中心アプローチ)が注目されるようになった。日本では、1980年代中頃から普及した。データの構造は環境変化があっても大幅な変更を必要としない。この頃になるとプログラム作成はTSSを使うのが通常になり、標準パターンなども整備されてきたので、プログラミング作業が低減してきた。Management、情報資源管理)が提唱され、データ管理の重要性が認識されてきた。それでデータベースを中心にして、それの作成・更新・参照を行うプログラムを付帯的なものと位置付けるDOAが注目されたのである。Database)の実用化がDOAを実現させた。Diagram)の図法が適している。RDBの操作言語としてSQLが開発された。こららは1970年代中頃には開発されており、それに呼応してDOAの概念が生まれたのであるが、当時のコンピュータ性能や技術では、RDBはあまりにも処理時間がかかりすぎた。一般企業でRDBが利用されるようになったのは1980年代後半である。(注)NDB1970年代後半からデータベースの利用は行われていた。Database、網構造モデル)であり、あらかじめ設定した結合インデクス(静的結合)により、定例的な処理の効率は高かったが、動的結合ができないため、それとは異なる結合処理には困難だった。そのため、システム改訂にはデータベースの変更を伴った。スキーマ定義などデータベースの管理に専門担当者を必要とした。多くの企業がNDBを採用したが、管理能力が未熟なために、データベースそのものがブラックボックスになってしまい、新しい処理をするときに、データベースから通常のファイルに変換して使うなど、データベースが厄介者になってしまったケースも多い。(注)POAとDFDDOAが注目されたとはいえ、プロセスを重視するPOAが消滅したのではない。大規模で比較的安定した業務にはPOAのほうが適していることが多い。(1994年)が出版されている。情報検索系システムとDOA1980年代前半では、DOAが優れていることは認識したものの、実際に活用するには、POAの考え方で構成されている既存システムを全面的に再構築する必要があるし、全面的にRDBを採用するにはハードウェアの大幅な増強が必要になる。そのため、この頃に基幹業務系システムにDOAを採用したのは、たまたまシステムの全面改訂を行う企業か、先進企業が部分的業務に適用した程度であった。1980年代初頭頃から、基幹業務系システムで収集蓄積したデータをエンドユーザが使いやすいように整理して公開し、エンドユーザがTSSによりそれを任意な切り口で検索加工する情報検索系システムが普及し始めた。この「任意の切り口」に対処するには、RDBが適している。RDBを使わなくても、公開ファイルではデータの正規化を行うのが適切である(処理効率のために、実装段階では正規化を崩す必要があったが)。それで、情報検索系システムからDOAを採用した企業が多かった。RDBの導入も同様である。簡易言語SQL以前にも、情報検索系システムの普及に伴い、多様な簡易言語が提供されるようになった。基幹業務系システムでも入出力などヒューマンインタフェースが多い処理を除けば、簡易言語で記述できる処理が多い。COBOLやPL/Iよりも簡易言語のほうがステップ数が少なく記述できるので生産性も高いし、慣れれば見読性も高い。そのため、基幹業務系システムでも簡易言語を公式言語として利用するようになった。CASE従来のプログラミング作成には、エディタ、コンパイラ、デバッガーなど個々のツールを使っていた。Engineering)ツールが注目されるようになった。1980年代中頃には、TSSによる対話方式で、スケルトンプログラムからプログラムを作成して、プログラムのバグを表示して修正させ、テストデータで確認するという環境ができた。この一部はコンパイラの拡張機能としても提供されていた。1980年代の後半になると、GUI環境になった。当初はパソコンでのプログラミングを目的とするものであったが、COBOLなど汎用コンピュータ言語での開発にも適用するようになった。一般の企業では本格的な市販CASEツールを購入することは少なく、コンパイラなどに標準装備されて機能を用いたり、ソースプログラムからフローチャートを作成するような部分的なツールを使用するのがほとんどだった。System、戦略的情報システム)の概念は、それを強く認識させることになった。この頃までに、一般企業の大規模システム開発では、システム内部設計やプログラミングなどの下流工程は外注するのが通常になっていた。そのため、上流工程での方法論の確立、外注ベンダとの正確な意思疎通のための共通概念・用語の確立が必要になった。1994年に経済産業省は「共通フレーム」を策定した。システムのライフサイクルの上流から下流までを統合して、各プロセスで行う作業を示し、用語を標準化したのである。普及はしたのであるが、実務界で日常的に使われるもでにはいかなかった。CASEツールでは、プログラム作成を主目的とする下流CASEツールだけでなく、上流工程を対象にした上流CASEツールが開発されるようになった、その後、上流・下流を一貫した統合CASEツールも出現した。要件定義、DFD、ERDなどを記述するとプログラムが自動生成することを目的としていたが、実用的にはならず、むしろ文書化ツールとして使われることが多かった。非ウォータフォール型開発技法1980年代後半になると、システムの短期開発の必要性が認識され、ウォータフォール型開発技法の欠点が指摘された。その解決として、プロトタイピングやスパイラルなどの開発技法が提唱され、1990年代初頭頃から普及した。1990年代中頃にはRADが注目された。Explained)が提案されるなど、短期開発への対応が進む。これらは、システム開発の下流工程にまで利用部門の参加を求めるものであり、システム開発体制に大きな変化を与えた。環境変化に柔軟なシステムとしてオブジェクト指向アプローチが適していることは、すでに1970年代から認識されており、1972年にはSmalltalk、1979年にはC++など、オブジェクト指向言語も開発されていた。オブジェクト指向アプローチが一般企業に普及したのは1990年代後半になってらである。1996年にオブジェクト指向の図法がUMLとして統一されたことと、Javaの正式版の公開、さらに1998年にJavaの開発環境であるJ2SEやJ2EEが提供されるようになったのが普及の大きなきっかけになった。システム開発、特にプログラミングの観点では、オブジェクト指向は大きな思考の変化を要求した。プログラムを部品の組み合わせとしてとらえることは、構造化プログラミングでも行われていたのであるが、オブジェクト指向ではそれが徹底した。Java言語を習得するには、個々の命令文の理解よりも、標準として提供される膨大なクラスを覚えることが重要になったのである。FORTRANを覚えるのにサブルーチン群まで暗記せよというようなものである。オブジェクト指向プログラミングは、「入力があったら、在庫がなくなったら~をする」というように、何かが引き金になって処理を行うイベント駆動型である。これは、従来の手続き型言語での「入力するにはどうするか」を記述するのとは発想法から異なる。そのため、従来の発想法が染み込んでいるベテランプログラマにとって、オブジェクト指向は心理的に大きな障壁があり、ベテラン不要論まで発生した。UMLUML記法は、DFDやERDに習熟している者にとっては理解しやすいし、UMLになるまでにOMTやBooch法が知られていたので、あまり抵抗なく受け入れられた(UMLからコードを自動生成させるには、厳密な図法ルールに従って、詳細な記述をする必要があり、必ずしも容易とはいえないが)。UMLは経営者や利用部門にも理解できる「可視化ツール」だといわれるが、DFDやERDと比べて機能が多彩なので、かえって説明が必要になる。いくつものUMLを作成し、その間の矛盾が問題になることもある。ERPパッケージ1990年代後半にERPパッケージによるシステム開発が普及した。その理由にはBPRの実現、汎用コンピュータ環境からダウンサイジング環境への移行、海外事務所との連携、西暦2000年問題への対応などがある。ERPパッケージの導入は、システム開発に大きな打撃を与えた。これまでは、自主開発するか外注するかにかかわらず、独自の自社仕様による開発が通常であった。それが、ERPパッケージにより、システムは「作るから買う」へ変化したのである。実際には、業務とシステムとのマッチングや既存システムとのインタフェースなど多様な作業があり、システム稼働までには、むしろ従来システムよりも多くの作業が発生したような例もあるが、論理的に極端にいえば、一般企業からシステム開発業務がなくなったのである。Environment、統合開発環境)が提供され普及した。2000年代後半には、UMLの図からプログラムを生成するツールが普及した。Language(言語)になったのである。プログラミングはキーボードでソースコードを打つのではなくマウスで作成する時代になったのである。Webアプリケーションインターネットの普及によりWebページを利用したアプリケーションが多くなった。それに伴い、HTML内に記述できる言語、CGIで呼び出されるアプリケーションを作成する言語として、スクリプト言語(軽量プログラミング言語)が広く使われるようになった。これらの言語は、既に1990年代に開発されていた。JavaScriptがECMAScriptとして標準化しかし、これらを使った本格的なシステム構築が普及したのは2000年代に入ってからである。2005年にJavaScriptの非同期通信を利用した技術であるAjaxが開発され、グーグルやアマゾン・コムがそれを活用したアプリケーションを開発、そのAPIを公表したことから、Webアプリケーション開発が急速に普及した。Webアプリケーションは、当初は消費者向けのWebページに適用されたが、社内でのWeb化が進むに伴い、社内システムでもこのような仕組みが採用されつつある。現在はローカル的な分野が主であるが、そのうちに基幹業務系システムにも適用されるであろう。HTMLがベースになるので、本文のコンテンツが重要になる。消費者向けの受注システムなどでは、商品展示などのセンスが求められるので、プログラマだけで開発するのは困難である。そのため、開発体制が大きく変化してきた。技術面では、取り扱うデータがXMLが主流になってきた。それと従来型のデータファイルとの連携も必要になる。クラウドコンピューティングERPパッケージは、一般企業でのシステム開発をなくしたといったが、この動向は、2000年代後半に起こったクラウドコンピューティングでさらに顕著になる。インターネットのブロードバンド化により、社外サーバを利用した処理速度が急速に向上した。それで、ハードウェアだけでなく、アプリケーションやデータまでもプロバイダ側が持ち、自社にはクライアントだけを設置すればよい環境になったのである。ERPパッケージでは、そのシステムは自社で所有していたのであるが、クラウドコンピューティングではそれらをプロバイダ側にゆだねることになる。「所有から利用へ」の変化である。極端な表現をすれば、ITは電気や水道のようなものになったのである。見方によっては、コンピュータ導入以前の情報センター利用への回帰だともいえる。そのシステム化方法論として2003年に「業務・システム最適化計画」が策定された。Architecture)をベースにしたものである。業務と情報システムとの関係など上流工程を重視した方法論になっている。ここでは、標準的な図法として、DFD、ERD、UMLなど各種図法の体系が示され、主に中央官庁を対象としたひな型が示されている。これらの図を描いたり相互関連をチェックするツールも提供されている。これらは民間企業でも利用できる。全面的な採用をしている企業は少ないが、部分的に利用している企業は多い。2007年に「共通フレーム」が改訂された。ここでも「超上流工程」として、経営や業務と情報システムの関係を新たに取り入れている。このように、一般企業でのシステム開発への関心は、下流から上流へ、さらに超上流へと移ってきたのである。それに伴い、システム開発の従事者がプログラマからSEへ、さらにアナリストや経営者へと変化してきたのである。トピックス別の変化プログラム作成方法1970年代までは、プログラムを「書く」時代だった。コーディングシートに手書きしたプログラムを紙カードや紙テープに穿孔して読取機でコンピュータに読み込ませていた。1980年代後半になると、TSSが実用化してきたので、端末のキーボードからプログラムを入力するようになった。その結果がディスプレイに表示されるので、それを修正すればよい。プログラムを「打つ」時代になった。Frameworkなどの統合開発環境が提供される。UMLなどの図をディスプレイに書き込むとプログラムが生成されるようになった。プログラムはマウスで「描く」ようになったのである。プログラミング言語の影響1960年代はプログラミングは職人芸で個人のスタイルに任されていた。それでは他人が理解できないので、項目名の統一や字下げのルールなどプログラミング作法が認識され、社内標準化が行われた。1960年代末に、GOTO命令有害論、モジュール化など「構造化プログラミング」が提唱された。職人芸から技術的方法論への進化である。この頃に、サブルーチンによるモジュール化や標準パターンによるロジックの標準化が行われた。1980年代になると簡易言語が普及してきた。1980年代後半にはRDB用言語のSQLが普及した。ステップ数が少なく記述できること、非手続き言語で理解しやすいことなど、プログラミングの生産性向上に役立った。1990年代になると、オブジェクト指向言語であるJavaが普及した。この言語では元のクラスになるコンポーネントを組み合わせる形でプログラムする。従来は、比較的少数の命令文で自分がロジックを組み立てる外科医的能力が必要だったが、Javaなどでは、非常に多数のコンポーネントを知って、それを組み合わせる内科医的能力が重要になった。図法コンピュータ導入頃はもっぱらフローチャートが用いられていた。プログラム内部設計、プログラムの見読性が目的1975年にERD、1976年にDFDが提案された。前者は情報の流れ、後者はデータベース設計1990年頃、オブジェクト指向のための図法が提案1996年に統一されUMLとなる。システム最適化計画」で標準図法を示した。政策(経営戦略)、業務、情報システムの関係システム設計アプローチPOA→DOA→OOA→SOAの流れは、部品化と再利用化への発展である。次第に部品の粒度が大きくなり、プログラム→システム→業務へと対象が広がってきた。POA(プロセス中心アプローチ)当初は、実業務を情報システムにマッピングするのが当然だと思われていたので、担当者の処理をプログラム、伝票や帳票をファイルとし、システムとはプログラムの流れであり、そこでの情報の受け渡しにデータファイルがある、すなわち、プログラムが主でデータが従の位置つけであった、それをPOAという。ここでの部品化とは、プログラムのモジュール化であり、その典型的なものがサブルーチンである。DOA(データ中心アプローチ)1980年代になると、DOAの考え方が普及した。1980年代後半になるとRDBが実用化し、RDB設計のためのERD、RDB用言語であるSQLが普及した。DOAは、データをプログラムの存在に関係なく整理する考え方だといえる。データを部品化して再利用(共通利用)する考え方だともいえる。OOA(オブジェクト指向アプローチ)1990年代後半から2000年代になると、OOAが普及した。データだけでなく、それを参照したり更新したりする手続き(メソッド)までも部品化して再利用することになった。SOA(サービス指向アーキテクチャ)2000年代後半になるとSOAの概念が注目されるようになった。部品化とは抽象化による共通化だといえる。SOAでは、ここでのサービスとは「受注」や「出荷」など業務単位であり、システム設計とは、それらのサービスを組み合わせることだといえる。この考え方は、情報システムではなく業務に基づいた部品化であり、従来の部品化とは大きく異なる。素晴らしいのであるが、一般のユーザ企業では、サービスを単位としたのでは部品の粒度が大きすぎ、再利用する頻度は少ない。SaaSプロバイダに適切な方法論だと思われる。システム開発技法システム開発技法にはウォータフォール型やスパイラル型など多様な技法があるが、その主旨を実現するのはなかなか困難である。「銀の弾丸はない」のである。システムを構築するには、その目的やニーズを聞いて、おおまかな仕様を示して確認を得て、プログラム作成をするという手順は、常識的であり、当初から行われていた。それが、ライフサイクル、ウォータフォール型開発技法として理論化され、1970年代中頃になると一般実務家に普及した。現実には、経営者や利用部門は「手戻りの危険」を十分に認識しておらず、要件定義や概要設計を安易に承認していた。後になって変更が生じて、IT部門が文句をいっても、変更しなければ役に立たないのだから、変更に応じるしかない。それによる費用の増加や納期の遅れの責任を巡って対立が生じても、結局はIT部門の責任とされることが多かった。それで、IT部門では「システム開発は計画した2倍の費用と2倍の時間がかかり、機能は2分の1しか実現しない」という「222の法則」がいわれた。この法則が正しいことは、1990年代になってスタンデッシュ社の調査で証明された。ウォータフォール型開発技法の欠点を回避する方法として、1980年代後半になると、プロトタイピングやスパイラルなどの開発技法が普及してきた。1990年代になると、RADが注目されるようになった。これらは、比較的小規模で環境変化が多い対象業務に適用された。これらの特徴は、IT担当者と業務担当者がペアになって作業を進めるのが特徴であるが、業務担当者の人選が重要になる。消極的な担当者だと、自部門業務が多忙なことを理由に、開発作業をサボるのでペア作業が滞る。過度に積極的だと細かい変更を主張し、エンドレスなスパイラルに陥る。自部門での統制力がないと、完成したはずのシステムが、業務部門の反対により、大きな手戻りになる。複数のサブシステムに分割して開発する場合、個々の業務担当者の意見の相違により、一貫性に欠けるシステムになりやすい。昨今は、企業間競争に勝つために、新システムを早期に稼働することが求められるようになった。それが、「ともかく適当な要件で作ってしまえ。不都合が生じたら、また作り直せばよい」という風潮が出てきた。クラウドコンピューティングもそのような「使い捨てシステム」の手段に採用されるケースもある。このようなシステムは、Web環境での対消費者取引を対象にしたものに多い。消費者をテスト担当者にするような手法は許されない。憂慮すべき風潮である。当初は、自社独自仕様のシステムを自社で開発していた。次第に外注で開発するようになったが、それでも自社独自仕様であることは変わらなかった。システムは「作る」時代であった。1990年代中頃から普及したERPパッケージでは、ERPパッケージの仕様に合わせて業務を変えることになった。システムは「買う」時代になったのである。それらのシステムは自社が所有するのが通常であった。2000年代になるとASP→SaaS→クラウド・コンピューティングが普及した。その環境では、ソフトウェアだけでなくデータもプロバイダのハードウェアにあり、ユーザ企業はそれを利用するだけになる。システムは「所有」するのではなく、「利用」するものになったのである。これは多分にIT部門の任務と密接な関係がある。Processing:データ処理)業務が主任務であった。それが、構築の下流工程や運用を社外に委託して、システム設計の上流工程だけを受け持つことになった。業務のあるべき姿を設計する超上流工程だけに絞り込むようになった。その社外に出す任務の拡大がシステム取得方法の変化になったのである。