要求開発アライアンス · 他の技術・技沵との違い（その1） • EA （（（（（エンタープライズアーキテクチャエンタープライズアーキテクチャエンタープライズアーキテクチャエンタープライズアーキテクチャ）

要求開発アライアンス

チュートリアル

第二回「モデリング編」

萩本順三

モデリング編の内容

• Ｏｐｅｎthologyで利用を推薦するモデルおよび

成果物について、その利用目的と書き方を説明します。

• UMLモデリングについて、時間制限はあります

ができるかぎり詳しい説明を行います。

• ビジネス改善として行うモデル（トップダウンビジネス改善、ボトムアップビジネス改善）については、次回業務改革編で解説を行います。

目次

• 前回までのあらすじ（プロセス編）

• Openthologyモデル全体像

• モデリング詳細説明

• モデル化そもそも論

• 次回予告

Openthologyのモデルと目標

業務システム

ビジネスビジネスビジネスビジネスTo-Be, Realizeモデルモデルモデルモデル

Aシステムシステムシステムシステム分析分析分析分析モデルモデルモデルモデル

設計設計設計設計モデルモデルモデルモデル

Bシステムシステムシステムシステム

設計設計設計設計モデルモデルモデルモデル

分析分析分析分析モデルモデルモデルモデル

①①①①プロセスプロセスプロセスプロセスののののモデルモデルモデルモデル化化化化（（（（前回前回前回前回ののののチュートリアルチュートリアルチュートリアルチュートリアル））））

（（（（作業作業作業作業のののの時系列時系列時系列時系列をををを可視化可視化可視化可視化したしたしたしたモデルモデルモデルモデル））））

②②②②スケッチモデルスケッチモデルスケッチモデルスケッチモデル（（（（UML)

（（（（今回今回今回今回ののののチュートリアルチュートリアルチュートリアルチュートリアル））））（（（（瞬間瞬間瞬間瞬間のののの写像写像写像写像モデルモデルモデルモデル））））

最終

課題

④④④④ヒューマンプロセスヒューマンプロセスヒューマンプロセスヒューマンプロセスののののモデルモデルモデルモデル化化化化（（（（育育育育てのてのてのてのモデルモデルモデルモデル））））（（（（参加者感情参加者感情参加者感情参加者感情のののの統制統制統制統制バランスモデルバランスモデルバランスモデルバランスモデル））））（（（（永遠永遠永遠永遠にににに価値価値価値価値をををを出出出出せるせるせるせるモデルモデルモデルモデル））））チュートリアルチュートリアルチュートリアルチュートリアル未定未定未定未定（（（（笑笑笑笑））））

ビジネスビジネスビジネスビジネスAs-Isモデルモデルモデルモデル

ビジネスモデル

③③③③ディスカバリモデルディスカバリモデルディスカバリモデルディスカバリモデル

（（（（次回次回次回次回ののののチュートリアルチュートリアルチュートリアルチュートリアル））））（（（（As-IsからからからからToBeへへへへ。。。。変化変化変化変化のののの過程過程過程過程をををを可視化可視化可視化可視化））））

ITシステム

ITシステム

ITシステム

ITシステム

ITシステム

前回までのあらすじ（プロセス編）

ＴｏＢｅかＡｓＩｓか？

• ＴｏＢｅ先行– 長所

• やるべき活動が明確になり、それにあわせて改善すべきポイントにフォーカスしたＡｓＩｓが実施可能

– 短所• 明確なＡｓＩｓを持たずにＴｏＢｅを行うと現実的が問われる結果を出し

やすい

• ＡｓＩｓ先行– 長所

• 現状をふまえた問題点・改善点の合意を取りやすい。特に複数部門の最適化を目指す場合は、現状の業務モデルの可視化が有効

– 短所• 現状にとらわれすぎて、ＴｏＢｅを描けなくなってしまいやすい

ＴｏＢｅかＡｓＩｓか？開発タイプの分類

【新工程】新製造法・製造工程新テクノロジによるシステム改革

【新業務】提携業務システム人事・経理システム

【新商品】モバイル・ツール組み込み

【新商法】AMAZONE.COM

「仕事のやり方」を変える。

「商品」そのものを変える

「新しい価値」を創る

コスト・ダウンをはかる

ToBe

重視重視重視重視

AsIs

重視重視重視重視

ビジネスを可視化する際の対象領域

• ビジネス課題とビジネスオペレーション

ビジネス課題（戦略）会社の提供する価値とは何か

会社外側に向けた活動の可視化

ビジネスオペレーション会社の提供する価値をどのように実現するか

会社内部の活動の可視化

ビジネス可視化の構成要素と要求の関係

ＯＵＴＯＵＴＯＵＴＯＵＴ（（（（戦略戦略戦略戦略））））

ＩＮＩＮＩＮＩＮ（（（（戦術戦術戦術戦術））））

ビジネス戦略の可視化

ビジネスオペレーション

の可視化

TopDown

BottomUp

現場

オーナー

表（会社の提供する価値）

裏（会社の価値を実現する方法）

表裏一体である

cd cd cd cd ビジネスビジネスビジネスビジネス可視化可視化可視化可視化

活動活動活動活動

改善改善改善改善

新規新規新規新規

システムシステムシステムシステム

ビジネスビジネスビジネスビジネス

要求要求要求要求

情報情報情報情報

組織組織組織組織

ルールルールルールルール

フローフローフローフロー

サービスサービスサービスサービス

アクターアクターアクターアクター

方法方法方法方法

ビジネスビジネスビジネスビジネス課題課題課題課題

ステイクホルダステイクホルダステイクホルダステイクホルダ

競合他社競合他社競合他社競合他社ユーザユーザユーザユーザ提携企業提携企業提携企業提携企業

フローフローフローフロー（（（（バリューチェーンバリューチェーンバリューチェーンバリューチェーン））））


ビジネスビジネスビジネスビジネス戦略戦略戦略戦略

他の技術・技法との違い（その１）

