システム開発技法

情報システム開発の区分

販売システムや会計システムのような個別の業務システムを構築するのに，いくつかの切り口で区分すると次のようになります。

調達方法による区分

自社仕様による開発

注文で洋服を作る場合と同じように，自社独自の仕様で情報システムを開発します。自社の要望に合致したシステムになりますが，構築をするために多大な費用や時間がかかります。
小規模なシステムでは自社の情報システム部門が内製することもありますが，通常はソフトウェア会社（「ベンダ」といいます）に外注します。そのとき，要件のとりまとめからプログラミングまでの一切を依頼することもあるし，仕様までは自社で作成してプログラミングの部分だけを外注することもあります。

市販パッケージによる開発

イージーオーダーのように，既成の情報システム（「パッケージ」といいます）を購入し，部分的には自社に合うように修正（これを「カスタマイズ」といいます）して利用する方法です。自社の要望を完全に満たすことはできませんが，費用も時間も節約できる利点があります。
中小企業での非常に小さいシステムであれば，パソコン用の会計ソフトや販売管理ソフトなどが市販されています。一方，大企業の全社的な業務を統合したものには，ＥＲＰパッケージがあります。自社の環境に合わせるためにはカスタマイズが必要ですが，多くのカスタマイズをすると費用も時間もかかり，パッケージの利点が得られなくなります。

以降では自社仕様による開発に限定します。

アプローチによる区分

システムを構築するのに，何に注目するのかが大きな区分になります。

ＰＯＡ：プロセス（プログラム）中心アプローチ

新入社員にある部門の仕事を説明するとき，「○○係の仕事は△△の伝票がきたら◇◇の処理をして☆☆の帳票を作る」というように，係（プロセス）を対象にして，伝票（入力データ），帳票（出力データ）を示し，その処理手順（プログラム）を教えるのが通常です。このようにして開発したシステムは，プロセスやプログラムが中心でデータはその付属物となります。
このようなアプローチはわかりやすいので，初期の頃はこれが唯一のアプローチでした。それで特に名前はありません。このＰＯＡは正式な名称ではありません。他のアプローチを区別するために便宜的につけた名称です。
ところがこのようなシステムは，組織変更や仕事の変更が起こるたびにシステムを改訂しなければなりません。これはシステムとして致命的な欠点ですので，現在ではあまり使われていません。

ＤＯＡ：データ中心アプローチ

これに対してＤＯＡ（Data Oriented Approach）は，システム化対象の業務で必要とするデータの構造に着眼します。販売システムを例にすれば伝票には「年月日」「得意先」「商品」が記載されており，商品には「商品区分」や「仕入先」，得意先には「住所」などがあるという構造があります。ＤＯＡでは，その構造に従ったデータベースを中心にして，それの創生，更新，参照などの操作（処理，プログラム）を従の位置づけにします。
このようなデータ構造は，取扱う商品や組織に変更があってもあまり影響を受けません。そのために，環境変化に対して安定したシステムにすることができます。しかも，そのデータベースはＲＤＢ（リレーショナル・データベース）は，利用者にとっても使いやすいものになっています。それで，現在ではＤＯＡが主流になっています。

ＯＯＡ：オブジェクト中心アプローチ

ＤＯＡにも欠点があります。自動車のデータを例にしますと，「車種」「重量」「エンジン」など共通項目以外に乗用車では「座席数」や「内装」などの項目が必要ですし，トラックでは「積載量」や「荷台」などが必要です。ＲＤＢでは，乗用車とトラックで別々のデータベースにすると，「自動車出荷台数」とか「エンジン個数」などを求めるのに不便ですし，自動車全体のデータベースを作ろうとすると，乗用車・トラックでは不要な項目が多くなってしまいます。また，プログラムでも当初は通常販売だけだとしてシステムを作成したのに，その後レンタルやリースなどが加わると，それぞれのプログラムを大幅に変更する必要があります。

ＯＯＡ（Object Oriented Approach）では継承（インヘリタンス）という概念があり，乗用車のデータあれば，乗用車やトラックのデータは，それ特有のデータ項目だけを定義すればよいし，販売のメソッドがあればレンタルやリースは販売との違いだけを記述すればよいのです。このように，状況変化に柔軟に対応することができます。
また，ＤＯＡ／ＲＤＢでは，ＲＤＢを更新する手続きは多数のプログラマが記述しますが，それにはプログラマがＲＤＢの仕様を知る必要がありますし，なかには間違ったデータで更新してしまう可能性もありデータベースの品質を保証することができません。ＯＯＡではデータとそれをアクセスするメソッドをオブジェクトといい，そのアクセスする手段だけを見せて内部を隠蔽する（「カプセル化」といいます）ので，これらの欠点が解決できます。
このＯＯＡは，Ｊａｖａのようなオブジェクト指向言語やＵＭＬ（Unified Modeling Language）というシステムの図式法（プログラムの自動生成機能もある）が普及してきたことから，急速に広まってきました。特にこのＵＭＬの基礎的な知識は利用部門の人も必要になると思われます。

