スタートページ＞ 主張・講演＞ 経営者・利用部門のためのＩＴ入門＞ 第４章 個別システムの調達（２）
経営環境が激変し、競争が激化する環境に対処するためには、情報システムを迅速に立ち上げること、改訂が容易にできることが求められます。ここでは、そのための方法論や技術を概観します。
競争が厳しく、自社と同じようなビジネスモデルは他社も検討しています。それに遅れたのではビジネスチャンスを失います。逆に、他社が先行したならば、早急にそれに追従しなければなりません。
新しいビジネスモデルを実現するのに、ＩＴは不可欠なインフラですが、その情報システムの開発がネックになり、実現が遅れてしまうことがよくあります。それを回避するには、情報システム開発の短期化が重要です。レガシー時代では、１年・２年というような時間をかけて開発していたのですが、Ｗｅｂ時代では数週間・数か月で開発することが求められるようになりました。
経営環境が変化すれば、仕事の仕方も変わります。情報システムは仕事の仕方を規制しますので、情報システムの改訂が求められます。経営環境は激変しており、情報システムの対象分野が広くなったので、情報システムの改訂要求は頻発しますし、短期間での対応が求められます。
ところが、既存の情報システムは、頻発する改訂にその場しのぎのパッチ当てを繰り返している間に、複雑になってしまい、改訂作業が面倒になるだけでなく、その情報システムに長く従事したベテランでないと改訂できないような状態になっています。
このような事態を避けるためには、情報システムを開発する段階から、改訂が容易になるような工夫をしておくことが重要です。
例えば、定額給付金やエコポイントの政策を実施するには情報システムを短期間に開発する必要がありますが、その期間が終わったら不要になってしまいます。レガシー環境からオープン環境、Ｗｅｂ環境への移行やＥＲＰパッケージ導入には、データの変換や新旧システムのインタフェースなどのシステムが必要になりますが、移行作業が完了したら不要になります。
このような一時的にしか利用しない情報システムを、迅速に安価に構築することが求められます。
情報システムの調達方法が「作る→買う→使う」へと変化してきました。これは、衣服を誂えで作る、イージーオーダーで買う、レンタルで借りるのと似ています。早期に情報システムの稼働ができること、安価に構築できることなどの利点があります。
個別仕様による開発でも、開発の短期化や改訂の容易化のための方法論や技術が発展してきました。プログラム言語が昔の機械語やアセンブラから現在のオブジェクト言語やスクリプト言語になったように、ソフトウェア工学の発展の歴史は、開発の短期化や改訂の容易化の歴史だともいえます。
情報システム構築のアプローチでは、当初は実業務の担当者の作業をプログラム、それの入出力である伝票や帳票をデータと認識する「プログラム中心アプローチ」でした。プログラムが主、データはプログラムに付随する従の関係です。それでは、組織の変更、仕事の仕方の変更のたびに情報システムを全面的に改訂する必要になります。
それを回避するために、業務で必要となるデータを、その構造に着眼してデータベースを構築し、プログラムはそのデータベースを処理（更新・参照など）するものであり、業務の変更があってもプログラムだけを変えればよいという考え方になりました。データのプログラムからの独立であり、データが主、プログラムが従の関係になります。これを「データ中心アプローチ（ＤＯＡ）」といいます。
「オブジェクト指向アプローチ（ＯＯＡ）」では、データベースに標準的な処理を組み合わせたものをオブジェクトといいます。利用者（プログラマ）は、オブジェクトの内容を知る必要はなく、オブジェクトをアクセスする方法（メッセージ）だけを知っていればよく、メッセージを組み合わせるだけで、情報システムを構築できます。
最近では、ＳＯＡ（Service-Oriented Architecture）が注目されています。オブジェクトの単位を大きくして、「受注」「在庫確認」「出荷」のレベルにしたものをサービスといい、そのサービスを組み合わせることにより、情報システムを構築する方法です。
参照：「情報システム開発アプローチの変化」
これらの動きは、プログラムやデータの部品化による再利用だといえます。
昔からプログラムレベルでは、よく用いる処理をサブルーチンや標準パターンにして部品化し、多くのプログラムで再利用することが行われていました。ＤＯＡはデータの部品化であり、ＯＯＡはデータを含む処理の部品化、ＳＯＡは業務処理の部品化だといえます。
情報システムの開発技法も変わりました。
情報システムの開発は、要件定義→外部設計→内部設計→プログラミング→テストのプロセス（ライフサイクル）の手順で行われます。後工程に入ってから前工程の変更があると、手戻りが生じ、費用や納期に大きな影響を与えます。それを回避するために「前工程に関係者全員の承認がなれれば次工程に入るな」を絶対的なルールとするウォータフォール型開発技法が基本になっています。
ところがこの方法では、開発期間が長くなります。その間に環境が変化して、情報システムが稼働するときには時代遅れになることがあります。また、利用者は完成するまで実物を見ることができません。実物を見てはじめて要件を変更したくなることもあります。
環境変化が激しい分野ではウォータフォール型開発技法の欠点が致命的になります。それを回避するには、ライフサイクルを短期間でまわして、中間のプロトタイプを利用者に見せて修正を繰り返すことが効果的です。そのような開発技法として、スパイラル型開発技法やプロトタイプ型開発技法があります。さらには、期間を短期間に決めておき、その間で最大限の開発を行い、必要ならばそれを繰り返すという方法もあります。
現在では、対象業務の特徴により、これらの技法を選択あるいは組み合わせています。
参照：「情報システム開発技法」