•• EAEA（（（（エンタープライズアーキテクチャエンタープライズアーキテクチャエンタープライズアーキテクチャエンタープライズアーキテクチャ））））（（（（エンタープライズアーキテクチャエンタープライズアーキテクチャエンタープライズアーキテクチャエンタープライズアーキテクチャ））））– Openthologyは、EAにおけるビジネスアーキテクチャとアプリケーションアーキ

テクチャを繋げる手法を提供します。– Openthologyは、EAにおけるアプリーケーションアーキテクチャとデータアーキ

テクチャ、テクニカルアーキテクチャを構築するための実践的な手法を提供します。

(注実際の構築手法は豆蔵enThologyなどにより提供されます)

Technical

Architecture

Application

Architecture

Data

Architecture

Business

Architecture

データデータデータデータデータデータデータデータモデルモデルモデルモデルモデルモデルモデルモデル

オブジェクトオブジェクトオブジェクトオブジェクトオブジェクトオブジェクトオブジェクトオブジェクトモデルモデルモデルモデルモデルモデルモデルモデル

アプリケーションアプリケーションアプリケーションアプリケーション・・・・プロセスプロセスプロセスプロセスアプリケーションアプリケーションアプリケーションアプリケーション・・・・プロセスプロセスプロセスプロセス

ビジネスビジネスビジネスビジネス・・・・プロセスプロセスプロセスプロセスビジネスビジネスビジネスビジネス・・・・プロセスプロセスプロセスプロセスビジネスビジネスビジネスビジネス要求要求要求要求ビジネスビジネスビジネスビジネス要求要求要求要求

システムシステムシステムシステム要求要求要求要求システムシステムシステムシステム要求要求要求要求

ビジネスビジネスビジネスビジネスビジネスビジネスビジネスビジネス

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

フレームワークフレームワークフレームワークフレームワークフレームワークフレームワークフレームワークフレームワーク

実装実装実装実装アーキテクチャアーキテクチャアーキテクチャアーキテクチャ実装実装実装実装アーキテクチャアーキテクチャアーキテクチャアーキテクチャ

ビジネスビジネスビジネスビジネス戦略戦略戦略戦略ビジネスビジネスビジネスビジネス戦略戦略戦略戦略

ビビビビビビビビジジジジジジジジ

ネネネネネネネネスススススススス

II

TTシシシシシシシシスススススススス

テテテテテテテテムムムムムムムム

プロセスプロセスプロセスプロセス構造構造構造構造プロセスプロセスプロセスプロセス構造構造構造構造サービスサービスサービスサービス構造構造構造構造サービスサービスサービスサービス構造構造構造構造情報構造情報構造情報構造情報構造情報構造情報構造情報構造情報構造

OpenOpenthologythology

繋繋繋繋げるためのげるためのげるためのげるための手法手法手法手法

EAEA

構築手法構築手法構築手法構築手法

他の技術・技法との違い（その２）

•• RUPRUP（（（（（（（（ラショナルラショナルラショナルラショナル・・・・ユニファイドユニファイドユニファイドユニファイド・・・・プロセスプロセスプロセスプロセスラショナルラショナルラショナルラショナル・・・・ユニファイドユニファイドユニファイドユニファイド・・・・プロセスプロセスプロセスプロセス））））））））– RUPは、１プロジェクトの中でビジネスモデリングを行いますが、

Openthologyは企業レベルでビジネスのプロセスとモデルを形成します。

– RUPは、Openthology（要求開発）の後方工程に適合可能なプロセスです。

OpenOpenthologythology

プロセスワークフロープロセスワークフロープロセスワークフロープロセスワークフロープロセスワークフロープロセスワークフロープロセスワークフロープロセスワークフロー

サポートワークフローサポートワークフローサポートワークフローサポートワークフローサポートワークフローサポートワークフローサポートワークフローサポートワークフロー

プロジェクトプロジェクトプロジェクトプロジェクト管理管理管理管理

ツールツールツールツール・・・・環境整備環境整備環境整備環境整備

ビジネスモデリングビジネスモデリングビジネスモデリングビジネスモデリング

実装実装実装実装

テストテストテストテスト

分析分析分析分析・・・・設計設計設計設計

予備反復反復1回目

反復2回目

反復N回目

反復N+1回目

配布配布配布配布

構成管理構成管理構成管理構成管理・・・・変更管理変更管理変更管理変更管理

要求分析要求分析要求分析要求分析

推敲推敲推敲推敲移行移行移行移行方向付方向付方向付方向付けけけけ作成作成作成作成

反復N+2回目

反復M回目

反復M+1回目

RUPRUP

ディシプリンディシプリンディシプリンディシプリンディシプリンディシプリンディシプリンディシプリン

計画計画計画計画

ＩＴＩＴＩＴＩＴ戦略設計戦略設計戦略設計戦略設計

システムシステムシステムシステム計画計画計画計画

ビジネスビジネスビジネスビジネス改善改善改善改善

現状分析現状分析現状分析現状分析

現状理解戦略策定

反復反復反復反復反復反復

フェーズフェーズフェーズフェーズフェーズフェーズフェーズフェーズ

DisciplineDiscipline

Openthologyモデル全体像

データデータデータデータデータデータデータデータモデルモデルモデルモデルモデルモデルモデルモデル

オブジェクトオブジェクトオブジェクトオブジェクトオブジェクトオブジェクトオブジェクトオブジェクトモデルモデルモデルモデルモデルモデルモデルモデル

OpenthologyOpenthology構造とモデル

アプリケーションアプリケーションアプリケーションアプリケーション・・・・プロセスプロセスプロセスプロセスアプリケーションアプリケーションアプリケーションアプリケーション・・・・プロセスプロセスプロセスプロセス

ビジネスビジネスビジネスビジネス・・・・プロセスプロセスプロセスプロセスビジネスビジネスビジネスビジネス・・・・プロセスプロセスプロセスプロセスビジネスビジネスビジネスビジネス要求要求要求要求ビジネスビジネスビジネスビジネス要求要求要求要求