開発プロセスによる区分

開発プロセスとは，情報システムの開発をいくつかの工程にわけて，それをどのように実施するかを定めたものです。このなかのいくつかについては後述します。

ウォータフォール型

システム開発のライフサイクルの各工程を，前工程が完全に完了して承認を受けてからはじめて次工程に進むという，最もオーソドックスな方法です。しかし，これはシステム開発に時間がかかり，利用者は最後になってはじめて実物に接するという大きな欠点がありますので，環境変化が激しい分野への適用が問題視され，以下のような方法が出現してきました。

イタラティブ型

これには，スパイラル型とプロトタイピング型があります。前者はシステム開発のライフサイクルを短期間で繰り返し（イタラティブに）行うことによる方法であり，後者は早期に見本（プロトタイプ）を見せ逐次改善していく方法です。厳密には異なりますが，実質的には同じような方法であるといえます（後述）

インクリメンタル型

大規模なシステムを同時に完成させるのではなく，そのうちの共通部分や主要部分だけを短時間で構築し，その後周辺の部分を順次追加開発する方法です。

アジャイル型

規模に関係なく先に期間を設定しておき，その期間中で必要な機能を持ったシステムを構築するという意味と，高度な知識と権限を持つ少数（極端には開発者と利用者の２名）が優れた開発環境で短期間に構築するという意味があります。どちらも同じような形態になりますが，前者を重視したものにＲＡＤ（Rapid Application Development），後者を重視したものにＸＰ（eXtreme Programming）などがあります。

システム開発のライフサイクル

システムの開発は，おおまかに，要求分析→外部設計→内部設計→プログラミング→テスト→実施の順序で行なわれます。これをシステム開発のライフサイクルといい，各段階をフェーズあるいは工程といいます。また，厳密ではありませんが，要求分析と外部設計を上流工程，内部設計以降を下流工程ということもあります。

要求分析（基本計画）

既に全体の情報化計画の検討時にこのシステムの目的や機能概要は検討されているはずですが，その段階では細かい事項までは検討されていません。システム設計を開始するこの工程で，具体的に要求を収集して分析することにより，どのような要件をシステムに取り込むかを決定するのです。これらに最も関係するのは利用部門ですから，このプロセスでは利用部門が主体になるのは当然です。

外部設計

システムへの要求を整理したら，開発すべきシステムについて，利用者の観点から設計し，それを関係者全員で確認をします。この段階でシステムが持つ機能や開発費用などが把握できますので，そこでこのシステムを構築するかどうかの決定が下されます。ここでの「外部」とは，コンピュータを「内部」とした意味であり人間を対象とした設計という意味です。業務を中心とした記述にすることが必要ですから，この仕様書は利用部門が作成するのが望まれます。

内部設計

外部設計を受けて，実際にプログラムを作る観点から，データベースの設計や処理ロジックの設計など詳細な設計をします。ここでは高度な情報技術知識が必要ですので，情報システム部門が中心になります。しかし，入力画面・出力帳票の設計などのヒューマンインタフェースに関係する部分や，得意先コードや商品コードなどのコード体系の設計の部分は，利用部門が行なうほうが適切です。

プログラミング

内部設計に従ってプログラムを作る工程です。この工程は情報システム部門（あるいはベンダ）が行ないます。しかし，得意先マスタや商品マスタなどのデータの作成は利用部門が行なうのが適切です。

テスト

プログラムには誤り（バグという）があります。プログラムの文法的なミスはプログラミングの段階で簡単にチェックできますが，システム設計があいまいであったりプログラマが誤解していたりするミスは，実際にテストデータを使ってテストして確認しなければなりません。これは情報システム部門から利用部門への引渡し検収工程でもありますので，テストデータの作成やテスト結果の確認は利用部門が行なうべきです。

実施移行

テストに合格したら，実際の業務をシステムに移行します。それには，実際に利用する人たちへの説明や訓練をする必要があります。

