SEC BOOKS 経営者が参画する要求品質の確保
～超上流から攻めるIT化の勘どころ～第2版 解説・CD-ROM独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター 編
2006年5月発行、株式会社オーム社刊
業務ごとに個別にITシステムが設計・実装された時代には、ステークホルダ（利害関係者）は業務部門の中に限定されていました。しかし昨今では、コンピュータシステムの利用が、部内の利用者から社内の利用者（他部門）へ、社内の利用者から社外の利用者（取引先）へ、社外の利用者（取引先）から不特定の利用者（PC利用者）へと広がってきました。その結果、ひとつのシステムを作る場合でも、非常に多くのステークホルダが登場することになりました。
経営者、企画担当者、業務設計者、事務設計者、システム開発担当、メーカ、ソフトハウス、といった古典的なステークホルダに加えて、システムを本番に移行する際には、通信回線業者、端末展開業者、認証等セキュリティ業者、印刷アウトソーサなどが登場します。さらに出来上がったシステムが稼働し始めると、システムを使ってサービスを提供するコールセンタ、ヘルプデスク、業務アウトソーサ、事故受付サービスセンタ、代理店、特約店なども重要なステークホルダとなります。
特に企業間接続などを行う場合、システム開発の最初から、接続先の企業ＩＴ担当と密接な要件洗い出しを行う必要があります。相手先の企業がシステムについてアウトソースしている場合は、そのアウトソーサとの協業も発生します。窓口の営業担当もステークホルダになります。その他、開発環境管理者、本番運用担当者、認可事業であれば許認可官庁、住所コード等環境情報提供業者、共同サービスを提供する同業社、などなど、ステークホルダは多様です。
ステークホルダはエンドユーザ、システムの開発者や運用者など多岐に渡りますが、システムに直接携わり、開発に関与する（システムのプランニングに影響を与える）人達と、エンドユーザのようにシステム開発には直接かかわることができず、業務部門などが代弁者となって要求事項を反映する必要がある人達がいます。
各工程において、経営層、業務部門、情報システム部門および、利用者、運用者、などのステークホルダが、それぞれの立場での責任者、承認者、作業者を計画時に取り決め、何をしなければならないのかを明確にし、計画に盛り込んでおく必要があります。また、様々なステークホルダに開発の初期の段階で要件定義に参加してもらい、要件の精度を上げることが、システム開発品質向上の重要なポイントと言えます。
（図 ステークホルダ）
非機能要件は「機能要件以外のすべての要件」です。また、非機能要件は、事業要件、業務要件、システム要件を設定（設計･実装）する際に発生する運用要件、移行要件、性能要件、セキュリティ要件、機密保護対策の要件などの機能以外の要件を指します。非機能要件は、機能を実現（設計･実装）するためのインフラ（環境基盤）と考える事ができます。
また、非機能要件は極端な言い方をすれば「なくても良いが、なければ実用とならない機能」といえます。例えば、セキュリティ要件は実装されていなくても機能の実現を阻害することはありません。また、性能要件も設定されていなくても実装や稼働を阻害しません。ただし、そのためにオンラインのレスポンスに数分を要したり、企業情報や従業員情報、顧客情報が簡単に盗まれては「システムに対する評価」は著しく低下します。場合によっては「欠陥システム」の烙印を捺されてしまいます。さらに、
注意しなくてはならない事があります。これら非機能要件は実現の度合いによっては、開発コストを大きく押し上げる要因になります。そのため、どの程度で実現するのか充分な裏付けのある検討･設計が必要になります。
以下に、代表的な非機能要件を見て見ましょう。
＜性能要件＞
要件定義段階における性能要件とは、業務処理量からITシステムに要求される性能値に変換する作業です。インプットとなる情報は、業務処理量（例えば、伝票の処理件数、明細行数等）、システム利用ユーザ数、システムの運用時間、ピーク特性などです。これらの情報を元に、システムで必要とされる処理能力をスループットとレスポンスという2つの軸で規定します。
スループットは単位時間当たりの処理能力を示します。例えば、オンライン処理の場合ならば、システム全体でオンライン伝票入力処理が秒当たり10件こなせること、バッチ型の処理であれば、伝票の印刷処理が1時間あたり1万件処理できること、というように表わします。
レスポンスは、システムに処理要求を出してから結果が戻ってくるまでの時間を表わします。オンライン処理の場合は、キー入力後、システムに処理要求を出してから画面に結果が返るまでの時間を、バッチ処理の場合は、処理が開始してから、結果が出力されるまでの時間を表わします。これらスループットとレスポンスの情報、そして信頼性要件、セキュリティ要件、技術要件などを加味して要件定義工程におけるシステム構成を組み上げます。
性能要件を決めるにあたり、留意すべきいくつかの観点を述べます。
① 業務処理量の洗い出し
IT化する業務、およびその周辺業務の処理量を洗い出します。同時にオンライン系であれば、主な操作者、あるいは連携先のシステム、バッチ系であれば連携システムや前後の業務処理、データの受け渡し方法を明確にします。
② ピーク特性
実際の業務においては、システムに対していつも同じ量の処理を依頼しているわけではありません。例えば、オンライン系の処理の場合で考えてみると、人間の行動特性から午前は11時ごろ、午後は2時と４時ごろに平常時の1.5倍のピークがくるとか、棚卸を行う偶数月の第一月曜の朝に処理が集中する、チケット販売などの場合は、発売開始から最初の1時間に極端な処理集中があるなどです。バッチの場合は、月締めの処理が毎月第３営業日に集中するとか、小売業の場合は年末商戦の12月にピークがくるなど、業務によってピーク特性が異なってきます。
無論、システムによっては、ピークがひとつとは限らず、ある業務のピークは月曜だが、別の業務のピークは週末であるなど、複数のピークポイントを持つものも多くあります。
性能要件では、ピーク特性の洗い出しと、このピーク時において要求されるスループットとレスポンスタイムを設定することがひとつの大きな成果物となります。
③ 運用時間とバッチの処理時間の関係
処理結果が即時に分かるオンライン処理と異なり、一般に処理完了まで長時間を要すバッチ処理においては、運用可能な時間全てをバッチの処理時間で使い切ることは出来ません。
例えば、夜間バッチ処理に利用可能な時間が、20時から翌日の６時までであったとしても、バッチ処理そのものに目標として設定する処理時間(レスポンスタイム)は、10時間（20時から翌日6時）ではありません。処理完了まで長時間を要す以上、障害発生時にも運用に耐えうるよう再処理を行う時間を見込むのが普通です。また、オンライン処理などが延長されるなど、バッチ用に確保された時間自体が場合によっては短くなるという業務要件がある場合も考えられます。
④ ピーク時に要求する処理能力
前記②においてピーク時におけるスループットとレスポンスタイムの設定が重要であると述べましたが、ピーク時に極端に大きな性能を要求するシステムにおいては、投資効果とのバランスを考える必要があります。チケット販売などのようにピーク時の負荷のみが極端に高く、また処理量自体が予測しにくいシステムは、ピークにあわせてシステムを設計すると、効果に比べ巨額の投資が必要となってしまうケースもあります。このような場合は、処理すべき量にあわせてシステムをデザインすると共に、ピーク時にのみ発生する大量のリクエストをシステム内に全て滞留させるのではなく、処理可能な量からあふれたものはすばやく返す（つまり処理を拒否してエラーで返す）ようにシステムをデザインする必要があります。
バッチ系のシステムの場合は、特定日に極端に処理が集中するならば、処理量を分けて翌日にあふれた分を回すなどの工夫も織り込むケースもあります。
⑤ 成長率
業務処理量の将来的な伸びや、蓄積データ量の伸びで、処理能力の増加が確実に見込まれるケースは、システム拡張作業のリスクと照らしあわせ、事前にその分の投資を織り込んでおくことも多くあります。
また、チケット販売など将来的なピーク時の処理量が見通せないシステムは、柔軟な拡張性を持つシステムデザインとする必要があります。
⑥ 業務の処理量とコンピュータ上の処理量
要件定義段階で行う性能要件は、IT化を強く意識したものではありますが、完全にシステムへの実装までを意識してまとめることが出来ません。システム設計段階で漏れを中心に性能要件の洗い出しを再度行い、処理能力計算を実施して、システム構成を決定する必要があります。
＜信頼性要件＞
信頼性という言葉を広く捕らえると、安全性やセキュリティ強度、あるいはオペレーションミスに対応するフェール・セーフ対策なども意味として含まれてきますが、ここではシステムの可用性向上要件と捉えます。システムの信頼性は高いにこしたことはありませんが、高い信頼性を求めるほど、コンピュータシステムの購入コストに跳ね返ることから、業務要件と照らし合わせてバランスする構成を選択する必要があります。
信頼性要件として決定すべき業務要件とは、業務とITの融合度が高ければ高いほど業務の継続性と強く連動します。業務として許容される遅れの時間によって信頼性要件のインプットとなるダウン許容時間が示されることとなります。無論、業務がITシステムの停止時でも手作業で半日程度持ちこたえることが可能で、それが投資効果と見合うのであれば、半日のダウンタイムを目標要件と設定することもありえる選択肢です。
システムの信頼性向上施策はシステムを構成するコンポーネント（サーバやディスク装置、ネットワーク機器等）に冗長性を持たせることにあります。基本となる構成パターンは以下の通りです。
① 冗長構成を持たないシステム構成
この場合、障害コンポーネントの復旧を待ってシステムをリスタートさせる必要があります。復旧するまでは、システムは停止状態となりサービス提供が出来ません。
② 冗長箇所を持つシステム構成（ホットスタンバイ構成）
冗長構成となっているコンポーネントは、一方が主系(現用処理系)、他方が待機系となって、障害発生時、待機している他方のコンポーネントに処理を切り替え、継続してサービスを提供する構成です。
切り替えに要する時間が非常に短時間で、処理途中のリクエストも継続処理することが可能なコンポーネント（製品）や、切り替えに時に時間を要したり、切り替え中に要求されたリクエストは捨てられるものなど、コンポーネントの製品特性によって差があります。
③ 冗長箇所を持つシステム構成（パラレル構成）
前出の②と同じく冗長構成となっている点は同じですが、一方が主系(現用処理系)、他方が待機系となっているのではなく、冗長構成を成しているコンポーネント全てが現用系として処理をする構成です。
障害発生時は、障害となったコンポーネントのみ切り離され、その他のコンポーネントが障害コンポーネントの負荷も肩代わりします。
これらの他、②と③を組み合わせた構成などもありうる選択肢です。
次に冗長化するコンポーネントの選択指針について述べます。最近はほとんどのコンポーネントが冗長化可能ですが、以下のようなコンポーネントの優先度が高くなります。
ａ）回復に時間を要すコンポーネント
代表的なコンポーネントはディスク、特にデータベース（DB）を格納しているディスク装置があげられます。ＤＢを格納しているディスク措置の障害時はディスク装置の復旧だけでなく、データベースの回復作業も必要となり、一般に長時間を要します。
ｂ）障害になりやすいコンポーネント
これも駆動部分を持つディスク装置が代表的な例です。
ｃ）障害の発生によってシステム全体に対するダメージが大きいコンポーネント
これもディスク装置が該当するが、他には電源装置も代表的です。電源装置が壊れると、格納データ間の整合性を常に確保する仕掛けを持つデータベースが破壊される可能性が高いため、復旧処理に時間を要します。
障害発生時、回復までの時間を短くする工夫も重要な検討ポイントです。これも長時間を要するデータベースの回復についての対策が代表的な例です。データベースのバックアップは、本体領域と更新ログのそれぞれにおいて方針を決める必要があります。また格納媒体も他ディスク装置へのコピーを作成する方法から、各種販売され、技術革新も激しい可搬性のテープ系媒体、ディスク系の媒体があります。回復方法、回復時間の制約要件にあわせ選択することになります。
以上は、システムを構成するコンポーネントのいずれかの部位の故障に対する対応について述べてきましたが、さらに高信頼性を要求されるシステムでは、コンピュータセンタ自体が災害に見舞われた場合についても検討する必要があります。
信頼性要件についても、再度システム設計段階において見直しが必要ですが、信頼性向上のために冗長化や信頼性の高いコンポーネントを選択するということは、それだけ投資金額が大きくなることから、この要件定義段階できっちりした方針を定め、投資額を明確にしておく必要があります。
＜セキュリティ要件＞
セキュリティは、まず運用上の環境防衛と、個人情報保護のような情報漏洩リスク対応に分けて考える必要があります。
前者は、稼働中のコンピュータが壊される、誤った作動をするようコントロールされるといった、コンピュータセンタや、ネットワーク、オペレーションという分野の運用管理の問題です。インターネットからの攻撃などがこの中に入ります。また、これには、開発担当者が開発したプログラムを本番環境に移行しようとして、本番稼働条件定義を壊すといったことも含まれます。
後者は、例えば開発担当者が権限を利用して本番データを読み出し、持ち出すといったリスクです。最近の個人情報盗み出しは内部関係者による犯罪が多く、そういった悪意によるものに対抗するのは当然として、反社会的団体に脅されても担当者、管理者を犯罪者にしない、という観点から個人情報を中心に、本番データに許可なくアクセスできないようにすることが必要になります。個人情報が現金化できる現在、例えば個人情報を誰でもアクセスできる環境におくことは、出入り自由な、誰もいない部屋に、現金の山を築いておくようなものです。
さて、こういったセキュリティにかかわる手当てをするに際して、承知しておかなければならないことがあります。例えば、技術的に最高度のセキュリティをかけた環境のパソコンに業務上必要な個人情報を入れて営業に回っている際、おそわれてパソコンを奪われた場合であっても、個人情報保護の観点からは責任を免れないケースがありえるのです。そうなると犯罪被害にあった上に、個人情報保護の観点からは処罰されるということになりかねません。
システムがあらゆるビジネスシーンに登場している現在、セキュリティはかつての非機能要件の座から、もっとも重要な機能要件そのものになったといえます。セキュリティ要件を充足しないシステムはそもそも開発することが出来ないからです。
＜解説１＞
プロダクトオリエンテッドな開発管理とは、システム開発の達成度をドキュメントやプログラムという最終成果物の出来高に置き換えて測る考え方です。初期の頃のシステム開発では、アプリケーションプログラムの開発が圧倒的な比重を占めていたため、プログラムの量を開発の達成度の指標とする方法が一般的でした。設計段階でも、対応するドキュメントの量が設計の達成度の代替指標となり得ました。
対して、プロジェクトオリエンテッドな開発管理とは、プロジェクトとして行わなければならない行為とその成否によって、システム開発の達成度を測る考え方です。昨今のシステム開発では、システム開発の技術的な条件が非常に複雑になっています。例えば開発に必要な言語一つをとっても、Java、HTML、XML、など多様です。そのため、単純なプログラムの「量」では達成度を表すことができません。むしろ、要求分析、設計、実装など、行うべき行為、作業を、より精密に定義し、それぞれの成否を基礎値として全体の達成度を積み上げて管理する必要があります。
＜解説２＞
システム開発をするとき、一昔前はプログラムを作ってコンピュータの本番環境へ登録すればそれで完了でした。プロジェクト管理もプログラムの製造進捗と、プログラムの誤りをなくすテスト進捗について、しっかりと管理しておけばよかったわけです。
しかし、システム利用が高度化し、利用範囲も広がってきますと、ステークホルダも増え、要求やニーズも多様化します。これらの要求をシステム要件に落としていくのは大変な作業となっています。また、利用技術もオープン系システムの登場によって、様変わりしました。ネットワーク設計はプログラム技術ではできません。さらに、非機能要件といわれる、主に稼働環境にかかわる要素も出てきました。レスポンスや、稼働運用条件といった非機能要件は、要望やニーズをシステム要件に落としていくプロセスで発生してくるものが多いので、なかなか管理が厄介です。
このように、プログラマを集めて、業務要件を仕様書に落とし、一気呵成にシステム（プログラム）を作り上げていく古典的なシステム開発手法では、21世紀の開発品質は確保できなくなっています。
先に、述べましたように、要求は抽象的で、ブレがあります。開発の途中で発生するシステム要件もあります。こういった要件は、常にシステムを作ることによって実現したいビジネスの仕組みから、吟味検討しないと正しい要件は見つかりませんし、ステークホルダの合意承認も取り付けられません。プロセス管理が必要となります。
また、システム開発に参加する担当者も増えています。システム開発の依頼者もかつてのように、自分が使う仕組みを頼んでくることはまれで、営業や客先で使ってもらう仕組みを提供する役割を担っています。システムの提供者としてシステムテストで製造物の品質確認をしなければなりません。インフラストラクチャーの検討には専門化の参加が必要です。さらに保有する既存システムへの改定を伴う場合は、他システム担当者との連携も必要となります。
このように、現在のシステム開発においては、物（プログラム）を作るだけという管理から、プロジェクトを成功させるための管理へ大きく主軸を移すことが必要となっています。
＜解説３＞
システム開発で企業が手にしたいのは、単に正しく動作するプログラムの塊ではなく、そのシステムが実現するビジネスの成果です。その意味でシステムはあくまでもビジネスの手段にすぎません。
ＩＴ担当者やベンダは往々にして、現状の技術、それまでに積んできたスキルや経験など様々な条件に制約され、ややもすると正確に動作するプログラムを作り上げることのみに囚われます。手段にすぎないプロダクトが目的となるのです。プロダクトオリエンテッドのシステム開発と言えます。
しかし、現在のシステム開発はプログラムに実装される機能要件を満たすだけでは十分とは言えません。それはシステムの一部にすぎません。ましてや、ビジネスにとってはほんの一部にすぎません。
ステークホルダの多様化にともない、どのような人が、いつ、どのような状況で、どのようにシステムを使用するのか、想定される範囲は大きく広がっています。
システム開発にあたり、セキュリティ、個人情報保護、本人認証などシステムの稼働環境に関することなども配慮するのは、今ではあたり前であり、プロダクトオリエンテッドな開発管理を超えて、システム化の目的を見据えたプロジェクトオリエンテッドな開発管理が重要になっています。
具体的なシステム構築プロジェクトでみると、設計・製造・テストと工程は移るが、各プロジェクトメンバの意識が統一していないと、設計から携わったＳＥと、製造工程から参加したプログラマとの間に意識ずれが生じ、将来の障害に繋がる可能性もあります。 そのため、用語や機能といった業務的な要件、各工程の作業手順についての統一を図る以外に、業務の意義や目的、最終的に展開された姿についても、プロジェクトメンバ全員に浸透させておくといったプロジェクト独自のマネジメントの工夫とともに、強力なリーダシップが重要です。
▼ソフトウェアライフサイクルプロセス
▼ＩＳＯ／ＩＥＣ １２２０７
ソフトウェアのライフサイクルを構成する主要なプロセス要素を列挙した国際規格です。二者間契約において言葉の定義を明確化し、作業内容や役割分担に関する混乱を抑制することを目的としています。ソフトウェアの構想段階から廃棄までの時期に発生するプロセス要素間の関係、相互作用を記述しています。ライフサイクルは、プロセス、アクティビティ、タスク、リストといった細分化構造を利用して記述されています。
取得プロセス、供給プロセス、開発プロセス、運用プロセス、保守プロセスで構成される主ライフサイクルプロセス、文書化プロセス、構成管理プロセス、品質保証プロセスなどで構成される支援ライフサイクルプロセス、管理プロセス、環境整備プロセス、改善プロセス、教育訓練プロセスなどで構成される組織に関するライフサイクルプロセス、さらに修整プロセスやシステム監査プロセスなどが含まれています。
ライフサイクルプロセス、ISO/ IEC 15288を参照。
正式名称は「共通フレーム９８ ＳＬＣＰ－ＪＣＦ９８：ソフトウェアを中心としたシステムの取引に関する共通フレーム」で、ソフトウェアを中心としたシステムの開発および取引の明確化を目的に、ソフトウェアまたはシステムの構想からその廃棄にいたるまでのソフトウェアライフサイクルプロセスを可視化し、共通の枠組みを規定したものです。
共通フレームの策定にあたっては、ソフトウェアライフサイクルプロセス規格ISO/IEC 12207：1995（JIS Ｘ 0160-1996）との整合性をとりながら国内ソフトウェア産業界の特性を加味しています。
（出展：共通フレーム９８ ＳＬＣＰ－ＪＣＦ９８ 目的より）
CMM（能力成熟度モデル：Capability Maturity Model）とは、ソフトウェア開発やシステム開発において、重要で効果的であると考えられるプロセスの特徴を整理し、構造的に編集記述したプロセスモデルです。場当たり的で未成熟なプロセスから、改善された品質と有効性を伴った秩序ある成熟したプロセスへの進化の改善経路も記述しています。米カーネギーメロン大学ソフトウェアエンジニアリング研究所を中心に、米国防総省、産業界が協力して作成しました。CMMI（能力成熟度モデル統合：Capability Maturity Model Integration）は、システムエンジニアリング、ソフトウェアエンジニアリングなど、複数の専門分野を統合した能力成熟度モデルです。
CMMIにおいては、その適用アプローチとして段階表現と連続表現の2通りが用意されています。段階表現では、組織の改善経路を定義するために、あらかじめ定義されたプロセス領域の集合を用い、成熟度レベルという5段階の進化の段階を定義しています。連続表現では、組織がプロセス領域を選択して、それに関する改善活動を行います。連続表現では、個々のプロセス領域の改善の特性を明確化するために、6段階の能力レベルを用いています。
CMMIにおける評定手法は、SCAMPI(プロセス改善のための標準CMMI評定手法)として定義されており、内部プロセス改善、供給者選定、またはプロセス監視を目的に、CMMIモデルに照らして、組織のプロセス定義およびその実施状況を評価することができます。厳格さによってクラスA,B,Cの3通りがあり、最も厳格なクラスAの場合のみ評定値（成熟度レベルまたは能力レベル）を決定します。
PMBOK （Project Management Body of Knowledge ／ ピンボック）は、米国プロジェクトマネジメント協会（PMI：Project
Management Institute）が策定した、プロジェクトマネジメントのための知識体系（body of knowledge）で、事実上の標準として受入れられています。 ＰＭＢＯＫは、プロジェクトを以下に示す９つの知識エリアに分けて整理し、管理するためのガイドラインとして使用されます。
１．プロジェクト統合マネジメント
２．プロジェクト・スコープ・マネジメント
３．プロジェクト・タイム・マネジメント
４．プロジェクト・コスト・マネジメント
５．プロジェクト品質マネジメント
６．プロジェクト人的資源マネジメント
７．プロジェクト・コミュニケーション・マネジメント
８．プロジェクト・リスク・マネジメント
９．プロジェクト調達マネジメント
▼要件定義の段階で、ステークホルダとなる社内関係者をすべて巻き込む。
また、可能であればベンダも要件定義段階から本格的に参画させる。
○「集中検討会」にてステークホルダを巻き込む。
＜解説１＞
データをまとめて、一括で処理をする方式のことです。
日、週、月といった単位でデータを処理する業務に適しています。
対語：オンラインリアルタイムシステム
＜解説２＞
大量定型反復。60年代から70年代にかけて主流であったコンピュータの活用キーワードです。今ではすっかりオンラインリアルタイム、ネットワークに塗り変わっているように感じられますが、いまだにその役割は大きいものがあります。
バッチ時代のシステムはその後、その入出力のところは、オンラインや、Ｗｅｂに置き換わりましたが、データ上の情報処理については、例えば処理対象の商品などが変わらない限り、基本的には同じプログラムが動いています。生命保険会社などの100年にもわたる契約期間の商品などでは、発売時のプログラムが、商品が売り止めになっても、場合によっては100年間稼働します。
時代が移るにつれて、システムが新しい技術で置き換わってきたような印象を受けますが、業務処理の核のところでは30年・40年間にわたって、劣化しないプログラムが稼働しています。システム開発を理解するとき、この保有業務処理システムの存在を忘れてはなりません。
もう一つ、大量定型反復にも構造的変化が出てきています、大量・定型・反復といっても、まったく同じものを繰り返し作成しているわけではありません。条件に応じてアウトプット１件ごとに異なる数値や情報を打ち出しています。その内容が商品や、会社機構の複雑化、顧客ニーズに対応して、いわば大量・複雑定型・個別対応型になってきています。
損害保険の自動車保険更改お勧め申込書などでは数億通りの選択表示バリエーションが用意されていて、営業担当者や，販売代理店、はたまたお客様の要望に応じて、きめ細かく条件に応じた打ち出しをしています。
バッチないし、バッチ時代システムは、オンラインの皮をかぶった現在でも基幹システムの大きな部分を占めていて、決して古代遺跡のような存在ではなく、システムを開発する際には必ず、手を入れなくてはならない重要なシステム開発の対象です。その処理内容は外側に広がったシステムのために、ますます複雑になっています。システム開発をするときはこのレガシーともいえるシステムの手当てを必須のものとして対象に入れないと大きな見積もりミスを犯すことになります。
ネットワークの時代、どっこいバッチシステムは大きな存在感を見せ始めたように思えてなりません。
＜解説１・コールセンタ＞
顧客からの問い合わせや、苦情受付の窓口となる、大規模な電話対応組織のことです。
CTI（Computer Telephony Integration）技術を利用し、顧客情報を持ったコンピュータと電話、ＦＡＸを連動させ顧客へのサービスを充実させることを目的としています。
コールセンタの業務は顧客からの電話を受けるインバウンド業務と、企業から販売促進、アンケートなどの電話をかけるアウトバウンド業務の二つがあります。
＜解説２・ヘルプデスク＞
米国ヘルプデスク協会の創始者、ロン・マンズ氏が提唱しました。
企業の内部へサービス（パソコンの利用サポートなど）を行う「インターナルヘルプデスク」と、外部へのサービス（顧客からの問い合わせの対応、顧客への自社製品のサポートなど）を行う「エクスターナルサービスデスク」があります。
＜解説３＞
コールセンタは、お客様と企業との間のコミュニケーションを近づける、ヒューマンタッチの道具です。通販やインターネットプロバイダといった業種だけでなく、いまや金融、物流その他の基幹産業でもビジネスに不可欠な仕組みとして活用されています。
一般的に消費者サイドからコールセンタは、商品の購入といった営業機能、利用法照会といったサービス機能などだけしか見えませんが、コールセンタの仕組みは直接消費者から見えない企業内の業務フィールドにおいても活用されています。
例えば、大手損害保険会社では20万台を超える営業代理店端末を展開していますが、こうした代理店が端末を使って業務する際の様々な指導･助言といったサポート機能を、効率的に行うためにヘルプデスクという名の業務サポートコールセンタを用意しています。さらに、交通事故などについて代理店やお客様から事故の発生連絡を受け付けるサービスセンタなどもコールセンタ技術を活用して構築されています。
こういったコールセンタでは、オンラインで電話をかけてきた人と、企業との関係の契約などを確認して対応する仕組みが不可欠となりますが、こうした仕組みが、お客様とのコミュニケーションを管理するコールセンタのベースとなる通話管理機能と融合して、それぞれの業務目的にあったコールセンタが構築されます。
現在のシステム開発において、関係する業務についてのコールセンタ機能がどこで、どのような形で利用されるかは、開発要件の大きな影響を与えるものとなっており、ステークホルダとして開発要件検討に欠かすことの出来ない存在になっています。
＜解説１＞
時代遅れとなった古いシステムのことです、新たに導入しようとするシステムに対して制約を与える既存システムのことをこう呼びます。
既存の基幹システム＝ホストという意味で多く使われます。
＜解説２＞
レガシーという言葉は何も、ホスト機で構築、稼働している基幹システムだけではありません、新しいシステムの制約となるものがレガシーであるならば、最新の技術で構築したシステムでも利用開始時点でレガシーとなってしまいます。特に最近の技術の進歩は早く、稼働開始時点で、すでに時代遅れとなっている状況も多々あります。
それらを否定してしまうのではなく、本来のレガシー（遺産）として利用方法、有効活用を検討する事も必要でしょう。
＜解説３＞
主に大企業は、20世紀後半からコンピュータシステムを活用して、ビジネスを革新してきました。
例えば、損害保険業界の場合であれば、古くは1960年代からコンピュータを積極的に導入し、保険契約データを入力するところから、経理決算まで一貫して処理できるトータルシステムというコンセプトの業務システムを構築し活用してきました。
トータルシステムにおいては、例えば自動車保険の契約はコンピュータに入力されると、全ての項目が認可条件に合うものか、約款・規定に照らして検証され、誤りあれば訂正された上で、契約マスタという名のデータベースに格納されたのです。その上で後続の処理システムに契約データは渡され、統計や会計といった処理が連続して行われました。
こういった、処理を行うシステムは、その後、ネットワークの発展に対応してバッチからオンラインへ、さらにインターネット技術を活用し、会社の外にいるパートナである代理店、そして現在ではお客様のオフィス、家庭までつながるようになり、保険契約を処理する基本の部分は、核となるシステムとして中心に座った構造になっているため、この部分が何をするにも手当てが必要なレガシーと表現される部分になりました。
例えば、オンラインになったことで、パンチ会社で作成された入力電子データが、営業所第一線からエントリーされるようになっても、その効果は、バックオフィスでの契約書受付、パンチ回付、エラーデータ訂正、そのための営業第一線問い合わせといった業務担当者が不要になるというもので、その契約データ一件、一件の項目処理内容は変わりません。
つまり、システム利用の範囲拡大といった形で行われたシステム機能の拡張は必然的にレガシーという部分を少なからず残すことになり、常にメンテナンスを発生させる原因となりました。ある大手損害保険会社では商品発売等におけるシステム開発の８０％以上が修正であり、新しい施策はレガシーシステムをいかに効率的にメンテナンスできるかによってタイムリーに実現できるかどうかが決まるようになってきました。
＜解説１＞
従来のメインフレーム（汎用機）やオフコンは、プロプライエタリーな仕様（コンピュータメーカ独自の仕様）です。 したがって、同一メーカの同一機種（同一シリーズ）でしか互換がありませんでした。
つまり、A社のコンピュータにB社のソフトを乗せて利用することはほとんどできませんでした。またハードウェアも互換性がほとんど無く、同一メーカ品で揃えるのが普通でした。（ＣＰＵ互換機
、周辺機器の互換機は存在しましたが、選択肢は多いものではありませんでした）
1990年代になって、これを解消しようとオープン化の動きが始まりました。 当初はＯＳをＵＮＩＸとし、周辺機器の接続はＳＣＳＩ等の標準規格、ネットワークはイーサネット／ＴＣＰ／ＩＰから始まりました。そして、パソコンの分野でもWindowsの登場により加速しました。
オープン化とは、コンピュータメーカ独自の仕様でなくデファクトスタンダード（業界標準：事実上の標準）のもとでシステムを作っていくことです。 デファクトスタンダードに沿って作られたパソコンであれば、ハードウェア、ソフトウェア、ネットワークなどが共通化され、
購入時の選択の自由が広がりました。
＜解説２＞
オープン化はハードの価格を大幅に下げ、コストダウンに寄与した反面、デファクトスタンダードの規格が厳密でないため、１００％の接続、稼働の保障は無く、その責務はユーザに帰される事となりました、またミドルウェアが充実していないため、従来はミドルウェアが保有していた機能を、アプリケーションで作成しなければならない、といった弊害も表われ、品質の確保のためには、システム構築の検証、ソフトウェア作成に今まで以上に時間をかける必要が出てきました。この負の面が十分に論じられていない所に、現状のシステム開発の問題点があるのではないでしょうか。
＜解説３＞
1990年代に入り、情報システムのオープン化のムードが急速に広がりました。OSやネットワークなどの世界標準が普及し、情報システムの素材(コンピュータ本体、周辺機器、基本ソフトウェア等)を、複数のベンダ製品から選択することが原理的に可能になりました。それまで、メインフレームを中心とした情報システムでは、特定のメインフレーマの製品しか選択の余地はなく、限定的な調達しかできませんでした。オープン化とはその状況の反対語として生まれた言葉です。
実際、利用者にとってオープン化は、パソコンの実質標準であるWindowsおよびWebの普及という形で、最も端的な福音をもたらしました。車の運転を一度覚えればメーカや車種は自由に選択できるように、「パソコンが使える」人は、どのベンダ製のパソコンでも操作できます。
一方、オープン化によって、情報システム部門が期待したことが実現されたかどうかは、パソコンの例ほどはっきりしていません。情報システム部門は、オープン化によって、それまでの特定ベンダに限定された情報システム開発から開放され、自由な市場でシステム素材を調達でき、大幅なコストダウンに寄与すると考えました。しかし、現実には複数製品の組み合わせによる品質問題や、機能の不足によるアプリケーションへの皺寄せが起こり、オープン化が真にコストダウンに結びついたかどうかは疑わしいものです。
▼ＩＴ（Information Technology）ガバナンス
「企業が競争優位性構築を目的に、IT戦略の策定・実行をコントロールし、あるべき方向へ導く組織能力」（経産省の定義）
すなわち、企業がビジネス戦略に基づく活動を、ＩＴを活用して実行し、その結果を評価してビジネス戦略にフィードバックし、求めるものを追求する仕組みのことです。
ソフトウェア開発の生産性・品質向上を目指して、研究開発が進められている工学の一分野です。IEEEの定義では「(1) ソフトウェアの開発、運用、および保守における、システマティックであり、ディシプリンに基づいた、定量的なアプローチの適用である。換言すれば、ソフトウェアへのエンジニアリングの適用である。(2) (1)で示したアプローチに関する研究である。」とされています。例えば、①ソフトウェアの要求定義手法、②設計手法、③プログラミング言語とプログラミング技術、④テストと検証技術、⑤保守技術、⑥文書化技術、⑦品質管理手法、⑧プロジェクトマネジメント手法などが具体的なテーマです。
ソフトウェア開発は「気まぐれな」人間が中心となって作業するものであるため、再現性のある法則を定量的に扱うことが非常に難しいです。しかしながら、定性的な法則だけでは、経験談・ノウハウとしての「伝承・伝説」の域を脱し得ず、産業における共通ディシプリンとして根付きにくい。工学として確固たる基礎に基づいたものが望まれています。
バックオフィスとは、人事、会計、購買など、企業内における事務処理的な業務を指し、従来のシステム構築はこの部分のコスト削減、効率化が主な目的でした。
一方、フロントオフィスは、企業の中でマーケティング、営業、顧客サービスなど顧客に直接対応する業務を指し、近年のシステム構築は売上げを伸張させる手段として、このフロントオフィスを対象としているものも多くあります。
プロセスアセスメントとは、定められた手順に則って、組織の所有するプロセスを何らかのプロセスアセスメントモデルと比較評価する系統的な活動です。プロセスアセスメントは、単に合格/不合格ではなく、現状プロセスの実施状況を客観的に評価し、プロセスがその目的を満足させる程度を測定する枠組みを提供し、プロセスの強みと弱みを特定します。
ISO/IEC 15504を参照。
品質マネジメントシステムは、顧客満足の向上を目的とし、品質に関して組織を指揮し、管理するためのマネジメントシステムです。
マネジメントシステムは、経営方針や事業目標に基づき、業務のプロセスを組織横断的に定義し、それを適用して業務を遂行するとともに、その適用状況や結果を監視、測定し、必要なアクションをとっていく体系的な活動の枠組みです。
品質マネジメントシステムにおいては、個々の開発プロジェクトにおける品質管理(Quality Control)や品質保証(Quality Assurance)を組織の事業目標達成に向けた重要な活動と位置づけます。そして、それらのプロセスを明確化し、分析し、改善し、より効果的なプロセスを整備する活動を組織全体として実行することを通して、最終的に顧客満足を向上させ、組織の競争力を向上させていきます。
ISO 9001を参照。
ＫＰＩ（Key Performance Indicator／ケーピーアイ）は、業績評価指標と訳され、バランスド・スコア・カード（ＢＳＣ）と呼ばれる経営手法でも使用されます。
企業経営における事業目標やビジネス戦略で期待する最終目標および効果に対し、その達成度合いを定量的にモニタリングするための評価指標のことです。
ＩＴシステムにおいては、そのシステムを使用することによって生じるビジネス効果を、数値目標として設定し、ＫＰＩを使用して一定の間隔でモニタリングすれば、システム稼働後の成果を、定期的かつ定量的に把握できるようになります。
概念データモデルは、データによって表されている対象（世界）が、 どのように構成されているかを表すモデルです。 「どんなデータがあるか」、「データ項目間にどんな関係があるか」
が記述されます。
「データがＤＢＭＳに、どのように記録されているか」 という物理的な制約とは無関係に作成されます（実装独立）。 一般にＥＲ図で書かれる事が多く、ANSIの概念スキーマ
の一部と外部スキーマに対応しています。
また、本書で言う「概念データ」は、業務上必要なデータという意味で、これらはたいていの場合、画面や帳票上に入力データや出力データとして表現されています。
システム開発は、最初から最後まで人間によって行われます。
要求を分析し、業務要件、システム要件に落とす作業、システム構造の決定、プログラム仕様書の作成、プログラミング、テストケース・テストデータの作成、本番環境への登録移行、本番作業の実施結果確認等々、機械を道具として使うことはあってもその実態は人の作業です。
人が中心となるシステム開発の各工程作業について、その工程の業務内容に即した品質向上の仕組みを用意することが、高品質なシステム作りの鍵となります。
システム開発は、人の作業に拠るだけに、ビジネス構想から、プログラミング、さらにはテストにおいてさえ、その作業自体に誤りを作り込む特性を持っています。
システム開発では次工程のためのアウトプット品質が重要な意味を持ちます。誤りのないアウトプットを次工程に渡さなければ、次工程ではその誤りをその工程の生産物に作り込んでしまうのが普通です。もちろん、作り込まれた誤りを発見するためにテストをするのですが、古くからたとえられるように、地雷原の地雷を全て探すような手間とロードが必要で、全てをクリアーするような決め手となるような方法はまだ見つかっていません。
また、コーディングやＪＣＬ作成、プログラムの本番移行登録などには、手続き的手作業が数多くあります。これらの作業は、ヒューマンエラーを誘発します。アクセルとブレーキを踏み間違うようなヒューマンエラーはすぐに気がつきますが、システム開発において発生するヒューマンエラーは自分では気がつきにくいものが多いです。
人間技であることを踏まえた開発品質の向上は、こういった、業務特性を踏まえた、誤りの防止が鍵となります。
１． 超上流工程～上流
超上流工程での誤り作り込み防止で重要な事項の一番は、ビジネスプランの作成の初期からＩＴ担当者が参加し、システムを利用して実現を図るための適切な内容検討を行うことです。
特にシステム基盤の担当者による、完成後の想定稼働環境評価はオープン系システムについてとりわけ大きな効果があります。
新技術を活用したり、根本的に保有システムの作りかえを企画するような場合は、ベンダの専門家に早い時期から参加してもらうことが必要です。
次に、そのたたき台を基に、ステークホルダによるクロスファンクショナルな業務要求要件の洗い出しを行います。
企業が活用するシステムは、現在企業の枠を超えて利用されています。商品開発や、販売戦略はシステムなしに実現できませんし、システムのステークホルダは、ビジネスの企画者、システムの開発担当者、システムを使ってサービスを提供する担当者、代理店、提携する企業の担当者、アウトソーサ、そしてお客様とかつてないほど広い範囲に存在します。
業務企画担当者はこういったステークホルダを可能な限り集め、要求ヒアリングをしてシステム基本計画作成に反映させなければなりません。
こうして、漏れのないシステム化基本計画が出来たら、最後に、経営の承認決済を受けることになります。人、時間、資金といった開発資源がふんだんにある場合は別として昨今はシステム開発が、業務企画部門の思うままに出来る状況にありませんから、開発案件を絞らなければなりません。このとき、従来は業務企画部門と相対するＩＴ担当部門が個別に実施案件を決めていたのですが、これでは真に企業にとって必要な案件が適切に絞り込まれることにはなりません。
やはり、全てのシステム化基本計画を一本にして吟味し全体で優先順位をつける必要があります。こうすることで、経営の意思が反映されるだけでなく、選択のプロセスで他案件との比較検討がなされ、基本計画の要件は、吟味され責任あるものになります。
こうして、固めたれた基本要件は漏れ、曖昧さが少なくなるだけでなく、責任あるものとなり、変更管理が容易になります。ＩＴ部門相手だけの場合と違って反故にされにくくなります。
基本計画が通った後は、業務要件設計に入りますが、ここについてもっとも大切なことは、業務企画サイドが発注者として、業務要件について責任を持つということです。要件自体の検討作成をアウトソースしたり、ＩＴ部門が代替することはかまいません。しかし、出来上がった業務要件についての責任は発注者である業務企画部門がとらなければなりません。その点を明確にすることで、そのときの都合で、だれが業務要件を作ることになっても、吟味された、推敲された業務要件となります。
よく、要件どおりに出来ていても、不都合なことが起こると、システムがそうなっているからとシステムのせいにする業務企画担当者がいますが、システムが決められたとおりに作られていなければ別として、要件どおりならそれは、その業務要件が悪いのであってシステムが悪いということはありません。その責任は要件に責任を持つ業務企画担当者が負わなければなりません。
２．
システム開発プロセス
システムを構築するプロセスでの品質向上施策は、プログラムプロダクトについては、デザインインスペクションやウォークスルーといった技法が有効です。テストケースは業務要件ベースの物は業務要件定義の際、一緒に作成しておくとよいでしょう。
開発の基本は「書いてあることはやらなければならない、書いてないことはやってはいけない」ということです。しかし、読み誤りや、読み違い、把握漏れは頻繁に起こります。同じ言葉でも読む人によって違う解釈をすることは、まれではありません。それを防止するためには、システム設計・開発担当者が正確に業務要件定義を把握するのはもちろんですが、プログラムが完成したとき実現する世界について理解を深めるのがもっとも効果的です。システム開発の目的は「プログラムの塊を作ることではなく、プログラムの塊が作り出す世界にある」、のですから開発担当者もまたそこをしっかり把握し、業務要件を正しく読み解く、把握する知識を得る必要があるでしょう。
一方、プロジェクト管理についても工夫が必要です。担当者はプログラムを作ることに邁進しています。また、多少の不都合な事態は何とかしようと抱え込みます。何とかすることを常に要求されていることも事実ですが、何ともできない、何とかする必要のないものまで抱え込みますと不都合な事態が発生します。 こういった、特性を持つシステム開発ですから、基本は管理を実現するための可視化、透明化ということになります。
プロジェクトレビューや、進捗管理は、それを通じて、プロジェクトの状況が正確に把握できて初めて意味があります。管理が可能になります。
例えば、レビューの場合、報告会にしないことが重要です。要件確定レビューを例にとって見ましょう。多くの場合、要件確定レビューでは、「無事要件確定作業が終了し、発注部門とも確認が終わりました。」という報告がなされます。しかし、これはレビューという観点からはまったく意味がありません。
要件確定レビューであれば、なぜ、こういった要件になったのか、何をとり、何を落としたのか、その理由は、そのため何が変更になりどこに影響が出るのか、例えば完成後の想定作業で手作業部分が増えたりしないのか…そういった点を明らかにし、その判断の妥当性をレビューするのでないと意味がないことになります。さらに、そういうことなので次の工程以降にこういう影響がある、関係担当業務にこういう手配が必要になる、不要になる。そういったことがレビューの俎上にのって初めて意味があります。
なぜこうなったのか、それでどうするのか・・ということが重要なのです。
進捗管理も、進捗状況を聞いているだけでは事実を把握できません。担当者は問題があっても、何とかしようと思っている事項について、そう思っている間は問題ないと報告するからです。人間なのです。
ＥＶＭなど実施し、なるべく多くの事実を表す指標を用意し、センサが発するアラームをベースに進捗管理をしなければなりません。
多くの指標が取れないのであれば、予定工数と、実績工数だけでも十分問題発見のセンサになります。一定以上の乖離が発生したら説明を求めることです。そこから進捗管理が始まります。
３． テスト・本番展開
テストのポイントはまず、テストケースです。業務要件のテストは要件定義のときにすることがよいと先に書きましたが、テストケースを考えると、業務要件の推敲ができます。したがって早いタイミングで行うことに価値があります。
ところで、テストについては簡単な開発ほど、手抜きが発生しやすいところに気をつける必要があります。簡単だから、1行だけだから、他の処理と同じだから･･テストしないで目視チェックだけで本番に移行し大トラブル・・ということをよく耳にします。人間は簡単なことについて頭をあまり使いません。ましてや、同じだから・・というみなし、決め付けを生みやすい判断の場合、リスクは大きなものになります。簡単だから、頭を使わないのでテストで検証、というのが正しいアプローチでしょう。
本番展開にかかわる作業は、ヒューマンエラーの温床です。ＪＣＬの作成登録、プログラムの本番登録、データの準備手配、みな手続き的手作業を伴います。先にも書きましたが、アクセルとブレーキを踏み間違えるようなヒューマンエラーであればすぐに気がつきますが、こういった作業では本番をやってから気がつくことになります。
このような、環境準備においてさえも、「先月と同じだから、そのままコピーして作業」、「一部の修正なので、目チェックだけ」、といったことが、多く見受けられます。プログラムと同様に、可能な限りテストして本番に備えることが必要でしょう。
最後に、本番後の結果確認ですが、ここにも落とし穴があります。多くの場合、検証をしていることを管理者は確認しＯＫを出しているように思います。しかし、確実なチェックを実現したければ、なぜ、このチェックで正しいといえるのか説明させ、その内容をチェックすべきでしょう。口頭で十分ですから依頼書や、チェックにかかわる承認を求められた際、なぜこれで正しいといえるか説明を求めれば、漏れや、不足、勘違いを担当者自らが発見することになること請け合いです。
▼保有システムを可視化し、全体最適の観点から共通的で一貫した技法、構造を定義、活用できるようにすること
長年の部分最適システムの開発や、システムの経年劣化に対する部分修復などの蓄積に加え、低価格のオープンシステムの普及により、企業内のシステム環境は、業務間の整合性というビジネス面でも、ハードウェア・ソフトウェアといったインフラ面でも、ガバナンスの効かない状況に陥っています。これらのシステムを全社ベースで可視化し、企業全体の目指すべき方向性・理念に沿った最適化を行うことが大切です。
日本政府が策定したＥＡ（Enterprise Architecture：業務・システム最適化計画）では、以下の４つのレイヤで業務・システムをモデル化し、全体最適の検討を行うことを薦めています。
・ 業務（Business Architecture）
現状の業務プロセスを可視化し、無理・無駄・むらを排除し、標準化・共通化を図る。
・ データ（Data Architecture）
各システムで使われているデータ項目（名称、属性、桁数）を統一し、データ交換を容易にする。 また、重複データの保有をなくし、集中化を図る。 データ構造の見直しも図る。
・ アプリケーション（Application Architecture）
各システムと業務プロセスを俯瞰し、処理の配置を見直し、標準化・共通化を図る。また、サービスの観点から機能を括り出し、既存アプリケーションの再利用・パッケージソフトの活用などを図る。
・ テクノロジ（Technology Architecture）
現状の標準技術と将来技術の見極めを行い、単にハードウェアの共通化だけではなく、ＤＢ管理システムやアプリケーションサーバ、ネットワークソフト等の基盤ソフトウェア（ミドルウェア）の統一化も図り、将来の拡張性、可用性を目指す。
これらの検討により、一言でいえば、無駄がなく、効率的で、拡張性のある、「繋がる」システム群が実現できます。
本書１９ページで、「ネットワークの広がりを、固定ネットワークの段階から、やわらかいネットワークの段階へ、さらにユビキタス時代の自在なネットワークによる新しい段階に分けてみると、それぞれに見える範囲が拡大しています。」といいました。
これを図で示すと次のようになります。
特に、これがユビキタス時代になるとＲＦＩＤのタグや、機器に埋め込まれたチップ、いろいろなセンサ、映像監視などで、見える範囲がさらに拡がります。
例えば、
・機械にＲＦＩＤなどのセンサを入れると、機械の稼働状況が見えるようになる、
・それから、お客様がＩＣカードや携帯電話を持つと、お客様が見えるようになる、
・また、工場のラインでＲＦＩＤを使うと、ラインの流れがリアルタイムに見えるようになる、在庫が見えるようになる、
・ さらに、ITSにより道路の渋滞が見えるようになる など、どんどん、見える範囲が拡大する可能性広がります。
事例を次に述べます。これは、ある大手スーパーと実証実験をしている事例で、お客様に、お勧めの商品を表示したり、店舗案内など、ユビキタスを活用したお買い物のお手伝いシステムです。
ご覧いただいた事例をもう少しシステムの動きでご説明しますと、お客様にご来店いただきましたら、まず、カードをご提示頂き、スマートカートをお渡しします。このカートにはアクティブなＲＦＩＤのついたパソコンを搭載してあります。
店舗内の無線ＬＡＮ環境を活用し、カートと情報サーバを連携させます。これによって、お客様の購買履歴，嗜好などのプロファイル情報に基づいたお勧め商品を紹介するなど、高度な情報提供を行います。
また、商品棚に設置されたＲＦＩＤの感知により、プッシュ型で商品推奨や、クーポン利用の通知などが可能になります。
将来的には、携帯電話を媒体とした家庭内情報家電との連動，デジタル放送との連動による販促活動など、店舗外と連携した情報提供・情報活用を目指すというものです。
狙いとしては、新規顧客の増加、既存顧客の来店頻度向上、買上げ点数増、買上げ金額増、クーポン利用率向上などが考えられています。
さらに、メーカや卸とタイアップしたパーソナル向けの広告媒体としても有効な手段として、その活用が考えられます。今後の店舗での利用可能性という事例です。
（2004年11月16日 ＳＥＣオープニングシンポジウム 富士通 斑目氏講演より引用）
災害時あるいは障害発生時にシステムの停止時間をどの程度許容するのかによって、システム構築／運用コストは大きく異なります。一般に、停止時間を0に近付けようとするほど、システムの二重化やデータのバックアップ方式の整備には多くのコストがかかります。そのため、システム開発においては、分析／設計段階でシステム停止により想定される損害額を算出し、それに応じたシステム投資額を見積もることが重要です。
災害時の復旧時間については、RPO(Recovery Point Objective：復旧ポイント目標)とRTO(Recovery Time Objective：復旧時間目標)という概念がよく用いられます（下図参照）。RPOは「障害発生から遡ってデータを復元できる時点までの時間」を表し、バックアップの頻度や処理のタイミングに影響します。一方、RTOは「障害発生から復旧までにかかる時間」を表し、バックアップ・データの保管場所や代替施設、要員の確保などに影響します。企業が扱う様々なデータを分類し、それぞれの重要性に応じた適切なRPO/RTOを定義しバックアップ方式などを検討することで、投資対効果を高めることが可能となります。復旧時間も非機能要件（可用性）のひとつです。
（図 RPOとRTOの関係）
＜解説１＞
システムにおける投資効果は、システムの性質に応じた適切な評価方法を適用することで効果が明確になります。
例えば、メール、グループウエアの導入、ネットワークの敷設・拡張等、インフラとして継続的に活用するものについては、回収という概念を適用しにくいので、対売上高比率、費用／人年等の目標値を設定し、緩めの定量的評価が向いています。また、他社とのベンチマークも有効です。
一方、従来のコンピュータ導入の目的であった、省力化、合理化を実現する業務効率型システムは、回収年限を設定することで、明確な定量評価によって効果を確認できます。
昨今、増加しつつある商品開発や販路拡大等の戦略型システムへの投資は、システム以外の要因と複合的に関連して効果が生み出されるため、ＫＰＩ（Key Performance
Indicator：重要業績評価指標）等の目標値を設定して、極力定量的に評価可能とする必要があります。同時に定性的効果は、ユーザ満足度などで評価し、最終的にはアプリケーションオーナの収益性改善効果で評価します。
＜解説２＞
システムの価値は、そのシステムに投資した額によるものではなく、システムから生み出されるもの（売上げの増大、コストの削減、利益の増大、販売機会の増大、マーケットシェアの増大など）の価値（付加価値）が重要です、この価値の指標の一つとしてＲＯＩ（投資効果）があり、投資額に対する利益額がどれくらいなのかを判断材料にしてマネジメントする必要があります。
このＲＯＩを指標にしてマネジメントすることにより、作ったが使えないシステム、使わないシステムなど、動かないシステムと言われる現象を極小化することができます。つまり、システムを企画、計画する時、ＲＯＩを指標とし、これを上げるための利用方法、運用方法、教育などもシステムの計画と一緒に考え、総合的に考えていくことが必要です。
概念データモデルを上流で作成する意義：
業務上で利用する言葉とその言葉の意味・相互関係を整理することが、システムの仕様の整合性を保障する上で非常に大事です。ユーザ・設計者の認識の違いを予め排除しておくことにより、手戻りを防ぐことができます。決して、データベースを作るためだけのものではない事を理解していただきたいと思います。
実例の参照
「超上流から攻めるＩＴ化の勘どころ Ｗｅｂ検索システム」（ＵＲＬ：http://sec.ipa.go.jp/index.php）
＜システム間インターフェース＞
個々のデータインターフェースの内容と、システム間のデータインターフェースを明確にします。そのための表現方法の例として『システム間インターフェース定義書』や『システム関連図』等が機能します。
＜アプリケーション･インフラ間インターフェース＞
上記説明と例示は、アプリケーション･システム同士の関連について示しています。ここでは、インフラとアプリケーションの関連について簡単に図示します。（下図「システム間連携イメージ」参照）
（図 システム間連携イメージ）
当初予算を守ろうと固く心に誓っても、その通りに進めることができるシステム開発プロジェクトは少ないと思います。まだ柔らかい状態だった要求を、きっちりと固めて行くのが要件定義工程です。
検討を進めて行く間に要件の増減が発生したり、必要機能の複雑度が予測を上回ったりするのは至極当然のことと言えます。どうすればそれを防げるかを考えるより、それを見越してあらかじめ予算に幅を持たせておくのが賢明でしょう。
幅の持たせ方は色々あります。例えば、要件定義開始時の見積金額を下限とし、そこに数％上乗せしたものを上限とする方法や、投資回収期間自体に幅を持たせる方法、あらかじめ要件につけた優先順位を幅に見立てる方法などです。いずれにせよ、費用対効果が出ない投資では意味がありませんから、きっちりと効果が出せるように範囲を設定することが重要です。
また、金額の提示にはコツがあります。現場には幅を持たせた状態で提示してはいけません。幅があれば、上限まで使っていいと思うのが人間です。最初は下限の金額のみを提示し、要件が膨らんだところで「絶対に超えてはいけない額」として上限を提示するようにしましょう。費用対効果を勘案した上での上限ですから、超えては意味がないのだということも強く主張できるでしょう。
▼予算が当初予定をどれだけ超過したらプロジェクトを取り止めるかを決めておく
システム化予算を確保する段階で、投資採算計算をどの企業でも実施するものと思います。合理的な予算超過のボーダーラインは、「目標利益が確保できるだけの投資額」であるはずです。
ただし、システムはプロフィットセンタ向けのものだけでなく、コストセンタ向けのシステムもあります。その場合、「目標利益」基準ではボーダーラインは設定できません。システム化によるコスト削減額が設定できるのであれば、コスト削減額を目標利益に見立てて、ボーダーラインを設定するべきでしょう。
とはいえ、システム化効果が金額としてすべて表現できるとは限りませんし、また法改正など外部環境の変化により、コストの視点だけでは判断ができない、システム化対応が必須となるケースもあります。このような場合は、QCDの何を優先させるかを鑑み、企業収支を圧迫しない範囲で適宜ボーダーラインを設定することが必要になります。
一方、プロジェクトを取りやめると、今までに投下した開発費用を無にすることになる為、現実的には以下のような回避策が採用されることがよくあります。
１． 開発規模を縮小し予算内でプロジェクトを進める
２． 開発を数フェーズに分割し、次期フェーズ以降については、別途稟議し予算化を図る
プロジェクトをやめること、続けることの２つのシナリオで慎重に比較し、より合理的な結論を検討することも重要です。
システム開発プロジェクトが開発対象システムを予定通り（品質・予算・納期など）に開発するために用いる管理手法の総称です。
近年は、国際的なデファクトの知識体系としてアメリカPMI（Project Management Institute）の「PMBOK Guide」などがあり、プロジェクトマネジメントの重要性が多くの企業に認識されています。
これまでは企業独自の開発標準を持ちこれに従って進められていました。独自の開発標準は、その企業内では有効ですが、その企業の中でしか通用しない「言葉」が使われていたりします。そのため、複数の企業が参加する大規模なプロジェクトや、国際的なプロジェクトでは適用が難しくなります。
開発標準はひとつのプロジェクトを適切に完了させる視点から作成されている場合が多く、個人の経験をこえて、次のプロジェクトに教訓を引き継ぐ事ができませんでした。
いまでは、SLCP（ソフトウェア・ライフサイクル・プロセス）の考え方を基本にし、システムの企画から開発、運用・保守までをひとつのサイクルとして考えることが主流になっています。
超上流工程のプロセスは、企業価値を高めるための経営戦略・事業戦略を基にシステム化計画が行われＩＴ投資額の大枠が決められ、要求定義のフェーズへと進みます。したがって、システム開発に対する予算枠は要件定義する前に決まっているのが通常で、その予算枠が、要件定義以降の作業に大きな制約となります。
この理由から、文中の「増えてもよい予算の範囲」とはこの予算枠の上限値であり、「当初予算を超過したらプロジェクトを取りやめる」か、または、あらかじめ決められている予算枠をオーバした場合は、ユーザ企業とベンダ企業がその予算内に収まるように、知恵を絞ることになります。この具体例として、「必要不可欠機能」と「あったほうがベター機能」など実現希望機能に優先度をつけ、その優先度の低い機能を開発対象から除外するなどして、予算枠内に入れる努力をすることになります。
このときに、ベンダは機能実現のための確固たる技術と見積り根拠を示し、ユーザは機能が削減されることによる業務への影響などを最下流の利用部門を交えて慎重に検討し、両者が真摯に歩みよる姿勢こそがもっとも重要な「予算超過時の配慮」になります。
承認のタイミングや承認者についてのルールは、社内の規程やマニュアルであらかじめ定めておくとよいでしょう。具体的な事例以下に示します。
■承認の考え方システムの構築にあたっては広範囲にわたる検討が必要であることから、以下に示すように、検討した内容に応じた承認手続きを踏む。業務見直し案の変更や開発規模の増大、スケジュール遅延などにより承認内容に変動が生じた場合には、再度変更に対する承認を得る。委託実施承認、設備導入承認、業務適用承認においては、提案理由の中でよりどころとなる計画承認書を引用すること。
また、連係先のシステムの改修を伴うなど影響範囲の広い案件については、計画承認時に連係先も含めた全体の投資額を提示し承認を得ること。連係先のシステムはこの計画承認に基づき、それぞれ実施承認手続きを行う。
a．方針承認（業務主管箇所・システム企画箇所共同起案、業務主管部長・システム企画部長承認）
承認事項：業務見直しの方向性（業務内容、影響範囲、規模）、システム化の範囲（対象業務、対象箇所）
b．計画承認（業務主管箇所・システム企画箇所共同起案、業務主管部長・システム企画部長承認）
承認事項：業務見直し案（業務内容、影響範囲）、システム化案（対象業務、連係先を含む対象範囲）、実施時期、投資上限額（連係先を含む）、金銭関係（科目別・期別）
ｃ．委託実施承認（システム企画箇所または開発管理Ｇ起案、システム企画部長承認）
システム化調査・分析関係業務委託／技術支援委託の承認の場合はシステム企画箇所が起案し、基幹システム化開発保守委託の承認の場合は委託管理箇所が起案する。
承認事項：委託内容、委託期間、委託金額、当年度予算・既実施額、予算箇所・実施箇所
ｄ．設備導入承認（システム技術Ｇ起案、システム技術マネージャ承認）
承認事項：導入設備（Ｈ／Ｗ、Ｓ／Ｗ、周辺機器）、設置場所、設置時期、設備総費用・累積実施額、当年度支出費用・内訳、予算箇所・実施箇所
e．業務適用承認（開発：業務主管箇所とシステム企画箇所の共同起案、業務主管部長・システム企画部長
承認、改良・維持：業務主管箇所マネージャ承認）承認事項：適用業務、実施箇所、移行計画（実施内容、期間）、業務適用時期
○業務フローと役割分担
システム化にあたっては、下図のような業務分担に従い、検討および設計を進める。
（図 要件定義までの業務フロー）
超上流工程で作成するドキュメントは標準化しておいたほうがよいでしょう。各工程で実施すべき検討の広さや深さを示すことによってプロジェクト参画者の意識をそろえることができます。ただし、ドキュメントを標準化すると、ドキュメントを作成すること自体が目的化しがちなので、様式を定めるだけでなく、各ドキュメントの作成目的や作成上の留意点も記載したいものです。特に、
・意思決定に必要な成果物
・次工程以降のインプットとして必要な成果物
・検討の過程で作成が必要となるであろう中間（補助）成果物
など、ドキュメントの利用局面を想定して、それぞれのカテゴリーに必要十分なドキュメントを用意することが重要です。
サンプルを下表に示します。
サンプルとして、「仕様変更管理手順書」と「仕様変更管理台帳」の例を以下に提示します。
-------------------------------------------------------------------------
■１．はじめに
本書は「XXX プロジェクト」におけるシステム仕様変更について、その変更管理手順を記したものです。
開発スケジュール遵守を優先し、変更管理に阻害要因が見つかり次第、適宜運用方法を見直します。
■２．変更管理開始日
XXXX年X月末時点の基本設計書をベースに本仕様変更管理手順書をA社・B社・C社の３社の合意が完了次第、即日運用を開始します。従ってXXXX年X月X日から開始することとします。
■３．変更管理目的
１．システム品質管理（仕様変更によるXXXシステム全体の機能もしくは他システムへの影響度合いの確認）
２．システム開発予算（総額予算内での開発規模の管理）
３．システム開発期間（XXXX年X月時点で稼働すべき案件の管理）
■４．運用基本ルール
１．仕様変更依頼、承認、調査、決定に至るまですべて電子ファイルで取り扱います。内容承認等のワークフロー的な部分も電子ファイルを移動させる形態とし、ファイルを更新していくイメージとなります。運用詳細は次ページ以降に説明します。（＝紙で出力して承認印をもらう形態はとりません。）
２．最終決定機関がXXXチームである場合はさほど問題になりませんが、それ以外の場合最終決定機関が多岐に渡るためスピード感を持って（１週間単位で処理を進める）取り組むことが重要です。
３．詳細設計検討時の仕様変更期間はXXXX年X月XX日～XXXX年X月XX日までとしますが、開発スケジュール遵守のため、この期間の後半になればなるほど判断基準が厳しくなると考えて下さい。
-------------------------------------------------------------------------
■５．仕様変更処理フロー ＜処理フローの流れを中心に見てください。＞
■６．仕様変更依頼／回答書 各フェーズ取扱い(例）
■７．仕様変更管理台帳（Sample）
＜解説１＞
超上流工程とは、システム設計に入るまでの工程の位置付けであり、小冊子ではシステム化の方向性、システム化計画及び要件定義を指します。共通フレーム９８では企画プロセスとシステム要求分析、ソフトウェア要求分析に相当します。
＜解説２＞
２０世紀におけるシステム開発は、フィジビリティスタディを含め、システム開発の話がＩＴ部門ないしベンダにきてからスタートしました。超上流の概念はそもそも、新しいビジネスの企みが生まれたときからシステムを含めて考えることを基本動作として要求します。
企業が活用するシステムは、現在企業の枠をこえて利用されています。商品開発や、販売戦略はシステムなしに実現できなく、システムのステークホルダは、ビジネスの企画者、システムの開発担当者、システムを使ってサービスを提供する担当者、代理店、提携する企業の担当者、アウトソーサそしてお客様と、かつてないほど広い範囲に存在します。
そういった、ステークホルダの要求を把握し、経営戦略を踏まえ、マーケットのニーズを満たす、ビジネスの企みを現実の世界に形としていくためには、仕組みとしてのシステムが不可欠となっています。
何が出来て、何が出来ないのか、出来るとしてそのためにどういう人がどのくらい、いつから、いつまで必要なのか、作るための環境といった物、場所、また資金、期間はどうなのだろうか、出来上がってからどういう環境で動くのだろうか、それにはいくらかかるのだろうか、こういったこと全てがシステム開発を軸に検討されなければ、企みは実現しません。
システム開発は今や、ビジネスに命を与える核の要素であり、システムの要件定義はビジネス設計そのものとなっています。間違いのないシステムデザインの出来たビジネス構想だけが成功という栄冠を勝ち得ます。まさにシステムの発注力だけが企業の競争優位を実現するといっても過言ではないのです。
＜解説１＞
決まった手順（プログラム）に沿って演算、処理を行う機械のことです。パソコン、ワークステーション、汎用機、スーパーコンピュータなどがあります。
＜解説２＞
コンピュータの教科書を読むと、ＥＮＩＡＣの登場、ノイマンに始まるストアードプログラムの概念といったストーリーで、仕組みとしてのコンピュータがその発展の歴史と共に記述されています。
確かにコンピュータの原理を学ぶには適切な内容であろうと思います。しかし、アセンブラ言語でｂｉｔ単位の処理をしていた時代ならともかく、現在ではコンピュータの原理を学ばなくともシステム開発に参加できますし、業務要件定義は可能です。
一方、コンピュータが何に使えるかということになると、その知識は体系化されていませんし、わかりやすい事例集もありません。
初めてシステム開発に参加する業務企画担当者は真正面からコンピュータと向き合うこととなります。
コンピュータを使うと、こういったことができるという利用技術はコンピュータそのものを作るための技術ほどには難しくありません。テレビディスプレイの原理を知らなくても、テレビディスプレイをビジネスに活用することは出来ます。しかし、コンピュータの原理そのものがコンピュータとかかわるときに必要といった漠然とした認識が、コンピュータを専門家に任せようと言う風潮を生み、その利用検討も忌避する業務企画担当者を生んでいるように思えます。
コンピュータもそろそろ、仕組みから入るのではなく使い方から入るようにしたいものです。
＜解説１＞
事業として何を行うか、収益をどのように上げるかといった仕組みのこと、つまり事業が成り立つ仕組み、やり方のことです。
＜解説２＞
「新しい技術は、新しいビジネスモデルを可能にする。」といった壮大な世界では、システム技術がトリガーとなっているのですから、当然のこととしてビジネスモデルの検討が実装システムの検討を伴って行われます。
また、大きな制度が施行される場合も同様です。例えば、確定拠出年金制度が創設された際、日本を代表する金融グループは米国４０１Ｋ制度の研究着手とほぼ同時期に、システム専門委員会を立ち上げ、レコードキーピングシステムの検討をビジネスモデル検討と並行して進めました。
一方、こういった巨大ともいえるシステム構築の場合でなくともビジネスモデルは振り返りの対象となります。
例えば、既存システムの利用者が広がるような場合、よくある例としては、オンラインの利用者が社員から派遣スタッフに広がる場合、単に利用者登録を増やすだけではすまないことが普通です。権限、セキュリティの配慮、運用の管理指標改定等が発生します。こういった利用者の広がりは運用キャパシティの見直しを要求する場合もあります。
▼コンピュータからのアウトプットで業務を行う（ワークフロー）
今から30年ほど前のシステムは、企業の中で仕事が行われ、その結果をコンピュータに入力し活用するといったシステムが大勢を占めていました。
勘定系はもちろん、勘定というように経理決算にむけた売り上げ数字を自動集計する目的が主でありましたし、情報系も、例えば、保険会社の営業成績速報は、長い間、黒板にまずその月の売り上げ数字を日々集計し、営業本部に電話をして集計するといったことが行われていましたから、電話で連絡していたものをオンラインの画面から入力し自動集計するものを作ったわけです。
そのような時代、コンピュータセンタのシステムが止まっても、営業が出来ない、各種の支払いが出来ないなどということはありませんでした。
今はどうでしょう。航空券の発券など、システムが止まったらまったくできなくなります。商社も保険会社との接続システムが止まったら、保険証券が出ませんので輸出入業務がストップします。海外旅行へいこうとして成田で海外旅行保険加入システムが止まっていたら困るでしょう。ＡＴＭや証券の決済システムが止まったら社会不安が起こるかもしれません。
いまや、コンピュータシステムの上で重要な業務が多く動いています。また、多くの人がコンピュータシステムのアウトプットに依存して生活しているのです。
以上のような構造を最大限活用したワークフローシステムを考えてみましょう。つぎの工程に情報を渡し、その情報にキックされて人が仕事をする。コンピュータが止まると仕事はまったく出来ません。みんな、コンピュータを向いて、仕事が来るのを待っています。このような仕組みが現在のコンピュータ活用の主流です。
いや、システムの今日的重要性はその機能だけでなく、現在のコンピュータに依存した社会基盤のもつリスクからくるものなのかもしれません。そうしますと、今日、システム開発にとって第一義に大切なことはまず品質、セキュリティを含めた安全性ではないでしょうか。
＜解説１＞
コンピュータへ命令を与えるソースコードを記述するための言語。プログラミング言語にはＣＰＵが直接処理できる機械語から、人間に理解できるように英語などを元に作られている高水準言語まで、様々なものがあります。
代表的なものとして以下のものがあります。
・アセンブリ言語
・手続き型言語（ＦＯＲＴＲＡＮ、ＣＯＢＯＬ、ＰＬ／Ｉ、ＢＡＳＩＣ、Ｃ）
・関数型言語（ＬＩＳＰ）
・論理型言語（Ｐｒｏｌｏｇ）
・オブジェクト指向言語（Ｓｍａｌｌｔａｌｋ、Ｃ++、Ｃ#、Ｊａｖａ）
・スクリプト言語（Ｐｅｒｌ、Ｒｕｂｙ、ＰＨＰ）
＜解説２＞
60年代から80年代にかけて、コンピュータを学ぶといえば、コンピュータの原理と、プログラム言語でした。システムの仕事にかかわると、アセンブラ、ＦＯＲＴＲＡＮ、ＣＯＢＯＬ、ＰＬ／Ｉといった言語を学び、マッチングや、テーブルサーチといった、プログラムロジックパターンを頭に詰め込み業務処理プログラムに取り組むことになりました。システムエンジニアといえば、一般企業では事務システム構築エンジニアであり、そのほとんどがプログラマでした。
現在ではどうでしょう、オープン系システムが幅を利かせ、オブジェクト指向が若いエンジニアの知的好奇心の対象となり、ウォーターフォールは正さなければいけない悪い技法のようなことを言われ、いつしかＣＯＢＯＬプログラマは、落ちコボルと揶揄されるようになりました。
しかし、オープン化が進んだ今日でも、大企業を中心に基幹システムはホストコンピュータが担っており、その信頼性は抜群です。加えて、ＣＯＢＯＬに限って言えば事務処理システム構築には十分な機能を有していて、加えて習得が楽です。だれでも、２～3週間も勉強すれば開発に参加できるようになります。それで十分とはいえないまでも開発チームの末席くらいは占められるのです。
この類の生産性の高さは新しいシステム技術にはない特徴といえます。ＣＯＢＯＬによって実現する誰でも参加できるというオープン化もまた、システム開発に求められる要素ではないでしょうか。
もちろん、ＣＯＢＯＬプログラマだけではシステムを構築できる時代ではありません。システムはホストコンピュータの枠を飛び出して、ネットワークに乗ってしまった現在、インフラにかかわる業務がシステム構築には不可欠となっています。こういった基盤担当者には高度のシステム技術専門性が要求されます。こういった担当と業務プログラムを開発する担当が分業できる体制は大規模システム開発には不可欠です。基盤技術者の専門性をＣＯＢＯＬプログラマに期待するのは無理です。しかし、こういったことを踏まえてもなお、ＣＯＢＯＬの魅力は衰えません。誰でもすぐ出来る「簡単なＣＯＢＯＬ」。その効果を見直してはどうでしょう。
＜解説１＞
ＩＴにおけるネットワークとは、複数のコンピュータ間を通信媒体で接続した通信網のことを言います。
電話回線、専用回線、ＩＳＤＮ、ＬＡＮ、インターネットが一般に知られています。
＜解説２＞
現代はネットワーク社会です、ありとあらゆる業務がネットワークを通じて処理され、利便性は革新的に向上し効率的になりました。一方、完全にネットワークに依存した業務運営を行うようになった結果、障害により少しでもネットワークが停止するような事態がおこると、社会混乱もおこしかねません。物理的ハブとなる電話局の火災で大阪の航空管制が止まった事件は記憶に新しいことです。事故や災害でなくても、電話局の交換機メンテナンス時の配線ミス、ＦＡＸがあらぬところへ言ってしまうということも起こっています。ネットワークといえども人の手作業から解放された存在ではないのです。
社会インフラとしてのネットワークは意外にもろい面を持っているのです。９０年代におこった多摩大停電は多摩川の橋の不法滞在者による焚き火が原因でした。そういったネットワークを活用したシステム設計は、災害や、事故に大変弱い面を持っています。論理的な紙の上の設計だけで開発を進めると危ないことがたくさんあります。ネットワークダウンに備えた有事設計、人間の手による代替策、コンティンジェンシープランを必ず作成することは大切な基本動作です。
＜解説１＞
要求（Wants、Needs)をシステム化するにあたり、実現可能かつ具体的な要件へまとめて行くための調査分析、定義を行う工程です。
経営戦略に沿い、「システム化の目的、目標は何か？」、「そのためには何をすべきか？」、「予算から見た適正な規模は？」など検討する工程です。
現状の業務分析と、システム導入によって何をどう変えるかの新旧分析と比較、基本処理要件、入出力要件、テスト要件、移行要件、運用要件、品質管理とセキュリティ、開発スケジュールなど要件定義書にまとめます。
＜解説２＞
要件定義という言葉を使ってコミュニケーションするとき、会話をしている当事者の頭の中では、要件定義が同じ意味でつかわれているのでしょうか。
要件定義は、最終的にはプログラム、ネットワーク、運用ルール等の稼働システムの実体を定義するための作業で、「使い物になるシステムが出来た」ことになるための条件全てが、要件といえます。
要件が議論されるときそれは常に、当事者の立場から来る関心が中心となるため、勝手な解釈、思い込み、決めつけといったことが発生しやすい性格のものです。
かつて、コンピュータは、バッチシステムの時代においては、コンピュータに情報を入れ、プログラムで処理し、加工したデータをプリンタなどで作表し利用するといった使われ方をしていたので、要件も概ね、その範囲で考えればすみました。例えば、インプットとアウトプットを関係者、利用者と定義し、データ加工の手順をプログラム作成要件として整理すればシステムは開発でき、それなりに動きます。インプットとアウトプットが業務要件であり、システムの機器および制約そして、プログラムロジックがシステム要件でありました。
ネットワークの時代、こういった木造一戸建て的システム開発は通用しなくなっています。メンテナンスは都市再開発的であり、新規大プロジェクトは、ニュータウン建設に似ています。そこはホストコンピュータの周辺とプログラムだけを見ていれば済んだ世界とはまったく異なる世界であり、システムを稼働させ、利用に供するためには広い範囲で要件となるものを洗い出さなければなりません。
例えば、完成したシステムを自社コンピュータセンタで運用するか、アウトソースするかでシステム要件はまったく異なってきます。作り方が違ってきます。あれが欲しい、これが欲しいと機能要件だけ業務企画担当者がならべても、機能だけを見ていては出来上がったシステムは動きません。電子取引なら認証の契約手配が必要ですし、Ｂ２Ｂの接続なら、相手運用企画、システム企画にあわせる調整が必要となります。こういった、使い物になるシステムのための、要件実現の核心は、希望する業務要件と、実現のためのシステム要件をあわせて検討します。両方を天秤にかけるがごとくあわせ検討することです。要するに、引っ張り合いの関係にあります。
したがって、今日的要件定義の奥義は、業務企画担当と，ＩＴ担当のコラボレーションです。ビジネス企画の段階からＩＴの専門家を入れ実現に向けた設計を繰り返すことが必要です、この超上流における反復検討が要件定義を、的を射た確実なものとしていくのです。
ちなみに、要件定義において今日、俎上に載せるべき事項を4つのフィールドにまとめたので参考にしていただきたい。
（図 要求から要件へ、4つのフィールド）
情報システムの利用者 (user) とは、大きく最終利用者 (end user) と、代表利用者 (representative
user) の2種類に分けられます。
最終利用者とは、情報システムを直接操作する人、あるいはシステムからのアウトプットを自らの業務に直接利用する人を言います。情報システムの拡がりに対応して、昨今のシステムの利用者は、企業内の経営層や従業員にとどまらず、代理店などの提携先企業、重要個客、不特定の消費者まで含まれることになります。
代表利用者とは、情報システムの開発において、情報システムを企画する人、および上記の最終利用者の要求を代表してとりまとめる人を言います。代表利用者の役割は、これまでの企業内システムでも、例えば生産管理システムにおける工務部門、販売管理システムにおける営業統括部門などが担ってきました。しかし、システムが企業外の最終利用者に及ぶようになると、不特定の利用者へのサービス性の考慮、運用後の要望対応など、新たな要求定義の難しさが発生します。
＜解説１＞
社内の業務を外部の専門の会社に委託することです。外注、外部委託とも言います。
＜解説２＞
業務アウトソースはいまや、花盛りで、どこの企業でもコア業務と付随業務を洗い出し、後者をアウトソースし効率化を図っています。お客様サービスの観点からもその道のプロが業務を担うアウトソースは最高のサービスを実現するために有効活用すべき手法です。
システムの世界でも、古くはプログラミング業務やデータパンチなどを外部業者に依頼しアウトソースを活用してきました。現在ではバッチシステムの世界でさえ、高度の技術を要する印刷などは印刷プログラムの開発メンテナンスを含めてアウトソースするようになっており、企業間のデータ提供、さらには基幹のハードウェア運用管理もアウトソースする例が多くなっています。
これらのアウトソースは依頼側が内容をよく把握し、管理が出来ている場合はきわめて効率的に機能しますが、システムが業務の写像であるがゆえに、アウトソースすることによって企業で責任を負うべき部分がブラックボックスになったり、適切なトレーサビリティ、モニタリングが機能しなくなった場合はビジネスリスクとなりかねません。
何事もそうですが、可視化し管理できるようにする仕組みがアウトソース成功の鍵と言えます。
＜解説３＞
社内の業務の計画から実施までを外部のノウハウのある専門の会社に委託することです。これにより、企業のコアコンピタンスを集中させ、経費削減等の効果が得られます。また、環境の急激な変化にも柔軟に対応できるメリットもあります。ただ、社内に技術者がいなくなってしまうデメリットもあります。
＜解説１＞
ＩＢＭのZachmanが１９８７年に提唱したものが全体最適､つまりＥＡ（Enterprise Architecture）の始まりです。 縦軸は経営者、事業責任者、IT戦略企画者、ITシステム責任者、IT開発/運用者、横軸は５Ｗ１Ｈとし、３６のセグメントに分け、全体の整合性を保ちながら各セグメントを分析していくことで、全体としての整合性と最適化を目指す考え方です。
この他にも色々な方法が提唱されましたが、米国政府の採用した方法が最も有名であり、日本政府もその考え方を導入しました。 この方法は、業務・システムを４つのレイヤー（業務、データ、アプリケーション、テクノロジ）に分けて考え、現状（As-Is）モデルの分析、理想（To-Be）モデルの創出をし、企業の体力等を考慮して実際のシステム構築のターゲットとなる次期モデルの計画を策定するというものです。 日米の両政府が採用した方法であり、簡単で分かりやすいため、今後は民間企業でも普及すると考えられます。
日本のトップ企業では、米国のＳＯＸ法の関係で何らかの動きをしており、２００９年には日本版ＳＯＸ法も予定されており、中堅企業でも現状システムの可視化ということが重要になりつつあります。
また、各部署独自で導入したシステムが乱立していること、２００７年問題としてシステムの詳細を熟知している人が定年を迎えること、Ｍ＆Ａでの企業統合が多くなり、システムの統合機会が増えたこと、等により、今後も各システム単位の最適化ではなく、全社を見渡しての最適化がクローズアップされてくることが予想されます。
実際に最適化を行うためには、現状の可視化、標準化・共通化、ルール化（ガバナンス）がキーワードです。 データの共通化を行うためには、単にデータベースの再構築だけでなく、アプリケーションの修正にも及び、費用と期間が多大に必要となるため、長期的な視野で、じっくり検討を進めることが肝要です。
＜解説２＞
●開発ルール
担当ごと、違う開発言語、開発ツール、開発手続き手順で仕事を進めるようなことは、教育、開発環境維持、担当者異動、外部開発要員の登用などあらゆる局面で非効率です。
●端末等運用環境の統一
テストの手間、展開の煩雑さ、機種入れ替え、サーバＯＳのバージョンアップなど、端末一つ取ってみても、複数メーカを利用している場合開発、メンテナンスに大変な負荷がかかるシステムの運用環境はぜひ統一したいものです。
例えば、プリンタが5機種導入されていれば、プリンタを使用するアプリケーションの改定の都度、全機種のテストが必要となるため、1機種の場合に比べて5倍の手間がかかります、またプリンタの機能によって出来ることと出来ないことがあるため、（例えばバーコード処理、連票印刷）開発時に要件定義が複雑になります。
（プリンタの設置部署によって出来る、出来ないが発生します）さらに、入れ替えの都度テストが必要となり、担当者はそれだけに一年中張り付くこととなります。
このように、ネットワークに接続する端末利用技術の統一等、ＩＴ部門に課せられた課題のひとつが、全体最適の実現です。
ビジネス企画、事業内容にも全体最適があると思いますが、システム開発における全体最適はより具体的です。
みなが同じ洗練された、合理的でシンプルな仕組みの上で開発することが品質と生産性の向上、そして、開発コストを下げる鍵となります。
システムにおけるうまい、安い、早いは全体最適の追求から始まります。
企業としての本流を明確にし、その実行に向けて必要な資源（人材、情報、物資、資金、技術力、開発力、販売力、情報システム等）や機能（プロセス、ルール、フロー）を確実に把握できれば、他社との差別化を可能にし、異業種や海外への進出を含む、競争力強化に繋がります。
つまり、明確な目的を提示して、それに対する優位点と課題を正確に確認し、実現のための具体的な方策を持ち、強力な実行力のもと着実に推進し、価値を創造できる体制を維持して、独自の存在を明示できていることを、競争優位にある、といいます。
今日では、この状態確保に、情報システムが多大に影響していることは言うまでもなく、各種強みの複合化や、弱みの改善等に大きく機能している。経営を構成する、事業、業務、情報、組織等の構造を統一化し、それらの連携をより強固なものとすることで、さらなる競争優位を生み出す効果を持ちます。
＜解説１＞
情報システムの発注者としての責任を、また、開発が済んで受け入れ稼働後のシステム・オーナとしての責任を、いかに全うできるかの度量の範囲を発注キャパシティといいます。システムが運用される時点での状態、およびシステムが組み込まれて機能するビジネス全体について、その効果をどれだけ意識した推進体制を敷けるかを指します。
具体的には、状況やタイミングに合わせた要件の確定と提示、その確実な遂行のための組織および役割分担、承認体制の整備、稼働後の業務や他システムへの影響度合いの把握、プロジェクト推進中の適切な管理力の発揮、といった事項を実行できるレベルが、発注キャパシティの広さといえます。
＜解説２＞
システム開発で受注キャパシティという言葉は一般的ですが、発注キャパシティと言う用語は聞いたことが無いでしょう。従来のシステム開発では、開発を依頼する側の要員がネックになってシステム開発が立ち上げられないことはあまりありませんでした。システム開発をはじめるにあたっては、最初に何を作るのか決めなくてはなりません。つまり、まず依頼側から、希望や要求の形で提示され、これを受託側が聞き、実際、形にするシステムの要件として整理し、依頼側が承認し実際にシステム開発に取り掛かるというのが一般的なストーリでした。
かつての開発では、例えば60年代、70年代の主流であったバッチシステムでは、依頼側からの希望、要望はかなり具体的な個別アウトプットでした。例えば、給与明細のこの部分をこうして欲しい、作るサイクルを変えて欲しい、2部作って発送先を増やして欲しい…などといったものでした。新しい物を作る場合でも、従来行っていた処理を踏まえてこう変えたい、したがってこういった内容の表を作ってもらいたい…という内容でしたから、だいたいの説明で、受託側もシステム要件を把握できたわけです。また、要件のブレも、その担当者が使う、ないしその担当者が責任を持っている部門が使うというものが多かったですから、まずブレない、決めたとおりに作ってうまく動けば、大満足と言うことになったのです。
しかし、現在の状況は大きく異なっています。システムを使う人は、自分、もしくは自分の管理する部門ではなく、会社の外に利用者がいるところまで広がっています。システムを依頼する人は、システムを利用して商売をするという意味では利用者ですが、実際に使うという意味では利用者でなくなっています。利用に供する、提供者になっています。
さて、このようにシステムの利用が広がり、様々なステークホルダが登場してきますと要求はきわめて多様で、大量になります。もともと、ビジネスの新企画には夢も希望も企みもありますから、これを開発できる設計図のレベルまで、落とし込むのは容易なことではありません。おまけに、担当者で決められないことも多く出てきますので、ブレも大きくなります。
受託側がいくら熟練のエンジニアを用意しても、依頼側がシステム要件に落とし込めるレベルまで、要求や、プランをまとめ、噛み砕き、整えないとシステム開発は動かないのです。さらに、技術面でもオープン化が進み、業務要件の実現にはプログラム技術だけではなく、システム構築技術力が要求されるようになっていますので、こういった点につき、受託側の提案を理解して判断決断することも依頼側に要求されます。
今や、受託側以上に、依頼側の作業は複雑で多いといえましょう。こういった作業、役割を担うＩＴリテラシーのある業務企画担当者、またＩＴ担当者がいて、システム開発は初めて立ち上げられます。これが、発注キャパシティなのです。今や、発注キャパシティを用意することなくして、ビジネスの企みは実現できません。ＩＴガバナンスの重要課題といってよいでしょう。
新規で構築したシステムはそのままの状態で何年も使用できる訳ではありません。例えば、法令変更への対応や、組織の統廃合、ソフトウェア／ハードウェアの更新など、必ず機能の追加、変更が伴うものです。
その作業は、追加・変更機能の要件定義、設計、開発のみならず、他のプログラム、システムへの影響の調査も行わなくてはなりません。その意味では新規構築よりも時間、工数がかかるのが一般的です。
本来、新規で構築するシステムはそのライフサイクル全体で発生するコストを考え、保守しやすい設計を心がけるべきです。（設計思想の統一、ネーミングの統一、コーディングルールの統一、データの一貫性等）
消費者の多様なライフスタイルへの対応、企業のグローバル化によって、オンラインサービスを２４時間、３６５日受けられることが当たり前となってきています。サービスを受ける顧客から見れば便利になりましたが、サービスの提供側はシステムの故障やメンテナンスに対応するために、システム面、運用面（人間系も含む）について十分検討しなければなりません。
システムについては、ハードウェアの二重化は必須です。
例：銀行では定期的にＡＴＭに現金を補充しなければなりません。２４時間、３６５日のサービスを提供するためには、少なくとも補充時間内は別のＡＴＭを稼働させておかなければならないため、店舗でのＡＴＭは２台以上が必要となります。また、計算センタが地震で被災した場合に備えてのバックアップセンタの検討も必要です。
運用に関しては、まず、物理的な制約を考慮しなければなりません。すなわち、法定点検などの保守のための一時停止です。これは避けられない、というより、さらなる安定稼働のためのオーバーホールの意味があるため、運用設計上、考慮が必要となります。現在では、複数サーバの組み合わせや運用ソフトの改善により、「活性保守」（完全には運用を止めないでオーバーホールを行う）という考え方も一般的に知られるようになってはきましたが、一時停止の持つインパクトとそれをしないための投資を天秤にかける必要があります。
次いで、接続先との関係があげられます。すなわち、完全に自部門内に閉じているシステムの場合はこれには当たらないが、そういうシステムはむしろ少数派です。リアルタイムで情報の連携を行っている場合などは特に、その接続先のシステムの運用等との関連を押さえ、双方の運用に支障の出ない運用・保守設計を行うことが必要です。
また、グローバル企業が多くなった昨今では、国や地域によるシステム利用時間帯の相違も考慮に入れる必要があります。この場合、「日締め」の概念とも関わってくるため、一概にシステムサイドの問題とも言い切れませんが、上記に述べた法定点検などの保守を行うタイミングなど、システム側から考慮すべき点も多くあります。
なお、この他に関連して考慮しなければならない点として、故障箇所と影響範囲の可視化による早期リカバリや、資源の最適化による運用の継続など、停止が起こってしまった時の迅速な回復や予防保守の考え方などがあげられます。この際、人間系の対応として、異常時の対応を十分に検討し、手順と体制を確立しておく必要があります。そして訓練を定期的に行うことが重要です。また、社内の連絡体制と共に、最も大切な顧客対応についても十分に検討しておくことも重要です。システムは、人間が作る以上、「絶対」はあり得ません。したがって、問題発生を想定した対処（次善の策）が、実は有効であることが多いのです。
＜解説１＞
企業情報システムの開発は、要求を提示する責任のある最終的なシステム利用部門、システムの運用部門、開発時の参加部門、の3者の協働があって初めて成り立ちます。要求は単独で提示できるものではなく、ITが持つ技術的制約、運用上の制約を考慮しなければ現実的な要求になり得ません。従って、利用部門が一方的に発注者で、情報システム部門や外部ベンダが一方的にシステム提供者となるような図式は、本来的に情報システムの開発において成立しないものと考えなければならないのです。
要求を提示する側と要求を受けて開発する側が明確に分離できる、という立場は、欧米のシステム開発での慣習に沿ったもので、この傾向を反映したソフトウェア工学研究が日本では適用しにくい理由がここにあります。論理的には要求者と開発者の役は存在しますが、さまざまな意思決定プロセスにおいて、協働がうまく機能するような人的なプロジェクトマネジメントが、日本的な情報システム開発ではますます重要になります。
＜解説２＞
情報システムの提供者をユーザ企業の情報システム部門とベンダだと捉えるのはあまりにも狭い考えです。また、情報システム開発の現実ともずれています。この捉え方ではシステム開発を的確に捉えているとはいえず、今後ますますシステム開発を捉えがたくしてしまいます。
情報システムの提供者を狭く捉えたのでは、システム開発における情報の共有や役割の分担などを的確に行えず、またシステム化の目的や利用者のニーズを情報システムに反映することも難しくしてしまいます。
情報システムの提供者には、従来の情報システム部門やベンダだけではなく、企画部門と情報システム部、さらにはベンダがいっしょになってビジネスモデル作りから始めることもあるでしょう。また、新たなビジネスを創出し、市場の開拓に乗り出すような場合には計画段階のはじめから経営者の参画が必要なこともあるでしょう。
情報システム開発におけるステークホールダが多様化していることを踏まえて、システムの提供者という概念を、企画部門も情報システム部はもちろん、さらには経営者までも含むものとして捉え直し、それぞれの役割と責任に応じてシステム開発にコミットしていくことが求められています。
説明責任という言葉は、最近よく耳にしますが、直訳をそのまま思い浮かべると、ここで言う「説明責任」とは異なるため、注意を要します。
まず、文脈上、「発注側、受注側双方の」という修飾語がついているように、ここで言う「説明責任」とは「お互いが、自分の考えていること、必要としている情報を、過不足や誤解なく相手に伝えるための義務を負うこと」であり、この「お互いが」という部分が、通常の一方向の説明責任とは大きく異なります。（このとき、発注側にとっては、「要件確定責任」を負うことが「説明責任」の前提となるのは言うまでもありません。すなわち、説明する内容を相手に伝える前に、その中身について確定していなければならないのは当然です。）
また、言外に込められている意味として、「発注側から」「受注側から」だけでなく、同じ「発注者内」「受注者内」でも、役割の違うステークホルダ（例えば、経営者から業務担当者へ、設計者から開発者へ、など）間の「説明責任」も重要です。
要は、情報の出し手と受け手が、各々出せる情報、欲しい情報を理解しあい、交わらない部分をいかにして補うかを一緒になって考えることが求められるのです。それは、従来ありがちだった、発注側の「行間を読め」式の要件提示、それに対する受注側の都合のいい解釈、といったプロジェクト失敗への一里塚を回避するための必要条件に他なりません。
個人情報の誤った取り扱い（本人の意図しない利用や流用、ずさんな管理での流出）をしないように、一定数以上（5000名）の個人情報を取り扱う事業者を対象に義務を課す法律のことです。
国民が高度情報通信社会のメリットを享受できる適正な個人情報の取り扱いを目的とする。（内閣府）
個人情報とは、個人に関する情報で、これに含まれる氏名、生年月日、その他の記述等により、特定の個人を識別することができるもの。（内閣府の定義）
コンプライアンス（compliance）とは法令遵守と訳され、企業がその経営や活動において、法令や規制を守ることをいう。単に法令に留まらず、社会通念、倫理、道徳などを含めた広い意味に使用されることが多い。
コンピュータ資源の有効利用及び管理のためのソフトで、「基本ソフト」とも呼ばれます。その機能はキーボード入力や画面出力といった入出力機能やディスク内データの入出力及びメモリの管理など、多くのアプリケーションソフトから共通して利用される基本的な機能を提供しています。
プログラマは、OSの提供するこれらの機能を利用することによって、開発の手間を省くことができ、アプリケーションの操作性を統一することができます。
汎用機（ホストコンピュータ）全盛の時代、OSのバージョンアップはなるべく行わない、行っても最小限に留めるのが一般的であり、出荷直後の製品より、品質が保障されている（枯れている）数年経たものを導入していました。メーカのサポートは充実し、サポート年数も長期間でした。
現在も同様、安定稼働しているものは触らない方針で運用している所もあります、しかし、ネットワークに接続している場合、セキュリティなどの問題から、メーカのサポートが切れた物を使用し続けることは好ましい状況ではありません。
インターネットは、TCP/IP（通信プロトコル）を用いて全世界のネットワークを相互に接続したコンピュータネットワーク（情報通信インフラ）です。
インターネットは、その特性（オープンでの共同利用が前提）から、セキュリティには充分な注意が必要とされています。
ユビキタスコンピューティング（ubiquitous computing）のことです。
「いつでも、どこでもコンピューティング」とも言われ、社会のあらゆる所にコンピュータが存在するが、その存在を意識させることなく処理を行なうことを言います。
１９８９年にXerox社のパロアルト研究所が提唱したコンセプトで、１つのコンピュータ（ホスト機）が多くのユーザをサポートした第１世代、１人１台のコンピュータ（パソコン）を持つ第２世代に続く第３の世代のコンピューティングで、１人が多数のコンピュータによりサポートされる環境を言います。
サプライチェーンマネジメント（SCM／供給連鎖管理）は、コンピュータを使って、関連する取引先との間で材料調達／仕入れから商品の受注、商品在庫、物流、販売などの一連の流れを総合的に管理することです。
すなわち、ＩＴを利用しジャスト・イン・タイムを実現するシステムです。これにより余分な在庫（中間在庫、商品在庫）を削減するなど、コスト削減を実現します。
モバイル（ｍｏｂｉｌｅ）は本来、「動かしやすい」、「融通のきく」、「機動性のある」という意味ですが、ビジネス用語として転じて、①外出先で文書やデータを作成する。 ②自宅やオフィス以外の場所からネットワークに接続するという意味で使用します。
最近のノートパソコンやＰＤＡには、インターネット接続やメール送受信の機能が標準で搭載されているため、モバイル＝外出先でインターネット接続して用いるという意味で使用されます。
メインフレーム（mainframe）は、汎用機、汎用コンピュータなどとも呼ばれ、企業の基幹業務システムなどに用いられています。 電源やCPU、記憶装置を複数もち、並列処理など性能向上がなされた機種もあり、耐障害性にも配慮がなされています。 利用者は、ネットワークを介して接続された端末を用いてコンピュータを利用します。 データの処理や保存はすべて中央のコンピュータが行ないます。
近年のメインフレームはネットワークを介した大型サーバとして位置付けられ、多量データを高速で処理する業務で使われています。
ソフトウェアやシステムの着想から最終的に廃棄されるまでの期間をライフサイクルといいます。この期間に発生する成果物や情報の連鎖をプロセスとして捉え、ライフサイクルを構成する一連のプロセスの集合をライフサイクルプロセス、またはライフサイクルプロセスモデルといいます。ライフサイクルを構成するプロセスの例としては、企画プロセス、開発プロセス、保守プロセス、運用プロセスなどがあります。また開発プロセスを要件定義、設計、プログラミング、試験といったプロセスに細分化して捉えることもできます。
ISO9001やCMMIでは、開発組織が自らひとつ以上のライフサイクルプロセスを定めることを想定しています。
ソフトウェアライフサイクルプロセス規格ISO/IEC 12207、およびシステムライフサイクルプロセス規格ISO/IEC 15288を参照。
プロセス改善およびプロセス能力判定のためのプロセスアセスメントの国際規格です。「概念及び用語」の第一部、「アセスメントの実施」の第二部、「アセスメント実施の手引き」の第三部、「プロセスの改善及びプロセス能力判定のための使用の指針」の第四部、「規範プロセスアセスメントモデル」の第五部で構成され、第二部は規定(Normative)であり、他は参考(Informative)です。
プロセスアセスメントを参照。
品質マネジメントシステムの国際規格です。
ISO9001規格を利用した品質マネジメントシステムの審査登録制度を指して使われることもあります。
品質マネジメントシステムを参照。
ＪＵＡＳは、（Japan User Association of Information System）の略で、正式名は、日本情報システム・ユーザー協会といいます。
ＪＵＡＳは平成４年７月に設立されました。
沿革：＜沿革＞
・昭和３７年４月 日本データ・プロセシング協会創立企業や団体においてコンピュータ業務に携わる管理者・技術者が、情報交換・研究交流・相互研鑚の場として創立。
・昭和５６年２月 社団法人日本データ・プロセシング協会設立
情報化の進展を契機に、協会の社会的役割と責任体制を明確にするために社団法人化
・平成４年７月 社団法人日本情報システム・ユーザー協会に全面的に拡充改組
広域情報化に代表される経営・情報化環境の変革に対応するために、ユーザの立場での産業情報化の推進を目的とする団体として組織・運営体制を改革
▼システムライフサイクルプロセス
▼ＩＳＯ／ＩＥＣ１５２８８
ISO/IEC 15288システムライフサイクルプロセス規格は、システムレベルのプロセスを定義しています。この規格は、ソフトウェアとハードウェア、そして人間系を含めた幅広い視点である「システム」を対象としています。これは、何階層にも及ぶ大規模システムや、ミッションクリティカルなシステム、複雑な通信システム、組込みソフトウェアであるシステムLSIなどあらゆるシステムの調達・開発・管理に利用できる規格として制定されています。
システムの構想からシステムの廃棄にいたるまでのライフサイクルプロセスが、エンタープライズ、プロジェクト、テクニカルの3つの視点から構成されています。
ライフサイクルプロセス、ISO/ IEC 12207を参照。
業務パッケージとは、特定の業務向けに汎用的に利用できる既製のソフトウェアを指します。用途としては、給与計算など単一の業務を対象とするものから、企業の主要業務（財務・管理会計、人事、生産、調達、在庫、販売など）を包括する統合業務パッケージ（ERPパッケージとも呼ぶ）など多岐にわたります。
企業が業務パッケージを採用する利点としては、システムを一から開発する場合と比べ開発コストが抑えられることや、業務パッケージが提供する優れた業務プロセスを企業に導入できることなどがあげられます。
業務パッケージと実際の業務に差異がある場合には、業務パッケージに機能追加・修正を行うカスタマイズや、アドオン（追加プログラム）の開発が行われます。ただし、一般には、このカスタマイズやアドオン開発はできる限り少なくするべきと言われています。というのも、自社の業務に合わせて業務パッケージのカスタマイズやアドオンの開発を行えば行うほど開発コストは増加し、上述した業務パッケージ導入の利点が得られなくなるためです。また、カスタマイズを行うことで、システム稼働後の業務パッケージのバージョンアップ対応に手間とコストがかかるデメリットもあります。
ASP（Application Service Provider／エーエスピー）とは、ネットワークを通じて、アプリケーションソフトやそれに付随するサービスを顧客に提供することを言います。利用者は、ASP事業者の保有するサーバにネットワーク経由でアクセスし、サーバ上で動作するアプリケーションソフトを利用します。
ASPを利用する事で、利用者のパソコンには個々のアプリケーションソフトをインストールする必要がなくなり、利用企業の情報システム部門の負担のひとつであるアプリケーションソフトの維持管理にかかる費用や手間を節減することができます。
ＲＦＰ （Request For Proposal ／アール・エフ・ピー ）は、開発提案依頼書などと訳されます。
ＲＦＰは、ユーザ企業がベンダ企業に対して、開発提案書を求めるために作成します。ＲＦＰを作成する目的は、ユーザ企業の要求を正確にベンダに伝えることであり、文書にすることで、漏れや誤解を少なくでき、複数のベンダ企業に提案を依頼する場合でも、ＲＦＰにより前提条件を同じにでき、提案された内容の比較も行いやすくなります。
近年、技術の多様化や、システム化の対象となる業務範囲が広がるなど、RFPの重要性は今まで以上に高まっています。
ＲＦＰにはシステム構築の目的や主要な機能、それにより期待する業務上の効果のほかに、予算やスケジュールなどを書き込みます。 また、要件定義までを自社で実施し、開発以降をベンダに依頼する場合には、要件定義の作業成果を盛り込みます。
開発するシステムやユーザの都合により、早期にＲＦＰを提示する場合もありますが、未確定な情報を含むことが多くなる為、これらの内容を明示すると共に、契約に反映させたり、確定時での見直しを前提とするなど、段階的にＲＦＰ・提案を実施することが必要であることをユーザ・ベンダで共通に認識する必要があります。 本書では、ＲＦＰを開発工程に合わせて①～③の３段階に設定しています。
データモデルとは、企業において重要となる「モノ」と、それらの「関連」をモデル化したものです。一般には、Ｅ－Ｒモデルと呼ばれるものがこれに相当します。データモデルを構築することで複雑な企業構造が単純化されるため理解しやすいものになります。このモデルは開発担当メンバのコミュニケーション手段として用いることも可能であり、データベース構築のおおまかな指針として用いることもできます。
データモデルは、対象を表現するデータ群の構造を一定の規則に従って図式化したもので、データ対象の構造を表す概念データモデルと、データ構成の構造を表す論理データモデル、データ記録形式の構造を表す物理データモデルに分類されます。通常は概念データモデルを、単にデータモデルと表現し、概念データモデル作成をデータモデリングと表現することがあります。
概念データモデルは、データによって表されている対象（世界）が、どのように構成されているかを表すモデルです。「どんなデータがあるか」、「データ項目間にどんな関係があるか」が記述されます。
「データがＤＢＭＳに、どのように記録されているか」という物理的な制約とは無関係に作成されます（実装独立）。一般にＥ－Ｒ図で書かれる事が多く、ANSIの概念スキーマの一部と外部スキーマに対応しています。
▼図2.3は、（２）で述べた、事業、業務システム、ITシステム、ソフトウェアの関係を、開発の流れで見たものです
図2.3において、事業としての評価は、当初計画した「システム化の方向性・システム化計画」に対比して行います。ここで狙った価値が実現されたかどうかが評価の観点になります。同様に運用テストでは、要件定義に対してシステムが正しく構築されたかどうか確認し、システムテストでは、システム仕様どおりに構築されていることを確認します。このことは、チェックの観点やテスト項目が、対応する要件定義やシステム仕様、ソフトウェア仕様から導出されることを意味しています。正しいシステム化計画、要件定義、システム仕様、ソフトウェア仕様がなければ、満足なテストは実施できません。
特に注意すべきことは、要件定義の正しさを検証するのが運用テストでは「なく」、システム仕様の正しさを検証することがシステムテストでは「ない」ことです。運用テストの段階で要件定義の誤りが見つかると、大規模な修正が発生し、納期やコスト計画を守ることが困難になります。要件定義やシステム仕様の中で曖昧だったこと、開発者に伝わったかどうか自信のないことを、テストの段階で確認しようとする姿勢は、極めて危険です。間違っていたことが分かっても取り返しがつかないからです。
要件定義の正しさは、まず要件定義工程内で厳重にチェックしなければなりません。また、要件定義を受けて、システム設計を行う段階でも、要件の正しさを検証および妥当性確認することになります。さらにソフトウェア設計やコーディングの段階でも、要件の誤りに気づくチャンスがあります。運用テストまで持ち越されるのは、深刻な事態であると捉えるべきです。
怪しい、自信がないと思うことは早めに確認することが肝要です。
▼承認された要件が前提となって開発が進み、要件自身の間違いがあった場合は、要求仕様の変更として当初予算とは別の手当てがなされるのがあたりまえとなるような業界ルールです。
要件を確定しなければ、ベンダは納期や費用についてコミットできません。要件定義に要する工数も、要件定義後の設計開発テストに必要な工数、費用、開発期間も、要件定義が完了するまでは明確化することは困難です。したがって、要件定義工程までは委任契約とし、要件が明確化された時点で仕様を凍結し、凍結した仕様に対して請負契約を結ぶことが妥当と考えられます。中身の判らないまま一括請負契約にすることは、無理か無駄のどちらかになる可能性が高まります。仕様凍結後の仕様変更は追加料金を要求されるからと、仕様凍結を先延ばしにすると、工期を浪費し、開発期間の後期に作業が集中して品質の低下や納期の遅延を招きます。多少の仕様変更はやむを得ないものでもありますが、大きな仕様変更が発生しないように、上流工程で要件やシステム仕様を明確化し、関係者でよくレビューすることが重要です。上流工程における検討事項、選択肢をできるだけ網羅的に提示することがベンダ側の責任でしょう。重要決定を先延ばしして作業を進めることは、無駄な作業を行い、手戻りを起こさせることになり、実質的な進捗にはなりません。ユーザ側の立場からも、仕様変更、要件追加のルールを予め定義しておくことは大切です。システム開発に対する責任をベンダと分担することにより、結果として品質の向上・コスト・リスクの削減につながっていきます。
仕様凍結がどうしてもできないときはどうするか・・・ですが、仕様変更のやり方を契約で縛って運用する方法もあります。
顧客から仕様凍結後に出てくる仕様変更要求に対して、その変更が及ぼす影響（納期、コスト、体制など）を顧客が了解し、要求書に対するベンダの回答書に合意印（納期がどれくらい延びるのも了解、追加費用の支払いも了解など）を得てから着手するものです。
開発品質の向上に特効薬はなく、設計、開発、テストの各工程において地道な品質の作り込みが、結局は品質の高いプログラム、品質の高いシステムを作り上げることになります。
例えば、アプリケーションソフトウェアの品質向上のために、設計工程で取り組むべき事柄をみていくと、以下のようなことがいえます。
アプリケーション設計においてまずきっちり決めるべき点は、その全体構造です。30年前にG.J. Myersが提唱しているように、モジュール強度を高く（モジュール内の関連性を最大）、モジュール結合度を低く（モジュール間の関連性を最小）、機能に合致したシンプルなインターフェースとし、共通化を図って無駄に似たようなロジックをばら撒かないことが重要です。（オブジェクト指向言語では、モジュール強度を凝集度という）
モジュールの機能、データの意味を想起させ、管理しやすいネーミング基準の制定も重要な事項です。画面、インターフェース、データベース、ファイル、内部変数、いずれの場所にもデータ項目が存在しますが、同じ意味、同じドメインに属すデータは、このネーミング基準に基づいて名前をつけ、また基本属性を明確にして、モジュール間のインターフェースや、画面とモジュール、モジュールとデータソース間で食い違いのないよう整合性を取って設計を行う必要があります。
これら決めたことを徹底して遵守することで、初めて品質が作りこまれるといえます。遵守状況をチェックする組織的な取り組みも重要です。
これらの原則は、開発工程、テスト工程にも同じように存在します。たとえば、最近話題のTDD（Test-Driven Development）もその中で実施している内容は30年前から知られ、現場で実践されてきたものであり、このことからも品質はにわかに向上するものではなく、地道に築いていくことであると言えます。
（無論、ソフトウェア設計の上位工程としてあるシステム設計工程においても同様に品質を作り込むための基本が存在します）
メインフレーム時代は供給元がハードウェア・ＯＳ・ミドルウェアの組み合わせや整合性をきちんと取っていました。オーソドックスな組み合わせで、オーソドックスに利用していれば、システムの足回りはあまり気にせず、システム開発が出来ていました。
しかし、現在のオープン化の状況では、組み合わせ・選択の自由が増えた分、インフラの組み合わせパターンが大幅に増えました。それに伴い、組み合わせの検証は困難なものとなりました。バージョンの違いやパッチの適用など、組み合わせパターンを増やす細かな要素もあり、その組み合わせは爆発的に増えました。
そのため、初めて、もしくは使い慣れていないインフラの組み合わせパターンを利用する機会が増えました。それに伴い、当然リスクが以前に比べて増えました。また、組み合わせ上の問題が一旦生じると、インフラの組み合わせ要素が多いため、問題の切り分けや真因を探すことがより困難になりました。以上のようなことから、インフラの組み合わせ検証・保証は独特の難しさを抱えることになりました。
従来のITシステム開発は、手作業で行っていた業務をコンピュータ化、自動化することが中心でした。既に業務は存在しているため、ユーザが既存の業務規定書や現場の作業そのものから要求仕様書をまとめることは比較的容易でした。一方、近年では、技術革新やネットワークの普及に伴い従来は実現不可能であった優れたビジネスモデルや効率的な業務プロセスが、I
Tシステムの活用を前提に実現可能となってきています。
当然のことながらユーザもビジネス拡大、業務改革を推し進めるためのITシステムを必要としています。しかし、それは例えば「経営に役立つIT戦略」、「ITによる業務改革の実現」といった大きな要求(Wants)から始まるもので、要求仕様書として新業務機能や業務フローに結びつけるまでには依然大きなギャップが存在しています。現在あるいは近い将来のIT技術で何が実現可能となるかといった観点では、ある程度IT分野での専門性も必要とされ、ユーザが単独で要求仕様書を作成することは非常に困難な状況だと言えるでしょう。
したがって、従来のようなユーザ企業の業務部門と情報システム部門だけで、実業務を反映した形でシステムに対する要件をまとめるという進め方ではなく、システム開発の超上流段階からベンダと協業し、最新ＩＴ技術の動向や国内外の先進企業の成功事例等を研究しながら、未知・未経験の業務に対し、IT技術を効果的に活用し、業務要件、システム要件をまとめていく進め方が必要になってきます。
▼あいまいさがある段階の見積りをはっきりした段階で見積り直せるルールづくり
超上流や開発プロセスのどの段階での要求仕様かで、その固まり度合いや、見積り対象の深さなどに違いが出てきます。このような超上流や開発プロセスが明らかになると、要求仕様の固まり具合（時間軸、内容＝アウトプット、役割・責任など）と本文の図3.2に示すような見積りレベルとの因果関係などを発注側の経営者にも認識できるものと期待できます。すなわち、超上流での見積り内容は、仮試算、試算、概算レベルだとか、開発プロセスの設計に入って、確定の見積りとなる会話が、日常的に取り交わされることが期待できます。あいまいさがある段階での見積りが最後まで開発側（情報システム部門、ベンダ）の束縛になってプロジェクト成功の阻害要因になっている現状から、あいまいさがある段階の見積りを、はっきりした段階で見積り直せるルールづくりなどが産業界にとって新たなプロジェクト成功の鍵となるはずです。
投資判断を行う上でも、予算を確定させる上でも、なるべく早い段階で開発規模を予測し、ベンダとの間で確定させてしまいたいという思いは分かります。しかし、一般的には工程が上流であればあるほど各論の検討には至っておらず、予算として確定させるにはリスクが伴います（図１参照）。このリスクをベンダに抱えさせるという考え方もありますが、果たしてそれでよいのでしょうか？
リスク、すなわち不確定要素は金額に換算され、見積りを要求されるタイミングが早ければ早いほど、より多くの金額が上乗せされることになります。これはベンダに問題があるからではなく、ビジネス上当然の反応です。むしろ、十分な検討を行なわずに、精度の高い見積りや金額の早期確定を要求するユーザ側の姿勢に問題があると言えます。実際、開発するものが決まる前に、予算が決まっているプロジェクトは、失敗することが多いものです。根拠のない費用制約が無理な開発を招くからです。
これを解決する策として、図２にあるような見積りの多段階化があります。要件定義前での見積りは「これ位はかかりそう」という概算に止め、要件を出し切ったタイミング、即ち要件定義終了時点で確定見積りとするやり方です。しかし、これには「要件は時間の経過と共に変わるもの」とか「要件を詳細化しなければ見積り精度は上がらない」という認識が必要なため、単にルールとして定めるだけでなく、経営者も含め関係者にしっかりと理解してもらうよう、働きかけることが重要です。
別の策として、建築許可申請のように、システム開発の具体化の前に一定の事項が決まっていなければ、ある工程以降の作業を進めてはならない規制があってもよいかもしれません。しかし、現状では、一般的なルールを直ちに定義できるほどのコンセンサスはないでしょう。
本小冊子の表4.2、表4.3の成果物のうち、何がどこまで決まっていれば価格を固定した契約が締結できるのか、共通の理解を醸成して行く必要があります。当然ながら、価格を固定できる状況に至る前に作成した見積りは、見直さざるを得ません。見積りの前提条件が変化した場合は、再見積りするとともに計画を再精査しないと、開発プロジェクトが狙い通りのシステムを完成させる可能性が低下して行ってしまいます。
（図1 見積り時期とリスク）
（出典）小冊子「ITユーザとベンダのための定量的見積りの勧め」及び「ソフトウェア開発見積りガイドライン」
------------------------------------------------------------------------------
（図2 多段階契約と契約・再見積りのタイミング例）
（出典）小冊子「ITユーザとベンダのための定量的見積りの勧め」及び「ソフトウェア開発見積りガイドライン」
ここでいう要件定義終了のゴールとは、冊子(*1)５９ページの「（２）要件定義工程のゴール」にある通り、ユーザ企業が投資判断を行うのに耐えうる精度の予算を算定したもの、または、ベンダがその精度に対し責任を持って見積りを出すのに十分な要件を提示したものを言います。
(*1)「経営者が参画する要求品質の確保」~超上流から攻めるＩＴ化の勘どころ～
＜解説１＞
メインフレーム全盛期では特定のメインフレーマがバリューパートを担っていました。現在では必ずしも「古いつきあいの」ベンダがその役を任じることができるとは限りません。 経験ある人材は、業界内で相当流動化しています。そのため、コンピュータベンダに限らず、コンサルタント会社やベンチャー企業の中にも、当該業種での経験豊富なパートナが存在することがあります。 資本関係や過去の実績にとらわれず、広く提案をもとめる姿勢が必要です。
＜解説２＞
以下の活動を継続することにより、価値を創出するバリューパートナとしてのベンダを獲得する。
(1) いままでに付き合いのあるベンダに対して下記指標による格付けと定期的な見直しをおこない、ベンダデータベースを構築しておきます。
① 供給力 ・・・ 会社規模、情報部門の社員数、ＳＥ数、ＰＧ数など
② 技術力 ・・・ 対応可能業種、各種ＩＴ技術
③ 業務マナー
④ 単価 など
(2) ベンダ技術トップと積極的な交流を行い、ユーザ側要望を伝え理解を求めるとともに、ベンダサイドの情報収集にも努めます。
(3) 情報技術交流などを通し、新興ベンダの情報収集を行い、(1)のデータベースに反映します。
(4) 当該案件にふさわしいベンダを上記データベースから探し出します。
(5) 発注時には、必要な工数、工期、技術、要員数などを、できるだけ早い段階で意中のベンダ
に知らせて、無理のない要員調達を可能とします。
プロジェクトの状態を適切に管理できるような定量的な尺度（メトリクス）を定め、捉えにくいプロジェクトの状態を「見える」ようにすることが「プロジェクトの可視化」です。プロジェクトの可視化によってプロジェクトの状況に応じたタイムリーな判断を容易にし、プロジェクトの成功確率を向上させることが目的です。
可視化のための尺度は、１種類に限定されるものではなく、その目的によって定義や見せ方も違ってきます。例えば、プロジェクトの進捗を把握するという目的に合わせて、どんなデータをいつどのように収集し、加工して、提示するのかを定義することになります。
ここで重要なことは、情報を共有し、定量化し、モデル化し、指標化し、これらの情報から実行中のプロジェクトの実情を読み取ることです。
例えば、経営が経営だけの視点であれこれしろと言っても、現場は別のことをやりたい（やるべき）と考えていると、折り合いがつきません。強制的に進めれば、現場はやらされ感や不満が溜まるだけで、余りいいことはありません。よって、何のためにやるのか、どの範囲でやるのか、どれくらいコストを掛けていいのか、成否を何で評価するのかなどをきちんと議論・検討し、全てのステークホルダが納得した上で、一丸となってプロジェクトを進めて行ける状態にすること＝きちんとした合意形成が図られた状態になることで、それはシステム化の方向性およびシステム化計画工程の間に形成されなければなりません。
起こった障害の情報を蓄積し、それを分析し、予防などを行うことを障害管理といいます。
以下に障害管理の４つのアプローチを示します。
（１）障害対策手順の整備と対策体制の確立、訓練の実施
あらかじめ、発生が予想される障害発生パターンに応じて、その対策手順をまとめます。
システムの規模、重要度にもよりますが、対策手順はシンプルで、一定の経験を積めば誰でも実施できる程度のものにする必要があります。
また手順のみ整備しても、実際の場面では想定した形で事象が特定化できない、想定した順序では回復できないといったケースもあります。そこで実際の障害に極力近い形で実地に演習を実施し、システム更改時や、要員の引継ぎなどイベントに合わせ再度演習を行い、常に対策手順を最新の状態にしておく必要があります。
また、障害は夜間や早朝、休日など、人手が手薄な時間に発生することもあるため、組織的な対応体制を整備しておく必要があります。
（２）障害の監視
障害が発生した時、如何に速やかに検知するかが、まずは対策の第一歩です。システム的な仕掛けで、障害や性能ログの自動監視と、障害発生時に監視部署へアラームをあげるといったことは基本です。最近はエンドユーザの視点（ユーザを同じような操作を自動で行って障害状況を監視する）で障害を監視する仕掛けを組み込むことも可能です。しかし、ITシステムの仕掛けのみを過信してはいけません。必ず人間系でも障害を察知し、組織的に吸い上げる体制を作りあげることが重要です。
（３）障害内容の分析と対策
障害が連続的に起こる場合、それらには因果関係が潜んでいる可能性があります。過去に発生した障害は、必ずその発生状況をトレースし、根本原因を追求して抜本的な対策を実施しているのか、暫定的な対策なのかを明らかにし、記録に残しておくことが重要です。暫定的な対策で留まっている事項は、いつ抜本対策を行うのか、その実施状況も追跡します。
新たに障害が発生した時に、過去の対策方法が役立つことも多々あり、このように記録に残すことが、システムの信頼性を高めるひとつの武器でもあります。
（４）予防保守の実施
平常時から定期的にシステムを点検することが、障害の発生頻度を引き下げます。ハードウェアの点検や障害ログの解析は無論ですが、リソースの利用状況を監視することにより、将来のトラフィックの増大によるリソース不足の予測、あるいはメモリリークの検知などが可能となります。これらの情報を基に、リソースの増強、アプリケーションの見直し計画を立て、事前に障害を防ぐことが可能となります。
下図のグラフは、日本における7000人月規模の大規模プロジェクトの実績データの分析に基づいたものです。このプロジェクト自体は、予定どおりの品質／コスト／納期で完成したプロジェクトですが、そのコストの内容を調査・分析した結果、多くの欠陥除去コストが全体コストの内訳を占めていました。 （ちなみに、この例では、全体コストの半分を欠陥除去コストが占めています。）
（図 大規模開発における手戻りコストの概念図）
近年、プロジェクトの運用で注目されている、プロジェクトのマネジメント工数や、リスクへの対策（顕在化での対処と監視と予防の両面での対応）コストや、インフラ系（調達するハードウェアやミドルウェア・ソフトウェアの費用など）のコストや、テスト環境の構築費用などの他にも、セキュリティコスト、システムの移行コスト、新旧システムのインターフェイスの構築コストなど、さまざまなコスト要素があります。
（図 システム開発プロジェクトの構成要素）
（出典）「ソフトウェア開発見積りガイドブック」
ＤＲ／ＢＣは、それぞれDisaster Recovery／Business Continuity の略称です。
DR Disaster Recovery（デザスタリカバリ） は、災害対策のことです、災害などで不測の事態が起こった場合、ITシステムの回復、及び業務継続のための対応策です。
IT関連が中心であり、停電対策としてのUPS(無停電源装置)の設置や地震対策としてのデータセンタへの免震構造の導入など事前の予防策です。
BC Business Continuity は、ビジネス全般が対象で、災害の事前予防策に加え、リスク発生時の回復策を含んでいます。
災害や事故等の発生に伴って現在の場所において通常の事業活動が中断した場合に、別の場所で中核業務を持続させることです。
▼本CD-ROM内データ（文書・画像等）の著作権等の扱い
本CD-ROM内データ（文書・画像等）の著作権等の扱いは、本書
SEC BOOKS 経営者が参画する要求品質の確保
～超上流から攻めるIT化の勘どころ～第2版
独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター 編
2006年5月発行、株式会社オーム社刊
に準じます。
株式会社オーム社 東京都千代田区神田錦町3-1 電話03-3233-0641
http://www.ohsmha.co.jp/