システムシステムシステムシステム要求要求要求要求システムシステムシステムシステム要求要求要求要求

ビジネスビジネスビジネスビジネスビジネスビジネスビジネスビジネス

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

フレームワークフレームワークフレームワークフレームワークフレームワークフレームワークフレームワークフレームワーク

実装実装実装実装アーキテクチャアーキテクチャアーキテクチャアーキテクチャ実装実装実装実装アーキテクチャアーキテクチャアーキテクチャアーキテクチャ

ビジネスビジネスビジネスビジネス戦略戦略戦略戦略ビジネスビジネスビジネスビジネス戦略戦略戦略戦略

ビビビビビビビビジジジジジジジジネネネネネネネネスススススススス

II

TTシシシシシシシシスススススススステテテテテテテテムムムムムムムム

プロセスプロセスプロセスプロセス構造構造構造構造プロセスプロセスプロセスプロセス構造構造構造構造サービスサービスサービスサービス構造構造構造構造サービスサービスサービスサービス構造構造構造構造情報構造情報構造情報構造情報構造情報構造情報構造情報構造情報構造

ビジネスユースケースモデルビジネスユースケースモデルビジネスユースケースモデルビジネスユースケースモデル

業務業務業務業務フローフローフローフロー（（（（アクティビティアクティビティアクティビティアクティビティ図図図図））））ユースケースモデルユースケースモデルユースケースモデルユースケースモデル

ユースケースユースケースユースケースユースケース記述記述記述記述

ビジネスビジネスビジネスビジネス概念概念概念概念モデルモデルモデルモデル

DB

モデルモデルモデルモデル

分析分析分析分析・・・・設計設計設計設計モデルモデルモデルモデルクラスクラスクラスクラス図図図図

要求開発Openthologyモデリング全体像

cd cd cd cd 論理論理論理論理モデルモデルモデルモデル

0..*0..*

0..1

1..*

10..*

ud ud ud ud ユースケースモデルユースケースモデルユースケースモデルユースケースモデル

ad ad ad ad アクティビティアクティビティアクティビティアクティビティ

業務

システム

開始終了



業務

システム


終了開始


業務

情報

終了開始


現状ビジネスフロー図 IT戦略ビジネスフロー図

概念ビジネスフロー図

概念クラス図

要求開発

現状理解戦略策定

高高高高高高高高

現状現状現状現状ののののモデルモデルモデルモデル（（（（AsIs)

実現可能実現可能実現可能実現可能ななななモデルモデルモデルモデル(Realize)

理想理想理想理想ののののモデルモデルモデルモデル(ToBe)

ビジネスユースケースビジネスユースケース

ビジネス戦略


業務

システム

開始終了



業務

システム

開始終了



業務

システム

開始終了



業務

システム


終了開始

ビジネスビジネスビジネスビジネスののののビジネスビジネスビジネスビジネスのののの

抽象度抽象度抽象度抽象度抽象度抽象度抽象度抽象度

低低低低低低低低

システム基本要求書


業務

システム


終了開始

システム開発Openthologyモデリング全体像

cd cd cd cd 論理論理論理論理モデルモデルモデルモデル

0..*0..*

0..1

1..*

10..*

ud ud ud ud ユースケースモデルユースケースモデルユースケースモデルユースケースモデルcd cd cd cd 設計設計設計設計クラスクラスクラスクラス図図図図


業務

システム


終了開始


業務

情報

終了開始


IT戦略アクティビティ図

概念アクティビティ図

概念クラス図

要求開発

戦略策定

ビジネスユースケース

実現可能実現可能実現可能実現可能ななななモデルモデルモデルモデル(Realize)

システムユースケースシステムユースケースシステムユースケースシステムユースケース図図図図

s d s d s d s d 相互作用相互作用相互作用相互作用

論理モデル:: 論理モデル:: 論理モデル:: 論理モデル:: 論理モデル::

id id id id コンポーネントモデルコンポーネントモデルコンポーネントモデルコンポーネントモデル

パッケージパッケージパッケージパッケージ



cd cd cd cd 分析分析分析分析クラスクラスクラスクラス図図図図

0..*

0..*

0..1

1..*

dd dd dd dd コンポーネントモデルコンポーネントモデルコンポーネントモデルコンポーネントモデル

Node1Node1Node1Node1Node2Node2Node2Node2

Component 2Component 2Component 2Component 2



分析分析分析分析クラスクラスクラスクラス図図図図

システム開発

方向付け/推敲/構築/移行/評価

パッケージパッケージパッケージパッケージ図図図図

設計設計設計設計クラスクラスクラスクラス図図図図

配置図配置図配置図配置図

シーケンスシーケンスシーケンスシーケンス図図図図

高高高高高高高高

低低低低低低低低

ビジネスビジネスビジネスビジネスビジネスビジネスビジネスビジネスITITのののの抽象度抽象度抽象度抽象度のののの抽象度抽象度抽象度抽象度

システム基本要求

書

要求開発プロセスの大まかな流れとOpenthologyデシプリンの関係

①仮説ゴール

②現状分析

④ゴール

作業時間軸

目標軸

③ギャップ分析

要求開発計画

現状分析

ビジネス改善

戦略設計

モデル成果物一覧

説明重要度作業予測コスト◎…要求開発活動として重要大、中、小は、要求開発作業コストとして見た○…重要度低または要求開発活動外場合の、適切な作業配分をガイドしたもの

ビジネスオペレーションの可視化と要求

それぞれの観点はOpenthologyのモデルに対応

戦術観点活動レイア

情報モデル（概念構造とデータ構造に着目）

プロセスモデル（動的なフローに着目）

サービスモデル（内部のサービスに着目）cd cd cd cd ビジネスビジネスビジネスビジネス可視化可視化可視化可視化

活動活動活動活動

改善改善改善改善

新規新規新規新規


ビジネスビジネスビジネスビジネス

