その頃のソフトウェア開発ツールといえば、COBOLとFORTRANがすべてであったと言っても言い過ぎではありません。OS（Operating System）はすべてアセンブラ言語で書かれていた時代です。COBOLやFORTRAN言語は基本機能しか揃っていませんでしたから、システム開発には部品から構築する必要がありました。OSも今からは想像もできないほどプリミティブなものでした。それでも、多重プログラミングやマルチタスキングがあり、コンピュータをフル稼働させることができました。もちろん仮想記憶もありました。

　コンピュータの適用領域が広がり、システム開発コストを如何に削減するかが検討され、いろいろなツールが開発されました。

　例えば、データベースでいえば、CODASYL型のDBに代わるRelational型のDBが出現し、DBが扱いやすくなりました。

　ＯＳやコンパイラを作成する言語としては高級言語のカテゴリに入るシステム記述言語（例：C言語）が使われるようになりました。

　オンラインシステムの開発を容易にするためのパッケージソフトも開発されました。原理的には、現在の３tier構造（UI＋Processing+DB）をもつ各種ソフトウェア開発ツールと同じものです。

　更に、ソフトウェア開発支援ツールも開発されました。その中には、システム開発方法論（今で言うプロジェクト管理方法論）も用意されました。システム設計からテストまでを含むいわゆるWaterfall型の作業手順で工程毎に何を考え、どのような帳票で表現し、管理するかというようなことが書かれていました。当時の開発方法論は今日でも十分通用するものです。この方法論が前提としている開発支援ツールは画面設計ツールと帳票設計ツール、プログラム開発のパターンプログラミングツール、構造化COBOLなどが中心でした。

　当時の開発方法論の中心的な議論は構造化プログラミングでした。モジュール構造も盛んに研究されました。現在でも販売されている「ソフトウェアの複合/構造化設計」（Glenford J. Myers、近代科学社）は主にOSやコンパイラなど、基本ソフトウェアの世界で重視されました。私は当時門外漢でしたが、パッケージソフトの開発でも重要な考え方であったはずです。

　また、オブジェクト指向も研究が開始され、言語、データベース、システム設計方法論など幅広い領域で研究され、今日では概ねJ２EEや.NETなどの製品として体系化され、ほぼ研究は一段落しているようです。

　この当時の開発方法論はWaterfall型でした。大型システムの開発では品質問題に悩んでいましたから、がっちりとしたWaterfall型開発方法論の開発は当然の取り組みでした。最近、Waterfall型の方法論は重量級の方法論と言われています。この方法論はシステムの要求仕様がしっかりと固まっていて、途中で仕様変更がない、高品質のシステム開発に向いています。しかし、要求仕様がなかなか決まらないシステム開発には向いていないのです。要求仕様に変更があると、それまでの膨大な作業のやり直しを迫られ、予定した開発予算を大幅に超えてしまう可能性があるからです。

　そうしたことを背景に、新しい考え方の、軽量級の開発方法論が開発されるようになりました。その代表例がＸＰ（eXtreme Programming）です。顧客の要求を直ぐにプログラミングして、実現して見せ、その繰り返しでシステムを構築するという方法論です。これが可能となった背景にはシステムインテグレーションの方法が容易になったという技術的背景があります。プログラムがリンケージローダあるいはリンケージエディタと言われるツールで統合する作業が不要になったのです。ダイナミックリンクあるいはダイナミックロードという技術が確立され、プログラムを動的に組み込んでいくことが可能となったため、少しずつプログラム開発を積み重ねながら、システム統合することができるのです。この方法論にも弱点があります。それはシステム開発が何時終わるか約束できない点です。

　機能と品質が絶対重視される領域のシステム開発には重量級の開発方法論が向いています。重量級の開発方法論を採用する場合、要求仕様を定義することに時間をかけ、一旦決まったならば、なるべく仕様変更はせず、予定時期を守ることに顧客も開発者も重点をおく必要があります。要求変更が頻繁に起きるようならば、プロジェクトは完全に失敗します。

　顧客の要求がなかなか決められないならば、軽量級の開発方法論を採用し、出来栄えを確認しながらシステムを開発するのが適しています。この場合、開発される機能は、予算と期間に合わせて決まることになります。

　このように、システム開発の方法論は概ね重量級と軽量級の２種類に分けられますが、皆さんが関係するシステムの開発にそのどちらを採用するのが良いのかは、プロジェクトの状況により様々です。

　最近、アジャイルソフトウェア開発という概念がでてきました。これは、システム開発を定型の開発方法論を採用して開発することは困難だという考え方に立っています。開発方法論そのものをプロジェクト毎に開発して、システム開発を行う考え方です。とは言ってもゼロベースで開発方法論を開発するのではなく、CMMIやPMBOKなどの方法論を念頭において、自分達の開発プロジェクトに最も適した方法論を設計する必要があります。

　自分達のプロジェクトに適した開発方法論を開発したとしても、方法論は一つの型です。型を重んじる余り、実践する人達の人間的要素を無視していては失敗します。ソフトウェア開発という仕事は職人的要素を含んでいます。これはソフトウェア開発に限った話ではないのでしょうが、私の専門分野以外でも同じだと断言はできません。確信を持って言えるのは、ソフトウェア開発は職人的仕事だということです。このことについては「ソフトウェア職人気質」（Pete McBreen、ピアソン・エデュケーション）に良く書かれています。我々日本人は比較的職人的なものの考え方をします。この本は欧米人によって書かれましたが、日本人に広く受け容れられる本であると思います。

■