スタートページ＞ （主張・講演、 Ｗｅｂ教材） 歴史＞ 経営とＩＴ
高品質のソフトウェアを効率よく開発すること、保守改訂が容易なソフトウェアにすることが重要であることは、プログラムが出現した当初から認識されていた。
これが深刻になったのは１９６０年代末である。コンピュータが広く用いられるようになるのに伴い、プログラマが不足してきた。システムの規模が大きくなるのに伴い、システムが複雑になり、システムの品質を維持することが困難になってきた。
ＮＡＴＯは１９６９年にソフトウェアエンジニアリング会議を開催した。このような状況をソフトウェア危機（Software Crisis）であるとし、それを解決するためには、ソフトウェア開発を工学的な観点から方法論や手法を整備すること、すなわち、ソフトウェア工学（Software Enginnering）が必要だとしたのである。
この指摘もあり、１９７０年代には、ＥＲＤやＤＦＤなどの図法、ウォータフォールモデルなどのシステム開発技法など、現在でも広く利用されている手法が発表され、次第に洗練されるようになった。
日本でも、１９８０年にソフトウェア産業振興協会(当時)がソフトウェア・シンポジウム（第１回）を開催するなど、官民によるソフトウェア工学振興が進んだ。しかし、状況はますます深刻になり、通商産業省（現経済産業省）は１９８７年に『高度情報化社会を担う人材の育成についての提言』（1987年4月）を発表。２０００年には９７万人のソフトウェア技術者が不足すると警告し、人材の育成、開発技術の高度化が必要であると提言した。
本ページは、「ソフトウェア工学」の学術的な内容ではない。日本一般的な大企業でのシステム設計やプログラミングに従事する実務者が、そのときどきにおいて話題にし、取り組んだ概念や手法を展望する。かなり個人的な体験、見聞に偏っている。
以下は、研究者等が新概念や新手法を提唱した時期である。しかし、実務者に広く普及するには、かなり時間がかかった。
日本の大企業が本格的にコンピュータを導入し始めたのは１９６０年代中頃である。当時は初期のFORTRANは既に普及していたが、事務処理の分野では、COBOLの利用が始まったばかりであり、大部分のプログラムはアセンブラが使われていた。
アセンブラは記号言語で解読が困難だけでなく、Ｃ＝Ａ＋Ｂのような処理にも数ステップを必要とした。ロジックを明確にしたり他人に示したりするのが困難である。それで、コーディングする以前にフローチャートを作成していた。その記述粒度は、コンパイラの１ステップを一つの図にする程度が一般的だった。
当時は、業務を記述する図法は普及しておらず、情報システムの処理の流れもフローチャート形式で記述しており、ゼネラルフローチャートと呼ばれていた。
１９６０年代の後半になるとＣＯＢＯＬが普及してきた。ＣＯＢＯＬの１ステップを１つの図にするようなフローチャートは作業量の割には効果がない。それでプログラマの間ではフローチャート不要論が出たのであるが、フローチャートのほうが視覚的に理解しやいし、教科書的にはフローチャートが文書化として必須だとされており、（渋々ながら？）作成していた。
フローチャートの寿命は長く、現在でも情報処理技術者試験では必須の知識である。
そもそもＣＯＢＯＬは、プログラムを文書として表現することを意図した言語である。しかし、現実には、その目的が達成できているプログラムは少ない。少しでも理解しやすく、保守改訂を容易にするために、ガイドラインを作成した。
又聞きであるが、米軍のＩＴ部門の事務室に「．」だけの額が掲げられていたという。ミサイル発射実験の失敗で大きな損失を蒙った。プログラムの「．」が不適切で誤動作したのが原因だという。
これらの標準は、「作ったのだが実践されない」ことが多く、特に外注での徹底が大変だった（これは現在でも同様である）。
１９８１年にカーニハン、プルーガ著、木村泉訳『プログラム作法』は、FORTRANによる技術計算を対象にしたものであったが、プログラマでの必須図書になった。
なお、この頃になるとＰＬ/Ｉが普及してきた。当初はＩＢＭユーザが主であったが、国産メーカーもＰＬ/Ｉをサポートするようになっていた。ＣＯＢＯＬよりもＰＬ/Ｉのほうが「プログラミング作法」を実現しやすいので、主要言語をＰＬ/Ｉに切り替えた企業がかなりあった。
ＰＬ/Ｉの機能にポインタがあったが、当時は「ロジックをわかりにくくする」といわれ、使用を制限する規則にすることが多かった。それなのに、Ｃ言語ではポインタ利用が当然になっている。「プログラミング作法」も時代により変化するのだ。
構造化プログラミング、ＧＯＴＯ命令有害説、モジュール化などの理論は１９６０年代末頃に提唱された。当初から反響をよんだ実務的な手法として実践されたのは１９７０年代に入ってからである。これらは、それまで個人的な職人芸であったプログラミングを理論的・体系的な技術に変えたパラダイムシフトであった。
プログラミングでの表面的な変化を列挙する。
階層化やモジュール化の考え方に基づき、個々のモジュールをサブプログラムとし、それらをつなげた全体の流れをメインプログラムとするようになった。従来はプログラムを１つのモジュールとして記述していたため、５００ステップ以上になる長いプログラムが多かったが、「ソースリストは１枚の印刷用紙（６０行）以内とする」ようになった。これはデバッグや修正を容易にするのに役立った。
サブプログラムはサブルーチンともいう。技術計算では方程式の求根や行列計算など汎用的なサブルーチンは多く市販ライブラリもあったが、事務処理では他のプログラムでも使えるのは日数計算や定率償却計算などの少数に限られた。そのため、再利用よりも構造化によるわかりやすさを目的にすることが多かった。
ＧＯＴＯ命令有害論は、その頃、ＧＯＴＯ命令の乱用によるスパゲッティ状のプログラムに悩まされていた保守作業を救うために歓迎された。
しかし、ＧＯＴＯ命令をなくすには、かなり教育が必要だった。ＧＯＴＯ命令をなくすには、ＷＨＩＬＥ命令やＵＮＴＩＬ命令などのループ命令がが必要になるが、ループ命令の初期設定や打切り条件の間違いが多かった。ファイルからデータを読み込み処理するプログラムは、左の「ＧＯＴＯあり」ni 対して右の「ＧＯＴＯなし」では、ＲＥＡＤ命令を２か所で記述するが、これは人間の思考法と異なる。
開始処理 開始処理
＊戻り ＲＥＡＤ
ＲＥＡＤ ＷＨＩＬＥ（データあり）
ＩＦ(データなし) ＧＯＴＯ＊終り 処理
処理 ＲＥＡＤ
ＧＯＴＯ＊戻り ＥＮＤ ＷＨＩＬＥ
＊終り 終了処理
終了処理
「ＧＯＴＯあり」 「ＧＯＴＯなし」
しかも当時のＣＯＢＯＬでは、CONTINUEやBRAKEなどループ内からの脱出命令が不備だったので、複雑なＩＦ構造になることもあり、「戻りのＧＯＴＯは禁止するが、前向きのＧＯＴＯは柔軟に」というような不完全な取扱いもあった。
従来のフローチャート記法がＧＯＴＯ命令の使用を増長していると指摘された。フローチャートで繰り返し記号が正式に導入されたのはかなり後になってからであるが、当時でも自作の記号を使っていた人が多かった。また、ワーニエ法などＧＯＴＯが書けないフローチャート図法が提案されたが、実際に記述すると体裁が悪いとか修正がしにくいなどの理由で、あまり普及しなかった。
事務処理では、追加・削除・変更などの更新処理、小計・中計・大計の集計処理、マスタファイルとのマッチング処理などのパターンがあるが、せいぜい２０程度のパターンにまとめることができる。モジュール化によりメインプログラムが簡素になったこと、ＧＯＴＯレスの記述を普及したいことなどから、標準パターンを体系化して、それぞれにスケルトンとなるプログラムを提供し、それを修正することによりプログラムを作成するのが流行した。
当時はプログラムを紙カードに穿孔する時代であり、スケルトンの利用には限界があったが、１９８０年代後半になりＴＳＳでプログラムを作成するようになると、生産性向上に大きく貢献した。
ソフトウェアライフサイクルやウォータフォールモデルの概念は以前からあったらしいが、実務者が実践するようになったのは、ＩＢＭの各種マニュアルが整備され国産メーカーもそれを取り上げるようになった１９７０年代中頃である。
コンピュータ導入当時のシステム化対象業務は給与計算や財務会計など論理も処理手順も明確だったが、この頃になると、適用業務が複雑になってきた、それに伴い、システム化要件があいまいなままにシステム開発に入り、大きな手戻りが発生することが頻発されるようになった。
そこにこのような概念が出てきたのはＩＴ部門にとって朗報であった。前工程が承認されない限り後工程には入らないというお墨付きを得たのである。ところが、経営者や利用部門は、タテマエでは同意するが、現実には手戻り要求が多かった。また、承認手続のために時間がかかり、結局は納期に追われることも多かった。このような要件不備問題は現在も変わっていない。
１９７０年代までのシステム開発では、ゼネラルフローチャートでも明らかのように、プログラムが中心であった。容量制約からプログラムは複雑な処理ができず、中間ファイルが多かった。すなわち、データファイルはプログラムからプログラムに中間結果を引き渡すためのもので、システム全体としては付帯的な位置づけであった（このようなアプローチは、後になって、ＰＯＡ（Process Oriented Approach、あるいは、Program Oriented Approach）と呼ばれる）。
ＰＯＡは、手作業での処理と類似しており、当初のシステム開発アプローチがＰＯＡであったことは自然の成り行きであろう。
しかし、ＰＯＡでは業務環境の変化に直結してプログラムの改訂が必要になるし、それによりデータファイルの変更が必要になる。環境変化に弱い欠点がある。
１９８０年代になると、システム開発のアプローチとして、ＤＯＡ（Process Oriented Approach、データ中心アプローチ）が注目されるようになった。日本では、１９８０年代中頃から普及した。
データの構造は環境変化があっても大幅な変更を必要としない。この頃になるとプログラム作成はＴＳＳを使うのが通常になり、標準パターンなども整備されてきたので、プログラミング作業が低減してきた。また、ディーボルト（John Diebold）らによりＩＲＭ（Information Resources Management、情報資源管理）が提唱され、データ管理の重要性が認識されてきた。
それでデータベースを中心にして、それの作成・更新・参照を行うプログラムを付帯的なものと位置付けるＤＯＡが注目されたのである。
ＲＤＢ（Relational Database）の実用化がＤＯＡを実現させた。ＲＤＢの設計にはＥＲＤ（Entity-Relationshipl Diagram）の図法が適している。そして、ＲＤＢの操作言語としてＳＱＬが開発された。
こららは１９７０年代中頃には開発されており、それに呼応してＤＯＡの概念が生まれたのであるが、当時のコンピュータ性能や技術では、ＲＤＢはあまりにも処理時間がかかりすぎた。一般企業でＲＤＢが利用されるようになったのは１９８０年代後半である。
１９７０年代後半からデータベースの利用は行われていた。当時のデータベースはＮＤＢ（Network Database、網構造モデル）であり、あらかじめ設定した結合インデクス（静的結合）により、定例的な処理の効率は高かったが、動的結合ができないため、それとは異なる結合処理には困難だった。
そのため、システム改訂にはデータベースの変更を伴った。しかも、スキーマ定義などデータベースの管理に専門担当者を必要とした。
多くの企業がＮＤＢを採用したが、管理能力が未熟なために、データベースそのものがブラックボックスになってしまい、新しい処理をするときに、データベースから通常のファイルに変換して使うなど、データベースが厄介者になってしまったケースも多い。
ＤＯＡが注目されたとはいえ、プロセスを重視するＰＯＡが消滅したのではない。大規模で比較的安定した業務にはＰＯＡのほうが適していることが多い。
ＰＤＡでのシステム設計に重要なＤＦＤ（data flow diagram）が提唱されたのは１９７７年であり（ゲイン（Christopher P. Gane）とT・サーソン（Trish Sarson）の共著『Structured Systems Analysis: Tools and Techniques』）、構造化分析が普及したのはデマルコ（Tom DeMarco）の『Structured Analysis and System Specification』（1979年）であり、１９９０年代になってもデマルコ著、高梨智弘・黒田順一郎訳『構造化分析とシステム仕様』 （1994年）が出版されている。
１９８０年代前半では、ＤＯＡが優れていることは認識したものの、実際に活用するには、ＰＯＡの考え方で構成されている既存システムを全面的に再構築する必要があるし、全面的にＲＤＢを採用するにはハードウェアの大幅な増強が必要になる。そのため、この頃に基幹業務系システムにＤＯＡを採用したのは、たまたまシステムの全面改訂を行う企業か、先進企業が部分的業務に適用した程度であった。
一方、１９８０年代初頭頃から、基幹業務系システムで収集蓄積したデータをエンドユーザが使いやすいように整理して公開し、エンドユーザがＴＳＳによりそれを任意な切り口で検索加工する情報検索系システムが普及し始めた。
この「任意の切り口」に対処するには、ＲＤＢが適している。ＲＤＢを使わなくても、公開ファイルではデータの正規化を行うのが適切である（処理効率のために、実装段階では正規化を崩す必要があったが）。それで、情報検索系システムからＤＯＡを採用した企業が多かった。ＲＤＢの導入も同様である。
ＳＱＬ以前にも、情報検索系システムの普及に伴い、多様な簡易言語が提供されるようになった。基幹業務系システムでも入出力などヒューマンインタフェースが多い処理を除けば、簡易言語で記述できる処理が多い。ＣＯＢＯＬやＰＬ/Ｉよりも簡易言語のほうがステップ数が少なく記述できるので生産性も高いし、慣れれば見読性も高い。そのため、基幹業務系システムでも簡易言語を公式言語として利用するようになった。
従来のプログラミング作成には、エディタ、コンパイラ、デバッガーなど個々のツールを使っていた。それを統合して１つのツールですべての作業をサポートするＣＡＳＥ（Computer Aided Software Engineering）ツールが注目されるようになった。
１９８０年代中頃には、ＴＳＳによる対話方式で、スケルトンプログラムからプログラムを作成して、プログラムのバグを表示して修正させ、テストデータで確認するという環境ができた。この一部はコンパイラの拡張機能としても提供されていた。
１９８０年代の後半になると、ＧＵＩ環境になった。当初はパソコンでのプログラミングを目的とするものであったが、ＣＯＢＯＬなど汎用コンピュータ言語での開発にも適用するようになった。
しかし、一般の企業では本格的な市販ＣＡＳＥツールを購入することは少なく、コンパイラなどに標準装備されて機能を用いたり、ソースプログラムからフローチャートを作成するような部分的なツールを使用するのがほとんどだった。
情報システムは経営戦略や業務ニーズに合致する必要があるので、要件定義からシステム概要設計までの上流工程を重視すべきだという認識は、コンピュータ導入当初からあったが、１９８０年代後半に普及したＳＩＳ（Strategic Information System、戦略的情報システム）の概念は、それを強く認識させることになった。
また、この頃までに、一般企業の大規模システム開発では、システム内部設計やプログラミングなどの下流工程は外注するのが通常になっていた。
そのため、上流工程での方法論の確立、外注ベンダとの正確な意思疎通のための共通概念・用語の確立が必要になった。
１９９４年に経済産業省は「共通フレーム」を策定した。システムのライフサイクルの上流から下流までを統合して、各プロセスで行う作業を示し、用語を標準化したのである。これらの方策により、ライフサイクルの概念は定着したが、用語の統一は、情報処理技術者試験などで普及はしたのであるが、実務界で日常的に使われるもでにはいかなかった。
ＣＡＳＥツールでは、プログラム作成を主目的とする下流ＣＡＳＥツールだけでなく、上流工程を対象にした上流ＣＡＳＥツールが開発されるようになった、その後、上流・下流を一貫した統合ＣＡＳＥツールも出現した。
要件定義、ＤＦＤ、ＥＲＤなどを記述するとプログラムが自動生成することを目的としていたが、実用的にはならず、むしろ文書化ツールとして使われることが多かった。
１９８０年代後半になると、システムの短期開発の必要性が認識され、ウォータフォール型開発技法の欠点が指摘された。その解決として、プロトタイピングやスパイラルなどの開発技法が提唱され、１９９０年代初頭頃から普及した。１９９０年代中頃にはＲＡＤが注目された。さらに１９９０年代末にはＸＰ（Extreme Programming Explained）が提案されるなど、短期開発への対応が進む。
これらは、システム開発の下流工程にまで利用部門の参加を求めるものであり、システム開発体制に大きな変化を与えた。
環境変化に柔軟なシステムとしてオブジェクト指向アプローチが適していることは、すでに１９７０年代から認識されており、１９７２年にはSmalltalk、１９７９年にはＣ＋＋など、オブジェクト指向言語も開発されていた。
しかし、オブジェクト指向アプローチが一般企業に普及したのは１９９０年代後半になってらである。１９９６年にオブジェクト指向の図法がＵＭＬとして統一されたことと、Ｊａｖａの正式版の公開、さらに１９９８年にJavaの開発環境であるＪ２ＳＥやＪ２ＥＥが提供されるようになったのが普及の大きなきっかけになった。
システム開発、特にプログラミングの観点では、オブジェクト指向は大きな思考の変化を要求した。プログラムを部品の組み合わせとしてとらえることは、構造化プログラミングでも行われていたのであるが、オブジェクト指向ではそれが徹底した。例えばJava言語を習得するには、個々の命令文の理解よりも、標準として提供される膨大なクラスを覚えることが重要になったのである。FORTRANを覚えるのにサブルーチン群まで暗記せよというようなものである。
オブジェクト指向プログラミングは、「入力があったら、在庫がなくなったら～をする」というように、何かが引き金になって処理を行うイベント駆動型である。これは、従来の手続き型言語での「入力するにはどうするか」を記述するのとは発想法から異なる。
そのため、従来の発想法が染み込んでいるベテランプログラマにとって、オブジェクト指向は心理的に大きな障壁があり、ベテラン不要論まで発生した。
ＵＭＬ記法は、ＤＦＤやＥＲＤに習熟している者にとっては理解しやすいし、ＵＭＬになるまでにＯＭＴやBooch法が知られていたので、あまり抵抗なく受け入れられた（ＵＭＬからコードを自動生成させるには、厳密な図法ルールに従って、詳細な記述をする必要があり、必ずしも容易とはいえないが）。
ＵＭＬは経営者や利用部門にも理解できる「可視化ツール」だといわれるが、ＤＦＤやＥＲＤと比べて機能が多彩なので、かえって説明が必要になる。いくつものＵＭＬを作成し、その間の矛盾が問題になることもある。
１９９０年代後半にＥＲＰパッケージによるシステム開発が普及した。その理由にはＢＰＲの実現、汎用コンピュータ環境からダウンサイジング環境への移行、海外事務所との連携、西暦２０００年問題への対応などがある。
ＥＲＰパッケージの導入は、システム開発に大きな打撃を与えた。これまでは、自主開発するか外注するかにかかわらず、独自の自社仕様による開発が通常であった。それが、ＥＲＰパッケージにより、システムは「作るから買う」へ変化したのである。
実際には、業務とシステムとのマッチングや既存システムとのインタフェースなど多様な作業があり、システム稼働までには、むしろ従来システムよりも多くの作業が発生したような例もあるが、論理的に極端にいえば、一般企業からシステム開発業務がなくなったのである。
１９９０年代末から２０００年代前半にかけて、Ｊ２ＥＥ、Eclipse、.NET Frameworkなどシステム設計からプログラム自動生成やデバッグまでを一貫してＧＵＩ環境で行うＩＤＥ（Integrated Development Environment、統合開発環境）が提供され普及した。２０００年代後半には、ＵＭＬの図からプログラムを生成するツールが普及した。文字通り Unified Modeling Language（言語）になったのである。
もはや、プログラミングはキーボードでソースコードを打つのではなくマウスで作成する時代になったのである。
インターネットの普及によりＷｅｂページを利用したアプリケーションが多くなった。それに伴い、ＨＴＭＬ内に記述できる言語、ＣＧＩで呼び出されるアプリケーションを作成する言語として、スクリプト言語（軽量プログラミング言語）が広く使われるようになった。
これらの言語は、既に１９９０年代に開発されていた。
１９８７年 ラリー・ウォール(Larry Wall）、Perl開発
１９９３年 まつもとゆきひろ、Ruby開発
１９９５年 ラスマス・ラードフ（Rasmus Lerdorf）、ＰＨＰ開発
１９９５年 ブレンダン・アイク（Brendan Eich）、JavaScript開発
１９９７年 JavaScriptがECMAScriptとして標準化
しかし、これらを使った本格的なシステム構築が普及したのは２０００年代に入ってからである。特に、２００５年にJavaScriptの非同期通信を利用した技術であるAjaxが開発され、グーグルやアマゾン・コムがそれを活用したアプリケーションを開発、そのＡＰＩを公表したことから、Ｗｅｂアプリケーション開発が急速に普及した。
Ｗｅｂアプリケーションは、当初は消費者向けのＷｅｂページに適用されたが、社内でのＷｅｂ化が進むに伴い、社内システムでもこのような仕組みが採用されつつある。現在はローカル的な分野が主であるが、そのうちに基幹業務系システムにも適用されるであろう。
ＨＴＭＬがベースになるので、本文のコンテンツが重要になる。消費者向けの受注システムなどでは、商品展示などのセンスが求められるので、プログラマだけで開発するのは困難である。そのため、開発体制が大きく変化してきた。
技術面では、取り扱うデータがＸＭＬが主流になってきた。それと従来型のデータファイルとの連携も必要になる。
ＥＲＰパッケージは、一般企業でのシステム開発をなくしたといったが、この動向は、２０００年代後半に起こったクラウドコンピューティングでさらに顕著になる。
インターネットのブロードバンド化により、社外サーバを利用した処理速度が急速に向上した。それで、ハードウェアだけでなく、アプリケーションやデータまでもプロバイダ側が持ち、自社にはクライアントだけを設置すればよい環境になったのである。
ＥＲＰパッケージでは、そのシステムは自社で所有していたのであるが、クラウドコンピューティングではそれらをプロバイダ側にゆだねることになる。すなわち、「所有から利用へ」の変化である。極端な表現をすれば、ＩＴは電気や水道のようなものになったのである。見方によっては、コンピュータ導入以前の情報センター利用への回帰だともいえる。
２００１年のＩＴ基本法により、電子政府・電子自治体が推進された。そのシステム化方法論として２００３年に「業務・システム最適化計画」が策定された。これは米国政府でのＥＡ（Enterprise Architecture）をベースにしたものである。業務と情報システムとの関係など上流工程を重視した方法論になっている。
ここでは、標準的な図法として、ＤＦＤ、ＥＲＤ、ＵＭＬなど各種図法の体系が示され、主に中央官庁を対象としたひな型が示されている。これらの図を描いたり相互関連をチェックするツールも提供されている。
これらは民間企業でも利用できる。全面的な採用をしている企業は少ないが、部分的に利用している企業は多い。
２００７年に「共通フレーム」が改訂された。ここでも「超上流工程」として、経営や業務と情報システムの関係を新たに取り入れている。
このように、一般企業でのシステム開発への関心は、下流から上流へ、さらに超上流へと移ってきたのである。それに伴い、システム開発の従事者がプログラマからＳＥへ、さらにアナリストや経営者へと変化してきたのである。
ＰＯＡ→ＤＯＡ→ＯＯＡ→ＳＯＡの流れは、部品化と再利用化への発展である。次第に部品の粒度が大きくなり、プログラム→システム→業務へと対象が広がってきた。
システム開発技法にはウォータフォール型やスパイラル型など多様な技法があるが、その主旨を実現するのはなかなか困難である。まさに「銀の弾丸はない」のである。
これは多分にＩＴ部門の任務と密接な関係がある。以前のＩＴ部門は、システム構築から運用までのＤＰ（Data Processing：データ処理）業務が主任務であった。それが、構築の下流工程や運用を社外に委託して、システム設計の上流工程だけを受け持つことになった。さらに、業務のあるべき姿を設計する超上流工程だけに絞り込むようになった。その社外に出す任務の拡大がシステム取得方法の変化になったのである。