要求要求要求要求

情報情報情報情報

組織組織組織組織

ルールルールルールルール

フローフローフローフロー


アクターアクターアクターアクター

方法方法方法方法

結果

モデリング詳細説明

モデル・成果物説明１

№ ステークホルダー名実例内外区分居場所人数・規模責務・関心事主にグループを記述ステークホル

ダーの代表者内：企業内部外：顧客、取引先や外部パートナーなど

ステークホルダーの主な責務、つまりステークホルダーとしての関心事を列挙

1 販売部豆太郎様内部商品の販売、設備投資を管理し、販売店の効率的な営業展開を背後で支援する。

2 経理部内部販売店に関する収支を管理する。

3 営業部内部販売店と販売計画を締結し、販売店の売上を確保する。

4 クレジット部外部クレジット決済に纏わる業務を行う。

5 販売店外部保有する販売を経営する。

6 メンテナンス業者外部販売店を修繕（メンテナンス）する。

ビジネスステークホルダーリスト

最終更新者

最終更新日

文書番号

XXXXXXXXXX

----/--/--

00000000

承認者

承認日

バージョン

XXXXXXXXXX

----/--/--

1.00

ビジネスステークホルダーリストビジネスステークホルダーリストビジネスステークホルダーリストビジネスステークホルダーリスト

ビジネスステークホルダーリスト

• 概要概要概要概要– 問題領域となるビジネスの利害関係者の一覧

• 種別種別種別種別– リスト形式

• Openthologyデシプリン– 要求開発計画

• 効果効果効果効果– ビジネス可視化と改善として取り扱う範囲を利害関係者を通して明確に

する。– うっかり重要な利害関係者を忘れてしまうことがないようにする。

• 作成作成作成作成ポイントポイントポイントポイント– ビジネス課題に密接に関係するステークホルダーだけに絞り込みます。– あまり多くのステークホルダを抽出すると何をターゲットとするのか不明

確になる可能性があります。

ビジネスステークホルダー補足図ビジネスコンテキスト図

• 表記法

ビジネスアクタービジネスアクタービジネスアクタービジネスアクター

汎化関係汎化関係汎化関係汎化関係

関連関連関連関連(情報情報情報情報・・・・物物物物のののの流流流流れれれれ)

自社自社自社自社

自社

メーカー

会員一般

顧客配送する(商品)

請求

する

(金額

)

注文

する

(商品

、数量

)

発注

する

(注文

)

・自社ビジネスを取り巻くステークホルダー(利害関係者)との情報

や物のやり取りを明確にします。

モデル・成果物説明２

プロジェクトステークホルダーリストプロジェクトステークホルダーリストプロジェクトステークホルダーリストプロジェクトステークホルダーリスト

№ ステークホルダー名内外区分所属参画立場参画レベル責務・関心事懸念・心配事人・またはグループ内：企業内部

外：顧客、取引先や外部パートナーなど

プロジェクトに対して参画する立場

今回のプロジェクトに対する参画度：　メイン　サブ

ステークホルダーの主な責務、つまりステークホルダーとしての関心事を列挙

今回のプロジェクトに対して抱いている心配事や懸念される内容などのネガティブ面

1 田中豆男内部 ITセンター長要求開発プロジェクト責任者

オブザーバー要求開発計画に関する承認および、要求開発報告会の主催者として活動

6月中は出張のため参加できず、代替要員を検討中

2 鈴木豆子内部第二事業部開発グループリーダ

メイン開発グループとしてのプロトタイプ開発のスケジュール立案、および実施。ＩＴ側からの業務改善に関する提案。

3 佐々木豆三内部業務支援部業務グループリーダ

メイン業務グループのリーダとして成果物の取りまとめ、および作業時間の調整と作業指示。

繁忙期は週一回のミーティングに参加できないこともある。その場合代理を出す予

4 杉本豆太郎内部品質管理部標準化責任者メイン

業務改善と可視化された業務の標準化を推進する。

5 萩本順子内部第２業務部業務グループメイン

仕訳け業務の可視化および改善を担当する。

6 山岸歌麻呂内部第３業務部業務グループ

メイン在庫業務の可視化および改善を担当する。

7 依田大将外部要求開発コンサルサービス

　コントロールチーム・リーダ

メイン要求開発組織を技術面・ファシリテーション面で支援する。当面は、プロジェクトリーダとしてチームを率いる。

プロジェクトステークホルダーリスト

最終更新者

最終更新日

文書番号

XXXXXXXXXX

----/--/--

00000000

承認者

承認日

バージョン

XXXXXXXXXX

----/--/--

1.00

プロジェクトステークホルダーリスト

• 概要概要概要概要– プロジェクトミッションに関わる利害関係者の一覧

• 種別種別種別種別– リスト形式

• Openthologyデシプリンデシプリンデシプリンデシプリン

– 要求開発計画

• 効果効果効果効果– 要求開発プロジェクトとして達成すべきミッションにあわせて、重要人物を

どのような形で引き入れるか、メンバーとするか議論する。

– うっかり重要な利害関係者を忘れてしまわないようにする。

• 作成作成作成作成ポイントポイントポイントポイント– 品質管理部門などうっかり忘れがちになります。プロジェクト運営に重要な

人物とロールに着目しながら関係者からヒアリングを行ってください。

モデル・成果物説明３

ビジネスユースケースビジネスユースケースビジネスユースケースビジネスユースケース図図図図

• 表記法

ビジネスアクタービジネスアクタービジネスアクタービジネスアクター

顧客

商品を販売する

ビジネスビジネスビジネスビジネスユースケースユースケースユースケースユースケース

関連関連関連関連

エンティティエンティティエンティティエンティティサービス提供体の

範囲を表す

○○社

ビジネスビジネスビジネスビジネス課題課題課題課題：：：：外部（主に顧客）に提供しているサービスや、御社が内部で行っている目的を持った活動と、そのサービスに直接関係している・あるいは価値を受けている利害関係者を表します。

