【18-C-3】システムアーキテクチャ構築の実践手法

システムアーキテクチャ構築の
実践手法 ( ISBN978-4-7981-2164-2 )

18-C-3 吉田幸彦
日本アイ・ビー・エム株式会社
アプリケーション開発事業
エグゼクティブＩＴアーキテクト
Developers Summit 2011

目次
 アーキテクチャとは？
 アーキテクチャは誰によって使われ何故有益なのか？
 アーキテクチャはどの様に表現されるか？
 アーキテクトはどの様にアーキテクチャを描き・洗練するのか？
 ソフトウェア開発プロジェクトにおけるアーキテクトの役割は？


アーキテクト・アーキテクチャ・
アーキテクティング
－実行する
アーキテクトアーキテクティング

－作成する－結果を生む
アーキテクチャ

アーキテクトはアーキテクティング（アーキテクチャを構築する活動）
を実践しアーキテクチャを構築するプロフェッショナル


アーキテクチャとは
アーキテクチャ：
コンポーネント、あるいはコンポーネント相互間や
コンポーネントと環境との関係で具体化されるシステムの基本的な構造と
そのデザイン・進化を導く方針
（IEEE Std 1471-2000）

「システムの構造（構成要素、配置）や振る舞い」
「システムの設計・開発の方針」
「将来、どの様にシステムを進化させるか」

を決定するのがアーキテクト


アーキテクチャとは構造である
 構造＝
構成要素（コンポーネント）と、その間の動的、静的な関係を定義したもの
 構成要素はインターフェースを持っている
 構成要素は入れ子の関係
 範囲（システム・コンテクスト）が重要マトリョーシカ
（入れ子構造の
ロシア人形）
写真
システム・コンテクスト

コンポーネント

コンポー
コンポー
ネント何を対象とした構造で
コンポーネント関係
ネント
あるかはコンテクストに
より決まる !!


システム構造と構成要素と責務
(1000) (2000)
ユーザーユーザー

(2000)
システム (500)
ｸﾗｲｱﾝﾄ・
責務 S/W ｸﾗｲｱﾝﾄ・ S/W
ﾉｰﾄﾞﾉｰﾄﾞ
H/W S/W 責務
責務責務 H/W
責務
(60)
(20)

S/W 責務
H/W
責務
拠点ｻｰﾊﾞｰ･ﾉｰﾄﾞ
(6)
(4)

責務 S/W 責務
H/W
(1)
全社ｻｰﾊﾞｰ･ﾉｰﾄﾞ

アーキテクチャの特徴
• 見えない構造の可視化であり、その解釈は一義的でなければならない
• 設計・実装上の判断のよりどころとなる（制約ととらえるのでなく指針）
• アーキテクチャは設計され、実装され、アセット化され再利用される
• システム（ソフトウェア）構造の判断は開発の初期になされる
• 開発対象の特定のため
• 役割や作業の分担のためアーキテクチャ上の判断
• その時点では実際のシステム（ソフトウェア）は存在しない
• 十分な情報が揃った上で検討がなされることは少ない
• 厳密な意味での実証的な確認がとれない
アーキテクチャの評価

• 構成要素の設計・実装を並行して進めることが可能となる
• システムの整合性、長期ライフ、低コスト化の源泉となる
• 共通言語としてコミュニケーション促進をはかることができる

アーキテクチャ上の判断
必ずしも十分な情報が得られない段階において，不確定要素を考慮し，起こ
り得る開発上のリスクを踏まえて，システム（ソフトウェア）設計の方向付
けを行う必要がある (アーキテクチャ上の判断：Architectural Decision)

判らないことに対する判ることに基いた
リスク判断アーキテクチャ上の判断

リスク
評価評価必要な情報評価

実現可能性はより必要な情報が揃うにつれて，設計の詳細化に応じて，
決められたチェックポイントで再評価する

ステークホールダ
アーキテクチャは誰によって使われ何故有益なのか？
ステークホールダ：
システムに関して興味または関心事を有する個人、チーム、組織
（IEEE Std 1471-2000）
「課題をそのシステムによって解決したい」要求者
「開発または運用の費用を負担する」取得者（オーナー）
「解決・実現方法を考える」コンサルタント / アーキテクト
ビジネスアナリストなど

