本章では、基幹業務系システムの開発を対象にします。最近のように企業環境が激変する状況では、将来の改訂が容易なシステムにすることと、利用部門が積極的に情報システムに関与することが重要です。これが本章全体を貫く認識であり課題です。
システム開発は、システムへの要件定義から始まります。それには、現状改善を重視する帰納的アプローチと、理想的な姿を求めて抜本的な改革を重視する演繹的アプローチがあります。また、システムを構築する基本的なアプローチにプロセス中心アプローチとデータ中心アプローチがあります。また最近は、オブジェクト指向アプローチが注目されています。
実際のシステム開発の方法として、要件定義から実施にいたる各プロセスに厳密に従うウオータフォール型開発技法、これらのプロセスを短期間に繰り返すプロトタイピング型開発技法やスパイラル型開発技法、限定された期間内で最大の効果をあげるＲＡＤなどがあります。また、自社開発をせずに、市販パッケージを購入することも普及してきました。
情報システムを開発するには、情報システム部門と利用部門からなるプロジェクトチームを編成します。ここでは特に利用部門の任務を取り上げました。利用部門は、要求定義を明確にすること、マスタファイルやテストデータの作成などでプロジェクトの中心になる必要があります。
１ 情報システムの限定と情報システム開発での課題
本節では、本章で対象とする情報システムを基幹業務系システムに限定します。企業競争が激甚で経営環境が激変する状況では、基幹業務系システムの開発において、改訂を容易にできるようなシステムにすることが重要な課題になります。また、最近の情報技術の利用動向は、利用部門が情報システム開発にますます積極的に参加すべきことを示しています。
（１）本章で取り扱う情報システム
情報システムの利用形態には、データウェアハウスのように情報検索や分析を目的とする分野やグループウェアのように情報の伝達や共有化を分野もありますが、本章では、基幹業務に適用した情報システム、いわゆる「基幹業務系システム」を対象にします。
基幹業務系システムにも、メインフレームを中心にしたもの／クライアント・サーバの環境によるもの、社内を対象としたシステム／企業間ネットワークを活用したシステムなど多様な形態があります。これらの形態の違いにより、開発や運用における問題点も異なることが多いのですが、ここではその違いには触れずに、一般的な事項について記述します。
（２）経営環境によるシステム開発への要望
情報システムの開発では、経営戦略に合致していることが重要であり、特に基幹業務系システムでは、正確であること、迅速に処理されること、開発や運用にかかる費用が安いことなどは当然の要望です。
しかし、現在の経営環境では、このような基本的な事項に加えて、次のような事項が重要になっています。
① 開発期間の短縮
情報システムは企業競争の武器だといわれています。その競争で優位な立場を確保するには、情報システムを他社に先んじて構築して活用することが必要です。それには、企画してから実施するまでの期間を短縮することが必要です。
② 改訂の容易化
情報システムは企業のすみずみにまで浸透しており、経営環境は激変していますので、情報システムへの改訂要求は頻度も多く、しかも短期間での対応を要求されます。
（３）利用部門の参画
情報システムは、利用部門の業務そのものを対象としており、活用されてはじめて効果を生じるものですから、情報システムの開発に利用部門が積極的に参画する必要があるのは当然です。このようなことは、コンピュータがビジネスに利用されはじめた頃からもいわれていたことですが、近年、この重要性はますます増大してきました。
① 情報システムが現場活動に密着してきた
在庫を圧縮して製品コストを下げつつ、受注から納入までの期間を短縮して顧客満足を図ることは、利益確保や他社との差別化に大いに役立ちます。自社内だけでなく、供給企業や流通企業までも含めたシステムとして、ＳＣＭ（サプライ・チェーン・マネジメント）が注目されています。
ＳＦＡ（セールス・フォース・オートメーション：営業活動支援システム）は、営業活動の情報武装です。モバイル・コンピューティングにより、外出先でオフィスと同様な情報利用環境を実現します。また、コールセンターは顧客が何を望んでいるかを把握したり、訪問する得意先の情報を的確にセールスに伝えます。
このように、最近の情報システムは、経営戦略にますます密着してきましたし、それが現場の行動にも大きな影響を与えるようになってきました。
② 情報システムが業務改革に密着してきた
ＢＰＲ（ビジネス・プロセス・リエンジニアリング）など業務改革が大きな課題になっています。その実現には、情報システムが必要になります。逆にいえば、情報システムは組織改訂や業務改革を目的とするための手段であるという認識が高まってきました。
ＥＲＰ（エンタープライズ・リソース・プランニング）パッケージは企業統合パッケージとも呼ばれますが、ＢＰＲでの成功企業のノウハウなども取り込んだパッケージであり、業務に合わせて情報システムを構築するのではなく、パッケージに合わせて業務の仕方を変えるべきだとさえいわれるようになってきました。
２ システム開発の基本的アプローチ
システムを開発するには、システムに求める要件を決めることが必要ですが、それには、現状改善を重視する帰納的アプローチと、理想的な姿を求めて抜本的な改革を重視する演繹的アプローチがあります。
要件が決まってからシステムを開発するアプローチでは、仕事の仕方やプログラムを中心とするプロセス中心アプローチと、対象業務で必要となるデータを洗い出して、データ構造を中心にシステムを設計するデータ中心アプローチがあります。また最近は、データやプログラムを部品としてとらえ、その再利用により、低コストで高品質のシステムを作るオブジェクト指向アプローチが注目されています。
（１）帰納的アプローチと演繹的アプローチ
一般に物事を考えるときの方法には、現在の状況を前提として、それを改善する方法と、あるべき姿を描いて、それを実現するにはどうするかと考える方法があります。システム開発において、どのようなシステムを作るかを検討するときにも、同様に２つのアプローチがあります。
その一つは、帰納的アプローチです。現在行っている仕事の仕方を調査するとともに改善意見を聞きだして、それをシステムとして実現するアプローチです。開発要件を現場から積み上げるので、ボトムアップ・アプローチともいいます。もう一つは、演繹的アプローチです。まず理想的なシステムとはどのようなシステムを考え、それを実現するにはどうするかというように、理論的に考えます。大所高所から細かい事項に展開するのでトップダウン・アプローチともいいます。
どちらのアプローチにも一長一短があります。帰納的アプローチでは、現状の改善ですから、利用部門の同意も取りやすいし、着実な改善ができますが、抜本的な改革を行うのには不向きです。それに対して、演繹的アプローチでは、自分が考えたり調査したなかで最も優れたシステム（これをベスト・プラクティスといいます）を目標としますので、それが実現したときには、大きな成果が期待できます。ＢＰＲ（ビジネス・プロセス・リエンジニアリング）の考え方に基づく戦略的なアプローチだともいえます。それで、最近ではこのアプローチが採用されることが多くなってきました。しかし、このアプローチでは、現状とかけ離れたシステムになる危険もあるし、現場の同意を得られない危険もあります。それで、このアプローチで成功するには、かなり強力なリーダーシップが必要になります。
実際には、一方のアプローチだけで行うのではなく、帰納的アプローチのときには、常に全社的な経営戦略と合致しているかをチェックするとか、演繹的アプローチでは、現場からの参加を重視して、常に理想と現実の間の調整を図るなどの工夫をすることが大切です。
（２）プロセス中心アプローチとデータ中心アプローチ
システムの全体像が決まり、実際にシステムを設計するときにも２つのアプローチがあります。
古典的なシステム設計論では、ＰＯＡ（プロセス中心アプローチ）という方法でした（この方法が唯一の方法論だった頃は、このような名称もなかったのですが）。実際に各担当者が手作業で行っている仕事の仕方（プロセス）を調べて、あるいはベストプラクティスなプロセスを描いて、それをシステムとしてどう実現するかというアプローチです。ＰＯＡでは、仕事の仕方がプログラムであり、データはそのプログラムでの入力および出力という位置づけになります。すなわち、プログラムが主で、データファイルはその補助的な存在ということになります。それで、ＰＯＡはプログラム中心アプローチであるともいえます。
ＰＯＡは、新入社員に仕事を教えるのと同じような方法ですから、わかりやすい方法です。しかし、経営環境が激変し、システムの改訂が頻繁になり、しかも短期間で対応することが要求されてくると、ＰＯＡの欠点が問題になりました。ＰＯＡでは、仕事の仕方であるプログラムを基盤としていますが、経営環境が変わると、これは大きく変化してしまいます。プログラムが変われば、それに付随するデータファイルも大きく変化してしまいます。すなわち、ＰＯＡでは、経営環境の変化があると、システムを全面的に改訂しなければなりません。
データファイルをプログラムから独立させることができれば、このような改訂が容易になります（データベースにすることにより、データの重複が少なくなるとか、データの管理が容易になるなどの効果もあります）。この考えを押し進めたのがＤＯＡ（データ中心アプローチ）です。ＤＯＡでは、システム化対象の業務では、どのようなデータが必要かを調べ、その関係を明確にします。たとえば販売システムでは、商品、得意先、納入先、売上などの項目が必要ですが、これらをエンティティといいます。また、「各得意先は複数の納入先を持ち、各納入先は唯一の得意先に属する」とか、「売上データは得意先、商品、年月日で決まる」というように、エンティティ間には関係があります。これをリレーションシップといいます。エンティティとリレーションシップを明確にする図法をＥＲモデルといいますが、その例を図１２－１に示します。このようなデータの構造は、ある程度の経営環境の変化では変化しません。すなわち、ＤＯＡによって構築されたシステムは、環境変化に関して安定しているので、改訂が容易であるといえます。
図１２－１ ＥＲモデルの例
（３）オブジェクト指向アプローチ
最近はＯＯＡ（オブジェクト指向アプローチ）が注目されています。ＤＯＡはデータ構造を独立させることにより、データを部品として、多くのシステムで再利用する効果がありました。ＯＯＡでは、データだけではなく、それをアクセスするプログラム（メソッドといいます）を一体化（カプセル化といいます）したものをオブジェクトとして部品化します。すなわち、ＯＯＡでは部品としてのオブジェクトを作成し、それを組み合わせることによりシステムを構築します。
たとえば、図１２－２に示すように、乗用車というオブジェクトとトラックというオブジェクトは自動車というオブジェクトの一部分です。このとき、自動車をスーパークラス、乗用車やトラックをサブクラスといいます。スーパークラスで定義した事項（エンジンやタイヤなど）は、サブクラスである乗用車やトラックに引き継がれます（これをインヘリタンスといいます）ので、サブクラスでは乗員数や荷台などの特別な事項だけを定義すればよいことになります。これにより、部品としての機能がさらに強力になります。
従来は、ＯＯＡは設計論が確立していないとか、適切な開発ツールやデータベースがないなどの理由で、大規模システムの適用が遅れていましたが、最近はこのような分野への適用例も出てくるようになり、将来の発展が期待されています。
図１２－２ スーパークラスとサブクラスの例
３ システム開発技法
ここでは、実際にシステムを構築する段階を取り扱います。システム開発には、要件定義から実施にいたる各プロセスがありますが、たとえば、実施段階になって設計段階での不備が発見されたというように、下流工程から上流工程に手戻りすると、多くの労力と時間がかかります。そのプロセス忠実に実行するウオータフォール型開発技法が基本的な技法ですが、経営環境が激変する状況では限界があります。
それを解決する技法に、プロトタイピング型開発技法やスパイラル型開発技法があります。提供者と利用者が一緒になって見本を逐次改善する技法です。また、開発期間を限定して、その期間内で最大の効果をあげるＲＡＤという技法も出てきました。
さらに、システムを自社作成するのではなく、市販パッケージを購入することにより、安価に短期間でシステムを構築することも普及してきました。
（１）システム開発のライフサイクル
システム開発の方針が決まってから、実際にシステムを稼働するまでのプロセスは次のようになります。
①要件定義
システムで実現すべき要件をまとめるプロセスです。帰納的アプローチやＤＯＡなどのアプローチにより要件を整理します。
②外部設計
実現すべきシステムの仕様について、特に利用者の立場から記述します。これの承認により、システムの仕様が関係者間で確認されたことになります。
③内部設計
外部設計に基づき、次のプロセスであるプログラミングに渡せるように、コンピュータ処理の立場での仕様を記述します。
④プログラミング
この段階で、プログラムを実際に作成します。必要に応じてデータの作成もします。
⑤テスト
プログラムのテストです。プログラム単体のテストからシステム全体のテストまでを行います。
⑥移行実施
機器の設置、利用者への説明、手作業との併行処理などを行い、実施に移行します。
（２）ウオータフォール型開発技法
上記のプロセスにおいて、前工程の作業が不十分のままに次工程に入ると、後になってから新しい要求が出てきたり仕様が変更になります。家を建ててから木造を鉄筋にするのでは、最初から作り直さなければならないように、手戻りをすると、非常な労力や時間がかかります。
ウォータフォール型開発技法では、図１２－３に示すように、ウォータフォール（滝）が上流工程から下流工程に一方的に流れて逆流しないように、各プロセスごとに確認書を作成し、その承認を得てから次工程へ進むようにした開発技法です。この方法は効率的であり、責任も明確になり、文書化が徹底されますので品質管理も円滑にできます。このような理由により、あまり環境変化のない大規模なシステムでは、現在でも広く採用されています。
しかし、この技法にも限界があります。要求定義や外部設計の段階以降から移行実施に至るまでの間は仕様が凍結されます。経営環境が激変している現在では、その間に要求も大きく変化し、実施になった段階では、既に時代遅れになってしまいます。また、いかに要求定義や外部設計での検討があったにせよ、システムに素人である利用者は、実物を見てからはじめて要求を出したりします。すなわち、実施段階になってから要求定義に戻るという大きな手戻りをすることにもなります。
図１２－３ ウォータフォール型開発技法の限界
（３）プロトタイピング型開発技法とスパイラル型開発技法
このようなウオータフォール型開発技法の限界を解決するために、プロトタイプ型開発技法が出てきました。この技法では、ある程度要件が出た段階でプロトタイプ（見本）を作成します。それを利用者が見て、新しい要求や変更要求を出します。開発者は、その意見を採り入れて、短期間にプロトタイプを改訂します。このように、要求定義から実施までのプロセスを短期間で行い繰り返して逐次改善をします。その間に満足できる段階に達したら実施になります。
このとき、プロトタイプを作ることを重視したのがプロトタイピング型開発技法であり、スパイラル（らせん）のように繰り返すことを重視したのがスパイラル型開発技法です（図１２－４）。
図１２－４ プロトタイピング型開発技法とスパイラル型開発技法の図
これらの技法を可能にしたのが、パソコンやクライアント・サーバ・システムにおけるビジュアル環境でのシステム開発です。コンピュータを利用してシステム開発する技術をＣＡＳＥといいますが、最近は使いやすいＣＡＳＥツールが多く利用できるようになりました。このような環境により、提供者と利用者がパソコンの画面を見ながら、システムを具体的にチェックすることができるようになりました。
これらの技法にも限界があります。この環境では一つのチームは少人数になるので、プロジェクトは多くのチームになりがちですが、そうなるとチーム間の進捗調整が困難になります。さらに、利用者が細かいことにこだわったり、自分の趣味を主張すると、無限のスパイラルになり、いつになってもシステムが完成しないことにもなります。このように、全体のバランスがとれないシステムになる危険があります。
（４）ＲＡＤ
無限スパイラルなどの危険を回避するためには、開発時間を決めて、その間に最大の効果を実現する方法が考えられます。それがＲＡＤ（ラピッド・アプリケーション・デベロップメント）です。
ＲＡＤは、大規模システムでも、ほんの数人の優れた提供者と利用者を中心として開発されます。彼らには最高の開発環境を与え、システムに関する大幅な権限を与えます。そして、データの作成やテスト、マニュアルの作成などの付帯的な仕事はアシスタントに任せ、開発だけに専心させます。このような考え方は、かなり以前から外科医チームとして知られていましたが、それが開発環境の発展により、さらに有効な方法になったのです。
ＲＡＤの限界としては、その中心となる人材が得にくいことにあります。アシスタントもその分野での専門家でないと円滑にプロジェクトが進みません。
（５）パッケージの購入
ここまでのシステムは、自分で作ることを前提としていました。しかし、会計計算や給与の年末調整の計算などは、どこの企業でもほぼ同じ処理をしているのですから、個々の企業が独自に開発するよりも、誰かが一般的なシステムを作成して、それを多くの企業が購入して使えば、労力もかからず費用も安くシステムを利用することができます。このような市販ソフトウェアのことをパッケージといいます。
従来のパッケージは、単独の業務を対象にしたものがほとんどでしたが、最近では、企業全体の業務を対象とした統合業務パッケージが注目され普及してきました。このようなパッケージをＥＲＰ（エンタープライズ・リソース・プランニング）パッケージといいます。これによりＢＰＲの実現や、業務の世界標準化などの効果も期待されています（ＥＲＰについては、第１９章で詳述します）。
パッケージを自社の環境に合わせるように部分的な修正をすることをカスタマイズといいますが、カスタマイズを多くすると労力や時間がかかり、パッケージの利点が損なわれます。それで、パッケージに仕事の仕方を合わせることになりますので、利用部門の積極的な参加が必要となります。
４ 情報システム開発の運営
情報システムを開発するには、情報システム部門と利用部門からなるプロジェクトチームを編成します。とかく基幹業務系システムの作成では、情報システム部門が主体で開発するように思いがちですが、利用部門の積極的な参加が重要なのです。特に要求定義では、要求の明確化、全体最適化、費用対効果、業務の合理化、ＥＵＣの活用などの視点が重要です。マスタファイルやテストデータも利用部門が作成します。また、プロトタイピング型の開発では、利用部門も情報システム部門と同様な作業をすることになります。
（１）開発プロジェクトの編成
プロジェクトチームの体制は、開発すべき情報システムの対象範囲、重要性、規模などにより異なりますが、ここでは、会計システムの改訂のようなケースを想定します。
プロジェクトの最高責任者（オーナー）には経理部長（あるいはそれに準ずる者）がなります。利用部門が情報システムの依頼主であり利用者なのですから、最高責任者は利用部門の上位者とするのが適切です。
プロジェクト全体のリーダには、情報システム部門のベテランＳＥ（システム・エンジニア）がなります。対象システムの規模や重要性に適した力量のある者を選出します。
プロジェクトメンバーは、情報システム部門と対象の利用部門の者が中心になりますが、それ以外に必要に応じて他の関係部門も参画します。また、ある程度の規模になると、自社要員だけでなく社外のソフトウェア会社に外注することが多く、それもメンバに加わります。中核となるメンバは開発の全プロセスを通して参画しますが、それ以外のメンバは、各プロセスにより増減したり、メンバの変更をします。
情報システム部門や外注先のメンバが行うべき事項は比較的明瞭ですので、以降では利用部門について記述します。情報システムは活用されてこそ価値を生じるのであり、業務をよく知り問題意識を持っているのは利用部門ですから、情報システムの開発に利用部門が積極的に参画することが重要です。
（２）要求定義における利用部門の役割
要求定義の段階では、利用部門が中心になりますが、このときに、必要なことを列挙します。
① 要求の明確化
要求定義が不十分のまま開発に入ると、手戻りが生じて多大な時間とコストを浪費することになります。この段階で要求を明確にすることが重要です。
② 効果の測定尺度
このシステムによって、何がどう改善されるか、その効果はどの程度かを明確にするために、測定尺度を決める必要があります。「販売での納期遅れが現在では××％であるが、このシステムが実現することにより、○○％に減少させることができる」というようなことです。そして、○○％を実現するのは利用部門の責任ですし、それを可能とする要求定義をしなければなりません。
③ 全体最適化
たとえば、納期管理システムで、納期遅れを減少させるために在庫が増加したのでは困ります。自分の部門の都合をセクショナリズムに主張するのではなく、全社的な観点による目標設定が重要です。
④ 費用対効果
熱心なメンバーは、いろいろな改善点を見つけます。重要なものも多いでしょうが、なかには「あればないより便利」のような些細なものまでも、「ついでだから要求しておこう」という便乗要求をしがちです。ところが、情報システムの開発の費用は、システムの規模に対して指数的に増大します。その結果、全体として費用対効果の悪いシステムになる危険があります。
⑤ 業務の合理化
システム規模が増大する要因の一つに、業務の流れがシステムに合わないとか、各部門が違う仕事の仕方をしていることがあります。情報システムの検討においては、組織の統廃合や業務の標準化を行うことが必要です。それをなおざりにして情報システムで解決しようとするのは本末転倒です。
⑥ ＥＵＣの活用
プログラム作成で負荷がかかるのは、入力画面や出力帳票などヒューマン・インタフェースに関わる部分です。しかも、この部分が後になってからの変更要求が多いのです。また、出力帳票を作成する部分では、個々の帳票を作成するのではなく、その基になるデータをＥＵＣ用のファイルとして持ち、そこから利用者が任意に検索加工できるようにすれば、システムの規模を小さく簡素化することができます。
（３）データファイルの作成
得意先マスタファイルの作成やテストのためのデータの作成は、利用部門が作成すべきです。
① マスタファイルの作成
ファイルの仕様がほぼ決まった段階で、利用部門はマスタファイルの作成をします。マスタファイルが事前にできていれば、システム全体の把握もしやすくなりますし、プログラム作成も容易になります。
② テストのチェックは利用部門
テストにより要求事項が十分に実現できているか確認するのですから、テストのチェックは利用部門が行うことになります。テストでは単体のプログラムテストからシステム全体のテストへと進みますが、なるべく初期の段階でクレームを出すほうが、解決が円滑にできます。
③ テストデータ
できれば要求定義か外部設計の段階で、利用部門がテストデータとそれが正確に処理されたときの結果を作成するべきです。それにより、テスト段階が円滑になるだけでなく、要求内容を明確にするのにも役立ちます。また、テストデータは正しいデータだけでなく、誤りのデータや特殊なデータを用意する必要があります。これによりプログラムのエラーが早期に発見できます。
（４）プロトタイプ型開発技法などでの役割
プロトタイプ型、スパイラル型、ＲＡＤなどの開発技法を採用するときは、情報システム部門と利用部門の任務の境界が不明確になります。というよりも、両者が協同作業により、システム開発をすることになります。
とかく利用部門の人は、自分の業務が忙しいことを理由に、情報システム部門に任せがちですが、この開発形態で欠席すると作業が中断してしまうし、さらに悪いことは情報システム部門が独自判断で進むと大きな手戻りを生じてしまいます。専任体制が望ましいのです。