商品を仕入れる

メーカー

ビジネスユースケース図

• 概要概要概要概要

– ターゲットビジネスサービスとアクターの関係図

• 種別種別種別種別

– ＵＭＬ

– Openthologyのサービスモデル


– 現状分析と戦略設計

• 効果効果効果効果

– ビジネスとして、どのようなサービスをどのようなアクターに対して提供しているかの把握ができる。

– そもそもビジネスサービスのターゲットは誰なのかを明らかにし、合意を得る。

• 作成作成作成作成ポイントポイントポイントポイント

– 企業として外に向けて提供している主要なサービスを記述します。

– あまりにも多くのサービスを提供している場合は、今回ビジネスの可視化・改善およびシステム化計画が行われている箇所に絞込みましょう。

[ x > 0 ] [ else ]

モデル・成果物説明４（その１）

開始点開始点開始点開始点

条件分岐点条件分岐点条件分岐点条件分岐点

ガードガードガードガード条件条件条件条件条件を満たすときに

こちらへ分岐

マージマージマージマージ分岐の合流地点

ジョインジョインジョインジョイン複数の流れがすべて到達すると次へ進む

フォークフォークフォークフォーク複数の流れが並行に進む

アクティビティアクティビティアクティビティアクティビティ

終了点終了点終了点終了点

• 表記法

ビジネスフロー(UML)

アクティビティ名

・ビジネスユースケース単位に、その内部のビジネスプロセスをモデル化します。

オブジェクト名

オブジェクトオブジェクトオブジェクトオブジェクト

モデル・成果物説明４（その２）

• 表記上表記上表記上表記上のののの制約条件制約条件制約条件制約条件– AsIs,ToBe,Realizeモデルモデルモデルモデル共通共通共通共通

• アクティビティアクティビティアクティビティアクティビティ（（（（業務処理業務処理業務処理業務処理））））のののの単位単位単位単位がががが関係者間関係者間関係者間関係者間でででで認知認知認知認知されていることされていることされていることされていること

– AsIs,Realizeモデルモデルモデルモデル• システムシステムシステムシステムとのとのとのとの関係関係関係関係がががが明確明確明確明確になっていることになっていることになっていることになっていること

– システムレーンシステムレーンシステムレーンシステムレーンをををを設設設設けるかけるかけるかけるか、、、、アクティビティアクティビティアクティビティアクティビティでででで識別表現識別表現識別表現識別表現できるできるできるできる事事事事

• システムシステムシステムシステムのののの入出力入出力入出力入出力がががが明確明確明確明確であることであることであることであること– できるだけできるだけできるだけできるだけ業務担当業務担当業務担当業務担当にににに理解理解理解理解しやすいしやすいしやすいしやすいメタファメタファメタファメタファ（（（（帳票帳票帳票帳票・・・・画面画面画面画面））））をををを利用利用利用利用

– ToBeモデルモデルモデルモデル• 概念概念概念概念モデルモデルモデルモデルとのとのとのとの関係関係関係関係がががが明確明確明確明確になっていることになっていることになっていることになっていること

– ＴｏＢｅＴｏＢｅＴｏＢｅＴｏＢｅモデルモデルモデルモデルではではではでは、、、、画面画面画面画面・・・・帳票帳票帳票帳票などはなどはなどはなどは抽象化抽象化抽象化抽象化されたされたされたされた概念概念概念概念オブジェクトオブジェクトオブジェクトオブジェクトとしてとしてとしてとして表現表現表現表現されるされるされるされる

» 概念概念概念概念オブジェクトオブジェクトオブジェクトオブジェクトのののの妥当性妥当性妥当性妥当性ががががモデルモデルモデルモデル上上上上でででで検証検証検証検証できることできることできることできること

モデル・成果物説明４（その３）

発送する

商品在庫を確認する

注文を受け付ける

請求書を送付する

注文をクローズする

納品を確認する

支払いを確認する

経理経理経理経理営業営業営業営業在庫在庫在庫在庫センターセンターセンターセンター

Ｃ工程

Ａ工程

Ｂ工程


Ｚシステム

システムシステムシステムシステムレーンレーンレーンレーン


帳票帳票帳票帳票

入出力入出力入出力入出力

出力出力出力出力

例例例例

モデル・成果物説明４（その４）

注注注注））））細細細細かなかなかなかなルールルールルールルールははははモデリングガイドラインモデリングガイドラインモデリングガイドラインモデリングガイドラインをををを参考参考参考参考にしてくださいにしてくださいにしてくださいにしてください。。。。

応用例応用例応用例応用例

モデル・成果物説明４（その５）• 概要概要概要概要

– 現サービスを実現するビジネスオペレーションの姿をフロー化

– ビジネスユースケースひとつに対してひとつのフローが対応

• 種別種別種別種別

– ＵＭＬ

– Openthologyのプロセスモデル


– 現状分析と戦略設計

• 効果効果効果効果

– 業務担当にとって分かりやすい作業の流れ図を書くことで、現状または今後の業務がどうなっているのか、また、システムとの関係を明確にすることができる。

• 作成作成作成作成ポイントポイントポイントポイント

– レアーケースを取り上げすぎるとモデルが複雑になりすぎてしまいますので注意しましょう。

– アクティビティの単位について、できるだけ参加者全員で合意をとりましょう。

– 業務フローは他の業務を行っている人たちにも理解可能でなければなりません。

– アクティビティもいくつかの作業処理を集めた概念であることが多いでしょう。その場合は、必要であれば、アクティビティ１個に対してビジネスシナリオを書いてください。

– システムの関係するアクティビティは、システム側のユースケースと関係しています。つまり、システム関連アクティビティからシステムユースケースを抽出していくことでシステム要求へとつなげていきます。

モデル・成果物説明５

概念概念概念概念モデルモデルモデルモデル（ＵＭＬ（ＵＭＬ（ＵＭＬ（ＵＭＬクラスクラスクラスクラス図図図図））））cd Ecd Ecd Ecd E コマースコマースコマースコマース事業事業事業事業