「そのための情報システムの構造を考える」アーキテクト
「その情報システムを開発する」開発者
「システム運用を任される」運用者
アーキテクトは技術上のコミュニケーションにも関わる

アーキテクチャの表現
対象をどう表現すれば、関係者が、その対象（本質や価値）を認識し、その構
造を一義的に解釈することができるか？

 僅か一部分を取り上げたところで、その対象の全てが分かる訳ではない
 また、一枚の絵図で対象のすべてを表すことはできないであろう
 そこから対象に対する同一の理解に達することは不可能に近い（？）
 対象の本質を表現し理解するためには複数の適切な視点（ビュー）にもと
づく表現が必要
 ステークホールダの関心事に応じた視点の採用が必要


アーキテクチャの表現．．
アーキテクチャをどう表現すれば、ステークホールダがシステムの構造を一義的に解釈で
き、そのシステムおよび実現方法の価値を認識することができるか？

ビュー：
関連する一組の関心事の視点からシステム全体を表現したもの
（IEEE 1471-2000）
補足：一人以上のステークホールダが抱いている一つまたはそれ以
上の関心事にアーキテクチャがどう対応するかを示すアーキテクチャ
の一つ以上の構造的側面を表現したものである

ビューポイント：
ビューを作成し、使用するための約束事の詳細仕様である。また、
ビューの目的や利用者を明確にして、それぞれのビューを作成するた
めのパターンもしくはテンプレートであり、それらを作成し分析するた
めのテクニックである
（IEEE 1471-2000）


ビュー / ダイアグラム / モデル

ステークホールダステークホールダ
グループＡグループＢ

機能ビュー配置ビュー
ダイアグラムダイアグラムダイアグラム

機能モデル配置モデル


配置ビューポイント (参考)
説明このビューポイントは、システムの配置を支援し、ロケーション、ノード、デ
バイス、および、それらの間のコネクションなどのアーキテクチャ要素に関
係する
ステークホルダの関心事システム配置、ハードウェアノード(および、デバイス)仕様、および、ネット
ワーク仕様

ステークホルダ構成管理者、開発者、保守要員、プロジェクトマネージャ、サプライヤ、サ
ポート要員、システム管理者、および、テスター
ワークプロダクトアーキテクチャ上の判断、アーキテクチャ概要、および、配置モデル

チェックリスト配置要素は関連する規定された機能および非機能（品質および制約）要
求を支援するか？特別な制約として、既存環境からの移行、コスト、実装
スケジュール（必要なハードウェア取得のためのリードタイムを含む）、お
よび、データセンター内の空きスペースのような物理的制約が含まれる。
配置要素は要求に対して追跡可能性が保持されているか？機能ビュー
におけるすべての構成要素は配置ビューのノードに対して配置している
か？ノードとロケーション間のコネクションは機能要素間で相互作用を支
援するために存在するか？
物理的配置要素はノードおよびデバイスの数、それらの詳細仕様に関し
て十分詳細に定義されているか？すべてのオペレーティングシステムの
ような第三者ソフトウェア要求は、ソフトウェアライセンスを必要とするラン
タイム要素とともに特定されているか？

ステークホールダ．．
役割開発主要な責任
チーム
アプリケーション
外部システム開発を委託する(資金を供給する)
オーナー
ビジネス管理者外部実稼働システムのビジネス関連要素を管理する
構成管理者内部構成管理レポジトリとそれに属する要素の構造を定義する
開発者内部詳細設計およびシステムの実装を実行する
保守要員外部実稼働後のシステムに対する拡張・保守を管理する
計画、要員、監視、および、リスク管理の面から開発プロ
プロジェクト管理者内部
ジェクトの実行を管理する
システムの開発もしくは実行に必要とされるソフトウェアも
サプライヤ外部
しくはハードウェア要素を提供する
サポート要員外部システムサポートおよび診断機能の実行を提供する
システム管理者外部システムの実稼働を管理運用する
目的に合った機能・品質を確認するためにシステムをテス
テスタ内部
トする
ユーザ外部システムのビジネス機能の使用する

