参照アーキテクチャ調査報告（2005年度）itスキル標準®...

ＩＴスキル標準® プロフェッショナルコミュニティ®

ITアーキテクト委員会 2006年７月１日 Ver1.0

参照アーキテクチャ

調査報告

（２００５年度）

● 本報告書に記載されている「ＩＴスキル標準®」および「プロフェッショナルコミュニテ

ィ®」は、独立行政法人情報処理推進機構（ＩＰＡ）の登録商標です。また、社名およ

び製品名は、それぞれの会社の商標です。なお、本文中では「ＴＭ」、「®」は省略してい

ます。

● 本報告書に記載されているＷｅｂページに関する情報（ＵＲＬ等）については、予告な

く変更、追加、削除（閉鎖）等される場合があります。あらかじめご了承願います。

i

はじめに

独立行政法人情報処理推進機構（IPA）の IT スキル標準センターでは、プロフェッショナルによる情報

交換や議論の場を通して後進人材の育成に貢献するための「プロフェッショナルコミュニティ」を創設し、

2003年 11 月より「IT アーキテクト委員会」が活動を開始した。本報告は IT アーキテクト委員会の 2005 年

度活動によるもので、参照アーキテクチャ・ワーキンググループにより作成された。

本報告書は、既に情報サービス産業に従事していられる方の中で、これから IT アーキテクトを目指そうと

されている方、およびこれに関連する方に対して下記の情報を提供するものである。

■ エンタープライズ・アーキテクチャ

・内部統制のための参照アーキテクチャ

■ ソリューション・アーキテクチャ

・ＩＴアーキテクチャ策定ガイドライン

・ＩＴアーキテクチャの評価技法

・ＩＴアーキテクチャに関連する注目すべき技術

■ 標準化動向

エンタープライズレベルのアーキテクチャに関するテーマとしては、昨今話題になっているＳＯＸ法を含

め企業における内部統制とＩＴアーキテクチャの関係（ＩＴ統制）を取り上げた。また内部統制のためのフレ

ームワークとしてＣＯＳＯ、ＣＯＢＩＴ、経済産業省システム管理基準、ＩＴＩＬについて概要を説明してい

る。

ソリューションレベルのアーキテクチャに関するテーマとしては３点を取り上げている。

一点目は、ＩＴアーキテクチャをどのように設計したらよいのかについて日本におけるベストプラクティ

スと現在ホットなアプローチ方法、パターンについて紹介している。ベストプラクティスとしては経済産業省

が公開しているＥＡ（エンタープライズアーキテクチャ）におけるモデリング言語、アーキテクチャの策定方

法とＩＴアーキテクトのためのｅラーニング教材の中でＩＴアーキテクチャ策定の部分を抜粋として記載して

いる。ｅラーニング教材について興味のある方はＩＰＡのＩＴアーキテクト委員会事務局へ問い合わせをして

いただきたい。話題となっているＩＴアーキテクチャ策定のアプローチ方法としてはＡＢＤ（Architecture-

Based Development）、ソフトウェアプロダクトライン、ＩＢＭ社およびマイクロソフト社の方法論およびア

ーキテクチャ構築に役立つパターン例について紹介している。

二点目は、設計されたアーキテクチャに対する評価技法としてカーネギーメロン大学が中心となって提唱

しているものを紹介している。ＡＴＡＭ（Architecture Tradeoff Analysis Method）はシステムに要求されて

いる品質目標をアーキテクチャがどのように達成しているかを評価するもので、他方ＣＢＡＭ（Cost Benefit

Analysis Method）はＡＴＡＭのアウトプットからＲＯＩを算出し経済的にアーキテクチャを評価するもので

注目に値する。

三点目は、ＩＴアーキテクチャに影響を与える注目すべき技術として、ビジネスグリッドと大規模Ｗｅｂ

サイト構築のためのノウハウを紹介している。大規模Ｗｅｂサイト構築のノウハウは、ＩＢＭ社がレッドブッ

クとしてＷｅｂ上に公開しているものを概要としてまとめたものでワークロード分析、拡張性設計、パフォー

ii

マンス設計、可用性の確保といったトピックスについて網羅的かつ具体的に述べられている。残念ながら時間

の関係でＳＬＡの保証については触れることが出来なかったが今後チャンスを見て補足していきたいと考えて

いる。

ＩＴ技術に関する標準化がどのようになっているかを知ることはＩＴアーキテクチャを設計していく上で

インターオペラビリティ、ＩＴ資産の再利用といった観点から重要である。この第一歩として今年度はＩＴ技

術の標準化動向をどのように分類整理していけばよいか検討し分類体系としてまとめた。今後それぞれのカテ

ゴリに属するＩＴ技術の標準化動向について調査していきたい。

昨年度とは異なり今年度はいくつかの領域にまたがった内容となった。用語等については特に統一するこ

とはしておらず原典を優先している。それぞれの報告書を読む際には留意していただきたい。

ワーキンググループ活動に参加したメンバーは次の通り。

調査・収集作業担当メンバー（五十音順、○はリーダ）

• 小池和雄日本電気株式会社

• 長坂実株式会社ＣＳＫシステムズ

• 野村一行マイクロソフト株式会社

• 村上和正 ○ 株式会社システムイン

• 湯浦克彦株式会社日立製作所

なお、IT アーキテクト委員会の 2006 年度以降の活動により、本書は、必要に応じて随時改版していく予

定である。

2006年 7月

iii

CONTENTS

Ⅰ エンタープライズアーキテクチャ Ⅰ‐ⅰ 内部統制のための参照アーキテクチャ（湯浦）

Ⅱ ソリューションアーキテクチャ Ⅱ‐ⅰ ＩＴアーキテクチャ策定ガイドライン１経済産業省版（村上）

２ｅラーニング版（CSK、NEC、富士通３社合同版（３社版））（村上）

３ＩＴアーキテクチャ構築技法（野村）

Ⅱ‐ⅱ ＩＴアーキテクチャの評価技法１ＩＴアーキテクチャ評価技法ＡＴＡＭ、ＣＢＡＭ（長坂）

Ⅱ‐ⅲ ＩＴアーキテクチャに関連する注目すべき技術１大規模Ｗｅｂサイトの構築ノウハウ（小池）

２ビジネスグリッド（小池）

Ⅲ 標準化動向 Ⅲ‐ⅰ ＩＴ技術分類体系（村上）

ＩＴスキル標準プロフェッショナルコミュニティＩＴアーキテクト委員会

参照アーキテクチャ調査報告（２００５年度）









Ⅰ-ⅰ 内部統制のための参照アーキテクチャ

Ⅰ-ⅰ 内部統制のための参照アーキテクチャ 1

Ⅰｰⅰ 内部統制のための参照アーキテクチャ

// CONTENTS //

１．技術の名前 ................................................................................................................................................ 2

２．コンテキスト............................................................................................................................................. 2

２-１．米国企業改革法（SOX 法） ................................................................................................................... 2 ２-２．新会社法と金融商品取引法（JSOX 法）.............................................................................................. 3 ２-３．COSO フレームワーク........................................................................................................................... 3 ２-４．内部統制と IT 統制................................................................................................................................... 4

３．構成と内容 ................................................................................................................................................ 6

３-１．COBIT...................................................................................................................................................... 6 ３-２．経済産業省システム管理基準.................................................................................................................. 8 ３-３．情報セキュリティ管理基準と ISMS 認定基準....................................................................................... 9 ３-４．ITIL.......................................................................................................................................................... 11

４．標準化と適用の動向................................................................................................................................ 14

４-１．一般的な動向.......................................................................................................................................... 14 ４-２．実例に基づく適用法の解説 ................................................................................................................... 15

５．参考文献 .................................................................................................................................................. 18



１．技術の名前

COBIT、経済産業省システム管理基準、情報セキュリティ管理基準、ISMS 管理基準、ITIL

２．コンテキスト

２-１．米国企業改革法（SOX 法）

2000 年から翌年に発覚したエンロン社およびワールドコム社の粉飾決算とそれに引き続く倒産は、米国の投

資市場に衝撃を与えた。そこで、粉飾決算を防止するために、2002 年 7 月に SOX 法（企業改革法、サーベンス・

オックスリー法）が制定された。SOX 法の名前は、議会への提案者である、ポール・サーベンス上院議員およびマ

イケル・オックスリー下院議員の両者の名前に由来する。

改ざん、公務執行妨害などに対する刑事罰の強化企業不正行為責任１１

経営者が財務報告の証明を行わない場合の刑罰ホワイトカラー犯罪の刑罰９

政府調査を妨害する隠匿などに対する刑事罰強化可罰的違法行為責任８

経営者における財務報告に関する内部統制を確立し、維持する責任。

監査委員会の設立と役割

企業の責任３

経営者における内部統制の有効性の検証と、評価が真正であることの報告の責任。

経営者への個人ローンの禁止

財務ディスクロージャの強化

４

投資活動関係者との事前情報交換の禁止アナリストの利益相反５

会計監査の監視、不正防止のためのスタッフ追加SECの補強６

SECにおける違反者の調査報告義務調査および報告７

還付はCEOによって署名すること法人税の還付１０

監査と同時に監査以外の業務にあたることの禁止。

監査パートナーの5年での交代

会計監査人の独立２

公開企業の会計監査を監視する委員会の設立公開企業会計監視委員会１

おもな内容タイトル章

図 4.1 ＳＯＸ法の概要

企業改革法は、全部で 11 の章と 66 の条からなるが、中心となるのは、第 3 章「企業の責任」の 302 条「財

務報告に関する企業の責任」と第 4 章「財務ディスクロージャの強化」の 404 条「経営者による内部統制の評価」

である。302 条においては、経営者は財務報告に関する内部統制を確立し、維持する責任があることが明記されて

いる。不備や不正があればそれを開示することや、内部統制の内容を変更した場合には変更点を開示することなどが

定められている。40４条においては、さらに進んで、経営者は内部統制の確立、維持に関する責任を表明する必要

があることが示されている。責任の表明には、採用した内部統制のフレームワークや内部統制の有効性に関する評価

を述べ、さらに会計監査事務所に検証を受けたことを報告する必要がある。

企業改革法は、404 条を含めて 2004 年 11 月より施行されており、米国の取引所に上場している日本の

企業においても2005 年７月から適用となっている。



２-２．新会社法と金融商品取引法（JSOX 法）

日本においても、大手鉄道会社や大手繊維会社における虚偽記載が大きな問題となり、内部統制の必要性が叫ばれ

た。すでに、2006 年 6 月より施行となった新会社法において内部統制の導入が規定されている。また、2006 年

6 月には金融商品取引法が成立した。金融商品取引法では、上場企業に対してインサイダー取引に関する罰則などを

規定するとともに、２００８年より内部統制の実施を義務付けている。そこで、別名日本版 SOX 法(JSOX 法)とも

呼ばれており、引き続き、その実施基準が金融庁において審議されている。

こうした内部統制を強化する動向は、2006 年に新興金融業者による株式の偽計取引やインサイダー取引が摘発

されたことにより、いっそう拍車がかけられている。折からインターネットによる株式取引が盛んになっているが、

一般投資家による直接投資をより本格化し経済を活性化させるためには、投資市場への信頼性を維持することが必須

である。そこで、規則と罰則の明確化、証券取引等監視委員会の機能強化などが緊急の政策課題となっている。

２-３．COSO フレームワーク

内部統制のフレームワークとして、米国では COSO フレームワークが提案されている。米国公認会計士協会ほか

４つの協会が共同して設立したトレッドウェイ委員会により、1992 年に発表され、米国および日本の監査基準に

影響を与えたほか、金融機関の内部管理フレームワークや後述する COBIT などシステム監査のフレームワークに影

響を与えていった。

統制環境

リスク評価

統制活動

情報と伝達

モニタリング

業務の有効性と効率性

財務報告の信頼性

関連法規制への準拠

事業部門群

活動プロセス群

統制目的

統制要素

統制対象

図 4.2 COSO フレームワークの概要

COSO フレームワークでは、内部統制の目的を、①業務運用の有効性と効率性、②財務報告の信頼性、③関連

法規の遵守としている。



COSO フレームワークは、統制環境、リスクの評価、統制活動、情報と伝達、監視活動という五つの構成要素

を有している。統制環境には、誠実性や倫理観、経営理念、権限や責任の委譲、従業員の能力開発、取締役会による

監督などを含んでいる。リスク評価とは、不正や誤りを犯すリスクの識別、分析と対応策の管理である。統制活動と

は、リスク対応策を適切に実行して、適正な業務遂行を担保するための方針や手続である。情報と伝達は、従業員が

内部統制システムにおける自分の役割や他の業務との関連を理解し、また重要な情報を上層に伝えるための情報の体

系と伝達手段である。監視活動（モニタリング）とは、内部統制が有効に機能していることを継続的に監視する方針

や手段である。

２-４．内部統制と IT 統制

財務諸表の科目の値は会計に関係する IT システムのデータから集計される。そこで、財務報告の信頼性を確保

するには、IT システムのデータの信頼性を保証しなければならない。データの信頼性を維持するには、システム自

身の技術的信頼性が求められることは勿論であるが、それとともに IT システムが企業活動に有効に機能し、経営資

源の状態が適切にデータに反映されることが必要である。

アプリケーション

アプリケーションＡアプリケーションＢ

ITマネジメント・開発運用手順

ＩＴサービス・基盤ソフトウェア・ハードウェア

ＩＴインフラストラクチャ

業務プロセスＡ業務プロセスＢ

業務プロセス

全般統制

業務処理統制

IT開発への取り組み方・利用の推進などその他のＩＴ統制

ITと経営・業務プロセスの構造 IT統制内部統制

経営方針・職務分担・職場環境など

おもに統制活動

統制環境リスク評価情報・伝達監視活動

全社レベル統制

業務レベル統制

図 4.3 ＩＴ統制の構造（文献１による）

以上の事柄を体系的に検証していくには、IT システムに対しても内部統制と同様の枠組みが必要と考えられる。

内部統制の特に統制活動について IT システムに関わる部分を IT 統制と呼んでいる。あるいは、第 6 の要素として独

立して扱う場合もある。統制活動における IT 統制には２つの要素がある。一つは業務処理統制と呼び、個々のビジ

ネス操作とそれを実現している IT システムの業務機能（アプリケーション）を対象とする。もう一つは全般統制と

呼び、企業全体にわたる統制の問題とそれに関わる共通 IT 基盤（インフラストラクチャ）を対象とする。さらに、

統制活動以外の要素において、企業としてのＩＴへの取り組み方やＩＴの活用法などＩＴに関わる部分を、ＩＴ統制



の第 3 の要素とする。

IT 統制に関しては、日本公認会計士協会(JICPA)から実務上の指針が公表されている。この報告によれば、

COSO の目標である、業務の有効性、財務報告の信頼性および法令の遵守を、業務処理統制による網羅性、正確性、

正当性、維持継続性の検証と、全般統制による準拠性、可用性、機密性の検証によって確保する。

網羅性情報が漏れなくかつ重複なくデータとして記録されていること

（たとえば、製品の売り上げを漏れなく記録していること）

正確性情報が正確にデータとして記録されていること

（たとえば、売り上げの金額、日付を正確に記録していること）

正当性情報が正規の承認手続きを経たものであること

（たとえば、必要な上長承認を経て資材の購入していること）

維持継続性情報を継続的に使用することが可能であること

（たとえば、昨年の売り上げ情報を参照できること）

準拠性会計基準、関連法規および社内規則等に合致していること

（たとえば、社内で統一した会計科目を用いること）

可用性情報が壊れにくく、障害があっても復旧が容易であること

（たとえば、定期的にバックアップしていること）

機密性正当な権限者以外に利用されないように保護されていること

（たとえば、パスワードが設定されていること）

このほか、全般統制では、このほか IT システムの開発運用過程を検証する。特に上流における IT 投資計画と技

術方針の決定状況、外部委託先の選択方針、IT に関わる職務分担、IT 要員管理状況などに注意する。IT システムの

信頼性は、開発初期の方針や取り組み体制によって左右される部分が多い。また、運用時におけるシステム運用手順

やエラーが発生した場合の対応手順は、業務活動の品質に直結するので注意深く確認すべきである。セキュリティ確

保のための施策、IT 業務委託先におけるサービルレベル維持のための施策に関しては、開発運用過程を横断して確

認する必要がある。



３．構成と内容

内部統制に関連するフレームワークとして、以下のようなシステム監査、セキュリティ監査およびＩＴサービス

管理の方法論が、しばしば参照されている。

COBIT

経済産業省システム管理基準

経済産業省情報セキュリティ管理基準と ISMS 認定基準

ITIL

３-１．COBIT

COBIT は情報システムコントロール協会（ＩＳＡＣＡ）が提唱するシステム監査の基準であり、同時に内部統制

の成熟度を評価するフレームワークとして利用される。2000 年に発表された COBIT3（Governance, Control

and Audit for Information and Related Technology）が、現在内部統制実現に関する事実上の標準となってい

る。２００５年１１月には、SOX 法対応を強化した COBIT４が発表されている。本報告では、以下 COBIT３を中

心に、COBIT４での改訂を含めて、COBIT と総称して解説する。

計画と組織

ITプロセス

デリバリーとサポート

調達と実装モニタリング

と評価

データ


人

インフラストラクチャ

ITリソース

ビジネス要件

有効性

効率性

信頼性

機密性

完全性

可用性

準拠性

図 4.4 ＣＯＢＩＴフレームワークの構造（文献５の内容に基づく）

COBIT フレームワークは、ビジネス要件、IT プロセスおよび IT 資源の３つの視点を有している。

ビジネス要件は、一般投資家からの受託要件およびセキュリティ要件に分かれる。一般投資家からの受託要件には

COSO の目的である、業務の有効性と効率性、情報の信頼性、および法律や規則への準拠があげられている。セキ

ュリティ要件には、機密性、完全性、可用性があげられており、通常言われるセキュリティよりも広い意味での安全

性を求めている。なお、完全性(integrity)とは、情報の網羅性、正確性および正当性を備えることをいう。



IT リソースには、データ、アプリケーション、インフラストラクチャおよび人を取り上げている。インフラスト

ラクチャには、基本ソフトウェア、ハードウェア、ネットワークなどのほか、従来したリソースとして分類されてい

たサーバ室、入退室管理機器、空調機器などの設備を含む。

IT プロセスは、COBIT における統制の基本とする視点である。プロセスとは、手順によらない職務の区分である。

IT プロセスは 34 種を数え、計画と組織、調達と導入、サービス提供とサポート、およびモニタリングと評価の４

つの領域に分かれる。

IT プロセス群のうち、計画と組織の領域には、IT に関する戦略、指針、コンプライアンス、アーキテクチャのほ

か、IT に関わる組織と人材（ヒト）、IT 投資（カネ）の計画に関するプロセスを網羅的に含んでいる。また、計画遂

行のためのリスク評価、プロジェクト管理および品質管理の統制を含んでいる。調達と実装の領域では、システムの

業務処理部分（アプリケーション）から基盤部分までの広範囲にわたるアーキテクチャを構築し、インストール、移

行、運用、変更、改善と続くシステムのライフサイクルの最適化を計画する。デリバリとサポートの領域においては、

ＩＴの運用に必要となる支援活動のプロセスが網羅的に示されている。大別すると、はじめの５つは品質を維持する

ためのプロセス群、次に費用に関するプロセスが一つ、次に利用者に関するプロセス群が２つ、最後の５つはＩＴ自

身の管理に関するプロセス群である。モニタリングと評価の領域には、IT プロセスの監視（モニタリング）のほか、

IT 統制の有効性評価や保証のプロセスを含んでいる。

計画と組織領域

IT戦略計画の策定

情報アーキテクチャの定義技術方針の決定IT組織の関係の定義IT投資の管理

マネジメント目標と方針の伝達人的資源の管理

品質管理リスクの評価プロジェクト管理

調達と実装領域

自動化ソリューションの識別アプリケーションソフトウェアの

調達と保守技術基盤の調達と保守手続きの開発と保守ITリソースの調達

変更管理設置、受入認証とその変更

デリバリとサポート領域

サービスレベルの定義と管理サードパーティのサービス管理品質と能力の管理継続サービスの保証システムセキュリティの保証コストの識別と配分利用者の教育と訓練顧客の支援と助言構成管理問題と障害の管理データ管理設備管理

モニタリングと評価領域

プロセスのモニタリング内部統制の妥当性評価規則の遵守ITガバナンスの規定

図 4.5 ＣＯＢＩＴのＩＴプロセス体系（文献５の内容に基づく）

IT プロセスには、それぞれ、目標とするビジネス要件、関連する IT リソースを含めて統制目標が示される。IT プ

ロセスの下位構造として複数の活動（アクティビティ）が示され、COBIT４では IT プロセスへの入力、他のプロセ

スへの出力、プロセスの関係者の役割と責任に関しても言及されている。

目標の遂行に向けては、取り組みの要点を主要成功要因(CSF)として示している。また、目標の達成を評価する指

標である重要目標指標(KGI)および KGI 達成にいたる中間的な成果を測定方法とともに示した重要成果指標(KPI)が

合わせて定義される。このほか、内部統制に関する成熟度基準や監査手続きのガイドラインが示されている。



ITプロセス

ITリソースとの関係

IT目標との関係

機密

補助

完全

補助主要主要

可用準拠信頼効率有効

○

人

○○

インフラ

ストラクチャ


データ

プロセスの統制目標主要成功要因（CSF）

重要目標達成指標（KGI）

重要成果達成指標（KPI）

ITガバナンス

成熟度モデル

0 統制不在1 初期/その場対応………

監査手続きのガイドライン

面接対象者収集すべき証拠資料評価視点、評価方法報告など

プロセス定義管理指標取り組みへの指針

プロセスの入出力、役割と責任

図 4.6 ＣＯＢＩＴプロセス定義のイメージ（文献１による）

３-２．経済産業省システム管理基準

システム管理基準は、COBIT と同様に、IT 全般に対する統制のフレームワークであり、日本におけるシステム監

査の基準としてもっとも参照されているものである。1985 年１月に当時の通産産業省から発表されたシステム監

査基準を初版として、2004 年 10 月に大きく改訂されている。現在は、システム監査の行為規範を述べたシステ

ム監査基準と、システム監査における注目点を述べたシステム管理基準に分けて公表されている。



コンプライアンス

事業継続計画

情報資産管理の方針

情報化投資

組織体制

共通業務

保守業務

運用業務

開発業務

企画業務

情報戦略

分類

開発手順、システム設計、プログラム設計、プログラミング、テスト、移行

開発時のリスク評価。モニタリング機能を考慮した設計

ドキュメント管理、進捗管理、品質管理、人的資源管理、委託・受託、

変更管理、災害対策

保守の計画、実施、確認。システムの移行、廃棄

運用管理、事故・障害管理、データ管理、出力管理、ソフトウェア管理、ハードウェア管理、ネットワーク管理、構成管理、設備管理

組織的体制での事業継続計画の立案と周知徹底

情報資産管理の方針、体制の明確化

経営戦略との整合性、投資効果を考慮した情報化投資計画

情報システム化委員会の設置。人材育成方針の明確化

全体最適化計画と整合した開発計画策定、ルールに従った調達

法令、規範への管理体制、管理責任者、倫理規定等の設定

ITガバナンス、情報化投資の方針、コンプライアンス、リスク算

定、システム構築・運用の標準化を含めた全体最適化計画全体最適化

おもな内容

図 4.7 経済産業省システム管理基準の概要（文献１による）

システム管理基準では、システム構築と利用における企画、開発、運用、保守という業務のフェーズに沿って手順

が示されている。これに共通業務の分類を加えて、手順と分類ごとに基準となる項目を設定している。COBIT がプ

ロセスに着目して IT 関連業務を分類しているのに対し、手順を重視して作業を分類し、統制上の注意点を述べてい

るのが特徴である。

２００４年の改訂では、特に企画業務の上流に情報戦略のフェーズを独立して設け、全体最適化、組織体制、事業

継続計画およびコンプライアンスに関する基準を追加している。情報戦略のフェーズの項目の多くは、COBIT にお

ける計画と組織に関するプロセス群と対応付けることができる。また開発業務のなかにモニタリングに関する基準を

追加している。これらの追加は、内部統制の実施に対応するとともに、企業全体の経営最適化に資する IT 投資を目

指すエンタープライズ・アーキテクチャの考え方や、情報システムに関するリスクマネジメントの考え方に対応する

内容となっている。全体で 287 の基準項目があげられており、各項目はすべて単文で簡潔に述べられている。

３-３．情報セキュリティ管理基準と ISMS 認定基準

情報セキュリティ管理基準および ISMS(Information Security Management System)認定基準は、セキュリ

ティに焦点を当てた IT 統制のフレームワークである。この二つは、いずれも英国のセキュリティ規格である

BS7799 を発端としており、BS7799 第一部の情報セキュリティ基準が ISO/IEC17799 と発展した成果を受け

て、経済産業省において制定されたものが情報セキュリティ基準であり、一方、ISMS 認定基準は、BS7799 第二

部の情報セキュリティマネジメントシステムを中心に第一部の内容も含めて制定されている。

情報セキュリティ管理基準は、2003 年 3 月に経済産業省から発表されており、これと合わせて情報セキュリ

ティ監査制度を運用している。情報セキュリティ基準は、9 つの管理分野を持ち、その下に 132 の統制目標と 932

のサブ統制目標を持つ。それぞれのサブ統制目標は、情報システム管理基準と同様に簡潔に単文で記されている。管

理分野の中では、「セキュリティ基本方針」および「組織のセキュリティ」が、情報システム管理基準における情報



戦略の章に対応する、全体への方針と組織化を述べている。

事故、災害からの復旧・予防管理事業継続管理

情報システムの運用管理における完全性・可用性の確保。悪意のあるソフトウェアからの防御、ネットワーク保護。

通信および運用管理

入退室管理、施設や装置取り付けなど物理的および環境的セキュリティ

人の誤りや不正行為への対策。利用者訓練、誤動作報告など。人的セキュリティ

情報資産項目の作成と情報資産分類資産の分類および管理

情報セキュリティに責任を持つ委員会の設置と外部委託組織のセキュリティ

経営陣の責任による基本方針の策定および支持セキュリティ基本方針

知的財産など法的措置への準拠、監査活動の保護適合性

セキュリティ要件定義、開発時のセキュリティ確保、情報の改ざん防止、暗号鍵の管理など

システムの開発および保守

利用者のアクセス管理、ソフトウェアのアクセス制御と監視。モバイル作業、遠隔作業への規程。

アクセス制御

おもな内容管理分野

図 4.8 経済産業省情報セキュリティ管理基準の概要（文献１による）

情報セキュリティ管理基準および情報セキュリティ監査基準は、前の項で述べたシステム管理基準とシステム監

査基準と組み合わせて利用することを推奨している。情報セキュリティ管理基準では、セキュリティ以外の統制には

触れていないが、情報資産の体系に基づく安全確保に関して、IT 以外の人的要素にも深く踏み込んで述べている。

これに対し、情報システム管理基準は IT のライフサイクルの手順に基づいて、安全性のほか、有効性や信頼性を含

めて検証する。情報システムと情報資産は不可分であるので、この２つの管理基準は排他的ではないが、体系が異な

り、一部異なる領域を持っている。

ISMS 認定基準は、セキュリティ基準に沿って作成された情報システムの認定基準であり、日本情報処理開発協

会(JIPDEC)が認定審査機関となっている。2002 年 4 月に第一版が公表されている。ISMS 認定基準においては、

PDCA による継続的なセキュリティ向上の手順を述べており、特に計画(Plan)のフェーズについては９つのステッ

プを詳細に述べている。



適用範囲の設定

基本方針策定

リスク評価の取り組み法策定

リスクの識別

リスクの評価

リスクの対応

管理目的と管理策の選択

適用宣誓書の作成

残留リスクの承認

リククマネジメント実施基準

資産目録リスク一覧

リスク評価結果

リスク対応結果

対策基準

適用宣誓書

管理目的と管理策の候補

図 4.9 ISMS 認定基準におけるセキュリティ・リスクマネジメント計画の概要（文献１による）

「適用範囲の決定」ステップでは、事業、組織、所在地、資産、技術などを選定し、「基本方針の策定」ステッ

プでは、事業上の要求事項、法的要求事項、契約上の義務などを確認する。これに従って、「リスク評価の体系的取

り組み方法の策定」ステップでは、分析アプローチ、リスク評価手順、リスク保証のレベルなどの設定を行う。「リ

スクの識別」ステップでは、保有する情報資産を洗い出し、それらに含む脅威と脆弱性を明確化する。「リスクの評

価」ステップでは、機密性や影響度の観点からリスクの持つ事業上の損害の大きさを評価し、これに脅威の大きさと

脆弱性の大きさを掛け合わせてリスク値を算出する。そして、企業としてリスクを受容できる基準と照合して、対策

するか受容するかを判断する。「リスクの対応」ステップでは、適切な管理策を選択して、発生可能性の低減もしく

は影響度の低減を図る。

３-４．ITIL

ITIL(IT Infrastructure Library)は、システム運用フェーズに焦点を当てた IT サービスマネジメントのフレームワ

ークである。英国を発祥の地として、1991 年に ITIL の普及団体である itSMF (IT Service Management Forum)

が設立され、現在は世界的に普及している。

IT サービスとは、IT を用いて利用者の事業を支援する活動全般を指す。IT サービスの品質を維持するために必要

な IT 部門の業務プロセスや作業基準を規定し、管理・改善する活動を IT サービスマネジメントと呼ぶ。ITIL では、

IT サービスを管理の単位とし、IT サービスの品質である「サービスレベル」を重要な管理属性とする。

ITIL のプロセス群は、サービスサポート領域とサービスデリバリ領域に分かれる。この２つの用語は、COBIT に

おける「デリバリとサポート」領域を連想されるが、内容的にも対応するものが多い。



顧客

サービスレベル管理

IT財務

管理能力管理

可用性管理

ITサービス

継続性管理

要件・目標・実績サービスサポート領域のプロセス群へ適用（日常の運用業務）

サービスデリバリ領域（ITサービスの

設定と継続的改善）

図 4.10 ITIL におけるサービスデリバリの概要（文献１による）

サービスデリバリ領域は、サービスレベル管理、ＩＴサービス財務管理、能力（キャパシティ）管理、可用性管理、

およびＩＴサービス継続性管理の各プロセスからなる。ＩＴサービスの投資対効果を上げるための長期的な改善に焦

点を当てている。

サービスレベル管理プロセスでは、ＩＴサービスの品質を利用者の事業と整合性のとれたレベルに維持する。そ

のための目標設定、顧客との合意（SLA、サービスレベル・アグリーメント）、監視、報告、レビューなどを行う。

SLA は、個々の IT サービスの品質特性毎に設定される。SLA の項目や水準は業務要件に依存するが、企業全体に

わたり一貫性を持って設定することが重要である。そこで、しばしば SLA 体系に関して提案されたガイドラインが

参照される。日本においては、経済産業省による政府調達への SLA ガイドライン、総務省による公共 IT の SLA ガ

イドライン、電子情報技術産業協会による民間向け IT システムの SLA ガイドラインなどがある。

利用者

サービスデスク

障害管理

問題管理

変更管理

リリース管理

構成管理

構成管理データベース

迅速対応問題を

究明した変更反映

サービスデリバリ領域

（サービス設定と継続的改善）

サービスサポート領域（日常の運用業務）

図 4.11 ITIL におけるサービスサポートの概要（文献１による）



サービスサポート領域は、障害(incident)管理、問題管理、変更管理、リリース管理、構成管理、およびサービ

スデスクの各プロセスからなる。利用者が日々ＩＴサービスを円滑に利用するための運用とサポートに焦点を当てて

いる。ハードウェアの故障、ウィルスの検出など IT 自身が引き起こす異常のほか、利用者のパスワード忘れなど人

為的なトラブルも含めて障害が発生すると、即座に対応可能なものと対策を検討すべきもの（問題）とに分けて対策

される。問題に対するシステムの変更はリリースという単位で、稼動システムへ反映される。

構成管理プロセスでは、ＩＴインフラストラクチャに存在する全ての構成要素を識別し、特徴、関係、状況など

を記録管理する。構成情報は最新リリースを反映し、他のプロセスからも共通にアクセスして利用する。以上のサー

ビスサポート領域のプロセス群では、それぞれ処理した情報を構成情報に関連付け、構成管理データベース(CMDB,

Configuration Management Data Base)に一括して保存する。CMDB に格納された履歴や過去事例をもとに、

各プロセスの作業を効率化し、作業の品質を向上させる。



４．標準化と適用の動向

４-１．一般的な動向

米国企業改革法は、404 条を含めて2004 年11 月より施行されており、米国の取引所に上場している日本

の企業においても2005 年７月から適用となっている。日本の新会社法は 2006 年６月より施行される。JSOX

法)は 2008 年の施行が予定されている。このような状況のなかで、各社 IT 統制の方法および体制の準備に取り組

んでいる。

システム監査および情報セキュリティ監査に関しては、内部統制に係らず従来から実施されていたが、いずれも普

及途上にある状態である。日本情報処理開発協会(JIPDEC)が 2004 年から 2005 年にかけて全国の企業約 400

社（平均従業員数 2751 名）行ったアンケートによれば、システム監査を実施したことがある企業は 46.3％であ

る。監査の主体（複数回答）については、監査部、検査部など内部監査部門が約 60%を占め、監査法人やコンサル

タント会社への委託(約 40%)を上回っている。総務省による 2004 年度のアンケート調査によれば、情報セキュリ

ティ監査を実施している組織は、大企業で 24.2%、地方公共団体で 9.4%である。ISMS 認定基準に関しては、認

定取得している企業が 9.3%、取得していないが制度を知っている企業が 53.2％となっている。

米国 IT ガバナンス協会(ITGI, IT Governance Institute)では、2004 年 4 月に「SOX 法のためのＩＴコント

ロール目標」という報告書を発表しており、そのなかで IT 統制の責任分野や取り組みの上での注意を述べている。

この報告では、ＩＴ統制の手順についても言及しており、現在日米の企業における事実上の標準となっている。ＩＴ

統制、特に業務処理統制は作業量が膨大となる恐れがあるので、重要な会計科目、重要な業務プロセス、重要な業務

拠点などの観点から統制対象を絞り込む必要がある。また、統制の結果は文書として記述し、第三者の検証を受ける

必要があるので、文書の体系や形式の設定が重要な事項となる。

計画と範囲の設定

リスク評価の実施

重要な会計科目と統制の特定

文書統制の設計

統制設計の評価

企業活動～統制監視の実施

有効性の評価

文書処理と結果

持続可能性の構築

欠陥の特定と是正

図4.12 ITGI 報告における内部統制の手順の提案の概要（文献４の内容に基づく）



４-２．実例に基づく適用法の解説

上記のような一般的な手順の提案に対して、すでに日本においても実際的な作業方法が文献で紹介されている（文

献２）。内部統制においては、まず、ＩＴ全般統制を含めて全社レベル統制の計画と文書化が推進される。業務プロ

セスレベル統制は、全社レベル統制での確認点を踏まえて、統制の計画作業および統制の文書化設計作業に分けて準

備作業が実施される。

１．全社的な内部統制の計画と文書化設計

① 企業レベル統制の計画と文書化

② ＩＴに関する全社的な統制の計画と文書化

２．業務プロセスに係る内部統制の計画作業

① 文書化範囲に関するスコーピング（絞込み）

② 担当者の割り当てとスケジューリング

３．業務プロセスに係る内部統制の文書化設計

① ビジネスプロセスの文書化（可視化）

② リスクの把握とコントロールの設計

４．内部統制のテスト・評価・改善

① 内部統制テストの実施

② 内部統制の評価・改善・報告（意見表明を含む）

図４．１３内部統制整備の全体像（文献２による）

統制の計画では、文書化の負荷を軽減するために、統制の目的や企業の状況に合わせて実際に文書化を実施する範

囲を順次絞りこんでいく。特に重要な勘定科目に対して関連の深い「重要な業務プロセス」を選択することで、文書

化の対象業務を特定化することができる。

重要な業務プロセスの選択においては、もとより業務プロセスに対する全社的な合意が必要である。たとえば、営

業プロセスとそのサブプロセスとしての売上プロセスを定義して、その企業で扱うすべての製品の営業あるいは売上

の作業を共通的に捉えることができれば、統制の文書化も一つに集約して実施することができる。しかし、営業ある

いは売上の示す作業の範囲や作業分担法が製品や拠点毎に異なるならば、文書化の共通化は不可能であり、個々の業

務毎に実施せざるを得ない。業務プロセスの識別と共通化は、業務改革・改善を計画する上で必須であるが、業務処

理統制の計画においても鍵となる作業となっている。



・重要な勘定科目に関連するビジネスプロセス（Ex.売上高⇒営業プロセス，貸倒引当金⇒決算プロセス）を選択。

・ビジネスプロセスをサブプロセスに分解して，重要な勘定科目に直接的に影響するサブプロセス（Ex.貸倒引当金⇒決算（引当金評価）），間接的に影響を及ぼすサブプロセス（ Ex.貸倒引当金⇒債権管理（売掛金回収））を選択。

現金および預金

重要科目

受取手形

売掛金

プロセス

営業調達生産物流原価資金

ビジネスサポート

決算・・・・・・

○ ○

○ ○ ○

○ ○ ○

売上高

重要科目

○

○

サブプロセス

見積り

営業プロセス調達プロセス

受注出荷売上・・・発注検収仕入・・・

図４．１４重要なビジネスプロセスの選択（文献２による）

統制の文書化設計においては、業務プロセスに対するリスクを把握し、それに対する統制（コントロール）の方法

を設計していく。コントロールの方法は、職務の分離、承認・決裁、照合・調整など従来から知られた方法がいくつ

か存在するが、いずれも一つの方法で完全にリスクを除去できるものではないので、一つのリスクに対して複数のコ

ントロールが設定されることが多い。

販売業務 R1 不適切な販売

R2 出荷内容の誤り

C1 債権管理担当者による顧客の信用調査

C4 物流部門責任者による出荷内容レビュー

職務の分離

C5 注文書と出荷指示書との照合（営業）

C2 法務部門による契約書の審査職務の分離

照合・調整

C3 販売部門責任者による契約書の承認承認・決裁

C7 売上伝票と出荷報告書との照合（経理）

C6 得意先元帳と総勘定元帳との内容照合照合・調整

R4 ﾃﾞｰﾀ伝送・入力漏れ C8 物流ｼｽﾃﾑの出荷ﾃﾞｰﾀによる自動消し込み I/F照合

C10 販売管理ｼｽﾃﾑへのアクセス権限の設定アクセス管理

ITｺﾝﾄﾛｰﾙ

R5 不正処理・アクセス

C11 得意先ﾏｽﾀ登録企業以外への請求禁止誤謬チェック

C9 売掛金未回収リストによる支払い督促例外チェック

ITｺﾝﾄﾛｰﾙ

R3 売掛金残高の誤り

管理者レビュー

照合・調整

プロセスリスクコントロール統制種類

図４．１５販売プロセスのリスクと統制の事例（文献２による）



統制の計画および文書化設計により統制システムを整備した業務を実施し、その上で統制が実際に機能しているか否

かのテストを実施する。さらにこのテスト結果に基づいて、不備が残されているなら改善するなど内部統制全体とし

ての有効性を検証し、最終評価を報告することになる。



５．参考文献

［１］湯浦克彦、「IT ガバナンスの構造－SOX 法と CSR が変える企業システム」、エスアイビーアクセス社刊、

2006 年 3 月

［2］湯浦克彦、染谷英雄、河辺亮二、「IT コンサルタントのための会計知識～内部統制と経営最適化の実現～」、

ソフトリサーチセンター社刊、2006 年 6 月

［３］日本公認会計士協会 IT 委員会報告第一号、「財務諸表監査における情報技術（IT）を利用した情報システム

に関する統制リスクの評価」、JICPA ジャーナル、2003 年３月号

［４］IT ガバナンス協会、「SOX 法のための IT コントロール目標」、2004 年４月、http://www.itgi.org/

［５］IT ガバナンス協会、COBIT4.0、2005 年 11 月、http://www.itgi.org/

［６］経済産業省、「システム管理基準」、 200４年 10 月、

http://www.meti.go.jp/policy/it_policy/press/0005668

［７］経済産業省、「情報セキュリティ管理基準」、 200３年３月、

http://www.meti.go.jp/policy/netsecurity/audit.htm

［８］日本情報処理開発協会、「ISMS 認定基準」、 200４年 10 月、

http://www.jipdec.jp/std/std.htm

［９］ Office of Government Commerce、“Service Delivery “、Stationary Office, 2001.

［10］Office of Government Commerce、“Service Support“、Stationary Office, 2000.

［11］経済産業省、「情報システムに係る政府調達への SLA ガイドライン」、 200４年３月、

http://www.meti.go.jp/kohosys/press/0005140

［12］総務省、「公共 IT におけるアウトソーシングに関するガイドライン」、 200３年３月、

http://www.lasdec.nippon-net.ne.jp/support/

［13］電子情報技術産業協会、「民間向け IT システムの SLA ガイドライン」、日経 BP 出版センター刊、 200

４年９月

〈注〉URL は全て 2006 年 1 月現在

なお、”COBIT”とCOBITのロゴは情報システムコントロール財団およびITガバナンス協会の商標であり、

COBIT の内容に関する記述は、情報システムコントロール財団および IT ガバナンス協会に著作権がある。ま

た、”ITIL”は英国セ政府商務局の登録商標である。本報告書では、Copyright, TM, ®マーク等は省略している。

Ⅱ-ⅰ ＩＴアーキテクチャ策定ガイドライン

Ⅱ-ⅰ １経済産業省版 1

Ⅱｰⅰ １ＩＴアーキテクチャ策定ガイドライン経済産業省版

// CONTENTS // １．アーキテクチャの概要 ...................................................................................................................................... 2 1.1. 構成要素 ..................................................................................................................................................... 2 1.2. アーキテクチャ間の関連 ........................................................................................................................... 3 2. アーキテクチャの設計 .................................................................................................................................... 4 2.1. ビジネスアーキテクチャ（ＢＡ） ............................................................................................................ 4 2.2. データアーキテクチャ（ＤＡ）................................................................................................................ 5 2.2.1. データ参照モデル（ＤＲＭ：Data Reference Model） .............................................................. 5 2.2.2. イベント情報構造 ............................................................................................................................... 5 2.2.3. エンティティ構造 ............................................................................................................................... 6 2.2.4 . データアーキテクチャの設計 ........................................................................................................... 6 2.3. アプリケーションアーキテクチャ（ＡＡ） ............................................................................................... 7 2.3.1. サービスコンポーネント参照モデル（ＳＲＭ：Service-component Reference Model）.. 7 2.3.2. コンポーネントの粒度.......................................................................................................................... 8 2.3.3. アプリケーションアーキテクチャの設計.......................................................................................... 9 2.4. テクノロジアーキテクチャ...................................................................................................................... 10 2.4.1. テクノロジ参照モデル（TRM：Technology Reference Model）.......................................... 10 2.4.2. テクノロジアーキテクチャの設計................................................................................................... 11

3. アーキテクチャのモデリング言語.................................................................................................................. 11 3.1. ビジネスアーキテクチャ ......................................................................................................................... 11 3.1.1. 機能情報関連図（ＤＦＤ） .............................................................................................................. 11 3.1.2. 業務流れ図 ........................................................................................................................................ 12 3.1.3. 情報体系整理図................................................................................................................................. 12 3.2. データアーキテクチャ............................................................................................................................. 13 3.2.1. 実体関連図 ........................................................................................................................................ 13 3.2.2. データ定義表..................................................................................................................................... 14 3.3. アプリケーションアーキテクチャ ............................................................................................................ 14 3.3.1. システム関連図................................................................................................................................. 14 3.3.2. パッケージ図..................................................................................................................................... 15 3.3.３. コンポーネント図 ............................................................................................................................ 15 3.3.４. イベント流れ図 ................................................................................................................................ 15 3.4. テクノロジアーキテクチャ...................................................................................................................... 16 3.4.1. ネットワーク構成図.......................................................................................................................... 16 3.4.2. ソフトウェア構成図.......................................................................................................................... 17 3.4.3. ハードウェア構成図.......................................................................................................................... 17



１．アーキテクチャの概要

参照モデル

アーキテクチャモデル

業務体系（Business Architecture ）

データ体系（Data Architecture ）

適用処理体系（Applications Architecture ）

技術体系（Technology Architecture ）

Standards （データモデル、セキュリティ要件などの標準を策定）

現状

BusinessArchitecture

DataArchitecture

ApplicationsArchitecture

TechnologyArchitecture

目標


DataArchitecture



Transitional Processes （業務、システムなどの移行管理計画を策定）

参照モデル

アーキテクチャモデル






現状


DataArchitecture



目標


DataArchitecture









現状


DataArchitecture



目標


DataArchitecture









現状


DataArchitecture



目標


DataArchitecture




想定するアーキテクチャの構成要素は上図のとおり。 1.1. 構成要素

■アーキテクチャモデル

標準とするアーキテクチャモデリング言語について規定したもの。下記のアーキテクチャについて規定して

いる。

・ビジネスアーキテクチャ（業務体系） ―ＢＡ－

・データアーキテクチャ（データ体系） ―ＤＡ－

・アプリケーションアーキテクチャ（適用処理体系） ―ＡＡ―

・テクノロジアーキテクチャ（技術体系） ―ＴＡ―

■標準（Standards）

アーキテクチャが準拠する標準を規定したもの。

・データモデル

・セキュリティ要件等

■現状アーキテクチャ

・アーキテクチャで規定されたモデリング言語で現状のアーキテクチャを記述したもの。

■参照モデル



・再利用可能なＩＴ資産（コンポーネント）を整理、分類体系化したもの。

■目標アーキテクチャ

・アーキテクチャで規定されたモデリング言語で目標のアーキテクチャを記述したもの。

■移行計画（Transitional Processes）

・業務移行計画

・システム移行計画等

これらの構成要素は、統一的な標準記述様式から構成され、各業務・システムの機能、構成等を整合的に分

類し、整理するものであり、業務・システムの現状から将来の在るべき姿に移行するための戦略的な基盤と

して活用する。

1.2. アーキテクチャ間の関連

各アーキテクチャを設計するためのモデリング言語（記述様式）については後述するが、その関係は以下の

とおり。

BA

AA

TA

DA（イベント情報）

DA（エンティティ情報）

■ビジネスアーキテクチャ（ＢＡ）は、業務の機能と業務機能間を流れるデータ（イベント情報）を明確にし、

最終的に業務フローとしてモデル化する。ＢＡのステークホルダは経営者等のマネージメント層で、彼らの

システムに対する関心事から見たビューにより可視化される。 ■データアーキテクチャ（ＤＡ）は、イベント情報とエンティティから構成される。イベント情報の識別はＢ

Ａ設計の中で行われるので、ＤＡとしてはその構造を論理的に明確化する。一方エンティティ（ヒト、モノ、

カネに関するリソース情報）は、企業活動におけるエンティティを識別することにより設計される。最終的

にデータベースの論理設計（ＥＲ図）として可視化される。



■アプリケーションアーキテクチャ（ＡＡ）は、アプリケーションコンポーネントが提供するサービスとこの

サービスを実装するコンポーネント自身から構成される。サービス層のステークホルダは設計者で、ＢＡで

明らかになった業務機能を可能な限り既存のコンポーネントを再利用することに努めながら識別していく。

設計作業としては業務機能とコンポーネントが提供するサービスとをマッピングさせながら組み立ててい

く。サービスはコンポーネントのインタフェースを通して提供される。コンポーネントはアプリケーション

層に配置されるが、ステークホルダとしての開発者は当初明確にされている業務機能に近い粒度のコンポー

ネントを実装のための粒度のコンポーネントに詳細化する。最も詳細化されたコンポーネントが既存のＩＴ

資産としてなければ開発を行い再利用のためにリポジトリに登録する。 ■テクノロジアーキテクチャ（ＴＡ）は、ＤＡ、ＡＡを物理的に実装するためのＩＴ技術を選択し配置して、

物理的に稼働可能な形に設計する。

2. アーキテクチャの設計

アーキテクチャの設計はビジネスアーキテクチャの設計から始めてテクノロジアーキテクチャの設計で完

了する。ここでは各アーキテクチャを設計するために採用したモデリング言語および手順について簡単に紹介

する。 2.1. ビジネスアーキテクチャ（ＢＡ）

稼動給与等支払

人事評価

研修人事給与

モニタリング

厚生共済

採用配属

計画

採用・異動辞令

職員・アルバイト採用

異動対象者決定

採用配属

退職

個人希望調査

組織希望調査

採用計画

年末調整

退職金支払

予算・支払実績等作成

返納金徴収

給与等支払

給与賞与支払

給与賞与計算準備

予算策定

研修実施

習熟度テスト実施

アンケート分析

個別研修計画

研修研修結果評価

受講者募集

年間研修計画

研修テーマ募集

利用許可

利用利用料請求

審査厚生

共済

利用料回収

調整申込受付

調査計画

アルバイト出勤管理

出勤簿

整理

セキュリティクリアランス

出勤簿休暇簿記入

稼動予実評価

勤務時間報告書作成

出勤時間帯決定

業務指図

決定規程類改正

折衝計画行政目標策定

定数改訂機構要求検討

人事計画

勤勉手当成績率作成

永年勤続表彰

叙勲・褒賞準備

処分人事評価

叙勲・褒賞

昇任・昇格

評価評価基準作成

定期的内部評価

課題報告

モニタリング

改善案報告

差異分析

部分がシステム化される業務


人事評価

研修人事給与

モニタリング

厚生共済

採用配属

計画




採用配属

退職

個人希望調査

組織希望調査

採用計画

年末調整

退職金支払


返納金徴収

給与等支払

給与賞与支払


予算策定

研修実施



個別研修計画


受講者募集

年間研修計画


利用許可


審査厚生

共済

利用料回収

調整申込受付

調査計画


出勤簿

整理



稼動予実評価



業務指図




人事計画


永年勤続表彰


処分人事評価

叙勲・褒賞

昇任・昇格



課題報告

モニタリング

改善案報告

差異分析


省内各課室

省内各課室

機構定員設定

機構定員設定

採用・配属採用・配属

厚生厚生

共済共済

要求項目

総務省行政管理局


内示

併任先併任先

改正規程掲載依頼

研修研修

結果

財務省財務省

内閣府内閣府

講師講師

職員アルバイト


出退勤・超勤管理

出退勤・超勤管理給与等支払給与等支払

人事評価人事評価

表彰・叙勲表彰・叙勲人事ファイル

機構定員＆定数改定

役職別人数結果

人事院人事院

定数改定

機構定員

人事記

録

内々定者

内々定者

人事院人事院

合格者情報

職員職員

内定

通知

希望・発令

共済組合

共済組合

個人票

人事記録

申請・承認

利

用料回収指示利用料回収指

示

申請・承認

共済組合共済組合

申請・承認



給

与明細書

支払

被災職員被災職員

申請・支払

財務省財務省税務署税務署

税・申告・源泉徴収票

受講者受講者

省内各課室

省内各課室

研修計画案・募集

依頼受講記録

結果通知・アンケート

出勤簿・休暇簿記入／確認

出勤状況

人事評価

勤務日数勤務報告書実

績報告

職員職員

発令・処分

昇任・昇格

宮内庁

宮内庁指示

業界団体等

業界団体等

推薦・内示

表彰プレスプレス結果公表

調整

省内各課室

省内各課室

機構定員設定

機構定員設定


厚生厚生

共済共済

要求項目



内示

併任先併任先


研修研修

結果

財務省財務省

内閣府内閣府

講師講師






表彰・叙勲表彰・叙勲人事ファイル人事ファイル



人事院人事院

定数改定

機構定員

人事記

録

内々定者

内々定者

人事院人事院

合格者情報

職員職員

内定

通知

希望・発令

共済組合

共済組合

個人票

人事記録

申請・承認

利


示

申請・承認


申請・承認



給

与明細書

支払


申請・支払



受講者受講者

省内各課室

省内各課室


依頼受講記録



出勤状況

人事評価


績報告

職員職員

発令・処分

昇任・昇格

宮内庁

宮内庁指示

業界団体等

業界団体等

推薦・内示


調整

申請者Ａ省認証局

PC オンライン申請システム認証局サーバ

申請書作成アプリケーション

＜記号説明＞

手作業

確認、チェック

保管

コンピュータ処理

コンピュータ画面

帳票

コンピュータファイル

＜記号説明＞

手作業


保管



帳票


様式ファイルの

形式チェック

申請書

証明書の確認

到着確認

シート発行

申請書の受信

申請書送信アプリケーション

電子証明書


不足チェック

申請書の送信認証

到着確認シート受領

到達確認シート

到着確認シート表示

申請者

様式ファイル

ヘルプファイル

編集

参照

ヘルプ参照

様式ファイル

の選択

証明書の

指定

ID・ﾊﾟｽﾜｰﾄﾞの指定

DMM DFD WFA


人事評価

研修人事給与

モニタリング

厚生共済

採用配属

計画




採用配属

退職

個人希望調査

組織希望調査

採用計画

年末調整

退職金支払


返納金徴収

給与等支払

給与賞与支払


予算策定

研修実施



個別研修計画


受講者募集

年間研修計画


利用許可


審査厚生

共済

利用料回収

調整申込受付

調査計画


出勤簿

整理



稼動予実評価



業務指図




人事計画


永年勤続表彰


処分人事評価

叙勲・褒賞

昇任・昇格



課題報告

モニタリング

改善案報告

差異分析



人事評価

研修人事給与

モニタリング

厚生共済

採用配属

計画




採用配属

退職

個人希望調査

組織希望調査

採用計画

年末調整

退職金支払


返納金徴収

給与等支払

給与賞与支払


予算策定

研修実施



個別研修計画


受講者募集

年間研修計画


利用許可


審査厚生

共済

利用料回収

調整申込受付

調査計画


出勤簿

整理



稼動予実評価



業務指図




人事計画


永年勤続表彰


処分人事評価

叙勲・褒賞

昇任・昇格



課題報告

モニタリング

改善案報告

差異分析


省内各課室

省内各課室

機構定員設定

機構定員設定


厚生厚生

共済共済

要求項目



内示

併任先併任先


研修研修

結果

財務省財務省

内閣府内閣府

講師講師









人事院人事院

定数改定

機構定員

人事記

録

内々定者

内々定者

人事院人事院

合格者情報

職員職員

内定

通知

希望・発令

共済組合

共済組合

個人票

人事記録

申請・承認

利


示

申請・承認


申請・承認



給

与明細書

支払


申請・支払



受講者受講者

省内各課室

省内各課室


依頼受講記録



出勤状況

人事評価


績報告

職員職員

発令・処分

昇任・昇格

宮内庁

宮内庁指示

業界団体等

業界団体等

推薦・内示


調整

省内各課室

省内各課室

機構定員設定

機構定員設定


厚生厚生

共済共済

要求項目



内示

併任先併任先


研修研修

結果

財務省財務省

内閣府内閣府

講師講師









人事院人事院

定数改定

機構定員

人事記

録

内々定者

内々定者

人事院人事院

合格者情報

職員職員

内定

通知

希望・発令

共済組合

共済組合

個人票

人事記録

申請・承認

利


示

申請・承認


申請・承認



給

与明細書

支払


申請・支払



受講者受講者

省内各課室

省内各課室


依頼受講記録



出勤状況

人事評価


績報告

職員職員

発令・処分

昇任・昇格

宮内庁

宮内庁指示

業界団体等

業界団体等

推薦・内示


調整




＜記号説明＞

手作業


保管



帳票


＜記号説明＞

手作業


保管



帳票



形式チェック

申請書

証明書の確認

到着確認

シート発行

申請書の受信


電子証明書


不足チェック





申請者

様式ファイル


編集

参照

ヘルプ参照

様式ファイル

の選択

証明書の

指定


DMM DFD WFA

（業務）機能イベント情報システム領域

ＤＦＤのフローから

明確化

ＤＦＤの機能から

明確化

ＷＦＡの矢印から

明確化

ＷＦＡの処理等から

明確化

既に説明したように、ビジネスアーキテクチャ（ＢＡ）の設計は要求される業務機能および各業務機能間を

流れるデータを明確にし最終的に業務プロセス（業務フロー）を設計することを目的として行われる。この際

使用されるモデリング言語としてはＤＭＭ、ＤＦＤ、ＷＦＡが規定されている。ＤＭＭ（Diamond Mandara Matrix）は省略しても構わないが、業務機能をより詳細な業務機能にブレークダウンする際に使用される。DMM詳細化のレベルは３までとする。次に、最も詳細化された業務機能それぞれについてＤＦＤ（Data Flow Diagram）を記述し、機能間を流れるデータ（イベント情報）を明確化する。ＤＦＤの詳細化レベルも３までとする。最後に、最も詳細化されたＤＦＤからワークフロー図（ＷＦＡ：Work Flow Architecture）を作成する。ＷＦＡは各システム領域（クライアント、Ａ省、認証局等）を明確にし、各システム領域に配置する業



務機能、流れるデータを明確にする。 2.2. データアーキテクチャ（ＤＡ）

2.2.1. データ参照モデル（ＤＲＭ：Data Reference Model）

データアーキテクチャを設計する際に、既存のＩＴ資産（データコンポーネント）を再利用するように努め

る必要がある。既に説明したように、データコンポーネントとしてはイベント情報とマスタ（エンティティ）

情報から構成されている。イベント情報はエンティティを業務機能から他の業務機能へ引き渡すためのコンテ

ナとして働く。データコンポーネントを再利用するための分類体系化フレームワークとしてデータ参照モデル

が用意されている。データ参照モデルの詳細は後述するが、基本としてのエンティティおよびエンティティを

運ぶためのコンテナであるイベント情報（情報交換パッケージ）、さらに上位の分類体系としてのビジネス視点

から構成されている。下記にデータ参照モデルについて示す。

ビジネスニーズ

サブジェクト領域

情報体系（ﾒｼﾞｬｰﾃﾞｰﾀﾌﾞﾛｯｸ）

情報交換メッセージ（ｺﾝﾊﾟｳﾝﾄﾞﾃﾞｰﾀﾌﾞﾛｯｸ）

エンティティ定義（データブロック）

属性項目定義（データエレメント）

共通属性定義

ビジネス視点からのデータ分類

サブジェクト領域ごとの情報グループ

DFD上のプロセス間を流れる情報（メッセージ）の定義グループ

管理対象となるエンティティ

エンティティの属性項目定義

複数のエンティティで共有される共通フォーマット定義

データ定義の詳細化

データ視点

ﾋﾞｼﾞﾈｽﾃﾞｰﾀﾌﾛｰ

ビジネス視点

2.2.2. イベント情報構造

イベント情報の構造は、イベント名（情報交換パッケージ名）と含まれるエンティティのリストとして構成

される。下記にイベント名 “申請文書” におけるイベント情報構造の例を記載する。申請文書は申請書受領、申請書チェック、審査等のエンティティのコンテナであり、エンティティ申請書受領には申請書番号、組織コ

ード、法令コードといった属性が定義されている。またこのイベントはサブジェクト領域 “実施”、情報体系 “申請／届出の受付と管理” に分類されている。



戦略的情報収集と分析・・・・・・・・・政策立案／戦略策定・・・・・・・・・資源配置の最適化・・・・・・・・・

情報管理統計的情報収集と分析・・・・・・・・・記録維持・・・・・・・・・

申請書番号組織コード法令コード申請書ID組織コードグループID職員番号申請書番号職員番号申請書ID組織コード職員番号文書番号文書番号申請書ID申請書ID組織コード職員番号文書番号申請書番号申請書ID

・・・・・・・・・

情報交換メッセージ

公文書作成

公印付与

公文書発行

申請文書

申請書受領

申請書チェック

企画立案と資源配置

申請／届出の受付と管理実　　施

共通属性定義

審査

決済

サブジェクト領域情報体系エンティティ定義属性項目定義

2.2.3. エンティティ構造

エンティティ構造の例を下記に示す。ここではエンティティ “起案文書” は属性項目 “文書番号”、“申請者ＩＤ” から構成されている。また起案文書はサブジェクト領域 “共通情報リソース” の情報体系 “知的資源／法令等／文書資源” に分類されている。

大分類中分類法人事業者申請者申請者番号個人事業者申請者申請者番号

申請書申請書ID文書番号申請書ID文書番号申請書ID文書番号申請書ID

共通属性定義サブジェクト領域

共通情報リソース

起案文書

施行文

公文書

文書資源

事業者人的資源

法令等

情報体系エンティティ定義属性項目定義

知的資源

2.2.4 . データアーキテクチャの設計

イベント情報はエンティティを運ぶためのコンテナであり、BA で明らかにされたイベント情報について必要とするエンティティを洗い出して構造を定義する。エンティティは業務処理の対象となる物理的存在、概念、

事象に係る情報で、エンティティ間の関係をER図に基づき表現する。



2.3. アプリケーションアーキテクチャ（ＡＡ）

2.3.1. サービスコンポーネント参照モデル

（ＳＲＭ：Service-component Reference Model）

アプリケーションアーキテクチャを設計する際に、既存のＩＴ資産（アプリケーションコンポーネント）を

再利用するように努める必要がある。アプリケーションコンポーネントを再利用するための分類体系化フレー

ムワークとして、サービスコンポーネント参照モデルが用意されている。既存のアプリケーションコンポーネ

ントはSRMの分類体系に則って整理され蓄積されている。SRMはサービス領域および各サービス領域に属するサービスタイプ、サービスタイプを詳細化したサービスコンポーネントとして分類体系が構成されている。

またサービス領域は顧客サービスからバックオフィスサービスまで６つの領域があり、さらにこの６つのサー

ビス領域に共通の支援サービスが用意されている。SRMの分類体系を下記に示す。

顧客サービス

プロセスオートメーションサービス

ビジネスマネージメントサービス

ＩＴ資産サービス

ビジネス分析サービス

バックオフィスサービス

支援サービス

(i.e.

, Se

arch

, Se

curit

y)

サービスタイプ

サービス領域

サービスコンポーネント

パフォーマンス尺度ビジネスプロセス

アクセスとデリバリのチャネル

顧客サービス






支援サービス

(i.e.

, Se

arch

, Se

curit

y)


サービス領域



アクセスとデリバリのチャネル【ＴＲＭ】

【ＰＲＭ】【ＢＲＭ】

各サービス領域に属するサービスタイプを下記に示す。

顧客サービス領域

プロセスオートメーションサービス領域

顧客のプリファレンス顧客によるアシスタンスＣＲＭ(Customer Relationship Management)

トラッキングとワークフロールーティングとオートメーション

ビジネスマネージメントサービス領域

プロセスの管理ＳＣＭ（Supply Chain Management）組織管理投資管理

ＩＴ資産サービス領域

コンテンツ管理ドキュメント管理ナレッジマネージメントレコード管理

ビジネス分析サービス領域

分析、統計表示ビジネスインテリジェンスレポーティング

バックオフィスサービス領域

データ管理資産/資材管理人的資源開発と統合財務管理人的資本/労働力管理

支援サービス領域

セキュリティ管理コミュニケーションシステム管理コラボレーションフォーム検索




サービスコンポーネントの例として顧客サービス領域のコンポーネントを下記に示す。ここでいうコンポー

ネントは分類体系としての論理的なものであって、この下に物理的に実装可能なソフトウェアコンポーネント

が分類されることになる。コンポーネントの前に付与されている番号は経済産業省で付与したコンポーネント

番号を表す。

コンポーネントの意味１－１１－１－１コールセンタ管理顧客への電話セールス、電話サービス処理のた

めの機能１－１－２顧客分析組織の顧客について、第三者情報のスコアリング

を含めて顧客分析を可能にする機能１－１－３販売とマーケティング製品やサービスおプロモーションおよび新規ビジ

ネスを見つけるための機能１－１－４製品管理製品やサービスを開発し保守するための機能１－１－５ブランド管理製品やサービスの取引におけるブランド名に関す

るアプリケーション、ブランド名管理をするための機能

１－１－６顧客／アカウント管理組織の顧客へ、製品やサービスを配布し維持するために必要な機能

１－１－７コンタクト管理顧客とその顧客に関係する組織のアクティビティを記録・追跡するために必要な機能

１－１－８パートナーリレーションシップ管理組織、ステークホルダ、ビジネスﾊﾟｰﾄﾅｰそれぞれの間のアクティビティを計画しコントロールするための機能

１－１－９顧客フィードバック顧客からのコメント、フィードバックを収集、分析、処理するための機能

１－１－１０顧客調査顧客から有益な情報を収集するために必要な機能

１－２１－２－１パーソナリゼーションユーザインターフェースとデータ表示方法を変更することを可能にする機能

１－２－２サブスクリプションフォーラム、メーリングリスト等に顧客が参加するための機能

１－２－３警告と通知顧客が興味のあるサービス、サブスクリプションに接触を可能とするために必要な機能

１－２－４プロファイル管理顧客のプロファイルに関係するアカウント情報を保守、更新のために必要な機能

１－３１－３－１オンラインヘルプ顧客をアシスタンスするための電子的なインタフェースを提供する機能

１－３－２オンラインチュートリアル顧客を教育しアシストするための電子的なインタフェースを提供する機能

１－３－３セルフサービス顧客自身が率先して特別なサービスのためのサインアップをするための機能(レジストレーション）

１－３－４リザベーション／登録サービスの登録と確認のためのサインアップをするための機能

１－３－５多国語サポートデータと情報へ複数への言語でアクセスすることを可能にする機能

１－３－６アシスタント要求顧客からのサポート依頼を支援するための機能１－３－７スケジューリング顧客ニーズに対応するために実施する作業、サー

ビスの計画を支援する機能

サービスタイプコンポーネントCRMCRMは、製品やサービスの提供を開始する前と開始した後における、顧客と組織間でのアクティビティを計画、スケジュール、コントロールするための機能を定義する。

顧客嗜好対応顧客がユーザインターフェースとデータ表示方法を変更することを可能とする機能を定義する。

顧客によるアシスタンス（組織からのアシスタンスとサービスを顧客が事前に探索することを可能とする機能）

2.3.2. コンポーネントの粒度

アプリケーションコンポーネントにはいくつかの粒度がある。下記に粒度のレベルとその内容について記載

する。

オブジェクト指向プログラミング言語によるクラスで作成された分散コンポーネント。これはＳＲＭコンポーネントとしては対象外。

言語クラス

最小レベルの粒度のコンポーネント。ランタイム時に呼び出すことが出来るソフトウェアエレメントで、明確なインタフェースおよびインタフェースと実装が明確に分離されている。自律的に実装可能。

分散コンポーネント

自律的なビジネスプロセスやビジネスコンセプトを実装する。これらは、大きな情報システムの自律的で再利用可能な要素としてビジネスコンセプトを表現し実装するために必要なすべての技術要素（ソフト、ハード、データ等）から構成される。開発ライフサイクルと分散階層を統合する概念。

ビジネスコンポーネント

ビジネスの課題に対するソリューションを提供するために互いに組み合わせるビジネスコンポーネントの集合。

ビジネスコンポーネントシステム

互いに協調するシステムレベルコンポーネントの集まりで、異なる組織に属する複数のエンドユーザにとって必要なビジネスニーズを解決する。

連携コンポーネント

定義粒度のレベル

オブジェクト指向プログラミング言語によるクラスで作成された分散コンポーネント。これはＳＲＭコンポーネントとしては対象外。

言語クラス

最小レベルの粒度のコンポーネント。ランタイム時に呼び出すことが出来るソフトウェアエレメントで、明確なインタフェースおよびインタフェースと実装が明確に分離されている。自律的に実装可能。

分散コンポーネント

自律的なビジネスプロセスやビジネスコンセプトを実装する。これらは、大きな情報システムの自律的で再利用可能な要素としてビジネスコンセプトを表現し実装するために必要なすべての技術要素（ソフト、ハード、データ等）から構成される。開発ライフサイクルと分散階層を統合する概念。

ビジネスコンポーネント

ビジネスの課題に対するソリューションを提供するために互いに組み合わせるビジネスコンポーネントの集合。


互いに協調するシステムレベルコンポーネントの集まりで、異なる組織に属する複数のエンドユーザにとって必要なビジネスニーズを解決する。

連携コンポーネント

定義粒度のレベル



ここで最も重要な粒度のレベルとしてビジネスコンポーネントシステム（システムレベルと略記）とビジネ

スコンポーネントが挙げられる。システムレベルのコンポーネントは、特定のビジネスの課題に対するソリュ

ーションを提供するもので、粒度は大きいが特定のビジネスでしか再利用はできない。一方ビジネスコンポー

ネントは、特定のビジネスを想定しない少し粒度の小さいコンポーネントで、再利用性は高いが対象とする範

囲は小さくなる。 2.3.3. アプリケーションアーキテクチャの設計

BAの業務フロー（WFA）によりシステム領域、業務機能とイベント情報が明確になっているので初めに業務機能についてシステムレベルの粒度でアプリケーションアーキテクチャを設計する。このシステムレベルの

コンポーネントを詳細化していき最終的に SRMで規定しているアプリケーションコンポーネントにマッピングを行う。さらにアプリケーションコンポーネント間に流れるイベント情報との関係を対応づけて整合性を確

認する。

文書管理システム個別業務システム

認証局の

システム

財務省の

システム

申請者の

システム（ＰＣ）

Ａ　省

電子申請システム

文書管理システム個別業務システム

認証局の

システム

財務省の

システム

申請者の

システム（ＰＣ）

Ａ　省

電子申請システム

：インターナルクライアントＰＣ

<<ﾌﾞﾗｳｻ゙ >>

申請書名

<<ｲﾍ゙ﾝﾄ>>申請書検索

<<ｲﾍ゙ﾝﾄ>>申請書

申請書

識別と認証

ログイン認証

受付管理サーバ：申請システム申請書管理サーバ：申請システム

Struts

申請書の検索

業務システム

決済システム

情報検索

電子メール

メール送信

データ交換

申請書送信

データ交換

申請書受信

請求管理

申請者に課金・請求

<<ｲﾍ゙ﾝﾄ>>

申請書訂正依頼

依頼文

：パブリッククライアントＰＣ

<<メーラー>>

メール受信

データ交換

決済処理

顧客サービス






支援サービス

(i.e

., Se

arch

, Sec

urity

)


サービス領域




顧客サービス






支援サービス

(i.e

., Se

arch

, Sec

urity

)


サービス領域




【ｻｰﾋﾞｽｺﾝﾎﾟｰﾈﾝﾄ参照モデル（SRM)】

システムレベル配置図コンポーネントレベル配置図コンポーネントレベル配置図

イベント流れ図必要なコンポーネントがリストアップされたら、テクノロジアーキテクチャのフレームに従って実装をイメ

ージして配置図を作成する。コンポーネント配置図の例を下記に示す。



ユーザー管理

ユーザー

・申請者情報の管理・ID/PSWの管理・証明書の管理

外部クライアント

7-1-1

7-1-7

メタデータ管理

6-1-4

・利用可能な申請書を管理

情報検索

4-3-1

・利用可能な申請書

を検索

レコードの関連付け

4-4-1

・入力内容のチェック

・手数料処理・過去の申請書との関連付・審査状況情報を保存

抽出と変換

6-1-6

・申請内容PDF出力

電子メール

7-2-1

・公文書発行を申請者にメール通知

ﾗｲﾌﾞﾗﾘ/ｽﾄﾚｰｼﾞ

4-2-4

・ダウンロード可能な状態で保存

ストレージ

経路(チャネル) 処理(プロセス) 共通処理(プロセス)

内部クライアント

7-1-1

外部ポータル

共通経路(チャネル)

ﾕｰｻﾞｰ情報

・メニュー制御・権限管理

内部ポータル

・メニュー制御

・権限管理

ﾒﾀﾃﾞｰﾀ

★

★

請求管理(決済)

6-3-1

・申請者に課金・請求

ﾌﾟﾛｾｽﾄﾗｯｷﾝｸﾞ

・審査状況・申請書

審査状況

PDF保管

文書管理ｼｽﾃﾑ

・公文書管理・公文書ﾃﾝﾌﾟﾚｰﾄ管理・公文書作成・公文書承認・公文書発行・公文書暗号化・公文書を申請ｼｽﾃﾑへ

申請書

申請業務画面

・画面制御

★

役割/権限管理

・担当者権限管理

7-1-8


2-1-1

・申請書を承認・審査状況を申請ｼｽ

ﾃﾑへ

ドキュメント参照

4-2-2

・公文書発行を要求

公文書

2-1-1 ★

識別と認証

・ログイン認証

識別と認証


データ交換

6-1-1

・決済処理呼び出し

・業務ｼｽﾃﾑへ転送・ﾒｰﾙ送信・公文書受け取り

・公文書をﾗｲﾌﾞﾗﾘへ

・審査状況を申請ｼｽﾃﾑへ

電子申請画面

・画面制御

★

審査状況

★

認証局

・証明書発行・整合性確認

★

ユーザー管理

ユーザー

・申請者情報の管理・ID/PSWの管理・証明書の管理

外部クライアント

7-1-1

7-1-7

メタデータ管理

6-1-4

・利用可能な申請書を管理

情報検索

4-3-1

・利用可能な申請書

を検索

レコードの関連付け

4-4-1

・入力内容のチェック

・手数料処理・過去の申請書との関連付・審査状況情報を保存

抽出と変換

6-1-6

・申請内容PDF出力

電子メール

7-2-1

・公文書発行を申請者にメール通知

ﾗｲﾌﾞﾗﾘ/ｽﾄﾚｰｼﾞ

4-2-4

・ダウンロード可能な状態で保存

ストレージ

経路(チャネル) 処理(プロセス) 共通処理(プロセス)

内部クライアント

7-1-1

外部ポータル

共通経路(チャネル)

ﾕｰｻﾞｰ情報

・メニュー制御・権限管理

内部ポータル

・メニュー制御

・権限管理

ﾒﾀﾃﾞｰﾀ

★

★

請求管理(決済)

6-3-1

・申請者に課金・請求


・審査状況・申請書

審査状況

PDF保管

文書管理ｼｽﾃﾑ

・公文書管理・公文書ﾃﾝﾌﾟﾚｰﾄ管理・公文書作成・公文書承認・公文書発行・公文書暗号化・公文書を申請ｼｽﾃﾑへ

申請書

申請業務画面

・画面制御

★

役割/権限管理

・担当者権限管理

7-1-8


2-1-1

・申請書を承認・審査状況を申請ｼｽ

ﾃﾑへ

ドキュメント参照

4-2-2

・公文書発行を要求

公文書

2-1-1 ★

識別と認証


識別と認証


データ交換

6-1-1

・決済処理呼び出し

・業務ｼｽﾃﾑへ転送・ﾒｰﾙ送信・公文書受け取り

・公文書をﾗｲﾌﾞﾗﾘへ

・審査状況を申請ｼｽﾃﾑへ

電子申請画面

・画面制御

★

審査状況

★

認証局

・証明書発行・整合性確認

★

2.4. テクノロジアーキテクチャ

2.4.1. テクノロジ参照モデル（TRM：Technology Reference Model）

テクノロジアーキテクチャを設計する際に既存の IT 資産（テクノロジコンポーネント）を再利用するように努める必要がある。テクノロジコンポーネントを再利用するための分類体系化フレームワークとしてテクノ

ロジ参照モデル（TRM）が用意されている。TRMはアプリケーションプラットフォーム、アプリケーションソフトウェア、外部環境、共通基盤の領域から構成されている。

外部環境

土台（ベース）

処理（プロセス）

情報（データ）経路

（チャネル）

アプリケーションソフトウェア

共通基盤

アプリケーションプラットフォーム

外部環境



情報（データ）経路

（チャネル）


共通基盤




それぞれのテクノロジ領域は下記のように詳細分類されている。最終的にそれぞれの分類体系の中に使用す

る IT技術が配置されている。（例アプリケーションプラットフォーム領域―土台―OSサービス→Linux）

アプリケーションソフトウェアアプリケーションプラットフォーム外部環境共通基盤

ＴＲＭフレームワーク

経路（チャネル）


情報（データ）


デバイス／周辺機器ユーザアプリケーション

オフィスオートメーション

ビジネスプロセス

セキュリティ

可用性サービス

分散コンピューティング

システム／ネットワーク管理

国際化

ソフトウェアエンジニアリング

アクセス経路

サービス経路

コミュニケーションサービス

出力サービス

アプリケーションコアサービス

技術サポート

マルチメディアサービス

データベースアクセス

データ管理

データ交換

プラットフォーム通信サービス

OSサービス

物理環境サービス

本体装置

ネットワーク装置

ユーザサービス

モバイル装置

ストレージ

アプリケーションソフトウェアアプリケーションプラットフォーム外部環境共通基盤

ＴＲＭフレームワーク

経路（チャネル）


情報（データ）


デバイス／周辺機器ユーザアプリケーション

オフィスオートメーション

ビジネスプロセス

セキュリティ

可用性サービス

分散コンピューティング

システム／ネットワーク管理

国際化

ソフトウェアエンジニアリング

アクセス経路

サービス経路

コミュニケーションサービス

出力サービス

アプリケーションコアサービス

技術サポート

マルチメディアサービス

データベースアクセス

データ管理

データ交換

プラットフォーム通信サービス

OSサービス

物理環境サービス

本体装置

ネットワーク装置

ユーザサービス

モバイル装置

ストレージ

2.4.2. テクノロジアーキテクチャの設計

テクノロジアーキテクチャの設計は、明確になったアプリケーションアーキテクチャ、データアーキテクチ

ャから配置するノード（ハードウェア）および OS、データベース等を設計していき最終的にイベント量を考慮しながらネットワークトポロジを確定する。

3. アーキテクチャのモデリング言語

以下に、統一的な業務・システム管理手法として用いる各分類体系及びこれらを構成する標準記述様式につ

いて解説する。 3.1. ビジネスアーキテクチャ

ビジネスアーキテクチャは、業務の企画・立案、処理過程、情報及び情報の流れを示す体系であり、データ

体系、適用処理体系及び技術体系の上位の概念体系として位置する。政策・業務体系は、次に掲げる標準記述

様式により構成する。・機能情報関連図（DFD）・業務流れ図（WFA）・情報体系整理図（UML） 3.1.1. 機能情報関連図（ＤＦＤ）

システムを構成する機能を階層的に分解し、各階層の機能間でやり取りする主要情報の関係を模式的に示す

ため、機能情報関連図（ＤＦＤ）を作成する。機能情報関連図は、対象とする業務・システムの機能と情報の



流れを明確化するためのもので、業務・システムの各機能について情報の発生源と到達点、処理、保管とそれ

らの間を流れるデータを統一記述規則に基づき表現する。

省内各課室

省内各課室

機構定員設定

機構定員設定


厚生厚生

共済共済

要求項目



内示

併任先併任先


研修研修

結果

財務省財務省

内閣府内閣府

講師講師









人事院人事院

定数改定

機構定員

人事記

録

内々定者

内々定者

人事院人事院

合格者情報

職員職員

内定通知

希望・発令

共済組合

共済組合

個人票

人事記録

申請・承認

利用料回収指示利用料回収指

示

申請・承認


申請・承認



給与明細書

支払


申請・支払



受講者受講者

省内各課室

省内各課室


依頼受講記録



出勤状況

人事評価


績報告

職員職員

発令・処分

昇任・昇格

宮内庁

宮内庁指示

業界団体等

業界団体等

推薦・内示


調整

省内各課室

省内各課室

機構定員設定

機構定員設定


厚生厚生

共済共済

要求項目



内示

併任先併任先


研修研修

結果

財務省財務省

内閣府内閣府

講師講師









人事院人事院

定数改定

機構定員

人事記

録

内々定者

内々定者

人事院人事院

合格者情報

職員職員

内定通知

希望・発令

共済組合

共済組合

個人票

人事記録

申請・承認

利用料回収指示利用料回収指

示

申請・承認


申請・承認



給与明細書

支払


申請・支払



受講者受講者

省内各課室

省内各課室


依頼受講記録



出勤状況

人事評価


績報告

職員職員

発令・処分

昇任・昇格

宮内庁

宮内庁指示

業界団体等

業界団体等

推薦・内示


調整

3.1.2. 業務流れ図

業務処理過程に関係する機能及び情報に関し、機能を実施する人、組織、情報システム等の業務主体、順序

並びに当該業務主体及び順序においてやり取りされる情報を明確化するため、業務流れ図（WFA）を作成する。




＜記号説明＞

手作業


保管



帳票


＜記号説明＞

手作業


保管



帳票



形式チェック

申請書

証明書の確認

到着確認

シート発行

申請書の受信


電子証明書


不足チェック





申請者

様式ファイル


編集

参照

ヘルプ参照

様式ファイル

の選択

証明書の

指定


3.1.3. 情報体系整理図

業務処理で取り扱う対象となる情報について、各情報間の関連及び構造を明確化するため、情報体系整理図

を作成する。情報体系整理図は、業務・システムにおけるエンティティ（業務処理の対象となる物理的存在、

概念、事象に係る情報）間の関係を表現する。



業界

顧客

ユーザー

ハードベンダー

ソフトベンダー

ベンダー

協力会社（固定）

委託開発会社

パートナー社員派遣社員協力会社、メンバ

アサイン計画

教育計画

見積もり予算

実行予算スキル別要員

協業パートナー

要員計画プロジェクト

メンバロール

プロジェクトメンバ

タスク

予算

実績

スケジュール

実行資源

SIアクティビティ

SI営業折衝受注契約納入入金

実行計画要件定義設計開発テスト運用

SI提案

提案書

見積もり

見積書

SI請負

案件管理

請求

請求書イベント

情報

エンティティ

情報

3.2. データアーキテクチャ

データ体系は業務を遂行するための情報処理に必要となるデータ及びデータ間の関係を示す体系である。デ

ータ体系は、次に掲げる標準記述様式により構成する。・実体関連図（ER図）・データ定義表 3.2.1. 実体関連図

業務・システムで利用する情報システムにおける論理的なデータ構造を明らかにするため、実体関連図を作

成する。実体関連図では、エンティティ（業務処理の対象となる物理的存在、概念、事象に係る情報）及びリ

レーションシップ（関連）の概念を用いて、情報システムで用いる論理的なデータ構造を表現する。

部局管理

部門コード (FK)会計コード (FK)会計年度

超勤予算

部門コード (FK)会計年度

財源計算

支払年月日会計コード (FK)

支払義務者ｺｰﾄﾞ表

支払義務者コード

控除ｺｰﾄﾞ表

控除コード明細ｺｰﾄﾞ表

明細コード

宿舎コード表

宿舎コード

会計コード (FK)

財務局コード表


会計コード表

会計コード

部門コード表

部門コード

人事異動ｺｰﾄﾞ表


出納員ｺｰﾄﾞ表


特別調整手当定数１

有効期間FROM (FK)特別調整手当定数

有効期間FROM

寒冷地手当定数

有効期間FROM

寒冷地手当定数１

有効期間FROM (FK)

扶養手当定数

有効期間FROM扶養手当定数１

有効期間FROM (FK)期末勤勉定数

有効期間FROM

超勤手当定数

有効期間FROM

年末調整定数3


所得税定数3


通勤手当定数

有効期間FROM

年末調整定数

有効期間FROM年末調整定数１


年末調整定数2


通勤手当定数1


調整手当定数１

有効期間FROM (FK)調整手当定数

有効期間FROM

所得税定数

有効期間FROM

所得税定数１


所得税定数2


住居定数2


住居定数１

有効期間FROM (FK)住居定数

有効期間FROM

俸給表

給与種別

級号俸開始年月日改定年月日

ﾕーｻ゙権限

ｱｸｾｽ権ID (FK)職員番号 (FK)

局 (FK)部 (FK)課 (FK)室 (FK)班 (FK)係 (FK)特定官職 (FK)専門官職 (FK)担当 (FK)

ﾃｰﾌﾞﾙ編集権限

ｱｸｾｽ権ID (FK)

処理実行権限

ｱｸｾｽ権ID (FK)ｱｸｾｽ権

ｱｸｾｽ権ID

任命権者

局 (FK)部 (FK)課 (FK)

室 (FK)班 (FK)係 (FK)特定官職 (FK)専門官職 (FK)担当 (FK)

所属権限

局 (FK)部 (FK)課 (FK)室 (FK)

班 (FK)係 (FK)特定官職 (FK)専門官職 (FK)担当 (FK)

所属定数役職M

局 (FK)部 (FK)課 (FK)室 (FK)班 (FK)係 (FK)特定官職 (FK)専門官職 (FK)担当 (FK)職種

所属M

局部課室班係特定官職専門官職担当

分類ｺｰﾄﾞ

分類ｺｰﾄﾞ

親ｺｰﾄﾞ子ｺｰﾄﾞ孫ｺｰﾄﾞ

次期PC-LAN情報

職員番号 (FK)

住民票住所

職員番号 (FK)

勤怠情報

職員番号 (FK)

長期組合番号

職員番号 (FK)

資格

職員番号 (FK)資格SEQ

分類ｺｰﾄﾞ (FK)

メモ

職員番号 (FK)メモSEQ

級号俸

職員番号 (FK)級号俸SEQ

給与種別 (FK)分類ｺｰﾄﾞ (FK)

職歴

職員番号 (FK)職歴SEQ

留学

職員番号 (FK)留学SEQ


学歴

職員番号 (FK)学歴SEQ


住所

職員番号 (FK)住所SEQ


家族

職員番号 (FK)家族SEQ


入省採用退職

職員番号 (FK)入省採用退職SEQ


職員基本

職員番号

入省採用退職SEQ家族SEQ住所SEQ学歴SEQ留学SEQ職歴SEQ級号俸SEQ異動SEQ資格SEQ表彰SEQ公災SEQ試験SEQ研修SEQ改姓SEQ退職後SEQメモSEQ語学試験SEQ

表彰

職員番号 (FK)公災SEQ


試験結果

職員番号 (FK)試験SEQ


研修結果

職員番号 (FK)語学試験SEQ


婚姻

職員番号 (FK)婚姻SEQ


改姓

職員番号 (FK)改姓SEQ


ｲﾒｰｼﾞ

職員番号 (FK)

退職者

職員番号 (FK)退職後SEQ

所属職種

職員番号 (FK)異動SEQ

部 (FK)課 (FK)室 (FK)班 (FK)係 (FK)特定官職 (FK)専門官職 (FK)担当 (FK)局 (FK)職種 (FK)分類ｺｰﾄﾞ (FK)会計SEQ

会計

職員番号 (FK)異動SEQ (FK)会計SEQ

昇給件数

職員番号 (FK)

語学試験結果

語学試験SEQ職員番号 (FK)


公災

公災SEQ職員番号 (FK)


調査書名

調査書番号

希望調査項目

職員番号 (FK)調査書番号 (FK)行番号 (FK)

回答年月日

調査書番号 (FK)職員番号 (FK)

希望調査書

職員番号 (FK)調査書番号 (FK)行番号

個人票名

個人票番号

個人票項目

個人票番号 (FK)

行番号

回答年月日

個人票番号 (FK)職員番号（部下） (FK)

職員番号（上司）

個人票

職員番号（部下） (FK)行番号個人票番号 (FK)

個人票入力者

職員番号（上司）

個人票入力対象

職員番号（上司） (FK)職員番号（部下） (FK)

異動候補者

年度局内局間区分局職員番号 (FK)

辞令

年度局発令日枝番職員番号 (FK)異動SEQ (FK)辞令SEQ

昇格昇給級号俸

職員番号 (FK)昇格昇給級号俸SEQ昇格昇給詳細SEQ (FK)

昇格昇給詳細

昇格昇給詳細SEQ職員番号 (FK)

昇格昇給発令SEQ昇格昇給所属SEQ昇格昇給会計SEQ昇格昇給級号俸SEQ

異動起案

年度 (FK)局内局間区分 (FK)局 (FK)ライン番号ライン内番号職員番号 (FK)

昇格昇給基本

発令日給与種別職員番号 (FK)

昇格昇給詳細SEQ (FK)

候補者情報

職員番号 (FK)昇格昇給詳細SEQ (FK)

昇格昇給会計

職員番号 (FK)昇格昇給会計SEQ昇格昇給詳細SEQ (FK)

流れ図

年度 (FK)局内局間区分 (FK)局 (FK)ライン番号ライン内番号職員番号 (FK)

昇格昇給発令

職員番号 (FK)昇格昇給会計SEQ昇格昇給詳細SEQ (FK)

昇格昇給所属

職員番号 (FK)昇格昇給所属SEQ昇格昇給詳細SEQ (FK)

身分証明書ﾃﾞｰﾀ

長期組合員番号

給与基本

部門コード (FK)職員コード (FK)会計コード (FK)

人事職員

職員コード (FK)

月例変動

支払年月日部門コード (FK)職員コード (FK)会計コード (FK)

給与実績

支払年月日部門コード (FK)状態区分職員コード (FK)会計コード (FK)

給与計算

部門コード (FK)支給区分支払年月日状態区分職員コード (FK)会計コード (FK)

＊＊内訳

部門コード (FK)支給区分 (FK)支払年月日 (FK)状態区分 (FK)職員コード (FK)＊＊内訳SEQ会計コード (FK)

差額追給対象者

会計コード (FK)職員コード (FK)

差額追給仮

会計コード (FK)支払年月日状態区分職員コード (FK)

＊＊履歴

＊＊履歴SEQ職員コード (FK)

扶養手当履歴

扶養手当履歴SEQ職員コード (FK)

職員家族履歴

家族履歴SEQ扶養手当履歴SEQ (FK)職員コード (FK)

組合員

組合員SEQ職員コード (FK)

職員（基本・履歴）職員（基本・履歴）//人事記録人事記録ｾｷｭﾘﾃｨｾｷｭﾘﾃｨ

昇格・昇給昇格・昇給

定数管理定数管理

定数定数管理管理

人事異動人事異動

ｱﾝｹｰﾄｱﾝｹｰﾄPCPC--LANLAN

共済・給与共済・給与IFIF（ｷｰ）（ｷｰ）

共済共済IFIF（ｷｰ）（ｷｰ）

給与基本給与基本

給与履歴給与履歴

給与定数管理給与定数管理

業務ｺｰﾄﾞ管理業務ｺｰﾄﾞ管理

職員（基本・履歴）職員（基本・履歴）//人事記録人事記録ｾｷｭﾘﾃｨｾｷｭﾘﾃｨ

昇格・昇給昇格・昇給

定数管理定数管理

定数定数管理管理

人事異動人事異動

ｱﾝｹｰﾄｱﾝｹｰﾄPCPC--LANLAN

共済・給与共済・給与IFIF（ｷｰ）（ｷｰ）

共済共済IFIF（ｷｰ）（ｷｰ）

給与基本給与基本

給与履歴給与履歴

給与定数管理給与定数管理

業務ｺｰﾄﾞ管理業務ｺｰﾄﾞ管理



3.2.2. データ定義表

業務・システムで利用する情報システムにおける物理的なデータ構造を明らかにするため、データ定義表を

作成する。

3.3. アプリケーションアーキテクチャ

3.3.1. システム関連図

業務・システムの処理過程で利用される情報システム間でやり取りされる情報の種類及び方向を明確化する

ため、情報システム関連図を作成する。



3.3.2. パッケージ図

3.3.３. コンポーネント図

3.3.４. イベント流れ図



3.4. テクノロジアーキテクチャ

技術体系は、業務を遂行するための情報処理に関し、必要となる技術基盤（ハードウェア、ソフトウェア等）

及びセキュリティ基盤を示す体系である。技術体系は、次に掲げる標準記述様式により構成する。・ネットワーク構成図・ソフトウェア構成図・ハードウェア構成図 3.4.1. ネットワーク構成図

情報システムを構成するサーバ、クライアント等の機器の物理的又は論理的な接続関係を明確化するため、

ネットワーク構成図を作成する。



3.4.2. ソフトウェア構成図

情報システムを構成するサーバ、クライアント等の機器に実装するソフトウェアの構成を明確化するため、

ソフトウェア構成図を作成する。

3.4.3. ハードウェア構成図

情報システムを構成するサーバ、クライアント等の機器の CPU、メモリ、ハードディスク等の機能構成を明確化するため、ハードウェア構成図を作成する。


Ⅱ-ⅰ ２ｅラーニング編 1

Ⅱｰⅰ ２ＩＴアーキテクチャ策定ガイドラインｅラーニング編

// CONTENTS //

1. ITアーキテクチャの構成.................................................................................................................................. 3

1.1. 業務機能とは.............................................................................................................................................. 3 1.2. システム基盤とは....................................................................................................................................... 4

２. ITアーキテクチャ構築のプロセス.................................................................................................................. 5

2.1. 戦略的情報化企画プロセス........................................................................................................................ 6 2.1.1. 課題整理・分析................................................................................................................................... 6 2.1.2. ソリューション設計プロセス............................................................................................................. 7 2.2. コンポーネント設計プロセス.................................................................................................................... 8

３. 業務機能の企画と設計 ..................................................................................................................................... 9

3.1. 経営課題と情報化戦略............................................................................................................................... 9 3.1.1 業務モデルの作成.............................................................................................................................. 11 3.2. 情報システム構想の立案 ......................................................................................................................... 13 3.2.1. 情報システム構想の立案とは........................................................................................................... 13 3.2.2. データモデルの作成.......................................................................................................................... 14 3.2.3. アプリケーションモデルの作成....................................................................................................... 15 3.2.4. 基本処理方式について方針検討....................................................................................................... 17 3.2.5. 阻害要因やリスク分析と構想まとめ ............................................................................................... 19 3.3. 業務機能の要件定義................................................................................................................................. 20 3.3.1. 対象業務の定義................................................................................................................................. 20 3.3.2. 機能要件の定義................................................................................................................................. 21 3.4. 情報システムの機能の明確化.................................................................................................................. 22 3.4.1. データアーキテクチャの明確化....................................................................................................... 22 3.4.2. アプリケーションアーキテクチャの明確化 .................................................................................... 23 3.4.3. 処理方式の決定とハードウェアへの割り当て ................................................................................ 26 3.4.4. 要件実現度の評価 ............................................................................................................................. 27 3.5. システム開発基本方針の策定.................................................................................................................. 28 3.6. コンポーネント設計................................................................................................................................. 28 3.6.1. コンポーネントとは.......................................................................................................................... 28 3.6.2. コンポーネントベース開発とは....................................................................................................... 29 3.6.3. コンポーネント開発工程.................................................................................................................. 30

４．システム基盤の企画と設計（非機能的側面）............................................................................................... 32

4.1. システム基盤構想の立案 ......................................................................................................................... 32



4.1.1. システム基盤課題の分析.................................................................................................................. 32 4.1.2. システム基盤の方向性検討 .............................................................................................................. 33 4.1.3. システム基盤のアーキテクチャ検討 ............................................................................................... 34 4.1.4. システム基盤構想書の作成 .............................................................................................................. 35 4.2. システムアーキテクチャの要件定義....................................................................................................... 36 4.2.1. 要件定義の目的と位置づけ .............................................................................................................. 36 4.2.2. 現状システム基盤の把握.................................................................................................................. 37 4.2.3. 品質要件 ............................................................................................................................................ 38 4.2.4. セキュリティ要件 ............................................................................................................................. 39 4.2.5. 運用要件 ............................................................................................................................................ 40 4.2.6. サイジング要件................................................................................................................................. 41 4.3. システム基盤の明確化............................................................................................................................. 42 4.3.1. システム基盤の明確化とは .............................................................................................................. 42 4.3.2. プロセスモデルの作成...................................................................................................................... 43 4.3.3. データモデルの作成.......................................................................................................................... 44 4.3.4. パフォーマンスモデルの作成........................................................................................................... 45 4.3.5. アベイラビリティモデルの作成....................................................................................................... 46 4.3.6. 運用・監視基盤モデルの作成........................................................................................................... 48 4.4. システム基盤設計基本方針の設定 .......................................................................................................... 49 4.4.1. システム基盤設計基本方針の設定とは............................................................................................ 49 4.4.2. サービスレベルの設定...................................................................................................................... 50 4.4.3. システム基盤計画の作成.................................................................................................................. 51



1. ITアーキテクチャの構成

機能的側面

業務ロジック

OS・ハードウェア

ミドルウェア

制御ロジック


業務ロジック

OS・ハードウェア

ミドルウェア

制御ロジック

アプリケーション＝

業務機能

非機能的側面

＝

システム基盤

システム基盤

業務機能（業務、アプリケーション、データ）

業務基盤

マルチベンダ化、多様な製品の組み合わせ、大規模、短納期開発などの環境下で、システム化要件を満た

すアーキテクチャを設計するための方策として、アーキテクチャやコンポーネントの階層化がある。システ

ム構造を役割や機能ごとに階層化して、各層ごとに独立した形で機能を提供するシステム構造。各層ごとに

設計や実装を行えるため、構築が容易になる。また、ある階層に仕様変更が発生した場合でも、他の層に影

響を与えず、その層のみ変更対応を行えばよいため、仕様変更への対応も容易になる。アーキテクチャの階

層化のモデルの１つとして、機能的側面である業務機能（業務、アプリケーション、データ）と非機能的側

面であるシステム基盤の 2つのレイヤに階層化できる。アーキテクチャを階層ごとに役割や機能を明確化し

て標準化、モデル化しアーキテクチャの複雑性を排除して、豊富な実績を持つ標準化した階層に合わせてシ

ステム構造を設計することにより、信頼性、可用性、性能や拡張性などが保証され、短期間で整合性の高い

システムを構築することができる。

1.1. 業務機能とは

WWW AP/DBアプリケーションアーキテクチャ

データアーキテクチャ

業務

実現

受注注文登録注文登録

受注DB受注DB 在庫DB在庫DB

顧客受注

受注明細

業務ロジック

運用制御基盤

業務フレームワーク

業務基盤



ITアーキテクチャの業務機能（機能的側面）は、業務、アプリケーションアーキテクチャ、データアーキ

テクチャから構成される。

・企業の経営課題解決のために、業務の設計（業務の定義、業務フロー、業務運用）など業務全体を明確に

する。

・アプリケーションアーキテクチャとして、業務実現のために必要なシステム形態と業務をコンピュータ化

するための業務アプリケーション処理方式を明確にする。

・データアーキテクチャとして、業務で利用するデータの内容、データ間の関連、業務とデータの関連を明

確にする。

ソフトウェアアーキテクチャを実現するときに、業務部分に特化したロジックである業務ロジック部分と、

データベース制御などの共通処理を行う制御ロジックの業務基盤部分に分けると良いアーキテクチャ構造

になる。業務基盤には、すでに実績のあるモデル化された制御ロジックのソフトウェア部品を採用すること

により、開発者は、インフラの制御部分を作成する必要がないため、業務ロジックの開発にのみ専念するこ

とができる。業務基盤としてバッチ処理などの業務の用途に応じた処理をモデル化した業務フレームワーク

や、業務システムの安定稼動を支援するための処理をモデル化した運用制御基盤を準備する。業務ロジッ

クや業務基盤のようにコンポーネントとして構造化することにより、アプリケーション開発のスピードアッ

プと、信頼性の高い、再利用可能なアプリケーション開発を行うことができる。

1.2. システム基盤とは

可用性保守性性能

拡張性セキュリティ

サービスレベル

プロセスモデルデータモデルパフォーマンスモデルアベイラビリティモデル運用監視基盤モデル

システム基盤とは、業務アプリケーション実行のためのアーキテクチャであり、ミドルウェア、プラット

フォーム、ハードウェア構成のことをいう。システム基盤は業務実現のためのアーキテクチャであり、かつ、

システムに求められる品質要件（性能、可用性、保守性、拡張性、セキュリティなど）実現のためのアーキ

テクチャでもある。システム基盤の設計・構築は、システムが実現すべき性能、信頼性などの指標であるサ

ービスレベルを実現するように行うが、それに先立って、品質要件を十分に確保できる ITアーキテクチャ



を設計しておく必要がある。品質要件に合わせてシステム基盤として、以下の５つを明確にする。

・プロセスモデルとして、業務アプリケーション（業務、業務基盤）のノード配置を明確にする。

・データモデルとして、プロセス間のデータの流れとインタフェースを明確にする。

・パフォーマンスモデルとして、性能要件を確保する方式を明確にする。

・アベイラビリティモデルとして、可用性を確保する方式を明確にする。

・運用・監視基盤モデルとして、運用・監視機能要件を満たす方式を明確にする。

システム基盤も、多種多様な製品から機能単位に使用頻度の高いものを組み合わせて標準化、モデル化す

る。WebサーバやDBサーバなど、それらの組み合わせや配置をモデル化した実績のあるシステム構成を適

用することで、短期間で信頼性の高いシステムを構築できる。

２. ITアーキテクチャ構築のプロセス

戦略的情報化企画

ソリューション設計

コンポーネント設計

業務機能

システム基盤

プロジェクトマネジメント

経営課題の把握

業務の分析

情報化課題の分析と

情報化方針の策定

情報システム構想の立案

データアーキテクチャの明確化

アプリケーションアーキテクチャの明確化

システム基盤課題の分析

システム基盤方針の策定

システム基盤構想の立案

システム基盤の要件定義

プロセスモデルの作成

パフォーマンスモデルの作成

アベイラビリティモデルの作成

運用監視基盤モデルの作成

対象業務の定義

機能要件の定義

外部設計

内部設計

データモデルの作成

各種モデル（プロセス・データ・パフォーマンス・アベイラビリティ・運用監視基盤）の実装方法の決定

課題整理/分析

ITアーキテクチャ構築のためのプロセスには、「戦略的情報化企画」「ソリューション設計」「コンポー

ネント設計」の３つがある。３つのプロセスを通じて、業務機能（機能的側面）とシステム基盤の両面から

システム要件を満たす情報システム全体の処理方式を設計する。

（１）戦略的情報化企画

企業の中長期的な経営目標・課題や経営基本方針について情報収集し、「担当組織」、「業務の流れ」、

「主要なデータ」の３者の関わりを本来あるべき理想的な業務モデルとして定義する。その後、現状の情

報化課題や業務モデルと理想的な業務モデルを突き合わせて、情報システムが解決すべき経営課題を明確



にする。システム基盤側では、業務要件を基にシステム基盤で解決し実現しなければならない課題を明確

にし、現状のシステム基盤アーキテクチャを把握した上で、新システム基盤に必要となる品質要件を定義

する。

（２）ソリューション設計

業務機能（機能的側面）では、業務上必要なデータを体系化し、データベースの骨格を明確にする。また、

戦略的情報化企画プロセスにおいて明確にした業務機能のうち、どの機能をシステム化するかを検討し、

機能とデータの全体像を整理する。システム基盤側では、戦略的情報化企画プロセスにおいて明確にした

品質要件および業務要件を基にシステム基盤を具体的にモデル化する。

（３）コンポーネント設計

業務機能およびシステム基盤を実装するために必要となる具体的なアプリケーションコンポーネント、シ

ステムコンポーネントをそれぞれ設計する。

2.1. 戦略的情報化企画プロセス

2.1.1. 課題整理・分析

業務機能

システム基盤

経営課題の把握

業務の分析

情報化課題の分析と

情報化方針の策定

情報システム構想の立案

対象業務の定義

機能要件の定義

システム基盤課題の分析

システム基盤方針の策定

システム基盤構想の立案

システム基盤の要件定義

業務機能階層図

現状業務モデル

新業務モデル

情報化課題

要件定義書（システム基盤）

現状システム基盤モデル

システム基盤課題

新システム概要イメージ

業務処理概要図

システム化要件一覧

機能情報関連図（DFD)

戦略的情報化企画は、ITアーキテクチャを構築するための最初の重要なプロセス。業務機能では、新業務

モデル及び業務機能に求められる要件をまとめ、システム方式（データやアプリケーションの方式）の中長

期に渡る構想を策定します。また、システム基盤側では、業務機能（機能的側面）で明らかになった業務要

件をもとにシステム基盤に必要となる要件を洗い出し、要件を実現するための新システム概要イメージを立

案する。業務機能では、企業の経営課題を解決するために必要とされる業務をモデル化することが重要。シ

ステム基盤側では、業務を実行でき、情報システムに求められる品質要件を満たすためのシステム基盤構想

を立案する。



2.1.2. ソリューション設計プロセス

業務機能

システム基盤

実体関連ダイアグラム

(ERD)データモデル定義

情報分析図(CRUD図)

実体関連ダイアグラム

(ERD)データモデル定義

情報分析図(CRUD図)

データアーキテクチャの明確化

アプリケーションアーキテクチャの明確化

プロセスモデルの作成

パフォーマンスモデルの作成

アベイラビリティモデルの作成

運用監視基盤モデルの作成

データモデルの作成プロセスモデルデータモデルパフォーマンスモデル

プロセスモデルデータモデルパフォーマンスモデル

アベイラビリティモデル

運用監視基盤モデル

サブシステム階層図

目的・サブシステム関連表

システム選定方針検討表



システム選定方針検討表

ソリューション設計は、ITアーキテクチャを決定するための最終プロセス。この後のコンポーネント設計

では、決定した ITアーキテクチャを基に具体的にアプリケーションコンポーネントとシステムコンポーネ

ントの設計を行っていく。業務機能（機能的側面）では戦略的情報化企画で作成した新業務モデル及びシス

テム化要件を基にして、システム化対象業務と開発するシステムを特定し、もう一段階詳細な業務機能とそ

のために適切なデータ及びアプリケーションのアーキテクチャを設計し、明確にする。既に機能情報関連図

(DFD:Data Flow Diagram)として論理化されている機能と情報の関わりを整理し、データの関連を実体関連

図(ERD:Entity Relation Diagram)としてまとめる。さらに情報分析図(CRUD図)を作成すると、データの流

れと機能配置を最適化した業務・システムを可視的に設計しやすくなる。また、アプリケーションアーキテ

クチャとして、サブシステムの階層化およびアプリケーションの処理方式を決定する。システム基盤側では、

システム基盤構想を基にシステム基盤モデルとして、プロセスモデル、データモデル、パフォーマンスモデ

ル、アベイラビリティモデル、運用監視基盤モデルを作成して、アーキテクチャを具体化する。



2.2. コンポーネント設計プロセス

業務機能

システム基盤

外部設計

内部設計

プロセスモデルの実装方法

パフォーマンスモデルの実装方法

アベイラビリティモデルの実装方法

運用監視基盤モデルの実装方法

データモデルの実装方法

Windows

アプリケーションサーバA

フレームワークＢ

サービスコンポーネントC

Windows



サービスコンポーネントC

UNIX



サービスコンポーネントD

サービスコンポーネントE

コンポーネント



コンポーネント設計は、決定した ITアーキテクチャを基にアプリケーションコンポーネント、システム

コンポーネントを具体化するプロセス。業務機能（機能的側面）では、決定された処理方式を基にアプリケ

ーションコンポーネントを設計する。システム基盤側ではプロセスモデル、データモデル、パフォーマンス

モデル、アベイラビリティモデル、運用監視基盤モデルから実際のハードウェア、ソフトウェアへ実装方法

を定義する。ITアーキテクチャを構成するコンポーネントは再利用することを前提として設計する。特にア

プリケーションコンポーネントに関しては、その一部分が部品として他システムにおいて再利用し易くする

ことを考慮して、ITアーキテクチャを設計することが求められる。



３. 業務機能の企画と設計

3.1. 経営課題と情報化戦略

経営課題とは、現状とあるべき姿のギャップ

このギャップを埋めるために、戦略案の検討、新規ビジネス

モデルの検討および情報戦略案の検討が統合的に行われま

す。

経営課題とは、現状とあるべき姿のギャップ

このギャップを埋めるために、戦略案の検討、新規ビジネス

モデルの検討および情報戦略案の検討が統合的に行われま

す。

ミッション・経営方針ミッション・経営方針

経営戦略の策定経営戦略の策定

情報化戦略案情報化戦略案

経営課題の抽出

経営課題の抽出

新しいビジネスモデル

新しいビジネスモデル

情報戦略とは、経営目標を実現するために、情報をどのように活用するか、また、そのために情報化進めるべきかを定めた基本的な戦略です。

情報化戦略策定で検討すべき事項

(1) 経営活動や業務機能をより効率的にするための仕組み

(2) 情報システムを支えるプラットフォーム

(3) 情報リテラシーなどの情報化に対応した人材育成

(4) 投資対効果評価

情報戦略とは、経営目標を実現するために、情報をどのように活用するか、また、そのために情報化進めるべきかを定めた基本的な戦略です。

情報化戦略策定で検討すべき事項

(1) 経営活動や業務機能をより効率的にするための仕組み

(2) 情報システムを支えるプラットフォーム

(3) 情報リテラシーなどの情報化に対応した人材育成

(4) 投資対効果評価経営戦略策定作業と情報化戦略の関係

外部環境の変化

外部環境の変化

自社の強みや弱み

自社の強みや弱み

自社の保有資源

自社の保有資源

経営目標の設定

経営目標の設定

全社戦略案事業戦略案機能戦略案

全社戦略案事業戦略案機能戦略案

経営戦略とは｢経営活動の長期的な基本方針｣であり、その内容は今後の事業領域の定義、経営目標、経営資源（すなわち、ヒト、モノ、カネ、情報）の計画

経営戦略とは｢経営活動の長期的な基本方針｣であり、その内容は今後の事業領域の定義、経営目標、経営資源（すなわち、ヒト、モノ、カネ、情報）の計画

（１）経営戦略

経営戦略とは、｢企業の基本的な長期目標や目的を定め、行動すべき方向を選択し、目標遂行に必要な

資源計画を定めたもの｣とChandler, A.D.jr.は定義している。一般的には、｢経営活動の長期的な基本方

針｣であり、その内容は今後の事業領域の定義や経営目標、経営資源（すなわち、ヒト、モノ、カネ、

情報）の計画などである。経営戦略の策定には、

(a)事業領域の明確化と経営目標の設定

(b)組織を取り巻く外部環境の変化の予測、組織の保有する資源の分析、自社の強みや弱みの分析

(c)戦略の代替案作成と評価

(d)選択した戦略案への経営資源への配分

といった作業を繰り返す。

（２）情報化戦略

情報化戦略は、

・経営活動で発生する情報そのもの

・コンピュータとネットワークなどの情報基盤

・経営活動における情報の活用方法やその活用技術

の長期的な計画。



（３）情報化戦略策定で検討すべき事項

情報化戦略で検討すべき事項には次のようなものがある。

・経営活動や業務機能をより効率的にするための仕組み

・情報システムを支えるプラットフォームの整備

・情報リテラシーなどの情報化に対応した人材育成

・投資対効果評価

（４）情報化戦略の立案チームとITアーキテクト

経営戦略や情報化戦略はトップダウンで策定することが望ましく、一般的にはCIO（Chief Information

Officer）、経営企画部門、事業部部門代表者およびコンサルタントなどによりプロジェクトチームを結

成し策定する。ITアーキテクトは情報化戦略の技術的な実現可能性や技術的な全体最適性および現行シ

ステムとの整合性などを踏まえた情報化戦略が立案されるようにチーム（あるいはコンサルタント）の

支援する活動を行う。なお、今日では情報化戦略は経営戦略の１つとも位置づけられるため、情報化戦

略策定作業が経営戦略策定作業に含まれるとして説明されることもある。

（５）情報化戦略の策定作業概要

情報化戦略の立案のための作業情報化戦略の立案のための作業

基本戦略の策定基本戦略の策定

技術動向の調査分析技術動向の調査分析

業務環境の調査・分析業務環境の調査・分析

現行業務の調査・分析現行業務の調査・分析

情報システムの調査・分析情報システムの調査・分析

業務の新全体像の作成業務の新全体像の作成

対象の選定と投資目標の策定対象の選定と投資目標の策定

情報化戦略の作成と承認情報化戦略の作成と承認

情報化戦略推進体制の確立情報化戦略推進体制の確立

SLCP－JCF98で定義されている作業

INPUT OUTPUT

経営目標業務の中長期計画業務課題

経営目標業務の中長期計画業務課題

情報化戦略・経営活動で活用すべき情報の定義と活用計画・情報システムの開発計画・コンピュータやネットワークなどの情報基盤の整備計画・情報技術を活用するための人的面の能力向上計画

情報化戦略・経営活動で活用すべき情報の定義と活用計画・情報システムの開発計画・コンピュータやネットワークなどの情報基盤の整備計画・情報技術を活用するための人的面の能力向上計画

・情報化戦略に求められる原則

情報化戦略には、

(1)経営戦略との整合性

(2)実現範囲の適切性

(3)実現期間の適切性

(4)費用対効果の適切性

(5)実現性

(6)成果測定の基準と仕掛けの組込み

・情報化戦略に求められる原則

情報化戦略には、

(1)経営戦略との整合性

(2)実現範囲の適切性

(3)実現期間の適切性

(4)費用対効果の適切性

(5)実現性

(6)成果測定の基準と仕掛けの組込み

（６）経営課題の把握

経営課題の把握には、経営層や事業部門に対してのインタビューや社内公式文書、業界雑誌紙の調査、

経営戦略、情報化戦略、業務実行部門の部門別中長期目標や課題などの情報を収集する。収集した情報

を参考にして経営目標を達成するためにはどのような課題があるかを具体的に詳細化する。この作業は

複数のプロジェクトメンバーで、ブレーンストーミング形式で行うのが良い。複数箇所で同じ課題が出

てくることもある。課題に対して情報システムで解決できるかを検討し、情報システム課題とします。

これらを目標体系図としてまとめる。



3.1.1 業務モデルの作成

業務モデルとは、｢担当組織｣、｢業務の流れ（業務プロセスとも呼びます）｣、｢主要な情報｣を定義したもの

と、それらの関わりを図や表で表したもの。「現行業務の調査・分析｣や｢業務の新全体像の作成｣で、業務

内容を把握したり、新業務を表すために業務モデルを使用する。これらのモデルは ITアーキテクトが中心

となって、全社アーキテクチャとして維持管理していき、情報化戦略の見直しや次工程の入力情報とする。

（１）業務分野と主要情報の関連

業務と主要情報の関連をDFD(Data Flow Diagram)で表している。この段階では業務は最上位の業務で

ある業務分野の粒度で取り扱う。このモデルにより全社の業務の関連と主要な情報を把握することがで

きる。

業務分野と主要情報の関連業務分野と主要情報の関連

業務実績

人事目標

得意先

仕入先

支払い

商品・納品書・請求書

入金実績

販売実績

販売予算

販売目標

生産目標

販売計画・在庫実績

工場出荷計画

製品在庫・仕掛在庫

資材所

要量

発注

請求書

支払い支払い依頼

購買予算

開発目標

設計情報

歩留まり率生産実績

棚卸在庫

業務分野

情報

外部実体

経営計画

設計生産販売

人事・組織管理

購買

財務


業務実績

人事目標

得意先

仕入先

支払い


入金実績

販売実績

販売予算

販売目標

生産目標


工場出荷計画


資材所

要量

発注

請求書


購買予算

開発目標

設計情報


棚卸在庫

業務分野

情報

外部実体

経営計画

設計生産販売


購買

財務

（２）業務機能定義表

業務を機能単位に第 1レベルから第 3レベルの粒度程度まで詳細化し、各々の概要説明を記述した表で

ある。新しい業務は工程が進み業務内容が明らかになった段階で詳細化する。

業務機能(第三ﾚﾍﾞﾙ) 概要見積り顧客の依頼を検討し納期、

予算に合う見積りを作成する

受注顧客からの注文を受け、在

庫を検索し、引当可能の場合、受注伝票を作成して受注を登録する

注残管理受注で引当できなかった注

文を営業担当者が営業メモを残し、受注ができる状況になるまで管理する

販売市場情報収集季節変動分析顧客動向予測景気予測需要予測シュミュレーション報告書作成商品企画プロモーション企画流通企画市場開発ＩＲ

需要予測

マーケティング

市場動向情報収集製品別販売計画重点得意先別販売計画担当別販売計画販売計画報告見積り受注処理注残管理

受注管理

販売計画

業務分野業務業務機能販売市場情報収集

季節変動分析顧客動向予測景気予測需要予測シュミュレーション報告書作成商品企画プロモーション企画流通企画市場開発ＩＲ

需要予測



受注管理

販売計画

業務分野業務業務機能

業務機能定義表



（３）業務・システム体系一覧作成

主要な業務とシステム化状況を整理する。現状では業務ごとにどのようなシステムを利用しているか、

全社的な視野で課題となることは何かを検討する材料とする。新しい業務については｢今後、考えられ

るシステムの導入予定｣を書き込んでいく。一覧表を作成することにより既に他事業所で稼動している

システムがあれば、システムの再利用を検討し、重複投資を防ぐことができる。また、現行業務の調査

分析と並行して、現行の情報システムの調査を行う。インタビューやアンケートを通して、利用部門の

評価やコンピュータ化率、および利用部門が考える今後の課題などをまとめる。下図のように調査結果

を数値化するとわかりやすい。

業務・システム体系一覧業務・システム体系一覧

業務分野業務（第2レベル）

本社

東北支社

大阪支社

埼玉工場

広島工場

香港販社

ロンドン支社

北米販社

中国生産会社

マレ

ーシア工

場

販売需要予測 ● ● ●販売計画 ○ ○ ○ ○ ○ ○ ○販売実績管理 ○ ○ ○ ○ ○ △ △受注管理 ○ ○ ○ ● ● ○ ○ ○ ○ ○商品管理

財務仕訳処理 ○ ○ △ ○決算処理 ○ △ △ ○

生産生産計画 ○ ○ △ ○資材所要量計算 ○ ○ △ ○工程管理 ○ ○ △ ○製造管理 ○ ○ △ ○品質管理 ○ ○ △ ○設備管理 ○ ○ △ ○原価管理 ○ ○ △ ○

○　社内標準コンピュータシステム△　独自開発コンピュータシステム無印　未コンピュータシステム化●　コンピュータシステム導入不要

現状の情報システムの評価情報システム名利用部門の満足度コンピュータ化率主たる今後の課題

販売計画システム 80% 70% 生産計画との連動受注管理システム 60% 100% EDI化、価格差別化の仕組みを追加生産管理システム 80% 75%情報共有システム 40% 50% 情報入力の効率化

現状の情報システムの評価

（４）新しい業務モデル作成




業務実績

人事目標

得意先

仕入先

支払い


入金実績

販売実績

販売予算

販売目標

生産目標


工場出荷計画


資材所

要量

発注

請求書


購買予算

開発目標

設計情報


棚卸在庫

業務分野

情報

外部実体

経営計画

設計生産販売


購買

財務


業務実績

人事目標

得意先

仕入先

支払い


入金実績

販売実績

販売予算

販売目標

生産目標


工場出荷計画


資材所

要量

発注

請求書


購買予算

開発目標

設計情報


棚卸在庫

業務分野

情報

外部実体

経営計画

設計生産販売


購買

財務

業務分野業務（第2レベル）

本社

東北支社

大阪支社

埼玉工場

広島工場

香港販社

ロンドン支社

北米販社

中国生産会社

マレー

シア工

場

販売需要予測 ● ● ●販売計画 ○ ○ ○ ○ ○ ○ ○販売実績管理 ○ ○ ○ ○ ○ △ △受注管理 ○ ○ ○ ● ● ○ ○ ○ ○ ○商品管理

財務仕訳処理 ○ ○ △ ○決算処理 ○ △ △ ○

生産生産計画 ○ ○ △ ○資材所要量計算 ○ ○ △ ○工程管理 ○ ○ △ ○製造管理 ○ ○ △ ○品質管理 ○ ○ △ ○設備管理 ○ ○ △ ○原価管理 ○ ○ △ ○

○　社内標準コンピュータシステム△　独自開発コンピュータシステム無印　未コンピュータシステム化●　コンピュータシステム導入不要

販売市場情報収集季節変動分析顧客動向予測景気予測需要予測シュミュレーション報告書作成商品企画プロモーション企画流通企画市場開発ＩＲ

需要予測



受注管理

販売計画

業務分野業務業務機能販売市場情報収集

季節変動分析顧客動向予測景気予測需要予測シュミュレーション報告書作成商品企画プロモーション企画流通企画市場開発ＩＲ

需要予測



受注管理

販売計画

業務分野業務業務機能

経営戦略を実現するための組織設立や組織改変、業務の流れや内容の変更を検討し、業務モデルを作成する。

3.2. 情報システム構想の立案

3.2.1. 情報システム構想の立案とは

全社最適モデル

情報システム構想の立案情報システム構想の立案

業務機能面

システム基盤面

経営戦略・情報戦略

現状業務の課題や問題点

業種・業務参照モデル

技術動向・標準化動向

ベンチマーキング

既存の情報システムからの制約

情報システム構想のINPUTとOUTPUT新しい情報システム構想

以前の情報システム構想

業務機能


業務部門の中長期業務計画

ＩＮＰＵＴＯＵＴＰＵＴ

業務機能


■情報システム構想とは

情報システム構想とは情報化戦略を受けて中長期にわたりどのような情報システムをどのような優先順

位で開発するか、どのようなシステム基盤を整備するか、どのような推進体制とするかなどについて具体

的に決めたもの。同時に開発対象となるシステムについて、全社的な観点からみた最適なものとなるよう

に大枠を設計する。この情報システム構想立案活動は業務組織やプロセスの改革がともなうことが多いた



め、経営企画室などの企画部門、業務部門代表者、コンサルタントなどが参加したプロジェクトチームで

立案する。ＩＴアーキテクトは、情報システム構想が技術的な観点から実現可能なものになるように、そ

して中長期にわたり全社最適なアーキテクチャの構築のためにチームに参画する。情報システム構想の立

案は、ITアーキテクトの中心的な業務である。

■全社最適の視点の重要性

エンドユーザコンピューティングやクライアントサーバ型システムの普及により、システム機能の重複や

データの重複、あるいは不整合が発生している。そのため、保守や運用も複雑化している。全社的な観点

で情報システム構想を描くことによって、情報システムの新規開発や保守、運用が明確になるだけでなく、

経営層にとってはより重複投資や無駄な投資を防ぐことが期待できる。

■情報システム構想立案作業

情報システム構想立案作業では経営戦略、情報化戦略、業務部門の中長期計画、同業他社の成功事例、ベ

ンチマーキング結果などを入力情報として、中長期にのような情報システムが必要であるか検討し、その

具体的な開発プランを立案する。また技術動向や標準化動向は影響が大きいので継続的な情報収集が必要。

例えばＥＡＩツール、ビジネスオブジェクトやWebサービスなどはシステム開発の生産性向上や経営体

の枠を超えた情報共有化のための技術として実現性が高くなってきた。このような技術はアーキテクチャ

に影響を与えるためとても重要。

3.2.2. データモデルの作成

エンティティの識別

• エンティティの関連付け

ERD

エンティティ需要予測工場生産予定取引先との商談販売目標販売計画得意先受注出荷依頼

売上納品請求入金在庫商品

受注得意先請求

入金

販売目標

販売計画

売上

在庫

商品

需要予測

工場生産予定

関連が強いものをグループ化（データクラスとも呼ばれています）

請求エンティティ

関連

関連の一方が１のとき、もう一方の数で複数あることを示す。

■あるべき姿の情報システムモデルの作成

新しい業務モデルを参考にして、あるべき姿の情報システム案を検討しモデルを作成する。情報システム

モデルとしてはデータモデルとアプリケーションモデルを作成する。データモデルは業務モデルの分析で

あがってきたデータ項目とその関係を表現したものです。データの洗い出しにより似たようなデータの重

複や不整合を防ぐ。



■データモデルの作成

（１）エンティティの抽出

エンティティの抽出は業務上の核となる実体（例.商品、得意先、仕入先）と実体はないが管理すべき

ものや情報として認識できるもの（例. 予算、売上）を抽出する。これをエンティティと呼ぶ。

（２）エンティティの関連付け

(1)で抽出したエンティティ同士に関連性があるか検討する。たとえば、｢得意先｣と｢商品｣の間には、

｢注文をする｣、｢納入をする｣、｢売上を計上する｣などといった関係が考えられる。このように関係が

ある場合に関連付けをする。エンティティ同士を線でつないで表現する。

業務

論理デー

タベー

ス工場生産予定

販売目標

需要予測

販売計画

取引先との商談

受注

出荷依頼

売上

納品

請求

入金

在庫

得意先

商品

経営目標作成

中長期計画作成C

収益性分析 C

需要予測 C

マーケティング営業活動 C販売計画 C受注管理 C C出荷 C C在庫管理 C返品管理 R販売実績管理 C請求 C C販売支援顧客サービス管理 CEDI受注管理 C C商品管理

経営計画

販売

業務と論理的なデータベースの関係(CRUD図を使用)Cは生成を表す Rは置換を表す

（３）情報の構造化

エンティティあるいはERDから関連が強いものをグループ化したもの（これはデータクラスとも呼ば

れる）を論理的なデータベースの候補と仮置きし、業務との関係を表にする。

3.2.3. アプリケーションモデルの作成



情報システムの定義図

販売システム

受注管理サブシステム

販売計画サブシステム

需要予測サブシステム

出荷サブシステム

在庫管理サブシステム

省略省略


販売システムをサブシステムに分割

業務

論理デー

タベー

ス候補

工場生産予定

販売目標

需要予測

販売計画

取引先との商談

受注

出荷依頼

売上

納品

請求

入金

在庫

得意先

商品

財務計画

事業損益

決算書

税金

経営目標作成

中長期計画作成

収益性分析

需要予測マーケティング営業活動販売計画受注管理出荷在庫管理返品管理販売実績管理請求販売支援顧客サービス管理EDI受注管理商品管理

仕訳処理損益管理決算処理

財務システム

販売システム

財務

経営企画

経営管理シ

ステム

販売

（１）情報システムの定義

データモデルで作成した業務と論理データベース候補の関連表を使用し、同じ業務で生成するDBをま

とまるように並べる。そして１つの業務と生成するDBの範囲を枠で囲む。それを情報システムの範囲

とみなし、システム名称を付ける。別のシステムのDBの更新や参照などがある場合には、矢印を引き、

データの流れがあること明らかにする。

（２）サブシステムへの分割

さらに構想を具体化するために各情報システムをサブシステムに分割する。(1)のように、業務と生成す

るデータとの２次元の領域をサブシステムとすると整合性が取れる。どの業務と業務を一緒に考えるか

により、サブシステムの粒度は違ってくる。現状のサブシステムの粒度も参考になる。図のようなサブ

システム階層図を作成すると一覧性があり、わかりやすい。サブシステムのコンセプト、機能概要、イ

ンタフェースを表にまとめる。この表は全社モデルとして管理できるように定義項目を決めておく。全

社の中で再利用可能なコンポーネントを適用するための資料としても利用できる。

販売システム

受注管理サブシステム

販売計画サブシステム




省略省略サブシステム概要説明

全社アーキテクチャ管理資料

再利用可能コンポーネント定義表

（サブシステムレベル）

ERP

ERPパッケージ

EAIツール

再利用可能コンポーネントの利用

適用可能か

コンポーネントとは

コンポーネントとは実行可能なソフトウェアの単位です。コンポーネントの粒度はさまざま



（３）再利用コンポーネントの利用の検討

コンポーネントとは実行可能なソフトウェアの単位をいう。コンポーネントの粒度は１つのシステムや

サブシステムと言えるほど大きなものから Java言語の１つのオブジェクトまでさまざまな粒度がある。

サブシステム（あるいは情報システム）単位に、個別にシステム開発を行うか、ERPやグループウェア

などのパッケージソフトウェア、あるいは自社内のソフトウェアコンポーネントを適用するか、また適

用する場合にどの程度のカスタマイズが見込まれるのかなどの検討を行う。個別開発の方が、ユーザの

ニーズをより良く満たすことができるが、コンポーネントを利用することによりスピーディに開発を進

めることができる。ただし、適用にあたってはカスタマイズの度合い、性能の見通し、システム基盤へ

の依存度合い、利用やカスタマイズのしやすさなどで評価を行う。

・汎用的な統合ツールの利用

EAIツールに代表されるようなシステム連携ツールを活用することにより、複数の情報システムの関

連を疎関係にしながらもデータ交換や２つのプロセスを自動的に連携をしたり、システム間を迅速に

結合させることができる。このようなツールも種類があるで、ツールの種類や目的を調査をしておく

と良い。

・他のシステムで利用できるようなコンポーネントの検討

情報システム構想で複数のシステムを検討している場合、他のシステムで利用可能なサブシステムが

切り出されることもある。１つのシステムに閉ざされることなく、サブシステムのコンセプトやイン

ターフェスの方針を明確にして、コンポーネント化の計画を立てることにより開発の効率化を図るこ

とができる。

3.2.4. 基本処理方式について方針検討

Webオンライン系

受注管理サブシステム販売計画

サブシステム




請求サブシステム

返品管理サブシステム

商品管理サブシステム

得意先管理サブシステム EDI受注管理サ

ブシステム

顧客サービス管理サブシステム

販売実績サブシステム

クライアントサイドサーバーサイドホストサイド

バッチ系

日時バッチで更新データをサーバーサイドへ送付

月次バッチ日時で出荷実績データ送付

オンライン系

販売システム基本処理方式図

本社：名古屋情報管理センター配送センンター埼玉配送センター、広島配送センター全国営業所２０拠点

バッチ系

オンライン系

TCP/IP



■基本処理方式の方針

システムの基本処理法式としては分散化するか集中化するかは議論のある点である。ネットワークの高性

能化により、必ずしも分散化の必要はなくなっている。また、ダウンサイジングにともなう分散化も必然

的に発生する。さらに、新しいビジネス分野に進出するために、他社との緊密な連携も発生する。そのた

め構想段階で基本的な処理方式を検討しておく。また、運用段階での不整合を防ぐために、現行システム

の活用拠点、サブシステムの処理サイクル、現状システムの稼動状況、システム基盤の状況などの情報を

収集して検討する。

収集する情報には次のようなものがある。

（１）情報の活用拠点の確認

サブシステムで扱う情報の活用場所を確認する。

（２）既存システムの情報の存在拠点の確認

既存システムの場合、情報がどこに存在しているかを確認する。

（３）処理サイクルの決定

サブシステムの主たる機能の処理サイクルは、即時処理、一定時間での処理、日次処理、週次処理、

月次処理、年次処理かなどを確認する。

（４）システム基盤や要求の調査

既にあるインフラ基盤の依存状況と、新システムへのレスポンス要求などの調査を行う。

■基本処理方式の方針の決定

（１）～（４）の情報を元にして、システムを集中化するか分散化するか、あるいは両者を統合した統合

型にするかなど方針を決める。また、各サブシステムがバッチ系かオンライン系かなどをおおよその案を

決めておく。将来的な拡張性、保守の容易さ、データの整合性などが重要な判断基準になる。（サーバー

サイドかクライアントサイドかホストかなどで処理方針の呼び名が違うこともありますので、自社の標準

的な名称を使用すること。）



3.2.5. 阻害要因やリスク分析と構想まとめ

阻害要因やリスクの整理阻害要因やリスクの整理

阻害要因

リスク

阻害要因

リスク

解決方法の検討解決方法の検討

対策の実施・回避のための準備

対策の実施・回避のための準備

情報化課題情報化課題

アプリケーションモデル


業務モデル業務モデル

これまで作成したドキュメントをまとめ情報化構想書を作成し、経営層の承認を受けます

阻害要因とリスク分析

■阻害要因とリスクの分析および解決方法の検討

情報システムの方向性が明確になった段階で、阻害要因やリスクを見通し、解決方法をまとめる。阻害要

因やリスクには、次のようなものがある。

・経営方針に起因するもの

経営方針に起因する典型的な阻害要因は、コスト削減要請である。これを解決するには、情報化がもた

らす経済的効果を分析して経営者や関係者の承認を得る必要がある。

・組織文化や組織関係に起因するもの

組織文化や組織関係に起因するものには業務効率化やアウトソーシングなど、情報化と関連して業務改

革が進んでいる場合などに、労使関係の問題や組織の情報化に対しての保守的な反応などがある。これ

は解決も難しく、別プロジェクトなどで経営層と協同で取組む必要がある。また、複数の組織が絡む場

合には、業務負担増の発生に対してどの組織が担当するのかといった利害関係や責任回避など、組織と

新業務に関する阻害要因が発生する。これらも経営層と協同して、啓蒙活動を行う必要がある。

・現行システムとのインタフェースに起因するもの

現行システムとのインタフェースに起因するものも阻害要因やリスクとなり兼ねないのでアプリケー

ションスペシャリストとともに、実現可能な解決策を検討する。

・情報技術の高度化に起因するもの

情報技術の高度化に起因するものとしては情報技術の高度化がある。高度化や複雑化に伴い技術上の問

題が発生する可能性も高く、その技術を活用したシステム設計ができる人員が不足するといった問題も

考えられる。これらは ITスペシャリストやアプリケーションスペシャリストも交え、技術コミニュテ

ィに参加したり、教育を受けたりといった解決策の検討を行う必要がある。

■開発優先順位と投資対効果分析

システム構築（コンポーネント設計）は、重要度、緊急度、開発の難易度、投資高と期待効果などに重み

付けを行い、プロジェクトチームで評価の上、開発の優先順位を決定する。最期にこの節で作成したシス



テム構想案をまとめ、経営層の承認を得る。これにより中長期の安定した情報システムの開発を行うこと

ができる。情報システム構想は一度作成したら終わりではなく、定期的に見直しを行う。

3.3. 業務機能の要件定義

3.3.1. 対象業務の定義

業務分野業務業務機能作業(タスク）販売販売計画製品別販売計画製品販売計画主シミュレーション

製品販売計画確定製品販売計画差し戻し

重点得意先別販売計画得意先別販売計画主シミュレーション得意先別販売計画確定得意先別販売計画差し戻し

担当別販売計画担当別販売計画シュミレーション受注管理見積り在庫検索

価格検索納期確認見積書発行

受注登録与信限度確認受注保留在庫引当受注登録受注伝票発行

注残管理注残登録注残一覧作成

出荷出庫処理在庫引落ピッキンリスト作成配送先別一覧作成ピッキング欠品処理出荷状況問い合わせ

配送処理配送車別積載箱番一覧配送車別集荷荷積み

業務機能一覧

業務マニュアルや業務担当者へのインタビューなどにより詳細な作業（タスク）に業務機能を詳細化する。

作業の概要説明を書いておくと良い。名称だけにすると、プロジェクトチーム員の中でも誤解が生じること

があり、以降のアーキテクチャ設計にも影響する。



3.3.2. 機能要件の定義

システム化要件の一覧

情報システム構想書

ユーザ要望/課題

要件定義

機能要件

非機能要件

明確化作業（モデリング）システム基盤

の要件定義へ

現状システムの把握

(1)システム化要件一覧の作成項

番システム化要件優先度内　　容問題点備考1 営業所と配送センターはWEB

アプリケーションにする

◎

営業所のオフコンを撤廃し、汎用

的なパソコンにする。配送センターにWWWサーバを設置し、営業所は配送センターサーバのクライアントとする

配送センターを

356日24時間稼動にしないと営業活動に支障が出る

2

配送センターの迅速な出荷に

よる顧客サービスの向上 ◎

営業所の受注登録により、配送

センターからすべて出荷する

3

在庫がない場合の注文残管

理の自動化による営業所管理業務の軽減とミス削減

○

配送センターに在庫不足が生じ

た場合、注文残をデータとして登録する

いつも在庫がない

ものの対応を考える

4

与信限度額の設定により信

頼性の高い取引を行う

○

得意先情報の登録時に限度額を

登録し、売上及び返品時に更新をする。限度額を超えた場合には特別決済ＩＤがなければ販売できない。どうしても必要な場合は保留処置を行う。

・特別決済の仕掛

けを作成する必要があり・在庫仮抑えで保留された受注を取り消す仕組みが必要

5 需要予測制度の向上 ○ 予測シュミュレーションソフトの導

入を行い需要予測作業を行う

6 配送センターの適切な在庫維

持

◎ 発注点管理方式により自動補充

ができる仕組みにする

工場に在庫がない

場合には補充されない

要件定義とはシステム化対象の情報システムアーキテクチャを設計することを目的として、情報システムを

実現するための制約や条件を収集・分析を行う作業をいう。情報システム構想の中で明確になった課題や方

針のほかに業務の定義中にユーザからヒアリングしたシステム化の要求がありこれらを一覧表に纏める。要

件を明確にし実現可能性やその実現のためのコストなどを吟味することにより、後工程の手戻りを発生させ

ないようにする。また要件にはシステム基盤に該当するものもある。同時に現状システムの調査を行う。こ

れは既存システムの再利用やインタフェース上の制約条件となり、重要な要件である。現状システムの把握

は開発時に作成したシステム化計画書、現状のDB構成や関連、サブシステム構造、インタフェース、運用

方式、稼働率などを超諫する。



注文書

受注管理業務（サブシステム）のDFD

見積り

営業担当者

受注管理

システム

受注情報

注残情報


商品情報

得意先情報

商品名

得意先与信限度額

注文情報

在庫情報


得意先

見積り依頼

見積書

色塗りがありものはコンピュータを利用するもの

注残管理

システム

注残管理

システム

このDFDは担当組織を明らかにするためにラウンドボックスを３つの区画に分けています。また外部実体を明示するために縦線を引いています。

(2)システム利用作業の切り分け

業務処理概要図を参照して、｢作業｣の粒度でDFDを作成する。DFDにより「対象とする作業」、「サブシ

ステムの主要な情報」、「作業｣の関連を明らかにすることができる。また、他の作業や他のサブシステム

との関連も明確になる。このDFDは｢作業｣の実施責任者とコンピュータを利用するかどうかをラウンドボ

ックスに記載するためにボックスを 3つに分けて記述している。

3.4. 情報システムの機能の明確化

3.4.1. データアーキテクチャの明確化

論理DBの候補

エンティティの関連付け

受注得意先

受注明細

売掛金

入金

ERD

受注得意先

受注明細

売掛金

入金

ERD

データ定義

エンティティキー生成者利用者属性（データ項目）得意先ID得意先名得意先住所電話番号郵便番号

受注管理受注NO商品ID得意先ID数量単価配送先名配送先ID配送先名

受注受注NO 受注管理システム出荷

得意先得意先ID 得意先管理システム販売システム

機能要件

業務モデル

機能要件

業務モデル

データモデル



作業の流れ



情報システムの機能の明確化とは情報システムの機能的側面であるデータおよびアプリケーションモデル

の作成を行い、アーキテクチャを明確にすることをいう。この工程ではより正確なシステム規模の見積りを

行うために、前工程よりもさらに業務の詳細化した｢作業｣レベルで検討を行う。なお、情報システム構想で

作成したモデルを利用して概算のシステム規模を見積り、開発スケジュールを立案することもある。

■データモデル作成

（１）論理DBの候補抽出

エンティティの抽出方法は前工程と同じ。作業レベルになったことにより管理しなければならないも

の（これがエンティティ）が増えている。これを洗い出し、関連を結びER図を作成する。これが論

理DBの大枠になる。なお、これはコンポーネント設計に入った段階で正規化を行い、論理DBとし

て設計する。

（２）データ項目収集

次にDBの属性（データ項目）となるものを伝票、帳票、画面などから収集してエンティティと関連

付ける。現状のデータベースの構成なども参考になるが、それにあまりまどわされると論理的なもの

にならない。現状のDBと不整合な点が明確になった場合には、移行処理が必要になるため開発課題

として一覧表に整理しておく。

（３）データ定義の作成

(1)、(2)の結果を踏まえて、データ定義一覧をまとめる。主要なキーやデータの生成者、利用者もデ

ータ定義表に書き込む。

3.4.2. アプリケーションアーキテクチャの明確化

3.4.2.1. コンピュータ処理一覧の作成と再利用コンポーネントの適用

WWW AP/DBWWW AP/DB

コンピュータ処理一覧

業務名業務機能名処理内容説明受注管理受注登録顧客からの受注伝票を登録す

る。顧客は顧客マスターに登録してあること、商品も事前に商品マスターに登録してあるものを使用する。配送センターに在庫がない場合には注残として、納期をお客様に回答する。

注残管理配送センターに在庫がない場合に、工場および他の配送センターに在庫があれば注残として注残情報に登録する。

注残管理

システム

受注管理

システム

業務ロジック

運用制御基盤

フレームワーク

再利用可能なコンポーネント

再利用可能コンポーネント一覧表

適用可能か？

■コンピュータ処理部分の処理概要

DFDで明らかになったコンピュータ処理部分をピックアップして、アプリケーションの概要概要説明を



作成する。業務機能の粒度が大きい場合には、一部のみシステム化対象ということもあるので、わかりや

すい説明を書くようにする。

■ﾗｲﾌﾞﾗﾘ、ﾌﾚｰﾑﾜｰｸなどの再利用コンポーネントの適用や汎用パッケージの採用の検討

コンピュータ処理一覧で記述した処理内容やシステム化要件などからライブラリ、フレームワーク、汎用

パッケージ、あるいは現行システムの一部を再利用できるかどうかを検討する。図の例は現在ではPCサ

イドのブラウザとWWWサーバーがインターネット経由して処理をすることが多いため、WWWサーバ

ーサイドの処理制御やデータベース制御などの共通処理を行う運用制御基盤と条件ごとに異なる処理を

するパターンの処理をフレームワークとして再利用できるようにしたもの。すでに実績のあるコンポーネ

ントを利用することにより、生産性向上や高い信頼性を得ることができる。ただし、再利用コンポーネン

トを利用する場合、特に業務ロジック部分があるコンポーネントの場合はコンポーネント仕様と業務仕様

が同じかどうか、異なる場合にはどの程度のカスタマイズが必要かどうか具体的に把握する。カスタマイ

ズがあまり大きい場合は採用を中止する。

■再利用コンポーネントの抽出

再利用コンポーネントの抽出とは複数の情報システムのアプリケーションに共通する再利用可能なコン

ポーネントを抽出することをいう。前工程でも再利用の検討を行ったが、分割されてモジュール化してく

るほどに検討しやすくなる。コンポーネントの開発は業務システムの開発に先がけて行うようにする。

3.4.2.2. サブシステムの階層化

販売管理

入金管理出荷手配受注

残高集計

入金引当

請求売掛計上

顧客登録

出荷手配

受注登録

注残管理


機能名担当サイクルデータ名作成場所

サイクルデータ名出力先サイクル

注文書製造部

注文書注文書情報受注DB顧客情報顧客管理

DB

顧客随時随時注文情報（製品名、数量、単価、配送先）、担当営業を入力し、受注を登録する。

注文書情報受注登録営業随時

発注仕様書

業務機能入力データ出力データ業務機能説明

サブシステムとデータの関連一覧

ピックアップされたコンピュータ処理部分をサブシステムおよびさらに細分化した機能モジュールへと階

層化する。階層化した最下位のモジュール単位に機能と入出力のデータ、およびそのサイクルを検討してお



く。データモデルで分析した以外のデータも抽出されるので、その場合にはデータモデルを修正する。

3.4.2.3. システム概要処理フローの作成

販売管理

出荷手配受注

売掛計上

顧客登録

出荷手配

受注登録

注残管理


受注登録

出荷手配

売上計上

システム概要処理フロー

受注DB

出荷実績DB

売上実績DB

機能モジュールの中で処理に流れがあるものは処理フローを書く。データの関連性や処理の順番などがより

明確になる。ここではサブシステム階層図や処理概要フローを用いたが、UMLのユースケース図やユース

ケース記述により同様に表記することができる。また、サブシステム階層図や概要処理フローから、既存の

システムとのインタフェースを見直す。既存プログラムの改訂点が具体化するほか、ファイル形式が変わる

場合にはどのような移行処理を行うかを検討する。



3.4.3. 処理方式の決定とハードウェアへの割り当て

項番項目選定方針重要度備考

1

適用技術の将来性業界標準に合わせる高

2

システムの移行性ホストDBからの移行を前提とする高

Webアプリケーションを基本とする

Webサーバーは秋田と広島に分散する

5

システムの信頼性、可用性、セキュリティ、保守性

今後の社内システムとして高い可用性と十分なセキュリティが必要である

中

業務面の変更の大きさと導入コストが見合えば、適用する

中

システムの処理方式高

3

4

統合業務パッケージの適用

システム選定の検討表

サブシステム名機能名データ名販売管理受注注文

注残データ顧客マスター商品マスター

出荷出荷実績

発生サイクルデータ量増加率随時 30000件/月年30%随時 100件/月 -随時 20000件/月随時 100000件/月２回/日 30000件/月年30%

データ量の見積表

システム基盤の明確化

プロセスモデル

■システム基盤の検討

適用する技術の将来性、現状システムからの移行性、システムの処理形態、統合パッケージを使用、デー

タ量の見積り、処理フローなどを参考にして、基本的なハードウェア、ネットワーク、ソフトウェア、お

よびシステム基盤を決定する。

販売管理

入金管理出荷手配受注

残高集計

入金引当

請求売掛計上

顧客登録

出荷手配

受注登録

受注見積作成

販促

営業所サーバー配送センター

サーバー本社ホスト

クライアントPC



ハードウェアへサブシステムのマッピング

DBサーバー

TCP/IP TCP/IP



■処理方式の決定とハードウェアへのマッピング

機能サブモジュールおよびさらに細分化したモジュールごとに、ハードウェアへのマッピングを行う。最

終的はシステム基盤アーキテクチャのモデル作成をとおして、最適なマッピングを行う。

■システムの処理方式の決定

情報システム構想で基本的な処理方式を決定している、この工程では処理方式の再評価を行う。

ホストマシンやサーバにアプリケーションとデータを集中した場合には次のようなメリットとデメリッ

トがある。

・管理が容易で、統制しやすい。

・セキュリティ管理が容易で、障害対応や復旧のノウハウを蓄積しやすい。

・データの信頼性が高い。

・大量印刷、大量データ処理に向いている。

分散方式にした場合には、次のような特徴がある。

・低コストで利用側が自由に管理できるが、統合的な管理は難しい。

・セキュリティリスクがあり、障害対応や復旧は利用側のスキルに依存し、リモート監視のための仕組み

が必要。

・利用側のニーズに合ったデータ利用が可能。

・オープン技術を活用したシステムに向いている。

3.4.4. 要件実現度の評価

情報システムモデルシステム化計画書

システム基盤モデル

項

番システム化要件優先度内　　容問題点担当サブ

システム難易度コスト備考1 営業所と配送センターはWEB

アプリケーションにする

◎

営業所のオフコンを撤廃し、汎用

的なパソコンにする。配送センターにWWWサーバを設置し、営業所は配送センターサーバのクライアントとする

配送センターを

356日24時間稼動にしないと営業活動に支障が出る

受注/出荷

手配

高(運用

面)

中

2配送センターの迅速な出荷に

よる顧客サービスの向上 ◎営業所の受注登録により、配送

センターからすべて出荷する

受注中中

3

在庫がない場合の注文残管

理の自動化による営業所管理業務の軽減とミス削減

○

配送センターに在庫不足が生じ

た場合、注文残をデータとして登録する

いつも在庫がない

ものの対応を考える

受注低中

4

与信限度額の設定により信

頼性の高い取引を行う

○

得意先情報の登録時に限度額を

登録し、売上及び返品時に更新をする。限度額を超えた場合には特別決済ＩＤがなければ販売できない。どうしても必要な場合は保留処置を行う。

・特別決済の仕掛

けを作成する必要があり・在庫仮抑えで保留された受注は１週間をすぎるとログメッセージを営業担当者に送信して取り消される

受注/得意

先管理

中低

5 需要予測制度の向上 ○ 予測シュミュレーションソフトの導

入を行い需要予測作業を行う

需要予測高高

6 配送センターの適切な在庫維

持

◎ 発注点管理方式により自動補充

ができる仕組みにする

工場に在庫がない

場合には補充されない

高中

業務モデルシステム開発方針の策定

規模見積り

開発スケジュール作成

投資対効果の分析



3.6節の学習内容



■目的・サブシステム関連表による要件の実現度の評価

機能要件の定義で定義した要件がサブシステムで実現しているか評価するため、｢システム化要件の一覧｣

を元に要件を実現するサブシステムを追加する。（これを目的・サブシステム関連表と呼ぶ。）

■システム開発計画書の作成

これまでの検討結果をプロジェクトマネージャが中心となって、システム化計画書としてまとめる。計画

書に対する経営トップの承認を得て、次工程の作業であるコンポーネント設計を開始する。コンポーネン

ト開発工程はプロジェクトマネジャがマメジメントを行い、アプリケーションスペシャリストや ITスペ

シャリストが作業を行う。しかし、基本方針、目標、作業計画は、情報システムのアーキテクチャを最も

理解している ITアーキテクトがプロジェクトマネージャを支援して決定することが最良な方法である。

3.5. システム開発基本方針の策定

■システム開発の基本方針

システム開発の基本方針とは、コンポーネント設計に入る前に基本的な開発方針を定めておくことをいう。

ITアーキテクトは、プロジェクトマネージャを支援して作業を行なう。

（１）開発プロセスの決定、開発技法の決定、その他、開発手法に関する決定

システム開発を実施する際には開発前の企画段階で、開発プロセスや開発技法の選択、再利用性を確

保するための基本的な方針、フレームワークの利用、開発の標準化の方向性などをシステムの特徴や

メンバーのスキルを考慮して決定する。

（２）システム移行に対する基本方針

システムを一度にすべて置き換える例は少なく、実際の新規システムはほとんどの場合、既存システ

ムとのインタフェースを持っている。旧システムのデータを移行したり、システムを並行運用する可

能性がある。このように旧システムとの整合性を保つことは大変重要で、業務の流れを含めた全体的

な整合性を十分に検討しておく必要がある。

（３）開発環境整備に対する基本方針の設定

開発施設や開発機械の調達など開発環境の整備、テスト用機器やデータ準備などの方針を決める。

3.6. コンポーネント設計

3.6.1. コンポーネントとは



部品

部品

部品

部品

骨組み

品質の高い部品を使用したビルディングブロック

部品

連携コンポーネント連携コンポーネント



ビジネスコンポーネントビジネスコンポーネント

分散コンポーネント分散コンポーネント

言語クラス言語クラスオブジェクト指向のクラスの概念で作成

された分散可能なコンポーネント。コンポーネントよりも粒度が小さい。

コンポネントの最小単位。実行時に単独である目的の実現のために言語クラス複数集まったもの。インタフェースとインタフェースとは分離した実装から構成。

あるビジネスプロセスや１つのビジネスの目的を実現するためのコンポーネント。自律的に実行可能。自律的に稼動するために必要なリソース（ハードやデータ）もすべてが構成要素。

特定のビジネス課題に対する解決策を提供するもので、ビジネスコンポーネントの集合。

複数の異なる組織のユーザにとって課題を解決するためのもので、ビジネスコンポーネントシステムの集まり。ビジネスのニーズを実現。

コンポーネントの粒度

■コンポーネントとは

あるまとまった実行可能なソフトウェアの単位をコンポーネントと呼ぶ。現在、コンポーネントはさまざ

まな粒度のものが存在し、ERPパッケージソフトのように丸ごと１つの業務を実行できる大きなものから、

Java言語で作成した小さなオブジェクトまである。それらの共通の思想は、あらかじめインタフェースを

用意し、何かしらの方法で機能をインタフェースを通じて提供するもの。このことからサービスコンポー

ネントとも呼ばれる。説明してきた基本の手法は従来からあるプロセス中心アプローチとデータアプロー

チだが、ここで導き出されたシステムやサブシステム、さらには下位のモジュールも、基本機能とインタ

フェースを明確にしたものでコンポーネントと定義することができる。

3.6.2. コンポーネントベース開発とは

コンポーネントを利用した開発のメリット生産性向上品質向上組み合わせによる多様化

情報システム全体アーキテクチャ

システム化要件

コンポーネントコンポーネント


共通部品の抽出


再利用可能な部品の選定



全社的な視点で管理

上流工程

実装・テスト工程



■コンポーネントベース開発とは

30年前よりソフトウェア開発は手工業から工業化を目指して、さまざまな技法やツールが開発されてきた。

そのうちの重要事項として、ソフトウェアの部品化が追求されてきた。品質の良い、規格化されたソフト

ウェア部品を組み合わせることにより、システムを開発しようというもの。近年のオブジェクト指向技術、

およびコンポーネント化が容易な実装技術(たとえば、Java)の普及により、急速に現実的なものとなって

きている。コンポーネントベース開発には｢コンポーネントを再利用すること｣と｢再利用可能コンポーネ

ントを開発する｣という２つの面を持っている。コンポーネントベース開発はまだ確立したメソトロジで

はない。しかし、これまで説明してきたように上流工程段階から関連システムとの整合性やインタフェー

スを見極めながら、再利用の検討をすることが大切である。また再利用可能なコンポーネントを開発する

ためには、コンポーネントのコンセプトをきちんと定義し、インタフェースを明確にし、さらに全社的な

視点に立ってコンポーネントを維持管理していく必要がある。業務、DB、アプリケーションの相互の関

係とコンポーネントの凝縮性を論理的に設計することにより、再利用可能なコンポーネントの導出は可能

だと言える。また、コンポーネントを再利用した開発には生産性向上、品質向上などのメリットがあるが、

コンポーネントを再利用する場合には、適用するシステムの情報システムアーキテクチャおよびコンポー

ネントの仕様について十分に理解し、カスタマイズ量も見極めた上で採用を決定する必要がある。

3.6.3. コンポーネント開発工程

要求分析要求分析

外部設計外部設計

内部設計内部設計

コーディングコーディング

テストテスト

運用・保守運用・保守

要求を収集、分析 ⇒ システムに取り込む要件を決定する

ユーザの立場からみたシステム設計を行う

ソフトウェアとして実現可能な設計を行う

内部設計に従い、プログラムを作成する

要求どおりに稼動するかどうかの検査を行う

本番システムの運用や不具合に対する作業

コンポーネント開発工程

■コンポーネント開発工程

ここでいうコンポーネント設計とは、特に再利用可能コンポーネントを設計するためのものではなく、情

報化企画プロセスで導出されたサブシステムやモジュールをソフトウェアとして設計し開発する工程に

ついて説明する。この開発工程は具体的に画面の設計やDB設計を行い、プログラムを製造する。主たる

作業者はITスペシャリストやアプリケーションスペシャリストとなる。ITアーキテクトは企画者として、

技術的な指導、メンバーの支援、開発目標値の管理、また大きな技術上の障害が発生した場合の対応を行



う。そのためにも開発に関するスキルは十分に習得しておく必要がある。以下に工程の概要を説明する。

・要求分析

要求分析ではユーザの要求を収集して、具体的にシステム化するための要件の定義を行なう。

・外部設計

外部設計ではGUIなどユーザから見たシステムの設計やユーザサイドから見た処理機能の設計を行う。

ユーザの要求を十分に反映した設計を行う必要がある。

・内部設計

内部設計では外部設計の内容をソフトウェアで実現するために必要なシステム内部の設計で、プログラ

ムのモジュール分割、画面、DBの設計などを行う。

・コーディング

コーディングでは内部設計にしたがって、プログラムを作成する。

・テスト

テストでは作成されたプログラムが要求どおりに稼動するかを単体テスト、結合テスト、総合テスト、

運用テストと段階を踏んで検査する。

・運用・保守

運用･保守では本番に移行した後の運用や本番環境で稼動しているシステムの不具合の修正、環境変化

にともなうシステムの改版を行う。



４．システム基盤の企画と設計（非機能的側面）

4.1. システム基盤構想の立案

4.1.1. システム基盤課題の分析

コンサルティング

現状システム基盤課題

新業務機能要件

現状システムアーキテクチャ

アセスメント課題抽出

・現状アーキテクチャ調査・現状運用調査・現状問題点分析・関連技術動向の調査

・新業務での技術テーマ分析・IT検討課題の策定

システム基盤とは、業務機能の実行を目的として構築され、それらはさまざまなハードウェアやソフト

ウェア、それらを運用する体制などから構成される。 ITアーキテクトは最適なアーキテクチャの検討を行

い、システム基盤を実現して行く必要がある。システム基盤は、通常業務機能側の要件により実装されるも

のであり、それらを無視して作業をすすめることはできない。すべての機能は、業務側の要件により定義さ

れ実装されるものとなる。このタスクでは、新しい業務機能を実装するに当たって、システム基盤で解決し

実現しなければならない課題を明らかにすることを目的としている。このフェーズはコンサルタントととも

に作業を進める。コンサルタントは、ヒアリングや調査を行い、現状の課題や目標設定などを行う。ITアー

キテクトとしては、このフェーズでシステム基盤に対する分析を行う。主に、以下の作業を実施する。

（１）アセスメント

現状システム基盤に対する調査と実態の把握、これらに関する問題点の分析を実施する。

おもな実施テーマは以下のとおり。

・現状アーキテクチャ調査

・現状運用調査

・現状問題点分析

・関連技術動向の調査

（２）課題抽出

上記のアセスメント結果より、取り組むべき課題の抽出を実施する。



・新業務での技術テーマ分析

・IT検討課題の策定

課題に対しては、その実現性についても検討すべきである。実現方式の具体的な検討は以降のタスク

となるが、この時点で、技術レベルの難易度、実現するために発生するコスト、など課題解決に対して

制約事項となるものを確認し、可否についてもまとめておく。これらは、このシステムを実現するとき

の目標設定に必要なものとなる。

以降の作業タスクでは、このタスクで明らかになった課題を解決し、業務機能の要件に合致したシステム

設計を進めることとなる。

4.1.2. システム基盤の方向性検討

ランク外

ランク2

ランク1

新システム基盤課題

課題1

課題2

課題2

課題4

課題5

課題x

課題x

課題x

目標外の課題

課題に対する観点・アプリケーション実現の貢献度・実現の難易度・発生コスト・先進性

課題のランク付け

新しい「実現すべき課題」

プロジェクトオーナ、プロジェクトスポンサー、プロジェクトマネージャの要求

と合意

システム分析を経て明確になった解決すべき課題を整理し、本システム基盤の方向性付けを行うための方

針を決定する。課題に対しては、それぞれに優先付けを行うランクを設定する。主な観点は、以下のとおり。

・業務機能実現のための貢献度

・実現の難易度

・実現するために発生するコスト

・実現するために必要な技術の先進性や難易度

これは、すべてを満足する必要はかならずしもない。顧客を取り巻く環境や、業務機能に求められる要件

などで観点は変わって行く。そのため、最も重要と思われるものに対して、ランクをつけて行く。これらの

ランク付けから、本当に必要な課題に絞り込む。これは、プロジェクトメンバやプロジェクトスポンサーな

どとの合意が必要となる。



新しい「実現すべき課題」

目標設定

定性目標(1)数値化できない効果

(2)間接的に数値目標へ導けるもの

→要件定義、サービスレベル定義

定量目標(1)数値化できる効果

→サービスレベルの目標数値を導出

要件定義サービスレベル定義

サービスレベル目標値

課題の抽出が完了すると、これを実現するための目標値を設定する。課題を実現するために、目標とするも

のを、定量的、定性的に設定する。定性的な目標も必要だが、定量化できるものは、可能な限り設定してお

くことが必要である。この数値化された目標は、以降の要件やサービスレベルの設定で必要となる。もちろ

ん、ここで設定された目標は、以降の要件定義やサービスレベル定義での基準値となる。

4.1.3. システム基盤のアーキテクチャ検討

新システムイメージ新システムアーキテクチャ概要

実現すべき課題

定量目標

定性目標

ノウハウノウハウ

ノウハウ過去の成功事例

アーキテクチャ1アーキテクチャ2

アーキテクチャ3

製品ベンダ情報

ここまで設定された課題、およびそれらに対する目標がそろったら、それらをインプットとし次期システ

ムのアーキテクチャを構想する。検討にあっては、これまでに明らかにした課題や各種目標値を満足するこ

とが必要となる。アーキテクチャの選定については、さまざまなフレームワークをベースに、各製品ベンダ

からの技術情報を使用して行う。特に重要なのが、過去の類似業務システムのアーキテクチャを利用するこ

とである。これらはすでに実現されているため、その精度は高くなる。この場合、類似部分との違いとなる

部分を明確にする。類似部分は、そのまま過去事例が流用でき、ネックとなる可能性のある差異部分に検討

のリソースを集中して検討できる。このタスクで明らかになったアーキテクチャを用いて、システムの概要

イメージを作成する。これは、物理的なハードウェアやソフトウェアの実装を意識せず、全体的なシステム



のイメージ図と、主要なアーキテクチャの適用イメージ図としてまとめる。これらのイメージ図は、次の作

業のインプットとして活用する。なお、この段階で概算コストの提示を求められることがある。この場合は、

おおよその規模をつかむため、簡単なモデリング作業を実施し、システム構成を明らかにしておくことが必

要となる。ここでは、システム基盤の概要や、アーキテクチャのイメージをつかむことが目的であり、精度

は問われない。明確な部分はある程度詳細でもかまわないが、不明確な部分は、詳しい追求は行わないこと

が必要となる。不明確な部分は、要件としてより具体的な検討を、以降のタスクで実施する。しかしながら、

ここで検討されたアーキテクチャが、以降のタスクにおける検討のベースとなるため、その選定には注意が

必要となる。重要なものは、現実性、実施に当たってのコストである。いずれも、具体性が出てこないと明

確にできないものだが、過去の類似事例などを参考にして、その概要を把握しておくことが必要となる。特

に実現性については、あまりにも非現実的な内容にしてしまうと以降の作業で制約事項となってしまう。設

定した目標にもよるが、ある程度実現の可能性が見えるものでなくてはならない。コスト面についても同様

である。

4.1.4. システム基盤構想書の作成

システム基盤構想書

新システム概要イメージ・実現するための課題一覧・実現のためのアーキテクチャ

その他・システム化の目的

・解決する目標値定性目標/定量目標

システム基盤構想書とは、これまで検討したものをまとめ、新システムで目標とする項目を定義したドキュ

メントをいう。このドキュメントは、これ以降の作業のインプット項目となる。以降の作業ではこの構想書

に記載した目標をクリアする検討や設計を行わなければならない。結果として実現できなかった場合には、

そもそもの目標の設定に誤りがあるか、検討チームのスキル不足などが考えらるが、いずれにしてもサービ

スレベルの低下や、最悪の場合業務システムの構築に支障が出る恐れがある。そのため、事前の目標やアー

キテクチャの検討は十分に行う必要がある。そのドキュメントには、以下が盛り込まれている必要がある。

・実現のための課題と、その解決するアーキテクチャ

・定性目標／定量目標

・システム化の目的

・システム概要イメージ



4.2. システムアーキテクチャの要件定義

4.2.1. 要件定義の目的と位置づけ

システム基盤構想書

業務要件

要件定義

品質要件

セキュリティ要件

運用要件

性能要件

現状システムの把握

明確化作業(モデリング)

要件定義とは、システム化対象のシステム基盤のアーキテクチャを設計することを目標として、業務システ

ムを実現するために必要な条件を収集・分析する作業プロセスをいう。コンサルなどで分析された課題や方

針などを基に、システム基盤の設計で盛り込まなければならないニーズを、複数の視点で明確にする。定義

した要件は、以降の設計作業の基礎となるものであり、この要件を実現させることがシステム基盤設計の目

標となる。さらに業務設計から出てきたニーズについても盛り込むことが必要となる。検討項目は、次の 4

点。

・品質要件

・セキュリティ要件

・運用要件

・性能要件

また、これらとは別に、現状システムの把握を行っておく。これによりシステム基盤構築のためのインプ

ット項目として、現行基盤の活用という項目を盛り込むことができる。さらに、ある程度の実現性を考慮し

ておく必要がある。各要件の実現の可否について検討することは、以降の作業品質を高め、要件の再定義に

戻るという後戻り工数を減らすことにつながる。実現性の観点は、主に「現行の技術レベル」「実現のため

のコスト」となる。システムに対しての投資を把握しておき、その投資に見合った要件とする。また、現行

の技術では不可能であるという判断がある反面、近い将来に出てくるであろう、新しい技術で実現可能とな

ることもある。つまり、従来ではコスト面などで実現不可能だったものが、新しい技術では容易に実現可能

となることがある。これらを把握するためには、新しい技術に常に触れるだけでなく、過去のシステム化事

例をよく把握することが必要となる。特に、定義された要件がどのようにして実現されているのか、さらに

それをベースとして、新しい技術がどのように活用できるのかをよく読みとることが重要。ここでの作業で

は、可能な限り漏れが発生しないようにしなければならない。要件定義に漏れが発生すると、以降の作業が

要件を満たすことができなくなる恐れがある。また、要件は可能な限り明確に定義する必要がある。特に定

量的な指標は、必ず明確にしておく必要がある。あいまいさが残ると、以降の作業の負荷が増大するばかり



でなく、無駄なコストを発生させることにつながる。

4.2.2. 現状システム基盤の把握

目的

・システム基盤、運用設計ポリシーの理解・システム運用ポリシーの理解・他システムとのI/Fの理解

各種設計ドキュメント

顧客システム管理者ヒアリング

現状システムの運用状況の理解

・システム運用スケジュール・システム性能・データバックアップの運用状況・障害発生と対応の履歴など

モデリング作業でのインプット項目

現状システム基盤の把握を行う。すでに構想立案で課題分析や方針などが明らかにしているが、ここでは IT

アーキテクトとして、より具体的な分析を行う。目的としては、現状のシステム基盤を把握することにより、

以下の項目を明らかにする。

・システム基盤設計ポリシーの理解

・システム運用基盤の設計ポリシーの理解

・システム運用ポリシーの理解

・他システムとの I/Fの理解

作業としては、主にドキュメントベースで行う。確認しなければならないドキュメントの例として、以下の

ものが考えられる。

・システム基盤設計書

・システム運用設計書

・オペレーションマニュアル

また、ドキュメント上不足するものに関しては、個別にシステム運用管理者を中心にヒアリングを行う。場

合によっては、現状システムを構築した SIベンダにヒアリングすることもあるが、通常この場合、顧客を



経由して行うことになる。さらに、現状システムの運用状況の理解を行っておく。これは、要件をモデリン

グするときに必要なインプット項目となる。主な項目は以下のとおり。

・システム運用スケジュール

・システム性能

・データバックアップの運用状況

・過去の障害状況とその対応履歴

特にシステム性能については、モデリングにより実際のシステム構成を検討するときの重要なインプット項

目となる。可能な限り詳細な情報を入手しておくべきである。なお、これらの作業においては、顧客の所有

する現有資産に対して行うため、顧客側から提供してもらう情報であることを認識しておく。その必要性を

理解してもらい、情報提供に協力していただく。なお、ITアーキテクトが代行することも可能であり、各ス

ペシャリストと連携して調査を進める。

4.2.3. 品質要件

品質要件とは、主にベンダが提供すべき製品やサービスに対する品質を定義するものである。これらは、以

降の設計に影響するものや、システム稼動後のサービス内容の目標とするものとなる。なお、品質として業

務システム開発時にもその項目が存在するが、これらは外部、特に顧客に向けて定義するものではなく、通

常開発を請け負う SIベンダの内部目標とされるものであるため、このフェーズでは定義しない。要件と

して明確にすべき主な項目は、以下のとおり。

・サービス稼働率(通常、1年間の稼働時間の比率をパーセント表示する)

・保守サービルレベル(サービス時間、サービス内容、サービス体制など)

・システム障害時の、サービス回復時間

近年では、大規模地震やテロなどの広範囲な甚大災害の可能性が高まっている。これらの場合、システムが

完全に復旧不可能な状態に陥ることがある。これらのサービス再開、いわゆるディザスタリカバリの適用に

ついても検討が重要となってくることがある。



4.2.4. セキュリティ要件

検討に当たって….

その品質を実現するに必要なコストを考慮しておくこと

企業の利益

実現にかかるコスト

コストの方が高くては、企業活動が成り立たない。

セキュリティ要件は、セキュリティ対策の実現により発生するであろうコストと、それらをしなかった場合

に失おう恐れのある利益との対比で決定する。そのため、要件により発生するコストについて、可能な限り

概算値として算定しておく必要がある。本来、企業としてはこのシステムを利用することによって利益を上

げることが重要であり、コストのほうが上回ることは原則として受け入れられないためである。そのために、

あまりにもコスト上過大となるような項目については、この時点で見直しをしておく必要がある。ただし、

社会インフラなどの公共性の強いシステムについては、そのシステムの停止により発生する社会的影響によ

り、実現を考慮する。近年、不正アクセスやウィルス感染、データ流出などの、企業活動に大きく影響を与

えるセキュリティ上の問題が多発している。それらの企業情報保護の対策のために、あらかじめ採っておく

べき対策を要件として明確にするための作業フェーズである。セキュリティ対策は、主に外部と内部に対し

てそれぞれに明確にする必要がある。ここでいう外部とは、インターネットなど不特定多数からのアクセス

が想定されるものをいう。近年、インターネットVPNによるアクセスや、メールなどの普及により、企業

内システムといえども、その影響は無視できない状況となっている。外部に対するセキュリティ要件として

は、以下のとおり。

・不正アクセスの検出、防止

・データ改ざんに対する対応

・ウィルス感染

内部は、主に企業内の利用者を想定している。これは、外部に対して比較的制約は少ないが、各利用者個人

のモラルに影響するものであり、まったく対策が不要というわけではない。

主な要件としては、以下のとおり。

・部門、個人に対する、業務やデータの利用権限の定義



共通の要件としては、以下のとおり。

・監視項目、監視方法の定義

・システムの安全性定義

・システム管理体制の定義

セキュリティ要件は、使用するプラットフォームにより、その内容が異なってくる。

プラットフォーム:A プラットフォーム:B

要件1

要件6要件2

要件7

要件5

要件3

要件4

プラットフォーム共通の項目は少ない

なお、これらの要件は、使用するプラットフォームやプログラムにより、内容が異なることがある。あらか

じめプラットフォームが決まっている場合には、そこで必要とされるものを中心に行う。たとえば、OSに

よってはウイルスへの感染が顕著なものや、感染しにくいものがある。あるいは、不正侵入に対して広く知

れ渡っているOSがあったり、そのあたりの知識が浸透していないものもあったりする。すべてに共通の要

件を明確にすることは難しく、可能である場合には使用するプラットフォームに合わせて行うほうがよい結

果が出る。あるいは、要件からプラットフォームを選択することもある。

4.2.5. 運用要件

運用要件とは、業務システムを安定して安全に運用するために必要な要件を明確にすることをいう。複雑化

し、システム規模が大きくなるにつれて、システム運用の重要度は増していく。近年はマルチベンダ環境で

も同一機能で運用を行い、かつ管理者の負荷を減らし、TCOの削減を図る傾向にある。ここでは主に以下

の三つの大きな観点で要件を定義する。

・業務を安定して確実に運用する機能

・業務・システムの稼動状況を的確に把握する機能

・システム基盤の耐障害性を強化する機能

「業務を安定して確実に運用する機能」とは、主に業務機能などの運用を行うために必要な機能の要件を

いう。たとえば、業務を定刻に実行させたり、順序性を確保しながら運用すること。また、障害などによる

業務の中断に対する再開の方法についても検討は必要となる。



「業務・システムの稼動状況を的確に把握する機能」とは、業務機能や、OSやミドルウェアなどのシス

テム基盤の動作ステータスを収集し、運用管理者に通知する機能をいう。たとえば、業務機能の稼動状況を

捉え、正常に終了したのか、障害などで中断しているのかなどを通知し、運用管理者に通知する機能がこれ

に該当する。また、複数のシステムで構成される場合、さらにそれらが複数のプラットホームで構成される

場合など、同一のビューで表示する機能も必要となる。

「システム基盤の耐障害性を強化する機能」とは、障害発生を想定して復旧するための機能や、障害の発

生を抑制、障害による業務への影響を最小限に抑える機能をいう。これは、特に品質要件で出てきた可用性

の要件をさらに具体化し、それらを回避する機能の要件として明確にしておく。また、システムやデータの

バックアップや、それらの保管、リカバリ方法についても明確にし、データの保全についての要件とする。

運用体制の要件の明確化

運用部門

運用機能

対応時間

エスカレーションパス

品質要件

運用体制の要件見直しの検討

また、そのほかには運用体制についての要件を明確にしておく必要がある。運用を行う部門とその機能、対

応時間、エスカレーションパスなどの要件を確認しておく。これは、先の品質要件とあわせ、お互いの要件

を満足できるかどうかについて、検証して置く必要がある。たとえば、保守サービスは 24時間サポートで

きても、運用部門が夜間に不在では、保守サービスをうまく活用できない。そのようなチェックをするため

にも、体制についての検討は必要である。また、近年は運用自体をアウトソーシングすることも多くなって

きている。このような場合にはさらに、要件をアウトソース先に対して必要な要求項目としてまとめておく。

ただし、この場合には上記の機能要件も変わってくることがある。そのため、再度見直しておく必要がある。

4.2.6. サイジング要件

サイジング要件とは、システムの具体的な実装を検討するために必要な定量データをまとめることをいう。

このデータを元に、導入するシステム基盤を選定する。あまりにも過大な要件では無駄なコストが増えるこ

とになり、逆に過少な要件では本番時に要件どおりの性能で動作することができず、結果として追加コスト

の発生となる。主な要件の項目は、以下のとおり。



・単位時間当たりのトランザクション量

・一回で処理が必要なデータのレコード長と、その制限時間

・主要なデータのレコード構造とレコード数

顧客の要件にもよるが、通常は業務システムのもっともピークな日、時間帯を選定し、それを対象として要

件としておく。これにより、もっとも負荷の高い指標を用いてサイジングすることができ、高負荷状態にお

いても要件を満たすシステムとなり、安定稼動に貢献することができる。

サイジング要件には、今後の変化率を捉えること

・年間データ増加量・年間トランザクション増加量など

要件として見るべき期間最終的に必要なサイジングデータ量× =

データ増加量の算出には…・過去のデータ増加傾向・経営上の指標(年間成長率目標など)…から導き出すことができる。

これらの要件は、当然本番時の数値が最も重要だが、これらの数値の今後の変化率を捉えておくとよい。年

間データ量やトランザクション量などがどの程度増加するか等。期間は通常リース完了時点まで、などを想

定しておく。この要件から初期の導入規模、今後の増設計画へと導く。ただし、通常はデータ量などを数年

先まで導き出すのは困難である。この場合には、過去のデータ増加の傾向や、経営上の指標などから推定し

算出する。

4.3. システム基盤の明確化

4.3.1. システム基盤の明確化とは

本作業での作業範囲

システム基盤の明確化とは….

・各種要件を元に、実際のシステムモデルを明確にすること・具体的なハードウェアやソフトウェアの実装はベースとしないこと

各種要件

アプリケーションアーキテクチャデータアーキテクチャ

作業の流れ

プロセスモデルデータモデル

パフォーマンスモデル

アベイラビリティモデル

運用・監視基盤モデル

コンポーネント設計へ



システム基盤とは、業務機能を実行運用するための、各種ハードウェアやソフトウェア、それらを実装した

ものをさす。このフェーズでは、各種要件とともに、その具体的なモデルの作成を行う。この作業フェーズ

では特定のハードウェア、ソフトウェアの実装をベースとしないことが原則となる。どのような製品でも実

装できることを目標とする。本作業での作業タスクは図の点線の範囲となり、以下の５つのモデルを作成す

る作業を行う。

・プロセスモデル

・データモデル

・パフォーマンスモデル

・アベイラビリティモデル

・運用・監視基盤モデル

基本的なインプットは、前フェーズの各種要件だが、そのほかにも業務機能からの要件として、アプリケー

ションアーキテクチャとデータアーキテクチャがインプット項目となる。モデリングにあたっては、各種方

法論を用いて論理的に行うが、必要に応じて実機を用いて実証評価を行うことも重要となる。特にノウハウ

や過去の事例が非常に少ない場合、評価を行っておくことでリスクを削減することができる。

4.3.2. プロセスモデルの作成

プロセスモデルとは

・アプリケーションアーキテクチャを、「プロセス」という単位に分割したもの・プロセスはシステム基盤の最小の実行単位

プロセスモデルの目的

・具体的な機能をイメージとして把握し、以降の作業のベースとなるものを作成する

アプリケーションアーキテクチャ

データアーキテクチャ

処理1

処理2処理3

データベース

OLTP機能

業務機能

システム基盤機能を分割

関連するシステム基盤を明確化

検討の流れ

プロセスモデルとは、「機能アーキテクチャの明確化」で明確にされた、アプリケーションアーキテクチャ



を主なインプットとし、それらを「プロセス」に分解し、構成し直す。プロセスは、システム基盤の最小の

実行単位となり、たとえば一台のコンピュータの中の実行単位を指す。これらの作業により、具体的な機能

をイメージとして把握し、以降の作業のインプット項目となる。業務機能の設計から、以下を入力する。

・アプリケーションアーキテクチャ

・データアーキテクチャ

これらから、個々の機能、すなわちプロセスに分解する。システム基盤としては、業務機能とさらに各種ミ

ドルウェアなどのシステム基盤を実現するプロセスを加えていく。これらの検討により、アプリケーション

アーキテクチャを、個々のプロセスに分割する。このプロセスモデルでは、個々の業務機能だけの検討とす

る。ある業務機能の、インプットからアウトプットまでをプロセスに分解する。

4.3.3. データモデルの作成

業務機能1業務機能1

データモデルとは

・プロセス間を流れるデータでつないだモデル

データモデルの目的

・プロセスモデルに対して実際のデータの種類や流れを明確にする

OLTP

処理1

データベースデータの流れをともに構成する。

手入力

OLTP 処理1

データベース

新しく機能を追加データモデル作成の考え方

データモデルとは、プロセスモデルをベースに、プロセス間を流れるデータでつなぎモデル化したもの。作

業は、プロセスモデルをインプットとし、そのプロセス間のデータの流れを明確にしていく。プロセスモデ

ルでは、業務機能がプロセスとして詳細化されたままになる。そこで、業務機能の設計からデータアーキテ

クチャをインプットとし、これをデータの流れで接続して行く。これにより、以下を明確にする。

・個々のデータの流れ

・流れるデータの種類

・全体のデータの流れの矛盾点

・同一プロセス機能の洗い出し



プロセスに対するデータの流れが明確になると、個別の業務機能のプロセスでも同一機能のプロセスが存在

することがわかる。たとえば、データベースやWebサーバなど、ミドルウェアなどがこれに該当する。デ

ータモデルで矛盾となる部分が存在することがある。たとえば、プロセスがつながらなかったり、プロセス

をつなぐには機能が不足している場合など。この場合、新たに必要となるプロセスを洗い出し、新しくマッ

ピングしていく。これにより、プロセスがデータでつながり、システム基盤を明確にしていく。

4.3.4. パフォーマンスモデルの作成

パフォーマンスモデルとは

・主要なトランザクションの性能のデータを明確にする

パフォーマンスモデルの目的

・性能的観点からシステムの実装イメージをモデル化する。・業務機能から性能要件を明確にする。・ボトルネックとなる部分を明確にする

手入力

OLTP 処理1

データベース

要件より：10件/秒

推測：更新：20レコード/秒検索：10レコード/秒

データモデルに対して性能要件をマッピングする

■パフォーマンスモデル

パフォーマンスモデルとは、主要なトランザクション(主にメインとなる業務処理)の性能に関する基礎デ

ータを明確にし、性能的観点からモデル化を進めるもの。パフォーマンスモデルにより、システム全体と

して業務機能の性能要件を明確にすることができ、性能的なボトルネックが発生するようなシステム構成

になっていないかどうかを明確にすることができる。先に作成したデータモデルに対して、性能値を明確

にしていく。具体的には、サイジング要件で求められた各種性能値をマッピングする。これにより、その

プロセスに要求される処理能力を明確にしていく。このとき、サイジング要件ですべての性能値が明確に

なっていない場合がある。この場合、明確になっていない部分に対しても推論を行って新たに追加する必

要がある。たとえば、三層のオンライントランザクションモデルの場合、トランザクション量のみがサイ

ジング要件で出ている場合がある。トランザクションは、各処理でデータベースをアクセスすることがほ

とんどの場合ありえる。その場合、トランザクション量は、データベースアクセス性能に影響を与えるこ



とになる。

機能1

OLTP

データベース

手入力

10件/秒

更新：20レコード/秒検索：10レコード/秒

機能1

OLTP

データベース

手入力

10件/秒


機能1

OLTP

データベース

手入力

20件/秒


機能1

OLTP

データベース

手入力

15件/秒


OLTPやデータベースには、潜在的に大量のトランザクション性能が要求される恐れがある。→この情報は、実際の構成を検討するための情報となる。

同一のデータベースで作成すると、これらの数値の合計が要求される。

現実的な数値なのか?

また、複数のトランザクションが存在する場合、DBではさらに大きく積み上がることとなる。このような

システムでは、単体ではそれほど大きな負荷でなくても、機能が増えることにより、その潜在的な負荷は増

大して行く。パフォーマンスモデルを作成することにより、どの機能に負荷が集中する可能性があるのかを

把握しておく。この情報を用いて、実際の構成を検討することができる。

4.3.5. アベイラビリティモデルの作成

アベイラビリティモデルとは

・システムの可用性の実装をモデル化したもの

アベイラビリティモデルの目的

・システムの可用性をどのように実現するかの検討・品質要件の実現方法の検討

手入力

OLTP 処理1

データベース

アベイラビリティモデルの検討

停止1

停止2

停止3

検討項目・それぞれの停止時間が業務に与える影響は?・この業務機能の重要度は?・他のシステムに与える影響は?・停止を許容できる時間は?

・それぞれの要件を洗い出す・要求レベルを明確にまとめておく。

アベイラビリティモデルとは、システムの可用性の実装をモデル化したもの。これは、システムの可用性を

どのように実現していくかを検討するためのモデルであり、先の品質要件で明確にしたサービス稼働率など

をどのように実現するかを明確にしていく。まず、データモデルを使って、各プロセスやデータフローの停

止が、システム全体にどのような影響を与えるかを明確にする。その影響が、業務機能全体のサービスレベ



ルにどの程度影響するかを測定する。具体的には、その業務機能の重要度や、他の業務機能に与える影響な

どを推測し、サービス全体に与える影響を明確にしていく。その影響の度合いにより、可用性を必要とする

レベルを設定する。また、品質要件でのサービス稼働率を維持するために、そのプロセスやデータフローに

はどの程度の停止時間が許されるのかも明確にする。その時間内に復旧することができれば、品質要件を満

たすことができる。たとえば、全体に与える影響が少なく、また重要度の低い業務機能であれば、可用性に

対する要求は低くてもよいことになる。逆にシステム全体が停止するような場合や、基幹業務のような企業

の利益に結びつくような業務機能であれば、可用性の要求は高くなる。これにより、もっとも重要となる業

務機能を洗い出し、データフロートそのプロセスを洗い出す。

OLTP

手入力

処理1

データベース

可用性機能のマッピング

パラレル構成による強化

データベース

クラスタによる待機系システム

OLTPOLTPサービスレベルを強化するために、最適な可用性機能をマッピングする。

また、各データフローやプロセスの可用性を強化する機能のマッピングを検討する。強化が必要となるもの

に対して、どのような強化対策を取るかを明確にすること。ただし、この作業には具体的なハードウェアや

ソフトウェアに対する知識が必要となり、ある程度の実装されるシステム基盤を描きながら検討する必要が

ある。たとえば、可用性を向上させるためには、冗長化を行うことで実現できる。冗長化にはさまざまな機

能が存在するため、その業務機能の可用性を強化するためにはどのような冗長化機能を利用することができ

るのかを洗い出す。これらを明確にし、データモデルを修正する。また、それぞれに取るべき対策や許容停

止時間を記載しておく。



4.3.6. 運用・監視基盤モデルの作成

運用・監視基盤モデルとは

・システムの安定運用や各種動作監視を行う機能を実現するためのモデル

運用・監視基盤モデルの目的

・以下の機能のマッピングを行う・業務実行支援・システム保全・監視基盤

業務実行支援システム保全監視基盤

業務機能の実行・構築などを支援する機能

データの保護や退避、復旧などの機能

プラットフォームや業務機能、ミドルウェアなどの実行状況、資源などを監視

運用・監視基盤モデルとは、システムの安定運用や各種動作監視の実現を検討するためのシステムモデルを

いう。主に、業務を含めたシステム運用基盤と、稼動状況や業務実行状況の監視基盤の二つで構成される。

システム運用基盤とは、業務実行の支援を行うものと、障害などに対応するためのシステム保全を行うため

のものの 2つに分わかれる。業務実行の支援では、主に業務機能の実行・構築などを支援する機能がある。

データベースやミドルウェアはこれに含まれない。たとえば、ある業務処理を定められた時間に定期的に起

動する場合など、繰り返し操作が求められる場合に利用する。これにより、正確性と運用者の負荷が低減さ

れる。システム保全としては、データの保護や退避、復旧などの機能。たとえば、データのバックアップ・

リストアなど。これにより、システム障害に対する機能強化を行うことができる。監視基盤は、主にプラッ

トフォームや、業務アプリケーション、各種ミドルウェアなどの実行状況とその資源を監視するものをいう。

監視を行う目的は、正常にシステムが動作しているかどうかを常に把握し、システム管理者に通知する。あ

るいは、システム資源の利用状況を常に把握し、重大な問題が発生する前に対応に着手できるよう、支援す

るものになる。



運用・監視基盤の各機能をプロセスモデルにマッピングする

手入力

OLTP 処理1

データベース

エラー通知機能

バックアップ機能

資源監視機能

自動起動・終了機能

これまで作成したモデルと、品質要件などをインプットとし、これらの機能を各プロセスにマッピングして

行く。具体的には、以下のとおり実行する。

・各プロセスやデータに必要となる機能を洗い出す。

・それぞれに、必要となる運用・監視機能を割り当てる。

・割り当て後、プロセスやデータフローが新たに発生した場合、追加を行う。

これらにより、各プロセスに必要な運用・監視機能を明確にする。

4.4. システム基盤設計基本方針の設定

4.4.1. システム基盤設計基本方針の設定とは

作業計画

作業目標

スペシャリスト各種要件

各種モデリング

システム構成

スペシャリスト

スペシャリスト

作業における基礎情報

作業におけるスケジュールなど

ITアーキテクトは、これらの情報を伝え、計画や目標にしたがって作業をするよう、スペシャリストを指導する必要がある



システムモデルの作成が完了した段階で、設計すべきシステムが明確にすることができる。これ以降は、IT

スペシャリストによるシステム設計・導入作業となり、ITアーキテクトが直接行う作業ではなくなる。しか

しながら、そのシステムに対する設計・導入作業に対する作業計画や方針・目標の設定を行わなければなら

ない。それは、要求されている要件を実現するために重要であり、それはこれまでの検討を行った ITアー

キテクトが最もよく理解しているためである。このフェーズでは、以降の設計作業の計画、および指針とな

る目標を設定する。ITアーキテクトは、これまで作成した要件やモデリング結果などを基礎情報とし、作業

計画や目標にしたがって作業を進めるよう、スペシャリストを指導する必要がある。

4.4.2. サービスレベルの設定

サービスレベルとは、構築されたシステムが実現されているべき各種指標をいう。これは、以降の設計・構

築作業における指針となり、また、システムが稼動状態になった場合のサポートなどの条件となるもの。主

な指標の一例は、以下のとおり。

・サービスの稼働率

・システム障害時のサービス回復時間

・オンライン業務のレスポンス

通常、主に、パフォーマンス、運用面で定義されることがほとんどである。SLA(Service Level Agreement)

とは、このサービスレベルの実現と維持を、契約をもって実施するものであり、特に社会インフラのシステ

ムなどで交わされる。SLAの契約では、設定されたサービスレベルを実現できなかった場合ペナルティが課

せられることがあり、厳守することが要求される。サービスレベルは、通常要件として明確になる項目であ

る(品質要件など)。これらを実現すべくモデリングを行うが、要件の変更(規模の変更、機能の変更など)など

があると、変わることがある。また、大体においてモデリング作業は机上で行われ、しかも時間などの制約

からすべての要素において定義されないことがある。この場合、実際に設計を行い実在のシステムに実装す

ると、モデリングのとおりでは要件を満たせないことが出てくることがある。このような場合には、サービ

スレベルの見直しを実施するかどうか、プロジェクト内でよく議論し検討しておく必要がある。サービスレ

ベルは、設計・導入作業の契約に含まれることがあり、変更の次第によってはスケジュールやコストが変動

する可能性があるためである。



4.4.3. システム基盤計画の作成

システム基盤計画とは

・設計、構築作業における作業計画・以降の作業での作業項目と計画になる・作業は、この計画に従って進捗しなければならない

作業タスクとWBS

作成アウトプット

作業スケジュールとマイルストーン

要員計画

プロジェクトマネージャITアーキテクト

作成全体計画作成

全体プロジェクト計画

これらは、プロジェクトマネージャのインプットとなる。

設計・構築作業における、作業計画を立案する。これは、以降の作業での作業項目となり、この計画に沿っ

て作業を進める。また、この計画は、そのまま進捗管理にも利用される。作成された作業計画は、プロジェ

クトマネージャに提出し、全体の開発スケジュールに組み込まれることになる。作業計画には、以下が盛り

込まれている必要がある。

(1)作業タスクとWBS

(2)作成アウトプット

(3)作業スケジュールとマイルストーンの設定

(4)要員計画

(1)は、作業を行うタスクと、そのタスクの詳細なWBSを明確にする。

(2)は、各タスクで作成・納品すべきアウトプットを明確にする。アウトプットは、通常各種ドキュメント

類となっている。

(3)は、タスクやWBSをスケジュールとして作成する。また、目標とするマイルストーンを設定する。通

常、これは(2)のアウトプットの納品日など。

(4)は、各タスクやWBSを実行する要員を明確にする。各メンバの要求されるスキルレベル、要員数など

を盛り込む。


Ⅱ-ⅰ ３ＩＴアーキテクチャ構築技法 1

Ⅱ-ⅰ ３ＩＴアーキテクチャ設計技法

// CONTENTS //

１．アーキテクチャ設計概論...............................................................................................................................................3

1.1.アーキテクチャ設計の目的 ...........................................................................................................................................3

1.2.アーキテクチャ設計のタイミング ............................................................................................................................3

1.3.アーキテクチャ設計の基本的枠組み .......................................................................................................................4

1.4.プロダクトラインのアーキテクチャ .......................................................................................................................5

２．アーキテクチャ設計手法の例 ................................................................................................................................................5

2.1.アーキテクチャ設計のプロセス .................................................................................................................................5

2.1.1.アーキテクチャ要求の引き出し..................................................................................................................6

2.1.2.アーキテクチャの設計......................................................................................................................................8

2.1.3.アーキテクチャの文書化.............................................................................................................................. 11

2.1.4.アーキテクチャの分析................................................................................................................................... 12

2.1.5.アーキテクチャの実現................................................................................................................................... 13

2.1.6.アーキテクチャの保守................................................................................................................................... 14

2.2.プロダクトラインアーキテクチャの設計 .......................................................................................................... 15

2..2.1.プロダクトラインアーキテクチャの設計.......................................................................................... 16

2.2.2.機能ベースのアーキテクチャ設計.......................................................................................................... 17

2.2.3.アーキテクチャの評価................................................................................................................................... 18

2.2.4.アーキテクチャの変換................................................................................................................................... 18

2.2.5.プロダクトラインアーキテクチャの成果物...................................................................................... 19

2.2.6.ファミリーベースのシステム開発.......................................................................................................... 20

2.2.7.プロダクトライン資産の発展.................................................................................................................... 21

2.2.8.プロダクトラインのための組織構成..................................................................................................... 22

３．アーキテクチャ設計方法論の例 ........................................................................................................................................ 23

3.1.IBM SOMA（Service-oriented Modeling Method and Architecture） ........................... 23

3.1.1.SOMAのコンセプト..................................................................................................................................... 23



3.1.2.SOMAのアクティビティ........................................................................................................................... 24

3.1.3.SOMAの成果物............................................................................................................................................... 26

3.2.Microsoft Motion ......................................................................................................................................................... 26

3.2.1.Motionのコンセプト .................................................................................................................................... 26

3.2.2.ケーパビリティモデル................................................................................................................................... 27

3.2.3.Motionのプロセス ......................................................................................................................................... 28

3.2.4.Motionの成果物.............................................................................................................................................. 29

４．アーキテクチャ設計に役立つパターン例 .................................................................................................................... 29

4.1.Patterns of Enterprise Application Architecture ............................................................................. 29

4.2.Enterprise Integration Patterns ...................................................................................................................... 31

５．出典・参考文献 ........................................................................................................................................................................... 33



１．アーキテクチャ設計概論

1.1.アーキテクチャ設計の目的

アーキテクチャ構築はソフトウェア開発プロセスの重要な局面の１つである。特に現在のソフトウェア開

発は大規模化、短納期化、長寿命化の流れを受けて、アーキテクチャ設計を意識しなければならない局面が増

えてきた。ソフトウェア開発においても、アーキテクチャ設計は同一システムにおいては将来の修正や拡張を、

また異なるシステムにおいて、アーキテクチャを転用したりアーキテクチャ上に展開される様々なソフトウェ

ア群を構築することを意識する場合には必須のものと言える。

アーキテクチャ設計が重要である理由は以下の３つである（参考文献[1]より）。

１．ステークホルダ間のコミュニケーション手段－システムに関する相互理解、交渉、コンセンサス、

コミュニケーションの基礎となる。

２．初期の設計上の意思決定－実装上の制約の定義、組織構造の決定、システムの品質属性の実現性、

システム品質の予測、変化の予測および管理、コストとスケジュールの見積もりなどに対して重要な役

割を担う。

３．転用かつ再利用可能なモデル－設計上の選択肢の限定、テンプレートベースの開発、同様の品質特

性と機能要求を持つ他システムへの転用などを通じて、大規模な再利用性を促進する。

1.2.アーキテクチャ設計のタイミング

アーキテクチャ設計をいつ始めるかを決定するうえでまず考慮すべきなのは、ソフトウェア開発ライ

フサイクルのなかでの位置づけである。

参考として、ソフトウェア開発ライフサイクルにおけるアーキテクチャ構築の位置づけの図を以下に示す。



図 1-1 発展的配布ライフサイクル（出所：参考文献[1]）

上の図からアーキテクチャ設計の前に要求分析がなされることが理解できる。アーキテクチャは機能

要求、品質要求（または非機能要求）、ビジネス要求、およびアーキテクトの専門性と経験から方向づ

けられる。これらの要求をこれを「アーキテクチャドライバ（architechtural driver）」と呼ぶ。

アーキテクチャドライバを定義するには、まず最も重要なビジネス目標（goal）を特定する。それらは

比較的少数である。次にそれらをシナリオもしくはユースケースに落とす。最後にアーキテクチャに最

もインパクトを与えるもの、すなわちアーキテクチャドライバを選択する。その数は10個以下である

べきである。

1.3.アーキテクチャ設計の基本的枠組み

以下に参考文献[6]に基づきアーキテクチャ設計の基本的枠組みを示す：

図 1-2 アーキテクチャ設計の基本的枠組み（出所：参考文献[6]）

設計方針の明確化－要求の整理などアーキテクチャを検討する際のスコープや、設計判断を行う際に

必要となる価値基準を明確化する。



要求の整理－想定されるスコープに含まれるソフトウェアに対する要求事項を整理し、アーキテクチ

ャに対する要求として整理する。同様に基盤に対する想定もここで整理する。

アーキテクチャの設計－整理された要求に基づき、アーキテクチャスタイルなどを活用しながら、アー

キテクチャを検討・定義する。

アーキテクチャの評価－定義されたアーキテクチャを要求などと照らしながら評価し、評価結果をフ

ィードバックする。

上図で示した枠組みは、単体のアプリケーション設計のプロセスと類似した点も多いが、アーキテク

チャの場合は複数のアプリケーションの共通基盤となるために、まだ開発されていないソフトウェアの

想定や、品質特性を意識して将来の修正や拡張に備える必要性が強いといえる。

1.4.プロダクトラインのアーキテクチャ

更にアーキテクチャのほうに注目してソフトウェアの再利用性を高めようとするのが、プロダクトラ

インアーキテクチャの基本コンセプトである。プロダクトラインアーキテクチャでは、共通の特性を持

つ、特定のドメイン（問題領域、とも呼ばれる）向けに開発されるソフトウェアの集合であるが、共通

の再利用資産を戦略的かつ体系的に利用してシステム開発を進めることで、通常のアーキテクチャ設計

を通じてよりも高いソフトウェア開発生産性を実現する。米国カーネギーメロン大学ソフトウェア工学

研究所（CMU/SEI）を中心になお活発な研究、実践例が報告されているが、その多くは組み込み系ソ

フトウェアの分野であり、業務アプリケーションの分野は比較的発展途上の感がある。

２．アーキテクチャ設計手法の例

本節では、アーキテクチャ設計のプロセスの例として、CMU/SEI のArchitecture-Based

Development を、プロダクトラインアーキテクチャの設計手法の例として、Bosch法を取り上げて説

明する。本章で使われている概念や表現などは参考文献[2]と[3]に基づくものである。

2.1.アーキテクチャ設計のプロセス

Architecture-Based Development（ABD）は、Len Bass、Rick Kazmanが書いたテクニカル

レポートに詳しい説明があるが、特徴として特定の基盤技術から独立した概念的アーキテクチャを設計

するためのプロセスを示し、各ステップごとに、インプット、発展的アクティビティ、検証アクティビ

ティ、アウトプットが明示されている。このレポートにはプロセス全体が以下のように示されている。



図 2-1 ABD法のプロセス（出所：参考文献[2]）

2.1.1.アーキテクチャ要求の引き出し

アーキテクチャ要求の引き出しにおけるインプットとアウトプットは以下の図のようになる。

図 2-2 アーキテクチャ要求の引き出し（出所：参考文献[2]）

本ステップでは、開発組織によってアーキテクチャ要求が作成される。要求は技術面の環境とアーキ

テクト自身の経験によって影響を受ける。本ステップでは3種類の成果物が生み出される：

1. ユースケースにより明確になる機能要求の一覧

2. 特定のアーキテクチャ要求の一覧

3. アーキテクチャ要求のテストのための品質シナリオの一覧

アーキテクチャ要求においては、始めにいくつかの「アーキテクチャドライバ」を識別し、次にアー

キテクチャ要求を列挙する。要求はアーキテクチャドライバの影響を列挙したものであり、他の重要な

アーキテクチャ要求をもたらす。



アーキテクチャ要求は以下の３つより導き出される：

1. システムの品質ゴール

2. システムのビジネスゴール

3. システムを利用する人々のビジネスゴール

アーキテクチャ要求は機能要求に比べるとそれほど多くはない。最大でも約20個くらいであるべき

である。

2.1.1.1.品質シナリオ

設計プロセスは、システムのアーキテクチャ要求は動作に関する要求に劣らず重要であり、共にシナ

リオもしくはユースケースから具体化してゆく。プロダクトラインでは抽象的なシナリオに基づき動作

に関する要求を記述する。品質ベースのアーキテクチャ要求では品質特化のシナリオで表現される。品

質特化のシナリオとは修正に備えての変更、セキュリティにおける脅威、性能に関する応答時間、およ

び信頼性や可用性に関するエラー処理やデグレードのシナリオである。ただし、品質特定のシナリオも

他の多くの品質に影響を及ぼす。また、要求は多くのステークホルダから挙げられるため、シナリオに

おいてそれぞれの関心事を反映せねばならない。さらにシナリオの中には暗黙的な品質要求（保守容易

性、性能、セキュリティ、修正容易性、可用性など）を持っているものもある。このような要求を正し

く捉え、アーキテクチャを充足させるための枠組みとして、以下のようなマトリクスを使いカバレージ

を満たしているかどうか検討する。

図 2-3 シナリオ導出マトリクス（出所：参考文献[2]）



品質特定のシナリオはまず設計フェーズで検討される可能性があるが、分析フェーズにおいて他の品

質に対する影響を検討するのも重要である。

2.1.1.2.抽象シナリオ

プロダクトラインを検討するにあたっては、単一システムのためのアーキテクチャと違い、意図的に

特定性（プラットフォーム、動作環境、など）を無視し一般的な要求を定義することでシステム系列に

おける可変性を実現する。シナリオを抽象化して、システム特定のシナリオは適切なパラメータから導

出する。

2.1.1.3.品質特定シナリオ

プロダクトラインのための品質要求は品質シナリオにおいて具体化される。一般的に品質は設計にお

いて直接適用するには抽象的すぎるので、品質特定のシナリオを表現することにより具体化する。ただ

し、最初に考慮される特定の品質は、修正容易性、性能、セキュリティ、信頼性の４つである。

2.1.1.4 検証

一連のシナリオの検証は、以下を通じて遂行される：

■多くのステークホルダとのシナリオに対するブレーンストーミングを行う。

■シナリオをアーキテクチャ要求にマッピングし、カバレージを裏付けるためにシステムにおけるビジ

ネス及びユーザーのゴールにマッピングする。

続いて、シナリオはアーキテクチャ設計のための検証プロセスにおいて利用される。

2.1.2.アーキテクチャの設計

アーキテクチャの設計におけるインプットとアウトプットは以下の図のようになる。

図 2-4 アーキテクチャの設計（出所：参考文献[2]）



アーキテクトは一連のデザイン上の意思決定を行うことにより設計を行い、様々なアーキテクチャ構

造とビューの考慮を通じて判断を下す。アーキテクチャ要求はデザイン上の意思決定を動機付け、正当

性を評価するために利用され、様々なビューは品質上のゴールを達成するために情報の妥当性を表現す

るために利用される。そして品質上のシナリオはデザイン上の意思決定について推論し検証するために

利用される。デザイン上の意思決定はしばしばアーキテクチャスタイル、パターン、特定のツール（ソ

ケット、RPC、CORBA、など）の知識により開始される。以下の図はアーキテクチャ設計のステップ

を抽象化したものである。

アーキテクチャ設計はいくつかの意思決定を伴う反復プロセスであり、設計の完了に達するまで再考、

改定される。

2.1.2.1.アーキテクチャ構造とビュー

ソフトウェアアーキテクチャにおける構造は関係により接続されるノードである。ノードは「コンポ

ーネント」と呼ばれ、関係は「コネクタ」と呼ばれる。これらコンポーネントとコネクタは「プロパテ

ィ」と呼ばれる他の情報により注釈付けされる。

アーキテクチャ構造はアーキテクチャ情報の基礎的な表現であり、基礎的な成果物（クラス、関数、

オブジェクト、ファイル、ライブラリ、など）を表現する。

ビューは導出された表現であり、構造のサブセットを選択し、複数の構造から融合された情報により

達成される。

潜在的に興味深いソフトウェア構造は多くあるが、アーキテクチャを完全に記述する５つの規範的ある

いは基礎的構造が存在する：

1. 機能的構造－システムがサポートする必要のある機能の分解に関係がある。コンポーネントは機能的

（ドメイン）エンティティであり、コネクタでデータを利用するか転送する。この構造は問題空間にお

けるエンティティ間の相互作用を理解し、機能性を計画し、ドメインの可変性を理解するのに有効であ

り、その結果プロダクトライン構築の実現性にも有効である。

2. コード構造－重要なコード抽象化の実現に関係がある。コンポーネントはパッケージ、クラス、オブ

ジェクト、プロシージャ、関数、メソッドなど抽象化の様々なレベルにおいて機能をパッケージ化する

媒体である。この構造はシステムの保守容易性、修正容易性、再利用性、ポータビリティを理解するた

めに重要である。

3. 並行性構造－論理的な並行性に関心がある。この構造は性能の理解のカギであり、信頼性とセキュリ

ティにおいても重要である。

4. 物理構造－CPU、メモリ、バス、ネットワーク、I/Oデバイスを含むハードウェアに関係がある。こ



の構造は可用性、キャパシティ、帯域幅に関連がある。

5. 開発構造－ファイルとディレクトリに関係がある。この構造は開発が進み具体化する（作業をチーム

と構成管理に分割することも含む）につれ、システムの管理制御が重要になる。アーキテクトが複数の

ビューを同時に利用するのは、それぞれのビューがある情報を表し、他の情報を隠蔽するからである。

2.1.2.2.開発プロセス

開発の文脈により適切な開発プロセスが決定される。もし開発するシステムが既存のシステムからの

派生ならば開発プロセスは既存システムのビューが適切であるという前提がある。しかし、本セクショ

ンでは新規開発のためのプロセスを扱う。つまり、開発されるシステムは既存のコンポーネントの制約

を受けないという前提である。

まずアーキテクチャ要求の一覧と機能要求から派生した機能性のクラス一覧があるという前提から始

める。最初のステップのゴールは候補となるサブシステムの一覧を開発することである。機能要求から

派生した機能のクラスはすべてが候補となるサブシステムになる。他の候補となるサブシステムはアー

キテクチャ要求から派生する。そしてそれぞれのアーキテクチャ要求においてその要求を満たすアーキ

テクチャ選択を列挙する。これらの選択はデザインパターン、アーキテクチャスタイル、アーキテクト

自身の経験によって列挙される。この可能性のある選択肢から、すべてのアーキテクチャ要求が潜在的

に満たされ、選択肢の一覧が一貫して、一覧の項目の数が最低限になるように選択が行われる。選択肢

が少なければコンポーネントも少なく、実装と保守の負担も軽くなり、一般的に障害の可能性も少なく

なる。

次のステップはサブシステムの選択である。それぞれの候補となるサブシステムは実際のサブシステ

ム、より大きなサブシステム内のコンポーネント、あるいは実際のサブシステムによって利用されるパ

ターンとしてカテゴライズされる。それから、機能構造における実際のサブシステムを記録する。

実際のサブシステムに一覧が作成されたら、次のステップは並行性構造を作成する。この構造は分散

の単位とサブシステムに対する並行処理の単位について推論することで作成される。並行処理の単位は

スレッドとサブシステム内のスレッドの同期を推論することによって定義される。ここでいうスレッド

とは単一プロセッサにおける「仮想スレッド」である。物理構造を考慮する際に、仮想スレッドを物理

スレッドに変換する箇所と、この変換から派生するネットワークのメッセージを定義することが可能で

ある。

最後のステップはサブシステムと並行性の振る舞いを定義することである。このステップはその後検

証され、サブシステムは洗練化され、再び並行性の振る舞いが定義され、他の構造が作成される。検証

のステップは再び意思決定を引き起こす可能性があるので、実際のプロセスにおいて意思決定と検証の

間には非常に反復性が高い。

2.1.2.3.検証

品質シナリオは最初の検証メカニズムとして利用される。構造の案が、現レベルの設計において品質

シナリオを満たすかどうかを検討する。もし満たすのであれば、設計の次の洗練化に向けて進み、そう

でなければ現レベルの設計の洗練化が再び考慮される。

アーキテクチャが設計されたら、開発者の外部にいるグループによってアーキテクチャの評価を実施



することが有効である。外部による分析によって設計プロセスの結果が管理者側に見えるようになり、

アーキテクチャの文書化を強く促すことになる。

2.1.3.アーキテクチャの文書化

アーキテクチャの文書化におけるインプットとアウトプットは以下の図のようになる。

図 2-5 アーキテクチャの文書化（出所：参考文献[2]）

アーキテクチャの文書化はプログラマとアナリストのニーズをサポートする。それはステークホルダ

間のコミュニケーションを促進し、ステークホルダからアーキテクチャ要求を引き出す非常に有効な媒

体となりうる。以下の図のようにアーキテクチャ文書の作成と保守はソフトウェアアーキテクチャの長

寿命化において重要な成功要因である。

ソフトウェアアーキテクチャの文書化のための主な推奨事項は以下の通りである：

■文書は完全で情報が追跡可能であるべきである－ある程度ドメインの知識があるが、本アーキテクチ

ャに対する予備知識がない熟練のソフトウェアエンジニアが文書を読んで理解し、必要な情報を見つけ

られるべきである。これらの情報が開始点であるべきであり、相互接続されるサブシステムの集まりと

してシステムを表現するべきである。サブシステムには名前がつけられ、責務と機能が定義され、それ

ぞれの相互接続の本質が定義されているべきである。

この時点で文書は詳細についてあらゆる側面で完全とは言えない場合が多い。しかしながらコンセプ

ト、トップレベルの構造、重要な低レベルの詳細は完全であるべきである。

このことは文書がサブシステムについて内部でどのように密接に関係しているかとともに、様々なサ

ブシステムが相互に関係しているという“big-picture”参照アーキテクチャとして表現されなければな

らないことを意味している。

■アーキテクチャの不可欠な部分としてインフラストラクチャが文書化されていなければならない－ソ

フトウェアアーキテクチャがプロダクトラインのためのものであるなら、インフラストラクチャは不変

なもの（ただし、インフラストラクチャの上に乗る機能は将来変更されうる）であり、特定の機能が決

定されたらシステムの品質属性が予測し、測定し、裏付ける手段を提供する。

またインフラストラクチャはすべてのサブシステムから再利用されるため、メッセージシーケンス図

などからは論理データと制御フローについて十分知ることはできない。インフラストラクチャの利用を



通じて、どのようにこれらの論理関係が実現されているか理解する必要がある。

■アーキテクチャ文書の一部として、多くのユースケースが十分な詳細度でアーキテクチャ表現にマッ

ピングされなければならない－ソフトウェアエンジニアが機能（インフラストラクチャのコンポーネン

トを通じた処理、データフロー、制御フローという点で）を実装する方法が理解できる程度の詳細度が

必要である。これらのシナリオにはシステムの主な利用方法が表現され、多くのアプリケーションのニ

ーズを満たす少数のインフラストラクチャのコンポーネントから得られる効力を明示することになる。

■アーキテクチャと対象システムにおけるその利用は、通信や、データ配布、時間管理、その他のイン

フラストラクチャのサービスのためのリソースの管理のためのメカニズムに対して、一連の制約によっ

て縛られなければならない－インフラストラクチャにおいては前もってアプリケーションフレームワー

クを特化しておき、前もって最低限の通信メカニズムを特化しておくべきである。一貫した一連の設計

制約がなければ、代替案が要求された性能向上を提供するかどうか決定するためのシステム品質を測定

するのが困難である。

■すべての文書はすべてのステークホルダに公開されるべきである。

2.1.4.アーキテクチャの分析

アーキテクチャの分析におけるインプットとアウトプットは以下の図のようになる。

図 2-6 アーキテクチャの分析（出所：参考文献[2]）

設計、文書化、「小規模な」アーキテクチャの分析は主要なアーキテクチャに関する意思決定が行わ

れるまで反復される。この時点では主要なアーキテクチャ評価が外部のレビューアも関与させて実施さ

れるべきである。評価の目的は潜在的なリスクを定義するためにアーキテクチャを分析し、設計におい

て品質要求が扱われているかどうかを検証することである。

様々な種類とスタイルのアーキテクチャ評価手法がある。アーキテクチャの分析はアーキテクチャの

文書化を強く促し、リスクを早期に発見し、アーキテクチャを改善する利点がある。

2.1.4.1.アーキテクチャの評価

アーキテクチャの評価を実施するに際し、２つの論点が重要である、すなわち誰が評価に参加するか、

ということとどのように評価を実施するかレビューするという点である。



2.1.4.2.参加者

明らかにアーキテクトはいかなるアーキテクチャ評価においても参加者でなければならない。必要に

応じて設計チームのメンバーはアーキテクトをサポートするべきである。大規模なシステムにおいては

主要なサブシステムの設計リーダーは参加するべきであるし、できる限りテスト担当、保守担当、イン

テグレータ、システム管理者、エンドユーザー、顧客、管理者も参加するべきである。

評価チームは上述の参加者とは別に計画されなければならない。評価チームは公平で新鮮な観点が必

要なため開発チームの外部にあるべきである。アーキテクチャに関する専門性を持つ人々だけでなく、

システムのドメインに関する専門性を持つ人々もレビューに参加しなければならない。

そして、評価にはステークホルダの代表が含まれるべきである。レビューにおいてプロセスや要求に

おける課題を伴う場合がある。ステークホルダからのインプットはこれらの課題に対する適切な回答を

決定するのに不可欠である。なぜなら、評価チームがアプリケーションドメインのすべての詳細とすべ

てのビジネス課題について理解することを求めることはできないからである。これらの情報を得るため

にチームはステークホルダに頼ることになる。ステークホルダはアーキテクチャに影響を与えるかも知

れない要求や環境において、ありえる変更についての観点をももたらす。

2.1.4.3.評価テクニック

評価テクニックには質問ベースと、定量的な分析ベースの２つがある。

質問ベースのレビューは評価の間にもたらされるか、以前の経験に基づき質問もしくはシナリオの一

覧から実施される。また評価の間にステークホルダから他の質問をされる場合がある。

評価テクニックの第2のタイプが定量ベースであり、特定の属性とこれら属性のためのモデルの存在

の分析に基づくものである。例えば性能などが詳細に観察されるが、性能モデルの構築を可能とし、モ

デルについて知ることができ、モデルを裏付けるために必要な情報を導き出すことが可能な要求につい

て知ることができる、一連の情報が存在する。分析において有効なモデルを持つ他の属性には信頼性、

セキュリティ、活性（liveness）、到達可能性（reachability）がある。

具体的な評価テクニックとしてはATAM（Architecture Tradeoff Analysis Method）を参照のこ

と。

2.1.5.アーキテクチャの実現

アーキテクチャを実装する際に、有用なソフトウェア工学とプロジェクト管理の配慮のすべて（詳細

設計、実装、テスティング、構成管理、など）が取り入れられなければならない。しかしながら、アー

キテクチャベースの開発に特有なものの１つは組織の構造である。特に開発チームの組織構造はソフト

ウェアアーキテクチャに容易にマッピングされなければならない。



開発組織構造におけるアーキテクチャの影響は明白である。構築中のシステムのアーキテクチャにつ

いて合意がなされたら、チームは主要なコンポーネントに従事するために割り当てられ、それらのチー

ムを反映するWBSが作成される。

チーム内では濃密なコミュニケーションが必要とされる。詳細設計に関する意思決定において大量の

情報が継続的に共有される。チーム間においてはゆるやかなコミュニケーションで差し支えない（シス

テムの関心事が適切に分離されている場合）。もしチーム間の相互作用が複雑である必要があるなら、

チームが開発しているコンポーネント間の相互作用が必要以上に複雑であることを意味し、開発を開始

する前にそれらのコンポーネントのための要求が十分に固まっていなかったことを意味している。この

ような場合、チーム間でも濃密なコミュニケーションを必要とし、かなりの交渉が必要で、しばしばコ

ンポーネントとそのインターフェイスの改訂を必要とする。ソフトウェアシステムと同様、チームもゆ

るやかな結合と高い凝集性を目指すべきである。

2.1.6.アーキテクチャの保守

ソフトウェアアーキテクチャは同じにとどまらない。もし保守を行わなければアーキテクチャは必然

的に元々の指針からずれてゆく。これはリスクである。もしアーキテクチャが互いに一貫しないバラバ

ラな方法でずれてゆけば、元々のシステムにおいて注意深く設計され分析された品質属性の成果が危う

くなるであろう。

設計に対するアーキテクチャの一致を手作業にて査定するのは退屈で間違いを起こしやすい作業であ

る。１つのテクニックとしてはツールを使い、現行のアーキテクチャを抽出し、現行の設計されたシス

テムとの一致をチェックすることだが、以下のような様々な理由で容易なことではない：

■ソフトウェアアーキテクチャは実際にはほとんど文書化されていない。

■文書化されていても、あまり保守されていない。

■文書化されていても、あまり明瞭ではない。

多くのアーキテクチャに関する構成概念は、プログラマが実際に作成し保守する開発成果物という観

点からは具現化されていない。典型的なソースリポジトリのコードやヘッダファイルのどこにもレイヤ

やサブシステム、機能グループ、クラスカテゴリは存在しない。これらの概念は典型的にはアーキテク

トと精鋭プログラマの頭の中だけに存在し、概念から開発成果物へのマッピングはあまり明らかではな

い。従って、アーキテクチャの改造は一般的に「解釈的」側面があり、アーキテクトはアーキテクチャ

構成概念と、特定の名前付け規約、ファイルもしくはディレクトリ構造、もしくは構造制約とを関連付

ける。

再文書化よりも既存システムのソフトウェアアーキテクチャを抽出したい理由は他にも存在する：



■組織が既存システムのリエンジニアリングを望むかもしれず、リエンジニアリングのために、もしく

は既存資産が再利用に値するかどうか決定したくて、どの資産が現在稼動しているかを知る必要がある。

■組織が再利用可能なライブラリやプロダクトラインのコアを形成するために既存資産の採掘を望むか

もしれない。

■組織が将来の展望、成長の潜在性、他のシステムとの統合の適合性、スケーラビリティに関して既存

システムの分析を望むかもしれない。

抽出された情報はコード、ビルドファイル、実行トレース、計測の結果、ファイル構造、など広い範

囲に及ぶことがある。一般的にはこれは反復的で解釈的なプロセスである。パターンが定義され、抽出

された成果物に適用され、そしてアーキテクトによって考察され、場合によってはパターンの再定義を

もたらす。このようなパターンが定義され、適切に洗練化されれば、アーキテクチャを定義し、一致の

ために評価される現行のアーキテクチャに対する一連のルールとなる。

これらのルールは一般的には抽出された成果物に適用され、残りの例外部分はマニュアルもしくは自

動的に指摘される。この抽出と一致アクティビティの結果に基づき、以下の３つの結果がありうる：

1. 文書が既存のコードベースの現状を反映するように更新される。

2. コードベースが明確に定義されたアーキテクチャルールに一致させられる。

3. 例外部分が単純に例外として記録され、とりあえず何のアクションも取られない。

どの選択がなされても、結果として理解は進み従ってシステムとその利用に対して知的な制御が利く

ようになる。それ故にこのアクティビティはアーキテクチャライフサイクルの完全なビューという点に

おいて不可欠なステップである。アーキテクチャは他のシステム資産が保守されるのと同様に文書化さ

れ保守されなければならない。

2.2.プロダクトラインアーキテクチャの設計

ソフトウェアプロダクトラインはソフトウェアの再利用性を高め、品質を上げ、保守コストを下げる

ための、最も有望なアプローチの１つである。従来の再利用アプローチはサードパーティ製のコンポー

ネントを再利用することを前提としていたが、普及したとは言いがたい。ソフトウェアプロダクトライ

ンのアプローチは、組織をまたがるソフトウェア資産の再利用を主張し、様々な組織で成功例が報告さ

れている。

ソフトウェアプロダクトラインのアプローチには以下の３つの次元が存在する：

1. 資産の次元－プロダクトラインはソフトウェアアーキテクチャ、再利用可能なコンポーネント、再利



用可能なプロダクトの点から記述される。

2. プロダクトラインについての様々なビュー－これらのビューにはビジネスビュー、組織ビュー、プロ

セスビュー、技術ビューが含まれる。

3. プロダクトラインの主要なフェーズ－初期の開発、配置、進化。

プロダクトラインのアプローチは製品開発を行っている組織にとりわけ適用されてきたが、基礎をなす

概念の適用可能性は単なる製品より広範囲に及ぶ。ソフトウェアに関するコンサルタント組織や大きな

組織の IT部門であっても、アイデア自体は利益をもたらすものである。

本節は特にプロダクトラインアーキテクチャの設計について紹介する。

以下はプロダクトラインアーキテクチャの設計に関するおおまかなステップである。

■ビジネスケース分析－十分確かなレベルでプロダクトラインアプローチが費用対効果が高く、優れた

アプローチかを立証する。さらにプロダクトベースからプロダクトラインベースに変更するために革新

的な方針で進めるか、漸進的な方針で進めるかについて決定するための分析を行う。

■適用範囲の決定（Scoping）－プロダクトラインに含まれるプロダクトとプロダクトの特性

（features）を決定する。プロダクトラインにすべてのプロダクトと特性を含めるのは有益でも望まし

いものでもない可能性がある（特に最初からは）。

■プロダクトと特性のプランニング－プロダクトラインアーキテクチャの次のバージョンの特徴を定義

することに注力する。特性とプロダクトの保守や新規開発の観点からプロダクトラインアーキテクチャ

は継続する開発であるため、特性の結合について計画しておくことは重要である。

■プロダクトラインアーキテクチャの設計－プロダクトラインのためのソフトウェアアーキテクチャの

設計としてプロセスの中で主要なステップである。

■コンポーネント要求の仕様化－要求される振る舞いを実装するコンポーネントをソフトウェアアーキ

テクチャから決定する。それぞれのコンポーネントの要求を明記する。要求の仕様化では、それぞれの

コンポーネントがサポートするインターフェイス、機能性、品質属性と可変性を定義する。

■検証－コンポーネント開発など次のアクティビティに入る前にプロダクトラインアーキテクチャがス

テークホルダによって特定された要求をサポートしているか検証する。ステークホルダのミーティング

か、外部の評価を実施するアーキテクチャ評価チームによって立証する。

2..2.1.プロダクトラインアーキテクチャの設計

プロダクトラインで定義されたソフトウェアアーキテクチャは、ファミリのなかでは”as-is”で利用

できる。プロダクト間の実装の違いはコンポーネントの可変性を利用して表現する。プロダクトライン



アーキテクチャはプロダクトアーキテクチャの一部もしくはコアとして利用されるのみである。

プロダクトラインのためのソフトウェアアーキテクチャの設計と個別プロダクトのアーキテクチャの

設計との違いは、プロダクトラインアーキテクチャを設計している時でさえプロダクト特定の特性を考

慮する必要があることである。もしプロダクト特定の特性が考慮されなかったら、一般にプロダクトラ

インアーキテクチャのための設計上の意思決定が必要な品質属性において、特定のプロダクトの特性を

実装することができない結果となる。以下はソフトウェアアーキテクチャ設計のプロダクトライン特定

の側面について概説する。

2.2.2.機能ベースのアーキテクチャ設計

機能ベースのアーキテクチャ設計は、プロダクトの文脈の定義、アーキタイプの識別、プロダクトの

インスタンス化の記述、からなる。

■プロダクトの文脈の定義－プロダクトラインの一部であるプロダクトは文脈、基礎をなすハードウェ

ア、連携する外部のプロダクト、ユーザーインターフェイスの点から多様でありうる。プロダクトライ

ンのメンバーであるプロダクトの文脈はプロダクト全体として必ずしも特化されていない。むしろ多く

の場合サポートされる文脈で個々のプロダクトは区別される。いくつかのプロダクトの文脈の側面は根

本的なものであり、最初からプロダクトラインアーキテクチャにおいて対処されなければプロダクト全

体に渡って影響を及ぼす。他の側面は高度にモジュール化され、全体としてアーキテクチャについての

影響は最低限であり、その文脈をカバーする特定のプロダクトのために対処することができる。一般的

には様々なプロダクトの文脈はすべてが組み入れられているというより、むしろプロダクトのサブセッ

トが組み入れられている。適切なアプローチとしては側面を除外するのがどれくらい困難かあるいは易

しいか、およびその側面がプロダクトラインから除外された場合に再現の処理にどれくらいのオーバー

ヘッドがかかるかによることは明らかである。別のアプローチとしてはプロダクトファミリの階層を定

義することで、より多くのプロダクトをカバーするがより少ない特性しかカバーしない高レベル、およ

びより少ないプロダクトしかカバーしないがより多くの特性をサポートする低レベルの両方が含まれる。

■アーキタイプの識別－アーキタイプはソフトウェアアーキテクチャのモデリングとプロダクトのイン

スタンス化の記述に利用されるコアコンセプトを表現したものである。またアーキタイプはプロダクト

ラインが定義され、コンポーネントの基本コンセプトがアーキタイプのインスタンスの点から定義され

ることについてコアとなる抽象化を行う。プロダクトラインの特性の総計と比較したプロダクト特定の

特性の総計により、プロダクトラインのアーキタイプに加えプロダクト特定のアーキタイプも識別する

必要がありうる。いったんアーキタイプが選択されれば、アーキタイプ間の関係が定義される必要があ

る。

■プロダクトのインスタンス化の記述－本ステップのゴールは選択されたアーキタイプの適合性とプロ

ダクトのすべてのバリエーションを表わす現在のアーキテクチャの能力とを検証することである。した

がってプロダクトのインスタンス化の記述には極端な場合すべてのプロダクトをカバーする必要がある。

最後にプロダクトのインスタンス化の記述には適用範囲の決定の後に残された特性間のコンフリクトを



検討し取り組むという効果がある。

2.2.3.アーキテクチャの評価

アーキテクチャ評価には３つのテクニックが確認されている：シナリオの利用、シミュレーション、

そして数学的モデルである。プロダクトラインアーキテクチャは目的の文脈（ハードウェア、ネットワ

ーク、他の通信プロダクト、ユーザーインターフェイスなど）で評価する必要がある。品質要求に対す

るプロダクトラインアーキテクチャの評価は、機能ベースのアーキテクチャ設計のあいだに開発された

プロダクトの各インスタンスを評価するという正攻法のアプローチがある。ただし、評価の実施は高価

で時間のかかるアクティビティであり、プロダクトラインの各メンバーに対して評価プロセスを繰り返

すのは一般的に費用対効果がよくない。そこで２つの代替案として、リファレンスとなる文脈の利用と

プロダクトの評価がある。

リファレンスとなる文脈では、ハードウェア、通信の帯域幅、プロダクトと通信する多くのデバイス

に関する不変性を提供する。リファレンスとなるプロダクトも定義されるが、かならずしもプロダクト

ラインの実際のメンバーでなくてもよく、むしろプロダクトラインで存在している重要な特性を含んで

いるべきである。

もう１つのプロダクトの評価という代替案は、プロダクトラインのなかのプロダクト群のサブセット

を評価するものである。典型的には両極端のプロダクトが選択される。ファミリの一部である現状のプ

ロダクトの特性と品質要求が満たされたら、次の重要なアクティビティは将来の特性とプロダクトを含

めるためのプロダクトラインアーキテクチャの評価である。

2.2.4.アーキテクチャの変換

アーキテクチャ変換はソフトウェアアーキテクチャの品質属性を改善することに関係する。これには

４つの種類のアーキテクチャ変換がある：アーキテクチャスタイルを課す、アーキテクチャパターンを

課す、デザインパターンを適用する、そして品質要求から機能へ変換する、である。アーキテクチャの

品質要求を満たすために変換テクニックを組み合わせる場合もよくある。プロダクトラインアーキテク

チャの変換には以下の３つの側面を成し遂げる必要がある。

1. バリアント（Variants）－アーキテクチャパターンのように、アーキテクチャソリューションがプ

ロダクトラインのすべてのメンバーの要求を満たせない場合がある。代わりにプロダクトラインのサブ

セットに対して、２つ以上のソリューションを利用する必要がある。バリアントをサポートする典型的

な変換にはレイヤスタイルやブローカーアーキテクチャパターンがある。ソフトウェアの構成要素の不

変部分と変更部分の結合度を減らすために、多くのデザインパターンが利用できる。

2. 選択性（Optionality）－プロダクトラインにおけるいくつかのプロダクトのために、ある種のコン

ポーネントが除かれる。アーキテクチャ変換ではオプショナルなコンポーネントの依存性を減らす必要

がありうる。選択性をサポートする典型的な変換は“blackborad”アーキテクチャスタイルである。

なぜなら、コンポーネントはblackboardのみに依存し他のプロセスには依存しないからである。また



proxy パターンのようにアクセスをコントロールするためのプレースホルダを提供するものや、

strategy パターンのように異なる文脈で異なる振る舞いをコンポーネントにさせるデザインパターンも

含まれる。

3. コンフリクト（Conflict）－コンポーネントとプロダクトラインアーキテクチャの一部にコンフリク

トが発生し、特定のプロダクトに関する要求を満たす必要のある、プロダクトラインとプロダクト特定

のコンポーネントの最も重要なメンバーを最適化する必要がありうる。他のコンフリクトの元としては

プロダクトラインアーキテクチャに一致するよう設計されていないレガシーソフトウェアやサードパー

ティのソフトウェアの結合がある。もしプロダクトラインアーキテクチャでコンフリクトが処理される

なら、不一致や他のコンフリクトを処理するために変換が必要とされる。プロダクトラインとレガシー

もしくはサードパーティのソフトウェアの間にアーキテクチャの不一致が存在していても、不一致を解

消するためにアーキテクチャスタイルやアーキテクチャパターンを適用することは一般的に適切ではな

い。一般的にはデザインパターンのような小規模なソリューションをコンフリクトが発生している具体

的な箇所に適用する必要がある。コンフリクトを解消するために有効なデザインパターンの例としては、

adapter、proxy、mediator がある。

2.2.5.プロダクトラインアーキテクチャの成果物

以上のようなプロセスを通じて以下の図のように様々な成果物が開発される。

図 2-7 プロダクトラインアーキテクチャの成果物（出所：参考文献[3]）

成果物は２つのカテゴリに分けられる。すなわち、プロダクトメンバーによって共有される成果物と、

プロダクト特定の成果物である。

共有の成果物は、「ビジネスケース分析の結果」、「プロダクトライン要求」、および「特性グラ

フ」から構成される。それらに加え、「プロダクトラインアーキテクチャ」には、1つ以上の「参照コ



ンテキスト」と「コンポーネント」と「関係」に関する「構造」が、コンポーネント開発の結果である

「アーキテクチャコンポーネント」には「可変性」を含んだ「要求」と、どのようなプロダクトに適し

ているかを記述する「特徴」を含む「コンポーネント実装」が含まれる。

プロダクト特定の成果物は、プロダクト要求とプロダクト特性グラフから構成される。それらに加え、

プロダクトラインアーキテクチャから派生したプロダクトアーキテクチャが含まれる。そのアーキテク

チャに基づき、インスタンス化されたプロダクトラインコンポーネントはプロダクト特定の拡張で設定

され、プロダクト特定のコンポーネントがある。最終的にプロダクト統合コードと、パッケージ化とプ

ロダクトリリースによってプロダクト特定の成果物が生み出される。

2.2.6.ファミリーベースのシステム開発

ここではソフトウェアプロダクトラインにおける、再利用可能な資産に基づくプロダクト開発につい

て概説する。開発のフェーズは７つのステップから構成される。

1. 要求仕様の作成－プロダクトラインアーキテクチャの設計のあいだに特定されたプロダクトの要求に

おいても、組織上と期間の理由から一般的には要求定義の再反復が必要とされる。

2. プロダクトアーキテクチャの導出－プロダクトアーキテクチャはプロダクトラインアーキテクチャか

ら導出される。導出において、不必要な部分を取り除き、プロダクト特定の特性でアーキテクチャを拡

張し、コンフリクトを解消し、関連する機能属性もしくは品質属性を決定する。本ステップの最後にア

ーキテクチャが要求を満たしているという確信を強めるために、たいていの場合アーキテクチャ評価を

することが適している。

3. プロダクトラインコンポーネントの選択とインスタンス化－プロダクトアーキテクチャにおけるそれ

ぞれのアーキテクチャコンポーネントのために、プロダクトラインコンポーネントが選択され、インス

タンス化される。複数の代替案がある場合、プロダクト要求に最も適合するコンポーネントが選択され

る。

4. プロダクト特定コンポーネントの開発－プロダクトラインコンポーネントに適合しないアーキテクチ

ャコンポーネントが選択されうる場合は、プロダクト特定コンポーネントの開発が必要である。新しい

プロダクトがコンポーネント機能を必要としたときに将来コンポーネントを開発しプロダクトラインコ

ンポーネントに追加する可能性を考慮することは重要である。

5. プロダクトの統合－最終プロダクトを生成するために、さまざまなコンポーネントとソフトウェアの

統合が必要とされる。このステップにおいてはコンポーネントを集め、接続し、システム統合コードを

書いてシステムインターフェイスをバインドする。

6. 検証－顧客が、あらかじめ取り決められた、信頼性のあるプロダクトを受け取るために、プロダクト

とそのコンポーネントは間違いなくテストされる必要がある。とりわけコンポーネントのテストは、コ



ンポーネントがたいていの場合汎用およびプロダクト特定コードから構成されているという事実によっ

て複雑になる。このことはソフトウェアプロダクトラインのアプローチの長所を伸ばすのも困難にする。

7. コンポーネントのパッケージ化とリリース－最終的にプロダクトはパッケージングされリリースされ

る。このステップにおいてはシステムの種類およびソフトウェアが新しいインストレーションかアップ

グレードかによって実際の作業が変わる。

プロダクトライン開発におけるプロダクトの実装フェーズでは、特定のプロダクトのためのすべての

成果物が生成される。

2.2.7.プロダクトライン資産の発展

プロダクトラインにおける資産の発展は主要な取り組みの部分である。しかし最初の設計の重要性を

過小評価するべきではない。なぜなら、プロダクトラインのライフサイクルにおいてやがて起こる発展

を予期した、よい設計はプロダクトライン資産を発展させる苦労を大幅に減らせるからである。このこ

とは他にもさまざまなよい結果をもたらす。例えば、より多くのスタッフが新規開発に従事でき、より

少ないスタッフで既存プロダクトの保守が行えるという点で競争力が増すなどである。

以下にプロダクトラインのなかで起こりえる発展のカテゴリについてまとめる。

■新しいプロダクトライン－多くの状況で新しいプロダクトラインの導入が必要とされている。例えば

新しいセグメントにおけるプロダクトの可変性が多すぎる、どんなことをしても重要な顧客を満足させ

なければならないようなビジネス上の理由、既存のプロダクトを組み入れる必要がある、プロダクトラ

インにおける様々なプロダクトと連携する単位間で地理的な距離がある場合や文化的な不一致、などで

ある。新しいプロダクトラインの導入には２つのアプローチがある。１つはクローニング、すなわちプ

ロダクトライン資産のコピーを作成することである。もう１つは特殊化、すなわち既存のプロダクトラ

インの特殊化として新しいプロダクトラインを編成することである。

■新しいプロダクトの導入－プロダクトラインにおける新しいプロダクトの導入はむしろプロダクトラ

インにおける典型的な発展のタイプである。これは多くの理由で起こりうる。マーケットの機会、既存

のプロダクトの組み入れ、プロダクトラインのスコープ拡大、などである。新しいまたは既存のプロダ

クトの組み入れには、新しいプロダクトラインのメンバーの要求と特性を統合するためにプロダクトラ

イン資産の設計のなかで多くのステップを繰り返すことを、プロダクトラインアーキテクトとエンジニ

アに要求する。

■新しい特性の追加－新しい特性は一般的にはプロダクトラインのメンバーに絶えず追加される。新し

い特性のための３つの原因が識別されうる。すなわち、マーケット調査、技術機会、競合から駆動され

る特性、である。

■標準サポートの拡大－大抵の場合プロダクトの最初のバージョンにおいては標準で定義された機能の



サブセットのみが実装される。後に続くバージョンで既存の標準の追加側面やより新しいバージョンの

標準が組み入れられる。標準の例としてはネットワーク通信プロトコル、コンポーネント通信の標準な

どがある。

■新しいバージョンのインフラストラクチャ－プロダクトラインにおけるプロダクトに基づくインフラ

ストラクチャはさらに発展すべく構築される。このことは、プロダクトラインで実装された状況と機能

がインフラストラクチャの次のバージョンにおいて利用できるようになるという結果が引き起こされる。

プロダクトライン資産から機能を取り除いたり、インフラストラクチャに依存させるのは価値あること

である。インフラストラクチャの発展形態としては、ハードウェア、OS、サードパーティのコンポーネ

ントの３つがある。

■品質属性の改善－とりわけプロダクトのリリースで市場への投入期間（time-to-market）に対して

厳しい要求があるせいで、以前のバージョンでは品質属性が犠牲にされる。後のバージョンの開発の際

にはこれらのプロダクトの品質を向上させる必要がある。よくある例としては性能、信頼性、柔軟性が

ある。プロダクトラインアーキテクチャを再編成せずにこれらの属性を改善するテクニックとして、キ

ャッシュ、ドメイン特定のメモリ管理、間接コールとラッパーがある。

リリース後および運用時のプロダクトの発展は重要度を増している。この種の発展はとりわけテレコ

ミュニケーションのシステムに顕著である。地理的に離れていてもプロダクトをアップグレードするた

めの費用対効果の高い、信頼性のあるソリューションを見つけることが重要である。ここでは４つのモ

デル（従来のリリース後の発展、運用時の発展、リモート環境での発展、顧客主導の発展）を提案して

いる。

2.2.8.プロダクトラインのための組織構成

プロダクトラインにおける資産の開発と保守を実行するプロセスの成功は、組織体制と無関係ではな

い。以下に組織モデルの例として4通りの体制を挙げる。

開発部門－このモデルは単一の開発部門において、プロダクトライン資産の開発とプロダクトライン

を利用したプロダクト開発を行う。比較的小規模な組織（最大でも 30 人程度の開発者）に向いている。

メンバー間のコミュニケーションがスムーズで小回りが利くが、組織モデル変更なしにスケールアップ

することはできない。

事業部門－このモデルは事業単位でプロダクトの種類に特化する。事業部門間でプロダクトライン資

産を共有し、資産の改良・発展はプロダクト（関連プロダクトも含む）の要件を満たす資産に対して新

しい機能をプロダクトラインに組み込みたい事業部門が行う。事業部門の数や規模、プロダクト間の機

能の共有の割合によって、3段階の成熟度モデル（unconstrained model、asset responsibles、

mixed responsibility）がある。組織の規模としては開発部門よりスケールアップが可能（最大100名

程度）。事業部門間の資産の効率的な共有を促すが、再利用可能資産より具体的なプロダクトに焦点が

行きがちである。

ドメインエンジニアリング部門－このモデルでは、再利用可能資産の設計、開発、発展に責任を持つ。



また、プロダクトラインに基づき構築されるプロダクトの開発と発展にも責任を持つ。複数のドメイン

エンジニアリング部門が存在する場合は、プロダクトラインアーキテクチャの構築と再利用可能なコン

ポーネントの開発を分けることも可能。組織の規模としては、事業部門の限界点あたりから、数百人ま

でスケールアップが可能。利点としては、事業部門のようにn:mのコミュニケーションパスから、プロ

ダクトエンジニアリング部門との1:nに減らせることと、広く使われる再利用可能な資産の開発に注力

できることである。逆に要求フローの管理と新しい要求に対応する再利用可能な資産の発展が困難であ

る。ドメインエンジニアリング部門は全てのプロダクトエンジニアリング部門とのバランスを取る必要

があるため、個別プロダクトエンジニアリング部門には time-to-market に悪い影響を及ぼす可能性が

ある。

階層的なドメインエンジニアリング部門－階層的なプロダクトラインが必要とされる場合があれば、

ドメインエンジニアリング部門も階層化される必要がある。ドメインエンジニアリング部門は特化され

たプロダクトラインを扱い、最上流のドメインエンジニアリング部門のプロダクトライン資産を基にす

る。この組織モデルは長いライフサイクルを持つ多様なプロダクトを非常に大規模な組織で運営するの

に向いている。しかしながら管理コストがたやすく増加し、全体として組織の俊敏性が低下するため、

競争力に悪い影響を及ぼす可能性がある。

また、組織モデルを選択するにあたっては、地理的分散、プロジェクト管理面での成熟度、組織文化、

プロダクトの種類による影響を考慮する必要がある。

３．アーキテクチャ設計方法論の例

3.1.IBM SOMA（Service-oriented Modeling and Architecture）

SOMAはサービス指向アーキテクチャの基礎の上にターゲットとなるビジネスプロセスを実装するこ

とを目的とした、技術変換アプローチである。SOMAはビジネス特性（ゴール、KPI、パフォーマンス

モニタリングの目的）を IT分析と意思決定へ広げることにより、ビジネス上の意図と IT実装の間に連

続性を持たせる。本節で使われている概念や表現などは参考文献[7]に基づくものである。

3.1.1.SOMAのコンセプト

IBMはSOAを以下の３つの文脈で定義している：

１．ビジネス－SOAはビジネスを顧客やパートナー、あるいは組織の他の部署に公開する一連のサー

ビスである。

２．アーキテクチャ－SOAはサービスプロバイダ、リクエスタ、サービス記述を必要とするアーキテ

クチャスタイルである。さらに、モジュール性、カプセル化、疎結合、関心事の分離、再利用、構成可

能性、単一実装のような特性を扱う、一連のアーキテクチャ原則、パターン、基準でもある。



３．実装－SOAはWebサービスのような標準、ツール、技術を備えたプログラミングモデルである。

SOMAのコンセプトは上記のうち、ビジネスとアーキテクチャにフォーカスし、サービスの識別と仕

様化（specification）を行うことにある。SOMAのゴールは企業に ITリソースを優先するプロジェク

トに素早く効率的に導く支援を行うことである。

以下の図はビジネスプロセスとその基礎をなすSOAインフラストラクチャとの間を埋めるSOMA

フレームワークと手法を示す：

図 3-1 SOMAフレームワークと手法（出所：参考文献[7]）

3.1.2.SOMAのアクティビティ

SOMAはビジネスプロセスをSOA環境にマップするために既に立証された様々なソフトウェア工学

テクニックを利用し拡張している。これらのテクニックにはドメイン分析、プロセスモデリング、コン

ポーネントベース開発、オブジェクト指向分析・設計が含まれる。SOMAはさらにサービスモデルを生

成することについての特定の要求を扱う独自のテクニックをいくつか紹介している。



図 3-2 SOMAの主要なアクティビティ（出所：参考文献[7]）

実際には個々のサービスとそれらの関係のモデル化を行い、SOAの配置を通じてインスタンス化を

導く３つの主要なSOMAアクティビティが存在する：

１．サービスとコンポーネントの識別

２．サービス特性の記述

３．サービスの実現

これら３つのアクティビティは実際には並行して行われる可能性がある。

SOMAエンゲージメントの最初の段階である「識別」において、サービスとエンタープライズコンポ

ーネントの候補が特定される。これらのサービスのいくつかは既に存在するかも知れず、その他のもの

は作成される必要があるかも知れない。SOMAはこのようなサービス候補を識別するために３つのアプ

ローチを利用する：

１．ドメイン分解－ビジネスドメインやプロセスのトップダウンの分析であり、CBMエンゲージメン

トより必然的に流れてくる。

２．ゴールサービスモデリング（GSM）－ドメイン分解を補完する新しいアプローチであり、ビジネス

目標とサービスを提携させることを支援し、さらにサービスの適切な粒度を決定することを支援する。

３．既存システムの分析－レガシーシステム、アプリケーションを含む現在の IT資産を調査するボトム

アップアプローチであり、標準ベースのサービスとしてラッピングされ公開される最も有益なアプロー



チでありうる。

SOMA プロセスの第二段階である「記述」は、サービスモデルにおいてサービスの特性が特定される。

顧客はこのモデルを利用し、サービスの合成、依存関係、インターフェイス、その他の特性を定義し、

どのサービスを内部に留め、どのサービスを外部に公開するか決定することを支援する。

SOMAの最終ステージである「実現」は対象となるサービスを実装する方法についてのアーキテクチ

ャ上の意思決定を行うことを伴う。SOMAはこれらの意思決定を行い、配置されるサービスのパフォー

マンスと効果を前もって見積もるためのフレームワークを提供する。このようにSOMAは、密結合な

レガシーIT環境から、より柔軟なビジネス中心のSOA環境に成功裏に移行するためにつきもののリス

クと不確実性を大幅に減らすことになる。

3.1.3.SOMAの成果物

SOMAエンゲージメントの成果物は企業の核となるビジネスプロセスを支援する最も適切なSOAデ

ザインを定義するサービスモデルとなる。ビジネスアクティビティおよびプロセスと ITインフラストラ

クチャとのギャップを埋めるよう、SOMAはビジネスと IT両方の領域をより緊密に提携させる。

3.2.Microsoft Motion

Microsoft Motion方法論はSOAをベースとして、ビジネスアーキテクチャを構築するための手法

である。Motion におけるビジネスアーキテクチャとは、ビジネスを俯瞰し、IT とビジネスのステーク

ホルダの間で共通の理解と一致協力を生み出すための構造であり、その結果企業が、技術、プロセス、

人々の最も重要な課題についてリソースを集中させられるようにするための支援をするものである。本

節で使われている概念や表現などは参考文献[9]に基づくものである。

3.2.1.Motion のコンセプト

Motion のコンセプトの中心はビジネスを構造化し、その構造をビジネスケーパビリティ

（capabilty：機能）というビルディングブロックの集まりから構成されるものと捉えているところであ

る。ビジネスケーパビリティとは、個々の業務機能の内容をモデリングしたものであり、特定の業務機

能に関連する人々、プロセス、手順などをビルディングブロックに抽象化し、カプセル化したものであ

る。

業務機能の達成方法ではなく、外部から見える振る舞いとその効果の期待レベル（service level

expectation：SLE）に注目した業務機能の単位である。いわば、“how”より“what”を重視した

機能分割である。

ケーパビリティを重要視する利点としては、組織構造やビジネスプロセスのフローより、安定してい

るということにある。

ビジネスケーパビリティの例としては、“製品の出荷”、“請求書の作成”、“買掛金の支払い”な

どがある。これらはインソースでもアウトソースでも、また手作業でも自動化されていても基本的な機

能としては変化しない。



3.2.2.ケーパビリティモデル

ケーパビリティモデルはビジネスケーパビリティの入れ子構造となっている。これはビジネスで利用

されるケーパビリティの構造化されたネットワークを図式化したものである。

図 3-3 ケーパビリティモデル構築のための基本フレームワーク（出所：参考文献[9]）

上の図のようにビジネスケーパビリティは何段階かの抽象レベルで構成される。レベル１は業界分野

に関わらず、ほとんどの組織に共通する基本的なケーパビリティであり、レベル２と３（およびそれ以

上）については、ビジネスケーパビリティの詳細を表す追加のレベルである。ケーパビリティモデルを

利用してビジネスアーキテクチャを検討するにあたっては、すべてのケーパビリティを同じレベルに分

解するのでなく、注目すべきビジネスの問題や専門領域の範囲に従い適切なレベルまで検討する。

以下はレベル１のケーパビリティモデルである。

図 3-4 基本的なケーパビリティのモデル（出所：参考文献[9]）

1.から5.までは運用（operational）ケーパビリティと呼ばれる。なぜなら、これらはビジネスの運

用モデルの一部を表しているからである。しかしながら、ビジネスは自己完結ではないので、組織のリ

レーションシップのモデルを構築する際には外部からの影響を考慮する必要がある。それがA.からF.で

記述されたインターフェイスである。



3.2.3.Motion のプロセス

Motion の方法論に基づきビジネスアーキテクチャを構築するにはMotionのチームモデルとプロセ

スに従う。

Motionは顧客の主導的な役割が重視されているため、チーム構成も顧客側の主要なステークホルダ

とともに顧客側の幹部クラスのリーダーシップを前提としている：

■Exec sponsor－プロジェクトのP&Lオーナー

■Project champion－プロジェクトのオーナー

■Project lead－Project championの指示を遂行する責任者

■Motion lead－Motion プロジェクトのコンサルタント

■Subject matters expert－ケーパビリティの専門家

■Project financial analyst

Motion では上述のケーパビリティモデルに組織構造、ツール、プロセスを直接組み込むのではなく、

適切なソリューションを導くために４つのフェーズを実行することで自身のケーパビリティモデルを描

き、ビジネスアーキテクチャを構築する。Motion では次のフェーズに進む前に一定の基準を満たす必

要があり、そのため“ステージゲート方式”とも呼ばれている。また、各フェース内では反復が推奨さ

れている。

図 3-5 Motion のプロセス（出所：参考文献[8]を基に作成）



3.2.4.Motion の成果物

Motion では個々のケーパビリティに沿ってプロセス指向で構造的な情報を抽出し文書化する方法を

提供する。Motionの成果物はそれらの文書であるが、結果として個々の組織の課題を、ビジネスプロ

セスよりも安定したビジネスアーキテクチャとして洗い出し、それぞれのケーパビリティに定義される

期待レベル（SLE）が理解できる。さらにそのSLEからサービス実装のための適切な実装技術と配置

トポロジを決定することができる。

４．アーキテクチャ設計に役立つパターン例

アーキテクチャ設計において適用されるパターン、すなわちアーキテクチャパターンは、アーキテク

チャ設計において繰り返し現れる問題に対する解法をカタログ化したものである。デザインパターンな

どのような細粒度のパターンと違い、具体的な実装方法より抽象的なアイデアを示すことが多い。ABD

法、Bosch法などではアーキテクチャスタイルという表現をしているが、本質的な違いはない。代表的

なものとしてはShawとGarlan、Bachmannらのパターン集があるが、本章では業務向けの分散ア

プリケーションという特定のトピックを扱ったものとして、Fowler の Patterns of Enterprise

Application Architecture と、Hohpeの Enterprise Integration Patterns を取り上げる。本章で使

われている概念や表現などは参考文献[4]と[5]に基づくものである。

4.1.Patterns of Enterprise Application Architecture

システム全体を階層的に構造化して修正や拡張を容易にするのが、レイヤであるが、Fowler はレイ

ヤ化されたアーキテクチャという文脈でパターンを提示している。Fowler はプレゼンテーション、ド

メインレイヤ、データソースレイヤという３つのレイヤから構成されるアーキテクチャに焦点を当てて

いるが、なかでも重要視しているのが、ドメインレイヤである。以下に簡単な説明を記述する。

ドメインレイヤにはシステムそのものであるロジックが配置され、ドメインロジック（ビジネスロジ

ックとも呼んでいる）、すなわち現在作業中のドメインに対してアプリケーションが行うべき作業の場

となっている。入力データと格納データに基づく計算、プレゼンテーションから送信されたデータの妥

当性確認、プレゼンテーションレイヤから受信したコマンドに応じてどのデータソースロジックを呼び

出すかの決定などが、作業にあたる。

ドメインロジックの構築にはトランザクションスクリプト、ドメインモデル、テーブルモジュールの

３つのパターンを挙げている。シンプルな手続き型のトランザクションスクリプト、最もオブジェクト

指向的で複雑なロジックに対応できるドメインモデル、そしてデータベースへのクエリ結果を格納する

レコードセットを処理するテーブルモジュール、という違いがあるが、それら３つのうちどれを選択す

るかは、ドメインロジックの複雑性と実装の労力とのバランスに依る。

全般的なパターンの形式としては、以下のような構造で記述されている：



■パターン名

■目的－パターンの要約

■スケッチ－パターンのビジュアル表現

■動作方法－解決策の説明

■使用するタイミング－パターンをいつ使用すべきか、また選択のトレードオフ

■参考文献

■例－JavaやC#のコード例

以下にパターンの一覧を示す（カテゴリ－名前、で記述）：

■ドメインロジック－トランザクションスクリプト、ドメインモデル、テーブルモジュール、サービス

レイヤ

■データソースのアーキテクチャ－テーブルデータゲートウェイ、行データゲートウェイ、アクティブ

レコード、データマッパー

■オブジェクトリレーショナル振る舞い－ユニットオブワーク、一意マッピング、レイジーロード

■オブジェクトリレーショナル構造－一意フィールド、外部キーマッピング、関連テーブルマッピング、

依存マッピング、組込バリュー、シリアライズLOB、シングルテーブル継承、クラステーブル継承、具

象テーブル継承、継承マッパー

■オブジェクトリレーショナルメタデータマッピング－メタデータマッピング、クエリーオブジェクト、

リポジトリ

■Web プレゼンテーション－モデルビューコントローラ、ページコントローラ、フロントコントローラ、

テンプレートビュー、トランスフォームビュー、ツーステップビュー、アプリケーションコントローラ

■分散－リモートファサード、データ変換オブジェクト

■オフライン並行性－軽オフラインロック、重オフラインロック、緩ロック、暗黙ロック

■セッションステート－クライアントセッションステート、サーバセッションステート、データベース



セッションステート

■ベース－ゲートウェイ、マッパー、レイヤスーパータイプ、セパレートインターフェイス、レジスト

リ、バリューオブジェクト、マネー、スペシャルケース、プラグイン、サービススタブ、レコードセッ

ト

4.2.Enterprise Integration Patterns

Hohpeは本パターン群において、アプリケーション統合の問題を取り扱っている。Hohpeは統合は

単にERPを採用するなどの技術インフラストラクチャの問題ではなく、ビジネスと技術両面にわたる

課題があると主張している。たとえば設計されるアーキテクチャの構造と組織構造との類似性の問題、

統合ソリューションの開発においてレガシーアプリケーションに対する変更の制限の問題、統合ソリュ

ーションに対する標準化の遅れ、開発以上に深刻な運用・保守の問題、などを挙げて、高レベルの統合

問題とその土台となる実装問題とのギャップを指摘している。

とは言えHohpeはこれらの問題は、過去にも繰り返し起こり先達が提示してきた最適解をパターン

として整理しこれらのアドバイスを適切に活用することにより、上述のギャップを小さくできると主張

している。

Enterprise Integration Patterns が提示するパターン群は、メッセージベースのゆるやかな統合ソ

リューションを描いており、以下のような要素から成り立っている。

図 4-1 メッセージベース統合の基本要素（出所：参考文献[5]）

「メッセージ」は両端のアプリケーションによって意味が取り決められたデータの断片である。

「チャネル」は情報を一方からもう一方へと移動させる通信経路であり、TCP/IP、共有ファイル、

共有データベース、あるいはフロッピーディスクの直接的なやり取りでもよい。

もし、アプリケーションが利用している内部フォーマットを変更することができないのならば、一方

のアプリケーションのデータフォーマットをもう一方のデータフォーマットに変更する必要がある。こ

れが「変換」である。

また、新しいシステムが追加される度に環境を調整する労力が大きければ、送信されたメッセージを

正しい場所に届ける仕組みが有効である。このような要素を「ルーティング」を呼び、メッセージブロ

ーカのようなミドルウェアがそのような役目を果たしている。



様々な要素が複数のプラットフォームや地理的場所に分散すると、「システム管理」機能を入れて、

データの流れを監視しすべてのアプリケーションが起動し動作しており、障害時にはレポートするなど

して、システム内部に何が起こっているか知らされなければならない。

最後の要素として、統合ソリューションに参加できないアプリケーションをシステムに明示的に接続

させる「メッセージエンドポイント」と呼ばれる特定のコードを追加する。

Enterprise Integration Patterns が他のパターンと比較してとりわけユニークなのは、多くのパタ

ーンが名前だけでなくアイコン形式（“Gregorgram”と呼ばれている）で描かれているためにパター

ンの組み合わせによるソリューションを直感的に表現できることである。例えば下の図のように注文処

理システムをパターンのビルディングブロックで描くことができる。

図 4-2 非同期メッセージングを用いた注文処理ソリューションの例（出所：参考文献[5]）

全般的なパターンの形式としては、以下のような構造で記述されている：

■パターン名

■アイコン

■文脈－パターンが解決する問題に出会う状況

■問題

■フォース－問題解決を困難にする制約

■ソリューション

■スケッチ－パターンのエッセンスの理解を促す図

■結果－ソリューションの適用とフォースの解決方法についての詳細

■関連（next）－他に考慮すべきパターン

■補足－技術的話題やパターンのバリエーション



■例－コード例など

以下にパターンの一覧を示す（カテゴリ－名前、で記述）：

■統合スタイル－ファイル転送、共有データベース、リモートプロシージャ呼び出し、メッセージング

■メッセージングシステム－チャネル、メッセージ、パイプとフィルタ、ルーティング、変換、エンド

ポイント

■メッセージングチャネル－ポイントツーポイントチャネル、パブリッシュ－サブスクライブチャネ

ル、データタイプチャネル、無効メッセージチャネル、デッドレターチャネル、保証配信

（Guaranteed delivery）、チャネルアダプタ、メッセージングブリッジ、メッセージバス

■メッセージ構築－コマンドメッセージ、ドキュメントメッセージ、イベントメッセージ、要求－応答、

リターンアドレス、相関識別子（Correlation identifier）、メッセージシーケンス、メッセージ期限、

フォーマット指示器（Format indicator）

■メッセージルーティング－コンテンツベースルータ、メッセージフィルタ、動的ルーター、受信者リ

スト、スプリッタ、アグリゲータ、再組み立て（Resequencer）、構成メッセージプロセッサ

（Composed message processor）、散布－収集（Scatter-Gather）、ルーティングスリップ、プ

ロセスマネージャ、メッセージブローカ

■メッセージ変換－エンベロープラッパー、コンテンツエンリッチ、コンテンツフィルタ、手荷物預り

証（Claim check）、標準化（Normalizer）、規範的（Canonical）データモデル

■メッセージエンドポイント－メッセージゲートウェイ、メッセージングマッパー、トランザクショナ

ルクライアント、ポーリングコンシューマ、イベント駆動コンシューマ、競争（Competing）コンシ

ューマ、メッセージディスパッチャ、選択的コンシューマ、永続的サブスクライバ、等べきレシーバ、

サービスアクティベータ

■システム管理－コントロールバス、迂回路（Detour）、通信傍受（Wire tap）、メッセージヒスト

リ、メッセージストア、スマートプロキシ、テストメッセージ、チャネル浄化（Channel purger）

５．出典・参考文献

[1] Bass, L., Clements, P. and Kazman, R.： Software Architecture in Practice Second

Edition, Addison-Wesley, 2003. 前田卓雄他訳「実践ソフトウェアアーキテクチャ」, 日刊工業新



聞社, (2005).

[2] Bass, L.. and Kazman, R.： Architecture-Based Development, Technical Report,

CMU/SEI-99-TR-007, 1999.

[3] Bosch, J.： Design and Use of Software Architectures, Addison-Wesley, 2000.

[4] Fowler, M.： Patterns of Enterprise Application Architecture, Addison-Wesley, 2002. 長

瀬嘉秀他訳「エンタープライズアプリケーションアーキテクチャパターン」, 翔泳社, (2005).

[5] Hohpe, G. and Woolf, B.： Enterprise Integration Patterns, Addison-Wesley, 2003.

[6] 岸知二、野田夏子、深澤良彰：「ソフトウェアアーキテクチャ」、ソフトウェアテクノロジーシリ

ーズ4、共立出版、2005

[7] Ransom, M., et al.： The Solution Designer’s Guide to IBM On Demand Business

Solutions Third Edition, International Business Machines Corp., 2005.

[8] Sehmi, A. ： Rock Your Business Architecture with Motion, Microsoft Tech・Ed Israel,

Microsoft Corp., 2006. （2006年6月現在

http://download.microsoft.com/download/5/f/2/5f224fcf-2ed2-4d29-814c-

d3baac20d430/ARC310.ppt よりダウンロード可能）

[9] Sehmi, A. and Schwegler, B.： Service-Oriented Modeling for Connected Systems ･

Part 1, The Architecture Journal issue 7, Microsoft Corp., 2006.

Ⅱ-ⅱ ＩＴアーキテクチャ評価技法

Ⅱ-ⅱ １ＩＴアーキテクチャ評価技法ＡＴＡＭ、ＣＢＡＭ 1

Ⅱｰⅱ １ ITアーキテクチャ評価技法 ATAM,CBAM

// CONTENTS //

１．コンテキスト............................................................................................................................................. 2

１-１．概要........................................................................................................................................................... 2 １-２．評価法の分類............................................................................................................................................ 3 １-３．ATAMとCBAM ................................................................................................................................... 4

２． ATAMの構成と内容 ............................................................................................................................... 5

２-１．ATAMの目的 ......................................................................................................................................... 5 ２-２．実施時期 ................................................................................................................................................... 5 ２-３．ATAMの関係者...................................................................................................................................... 5 ２-４．インプットとアウトプット ..................................................................................................................... 6 ２-５．評価の実施手順........................................................................................................................................ 6 ２-６．用語の説明 ............................................................................................................................................. 11

３． CBAMの構成と内容.................................................................................................................................... 13

３-１．CBAMの目的 ....................................................................................................................................... 13 ３-２．実施時期 ................................................................................................................................................. 13 ３-３．インプットとアウトプット ................................................................................................................... 13 ３-４．評価の実施手順...................................................................................................................................... 14 ３-５．用語の説明 ............................................................................................................................................. 19

４．参考文献 .................................................................................................................................................. 20



１．コンテキスト

１-１．概要

アーキテクチャはシステムの青写真であり、システムに要求される品質特性を明らかにするものである。

アーキテクチャを評価することは、システムの品質を向上し、リスクを低減するため良い方法である。

また、評価は可能な限り早期に実施したほうが、多くの場合コスト効率が良い。プロジェクトの後期に

なるほど修正にかかるコストがかかるからである。

一方、アーキテクチャ評価は、システムのライフサイクル中の多くの場面で実行できる。これから作成

するアーキテクチャの方針の検討、完成したアーキテクチャの妥当性の確認、システムをアップグレー

ドする際の既存のアーキテクチャの評価など、アーキテクチャ評価が効力を発揮する出来る場面は様々

である。

アーキテクチャの評価をする利点としては以下の事項が挙げられる。

■ 財務上の利点

レヴューにかかる工数以上の工数を削減できた、という調査が多くある。

■ レヴューの準備を強制する

レヴューを受ける側はアーキテクチャを説明する必要があるため、レヴューに先立ち簡潔で理解し

やすいアーキテクチャの文書が作成される。

■ 論理的根拠を捉える

評価において、アーキテクチャ上の決定に対する論理的根拠を説明する必要がある。

■ 既存のアーキテクチャに関する問題の早期発見

問題の発見が早いほど、修正するコストは低くなる。アーキテクチャ評価では、無理な要求、性能

の問題、下流の変更に関する潜在的な問題を見つけることが出来る。

■ 要求の妥当性評価

システムに対する要求に対し、

■ アーキテクチャの改善

アーキテクチャの評価を継続的、組織的に行うことで、評価を

本文書では、アーキテクチャの評価法の分類を述べた上で、多くの業界で採用されているATAMと

CBAMの２つの技法を取り上げる。



１-２．評価法の分類

評価法には大きく分けて以下の３つの分類が存在する。

質問技法（Questioning Techniques）

質問表、チェックリスト、シナリオなどを基に、アーキテクチャが要求にどの程度適合しているかを理

解するものである。システム開発の早い段階で実施できることが利点である。

測定技法（Measuring Techniques）

質問技法と違い、定量的な計測を基に評価する方法である。例として、アーキテクチャのメトリック、

シミュレーションやプロトタイプを使用した品質に関する測定等が挙げられる。より具体的な結果が得

られるが、測定を行うための・成果物が必要となる。

ハイブリッド技法（Hybrid Techniques）

質問技法、測定技法双方を取り入れた評価方法。

以下に、代表的なアーキテクトの評価技法を上記の3つに分類した表を記載する。同分類は、参考文献

[２]Evaluating Software Architectures によるもので、参考文献[１]実践ソフトウェアアーキテクチャに

よるとATAMは質問技法に位置づけられる。

図表1-1 評価技法の比較

※出典：Evaluating Software Architectures を元に執筆者が編集

技法カバーする品質特性使用する手法いつ適用するか

質問表、チェックリスト

各種所定の分野の質問アーキテクトが何らかの設計手法を採用した際、もしくは任意の時

シナリオ技法各種；特に変更容易性、セキュリティ

SAAM 変更容易性、機能性

ARID デザインの

SNA セキュリティ

メトリクス各種；変更容易性、信頼性に構造の静的な分析、アーキテクチャが設計された後

シュミレーション、プロトタイプ、実験

各種；特に、性能、機能性、使用性

プロトタイプ等の成果物の実行結果の測定

アーキテクチャが設計された後

RMAパフォーマンスを重視したリアルタイムシステム

定量的な分析プロセスモデルが構築され、プロセスの処理方法が決定された後

ADLs各種但し振る舞いと性能に使用される傾向がある

シナリオ、及び定量的な分析アーキテクチャ上の設計書が完成した時

SPE 性能シナリオ及び定量的な分析

ATAM

特定の品質特性に限っているわけではないが、歴史的に変更容易性、セキュリティ、信頼性、性能に

ユーティリティツリーとブレインストーミングにより要求される品質特性を明確化する。アーキテクチャ上の決定を分析することで、センシティビティポイント、トレードオフポイント、リスクを特定する。

アーキテクチャ手法が選択された後

質問技法

測定技法

ハイブリッド技法

シナリオにより要求される品質特性を明確化し、ウォークスルーにより、システムの応答を設定する。

シナリオのウォークスルーを実施してもよい程、アーキテクチャが設計された時



１-３．ATAMとCBAM

(1) ATAM

ATAM（Architecture Tradeoff Analysis Method）はシステムに要求されている品質目標をアーキテクチ

ャがどのように達成しているかを明らかにする。そして、アーキテクチャ上の決定が複数の品質特性に

影響を与えるという認識の上で、品質目標がどのように相互作用するか、すなわちそれらがどのように

トレードオフされるのかを検討する。

ATAMを実施することにより、品質特性を構造化して表現したユーティリティツリーや品質特性を実現

するためのシナリオが得られる。

(2) CBAM CBAM（Cost Benefit Analysis Method）はATAMでは考慮されない経済的な側面から。アーキテクチ

ャを評価する。

ATAMで得られたアウトプットを基に実施し、シナリオを実現するためのアーキテクチャ戦略を明確化

し、各々から得られる利益と実施するためのコストからROIを算出し、経済的側面からアーキテクチャ

戦略に対して優先順位付けを行う。



２． ATAMの構成と内容

２-１．ATAMの目的

ATAM の目的は、システムに要求される品質特性を実現するためのアーキテクチャ上の決定を明ら

かにし、それらの決定のリスクを顕在化することである。

２-２．実施時期

システムでどのようなアーキテクチャ手法を採用するかが決められた後に実施が可能となる。

２-３．ATAMの関係者

ATAMは以下の 3つの主体で実施される。

評価チーム

評価されるアーキテクチャのプロジェクトチームの外部の人間で構成される。通常、3～5人で構成され、

評価を行う上でいくつかの役割が与えられる。

プロジェクトの意思決定者

プロジェクトを代弁することができる人たち、変更を強制できる権限がある人たち。通常、プロジェクト

管理者、顧客（開発に資金を出している特定の顧客）、アーキテクトから構成される。また、評価の依頼人

も含まれるべきである。

アーキテクチャのステークホルダー（利害関係者）

アーキテクチャの決定に左右される人たち。開発者、テスト担当者、保守担当者、ユーザ、関連があるシ

ステムの開発者等が含まれる。



２-４．インプットとアウトプット

(1) インプット ATAMを実施するために必要なインプットは以下の通り。

・システムのビジネスドライバー

・アーキテクチャを説明する文書。

(2) アウトプット ATAMを実施した際に得られるアウトプットは以下の通り。

・採用するアーキテクチャ手法

・ユーティリティツリー

・優先順位付けされたシナリオ・リスク、ノンリスク、センシティビティポイント、トレードオフポイント

２-５．評価の実施手順

ATAMは 4つのフェーズと 9つのステップで構成される。

(1) 4つのフェーズフェーズ０協力関係と準備

評価チームのリーダー、プロジェクトの主要な意思決定者が、実行の詳細を計画する。２-３週間程度必要

とする。

フェーズ１評価

評価チームのリーダー、プロジェクトの意思決定者が、アーキテクチャの評価を実施する。通常１日間実

施する。事項で説明するステップ１から６までを実施する。

フェーズ２評価（続き）

評価チーム、プロジェクトの意思決定者、利害関係者が、アーキテクチャの評価を実施する。通常２日間

実施する。事項で説明するステップ７から９までを実施する。

フェーズ３フォローアップ

評価チームが最終報告書を作成し、配布する。１週間程度必要とする。詳細は事項で説明する。



(2) 評価フェーズの9つのステップ評価フェーズ（フェーズ１及び、フェーズ２）は、以下の9つのステップで構成される。この内、１～６

はフェーズ１で実施され、７～９はフェーズ２で実施される。

ステップ１ ATAMの提示

評価リーダーが参加者に対して、ATAMの説明を行う。

ステップ２ビジネスドライバーの提示

プロジェクトの意思決定者がビジネスの視点からのシステムの概要を説明する。説明には以下の内容

を含めるべきである。

・システムの最も重要な機能。

・技術的制約、管理上の制約、コストの制約、政治的制約

・プロジェクトのビジネスの目標と背景

・主なステークホルダー。

・アーキテクチャドライバー（アーキテクチャを方向付ける主な品質特性の目標）

ステップ３アーキテクチャの提示

アーキテクトのリーダーがアーキテクチャの説明を行う。説明には以下の内容を含めるべきである。

・技術的な制約事項。例えば、OS、ハードウェア、ミドルウェアなど。

・関連する他のシステム。

・要求を満たすために使用したアーキテクチャの手法。

ステップ４アーキテクチャ手法を特定する

採用されているアーキテクチャ手法を明確化し、理解する。また、採用されている主なアーキテクチ

ャをカタログとしてまとめる。



ステップ５品質特性のユーティリティツリーを作成する

このステップでは、品質特性の目標を明確化、詳細化、優先順位付けを行うために、ユーティリティ

ツリーを作成する。また、詳細化された品質特性はシナリオとして表現される。

ユーティリティツリーは、ルートノードとして｢Utility｣で始まる。次のレベルは品質特性で形成され

る。品質特性の例としては、性能、変更容易性、セキュリティ、使いやすさ、可用性などが挙げられ

る。更に、次レベルで品質特性が詳細化される。例えば、性能は｢データ待ち時間｣｢トランザクショ

ンスループット｣などに詳細化される。詳細化された品質特性はシナリオとして表現され、品質具体

的な目標が伴った、検証可能な状態になる。また、各シナリオには優先順位を付与する。優先順位に

は、シナリオの重要度と難易度を高(H)、中(M)、低(L)の3段階で評価する方法が用いられる。例えば、

重要だが難易度が低いものは（H,L）、重要度は中程度で難易度が高いものは（M.H）などである。

ユーティリティツリーの具体例を図表2-1に記す。

図表2-1 ユーティリティツリーの例

※出典：Evaluating Software Architectures を元に執筆者が編集

Utility

性能

変更容易性

可用性

セキュリティ

データ遅延

トランザクションスループット

アプリケーションの変更容易性

ハードウェア障害

ソフトウェア障害

データの機密性

データの完全性

新規モジュールの追加

(H,L) リアルタイムの動画配信

(H,L) 認証サーバの平均スループットを最大化する

(L,H) CORBAのミドルウェアの追加を20人月未満で実施する。

(H,L) Webのユーザインターフェースを1人月未満で実施する。

(M,M) ディスク障害の後5分以内に復旧する

(H,M) NW障害を検知し、1分半以内に復旧する。

(H,M) クレジットカードのトランザクションの99.999%の安全性が保障されている


Utility

性能

変更容易性

可用性

セキュリティ

データ遅延

トランザクションスループット

アプリケーションの変更容易性

ハードウェア障害

ソフトウェア障害

データの機密性

データの完全性

新規モジュールの追加

(H,L) リアルタイムの動画配信

(H,L) 認証サーバの平均スループットを最大化する

(L,H) CORBAのミドルウェアの追加を20人月未満で実施する。

(H,L) Webのユーザインターフェースを1人月未満で実施する。

(M,M) ディスク障害の後5分以内に復旧する


(H,M) クレジットカードのトランザクションの99.999%の安全性が保障されている




ステップ６アーキテクチャ手法を分析する

ステップ５で重要度が高いと判断されたシナリオに対して、それを実現するために用いるアーキテク

チャ手法を詳しく調査する。評価チームはシナリオを実現するためのアーキテクチャ上の決定を記録

し、それらの｢リスク｣、｢ノンリスク｣、｢センシティビティポイント｣、｢トレードオフポイント｣を特

定し、カタログ化する。

センシティビティポイントは、シナリオの応答測定（品質の目標）に影響を及ぼす、注意すべき点を

言う。例えば「データベースにベンダー固有のSQL方言を使用することは、変更容易性に負の影響

を与えるセンシティビティポイントである。」

アーキテクチャ上の決定が、品質特性のセンシティビティポイントとなる場合、トレードオフポイン

トに指定される。例えば「選択した製品がデータベース固有のSQL方言を使用している場合は、上記

のセンシティビティポイントに該当し、そのアーキテクチャ上の決定はトレードオフポイントに指定

される。」

また、センシティビティポイント、トレードオフポイントはリスクの候補として位置づけられる。

このステップの終了時点で、重要度が高いシナリオに対して、アーキテクチャ全体の最も重要な側面

を説明する図、設計方針の論理的根拠、｢リスク｣、｢ノンリスク｣、｢センシティビティポイント｣、｢ト

レードオフポイント｣のリストが得られる。

以下に詳細化されたシナリオの例を記載する。

図表2-2 詳細化されたシナリオの例

※出典：実践ソフトウェアアーキテクチャを元に執筆者が編集

ステップ７ブレインストーミングとシナリオの優先順位づけ

可用性

通常動作

CPUの1つが故障する

スイッチの0.999999の可用性

センシティビティトレードオフリスクノンリスク

S2 R8

S3 T3 R9

S4 N12

S5 N13

S6 N14

ハートビート

フェイルオーバールーティング

論理的根拠

アーキテクチャ図

異なるハードウェアとOSを使って普通のモードが故障しないことを確実にする（リスク8）最悪のロールオーバーが、最も計算がかかる状態でも、4秒で達成されるハートビートやウォッチドッグのレートに基づいて、2秒以内に故障を検出することを保障するウォッチドッグは簡単で、信頼がおけるデータチャネルのバックアップがないので、可用性の要求にはリスクがある（リスク9）

品質特性

環境

刺激

応答時間

アーキテクチャ上の決定

CPUのバックアップ

データチャネルはバックアップしない

ウォッチドッグ

シナリオ：メインスイッチのハードウェア故障を検出して、回復する

シナリオ#12

Primary CPU(OS1)

BackUp CPUWith Watch Dog

(OS2)

Primary CPU(OS1)

Heartbeat(1 sec.)



シナリオの優先順位付けをするために、ステップ６で重要度が高いと判断されたシナリオについてブ

レインストーミングを行う。その後、メンバーによる投票によりシナリオの順位付けがされる。

ステップ８アーキテクチャ手法を分析する

ステップ７で最も高く優先付けられたシナリオを実行する。アーキテクトは、そのシナリオ実現する

ために、関連するアーキテクチャ上の決定がどのような貢献をしているかを説明する。

ステップ９結果の提示

ATAMによって集められた情報を要約し、利害関係者に対してプレゼンテーションを行う。プレゼン

テーションには以下の内容が含まれる。

・文書化されたアーキテクチャ

・優先順位付けされたシナリオ


・リスク、ノンリスク、センシティビティポイント、トレードオフポイント



２-６．用語の説明

（1）品質特性

システムが提供するサービスである機能性では捉えられない、システムへ要求される特性。非機能要

件と同義。以下に、品質特性の例として｢ISO9026｣で定義されている品質特性を示す。

図表2-2 ISO9126で定義されている品質特性

（2）シナリオ（品質特性シナリオ）

品質特性を特徴付けるために用いられるものである。以下の 6つの要素から構成される。

刺激の発生源（source of stimulus ）

刺激を生み出す実体(人間、コンピュータ、他の装置など)。

刺激（stimulus）

システムに影響を及ぼす状況。（障害、変更要求など）

環境（environment）

刺激が発生する際のシステムの状況。（通常稼動状態、縮退稼動状態、設計時点など）

成果物（artifact）

刺激を受ける対象。（システム全体、プログラム、ミドルウェアなど）

応答（response）

刺激を受けたあとに開始される活動。（スタンバイ機での縮退稼動、プログラムの修正など）

応答測定（response measure）応答を何らかの方法で測定したもの。（10秒以内、3時間未満など）

品質特性説明品質副特性

合目的性 (suitability)

正確性 (accuracy)

相互運用性 (interoperability)

標準適合性 (compliance)

機密保護性 (security)

成熟性 (maturity)

耐故障性 (fault tolerance)

回復性 (recoverability)

理解性 (understandability)

習得性 (learnability)

運用性 (operability)

時間効率性 (time behavior)

資源効率性 (resource behavior)

分析容易性 (analyzability)

変更容易性 (changeability)

安定性 (stability)

試験容易性 (testability)

環境適応性 (adaptability)

設置容易性 (installability)

規格適合性 (conformance)

置換容易性 (replaceability)

移植性(portability)実環境や、現在とは違う環境への移行が少ない労力で行えること

効率性(efficiency)作業にかかる時間やメモリ使用量、処理時間などが許容範囲内に収まること

保守性(maintainability) 保守が容易で、変更が少ない労力で行えること

信頼性(reliability)決められた条件と期間の間で、目的の仕事が正しく行えること

使用性(usability) 使いやすく、少ない労力で利用できること

機能性(functionality)目的の仕事をするのに必要な機能がそろっていること



変更容易性に関するシナリオの一例を以下に挙げる。

図表2-1 変更容易性のシナリオの例


刺激の発生源：開発者

刺激：UIに対する変更要望

成果物：コード

環境：設計時点

応答：副作用・悪影響の無い修正

応答時間：3時間未満

刺激の発生源：開発者

刺激：UIに対する変更要望

成果物：コード

環境：設計時点

応答：副作用・悪影響の無い修正

応答時間：3時間未満



３． CBAMの構成と内容

３-１．CBAMの目的

CBAMは、「コスト」の面からATAMのアウトプットを評価し、優先順位を伴った、シナリオを実

現するためのアーキテクチャ戦略決定することを目的とする。

３-２．実施時期

CBAMの評価対象は、ATAMのアウトプットである。従って、CBAMはATAMの評価を行った後

実施可能となる。

３-３．インプットとアウトプット

(1) インプット前述の通り、CBAMでは、ATAMでの成果物をインプットとする。従って、以下のものがイ

ンプットとなる。

・システムの成功に重要なビジネス目標

・アーキテクチャを説明する文書。

・採用するアーキテクチャ手法


・優先順位付けされたシナリオ

・リスク、ノンリスク、センシティビティポイント、トレードオフポイント

(2) アウトプット

・シナリオを実践するための、アーキテクチャ戦略。

・アーキテクチャ戦略を実施するための指標となる、コスト(ROI)とスケジュール。



３-４．評価の実施手順

CBAMの実施手順は、9個のステップから構成される。

ステップ１シナリオを順に並べる

シナリオを優先順位に並べて、上位1/3を選択する。

以下に優先順位がつけられたシナリオの例を記載する。

図表3-1 シナリオの例


ステップ２シナリオを詳細化する

ステップ１で選んだシナリオの刺激と応答測定に焦点をあわせ、詳細化する。各シナリオについ

て、｢最悪｣｢現状｣｢必要｣｢最良｣の各々のケースの品質特性応答レベルを引き出す。

図表3-2 応答目標の例


シナリオ説明

1配布要求に人の介入を必要とする身動きのとれない結果になるデータ配布上の障害を減少させる。

2 行き先不明の要求につながるデータ配布上の障害を減少させる。

3 オーダー依頼処理場の障害となるオーダー数を減少させる。

4人の介在を必要とする処理不能なオーダーになるオーダー上の障害を減少させる。

5 オーダーの紛失につながるオーダー上の障害を減少させる。

6人手による介入なしに、処理されていない/取り消されたECSGuestを追跡する優れた方法が存在しない。(例えばスプレッドシート)

7ユーザは、自己のオーダー情報が処理されていない理由についてもっと情報を必要とする。

8 限界があるため、オーダーの規模や数に意図的に制限する必要がある。

9 小さなオーダーは、あまりに多くのユーザへの通知につながる。

10システムは、1日に50GBのユーザ要求を処理しなければならない。また、1週間では1TBのユーザ要求である。

最悪現状必要最良

1 10%停止 5%停止 1%停止 0%停止

2 >5%紛失 <1%停止 0%紛失 0%紛失

3 10%使用不能 5%使用不能 1%使用不能 0%使用不能

4 10%停止 5%停止 1%停止 0%停止

5 10%紛失 <1%紛失 0%紛失 0%紛失

6 50%支援が必要 25%支援が必要 0%支援 0%支援

7 10%情報取得 50%情報取得 100%情報取得 100%情報取得

8 50%制限 30%制限 0%制限 0%制限

9 1件当たり1件 1件当たり1件 100件当たり1件 1000件当たり1件

10 <50%目標に合致 60%目標に合致 80%目標に合致 >90%目標に合致

シナリオ応答目標



ステップ３シナリオを優先順位付ける

シナリオに投票をして上位50%を選択し、次の分析へ進む。投票方法は、100票を各利害関係者へ

割り当てて、それらの票を各シナリオへ分配させる。

ステップ４ユーティリティを割り当てる

ステップ３で選択したシナリオについて、各品質特性応答レベルのユーティリティを決定する。

以下に、シナリオに対する得票数とユーティリティの例を記載する。

図表3-3 ユーティリィティ値の例


最悪現状必要最良

1 10 10 80 95 100

2 15 0 70 100 100

3 15 25 70 100 100

4 10 10 80 95 100

5 15 0 70 100 100

6 10 0 80 100 100

7 5 10 70 100 100

8 5 0 20 100 100

9 10 50 50 80 90

10 5 0 70 90 100

シナリオ投票応答目標



ステップ５シナリオのためのアーキテクチャ戦略を開発して、それらの期待される応答レベルを

決定する

選択されたシナリオを扱うアーキテクチャ戦略を開発して、それらのアーキテクチャ戦略から生

じる期待される品質特性応答レベルを決定する。一つのアーキテクチャ戦略が複数のシナリオに

影響する場合がある。

図表3-4 アーキテクチャ戦略の例


戦略名称説明影響を受ける

シナリオ現在の応答期待の応答

1発行したオーダー情報の保持

システムにデータが到着すると同時に、オーダーを記憶する。

356

5%処理不能<1%紛失25%が支援が必要

2%処理不能0%紛失0%紛失

2 オーダーの分割オペレータが大きなオーダーを複数の小さなオーダーに分割することを許可する。

8 30%制限 15%制限

3 オーダーの統合複数の小さなオーダーを1つの大きなオーダーに統合する。

910

1件当たり1件60%目標に合致

100件当たり1件55%目標に合致

4 オーダーの区分けオペレータがデータの品質や可用性の問題が原因で参照できない項目を飛ばして処理することを可能にする。

4 5%停止 2%停止

5 オーダーの再設定オペレータがあるオーダーの項目ごとに媒体を再指定することを可能にする。

1 5%停止 2%停止

6 オーダーの再試行

オペレータが一時的なシステムあるいはデータの障害のために処理不能になった可能性のあるオーダーあるいはオーダーの一部を処理することを可能にする。

4 5%停止 3%停止

7 オーダーの強制完了オペレータがデータの品質上の制限によって、オーダーの一部を再処理することを可能にする。

1 5%停止 3%停止

8 オーダー障害の通知

オーダーの一部が処理不能であった場合のみ、ユーザに確実に通知し、それぞれの項目の詳細な状況を伝える。ユーザへの通知は、オペレーションが通知を承認した場合のみ発行される。オペレータは通知内容を編集できる。

67

25%支援が必要50%情報取得


9細分化したオーダーの追跡

オペレータとユーザはオーダーの項目ごとにその状況を判断できる。

67



10 ユーザ情報へのリンク

オペレータは速やかにユーザのコンタクト情報を知る。サーバーはSDSRV情報にアクセスし、DDIST,PDS,外部の設定者、データ処理ツールなどを含め、適切な配布昨日にオーダー/オーダーの区分けを適用する。そして送付するデータ上の制限について決定する。

7 50%情報取得 60%情報取得



ステップ６「期待される」品質応答レベルのユーティリティを内挿法で決定する

ユーティリティ曲線を使って、アーキテクチャ戦略の期待される品質特性応答レベルのユーティ

リティ値を決定する。

以下にアーキテクチャ戦略がもたらすユーティリィティ値の例を記載する。

図表3-5 アーキテクチャ戦略がもたらすユーティリィティ値の例


ステップ７アーキテクチャ戦略から得られる総利益を計算する

期待されるユーティリティ値から現在のユーティリティ値を引いて、各シナリオがアーキテクチ

ャ戦略から得られる利益を求める。各シナリオがアーキテクチャ戦略から得られる利益を合算し、

アーキテクチャ戦略から得られる利益を算出する。

図表3-6 アーキテクチャ戦略から得られる総利益の例


戦略名称影響を受けるシナリオ

現在のユーティリティ

期待されるユーティリティ

1発行したオーダー情報の保持

356

707080

90100100

2 オーダーの分割 8 20 60

3 オーダーの統合910

5070

8065

4 オーダーの区分け 4 80 90

5 オーダーの再設定 1 80 92

6 オーダーの再試行 4 80 85

7 オーダーの強制完了 1 80 87

8 オーダー障害の通知67

8087

8590

9細分化したオーダーの追跡

67

8070

9095

10 ユーザ情報へのリンク 7 70 75

戦略影響を受けるシナリオ

シナリオの重み

アーキテクチャ戦略の利益(素データ)

アーキテクチャ戦略の利益(正規化済)

アーキテクチャ戦略の利益(総計)

3 15 20 300

5 15 30 450

6 10 20 200

2 8 5 40 200 200

9 10 30 300

10 5 -5 -25

4 4 10 10 100 100

5 1 10 12 120 120

6 4 10 5 50 50

7 1 10 7 70 70

6 10 5 50

7 5 20 100

6 10 10 100

7 5 25 125

10 7 5 5 25 25

225

3

8

9

1

275

950

150



ステップ８コストとスケジュールの制約の下で、アーキテクチャ戦略をROIに基づいて選択する

各アーキテクチャ戦略に関するコストとスケジュールを決定する。それぞれについて、利益とコ

ストの比率として、ROIを計算する。ROIに従ってアーキテクチャ戦略をランク付けて、予算また

はスケジュールが底をつくまで上位のものを選択する。

ステップ９結果が直感と一致することを確認する

選択されたアーキテクチャ戦略について、それらが組織のビジネス目標に沿っているかどうかを

検討する。もし沿っていなければ、この分析で見落としてしまった問題について検討する。重大

な問題があれば、これらのステップを繰り返す。



３-５．用語の説明

（1）ユーティリティ

品質特性がシステムの利害関係者へ与える利益のことをいい、ユーティリティ値として 1から 100の

数値として現される。

品質特性とユーティリティ値の関係は、ユーティリィティ曲線として 2次元のグラフで現される。

ユーティリティ曲線の作成は以下の方法が挙げられる。

1. 最良のケースの品質特性を決め、それにユーティリティ値 100を割り当てる。

2. 最悪のケースの品質特性を決め、それにユーティリティ値 0を割り当てる。

3. 現状の品質特性と、そのユーティリティ値を決定する。ユーティリィティ値は最良のケース

と最悪のケースからを基準点として、利害関係者から引き出す。

4. 必要な品質特性と、そのユーティリティ値を決定する。ユーティリィティ値は 3と同様最良

のケースと最悪のケースからを基準点として、利害関係者から引き出す。

5. 以上の情報から品質特性とユーティリティ値をプロットし、ユーティリティ曲線を現す。

以下にユーティリティ曲線の例を記載する。

図表3-7 ユーティリティ曲線の例


（2） ROI

アーキテクチャ戦略 iから得られる総利益 Biは次のように計算する。ここで、bi,jは戦略 iがシナリオ j

に与える影響によって生じる利益で、Wjはシナリオ jの重みである。

アーキテクチャ戦略のROIは、総利益 Biと、実装の総コストCiの比として求める。従って以下の通

りに求められる。

100

0

utility

品質特性

100

0

utility

品質特性

∑ ×=j

jji WbBi )( ,

i

ii C

BR =



４．参考文献

［1］ Len Bass ほか (前田卓雄ほか訳)、実践ソフトウェアアーキテクチャ、日刊工業新聞社、2005年、625p、

(ISBN: 4526055239)

［2］ Paul Clements ほか、Evaluating Software Architectures: Methods and Case Studies (Sei Series in

Software Engineering)、Addison-Wesley Pub (Sd)、2002年、323p、(ISBN: 020170482X)

［3］ Architecture Evaluations、（2006年 1月アクセス）、

http://www.sei.cmu.edu/activities/architecture/ata_eval.html

Ⅱ-ⅲ ＩＴアーキテクチャに関連する注目すべき技術

Ⅱ-ⅲ １大規模Ｗｅｂサイトの構築ノウハウ 1

Ⅱｰⅲ １大規模Webサイトの構築ノウハウ

// CONTENTS //

１．序文 ................................................................................................................................................................... 2

２．負荷分析............................................................................................................................................................. 3

３．拡張性設計......................................................................................................................................................... 5

３－１．拡張性入門.............................................................................................................................................. 5 ３－２．インフラの拡張性確保のための６つのステップ.................................................................................. 7 ３－３．陥りやすい落とし穴............................................................................................................................. 10 ３－４．２階層か３階層の選択......................................................................................................................... 12

４．パフォーマンス設計........................................................................................................................................ 12

４－１．Webコミュニケーションについて ..................................................................................................... 13 ４－２．正常なページで問題が発生するとき .................................................................................................. 14 ４－３．良いページとは .................................................................................................................................... 16 ４－４．性能を改善する設計とは ..................................................................................................................... 16 ４－５．顧客満足を得るには............................................................................................................................. 17

５．成長性の予見 ................................................................................................................................................... 18

５－１．キャパシティプランニング方法論入門............................................................................................... 18

６．可用性の確保 ................................................................................................................................................... 24

６－１．始めに ................................................................................................................................................... 24 ６－２．可用性のコンセプトと費用 ................................................................................................................. 24 ６－３．してはならないこと............................................................................................................................. 26 ６－４．共通技術 ............................................................................................................................................... 27 ６－５．まとめ ................................................................................................................................................... 31

７．出典 ................................................................................................................................................................. 32



１．序文

本書はIBMのレッドブックである「Best Practices for High-Volume Web Sites」の要旨をまとめた資料で

ある。原書は130ページにわたる膨大なものだが、本資料は後半のSLA観点は割愛させて頂き、前半のベスト

プラクティスについてまとめている。本書中の図は全て原書を引用させて頂いているがご了解頂きたい。

なお、原書が書かれたのは 2002 年の 12 月であり、その後のネットワーク環境の急速な進歩により高速化、

低価格化が図られ、数値的なものは一部参考にならない点もある。ただし、IBM がいくつもの大規模 Web サイ

トを構築した際の技術的な観点が書かれており、この点についてはシステムを構築する上で非常に参考になる

と考えられる。以下、その内容となる。

Web システムにおいては下図のように Web サーバ、アプリケーションサーバ、データベースサーバの３階層

構造を取ることが多い（図2-1）。

図2-1. ｅビジネスにおける多階層構造

本書では性能と可用性の向上のため、いくつもの大規模システムのトラフィックパターンを分析し、ベスト

プラクティスとしてまとめている。この３階層システムにおけるアプローチは図2-2となる。

図2-2. Webサイトのライフサイクル



２．負荷分析

大規模Webサイト構築の基本はまず負荷の傾向を分析することに始まる。表2-1は以下のWebサイトのパタ

ーン毎にその特徴を整理している。

・Publish/Subscribe

・オンラインショッピングサイト

・消費者サービスサイト

・オンライントレードサービス

・WebサービスベースのBtoBサイト



表2-1. 負荷パターンと特性分析

そして表2-2は一般論となってしまうが、各コンポーネントの特徴を表している。



表2-2. コンポーネントの影響

３．拡張性設計

Web システムではトランザクション量が急に増加することを考慮する必要がある。短期間に単位時間あたり

のトランザクション数が数倍、数十倍になることも珍しいことではない。この拡張性を考える上では、

インフラのコンポーネント毎に適切に対応することが重要となる。特に多階層システムにおいては各層に

おいて分析を実施する必要がある。本章では適切な拡張性と分析のテクニックを説明する。

３－１．拡張性入門拡張性を考える際に、性能(応答時間)とボリューム(単位時間あたりのトランザクション数)の観点で捉える

ことは重要だが、これは単純ではない。拡張性設計の目的は下記となる。

・コンポーネントのサイズを大きくするもしくは性能を向上させる

・コンポーネント/システムの効率を高める

・コンポーネントの負荷を平準化もしくは減少させる

ここで各コンポーネントの改善により他のコンポーネントへの影響が出る事を忘れてはならない。つまり

改善のたびにホットスポットもしくはボトルネックが移ることになるのである。インフラの拡張性を、各層

において拡張限界を増加要求に合わせて設定する必要がある。図3-1は拡張性を考える上での負荷と性能の

関係を示す。



図3-1. 拡張性／性能曲線

拡張性設計の目的は、図3-1にあるように、将来の目標とするレスポンス性能値を満たすように各コンポ

ーネントを設計することである。

また、表3-1は拡張性確保のための技術がその目的にどう適合するかを表している。ここで適用する技術

の内容については3-2節にて記述する。

拡張性確保の技術性能改善効率化負荷平準化

１マシンの性能アップ ×

２サーバのクラスタ化（スケールアウト） ×

３専用マシンの導入 × ×

４負荷のセグメント化 × ×

５バッチでの対応 ×

６ユーザデータの集約 ×

７コネクション管理 ×

８データもしくはリクエストのキャッシュ化 × ×

表3-1. 拡張技術とその目的



３－２．インフラの拡張性確保のための６つのステップシステムの拡張性の実施には下記の６ステップでシステムの改善を図る事を推奨する。

1. アプリケーション環境の理解

2. 負荷の分類

3. 最も影響を与えるコンポーネントの特定

4. 拡張性確保技術の選択

5. 技術の適用

6. 再評価

状況を把握し、問題領域を特定し、適用する技術を選択し、評価を実施する一連の流れが重要となる。

Step1. アプリケーション環境の理解

状況把握の第一歩は全てのコンポーネントの関係を整理することである。そして最も重要なことは

アプリケーションの要件とプロセスを理解し、何が変更できないかを把握することである。アプリ

ケーションはインフラの拡張性に大きな影響を与えるので、必ず把握しておく必要がある。少なくとも

トランザクションタイプとボリュームは各階層別に把握しておく必要がある。階層の例としては図3-2の

ようなものが考えられる。例えばオンラインバンキングにおいてはデータベースサーバでの待ち時間が

問題となるが、ショッピングサイトではアプリケーションサーバの待ち時間が問題となる。層間の

トラフィックを制御することにより、リソース負荷の減少とレスポンスの改善を図ることができる。

従って層別の性能を測定し、トランザクション予測に基づいて改善を図るべきである。

図3-2. 負荷パターンと各層の遅延

Step 2. 負荷の分類

このステップではトランザクションの複雑さ、ボリューム変動、データの不安定さ、セキュリティ等の



観点により分類を実施する。各特徴から見た負荷パターンについては表2-1を参照して欲しい。

また、このステップでは各コンポーネントの特徴を整理する。表 2-2 はこの例となる。これを見て

分かる通り、各コンポーネントは負荷の特徴により異なる傾向を示している。

Step 3. 最も影響を与えるコンポーネントの特定

このステップではサイトの特徴をベースに機能をコンポーネントにマッピングする。コンポーネントの

例としては、エッジサーバ、WebAPサーバ、セキュリティサーバ、トランザクションサーバ、DBサーバ等

が挙げられる。2 章の表 2-2 はシステム負荷パターン別の各コンポーネントへの影響例となるので参考に

して欲しい。

Step 4. 拡張性確保技術の選択

ここはITアーキテクトとしてもっとも重要なステップとなる。管理性、セキュリティ、可用性が設計

上のポイントとなる。ここでは以下のような観点での対応が必要である。

1. より速いマシンを使用するこれはエッジサーバ、Web プレゼンテーションサーバ、WebAP サーバ、ディレクトリサーバ、

セキュリティサーバ、既存の AP サーバやデータベースサーバ、ファイアウォール等で使用できる。

これは単位時間当たりの処理能力を単純に増強するものだが、ソフトウェアのネックにより制限が

発生している場合においては別途検討が必要となる。また、ハード・ソフトの変更によりシステム

管理の変更が生ずる場合もあり注意が必要となる。

2. マシンをクラスタ化するこれは Web プレゼンテーションサーバ、WebAP サーバ、ディレクトリサーバ、セキュリティサーバ

に適用できる。ここではトランザクションの分散がポイントで、サーバを並列にすることにより処理

能力の向上を図ることが出来る。並列処理をすることによりレスポンスの改善が期待できるとともに、

可用性も向上することになる。

3. アプライアンス・サーバを使用このテクニックはエッジサーバ、Web プレゼンテーションサーバ、ディレクトリサーバ、セキュリ

ティサーバ、ネットワーク、およびファイアウォールに適用できる。この目的は特定の動作を実行

するのに適した専用マシンを使用することにより、特定のコンポーネントの効率を高めることである。

4. 負荷を区分するこのテクニックは Web プレゼンテーションサーバ、Web アプリケーションサーバ、データサーバ、

イントラネットファイアウォール、およびネットワークに適用できる。この目的は負荷を管理可能な

単位に分割する事により、予測可能で安定したレスポンスを得るものである。これによりどのサーバ

を管理すれば良いかが容易にわかると共に、ビジネスの拡張に合わせてシステムを再構成することが

容易となる。

5. リクエストのバッチ化このテクニックは Web プレゼンテーションサーバ、Web アプリケーションサーバ、ディレクトリ、



セキュリティサーバ、既存のビジネス・アプリケーション、およびデータベースに適用できる。これ

は複数のリクエストを一括してまとめることにより負荷を軽減するものである。ただし、送られて

くる各メッセージ間の依存性がある場合はそのアプリケーション対応コストが発生することになる。

6. 利用者データの集約これは Web プレゼンテーションサーバ、Web アプリケーションサーバ、およびネットワークに適用

される。これはよく使われるユーザデータをアプリケーションレベルでキャッシングして提供するも

ので、レスポンスの改善が期待できる。

7. コネクションの管理このテクニックはWebプレゼンテーションサーバ、Webアプリケーションサーバ、およびデータベ

ースに適用される。これは各階層においてコネクションをプールすることによりこれを再利用して効

率化を図るものとなる。たとえばデータベースやWebアプリケーションサーバなどでは、よくこの手

法が用いられる。

8. キャッシュキャッシュはハードウェアと管理コストを低減し、応答時間を改善するテクニックで、アプリケー

ションやデータベースを含む全階層にて用いることが出来る。これは要求から応答までのパスを短縮

することにより、コンポーネントのリソース消費を押さえ、性能向上と拡張性の双方を満たすことに

なる。この手法は静的及び動的なWebPageに使用できる。

指数的にトランザクション増加する場合において、ハードウェアの増強を考える前に、下記の２つの

点を検討する価値がある。

・アプリケーションサーバにおいてシステムの拡張はマシンの追加が基本となる。よって複数のサーバ

で稼働させることを前提として設計すべきである

・データベースサーバが分割できない場合は最初に大きめ（３倍以上で取るユーザもいる）に設計する。

ただし、可能であればサーバを分割する事も考える。

アプリケーションサーバとデータベースサーバはできればサーバを分割する。そしてWebサーバは低価

格なサーバに、アプリケーションとデータベースは信頼性の高いマシンに実装すべきである。そして性能

改善で最も効果があるのはデータベースサーバになる。データが大規模でないサイトでは大部分をメモリ

にキャッシングすることにより改善を図っている例もある。



Step 5. 技術の適用

上述のテクニックの適用に当たっては、特定箇所だけに注目するのではなく、その関連するコンポーネ

ントへの影響を考慮すべきである。図3-3は各層のコンポーネントとテクニックの典型的な関係を表す。

これにより各コンポーネントに対して適切なテクニックを適用できるだろう。ただし、下記の理由により

全てのテクニックが適用できるとは限らない。

・投資する余裕がない

・必要性を認知できない

・投資対効果から考えて必要性がない

図3-3. 拡張技術と適用対象

IT アーキテクトとしては効果が最大限に得られるテクニックを適用すべきである。図 3-3 はあくまで

どのコンポーネントに焦点を当てるかの出発点にしか過ぎない。

Step 6. 再評価

全ての性能問題においてチューニングは不可欠となる。繰り返しボトルネックを排除し、排除できない

問題は管理し対応する。例えばあるプロジェクトでは下記の手順を適用して改善を図っている。

・増加するWebサーバスレッドにおいて要求を平行に処理する数を増やす。

・I/Oボトルネックを減らすためにデータベースにインデックスを追加する。

・スレッド化されたアプリケーションにより、多くのヒープを使用できるようにパラメータを変える。

・キャッシュを使用してデータサーバへのアクセスを減少させる。

・エッジもしくはアプライアンス・サーバの数を増やして負荷バランスをとる。

・スループット改善のためデータサーバをアップグレードさせる。

３－３．陥りやすい落とし穴以下にシステム構築の各フェーズにおいてありがちな問題を挙げる。



計画フェーズ

顧客はしばしば将来の成長に対して無頓着で、経営計画の方向性が IT にどう影響するか考慮してくれ

ない。例えば特売を打つ際にITシステムでの対応が必要だと思いつかないといったこともある。

また、e-ビジネスのインフラ同様にビジネスプロセスの見積もりも出来ない事もある。例えば在庫不足

にもかかわらず注文を受けてしまうといった、ビジネス上の問題が発生しないような設計を心懸ける必要

がある。

アーキテクチャ設計フェーズ

ビジネス上の問題やアプリケーション構造の見直しをせずにシステムを設計しようとする開発者が

いる。決してプログラム作成やミドルウェアへ実装を急いではいけない。負荷の増大に対してHTTPサーバ

やWebアプリケーションサーバのバランスを取るとか、コスト、保守性、拡張性の各問題についても考慮

する必要性がある。

また、顧客は将来の負荷増加により制約が発生するとは思ってはいない。システムの構造としては予期

せぬ成長に耐えるようにすることが望ましい。例えば拡張性を考えてサーバ１台で始める際にもロード

バランサを組み込んでおくといったことが必要となる。

設計フェーズ

顧客は性能を考慮した設計をしない。利用者はページの表示に8秒以上待たないと言った事を設計者側

で考慮する必要がある。

開発テストフェーズ

多くの場合、開発に追われるあまりテストフェーズを軽視しがちとなる。負荷テストはボトルネックを

特定するためにも、スケーラビリティを明確にするためにも有効である。

実装フェーズ

コントロール手順の不足はサイトの停止や性能低下を招く。複雑な多層の Web システムでは横断的な

協力体制が必要となる。ネットワーク、ファイアウォール、UNIX、メインフレームの担当者それぞれが

協力して対応する必要がある。



３－４．２階層か３階層の選択単純な２階層のシステムはプレゼンテーションとビジネス論理を第１層、データ層を第２層とする。プレ

ゼンテーション層とビジネス論理層を分けて３層にする事も考えられる。図3-4は典型的な多階層の事例と

なる。

図3-4. ２、３、４階層の事例

４．パフォーマンス設計

Web ページにユーザをつなぎ止めるには第一印象が重要となる。もしページ表示が遅ければ、ユーザは二度

とアクセスしないだけではなく、口コミで評判が伝わることになる。電子商取引サイトの場合、これは致命的

な問題になる。

本章ではいくつかのケーススタディを通して、ページ表示性能の改善と、サイトの同時アクセス許容量を

増加させるための設計手法について述べる。

Web サイトの設計に絶対的な方法は存在しない。ちょっとしたサイトでもデザインや操作性と性能の

トレードオフは存在する。IBM では性能測定のツールがあるが、これはページ表示のタイミング、サイズ、

内容、項目のソースを分析するものになっている。



エンドユーザの反応に影響を及ぼす５大要素は下記となる。

１．ページに含まれる内容（情報）

２．内容の表現（Look & Feel）

３．プレゼンテーション効率（サイズ）

４．内容の構成（パッケージ）

５．Webサイトの管理（配布）

IBM のツールでは内容と表現は測定不能だが、効率、構成、配布に関する改善には有効となる。つまり性能を

最適化するためのWebページの設計基準と方法を支援する。

４－１．Webコミュニケーションについて Web にて 1 ページをダウンロードするまでの時間には多くの要素との相互作用がある。この要素を理解し

ていればダウンロード時間を最適にするページ設計が可能となる。図4-1はブラウザからWebサーバまでの

パスを簡略化して示している。Web サイトの構成によっては複数タイプ（データ、イメージ、プロキシ）の

サーバがあり、場合により複数サイトに分散している場合もある。

図4-1. Webコミュニケーション概要

クライアントはまずwww.xxx.comといったWebサイト名を入力する。ブラウザはこの要求に基づき、通常

DNS(Domain Name Service)およびUDP(User Datagram Protocol)を使用し、www.xxx.comのようなFQNｓ（fully

qyakufued names)から 123.321.456.34 といった IP(Internet Protocol)アドレスを引く。そして DNSは、IPアドレスを得るために接続をDNSサーバに組み込む。ブラウザが IP アドレスを得ると HTTP(HyperText Transfer Protocol)要求を開始する。HTTP は

TCP(Transmission Control Protocol)上で動作する。次に何が起こるかは通信を保証するかによる。

セキュア通信ではないなら、ブラウザは Web サーバに直接 TCP/IP で HTTP 要求を送る。これにより、Web



サーバとの間で確立した接続を管理する仮想的な機構（いわゆるソケット）が生成される。

セキュア通信なら、ブラウザはファイアウォールとの間で調停するセキュリティパッケージである Socks

サーバへ、HTTPS(保証された HTTP)要求を送る。要求の前後でこのセキュリティの調停が発生する。また

サーバは要求を受けてファイアウォールを経由して応答を返すためのソケットを参照する。

サーバは完全な end to end の通信を確立すると、サーバはページを構成する項目情報の要求を上げる。

ページは１つ以上のテキストファイル(HTML:Hypertext Markup Langage)、画像ファイル(GIF:graphic image

files)、音声クリップ、ビデオクリップそしてアプレットにより構成されている。HTML仕様はページの形式

と内容を決定する。サーバへのヒットによりクライアントへ送る操作が決定される。最初のクライアントの

要求とサーバから返答が帰るまでの時間差がサーバレスポンスと呼ばれる。

この通信プロトコルの設計によりブラウザもしくはWebサーバが他のコンポーネントに待たされる時間が

長くなる。この待ち時間の積み重ねでサーバレスポンスが長くなって行く。またサーバとブラウザ間の距離

が遠いほど、ブラウザとサーバ間の中間リンクが増えて遅くなる。遅延はブラウザやサーバ自身を含むハー

ド／ソフトコンポーネントによりさらに追加される。また、各コンポーネントで固定的に発生する遅延の他

に、コンポーネントのキューの状態により問題となる遅延が発生することもある。

Webサイトの見積もりのためには3-2節の拡張性設計を参照して欲しい。

４－２．正常なページで問題が発生するとき「最初の世代」の設計者たちは、顧客を引きつけ再アクセスさせるために見た目にこだわった。最近では

顧客へのアピールよりもレスポンスを向上するように再設計する例が多い。最終目標はあくまで内容と性能

のバランスを取ることにある。

ダウンロード時間に影響するものにはページのサイズ(KByte)、項目数と複雑さ、アクセスするサーバ数、

SSLの使用可否等がある。表4-1は実際の計測例となる。２つの違いは通信を保証するかどうかにある。

表4-1 ページダウンロード測定項目

このような計測値を判定する基準としては表4-2が挙げられる。



表4-2良い基準値

レスポンスは３０秒とあるが、世界クラスで見ると２０秒以内が望ましい。レスポンスの基準としては表4-3

になる（注：ネットワーク環境の変化により現在は値の大幅な見直しが必要）。

表4-3 ページロード時間のランク付け

Web システムの設計においては誰も意図して遅いページを設計したりしない。以下は、予期せず問題と

なったWebページの改善例となる。

・スペーサ GIF は一般的にページ上の領域を確保するために使用される。キャッシュ環境においてこの

スペーサ GIF を HTML 上で近接して置くと、最初の要求がキャッシュする前に次の要求を呼び出して

しまう。最初の要求をもっと早めることによりレスポンスはキャッシュされてシーケンスを短縮する

ことが出来るようになる。

・静的GIFにおいてサーバ上でキャッシュを許さない設定の場合、ブラウザに余裕があってもキャッシュ

されない。

・項目が多すぎることも問題となる。項目のサイズと数の決定的なルールは存在しないが、項目数と

サイズは少ないに越したことはない。サイズで大きな比重を占めるイメージデータについてはその数を

減らすか、解像度や色数を調節してデータの転送量を減らすようにすべきである。

・あるオンラインバンキングシステムでは、項目数やサイズの見直しの他、無駄な暗号化を省略すること

によりホームページの表示を15分から26秒に短縮できた。こうしたHTTPのチューニングによりダウン

ロード時間を短縮するだけではなく、Webサイトのキャパシティを増加させる効果もある。



４－３．良いページとは一般的にページ設計のあるべき姿は下記となる。

・ビジネス価値に応じて項目数や複雑性を考慮すること

・複数のサーバを見に行かないこと

・接続は固定化すること

・項目の要求は早めに実施すること

・ブラウザのキャッシュを活用すること

・個人情報を個人的なページと安全な個人的なデータだけに割り当てること

・ HTMLソースから無駄な余白を取り除くツールを使用すること

また、ユーザの視点から見栄えのスピードを改善する方法としては下記がある。

・主要項目は出来るだけ早くリンクを張ること

・ダイレクトリンクを使用すること

・ホットなビジュアル項目を使用する

４－４．性能を改善する設計とは良いページ設計のために設計者はビジネス価値に見合うサイズと複雑性を考慮する必要がある。しばしば

設計者は LAN 上での接続を前提に考えがちだが、WAN 経由でのユーザの事を配慮して設計することが重要と

なる。考えるべき要素としては下記の項目を挙げることが出来る。

・項目数、サイズ、複雑さ

・ポートの数

・アクセスサーバ数

・余白の使用

・ロードシーケンス

・データ機密保護

項目数、サイズ、複雑性の管理

各観点にてそのポイントを述べる。

項目数：下記のような性能改善のテクニックがある。

・グラフィックを要素とする表は遅いのでメニューとする

・項目を結合する

・アニメーションGIFを避ける。ダイナミックに表示が変更されるGIFは面白くはあるが、項目数を増

やす要因となる。

サイズ：伝えるべき内容に応じた項目サイズに抑えるべきである。

複雑さ：複雑さの要因としては、表、サイズが動的に計算される表セル、Java スクリプト、Java アプレッ

トなどがある。動的 GIF、イメージカラー管理、イメージディザリングは遅くなる要因となる。こ

れらは改善される傾向にはあるが、注意が必要となる。

HTMLのファイル数と項目数はページの複雑さの指標となるが、ユーティリティによりコードサイズを減少させ

ることができる。例えばGZIPによりHTMLの通信サイズが８０～９０％減少する場合もあり、HTMLファイルを

コンパクトにすることが重要である。



接続数の管理

Webサーバからの情報はTCP/IPソケット接続を通じて伝送されるが、事前に接続を開く必要がある。それぞ

れの接続においてセットアップとダウンロードが必要となるが、特定の接続がネックとなることが多いので

以下の注意が必要となる。

・固定的な接続を張ることによりセットアップのオーバーヘッドを減らすことができる

・機密保護された接続は、よりセットアップ時間が大きくなる

しかしながら固定的な接続はサーバのポートを消費するだけではなく、スレッドのようなサーバリソースを

消費するため、そのバランスが重要となる。適切な値はページあたりの接続を4つ以下に抑えることとなる。

アクセスサーバ数の管理

情報が複数のサーバにまたがっているときは、サーバ数だけの接続を張る必要がある上に障害時の対応も

複雑となる。できるだけサーバが複数にまたがらないよう設計すべきである。

余白の管理

余白を適切に管理できればダウンロード時間の短縮につながるだけではなく、サーバの負荷も軽減する。

設計者はページをイメージするために余白を挿入するが、ブラウザは別に必要としない。ソースHTML上の余分

な余白を取り除くツールを使用したい。

ロードシーケンスの管理

ページのダウンロード処理では複数の項目を並列に実行すると共に、処理の重い項目を先に実行して

トータルスループットを上げるべきである。

データ機密保護の影響を理解する

個人情報は保護する必要はあるが、SSL 処理と暗号化はレスポンスを遅くする要因になる。個人情報を取り

扱うページを明確に切り分けて暗号化の範囲を限定することを考えるべきである。

４－５．顧客満足を得るには顧客満足を得るためにもデザインの検討項目として前節であげたポイントを採用すべきである。性能の

専門家を設計チームに加える事が理想であり、これによりサーバの投資タイミングを遅らせることができる

かもしれない。



５．成長性の予見

ｅビジネスが「Web 速度」で成長するとき、インフラは拡張性と性能、そして効率性を要求される。そして

CIO とそのチームは障害時間を最小にし、ネットワークのボトルネックを取り除き、マシン効率を最大化する

べく格闘することになる。

大規模Webサイトの大部分は図5-1の様に複数のマシン階層で構成される。各階層は性能と可用性の確保の

観点から複数のサーバで構成される事が多い。

図5-1.ｅビジネスのためのインフラ階層

５－１．キャパシティプランニング方法論入門ここでのキャパシティプランニングの方法論は数多くのWebサイトの分析をベースとしている。この方法論

は以下の４ステップから成る。

Step1．負荷パターンの特定

Step2．サイトの性能測定

Step3．傾向の分析とパフォーマンス目標の設定

Step4．インフラの代替案モデル

サイトの新規設計、サイトの変更のどちらにもこの方法論は適用できる。以下にこの方法論を詳説する。

Step1．負荷パターンの特定

負荷はデータやトランザクションといった規模の他に、複雑さ、データの安定性、セキュリティなどにより

特徴づけられる。この負荷パターンは下記の５つに分類することができる。

・publish/subscribe

・オンラインショッピング

・顧客セルフサービス

・トレーディング

・B to Bサービス

分類するために下記に各負荷パターンの特性を記述する。

・publish/subscribe



publish/subscribe サイトとは新聞や雑誌情報、イベント情報提供のような検索エンジンを含むメディア

サイトとなる。サイトの内容はページレイアウトを含み頻繁に更新される。検索件数は多くないが、他の

タイプに比較して項目の種類は多くなる傾向にある。また他のタイプに比較してデータは安定しており、

取引も少なく、レガシーシステムとの連携もない。

・オンラインショッピング

オンラインショッピングは情報を検索して商品を購入するサイトとなる。publish/subscribe サイトより

はトラフィックが高くなるが、項目数はそれほど大きくない。トランザクションはピーク時で10万から300

万件で、ヒット数からいくと 100 万から 1300 万以上になる場合もある。販売サイトなのでセキュリティ

要件は厳しくなる。publish/subscribe サイトに比較してレガシーシステムとの接続は多くなるがその他の

サイトほどにはならない。

・顧客セルフサービス

これはホームバンキングや旅行代行業の様なセルフサービスの支援サイトとなる。データは通常複数の

レガシーシステムがソースとなりデータの一貫性が問題となる。セキュリティは特にバンキングや旅行代行

サイトにて問題となる。検索トラフィックは低いが、トランザクションは増加傾向となる。

・トレーディング

これはユーザの売買サイトとなる。内容は変化が激しく、トランザクション量は多くて複雑な処理である。

アプリケーションサーバ製品はこのようなシステムで重要で、レガシーシステムとの接続も問題となる。

ほとんどのトランザクションがバックエンドサーバのデータを必要とし、セキュリティも重要となる。検索

トラフィックは低い。

・B to Bサービス

ビジネスサイト間の取引である B to B サービスは、複数のレガシーシステムをアクセスするため、

データの一貫性が問題となる。セキュリティはオンラインショッピングと同等となる。トランザクション量

は増加傾向である。複数の IN/OUT がありトランザクションは複雑である。通常このパターンには以下の

2スタイルが存在する。

１．ビジネス間接続

これはサプライチェーンのような対等な立場間の取引を含む。

２．ｅマーケットプレイス

これは複数購買者と複数供給者間の取引となる。



Step2．サイトの性能測定

将来を計画するためには現状を把握する必要がある。ボリューム（ヒット数、ページビュー、トランザクシ

ョン数等）、到着率、クラス毎の応答時間、ユーザセッション時間、コンカレントユーザ数、CPU やディスク

使用率といった特性を測定する必要がある。

Web サイトでは負荷パターンの複雑さがリソース要件、スループット、レスポンスに影響する。最適に

コントロールしなければSLAを実現することはできない。図5-2はページデザイン測定基準をまとめたものと

なる。緑色は問題のないレベル、黄色は好ましくないレベル、赤色は容認できないレベルとなる。

図5-2.Webページの計測例

負荷の測定基準の理解

負荷パターンの分類のためにはサイトの複雑さを計測する必要がある。まず、要求がどのように Web

サイトに到着するかにより負荷パターンを定義し、ユーザ要求のクラスを決定する。このクラスは、トラン

ザクションの偏りと依存関係および周期性により特徴づけられる。

トランザクションの偏りと依存構造

長野オリンピックやウィンブルドンのように特定のイベントに依存してピークが発生するサイトでは、

ピークが局所的かつ不規則に発生する。このようなサイトではピークに合わせて十分な余剰リソースを確保

する必要がある。例えば大規模オンライン取引のサイトでは余剰リソースを通常の３倍確保している例も

ある。



周期性

Web サイトの中には月末や朝夕といった特定の周期性を持ったピークが存在するものがある。このような

周期性を配慮した設計が必要となる。SLA を考慮するとピーク値とそのピークが持続する期間を見極める

ことが重要となる。そしてピーク値に対して不測の事態に対応するための余力も必要となる。以下は拡張性

を確保するためのテクニックの説明である。

サイトの測定基準の獲得

それぞれの負荷パターンにおいて測定基準が必要となる。表5-3はあるオンラインショッピングサイトの

例となる。

表5-3 オンラインショッピングサイトの測定基準例

測定基準を明確にした後は、スクリプト処理のの流れを追うことによりサイトの性能についての見極めが

可能となる。このスクリプトの流れを図5-2の様な変遷図にまとめると理解しやすくなる。

図5-2 オンラインショッピングサイトにおける変遷図の例



Step3．傾向の分析とパフォーマンス目標の設定

システムの負荷は増加傾向にあるのでハード/ソフトの性能向上が必要となる。Step2 の測定基準に基づき

将来の傾向を分析、予測してその傾向を見る必要がある。表 5-4 はオンラインショッピングサイトにおける

経営目標における各指標を示す。

表5-4 オンラインショッピングサイトにおける目標指標

IBM には過去のデータ系列から将来の傾向を予測する方法論がある。この予測の方法論は IBM のノウハウで

ありここでは詳しく述べられていない。しかしながらいくつかのシステム構築の経験者であればstep2の分析

の観点を参考に設計のための予測は可能であろう。

Step4．インフラの改善モデル

以上の観点からサイトのインフラを構成する各コンポーネントの要件を決定する事ができる。IBMでは図4-3

の様に３ステップで性能設計を実施する。

まずビジネスモデルではeビジネスパターンと負荷パターン定義する。そしてトランザクションのタイプと

ルートから負荷パターンを想定する。つまりトランザクションのパターン毎に各階層を通るパスを捉え、層間

のキューを考慮して待ち行列分析して性能を予測する。そしてユーザの要件より各クラスの要件を明確にし、

ハードウェアとソフトウェアのリソース要件に落としてインフラモデルとする。



図5-3.性能設計モデル

こうして設計したWebサイトのインフラモデルのサンプルが図5-4となる。このモデルの特徴は以下。

・ Webサイトは複数のマシンレイヤーからなる

・ロードバランサーは複数のWebサーバにトランザクションを振り分け、負荷を調整する

・ WebAPサーバはビジネスロジックを実行する

・バックエンドのDBサーバは更新情報に基づくデータを表示する。

図5-4.インフラモデルのサンプル



６．可用性の確保

６－１．始めに従来 IT システムの可用性については比較的限定された環境下で考えられてきたが、インターネットの

普及によりそれが変わりつつある。つまり電子ビジネスの進展により、ちょっとしたシステムの停止が

ビジネスに対して大きな影響を与えるようになったのだ。さらにグローバル化、企業倫理の追求、M&A、

サーバ統合などにより可用性の標準的な考え方が変わりつつある。

Web サイトは高トランザクションになるだけではなく、システムが多階層化により複雑となり障害

ポイントも増えてきている。本章では大規模Webサイトにおける可用性の考え方と技術について説明する。

６－２．可用性のコンセプトと費用本節では可用性、高可用性、業務継続性について述べる。

可用性はある単位時間のうちシステムが使用できない時間を除いた割合で表示される。一般的に高可用と

はこの比率が99.99%以上のものを指す。これは単にハードウェアのダウンタイムだけを考慮するのではなく、

オペレーティングシステムを含むソフトウェア、ネットワーク、人的障害など無数の要因を含めて業務の

稼働を保証する必要があることに注意したい。

業務継続性とは障害停止の他にメンテナンス等の計画停止も考慮して 365 日 24 時間業務を継続させる

ことのできる能力を指す。これは図6-1で表すことができる。

図6-1.業務継続性

可用性を考慮する上で考える要因としては障害の頻度、障害停止時間、障害の範囲がある。この可用性に

ついて、１年のうちで停止が許容される時間を表にすると表6-1となる。



表6-1.可用性毎の停止許容時間

システムの可用性を考慮する上では、様々な要素を考慮して全体のバランスを取る必要がある。例えば

図6-2はeビジネスインフラにおける構成要素を表す。

図6-2.eビジネスインフラストラクチャにおける可用性の例

システムの可用性は、それぞれの要素の可用性を掛け合わせることにより計算することができる。この例

でいうと各要素はすばらしい可用性ではあるが、システム全体でみると 87%の可用性にしかならないことを

注意したい。

可用性が低いための損害

障害停止、性能低下、計画停止はビジネス機会、コストおよび顧客満足に重大な影響を与える。システム

停止による損害コストは下記の式で表すことができる。

顧客の生産性（＝１時間あたりのユーザコスト×業務停止時間）

＋IT生産性損失（＝１時間あたりの従業員×生産性）

＋顧客サービスへのインパクト

＋減収（＝１時間あたりの収入×システム停止時間）

＋その他のビジネスロス（＝残業時間＋消費資材＋ペナルティコスト）

減収については影響の大きいコストになるが、定量化は難しい。

業務継続性のために考慮すること



可用性を向上するには様々なコンポーネント、人、プロセスを安定的に運用し、統合的なシステムとして

考える必要がある。高可用性はまず信頼できる製品から始まる。しかしながら製品だけではなく、インフラ

ストラクチャや可用性を考慮したアプリケーション設計、およびSIが必要となる。

トレードオフを考慮する

高可用なシステムを実現するには可用性向上のためのコストと、システム停止による損害のバランスを

取ることが必要となる。図6-3はこのトレードオフ分析の考え方を示している。

図6-3.損失コストと可用性実現コストのトレードオフグラフ

６－３．してはならないこと以下のような運用が可用性を損なう要因となる。

・ユーザの可用性に対する認識やエンド－エンドの可用性よりも個別コンポーネントやツールの

可用性に焦点を当ててしまう

・下記の項目について十分考慮されていない

－管理ポイント

－長期計画

－変更計画

－問題分析/管理－人材育成－プロセス定義と再現性

・アプリケーション設計においてビジネスの継続性要件を考慮しない

・現状製品の可用性を活かさない

Web 環境においてはさらに ISP の可用性、クライアントアフィニティ、コンテンツ管理、DNS サーバ、

システム管理についても考慮が必要となる。リクエストが急増してレスポンスの極端な悪化や、サイトの



クラッシュを引き起こす可能性があるからである。

６－４．共通技術以下にシステム停止の頻度、期間、その範囲を減らすためのテクニックを述べる。

・可用性を向上させるアプリケーション設計

・可用性を促進するITプロセス保証

・可用性のためのインフラ設計

可用性を向上させるアプリケーション設計

Web サイトのアプリケーション設計においては性能や可用性、柔軟性について考慮が必要である。

可用性に対して考慮すべき点としては下記が挙げられる。

・設計者や開発者に対し障害発生時のコストや問題点について教育する

・アプリケーション設計の早い段階で専門家を投入する

・現状の製品の特徴を把握する

・合意した可用性要件に合ったコンポーネントを採用する

・データのアクセスやデータ管理に配慮する

・障害の範囲を最小にする

－他のコンポーネントへの影響を抑える

－セッション制御やデータベースなどの機能を独立させる

－各機能において冗長性を高める

・アプリケーションのリカバリや初期化処理を高速かつ簡易にする

・計画停止に対してアプリケーション上の代替策を講じる

・バッチがオンライン処理に影響を与えないように設計する

・標準のプロセスや手順を定義してありがちな障害を減らす

・使いやすく信頼のおける障害監視や意志決定のためのツールを導入する

システムはハードやソフト、ネットワーク等様々なベンダーの製品を組み合わせて出来ており、可用性

を考慮するとシステマティックで網羅性の高いテストが必要となる。



可用性を向上させるITプロセス保証

可用性はITプロセスに大きく左右される。よって良く理解され良く管理されたプロセスが不可欠となる。

ITプロセスにおいて考慮すべき点は下記が挙げられる。

・可用性の管理と維持の戦略もしくは計画を立案する

・サービスレベルの達成度を監視する

・エンドユーザの可用性を監視・分析しフォローする

・可用性に対して下記の依存関係を監視・管理する

－問題管理

－変更管理

－復旧管理

－キャパシティ管理

－構成管理

－設計開発プロセス

－テスト

・アーキテクチャや設計において可用性を保証する

Web システムはフロントエンドからバックエンドのレガシーシステムまで多くの異なるリソースから

構成される。従って環境を統合的に管理するため、以下のようなシステム構築への配慮が必要となる。

エンドユーザ観点での可用性管理

Web サイトの可用性については常にエンドユーザを意識する必要がある。「ページが見つかりません

でした」といった障害だけではなく、下記の２つの観点での対応が必要となる。

１．ユーザが常に接続され素早くアクセス出来るように、認証の自動化や的確なリソースへの

アクセスをさせること

２．接続されているときには一定時間での応答できるよう、ページの応答時間を設計すること

ビジネスプロセスについて考慮する

リソースはビジネスプロセスの中で管理すべきである。管理者がビジネスプロセスを構成する全ての

リソースを管理出来るようにし、適切な対応が図ることが出来るようにする。

一貫したコンプライアンス指針により可用性を保証する

可用性を妨げる一番の要因はセキュリティ違反によるダウンタイムである。開発者、セキュリティ管理

者、運用者が決められたセキュリティやプライバシー指針を守っていれば、ユーザの追加削除等において

もセキュリティレベルに違反した操作がされることはない。

全てのインフラ資源の可用性を管理する

経験則で管理できなくなるなら、管理者がシステムの状態を把握できるツールを用意すべきである。

ハードウェア、OS、ネットワークセキュリティ装置、ミドルウェア、アプリケーション等、Web サイトを

構成するコンポーネントの管理が必要となる。

システム資源の適正化を図る



バージョンの違いによりシステム停止に陥らないよう、ソフトウェアの配布やアップグレードが可能な

ツールを用意する。

インフラの負荷スケジューリングを自動化する

障害が起こってもシステム停止を避けるべくスケジューリングすることが必要となる。

データ管理の履歴を残す

システム管理上の問題解決のためには大量のデータが発生する。このデータはサービスレベル管理、

キャパシティプランニング、セキュリティ監査等に使用できるよう、データベースとして管理すべきで

ある。このようなアプローチにより、要件が時間と共に変化してもキャパシティの傾向を把握し管理する

ことが可能となる。

可用性のためのインフラ設計

Webサイトはファイアウォールからデータベースまでいくつかの階層に分かれて構成される。通常はWeb

サーバ、WebAP サーバ、トランザクションサーバ、データベースサーバ等となる。このように複数階層で

構成すればハードウェアの交換は容易になるが、ソフトウェアの品質確保は難くなる。可用性を向上する

には効率的な設定、チューニング、教育が欠かせない。

また、冗長性は可用性の向上に最も用いられる手段となる。これにはコンポーネント、システム、

データそして人の冗長性が含まれる。図6-4は各階層で冗長性を持たせたシステムのサンプルとなる。

図 6-4. 複数階層のインフラにおける高可用設計

そして復旧の時間短縮や人為的ミスを低減するために自動化は必須となる。

ハード・ソフト両面のクラスタとロードバランス

クラスタはインフラに高い可用性と拡張性をもたらす。そしてロードバランサと組み合わせることに



より、IPアドレスを各サーバに振り分けることが出来る。ロードバランサは相手サーバが稼働しているか

を判断して切り替えをするため可用性が向上する。また、共にサーバ追加も容易となる。

表6-2に各コンポーネントにおいてクラスタ構成において配慮すべきポイントをまとめる。

コンポーネント冗長性とロードバランスに関する考察

外部接続複数のインターネット接続サービス業者(ISP)と契約することにより個別

のISPの障害で業務が停止することを防ぐ。

DNS（Domain name server）代替のDNSサーバを用意する。

ロードバランサバックアップ用のロードバランサを用意し、プライマリとハートビートで

接続する事により、フェイルオーバを可能とする。

外部キャッシュロードバランサに対応して外部キャッシュも冗長化を図ることにより可用

性を向上させる。

ファイアウォールファイアウォールも冗長化して負荷バランスを取る。ファイアウォール接

続時間は長くなる傾向があり、負荷分散の結果もセッションの開始から終

了まで保持する必要がある。

Webサーバ、Apサーバサーバ構成を冗長にし、負荷バランスを図ると共に可用性を向上する。各

サーバは機能的に偏りが無いように配慮する。

ディレクトリサーバサーバ構成を冗長にし、負荷バランスを図って書込禁止状態にする。書込

操作はプライマリのみとしてそれをバックアップサーバに反映させる。

データベースフェイルオーバクラスタ構成とし、アプリケーションやセッションの回復

を図る。

サーバ間の物理接続物理的な接続も冗長化する。

表6-2. 各コンポーネントでの配慮ポイント

エッジサーバへの配慮

エッジサーバはeビジネスにおいて拡張性、信頼性、性能を満たすためのインフラと位置付けられる。

その機能は負荷バランスの調整を図ると共に、アプリケーションサーバの弱点を補強する。

このようなエッヂサーバには HTTP や FTP といったプロトコルを見てネットワークディスパッチする

ロードバランサやProxy等の履歴をみてキャッシングするサーバ等がある。

装置の接続における可用性への配慮

サーバ間の接続についても冗長化を持たせて障害時の代替アクセスを可能にすべきである。クラスタや

FTサーバ等を用いてサーバの可用性を上る場合には特にこのような配慮が必要となる。

コネクションプーリングはデータベースサーバやトランザクションサーバに対する接続のための

リソースを最小化するものである。特に非同期メッセージングにて通信する場合はこのコネクション

プーリングがリソースの使用を削減するために有効となる。

偶発的な消失、ウィルス、災害からデータを守るには

SAN を使用した集中バックアップと障害復旧ソリューションはミッションクリティカルなビジネス

データを管理する上で非常に重要となる。ストレージ管理ツールを導入して、偶発的なデータ消失、



ウィルス感染、ハードウェア障害、災害によるサイト被害等の障害に対し、ファイルやディレクトリ、

ファイルシステム、データベースの復旧を可能にする必要がある。

そのようなツールの要件として下記が挙げられる。

・高いデータ可用性を持つ

・被害を最小限に留めるバックアップが可能

・素早く簡単にかつ完全なデータリカバリが可能

・災害が発生しても明確かつ正確なディザスタリカバリが可能

SANの可用性

SAN はサーバとストレージ間の接続を自由に構築できる、管理されセキュアな情報インフラであり、

下記の特徴を持つ。

・リソースの普遍的なアクセスと共有を容易にする

・予測できない成長を遂げる情報技術(IT)に対応する

・手頃な24時間365日の可用性を提供する

・資源管理が集中化し、簡素化される

・情報保護と障害対応を図る

・セキュリティとデータ保全を高める

SAN はファイバーチャネル技術を使って分散ネットワーク環境と統合できるようになってきた。そして

ダイナミックにストレージ構成を変更できることにより、複数サーバからの共有を可能にした。そして

サーバ間でデータを引き継ぐことにより、サーバの故障からのリカバリ構成を容易に組むように出来る

ようになった。そしてサイト間をまたがる「クローニング」技術により災害対策への対応も図れるように

なった。

災害に対して複数のサイトを立てる

非常に高可用なWebサイトを要求する顧客へは、以下のような災害への対応を考慮して物理的に離れた

サイトにシステムを構築すべきである。

・コンピュータ電源ダウン

・ネットワークサービスプロバイダに起因するネットワーク切断

・需要のピークやアタックによりサイトの負荷オーバーが発生する

・物理災害

複数のサイトで適正な設定をすれば下記のメリットを得られる。

・高い可用性と信頼性

・サイト間のロードバランス

・「賢い」キャッシュ機能

しかし、サイトを複数持つことによりフェイルオーバーに関して複雑な要素も増える。また、サイトの

障害に備えてバックアップサイトに十分な余裕が必要となる。

６－５．まとめ最近の Web サイトは 365 日 24 時間の連続稼働が当然となり、大規模 Web サイトはますます高可用性が

必要となってきている。e ビジネスが始まった当初は必ずしも可用性が重要視されてはいなかったが、



今一度基本に立ち返ってインフラを考え直す必要がある。本章の構築ノウハウは下記の要請に答えるもので

ある。

・アプリケーションをより高可用に設計すること

・ ITプロセスをより可用性を持って保証すること

・インフラを高可用に設計すること

可用性を達成するためには技術、企業文化、システム管理、アプリケーション設計、さらには組織体系

まで繰り返し訓練が必要となる。本章はワールドクラスのシステム管理において、障害や災害に対する適切

な対応を取るための理解を深めるものである。

７．出典

［1］Best Practices for High-Volume Web Sites(Authored by the "The High-Volume Web Sites Team")、

http://www.redbooks.IBM.com/redbooks/pdfs/sg246562.pdf


Ⅱ-ⅲ ２ビジネスグリッド 1

Ⅱｰⅲ ２ビジネスグリッド

// CONTENTS //

１．概要............................................................................................................................................................ 2

１-１．グリッドコンピューティングとは.......................................................................................................... 2 １-２．サイエンスグリッドとビジネスグリッド............................................................................................... 3 １-３．ビジネスグリッドが必要とされる背景................................................................................................... 3 １-４．ビジネスグリッドの目的......................................................................................................................... 4

２．ビジネスグリッドの機能と主要技術 ....................................................................................................... 5

２-１．ビジネスグリッドの技術要素.................................................................................................................. 5 ２-２．ビジネスグリッドミドルウェアの構成................................................................................................... 6 ２-３．システムインフラの構成......................................................................................................................... 7 ２-４．OSの仮想化 ............................................................................................................................................ 7 ２-５．サーバの仮想化........................................................................................................................................ 8 ２-６．ストレージの仮想化................................................................................................................................. 8 ２-７．運用管理ミドルウェアの要件.................................................................................................................. 8 ２-８．ビジネスグリッド技術の適用に当たって............................................................................................... 9

３．経済産業省「ビジネスグリッドコンピューティングプロジェクト」................................................. 10

３-１．目的......................................................................................................................................................... 10 ３-２．概要......................................................................................................................................................... 10 ３-３．事例１（災害時での業務継続の実現とTCOの削減）....................................................................... 11 ３-４．事例2（安定した応答時間と業務継続性の実現）.............................................................................. 11

４．標準化の現在の動向と適用プロジェクト.............................................................................................. 13

４-１．標準化を必要とする技術領域................................................................................................................ 13 ４-２．技術観点からみた標準化活動................................................................................................................ 14 ４-３．GGF(Global Grid Forum).................................................................................................................. 14 ４-４．OASIS.................................................................................................................................................... 15 ４-５．Enterprise Grid Alliance (EGA)....................................................................................................... 16

５．参考文献 .................................................................................................................................................. 16



１．概要

１-１．グリッドコンピューティングとは

コンピュータが世に出て来た当初、そのハードウェアは非常に高価で１台のマシンをシェアリングして共同

利用する方式が一般的であった。これが半導体技術の進歩に伴い、そのコストパフォーマンスが飛躍的に向上

する中で、高性能マシンがどんどん分散化してゆくと、当初考えられなかったコンピュータリソースの余剰

パワーが生じてきた。また、１チップCPUの性能が向上するとコモディティな多数の小規模サーバを組み合

わせたシステムのコストパフォーマンスは大規模サーバとは比較にならない程高くなる。

グリッドコンピューティングとはこのような背景のもと、ネットワークを介して複数のコンピュータを結び

付け、これを１台の仮想的な高性能コンピュータとして使おうという概念である。もともとは電力業界から

きた用語で、送電網(Power Grid)にプラグを差せば、いつでも電気が使えるように、サーバやストレージ、

ネットワークといった ITリソースを、いつでも必要なだけ使えるようにすることを大きな目的としている。

現在は、高速な計算処理を短時間で提供するための「コンピューティンググリッド」、分散した情報に簡単

にアクセスするための「データグリッド」、Web及びDBを利用した信頼性の高いサービスをビジネス用途に

提供する「ビジネスグリッド」といった分類が行われている。

このようなグリッドコンピューティングは、次世代社会インフラとして期待されている。



１-２．サイエンスグリッドとビジネスグリッド

現在最も適用が進んでいるグリッドコンピューティングは、研究機関や大学などにおいて実用化されている

サイエンスグリッドだが、一般の企業などの業務システムへも適用（ビジネスグリッド）が期待されている。

このサイエンスグリッドとビジネスグリッドの関係を整理すると表１のようになる。サイエンスグリッドは、ある特定の目的のために相互接続されたサーバ群を協調して動作させることを前提

にしているのに対し、ビジネスグリッドは一般の業務に使用されるビジネスシステムへグリッド技術を適用

して全体最適を図るもので、その適用範囲はまだ明確にはなっていない。まさに現在進行形の技術といっても

良いだろう。

サイエンスグリッドビジネスグリッド

定義･ HPC (High Performance Computing: 高速技術計算)における分散コンピューティング技術(金融工学も包含)

･ HPCグリッド、計算グリッドなどとも呼称

･基幹業務システムのTCO削減、柔軟性

向上、高信頼化、業務連携の容易化などが

ターゲット･エンタープライズグリッドなどとも呼称

市場自動車、製造、ライフサイエンス、金融、研究機関など

基幹業務(ミッションクリティカル)

ジョブ制御の対象

長時間ジョブユーザプログラムが対象

トランザクション主体業務プログラム

対象データ大規模な数値データ観測・実験データを含む

データベース

対象機器（サーバ）

スパコン、PCクラスタ、Linuxサーバなど UNIX、Windows、Linux等のサーバ (ブレード等も含む)

要求される堅牢性

小大

表 1 サイエンスグリッドとビジネスグリッドの比較表

１-３．ビジネスグリッドが必要とされる背景

グリッドコンピューティングそのものはコストパフォーマンスの優れた小規模サーバを使って高機能な

システムを構成する事から始まったが、ビジネスグリッドについては別の側面も持っている。この数年のインターネットの発展と共に Web ベースのビジネスは急増し、トランザクションが短期間に増大する状況が多発し、システム負荷の予測が難しくなってきている。また、同時にビジネス形態もインター

ネットや ICカードと言った IT技術により変革する兆しを見せ、システム開発のスピードは速まり、システム基盤の更新タイミングは年々短くなってきている。一方、基幹システムの大部分は IT 化が果たされ、最近ではむやみに IT投資を増やすのではなく、ITコストの適正化が企業の大きな課題としてのしかかってきている。このような中、ROI の最適化や事業環境の変化にダイナミックに対応できる IT インフラのニーズなどが高まってきているのだ。



１-４．ビジネスグリッドの目的

このような背景の元、ビジネスグリッドに求められる要件としては大きくは下記の２点が挙げられる。・複数ある IT資源（サーバ・ストレージ等）を統合的に管理し、負荷変動への柔軟な対応、稼働率の向上を実現する。

・システムダウン等の障害に対して自律的に代替 IT資源を割当て、ビジネスの安定的な継続を実現する。この要件を実現するためにはヘテロ（異機種混在）環境のシステム群を統合的に管理し、高信頼で安定な

プラットフォームを開発・実用化する必要がある。これをもう少し詳しく説明しよう。資源の有効活用現在の ITシステムは

・サーバの低価格化・多階層システムの増加（Web3層システム等）・システム毎のサーバ設置

等の要因によりサーバリソースが分断され、リソースの平均的な稼働率は 30%とも言われている。このためマシンリソースを共通のプールとして管理し、リソースが不足する業務に対しこの共有資源を充当す

ることにより、システム全体の稼働率の向上を図ることが考えられる。ビジネス継続性の向上

オープンシステムにおいては信頼性向上のためにクラスタや RAID 等の多重化により対応することが多い。しかしながらこのような方法ではハードウェア投資が 2 倍、4 倍と膨らんでしまう。また、このようなリソースの確保により待機リソースの遊休が問題となる。そこで複数のシステムの待機リソースを

上記と同様な考えで共通化を図れば、可用性の向上と IT 投資の削減を同時に狙うことも出来る。逆に信頼性向上のための投資を減らすことが可能となるため、従来出来なかった可用性向上施策を実現する

ことも出来る。また昨今地震や異常気象等の自然災害に加え、テロ等の人的災害を含めたビジネス継続性が問題と

なっている。これら災害対策を考慮して、離れたサイト間で業務やデータを連携させ、特定のサイトが

稼働停止に追い込まれてもビジネスを継続できる仕組みが期待される。システム変更への対応インターネットビジネスの隆盛、新しいビジネスルールへの適応、M&A 等によるビジネス統合等、IT システムの変更要求は年々高まってきている。対してシステムの運用は継ぎ足しのシステム化や、異機種

サーバの組み合わせによりにより複雑性を増しており、その変更要求に耐えられなくなりつつある。そこで

異機種サーバを組み合わせたヘテロ環境においても、統一的かつ可搬的な運用を可能とする仕組みが期待さ

れる。もちろん上記は ITシステムへの課題のほんの一端にしか過ぎない。しかしながら ITインフラストラクチャとしての課題を解決するための一つとしてビジネスグリッド技術に対する期待は高いと考えて良いだろう。



ビジネスグリッドの機能と主要技術

２-１．ビジネスグリッドの技術要素

今まで述べて来たとおり、ビジネスグリッドはまだ発展途上の技術となるが、経済産業省主導の「Business Grid Computing Project」ではその技術要素として下記の表を挙げている。

仮想化異機種の IT リソースでも同一機種のように扱える

技術

①ITリソースを管理して論理化 ②IT リソース管理アダプタ開発用ツールキットの整備（管理対象の拡大）

プロビジョニング

業務処理の状況に応じて

自動的に必要なリソース

を割り当て、利用可能に

する技術

①業務の自動化運転に必要な全情報を記述する言語仕様

②様々なリソース割り当てのアルゴリズムに対応する

フレームワーク ③業務の優先度に基づき縮退等の割り当て制御方式 ④アプリケーションやデータの最適な配備方式

ポリシーベース

あらかじめ決められた

業務基準に従って自律的

にシステムを監視する

技術

①業務基準に基づいて業務の実行状況を監視する ②負荷増大時や障害時における業務基準に基づく

運用制御

ライフサイクル管理

ストレージに格納された

ビジネス情報をその生成

から抹消までを一貫して

管理し、保証する技術

①自律制御に基づく自動データ再配置 ②改竄防止、保管期限の設定と管理 ③遠隔自動レプリケーション

表２ビジネスグリッドの技術要素

※出典：参考文献[1]

ヘテロ環境でも業務システムを可搬に運用するための仮想化技術を中心に、それを実際に運用制御して環境を

自由に再割り当てするプロビジョニング技術、それを包括的にて定義・制御して自律的な運用を可能とする

ポリシーベースの技術が挙げられている。最後のライフサイクル管理は最初の 3つとは異なり、わかりにくい表現だが、高速化、低価格化が進むネットワーク環境を背景に離れた環境下においてデータのリプリケーショ

ンをベースとしたディザスタリカバリー技術となっている。このライフサイクル管理はストレージ技術に関す

るコンソーシアムによる開発技術であり、ここでは詳しく述べない。



２-２．ビジネスグリッドミドルウェアの構成

以上の技術を適用したシステムのソフトウェア構成として、経産省の「Business Grid Computing Project」では図 1のようにビジネスグリッドミドルウェアの構成を定義している。

図 1 ビジネスグリッドミドルウェアの構成


この図1はあくまで経済産業省の「ビジネスグリッドコンピューティングプロジェクト」が考えるグリッド

の制御・管理のためのミドルウェアであり、ITシステム全体のインフラの構成を示したものではないので注意が必要である。このプロジェクトでは異機種環境における業務運用の可搬性を中心に考えており、各機種に

依存して可搬性を向上させる技術（例えばVMの様なOSレベルの仮想化技術や、SANやNASに内包されるストレージの仮想化技術）は対象外になっている。しかしながら２章で挙げたビジネスグリッドの目的を達成

するためには、上記以外のインフラの構成を含めて全体として統合的な制御・管理を実施する必要があり、IT システムのインフラ構成全体から考える必要がある。



２-３．システムインフラの構成

ITシステム全体から見た標準的なインフラの構成というものは存在しないが、一つの類型として下記を提示する。

図2 システムインフラの構成例

この図でビジネスグリッドミドルウェアの部分は経産省のプロジェクトの働きかけで標準化が進むものと

期待されるが、その他の部分については各ベンダの技術に依存することとなる。ビジネスグリッド

ミドルウェアは業務システムを仮想化する技術であるが、その他 OS、サーバ、ストレージそれぞれの階層においても仮想化の技術が存在する。ビジネスグリッドに対してこれらインフラの仮想化モデルを導入すること

により、OS、サーバ・ストレージを含むシステム全体の構成を効率的に稼働させることが可能となる。そして、それをビジネスグリッドミドルウェアと連携して統括管理する運用管理ミドルウェアの存在が重要となる。

以下に各階層の仮想化のポイントを挙げる。２-４．OSの仮想化

OS の仮想化技術は主に VM(Virtual Machine)技術に代表される。これはハードウェア上に実装した VM Monitor上で１つもしくは複数のOS環境を実装する技術である。この技術を使うと一つのハードウェア上にて異なる複数のOSを稼働させることができると共に、OSから見てハードウェアが仮想化されることにより、新しいハードウェア上で古いOSもしくはその逆を稼働させることが可能となる。これによりソフトウェアに手を入れずにハードウェアを更新するソリューションも実現可能となるのだ。また、最近では OS 環境を、メモリ動作環境を含めて動的に移行することの可能な製品も出てきており、システムの稼働を止めることなくシステムを別のハードウェア環境に移動させることもできるようになって

きた。このような機能を使えば、OS が稼働する単位でビジネスグリッドミドルウェアの実現するプロビジョニング機能を実現することも可能になるのである。

業務システム

OS

サーバ

ストレージ

運用管理ミドルウェア

業務システム仮想化

経済産業省ビジネスグリッドミドルウェアの範囲

業務システム

OS

サーバ

ストレージ

運用管理ミドルウェア

業務システム仮想化

経済産業省ビジネスグリッドミドルウェアの範囲



２-５．サーバの仮想化

サーバの仮想化技術としてはハードウェアパーティショニングが挙げられる。これは１つのハードウェアを

複数のパーティションに分割し、その単位もしくはそれを束ねた単位で個々のサーバ環境を構築できるように

したものだ。これにより複数のサーバを物理的に１つの筐体に納められるだけではなく、動的に複数の

パーティションを組み合わせることによりサーバの拡張を動的に行うことができる。当初のハードウェアパーティションは I/O機能が各パーティションに付属しており構成の融通性に欠ける面があった。しかし最近では I/O 機能を仮想化して、CPU およびメモリから成るモジュール（ここでは CPU モジュールと呼ぶ）と独立させ、I/OとCPUモジュールを自由に組み合わせることのできる製品も出るようになり、柔軟性のある構成が取れるようになった。このようなサーバの仮想化と比較し、OS の仮想化技術の方が運用面から見ると実装しやすい面がある。しかし OS の仮想化も VM Monitor の処理に起因する性能面のオーバーヘッドがあり、ハードと OS の間にソフトウェアが介在することによる信頼性面での課題もある。ビジネスグリッドを構成する上で、制限はある

もののこれらの心配が不要なサーバ仮想化技術を組み合わせるメリットがあると考えられる。２-６．ストレージの仮想化

ストレージでは複数のディスクを組み合わせて RAID 構成を取ることが一般的になりつつあるが、これもいわゆる仮想化の技術の一つである。ストレージの仮想化はサーバと比較してかなり進んでおり、単なる

ドライブの仮想化に留まらない。現在ではストレージの装置の中で複数の RAID の組を構成できるだけではなく、複数のサーバを接続し、サーバとRAIDの組み合わせを自由に変更／再定義できる製品が一般的に存在する。こういった装置では多重化したデータを切り離し、バックアップを独立に実行できる機能や、別々の

筐体とデータを連動させ信頼性を向上させる機能を持つことが一般的だ。この筐体を離れた場所に設置すれば、

アプリケーションの考慮なしに災害対策を講じることもできる（ただし運用上の制限も存在する）。最近はさらに進化し、複数のストレージ装置（内部に RAID 構成を取るものも含まれる）を組み合わせて上記機能を実現する製品もできてきており、ネットワーク経由のストレージ（NAS）技術と合わせその選択肢はかなり広い。ストレージについてはかなり柔軟な構成が取れるようになってきていると言えよう。

２-７．運用管理ミドルウェアの要件

ビジネスグリッド技術を適用したシステムは、ビジネスグリッドミドルウェアの他に上記の技術を組み

合わせて実現することができる。しかし、一つのシステムとして柔軟な運用を実現するためには、運用管理

システムとして図 2の各階層をバラバラに管理していては現実的な運用は不可能である。このためシステムのインフラを統一的に構成定義する標準化が重要となる。DMTF という分散資源管理に関する標準化団体では CIM という管理対象資源の表現方法を規定している。最近の運用管理ツールはこの

CIMの表現を取り込み、構成情報を統一的な構成管理DB(CMDB)で管理する動きとなっている。ビジネスグリッドの標準としてはこの CIM の他、OASIS という標準化団体（５章参照）の規定するWSDM やWSRFと言った標準化が検討され、ヘテロ環境における相互接続性が高まりつつある。これら標準はまだまだ途上の

技術ではあるが、ビジネスグリッド技術を適用するシステムでは、今後運用管理ツールとしてこれら標準を

取り入れたものを使用すべきだろう。



２-８．ビジネスグリッド技術の適用に当たって

以上、ビジネスグリッドはビジネスグリッドミドルウェアや各階層における仮想化の技術を組み合わせ、

トータルな運用システムを構築して実現するものであることを説明してきた。しかし紙面の都合により 2章ではビジネスグリッド技術により構築されたシステムのイメージやメリットを十分説明できたとは言えない。

この観点で 3章の経済産業省のプロジェクトの事例を参照して欲しい。グリッド技術の全てが適用できているとは言えないが、その実現イメージはある程度つかんでいただけるのではないかと考えている。ビジネスグリッドでは複数の階層にて様々な技術を組み合わせて実現する必要がある。しかし技術はまだ

成熟途上である上に、各製品のサポート範囲も広いとは言えない。システムの構築に当たっては IT アーキテクトによりしっかりとしたアーキテクチャ設計を実施すると共に、インフラストラクチャの専門家を入れ、

将来性を考慮した上で信頼性を確保したシステム構築を目指す必要がある。



２．経済産業省「ビジネスグリッドコンピューティングプロジェクト」

３-１．目的

グリッドコンピューティングはネットワークで接続された多数のコンピュータを協調動作させ、あたかも

一つの大型システムのように稼働させる技術である。近年ビジネス分野のシステムの信頼性、安全性を向上

させるためにこの技術が有効であることが広く認識されてきた。このプロジェクトは、グリッドコンピュー

ティングを、高い信頼性と安全性が求められるビジネスの分野に適用することを目的とするものとなっている。

３-２．概要

このプロジェクトは以下の３つの活動を中心として 2003年度から 3年間の期間にて実施された。（１）国際競争力を有する技術開発（２）世界的普及を図るための国際標準化活動（３）事業化に向け、ユーザと協調した実証実験そして経済産業省、IPAを推進母体として富士通(株)/(株)日立製作所/日本電気(株)の三社が必要なミドルウェア開発及び実証検証を担当する体制となっている（下図）。

図 3 プロジェクトの体制


プロジェクトも 2005年度が最終年度となり、2006年 1月現在最終成果としてビジネスグリッドミドルウェアの完成と、業務定義標準となる「ZAR」をはじめとした国際標準化の働きかけを実施している。そしてビジネスグリッドミドルウェアの開発スケジュールは図 4の通りとなっている。



図4 ビジネスグリッドミドルの開発スケジュール

※ 出典：参考文献[2]

開発を担当する 3社ではそれぞれ異なる目的にて実証検証を実施しており、その成果が出てきている。以下に２つの事例について簡単に紹介する。

３-３．事例１（災害時での業務継続の実現とTCOの削減）

まず事例の最初は災害時での業務継続とＴＣＯ削減を目的としたマツダ株式会社の事例となる。これは業務

システムが本社サイトと外部データセンタの２カ所に分散したシステムにおいて本社サイトがダウンした場合

の業務継続性と構成の有効活用により投資コスト・運用管理コストを低減することを目的としている。平常時は外部データセンタと分散運用している販社システムを、本社サイトダウン時は外部データセンタに

集約して業務を継続する。また本社サイトでしか稼働していない集配信システムも、データを外部データ

センタへ非同期でデータバックアップしておき、本社サイトダウンが発生しても外部データセンタにて業務を

継続できるようにする（図 5）。

図 5 マツダ株式会社事例（災害時での業務継続の実現とＴＣＯの削減）


主担当：ＮＥＣ

ビジネスグリッドミドルウェアビジネスグリッドミドルウェア


販社システム販社システム

集配信システム販社システム

本社サイト外部ﾃﾞｰﾀｾﾝﾀ

平常時

災害時

集配信システム

応答時間が低下しても、業務継続を最優先

①販社システムは集配新システム復旧のため縮小し、片系で運用継続

②集配信システムを復旧

東日本販社西日本販社

平常時接続

災害時接続

データバックアップ

主担当：ＮＥＣ



販社システム販社システム

集配信システム販社システム

本社サイト外部ﾃﾞｰﾀｾﾝﾀ

平常時

災害時

集配信システム

応答時間が低下しても、業務継続を最優先

①販社システムは集配新システム復旧のため縮小し、片系で運用継続

②集配信システムを復旧

東日本販社西日本販社

平常時接続

災害時接続

データバックアップ

災害発生販社システムは両サイトで広域分散

実行し、被災時は外部データセンタ

集配信システムは本社サイトで実行

し、被災時は外部データセンターで



３-４．事例2（安定した応答時間と業務継続性の実現）

次は突発的に発生する大ニュースなど高負荷アクセス時も情報をインターネットユーザに安定的に提供

することを目的とする日本経済新聞社の事例である。通常は配信センタにてインターネットユーザに対してニュース配信サービスを実施しているが、突発的な

負荷増大時はセンタ内で優先度の低い Web サービス業務を縮退してそのリソースをニュース配信サービスに割り当てる。またそれでも不足する場合はさらに外部データセンタで稼働している Web サービス業務を縮退させて配信センタのニュース配信サービスを稼働させるものである（図 6）。

図 6 日本経済新聞社事例（安定した応答時間と業務継続性の実現）


The Internet

The Internet

ﾛｸﾞｻｰﾊﾞWWWｻｰﾊﾞ

F/W L4ｽｲｯﾁ

外部ﾃﾞｰﾀｾﾝﾀ

ﾚﾌﾟﾘｹｰｼｮﾝﾚﾌﾟﾘｹｰｼｮﾝ

ｸﾞﾘｯﾄﾞｻｰﾊﾞ

ＤＢｻｰﾊﾞ

ﾛｸﾞｻｰﾊﾞ

ＤＢｻｰﾊﾞ

WWWｻｰﾊﾞF/W L4ｽｲｯﾁ

ﾛｸﾞ集計ﾏﾈｰｼﾞｬｰ

ｸﾞﾘｯﾄﾞｻｰﾊﾞ

配信ｾﾝﾀ障害時に、外部ﾃﾞｰﾀｾﾝﾀでｻｰﾋﾞｽ継続

アクセス状況の迅速な把握

主担当：富士通

配信ｾﾝﾀ

アクセス急増時にサーバの自動追加

マルチサイトにわたるヘテロなITリソースの仮想化を行い、他サイトへも業務を拡張、必要時優先度の低い業務を停止/縮退させて優先度の高い業務にサーバを割りつける



４．標準化の現在の動向と適用プロジェクト

ビジネスグリッドにおいてはヘテロ環境にてリソースを融通し合う必要があるため、標準化が非常に重要な

位置づけとなる。特にグリッドシステムが外部（他のグリッド実装、管理対象リソース）との相互接続におけ

る標準化がポイントである。４-１．標準化を必要とする技術領域

標準化の動向を整理する上で、その技術領域を明確にした上で標準化活動をマッピングすると分かりやすい。

図 8はビジネスグリッド標準化を必要とする技術領域を整理したものとなる。

図 8 標準化を必要とする技術領域

①物理リソースを論理リソースとして仮想化、管理・制御 (A)②業務システムが必要とするリソースを記述、業務の実行を依頼 (B)③論理リソースと業務のリソース要求をマッチングし、業務システムにリソースを割当て (B)

④割り当てられたリソース（ホスティング環境）上にアプリやＤＢを自動配備(C)

ノードノード

Web ServerDBMS

AP Server

AP Server

業務システム群

物理リソースのプール

③資源管理（ﾘｿｰｽ自動割当）


論理リソースのプール

ベンダ固有（ヘテロな）リソースベンダ固有（ヘテロな）リソース

業務ｼｽﾃﾑ

標準化推進領域標準化推進領域

GGF CMM WG/OASIS WSDM TC CDDLM

JSDL/CDDLM

GRAAP/JSDL

(A)(A)資源を統一的資源を統一的に管理・制御に管理・制御する技術する技術((構成管理構成管理))

配備対象

④アプリやＤＢの自動配備④アプリやＤＢの自動配備(C)(C)

割りつけられた資源に割りつけられた資源にプログラム等を配備すプログラム等を配備す

る技術る技術((実行管理実行管理//リソース管リソース管

理理))

(B)(B)業務の実行依頼と業務の実行依頼と交渉の技術交渉の技術

((実行管理実行管理//リソース管リソース管理理))

①論理ﾘｿｰｽとして管理・制御

①仮想化①仮想化①仮想化

②ﾘｿｰｽ要求を記述

高信頼メッセージOASIS WS-RM TC

①物理リソースを論理リソースとして仮想化、管理・制御 (A)②業務システムが必要とするリソースを記述、業務の実行を依頼 (B)③論理リソースと業務のリソース要求をマッチングし、業務システムにリソースを割当て (B)

④割り当てられたリソース（ホスティング環境）上にアプリやＤＢを自動配備(C)

ノードノード

Web ServerDBMS

AP Server

AP Serverノード

ノード

Web ServerDBMS

AP Server

AP Server

業務システム群

物理リソースのプール



論理リソースのプール

ベンダ固有（ヘテロな）リソースベンダ固有（ヘテロな）リソース

業務ｼｽﾃﾑ

標準化推進領域標準化推進領域

GGF CMM WG/OASIS WSDM TC CDDLM

JSDL/CDDLM

GRAAP/JSDL

(A)(A)資源を統一的資源を統一的に管理・制御に管理・制御する技術する技術((構成管理構成管理))

配備対象

④アプリやＤＢの自動配備④アプリやＤＢの自動配備(C)(C)

割りつけられた資源に割りつけられた資源にプログラム等を配備すプログラム等を配備す

る技術る技術((実行管理実行管理//リソース管リソース管

理理))

(B)(B)業務の実行依頼と業務の実行依頼と交渉の技術交渉の技術

((実行管理実行管理//リソース管リソース管理理))

①論理ﾘｿｰｽとして管理・制御

①仮想化①仮想化①仮想化

②ﾘｿｰｽ要求を記述

高信頼メッセージOASIS WS-RM TC



４-２．技術観点からみた標準化活動

図 8の技術領域を標準化ポイントにしてまとめ直したものが図 9となる。

図 9 標準化ポイントに関わる主な標準化活動


各略号については図下部に説明を付けたので照願いたい。最後にグリッドに関するおもだった標準化団体を

紹介する。ただし、標準化は様々な観点で進められており、この標準化全てを記述できないことをご了承願い

たい。４-３．GGF(Global Grid Forum)

GGFはグリッドコンピューティング技術の国際的な標準化団体で、プロトコル標準化、用語統一、情報交換

等を目的として 2001年に設立された。下記の７つの技術エリアで標準化や情報交換に取り組んでいる。

・情報システムと性能

・スケジューリングと資源管理

・アーキテクチャ

・データ

・アプリケーションとプログラミングモデル

・ Peer-to-Peer

このGGFではこの７領域にて28WG(Working Group)と20RF(Research Group)が活動しているが、代表的なWG

として下記の4つを挙げておく。

参照ＵＲＬはhttp://www.gridforum.org/。

オープンな連携

外部との相互接続



全体アーキテクチャ全体アーキテクチャ

マルチベンダ／マルチサイトに対応する業務の依頼


業務に必要なリソースの記述


業務実行依頼と交渉の技術


マルチベンダ／マルチサイトで業務の配備を可能とする技術


マルチベンダのリソースを統一的に管理・制御する技術


接続性を確保する基盤技術接続性を確保する基盤技術

OGSA

JSDL

GRAAP(WS-Agreement)

CDDLMACSWSBPELWSDMCMM

WSRF/WSNWSRM

(OASIS Organization for the Advancement of Structured Information Standard)(GGF Global Grid Forum)

OGSA WG Open Grid Services Architecture WG WSRF TC WS Resource FrameworkJSDL WG Job Submission Description Language WG WSN TC WS NotificationGRAAP WG Grid Resource Allocation Agreement Protocol WG WSRM TC WS Reliable MessagingCDDLM WG Configuration Description, Deployment, and Lifecycle Management WGＡＣＳＷＧ Application Contents Service WGWSBPEL TC Business Process Execution Language TCWSDM TC Web Services Distributed Management TC TC OASISのTechnical CommitteeCMM WG Common Management Model WG WG GGF (Global Grid Forum) のWorking Group TC

















OGSA

JSDL

GRAAP(WS-Agreement)


WSRF/WSNWSRM

















OGSA

JSDL

GRAAP(WS-Agreement)


WSRF/WSNWSRM













OGSA

JSDL

GRAAP(WS-Agreement)


WSRF/WSNWSRM

(OASIS Organization for the Advancement of Structured Information Standard)(GGF Global Grid Forum)

OGSA WG Open Grid Services Architecture WG WSRF TC WS Resource FrameworkJSDL WG Job Submission Description Language WG WSN TC WS NotificationGRAAP WG Grid Resource Allocation Agreement Protocol WG WSRM TC WS Reliable MessagingCDDLM WG Configuration Description, Deployment, and Lifecycle Management WGＡＣＳＷＧ Application Contents Service WGWSBPEL TC Business Process Execution Language TCWSDM TC Web Services Distributed Management TC TC OASISのTechnical CommitteeCMM WG Common Management Model WG WG GGF (Global Grid Forum) のWorking Group TC



・ OGSA-WG(Open Grid Service AtchITecture) グリッドコンピューティングのアーキテクチャを検討しており、2005年 1月にOGSA仕様書の第 1版を公開した。ここにはOGSAへの要件、設計目標、主要なサービス機能が記述されている。・ CMM-WG(Open Grid Service Common Management Model)

OGSA で扱う様々な資源（サーバ、ネットワーク、ソフトウェアなど）の管理モデルを検討するWG。OGSA が提供する各サービスの機能を整合してゆく過程で、OASIS/WSDM-TC（後述）の仕様を採用することを決定し、それをベースにグリッドコンピューティングに特有の拡張機能を検討している。・ CDDLM-WG(Configuration Description, Deployment, and Lifecycle Management) アプリケーションの構成記述、配賦、ライフサイクル管理（軌道、停止、障害検出時の再配賦などを

含む）の検討を行っている。・ JSDL-WG(Job Submission Description Language) ジョブの実行要求を記述する言語、およびそのXML表現を検討している。

４-４．OASIS

OASIS は XML(eXtensible Markup Language)をベースとした業務アプリケーション向け言語標準から始まり、Webサービス関連技術の標準化を行っている標準化団体である。元々グリッド技術と Web サービス技術は別々に発展してきたものだが、分散コンピューティングやサービス指向など同じ方向性を目指す部分もある。このOASISには様々なTC(Technical Committee)が存在するが、グリッド技術と関連するTCとして下記を挙げることができる。・ WSDM-TC(Web Services Distributed Management) 分散された計算機資源を Web サービスの機能を使って管理する機能と、Web サービス自体を一つの計算機資源として管理する機能を検討している。DMTF(Distributed Management Task Force)や前述のGGF/CMM-WG とは緊密な連携を持って検討を進めている。ビジネスグリッドミドルウェアと実計算機資源との間のプロトコルはこの仕様に準拠してゆく予定である。・ WSRF-TC(Web Services Resource Framework) 状態を持つ資源を Web サービスを用いてモデル化し、アクセスするための、汎用的でオープンな枠組みを検討している。この仕様はGGFのOGSI(Open Grid Services Infrastructure)の要件と機能をWebサービスの基本機能を使って再構成したもので、GGFのOGSA-WGはOGSIの後継としてOGSA基盤サービスに採用している。・ WSBPEL-TC(Web Services Business Process Execution Language) 複数のサービスを組み合わせてひとまとまりの処理とするワークフローに関し、その記述言語の仕様を

検討している。経産省のビジネスグリッドミドルウェアの業務定義の一部であるジョブ制御フローはこの

資料をベースに開発されている。・ WSRM-TC(Web Services Reliable Messaging) ロイヤリティフリーで利用できる、Webサービス向けのオープンな高信頼メッセージの標準仕様を検討している。経産省のビジネスグリッドミドルウェアではそれを構成するコンポーネント間で、メッセージ

を非同期あるいは同期で高信頼に送受信する機能として利用している。



４-５．Enterprise Grid Alliance (EGA)

企業グリッドの発展と普及を目指して、主要 ITベンダを中心に 2004年 4月に発足した。このEGAは以下の特徴を備えている。

企業ユーザのニーズに特化オープンでベンダー中立のコミュニティを形成標準の策定だけでなくグリッド技術のビジネス化と普及にフォーカス企業会員ベースのコンソーシアム GGFやDMTFなど、既存の標準化団体とも協調してグリッド標準化に貢献

参加企業も EMC, Fujitsu Siemens Computers, HP, Intel, NEC, Network Appliance, Oracle, Sun Microsystemsと多数の企業が参加している

５．参考文献

［1］ビジネスグリッドコンピューティング研究開発事業（独立行政法人情報処理推進機構）

http://www.ipa.go.jp/software/bgrid/pdf/bgridpamphlet.pdf

［2］ビジネスグリッドコンピューティングプロジェクト状況報告（ビジネスグリッドコンソーシアム）

http://www.ipa.go.jp/software/bgrid/pdf/8Document1-1.pdf

［3］ビジネスグリッドコンピューティング３社共同事業化案（ビジネスグリッドコンソーシアム）


［4］ビジネスグリッドコンピューティング実証実験（ユーザ報告）マツダ株式会社


［5］ビジネスグリッドコンピューティング実証実験（ユーザ報告）株式会社日本経済新聞社


［6］ビジネスグリッドコンピューティング実証実験（ユーザ報告）株式会社損保ジャパン


［7］グリッド評議会ホームページ

http://www.gridforum.org/

〈注〉URLは全て 2006年 1月現在

Ⅲ-ⅰ ＩＴ技術分類体系

Ⅲ-ⅰ ＩＴ技術分類体系 1

Ⅲｰⅰ ＩＴ技術分類体系

// CONTENTS //

１．目的 ........................................................................................................................................................................2

２．分類体系............................................................................................................................................................. 2

2.1. アプリケーションソフトウェア........................................................................................................... 3 2.1.1. ユーザアプリケーション.................................................................................................................... 3 2.1.2. サポートアプリケーション ................................................................................................................ 3 2.1.3. 企業内主要情報システム.................................................................................................................... 8 2.2. アプリケーションプラットフォームのサービス...................................................................................... 8 2.2.1. システムサービス ............................................................................................................................... 8 2.2.2. OSサービス領域.............................................................................................................................. 14 2.2.3. 物理環境サービス領域...................................................................................................................... 14 2.3. 外部環境 ................................................................................................................................................... 15 2.4. 共通基盤 ................................................................................................................................................... 15 2.4.1. セキュリティサービス領域 .............................................................................................................. 15 2.4.2. 分散コンピューティングサービス領域............................................................................................ 17 2.4.3. システム/ネットワーク管理サービス領域...................................................................................... 17 2.4.4. 国際化サービス領域.......................................................................................................................... 19

３．分類体系サマリ ............................................................................................................................................... 20

3.1. アプリケーションサポートサービス....................................................................................................... 20 3.1.1 マルチメディアサービス領域 ........................................................................................................... 20 3.1.2 コミュニケーションアプリケーション領域..................................................................................... 20



１．目的

ここで述べるＩＴ技術分類体系は、共通的な概念のフレームワーク、用語を定義することにより、ＩＴ

アーキテクトにとって参考となるＩＴ標準技術を分類体系化するための基盤とすることを目的として

いる。今後この分類体系に則って具体的なＩＴ技術を整理していくことを予定している。

２．分類体系

【サポートアプリケーション】

・マルチメディアサービス・コミュニケーションアプリケーションサービス・オフィスオートメーションサービス・ビジネスプロセス管理サービス・環境管理サービス・データベースサービス・技術サポートサービス

ｾｷｭﾘﾃｨｻ|ﾋﾞｽ

分散ｺﾝﾋﾟｭ|ﾃｨﾝｸﾞｻ|ﾋﾞｽ

ｼｽﾃﾑ/ﾈｯﾄﾜ|ｸ管理ｻ|ﾋﾞｽ

国際化ｻ|ﾋﾞｽ

【ユーザアプリケーション】

【ＯＳサービス】

【企業内主要情報システム】

【システムサービス】

・ソフトウェア工学サービス・ユーザ/コンピュータインタフェースサービス・データ管理サービス・データ交換サービス・グラフィクスサービス・プラットフォーム通信サービス・出力サービス・アプリケーションサービス

・装置・システム・通信インフラ・ユーザ

【物理環境サービス】



外部環境



2.1. アプリケーションソフトウェア

2.1.1. ユーザアプリケーション

ユーザアプリケーションは、特定のユーザ要件やニーズを実現する。このアプリケーションソフトは、

独自開発、COTS、GOTSあるいはこれらの組み合わせにより提供される。また、アプリケーションソ

フトに加えて、アプリケーション特有のデータ（請求や支払いのログ等）や構成情報(例えば、アプリ

ケーションパラメタ、画面定義、診断メッセージ)も対象となる。

2.1.2. サポートアプリケーション

サポートアプリケーションは、個別あるいは複数のユーザ領域にまたがって標準化することができる共

通のアプリケーション(例えば、電子メール、文書処理、スプレッドシート)をいう。これ等は、ユーザ

アプリケーションを開発するのに利用するか直接ユーザが利用することができる。このセクションで説

明するサービスは、共通のアプリケーションを定義、開発または再利用可能なソフトウェアを選択する

ために必要な機能を記述している。サービスは主要なサービス領域に分類されている。サービス領域

とサービスは時間とともに変化していく。サービスのいくつかは、他のサービスを実行する部品として

使用される。

2.1.2.1. マルチメディアサービス領域

マルチメディアサービスはテキスト、グラフィックス、イメージ、ビデオ、およびオーディオから成る

情報を処理、管理する機能を提供する。直接ユーザアプリケーションからこれらのサービスを利用する

ことができるが、また、共通の要件を満たすために他のサポートアプリケーションによっても使用する

ことができる。これらのサービスは、組み合わせても単独でも利用することができる。

（１）Audio Processing サービス

音声情報に関してキャプチャ、構成、編集等を行うサービス。

（２）Document Processing サービス

文書について作成、編集、マージ、書式化等を行うサービス。これ等のサービスにより文書内にグラフ、

イメージ、音声等を配置することが可能。またスタイルガイド、用語のチェック表の作成、ヘッダ/フ

ッタ、イメージの取り込みといった応用的なサービスも含まれる。

（３）Electronic Publishing サービス

写真画質のイメージ、カラーグラフィクス、グラフィクスとテキストの組み合わせ、カーニング等を行

うサービス。また複雑な印刷、製本等の装置へのインタフェースも含む。

（４）Image Processing サービス

イメージの標準フォーマットにしたがってスキャン、キャプチャ、作成、編集等を行うサービス。



（５）Map Graphics サービス

地図情報について表記記号、地図情報の作成、編集、描画等を行うサービス。

（６）Multimedia Processing サービス

上述のメディアについて圧縮、保存、検索、修正、分類、印刷する等のサービス。またこれ等の情報を

マイクロフィルム、光ディスクへ保存し管理する技術も含む。さらにハイパーメディアの処理も対象と

なる。ハイパーメディアにより、文書に埋め込まれた情報を使用してインタラクティブに文書をナビゲ

ートすることができる。

（７）Video Processing サービス

ビデオ処理サービスは、ビデオ情報をキャプチャ、構成、編集する等のサービス。またグラフィクスや

タイトル作成機能も含まれる。

（８）Text Processing サービス

テキストを生成、編集、マージ、書式化等を行うサービス。

2.1.2.2. コミュニケーションアプリケーションサービス領域

コミュニケーションアプリケーションサービスは、電子的あるいは音声のメッセージを送信、受信、管

理する機能を提供する。

（１）E-Mail サービス

E-Mailサービスは、個人的なメッセージを送信、受信、転送、保存、表示、管理するサービス。またフ

ァイルや文書を添付する機能についても含まれる。メッセージにはデータ、テキスト、音声、グラフィ

クス、イメージが標準的なデータ交換フォーマットで含まれていることもある。

（２）Organizational messaging サービス

組織（官、民）間で、事前に規定されたフォーマットによりメッセージを送信、受信、転送、保存、表

示、検索、優先付け、認証、管理するサービス。

（３）Videoconference サービス

ビデオ会議サービスは異なるサイト間に対して双方向のビデオ情報通信を可能とする。これにはイベン

トや参加者の表示、カメラ操作、音声のピックアップ等の機能も含まれる。

（４）Broadcast サービス

単一方向の音声、音声/ビデオを複数の受信へ配信する機能を提供する。

（５）Computer conference サービス

ワークステーションを通して複数のグループが会議に参加できるサービスをいう。また文書の交換、会

議の管理、記録のための設備、検索等のサービスも含まれる。



（６）Directory サービス

インターネットのイエローページ(電話帳)のサービス。コミュニケーションのためのメールアドレスな

どを提供する。将来においては企業の提供するサービスを含めてWebサービスのUDDIに登録される

方向にある。

（７）Messaging サービス

チャットに代表されるような短文のメッセージを比較的リアルタイムに交換するサービス。

（８）Tele-communication サービス

電話の呼の転送、待ち受け、電話会議、自動的な呼の配布、呼の記録、音声メール等のサービス。

（９）Shared-screen Teleconferencing サービス

ワークステーション上の共有スクリーンを通して複数の会議参加者が音声通信しディスカッションで

きるサービス。全てのユーザに対して会議のウィンドウにグラフィカルに注釈をするあるいは変更する

機能が提供される。

2.1.2.3. オフィスオートメーションサービス領域

オフィスオートメーションサービスは、毎日使用される共通のオフィス機能を提供する。

（１）Spreadsheet サービス

表やグラフの形式で情報を作成、処理、表示するサービス。また第４世代言語によりスプレッドシート

に処理が記述できる機能も含まれる。

（２）Project management サービス

プロジェクトを計画、管理するサービスやツール。

（３）Calculation サービス

定型的あるいは複雑な算術計算をするサービス。

（４）Calender サービス

個人の仕事、時間を管理し、複数の人とスケジュールを調整する機能を提供するサービス。

2.1.2.4. ビジネスプロセス管理サービス領域

ビジネスプロセス管理サービスは、ビジネスプロセスオートメーション、人を介在したワークフローの

定義、管理する機能を提供する。



（１）Work Flow サービス

人の介在を含む処理の流れを手続きとして管理するサービス。処理の進行管理、分岐、通知などの機能

を提供する。

（２）Business Flow サービス

政府や企業の提供するサービス(ビジネスプロセス)を関連付けてひとつの手続きとして管理するサービ

ス。Webサービス上のワークフローとして標準化の検討が開始されている。

（３）Business Processing サービス

政府や企業のビジネスプロセスを定義し、構成するサービス。

2.1.2.5. 環境管理サービス領域

このサービスは、主として特定のデータ処理、コミュニケーション環境の管理を目的としており、他の

カテゴリよりスコープは広い。環境管理サービスは、特定の用途とユーザのためにプラットホームサー

ビスの実行を統合して、管理する。これらのサービスは、ユーザやアプリケーションが技術的な環境の

詳細を知ることなくプラットホームサービスを呼び出すのを可能とする、容易で高水準なインタフェー

スを通して呼び出される。環境管理サービスは、どのプラットホームサービスが要求を満たすのに利用

されるかを決定し、インタフェースを通してそれへのアクセスを管理する。

（１）Batch-processing サービス

ジョブ制御コマンドによるジョブのキューイング、シーケンス実行管理を行うサービス。またバッチ処

理の出力を管理するための支援機能も含まれる。バッチ処理はユーザがジョブを要求すると非同期に実

行される。

（２）Electronic-Records-Management-Processing サービス

ユーザとの情報のやり取りをオンラインでキャプチャする機能を提供する。やり取りとしては、データ

ベース・ファイルへのデータ入力、検証、表示、変更、検索がある。トランザクション処理としてはロ

ーカルやリモートへの分散サービスも含まれる。

（３）Information presentation and distribution サービス

バッチやインタラクティブなアプリケーションからの情報を配布し表示するサービスをいう。このサー

ビスにより、ミッションエリアのアプリケーションは情報をどのように使用されるか意識しなくて良い。

（４）Leaning Technology サービス

コンピュータによるトレーニング（ＣＢＴ）、教育（ＣＡＩ）、リモート学習等のサービスを提供する。

これには使用中のアプリケーションに関する個人指導、オフライン、オンサイトのインタラクティブな

トレーニングが含まれる。



2.1.2.6. データベースサービス領域

データベースサービスは、データベース管理システムからデータを検索し、処理する機能を提供する。

このサービスは、様々なデータベースへアクセスをし、一貫したインタフェースをユーザに提供する。

（１）Networking/Concurrent Access サービス

データベースマネージメントシステムのサービスへのコンカレントなユーザアクセスを管理するサー

ビス。

（２）Query Processing サービス

ファイルやデータベースに蓄積されている情報をインタラクティブに選択、抽出、フォーマッティング

する機能を提供するサービス。クェリ処理は第４世代言語のようなユーザ向けの言語やツールで呼び出

される。

（３）Report Generation サービス

データベースから抽出されたデータをハードコピーレポートするための定義と生成する機能を提供す

る。

（４）Screen Generation サービス

データの検索、表示、更新をサポートする画面の定義、生成をサポートするサービス。

2.1.2.7. 技術サポート領域

技術サポートサービスは、様々なユーザと環境のための分析、デザイン、モデル、開発、およびシミュ

レーションのサポートを対象としている。

（１）Computer-Aided Design（ＣＡＤ）サービス

コンピュータを利用して、建築や電子回路設計を支援するサービス。

（２）Decision Support サービス

意志決定を支援するためのインタラクティブなモデリング、シミュレーション機能を提供するサービス。

（３）Expert System サービス

専門家の知識と解析ルールをプログラム化し、特定の問題に対する問題解決や意思決定を行なうサービ

ス。

（４）Modeling and Simulation サービス

システム分析を支援するためにオブジェクトの関係、インタラクションを描画しオブジェクトの特徴、

属性を掴むための機能を提供するサービスをいう。



2.1.3. 企業内主要情報システム

企業内で開発し、ユーザﾞアプリケーションのために使用できるサポートアプリケーショ

ンをいう。 2.2. アプリケーションプラットフォームのサービス

2.2.1. システムサービス

2.2.1.1. ソフトウェア工学サービス領域

システム開発者は、アプリケーションの開発と保守に適切なツールを必要とする。これらはソフトウェ

ア工学サービスで提供される。

（１）Programming Language

ユーザアプリケーションを開発するための開発言語とコンパイラ。

（２）System Development ツール

アプリケーションのコンポーネントを構築するためのツールやアプリケーションとその実行環境を統

合するツール。

（３）Software life-cycle process

ソフトウェアのライフサイクルを明確にし、開発、保守するためのアクティビティ、方法、プラクティ

ス、変換および関連するプロダクト（プロジェクト計画、設計ドキュメント、コード、試験のケース、

ユーザマニュアル）を含む。

（４）Business and Process Re-engineering

ビジネスファンクション、入力情報、プロセス、プロダクトを理解するために共通的な定義、描画する

ためのビジネスモデリングツールが提供される。

（５）Data Modeling

ユーザが必要とする情報、ビジネスプロセスを正確にモデル化しグラフィカルに表現するサービスをい

う。データモデルは新規アプリケーションあるいはアプリケーションの機能拡張のためのフレームワー

クとなる。

（６）Project management

プロジェクトを管理するための機能を提供するサービス。

（７）Requirements management

システム要件の管理を支援するサービス。



（８）Configuration management

システム構成の設計、実装、管理を支援するサービス。

2.2.1.2. ユーザインタフェースサービス領域

ユーザーインタフェースサービスは、ユーザがアプリケーションと対話する方法を定義する。アプリケ

ーションプログラム、オペレーティングシステム、および様々なシステムユーティリティへアクセスし

てシステムを開発、管理、使用する人々に一貫した環境を提供する。ユーザーインタフェースは、メニ

ュー、スクリーンデザイン、キーボードコマンド、コマンド言語、およびヘルプスクリーンの組み合わ

せによりコンピュータとやり取りする環境を提供する。ユーザーインタフェースサービスは、マウス、

タッチスクリーン、および他の入力ハードウェアを利用する。

（１）Character-Based User Interface サービス

キャラクタベースのユーザインタフェースを提供するサービス。ユーザはコマンドラインにより端末と

インタフェースを取る。

（２）Graphical Client-Server サービス

ネットワークを介したクライアント/サーバ型でグラフィカルなユーザインタフェースを提供するサー

ビス。各表示単位のコントロールはサーバ側のプロセスにより行われ、実際の表示はサーバからのリク

ェストによりクライアント側のプロセスが独立に行われる。

（３）Object Definition and Management サービス

表示エレメントの特性、例えば色、シェイプ、サイズ、移動、エレメント間のインタラクション等を定

義し管理するためのサービス。

（４）Window Management サービス

ウィンドウの生成、移動、検索、保存、削除等をどのように行うかを定義するサービス。

（５）Web Graphical User Interface サービス

本サービスは２つの論理的なコンポーネント（webブラウザ、webサーバ）から成り、ＨＴＴＰを使用

してリクェスト/レスポンスで通信が行われる。

（６）Accessibility サービス

様々な機器に対して、健常者はもちろん高齢者や障害者にとっても使いやすさを提供するサービス。

2.2.1.3. アプリケーションサービス領域

アプリケーションを構築する上でのインフラとなるフレームワーク、コンポーネントを提供するサービ

スをいう。



（１）Application Service Platform

ERPなどの業務パッケージ基盤やDWHなどのアプリケーションパッケージの基盤サービス。SCMを

構成する基盤サービスやEAIツールなども含まれる。

（２）Service Module Component

TPモニターやEJBなどの Javaコンポーネントやその実行環境を提供するサービス。トランザクション

処理や分散実行環境などが含まれる。

（３）Application Service Provider

アプリケーションは複数のサービスコンポーネントを組み合わせて構成されるが、ASPはそのような外

部コンポーネントのひとつ。また、政府や企業のアプリケーションが提供するサービスをサービスコン

ポーネントとして外部へ提供することもできる。

2.2.1.4. データ管理サービス領域

データ処理とは独立に定義されるデータ管理のためのサービスをいう。

（１）Data Dictionary/Directory サービス

データ管理者や情報技術者にメタデータへアクセスし変更するためのサービスを提供する。このような

メタデータとしては、外部・内部形式のフォーマット、整合性・セキュリティのルール、分散したシス

テムのロケーション等がある。またデータベース上のデータ定義、データ取得をユーザ、アプリケーシ

ョンに提供する機能も含まれる。

（２）Database Management System サービス

データの管理およびデータの構成、変更、アクセスのコントロールを行うサービス。このサービスはプ

ログラムインタフェースを通してＳＱＬでアクセスすることが出来る。

（３）Transaction Processing

トランザクションを定義し処理するためのサービス。

（４）Metadata Repository サービス

情報資源について管理、コントロール、構成、定義、ドキュメント、標準化のためのメカニズムを提供

するサービスで、開発者とユーザの辞書となる。

（５）Online Analytical Processing（ＯＬＡＰ）サービス

ユーザのデータ分析要求を即座に処理するサービス。

（６）Search サービス

テキスト、イメージを検索するサービス。



（７）Document Management サービス

紙や電子的な文書のトラッキング、変換、構成管理や電子的な文書作成のためのサービス。

（８）Web Content Management サービス

webサイトのコンテンツ作成、フォーマッティングのための管理、コントロールサービス。

（９）Electronic Records Management サービス

E-Mail、音声メール、写真等のマルチメディアの情報を記録管理するサービス。

2.2.1.5. データ交換サービス領域

データ交換サービスは、アプリケーションと外部環境の間の情報を交換するための特別なサポートを提

供する。このサービスは、同一のプラットホーム上のアプリケーション間および他のプラットホームの

アプリケーションとのデータ交換するために提供される。

（１）Characters and Symbols サービス

キャラクタやそのフォントおよび日付の表現等の変換をするサービス。

（２）Compression サービス

データの圧縮アルゴリズムを規定しネットワーク上で交換するサービス。

（３）Document Interchange サービス

データ（テキスト、写真、数値、特殊文字等）のコード化仕様にもとづいて種々のコンピュータシステ

ム間で文書を交換するサービス。

（４）Hardware Applications サービス

同質ではないハードウェアコンポーネント間でデータ交換するサービス。コンピュータと印刷装置間の

データ交換等が挙げられる。

（５）Mapping サービス

地図情報とガスの配管情報をマッピングする等のサービス。

（６）Optical Digital Technologies サービス

光学的な記録装置にデータをキャプチャ、コード・デコード、保存するためのサービス。

（７）Raster/Image Data Interchange サービス

ラスターグラフィクスとイメージについてハンドリングし操作するための交換サービス。

（８）Technical Data Interchange サービス

グラフィクスデータ（ベクターグラフィクス、技術仕様、製品情報等）を交換するための標準を含む技



術的なデータの交換サービス。

（９）Tag Set サービス

アプリケーション間のデータ交換を可能にするためにデータに付加したタグのセットや規約、あるいは

メタデータのプロパティセットとして表現される。W3CのRDFなどがある。将来は意味変換を含めて

交換するための規約 SemanticWebの標準化が検討されている。

（１０）Data Format サービス

CSVなどのデータ交換のための標準フォーマット。

（１１）Data Element Standardization サービス

数値や日付などのデータ構成要素の標準フォーマット。

（１２）File Transfer サービス

データをネットワーク上で交換するサービス。FTPなどのファイル転送サービスやEDIなどの商取引の

標準交換サービスなどがある。

（１３）Geographic Information Systems サービス

地図情報の標準フォーマット。

2.2.1.6. グラフィクス・サービス領域

グラフィックスサービスは、画像を作成し、操作するのに必要な機能を提供する。

（１）Device Interfaces サービス

モニタ、スキャナ、プリンタ等のグラフィクス装置へのＡＰＩを提供するサービス。

（２）Raster Graphics サービス

スキャナ、カメラあるいはペイントソフトからラスタグラフィクスを作成するサービス。

（３）Vector Graphics サービス

ベクトル情報をベースに幾何学的な表現を行うサービス。スクリーンはほとんどラスタグラフィクスの

ため、ハードウェアあるいはソフトウェアによってベクトル情報がラスタ情報に変換される。

2.2.1.7. プラットフォーム通信サービス領域

プラットフォーム通信サービスは、ユーザアプリケーションをサポートするために、ネットワーク環境

での分散アプリケーションの相互運用性とデータアクセス機能を提供する。



（１）Application-Oriented サービス

Telnetや SNMPなどのネットワークアプリケーション層に位置するサービス。

（２）Network Technologies サービス

品質サービス(QoS)など特定のネットワーク階層だけで実現するのではなく、ネットワークシステム全

体で提供するサービス。

（３）Transport-Oriented サービス

TCPやUDPなどのネットワークトランスポート層に位置するサービス。インターネットでは現在

TCP/IPが標準だが、IPv6プロトコルの標準化が進んでいる。

（４）Address Management サービス

ネットワークのアドレス解決をサービスする。アドレスはURIで表現するのが一般的である。TCP/IP

ではURIから IPアドレスへの変換をDNSで行う。

（５）Routing Protocols サービス

ネットワークパケットを目的のノードまで届けるサービス。静的ルーティングや動的ルーティングなど

がある。

2.2.1.8. 出力サービス領域

（１）Facsimile Transmission サービス

FAX送受信サービス。

（２）Compact Disk-Read Only(CD-ROM) generation サービス

CD-ROM作成あるいはCD-Rへの出力をするサービス。

（３）DVD generation サービス

DVD-ROM作成あるいはDVD-Rへの出力をするサービス。

（４）Film Product generation サービス

写真フィルムへの出力をするサービス。

（５）Magnetic Tape generation サービス

磁気テープへの出力をするサービス。

（６）Plotter generation サービス

プロッタへの出力をするサービス。



（７）Printer generation サービス

プリンタへの出力をするサービス。

2.2.2. OSサービス領域

ＯＳサービスは、アプリケーションプラットホームを管理し、アプリケーション・ソフトとプラットホ

ームの間のインタフェースを提供する。アプリケーションプログラマは、オペレーティングシステム

機能にアクセスするためにオペレーティングシステムサービスを利用する。

（１）Clock/Calendar サービス

リアルタイムクロックやシステムの日付を管理するサービス。

（２）Fault Management サービス

システム障害の検出、通知、記録、回復をするサービス。

（３）Kernel Operations サービス

プロセス、メモリを管理するサービス。

（４）Media Handling サービス

周辺装置への入出力をするサービス。

（５）Operating System Object サービス

オペーレーティングシステムのコンポーネントのロードやファイルシステムの管理をするサービス。

（６）Real-Time Extension サービス

リアルタイムモニタなどの実時間のサービスを提供する。

（７）Shell and Utilities サービス

コマンドインタフェースやスクリプト言語およびファイル操作などのユティリティサービス。

2.2.3. 物理環境サービス領域

（１）Device Drivers

ハードウェアや周辺機器とのデータ転送や制御をするサービス。異なるハードウェアの違いを隠蔽し、

等価に扱うことができるようにもする。

（２）BIOS

OSが動作しない環境で、コンピュータを起動したり、ハードウェアの構成を変更したりするサービス。



2.3. 外部環境

外部環境インタフェース(EEI)は、情報がやり取りされるアプリケーション・ソフト、そのプラットホー

ム、外部環境との間のインタフェースである。EEIはインタフェースクラスの 1D、1L、2L、3L、およ

び 4Lを含んでいる。ユーザとデータの相互運用性はEEIによって直接提供される。以下の主要なグル

ープを含んでいる。

・人間/コンピュータ・インタフェースサービスEEI

・情報サービスEEI

・通信サービスEEI。

（１）Devices/Peripherals サービス

アプリケーションプラットフォームをサポートするために必要な装置で、アプリケーションプラットフ

ォームとユーザ間の物理的なインタラクションをサポートする。

（２）Systems/Models(Processing Platforms) サービス

システム/モデルは通信インフラを通してアプリケーションプラットフォームと接続される外部の物理

的なエンティティをいう。システムとしては人、プロダクト、プロセス等があり、モデルとしては物理

的、数学的あるいは論理的なシステムを表した物を言う。

（３）Communications Infrastructure サービス

外部とシステムを接続するために必要なルータ、ハブ、スイッチ等の通信インフラをいう。

（４）Userサービス

利用者がシステムから必要な情報を取得するためのプロセスを定義するユーザインタフェースサービ

ス。また画面のデザイン、フォントサイズ、スピードといったサービスも含まれる。

（５）Mobile Platforms サービス

携帯電話やＰＤＡ（Personal Digital Assistants）あるいは持ち運び可能なパソコンと接続するサービス。

（６）Storage サービス

データを保存するためのハードウェアデータストレージ。ディスク、テープ等の物理的なストレージメ

ディアの実装に関する標準も含まれる。

2.4. 共通基盤

2.4.1. セキュリティサービス領域

セキュリティサービスは、アプリケーションレベル、カーネルレベル、装置レベル、システムレベル、

アプリケーションプラットホームレベルなどのように複数のレベルにまたがったサービスである。



（１）Access Control サービス

情報システムリソースへの不正なアクセスとその方法をコントロールするサービス。

（２）Authentication サービス

本人性を確認し、本人であることを証明する認証サービス。

（３）Availability サービス

タイムリーで定常的な通信機能を提供するサービス。また不慮あるいは意図的なダメージから通信ネッ

トワークを防御するサービスも持つ。

（４）Confidentiality サービス

データの暗号化、セキュリティ管理、鍵管理等を通して不正な個人、コンピュータからのデータアクセ

スを防御するサービス。

（５）Integrity サービス

オープンシステム、ネットワーク、データの保全を通してシステム全体の保全性を保証するサービス。

データが不正なやり方で改変されたり破棄されないように防御する。

（６）Non-Repudiation サービス

オープンシステムの否認防止機能、電子署名、ハッシング等の機能を含む。データの送信者や受信者が

データの送信/受信を行ったにもかかわらず否認することを防止する。

（７）Security Labeling サービス

リソースのセキュリティ属性に名前を付けるサービス。

（８）System Management サービス

セキュアなシステムの運用/保守において、セキュリティ機能を提供するシステム管理サービス。これ

にはアラームの報告、監査、暗号の鍵管理等の認証、リスク管理に関わるサービスが含まれる。

（９）Audit Trail Creation and Analysis サービス

証跡を保存し、追跡や解析をするサービス。

（１０）Cryptography Management サービス

暗号化をするサービス。

（１１）Virus Protection サービス

ウィルスの検知、検疫をするサービス。

（１２）Fraud Prevention サービス

偽証を防止するサービス。



（１３）Detection and Mitigation サービス

不正を検知し、影響を最小限とするサービス。

（１４）Intrusion Prevention and Detection サービス

侵入への介入と防止をするサービス。

2.4.2. 分散コンピューティングサービス領域

分散コンピューティングサービスは、ネットワーク上のコンピュータシステムに物理的あるいは論理的

に分散したアプリケーションが互いに連携するために特化したサポートを提供する。

（１）Client-Server サービス

同一のプラットフォーム、分散されたプラットフォームに関わらず処理を依頼するクライアントと処理

を提供するサーバに分けてコンピューティングサービスを実装するサービス。

（２）Distributed Object サービス

分散環境におけるオブジェクトの定義、インスタンス化、インタラクションをサポートするサービス。

データの永続性、メッセージ転送といったサービスも含まれる。

（３）Message Transport サービス

分散コンピューティングサービスにおいてメッセージを送受信、ルーティング、キューイング、ディレ

クトリ管理するサービス。

（４）Remote Access サービス

分散コンピューティングサービスにおいてユーザ、クライアントプロセスが他のシステム資源にアクセ

スする際、ロケーションを意識しない機能を提供するサービス。

2.4.3. システム/ネットワーク管理サービス領域

情報システムは、オープンシステム環境の目標を達成するために管理されなければならない様々なリソ

ースから構成される。個々のリソース(プリンタ、ソフトウェア、ユーザ、プロセッサ等)は多種多様で

あるが、管理オブジェクトとしてのこれらのリソースの抽象化は統一的な方法でこれらを扱えるように

する。

（１）Configuration Control サービス

構成管理-情報システムのネットワーク構成、サーバ構成、システム構成などの資源の配置を管理、再

配置するサービス。標準技術としてはネットワーク機器のインターフェースとしてSNMP/MIBが IETF

で規定され、オブジェクトの構成モデルCIMがDMTFで規定されている。



（２）Fault Monitoring サービス

障害管理-情報システムの障害を検出し、管理するサービス。これには障害には至らなかった警告情報

のログも含まれる。

（３）Information System Security Management サービス

セキュリティ管理-セキュリティ基盤を利用してセキュアな情報システムを構成するサービス。システ

ムへの不正な侵入の検出や他のシステム管理サービスと連動したトータルな問題の監視などを行う。ま

た、セキュリティポリシーに基づいた複数のセキュリティサービスの設定や管理なども含まれる。

（４）Performance Monitoring サービス

性能管理-情報システムおよびシステムの構成要素の性能を監視し、サービスが適切に提供されている

ことを管理するサービス。サービスの目標は SLAとして設定される。また、Webコンテンツのサービ

ス応答時間を適正化するためのCDN技術などがある。

（５）State Management サービス

状態管理-情報システムの資源の状態を監視するサービス。これにはサーバの生死の監視やプリンタの

用紙切れ検出なども含まれる。

（６）Usage Monitoring and Cost Allocation サービス

稼動管理-システムの構成要素の稼動状況を監視し、稼動状況によって適切に資源を配置するサービス。

（７）User/Group Management サービス

ユーザ管理-ユーザの登録、使用、保全をするサービス。これにはシングルログインなどの統合された

サービスも含まれる。

（８）Backup and Recovery サービス

バックアップ管理-ストレージのデータのバックアップ、定期バックアップなどの自動運転、世代管理

などをするサービス。

（９）Disaster Recovery サービス

災害管理-広域災害などに備え、遠隔地にシステムやデータの複製を準備したり、二重化をしたりする

サービス。

（１０）Resource Management サービス

資源管理-情報システムの資源を割り当て、管理するサービス。これにはディスク、メモリ、ＣＰＵ、

ネットワーク、サーバや各種ソフトウェア資源などが含まれる。また、インターネット上の情報システ

ムを仮想化し、共通資源として管理するためのグリッド技術がGGFで検討されている。

（１１）Schedule Management サービス

スケジュール管理-バッチ業務の自動スケジュール、オンライン業務のサービス時間、カレンダースケ



ジュールなどのサービス。

（１２）Desktop/Asset Management サービス

資産管理-クライアントＰＣの構成管理、利用者管理を始めとして、部門に配置された情報システムと

その関連機器の資産を管理するサービス。デスクトップ管理としてはDMTFのDMIが標準仕様となっ

ている。

（１３）Software Release Management サービス

配布管理-多数のサーバやクライアントへソフトウェアを配布したりバージョンを管理したりするサー

ビス。

（１４）Change Management サービス

変更管理－ソフトウェアの修正情報を管理し、配布適用するサービス。

2.4.4. 国際化サービス領域

多国籍的、あるいは多文化的な環境で作業するユーザや組織が必要とするサービス。

国際化サービスは、ユーザが異なる文化的環境のアプリケーションを定義、選択、変更できるサービス

とインタフェースを提供する。

（１）Character Sets and Data Representation サービス

文字コード体系に依存しないでデータの入力、蓄積、操作、検索、通信、表示等を行うサービス。

（２）Cultural Convention サービス

文化的な習慣（日付の表記等）のリポジトリに管理されている文化的なエンティティを保存しアクセス

するためのサービス。

（３）Native Language Support サービス

メッセージ、メニュー、書式、オンラインドキュメント等をユーザが指定した言語で処理するサービス。



３．分類体系サマリ

3.1. アプリケーションサポートサービス

3.1.1 マルチメディアサービス領域

サービス名現在の標準技術（含デファクト）将来の標準技術コメントAudio ProcessingDocument ProcessingElectronic PublishingImage Processing JPEG、GIFMap GraphicsMultimedia ProcessingVideo ProcessingText Processing

3.1.2 コミュニケーションアプリケーション領域

サービス名現在の標準技術（含デファクト）将来の標準技術コメントE-MailDirectoryMessagingBroadcastEnhanced TelephonyOrganizational MessagingTele-communicationShared-Screen TeleconferencingVideo Conference


2006年７月１日初版第１刷

著作・監修ＩＴスキル標準プロフェッショナルコミュニティ

ＩＴアーキテクト委員会

発行者独立行政法人情報処理推進機構（ＩＰＡ）

IT スキル標準センター〒113-6591東京都文京区本駒込2-28-8 文京グリーンコートセンターオフィス16階

TEL：03-5978-7544／FAX：03-5978-7516

http://www.ipa.go.jp/jinzai/itss/index.html

Ⓒ200６ IPA All Rights Reserved

――本書の無断複製・転載を禁じます――

参照アーキテクチャ 調査報告 （2005年度）itスキル標準®...

Documents

参照アーキテクチャ調査報告（2005年度）itスキル標準®...