顧客顧客顧客顧客

- 氏名: - 住所: - 電話番号:

会員会員会員会員

- ID: - パスワード: - 有効期間:

+ 認証する()

注文注文注文注文

- 注文年月日:

仕入先仕入先仕入先仕入先

- 名称:

商品商品商品商品タイトルタイトルタイトルタイトル

- 名称:

非会員顧客非会員顧客非会員顧客非会員顧客

仕入先仕入先仕入先仕入先・・・・商品商品商品商品タイタイタイタイトルトルトルトル関係関係関係関係

- 販売期間: - 販売単価:

購入商品購入商品購入商品購入商品タイトルタイトルタイトルタイトル

- 注文時販売単価: - 注文量: - 消費税: - 販売金額: - 送料:

注文注文注文注文ルールルールルールルール

決済方法決済方法決済方法決済方法

+ 認証する()

決済方法決済方法決済方法決済方法＝＝＝＝現金現金現金現金決済方法決済方法決済方法決済方法＝＝＝＝カードカードカードカード

カードカードカードカード会社会社会社会社

+ 認証する()

値引値引値引値引ききききルールルールルールルール送料計算送料計算送料計算送料計算ルールルールルールルール

ポイントポイントポイントポイント

- 現ポイント数:

+ 金額換算()

ポイントポイントポイントポイント加算加算加算加算

- ポイント加算年月日: - 加算ポイント:

決済方法決済方法決済方法決済方法－－－－個別個別個別個別

- 金額:

+ 認証する()

決済方法決済方法決済方法決済方法－－－－ポイントポイントポイントポイント利利利利用用用用

- ポイント利用年月日: - 利用ポイント数:

+ 金額換算()

注文注文注文注文ルールルールルールルール型型型型商品分類商品分類商品分類商品分類

- 名称:

1

*

1

*

1

1

*

1

*

1

1

0..1

1

*

注文ルール型

*

1

注文ルール型*1

1

*

1

*

1

1

*1

1

<<powertype>>

*

*

*

*

*

・ビジネス実行者がビジネスを実行する上で頭や心に描いている概念（言葉と言い換えても結構です）を表します。概念間の関係も同時に表します。

情報構造モデル（クラス図）概念モデルはLevel1

•• 33段階段階段階段階にににに抽象度抽象度抽象度抽象度をををを分類分類分類分類段階段階段階段階にににに抽象度抽象度抽象度抽象度をををを分類分類分類分類– なぜなぜなぜなぜ

• ユーザナレッジユーザナレッジユーザナレッジユーザナレッジをををを無理無理無理無理なくなくなくなく吸収吸収吸収吸収できるできるできるできる• コンセプチャルレベルコンセプチャルレベルコンセプチャルレベルコンセプチャルレベルをををを持持持持つことでつことでつことでつことで、、、、概念構造概念構造概念構造概念構造をををを分分分分かりやすいかりやすいかりやすいかりやすいレベルレベルレベルレベルでででで視覚化視覚化視覚化視覚化・・・・合意合意合意合意できるできるできるできる

– Level１１１１• レベル…コンセプチャル• 用途 …現状分析モデル• 説明

– 汎化、関連、集約などの関係を使って用語語彙の関係意味構造を表したもの。

– Level２２２２• レベル…仕様• 用途 …現状分析モデル、戦略分析モデル、システム分析モデル• 説明

– クラスの責務を表現するために必要とされるキーや主な属性を割り付ける。また、責務を表す操作も微量ながら割り付ける。

– Level3• レベル…実現• 用途 …システム設計モデル• 説明

– データモデル» データベースの論理設計につなげるため、主キー、副キーの明確化、すべての属性の洗い出しを行う。

– 設計モデル» 属性と操作について、実装アーキテクチャを意識した構造として割り付ける。また、実装アーキテクチャを意識した最適なクラス

構造に変更する。

ビジネスビジネスビジネスビジネスコンセプチャルコンセプチャルコンセプチャルコンセプチャル

ビジネスビジネスビジネスビジネス仕様仕様仕様仕様

ソフトウェアソフトウェアソフトウェアソフトウェア実現実現実現実現

ビジネスビジネスビジネスビジネス担当者担当者担当者担当者

ビジネスオーナビジネスオーナビジネスオーナビジネスオーナ・・・・管理者管理者管理者管理者

設計者設計者設計者設計者

実装者実装者実装者実装者

概念モデルは、データモデルとオブジェクトモデルで共有します

要求開発要求開発要求開発要求開発プロセスプロセスプロセスプロセス

cd Ecd Ecd Ecd E コマースコマースコマースコマース事業事業事業事業





+ 認証する()


- 注文年月日:


- 名称:


- 名称:








+ 認証する()



+ 認証する()




+ 金額換算()




- 金額:

+ 認証する()



+ 金額換算()


- 名称:

1

*

1

*

1

1

*

1

*

1

1

0..1

1

*

注文ルール型

*

1


1

*

1

*

1

1

*1

1

<<powertype>>

*

*

*

*

*

概念モデル

Level1（コンセプチャルレベル）

オブジェクトモデル

データモデル






+ 認証する()


- 注文年月日:


- 名称:


- 名称:








+ 認証する()



+ 認証する()




+ 金額換算()




- 金額:

+ 認証する()



+ 金額換算()


- 名称:

1

*

1

*

1

1

*

1

*

1

1

0..1

1

*

注文ルール型

*

1


1

*

1

*

1

1

*1

1

<<powertype>>

*

*

*

*

*

分析モデルLevel2（仕様レベル）

cd cd cd cd データモデルデータモデルデータモデルデータモデル

Tab le1Tab le1Tab le1Tab le1 Ta ble2Ta ble2Ta ble2Ta ble2

Ta ble3Ta ble3Ta ble3Ta ble3


Table 5Table 5Table 5Table 5


データモデル（企業レベル）

cd cd cd cd データモデルデータモデルデータモデルデータモデル