アーキテクト：すべてのビューポイントにおいてステークホールダとみなされる

基本および横断的ビューポイント

グループＡグループＢグループＣグループＤ

要求機能配置妥当性確認
ビューポイントビューポイントビューポイントビューポイント

パフォーマンス配置コンポーネント
コンポーネント
性能要求ハードウェア仕様性能確認要素
ビューポイント結合
分散トポロジー
グループＥ

セキュリティセキュリティ
ビューポイントセキュリティ要求ポリシーセキュリティ
ファイアウォール
ユーザー認証確認要素
グループＦユーザー権限


ビューポイントと成果物

ビジネスエンティ アーキテクチャ アーキテクチャ アーキテクチャ
ティ・モデル上の決定上の決定検証
パフォーマンス
ビジネスプロセ アーキテクチャ アーキテクチャ アーキテクチャ
ビューポイント
ス・モデル概要概要構想実証
ビジネスルール データモデル 配置モデル RAIDログ
変更要求 機能モデル レビュー記録
EA基本原則
セキュリティ 既存IT環境
ビューポイント 機能要求
用語集
非機能要求
優先順位付要求
リスト
：
ステークホール
：
ダ要求 EA ( Enterprise Architecture )
：
システムコンテク RAID ( Risk, Assumption, Issue, Dependency )
：
スト
ビジュン


アーキテクチャ記述
 対象システムの特徴により重点は異なる
 システムの運用や管理が重要？
 可用性が重要？
 パフォーマンスが重要？
 セキュリティが重要？
 メリハリをつけたアプローチが重要
 既知のベストプラクティスの適用（再利用による促進）
 未経験の領域へ挑戦（専門家の組織化）
 先進技術の適用（構想実証による検証）

 適切なビューとワークプロダクトの採用
 要求と制約を満たし運用が可能なアーキテクチャであることを確認
 ステークホールダーの承認を得るための客観的根拠の提示
 詳細設計と実装の指針となる

主要ワークプロダクトと責任ロール

ビジネスビジネスエンテビジネスプロセビジネスルー機能要求非機能要求
アナリストィティモデルスモデルル

優先順位付ステークホールシステムコンテビジョン用語集
要求一覧ダ要求クスト

リードアーキテクチャアーキテクチャアーキテクチャアーキテクチャソフトウェア
アーキテクト評価上の判断概要構想実証アーキテクチャ
文書

機能モデル配置モデルデータモデル変更要求 RAIDログレビュー記録
アプリケーションインフラデータプロジェクト
アーキテクトアーキテクトアーキテクトマネージャ


関連ロール
プロジェクト
マネージャ

リード
アーキテクト

ビジネス
プロジェクト
プロジェクト
アナリスト
マネージャアプリ
マネージャ
アーキテクト

プロジェクト
開発者
プロジェクトインフラ
マネージャ
マネージャアーキテクト

プロジェクトデータ
テスター
プロジェクト
マネージャアーキテクト
マネージャ


アーキテクチャ文書

表紙７．妥当性確認ビュー
変更履歴８．アプリケーションビュー
目次、図表リスト、参照文献９．インフラストラクチャビュー
１．アーキテクチャ文書の目的１０．システム管理ビュー
２．アーキテクチャの概要１１．可用性ビュー
３．アーキテクチャ上の判断１２．パフォーマンスビュー
４．要求ビュー１３．セキュリティビュー
５．機能ビュー付録
６．配置ビュー


アプリケーション ビジネスエンティ アーキテクチャ上 アーキテクチャ上 アーキテクチャ
ビューポイントティ・モデルの決定の決定検証
ビジネスプロセス・ アーキテクチャ アーキテクチャ アーキテクチャ
モデル概要概要構想実証
インフラストラクチャ
ビジネス・ルール データモデル 配置モデル RAIDログ
変更要求 機能モデル レビュー記録
EA基本原則
システム管理
既存IT環境
機能要求
用語集
可用性 非機能要求
ビューポイント 優先順位付要求
リスト
パフォーマンス ステークホールダ
ビューポイント要求
システムコンテク
セキュリティスト
ビューポイント ビジュン