ウォータフォール型開発技法

たとえば，家を建てるにに，棟上をする段階になってから間取りの変更などをいわれたら，基礎工事からやり直さなければなりません。設計図を作成する段階にいわれたのと比較すれば，非常に大きな時間やコストがかかります。システム開発でも，各工程において，前工程に誤りがあるとか検討不十分なままに後工程に進むと，それを修正するためには非常な労力と費用がかかります。開発全体の生産効率を向上させるには，手戻りをしないようにすることが大切です。

ウォータフォールとは滝のことです。滝が上流から下流へ一方的に流れ逆流しないように，各工程の完了時点で関係者全員が文書により十分な確認をするまでは次の工程に入らないにすることにより，手戻りを未然に防ごうとする技法です。この技法は適切に管理できれば非常に効率的ですし，責任も明確になります。それで，従来はこれが最良の技法であるとされてきました。最近は後述のように欠点が指摘されてはいますが，環境が比較的安定した大規模業務を対象としたシステム開発では，この技法が広く用いられています。

ウォータフォール型開発技法の限界

ウォータフォール型開発技法は優れた技法ですが，対象とする業務が複雑であったり，企業競争が激しく経営環境が激変したりする場合では，大きな欠点が指摘されるようになりました。

利用者への提示と再要求

利用者はシステム設計の概念になれていないので，要求段階でいかに要求事項を検討しても実物が見えないので，十分な要求が出なかったり，関係者間で誤解をしたりすることがあります。外部設計の承認をしたとしても，具体的な内容がわからないままに承認をすることもあります。その結果，実施段階になってから要求が追加されたり，誤解をしていたことが発見されたりすることがよくあります。

環境変化への対応

前工程が完全に完了しないと後工程に進めないので，全体の工程が完了するまでには長期間がかかってしまいます。企業競争が激しい今日では，立案してから実施するまでに長期間を要すると，タイミングを失したり，他社に先行されたりする危険があります。また，いかに各工程で確認をして手戻りをしないようにしても，長期間の間には経営環境が変わってしまうので，要求分析の段階で確認したシステムが実施段階になったときには，すでに時代遅れのものになってしまう危険があります。

プロトタイピング，スパイラル型開発技法

ウォータフォール型開発技法の欠点を解決しようとする開発技法に，プロトタイピング型開発技法やスパイラル型開発技法があります。

プロトタイピング型開発技法とは，当初から完成されたシステムを作るのではなく，簡単なプロトタイプ（見本）を短期間で作成し，それを検討することにより，要求を明確にする技法です。スパイラル型開発技法とは，上述の開発工程を図２−１のようにスパイラル（らせん）のように短期間で繰り返すことによって，逐次改善して満足できるシステムにしていく技法です。プロトタイプを改善することを重視するか，工程を短期間で繰り返すことを重視するかで，呼び方は異なりますが，本質的には同じだと考えてもよいでしょう。

最近のシステム環境では，画面からデータを入力してデータベースを更新し，画面から指示して帳票を画面表示させるようなシステムが多くなってきました。このようなシステムでは，ヒューマンインタフェースとしての画面操作が重要になります。システム開発者が画面操作のプロトタイプを作成し，利用者がそれを試用して改善点を指摘し，開発者がさらにプロトタイプを修正して提供するというようにスパイラル的に作業を進めます。このような方法は，ＣＳＳ（クライアント・サーバ・システム），ビジュアル開発環境などの開発環境の発展により，急速に普及してきました。

プロトタイピング型開発技法の利点と欠点

利用者と開発者が画面を囲んで作業するので，両者の交流が円滑になります。利用者に常に最新の見本が示されるので，システムをよく理解できるし，適切な要望が出せるし，開発者が誤解することが少なくなります。それにより，後工程になってから前工程に戻るというような問題が解消します。プロトタイプ段階であっても，実用に使えるようになったら，実施に踏み切ることができます。利用者は開発段階からシステムに直接に関与しているので，実施段階になってから教育をするような必要がありません。すなわち，計画から実施までの期間を短縮できます。

しかし，次のような欠点もあります。

• 利用者が完全主義で次から次へと要求を出すと，いつになってもシステムが完成しないことがあります。なかには趣味的な要求により，複雑なシステムになってしまうこともあります。
• このような共同作業は少人数でないとできないので，大規模なシステムでは多くのグループにわかれて作業することになりますが，このような作業環境では担当者だけで物事を決定しがちですので，全体として統一のとれないシステムになる危険があります。