Tab le1Tab le1Tab le1Tab le1 Ta ble2Ta ble2Ta ble2Ta ble2



Table 5Table 5Table 5Table 5


データモデル（アプリケーションレベル）






+ 認証する()


- 注文年月日:


- 名称:


- 名称:








+ 認証する()



+ 認証する()




+ 金額換算()




- 金額:

+ 認証する()



+ 金額換算()


- 名称:

1

*

1

*

1

1

*

1

*

1

1

0..1

1

*

注文ルール型

*

1


1

*

1

*

1

1

*1

1

<<powertype>>

*

*

*

*

*

設計モデルLevel3（実装レベル）

目的目的目的目的：：：：企業企業企業企業レベルレベルレベルレベルででででデータモデルデータモデルデータモデルデータモデルをををを構築構築構築構築目的目的目的目的：：：：アプリケーションレベルアプリケーションレベルアプリケーションレベルアプリケーションレベルででででデータモデルデータモデルデータモデルデータモデルをををを構築構築構築構築

システム開発プロセス

システム開発プロセス

業務概念の整理

• アクティビティ図

– 業務処理をフロー（モデル）化したもの

– アクティビティ図は、業務処理の変更に影響されやすい。業務処理が変わっても変化しにくいものをとらえると、より業務を理解しやすくなります。

• 業務概念

– 業務に存在する普遍的な「概念」のこと

– 業務概念の例

• 部門、販売、顧客、商品

業務概念＝オブジェクト

• 業務概念とはオブジェクトの事

• オブジェクトの見つけ方

– 名詞や名詞句、動詞に着目する• 目に見える概念

– 病院、報告書、顧客

• 目に見えない概念

– セクション、グループ、測定原理

概念モデル基礎（クラス）

• クラス図とは– 静的な構造をクラスおよびクラス間の関係で表した

図

– クラスやそのクラスのインスタンスが持つことのできる情報、およびクラス間の関係を表す図のこと

概念の候補

• モノモノモノモノ（「（「（「（「物物物物」」」」・・・・「「「「者者者者」）」）」）」）– 物物物物：：：：物理的物理的物理的物理的・・・・有形的有形的有形的有形的なななな対象物対象物対象物対象物対象物対象物対象物対象物

– 者者者者：：：：人人人人のののの演演演演じるじるじるじる役割役割役割役割役割役割役割役割（（（（ロールロールロールロール），），），），組織組織組織組織（（（（組織組織組織組織（（（（機能機能機能機能やややや単位単位単位単位））））

– よそよそよそよそモノモノモノモノ：：：：外部外部外部外部システムシステムシステムシステム外部外部外部外部システムシステムシステムシステム

• コトコトコトコト（「（「（「（「事事事事」」」」象象象象・・・・「「「「事事事事」」」」実実実実））））– 事象事象事象事象（（（（事件事件事件事件））））

•• ビジネスビジネスビジネスビジネスビジネスビジネスビジネスビジネスのののの重要重要重要重要ななななのののの重要重要重要重要ななななイベントイベントイベントイベントイベントイベントイベントイベント（（（（事象事象事象事象））））ややややトランザクショントランザクショントランザクショントランザクショントランザクショントランザクショントランザクショントランザクション（（（（取引取引取引取引），），），），それらのそれらのそれらのそれらの明細明細明細明細

– 事実事実事実事実• モノモノモノモノややややコトコトコトコトをををを記述記述記述記述したしたしたした仕様仕様仕様仕様，，，，仕様仕様仕様仕様，，，，ビジネスビジネスビジネスビジネスプロセスプロセスプロセスプロセスプロセスプロセスプロセスプロセスややややビジネスビジネスビジネスビジネスルールルールルールルールルールルールルールルール

• ババババ（（（（モノモノモノモノややややコトコトコトコトがががが生起生起生起生起するするするする場場場場・・・・所所所所））））– ミクロミクロミクロミクロなななな場場場場：：：：モノモノモノモノややややコトコトコトコト（（（（内容物内容物内容物内容物））））にににに対対対対するするするする「「「「容容容容れれれれ物物物物（（（（コンテナコンテナコンテナコンテナ））））容容容容れれれれ物物物物（（（（コンテナコンテナコンテナコンテナ））））」」」」

– マクロマクロマクロマクロなななな場場場場：：：：モノモノモノモノややややコトコトコトコトのののの生起生起生起生起するするするする「「「「場所場所場所場所（（（（コンテキストコンテキストコンテキストコンテキスト））））場所場所場所場所（（（（コンテキストコンテキストコンテキストコンテキスト））））」」」」

◎

○

△

抽出優先度

抽出優先度

抽出優先度

抽出優先度

クラス[class] (1)

• 同種の複数のオブジェクト(インスタンス)をとり

まとめたもの

– オブジェクトを実体すると、実体を表す概念がクラス

• UMLでは…

– 四角形で表し、枠内にクラス名を記述する

• オブジェクトと異なり名前の下には下線を引かない

社員社員B

社員A

社員C

A、B、Cの

いずれも「社員」である

クラス名

クラス

クラス(2)

• 属性[attribute]と操作[operation]の表記

– 四角形を3つに区分けし、属性、操作を記述する

• クラス名欄の下が属性欄、その下が操作欄となる

• 属性欄や操作欄は省略可能

クラス名

属性名

操作名()

社員

社員

名前性別

仕事をする()

休憩する(時間)

社員

名前性別

全部同じ社員クラスを表す

属性、操作欄を省略した表記

操作欄を省略した表記省略なしの表記

関連[association] (1)

• クラス間の関係の一種

– 関連端のクラスともう一方の関連端のクラスの間に関係があることを示す

• UMLでは…

– クラス間を結ぶ実線で表すクラスA クラスB

部署Ｘ社員A

オブジェクト図

部署社員

クラス図

部署Ｙ社員Ｂ

社員Ｃ

パターン1

パターン2

関連(2)

• 関連名