アーキテクチャ文書（例） P241

１．システム化の基本方針７．システム管理
２．システム概要７．１．システム管理シナリオ
２．１．アーキテクチャの概要７．２．システム管理モデル
２．２．システムの特徴８．可用性と障害対策
３．アーキテクチャ上の判断８．１．可用性シナリオ
３．１．課題と関心事８．２．可用性モデル
３．２．選択肢と判断９．パフォーマンス
４．システム基本要求９．１．パフォーマンスシナリオ
４．１．機能要求９．２．パフォーマンスモデル
４．２．非機能要求１０．セキュリティ
４．３．将来要求１０．１．脅威と対応シナリオ
５．機能的側面１０．２．セキュリティモデル
５．１．機能モデル１１．妥当性確認
５．２．データモデル１１．１．アーキテクチャ評価
６．実行基盤的側面１１．３．リスクと今後の対応
６．１．ロケーションモデル
６．２．システム構成要素
６．３．論理構成図
６．３．物理構成図


アーキテクティング

－実行する




手法の概念とその関係
分割する考慮する

プロセス

フェーズ反復アクティビティ

参照する

実行される

タスクロール
メソッド
コンテンツ

利用・作成責任を負う
する

ワークプロダクト


タスク記述例（共通ボキャブラリの捕捉）
タスク名共通ボキャブラリの捕捉
目的このタスクの目的は、ステークホールダーによって使われる共通ビジネ
スおよび技術用語が理解され文書化されるか確認することである。
ロールビジネスアナリスト（主）、ステークホールダ（主）、アプリ・アーキテクト
（副）、インフラ・アーキテクト（副）
入力ビジネスエンティティモデル（オプション）、ビジネスプロセスモデル（オプ
ション）、EA基本原則（オプション）、ステークホールダの要望、ビジョン
出力用語集
ステップ共通ボキャブラリの特定
アーキテクト使用する技術用語の定義を支援する
のロール


タスク記述例（非機能要求の概要記述）
タスク名非機能要求の概要記述
目的このタスクの目的は、非機能要求の概要を記述することである。

ロールビジネスアナリスト（主）、ステークホールダ（副）、アプリ・アーキテクト
（副）、インフラ・アーキテクト（副）
入力ビジネスルール（オプション）、EA基本原則（オプション）、ステークホー
ルダの要望、システムコンテクスト、ビジョン
出力非機能要求
ステップ非機能要求を特定する
非機能要求の概要を記述する
アーキテクト適切な非機能要求が検討されていることを確認する
のロール非機能要求が適切な作法で表現されていることを確認する


アーキテクチャ構築の概要
要求アーキテクチャ開発

要求の定義論理アーキテクチャ論理詳細設計
の作成の作成

物理アーキテクチャ物理詳細設計
の作成の作成


要求定義アクティビティ
ステークホールダ共通ボキャブラリシステムコンテクスト
要望の収集の捕捉の定義

機能要求の概要記述非機能要求の概要記述

関係するロール（役割）
SH：ステークホールダ要求の優先順位付け
PM：プロジェクトマネージャ
BA：ビジネスアナリスト
LA：リードアーキテクト
AA：アプリ・アーキテクト機能要求の詳細化非機能要求の詳細化
IA：インフラ・アーキテクト
DA：データ・アーキテクト

ソフトウェアステークホールダ
アーキテクチャ文書との要求を確認
の更新

タスク名ステップ主担当副担当

ステークホルダステークホルダの特定 BA, SH AA，IA
要望の収集ステークホルダ要望の収集
ステークホルダ要望の優先順位付け
共通ボキャブラ共通ボキャブラリの特定 BA, SH AA, IA
リの捕捉
システムコンテアクターの特定 BA LA, SH
クストの定義アクターのいるロケーションの特定
データフローの特定
機能要求の概機能要求の特定 BA AA, SH
要記述機能要求の概要
非機能要求の非機能要求の特定 BA AA, IA,
概要記述非機能要求の概要記述 SH
要求の優先順要求の優先順位付け BA, LA PM, SH
位付け


機能要求のユースケースの詳細化 BA AA, SH
詳細化（反復毎に各ユースケースに対して）
ユースケースのデータフィールドの詳細化
システム全体に関わる機能要求の詳細化
機能要求シナリオの詳細化
非機能要求の非機能要求の詳細化 BA AA, IA,
詳細化（反復毎に各非機能要求に対して） SH
非機能要求シナリオの詳細化
ソフトウェアソフトウェアアーキテクチャ文書の更新 LA
文書の更新
ステークホルダベースラインとなるワークプロダクト BA, LA, AA, IA,
との要求確認ワークプロダクトの整理 SH DA
ワークプロダクトのレビュー


アーキテクチャ作成アクティビティ
（論理・物理）
アーキテクチャアーキテクチャ概要アーキテクチャ上の判断
アセットの調査の定義の文書化

機能要素の概要記述配置要素の概要記述

アーキテクチャアーキテクチャ
の検証構想実証
機能要素の詳細化配置要素の詳細化の構築

関係するロール（役割）
SH：ステークホールダ
PM：プロジェクトマネージャ
BA：ビジネスアナリストアーキテクチャのソフトウェアステークホールダ
LA：リードアーキテクト妥当性確認アーキテクチャとの要求確認
AA：アプリ・アーキテクト文書の更新
IA：インフラ・アーキテクト
DA：データ・アーキテクト Developers Summit 2011

アーキテクチャアセットアーキテクチャアセットの調査 LA AA, IA,
の調査 DA
アーキテクチャ概要アーキテクチャ概要の定義 LA AA, IA,
の定義 DA
アーキテクチャ上の判断課題または関心事の捕捉、収集 LA AA, IA,
の文書化アセットの選択肢 DA
望ましい選択肢
判断の文書化
機能要素の概要記述サブシステムの特定 AA DA,
コンポーネントの特定 IA
配置要素の概要記述ロケーションの特定 IA AA,
ノードの特定 DA


アーキテクチャの検証検証の計画化 LA AA,
キックオフミーティングの開催 DA,
検証作業の実施 IA
検証確認ミーティングの実施
再検証作業の実施
フォローアップ作業の実施
アーキテクチャ構想実証アーキテクチャ構想実証の作成 LA AA,
の構築発見および知見の文書化 DA, IA
機能要素の詳細化コンポーネントインターフェースの定義 AA DA,
オペレーションおよびオペレーションシ IA
グネチャの定義
コンポーネント間のコントラクトの定義
配置要素の詳細化コンポーネントのノードへの割当て IA AA,
ノード間のコネクション定義 DA
ロケーション間のコネクション定義


アーキテクチャの妥当性妥当性確認の計画化 LA AA,
確認アーキテクチャのレビュー DA,
発見および知見の文書化 IA,
リスクの評価と提言 PM

ソフトウェアアーキテクソフトウェアアーキテクチャ文書の更新 LA
チャ文書の更新
ステークホルダとのアーベースラインとなるワークプロダクト LA, SH AA,
キテクチャレビューワークプロダクトの整理 DA,
ワークプロダクトのレビュー IA


YouTour