– クラス間の意味的な関係を示す

– 読む方向を明示するために三角形を表記する（省略可）

• ロール名[role]

– 関連先のクラスが、自クラスから見て、どのような役割や立場であるかを示す

クラスA クラスB

部署社員

関連名

所属する

部署社員部員所属部署

クラスA クラスBクラスＢのロール名クラスＡのロール名

関連(3)

• 多重度[multipｌicity]– 自クラスのある1つのインスタンスから見たときに「関連先の

クラスのインスタンスがいくつ存在し得るか」を示す

クラスA クラスB0..*0..1

0..* 0以上※

1..* 1以上n以上(上限なし)n..*

離散値指定

一定値指定

範囲指定

1,3,5 1か3か5mかnかom,n,o

1 常に1厳密にnn

0..1 0か11..10 1以上10以下5..50 5以上50以下

m以上、n以下m..n

具体例意味表記

※ 0以上を表す0..* は、単に * と書くことも可能。

関連(4)

– 多重度の記述例

社員部員

1..*部署

所属部署

1

ある部署は1名以上の社員から構成される(最低1名いないと部署として成り立たない)。

パターンパターンパターンパターン1

パターンパターンパターンパターン2

ある社員は必ず1つの部署に

属し、かつ、複数の部署に所属することはできない

社員部員

0..*部署

所属部署

0..3

ある部署は0名以上の社員から構成される(社員がいない部署(名義上の部署)も存在する)。

ある社員は最高3つの部署に属す(兼務する)ことができ、

部署に属さないこともできる。

概念モデル

• 概要概要概要概要– ビジネスにおける重要概念の関係を完結に示す

• 種別種別種別種別– ＵＭＬ– Openthologyの情報構造モデル

• Openthologyデシプリンデシプリンデシプリンデシプリン– 現状分析と戦略設計

• 効果効果効果効果– 業務の流れに依存しない業務概念が理解でき、概念同士の関係によって、業務フローと

は異なる観点で業務概念構造を理解することができる。– 業務の普遍的概念整理と、参加者全員で業務構造を合意できる。– 業務概念をクラス（語彙）として整理することで、他のモデルで使用している語彙要素が

整理でき、結果として分かり易く理解可能なモデルを形成できる。

• 作成作成作成作成ポイントポイントポイントポイント– あまり時間をかけすぎても効果はありません。– まずは概念モデルの教育を行うことが重要です。– 概念モデルにより最初からビジネスの全体像を描こうとは思わず、参加者の関心の高い

物事から概念モデルにて整理して、参加者全員の合意を得ていくようにしましょう。

概念モデル

• 作成ポイント– 「もの」、「事」、「場」の事に着目しすぎるとモデル

自体に曖昧さが生じます。• なぜ？

– 事は動詞的なクラスとなる。動詞的なクラスはもの（名詞的）なクラスを利用する。本来の名詞同士が持つ普遍的な関連が、動詞的なクラスによって隠されてしまうことがあります。

• 対処法– 動詞的なクラスについては、業務にとって最も重要なものだけ

に絞り込みましょう。

» 動詞クラスはステレオタイプで識別する

» 動詞は関連名で表す

» 動詞はクラスの操作として表す

概念モデル

• 今後の検討課題概念を識別する• ステレオタイプで明記（例）

– 「もの」、「事」、「場」の区別– リソース（マスタ）とイベント（トランザクション）の区別

» ただし、この分類はかなりＤＢ思考になるような…（ＰＬＡＮＤＢ）

» リソースは「もの」、イベントは「事」の記録と考えるとよい

– クラス配置の意味付けを行う（原則として）• 汎化関係

– スーパークラスは上、サブクラスは下

• 集約関係– 全体は左、部分は右

• これらは、Openthologyとしてどうするか検討中のものです。みなさんも是非一緒に考えてください。

モデル化そもそも論

システム開発におけるＶ字モデル

システム要件

サブシステム要件

コンポーネント要件

モジュール要件単体テスト

コンポーネントテスト

サブシステムテスト

受け入れテスト

評価

評価

評価

評価

要求開発の目指す変形Ｖ字モデル

システム要件

サブシステム要件

コンポーネント要件

モジュール要件単体テスト

コンポーネントテスト

サブシステムテスト

受け入れテスト

ビジネス要求ビジネステスト

要求開発

システム開発

ValidationVerification

結果イメージの予測

変形Ｖ字モデルの重要性

• ビジネス要求段階の評価とは？– ビジネス要求の一環としてのシステムの姿を早期に見せる事

• 必要性– 運用イメージの欠如

• ユーザ要求の抽出において、システムを利用する際の運用イメージを描かず、こんなものがあれば嬉しいというレベルで要求を決めていることが多く、実際に作ってみると、使おうとしない。

– 洗練された要求の獲得• 具体的なイメージを見せることで新たな要件の獲得が出来やすくなる。

• 方法– 現在のところは、システムプロトタイプと業務フローモデル、概念モデル

にて、要求開発組織メンバーの中で合意を得る。

変形Ｖ字モデルの課題

• システム開発課題– 反復における各テストの実施プロセスの明確な定義方法

• 要求開発課題– 要求開発プロダクトにおいて、ビジネスの視点で評価を行う

ための支援ツールは不整備

– 業務担当とシステム担当に潜む、暗黙的要求の掘り起こし方

– 品質を保ちつつ、要求抽出を程よく延滞させ、洗練された要求を抽出させるためのプロジェクト管理。

– テスト工程の管理方法

次回予告

次回予告

• 業務改善におけるモデリング

– トップダウンビジネス分析

– ボトムアップビジネス分析

• 今後のチュートリアル提案

– 概念モデルと業務フローをもう少し親切に説明

– 実践概念モデリング

Documents

要求開発アライアンス · 他の技術・技沵との違い（その1） • EA （（（（（エンタープライズアーキテクチャエンタープライズアーキテクチャエンタープライズアーキテクチャエンタープライズアーキテクチャ）