代表的ワークプロダクト
（要求定義アクティビティ）
役割開発主要な責任カテゴリ要求説明
チーム
ユーザビリティアクセサビリティ当社組織標準に従って、視覚、聴覚、もしくは、認識障害
アプリケーション
外部システム開発を委託する(資金を供給する) のある方を支援する。
オーナー
リライアビリティ可用性ツアー予約のような安全なアクセスが必要とする機能を
ビジネス管理者外部実稼働システムのビジネス関連要素を管理する 99.9%提供する。システムはツアー参照のようなほかの
構成管理者内部構成管理レポジトリとそれに属する要素の構造を定義するすべての機能を99%提供する。バックアップや保守作業
はシステムの停止を必要としない。
開発者内部詳細設計およびシステムの実装を実行する
パフォーマンス応答時間 10秒未満でツアー予約確認を実施する
保守要員外部実稼働後のシステムに対する拡張・保守を管理するサポータビリティスケーラビリティ 10万登録ユーザと5千人の同時ユーザを支援する
計画、要員、監視、および、リスク管理の面から開発プロサポータビリティテスト容易性すべてのトランザクションとそのペイロードを確認するた
プロジェクト管理者内部
ジェクトの実行を管理するめに、どんなトランザクションの内容もログに記録すること
システムの開発もしくは実行に必要とされるソフトウェアもが出来る。
サプライヤ外部
しくはハードウェア要素を提供するビジネス制約スケジュール 6ヶ月未満でリリースされる。
サポート要員外部システムサポートおよび診断機能の実行を提供するアーキテクチャ制約コミュニケーション相互運用のため業界標準のWebプロトコルを使用する。
システム管理者外部システムの実稼働を管理運用するアーキテクチャ制約レガシー統合顧客情報保存のため既存のCRMシステムを利用する。
目的に合った機能・品質を確認するためにシステムをテス
テスタ内部

機能要求
トする開発制約プラットフォーム Internetデバイス（WebブラウザやPDAなど）を介して利
サポート用できる
ユーザ外部システムのビジネス機能の使用する
開発制約標準コンプライアンス当社開発標準に従って開発される。

ステークホールダ一覧（ユースケース図）非機能要求

テーマ説明
課題 YourTourは，定期的に更新する必要のある少数のビジネスルール（おそら
く50未満）を使用する．その目的は，これらのルールを開発者ではなくビジ
ネスユーザが更新できるようにすることである．ルールは，ある種の条件の
に使われる．
アーキテクチャ上パッケージソリューション又はコードに埋め込まれたルールを使用せずに，
の判断自前のルールエンジンコンポーネントを開発する．

仮定ビジネスルールの数を比較的少数（50未満）に制限し，比較的低頻度で（年
2回未満）変更する．

候補案オプション１：コードの中にルールを埋め込む．
オプション２：自前のルールエンジンコンポーネントを開発する．
オプション３：ルールエンジンパッケージを購入する．
選択された案オプション２
正当とする理由ルールをコード中に埋め込むのは，ソフトウェアエンジニアリングの関心事
の分離原則に反し，ルールの変更を困難にする悪いプラクティスである．
ルールエンジンンパッケージを購入するのは，管理すべきルールの数が少
ないことやルール変更の頻度が低いことを考えるとコスト効率が良くない．

システムコンテクスト図アクターとロケーションアーキテクチャ上の判断

YouTour

代表的ワークプロダクト
（アーキテクチャ作成アクティビティ（論理・物理））
【機能要素】【配置要素】
[T] [ R/W ] [R] <<Location>>
セッションツアールール本社
.
ツアー主催者カート予約
CRMシステム
ツアー予約者コンテンツセキュリティ
決済エンジン予約システムプレゼンテーションツアープロセスツアーアプリケーション
管理サーバー
統合制御サービス統合
決済エンジンサーバー
<<Boundary>> <<Boundary>> <<Boundary>> .
顧客決済エンジン
Tour Booker Paym’t Engine Reservat’n Sys.
Boundary Boundary Boundary
予約システム
コンテンツセキュリティ
管理サービス
ツアー統合
販売担当者予約システム
<<Control>> 予約サーバー
< Book Tour サーバー
Controller
[ R/W ] [ R/W ] [ R/W ] [ T ] ：一時データ
コンテンツ Web ユーザー [ R ] ：読取専用データ
<<Entity>> <<Entity>> ページオペレータ [ R/W ] ：読書データ
Tour Manager Tour Booking CRM
Manager サーバー

アーキテクチャ概要
ユースケースから導出
されたコンポーネント本社ロケーション上のノード
外部ネットワーク非武装地帯内部ネットワーク

.

<<Location>> ツアー主催者 CRMシステム
本社
F/W Web F/W ツアー予約統合 <<Location>>
Contents コンテンツセキュリティ
<<Deploy>> <<Deploy>> Security サーバーサーバーサーバー本社
<A>
Management 管理サーバー <A>
Components
サーバー決済エンジン
Components .
顧客決済エンジン管理者クライアントディスクアレイ
ツアー統合型式 / モデル
<<Deploy>> Integration 型式 / モデル
予約サーバー予約システム
<A>
Components メモリ : メモリ :
サーバーコンテンツディレクトリ製造者 : 製造者 :
管理セキュリティ
<<Boundary>> 販売担当者予約システム
CRM <<Manifest>> サーバーサーバー
CRM System
サーバー Boundary
<<Boundary>> Webサーバーツアー予約サーバーデータベースサーバー
<<Manifest>>
Paym’t Engine
型式 / モデル型式 / モデル型式 / モデル
<<Deploy>> <<Deploy>> <<Deploy>> Boundary F/W : ファイアウォールメモリ : メモリ :
メモリ :
Tour Booking Tour Booking Tour Booking <<Boundary>> 製造者 :
<<Manifest>> 製造者 : 製造者 :
<A>
UI Components <A>
Control <A>
Entity Reservat’n Sys.
Components Components

物理アーキテクチャ概要
Boundary
<<Manifest>> <<Entity>>
<<Manifest>> <<Manifest>>
Tour Booking
<<Manifest>> Manager <<Entity>>
<<Boundary>> <<Control>> コンテンツ管理サーバーセキュリティサーバー統合サーバー
< Tour Rules
Tour Booker Book Tour
Boundary <<Entity>> 型式 / モデル型式 / モデル型式 / モデル
Controller <<Manifest>>
Tour Manager メモリ : メモリ : メモリ :
<<Entity>> 製造者 : 製造者 : 製造者 :
<<Manifest>>
Transaction
Log

本社ロケーションノード上に本社ロケーションの
配置されたコンポーネント Developers Summit 2011 物理配置モデル

アーキテクト

－実行する




職種・専門分野・役割
 職種（ Profession : 専門的職業）
 建築、工学、数学、自然科学、コンピュータ、生命科学、社会科学、医学、保健、
教育、博物館学、図書館学、法学、神学、著述、芸術、音楽、芸能、ファッション･
モデル、企業経営者および管理者
(アメリカ移民局 H-1Bビザ(専門職用)で定義された職業分野)

 専門分野（ Discipline : 専門性を発揮する得意な分野）
 専門性（スキル・経験・レベル）に関する裏づけがある
 専門性に関する定義が必要（例）
【医学】外科、内科、眼科、循環器科、皮膚科、歯科．．．
【建築】都市計画、建築計画、建築構造、建築材料・施工．．．

 役割（ Role : 職務遂行上の立場）
 どのような立場で職務を遂行するか?
 専門性（スキル・経験・レベル）を活かせることが望ましい（例）
【ロボット開発】プロジェクトマネジャ、オーガニック系（解剖学医、整形外科医）、
メカニック系（機械工学技士）、エレクトロニクス系（電子工学技士）．．．

ITスキル標準第3版
( ITSS : IT Skill Standards V3 )
職種アーキテクト

専門分野

ITスキル標準V3ダウンロード：
http://www.ipa.go.jp/jinzai/itss/download_V3_2008.html

まとめ
 アーキテクチャとは？
 アーキテクチャは誰によって使われ何故有益なのか？
 アーキテクチャはどの様に表現されるか？
 アーキテクトはどの様にアーキテクチャを描き・洗練するのか？
 ソフトウェア開発プロジェクトにおけるアーキテクトの役割は？


【18-C-3】システムアーキテクチャ構築の実践手法

【18-C-3】システムアーキテクチャ構築の実践手法

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(20)

Similar to 【18-C-3】システムアーキテクチャ構築の実践手法

Similar to 【18-C-3】システムアーキテクチャ構築の実践手法(20)

More from Developers Summit

More from Developers Summit(20)

【18-C-3】システムアーキテクチャ構築の実践手法