モデリングの神髄

モデリングの神髄
～ビジネス戦略モデル、要求モデル、アーキテクチャモデルの
関係性とその本質的有効性を理解する～

萩本順三

Copyright (C) 2012 Takumi Business Place Corporation All Rights Reserved
www.takumi-businessplace.co.jp

モデリングって難しい？

新人の頃、モデルとはモデリングって、とても難しく専門的
なものだと思っていた。

でも…

単に、複数人の相手に文字ではなく、言葉でもない、人に分か
りやすいイメージを伝える事がモデリングの本質だというこ
とが分かってきた。


僕のモデリングへの取り組み

• Step1
– 構造化手法（機能の階層化、機能の概念化）
ＣＯＢＯＬで活用
カッコエ～。でもかなり概念的。

– データモデル（正規化理論）

なるほど納得！
（知識的にはファイル設計を応用）

•Step2
– オブジェクト指向設計モデル（オブジェクト指向プログラミングからの延長）
クラス図（静的モデル）
凄い！プログラムイメージをそのまま表現できる！
（クラス図は、正規化理論の知識を応用）

オブジェクト図（動的モデル）


• Step３
– 分析モデルをとことん疑う
当初：概念的でよ～わからん。
概念モデル
しかも、実世界をコンピュータの疑似世界
に持ち込んでどうするんだ？

•Step4
– 分析モデルの真の必要性が少し理解できるようになる

概念モデル
そもそもビジネス用語の概念が整理されていない事が
問題。コンピュータに持ち込む前に整理すべきであり、
整理後、コンピュータの設計に繋げるべき。



• Step５
– 要求モデル

概念モデル
（課題）
それをオブジェクト指向でどう取り扱うのか？

•Step６
– 要求モデル（ユースケースの登場）

概念モデル要求をオブジェクトとは異なる概念
ユースケースとして整理するやり方
に納得。でも世の中的には、ユース
ケースをクラス設計に繋げる方法に
ずいぶん混乱したような…
ユースケースモデル


（自分の中で）決めた事

悩み中決めた後
理解のモデル
（責務）
分析モデル・分かり易い事

理解と実現の為のモデ
設計モデルル
（責務）
・分かり易い事
・実装責任を負う

分析結果が設計に繋がらない繋がらなくともよしとする
だからこそ分析モデルはシンプル
スピィーディに作成すべき。


（世の中はどうあろうが自分の中で）変えた事

プロセスモデル情報モデル
（業務フロー）（概念モデル）

要求定義
（ユースケース）

ソフトウェア対象
分析モデル
（概念モデル）要求定義
（ロバストネス分析）（ユースケース）

設計モデル
設計モデル

ソフトウェア設計に入ってからの分析概念モデルは、ビジネス（業務）レベルで記述
モデルに価値を感じられないすべき。また、要求の根拠には業務モデルが
ロバストネスなどは教育的には論理的あるべき。要件定義の前のフェーズが必要。
だが、詳しくは（そもそもこういう考えは以前から存在して
「論理的美の虚像」で検索！いたけれど、2000年頃には陳腐化していた）


２００４年要求開発のベースモデルが誕生

戦略ビュー
ビジネスのサービスを定義する（戦略マップ）
際にはビジネス戦略の定義が必
要であるはず。

サービスビュー
（ビジネスユースケース）

業務プロセスも業務概念も、
HOWである。そのWhatとしてのサー
ビスの定義が必要だろう！
（サービス指向に強く影響を受けた）

プロセスビュー情報ビュー
（業務フロー）（概念モデル）


要求開発のモデル・ストラクチ
ャ図
ビジネス戦略
ビ戦略ビュー
ジビジネス戦略
ネ
スプロジェクト戦略

ビジネス要求
ビジネス・プロセスオブジェクト
モデル

Ｉ
Ｔアプリケーションシステム要求データ
シ・プロセスモデル
ス
テ
ムアプリケーション
フレームワーク
実装アーキテクチャ


ビュー別の代表的なモデル図
●BSC戦略マップ
システム ●要求分析ツリー
ユースケース記述
ユースケースモデルゴール記述
●ビジネス
●ステークホルダ
●業務フローユースケースモデル
●ビジネス概念モデル
戦略ビュービジネス戦略
分析・設計モデル
プロジェクト戦略
クラス図

ビジネス DB
モデル
ビ
ジ
ネオブジェクト
ビジネス・プロセスビジネス要求
スモデル

I システム要求データ
T アプリケーション・プロセス
モデル
シ
ス
テ
ムアプリケーション
フレームワーク

実装アーキテクチャ


要求開発＋システム開発のビユー
• 要求開発は、４つのビューをビジネスからシステムに繋ぐために、下記
のように７つのビューで表現されます。これによりビジネスからシステ
ムへのモデル上のトレーサビリティ（追跡可能性）が確保されます。

戦略ビュー

目的
ビ
ジ
ネ手段

スサービスビュー
目的目的

手段手段
目的目的

手段
シ
ス目的目的
テ
ム
手段手段


要求開発４象限
戦略・要求オペレーション

ビビジネスビジネス
ジ
ネ戦略オペレーション
ス What
表（価値） How 裏（実現）
What 表（価値）

裏（実現）
How
シ
ス What
表（価値） How裏（実現）
テ
ムシステム要求システム設計


僕の中でのモデリング手法発展の歴
史
描く力

価値

戦略

業務

機能

構造

作る力
オブジェクト指向要求開発匠メソッド
方法論Drop 1997 方法論2005 方法論2009


新時代のプロセス

分ける
（作業の見える化）要求開発段階システム開発段階

繋げる
（プロセ
ス）要求開発段階システム開発段階

並行で走らせる
（チームセル）
・Howの手探り
・Howからの突き上げ


要求開発を開発する中での悩み（その１）

そもそもシステム要求とは何か？

ＡさんがＢさんに要求を出す。

こんな単純な構造なのだろうか？


要求は、あるものではなく、開発するものである
。
要求開発に必要な事は、３つの視点のコタツ形
成。
これは、チームの役割だけを示すものではない。
参加者全員が３つの視点を持つ事。
戦略的将来の価値を
視点取りに行く傾向

業務部門に戦略的視野
を身につけさせる。

IT活用のビジネスにとって
価値のある
業務問題現在の価値を
取りに行く傾向
視点要求・要件解決の視点
戦略部門に現場の問題
課題を理解させる。

これによって、要求（戦略・業務・ＩＴ）を広い視野で考え、
取捨選択したり、創造するための基礎スキルが形成される。

要求開発を開発する中での悩み（その２）

そもそも要求と、業務モデルやソフトウェアモデル
との関係

たとえば、業務フローを書いたからといって業務要
求が整理されるわけではない。

ましてや、システム要求が定義されるわけではな
い。


要求は現状を変える際の変化から生まれる

戦略的視点
（将来の価値）プロセスビュー情報ビュー
現在（業務フロー）（概念モデル）
AsIs
トップダウン
ビジネス戦略から
見て業務ITをどう
変えるべきか？
・業務要求
・システム要求
問題解決的視点
（現在の価値）

ボトムアップ現在の業務改善か
新規プロセスビュー情報ビュー
ら見て業務ITをど ToBe （業務フロー）（概念モデル）
う変えるべきか？

つまりは、AsIs,ToBeの業務モデルと要求モデルは関係付けて定義すべき！


要求開発を開発する中での悩み（その３）

そもそもシステム要求定義のやり方には

業務要件から見た要求という観点が薄く点の要求

を細かくしているだけではないか。

だとすると無意味な作業に時間を費やしている。

結論：要求定義の根本を変える必要がある！


要求定義の根本的改善１
上位要求への階層的表現
ビジョン

上位What-Why
戦略要求

ここから
下はリアル
な要求イメージ
業務要求表現だけにする

IT基本要求

システム
要求

点の要求

要求定義の根本的改善２
面の要求（業務変更、新業務からの要求）

面の要求
業務変更

業務要求

IT基本要求

システム
要求


要求開発を開発する中での悩み（その４）

世の中はビジネスの方向へどんどん突き進んでいる。

その過程で、手段的なＨowよりも、価値、何を行うか
というWhat,Whyが必要とされている。

しかし、そのような観点でのＩＴアーキテクチャモデ
ルはまだ確立できていない。

ビジネス価値、戦略、業務に繋げてアーキテクチャ―
をモデルとして表現するための手法とモデル表現がこ
れから必要とされている。

現在会社として進めている事

ビジネス価値と戦略と業務とＩＴをシームレスに
繋げるためのモデルと手法を確立する事。

ビジネス企画の中で、ＩＴ活用法までイメージする
ための手法。＝＞匠Method for Service

製品企画というテーマで、プロダクト（複数製品）
の価値や戦略およびターゲットとする製品の企画
を行う方法＝＞匠Method for Product


匠Method for Serviceモデル体系
◆ビジネスユースケース図
◆システムユースケース図
◆SWOT分析シート ◆匠BSC戦略マップ
○○システム

○○社
商品一覧参照する

組織在庫の確認を粉う
在庫担当

ビュー
顧
客

商品を購入する

売上集計を粉う

会計担当

◆ステークホルダ分析 ◆ステークホルダ価値関連図
◆ビジネスコンテキスト図 ◆概念モデル
◆業務モデル（AsIs,ToBe）

ドメイン
ビュー

◆要求分析ツリー ◆プロジェクトゴール記述書◆プロジェクト初期プラン ◆プロジェクトシート

プロジェ
クトビュー


匠Method for Service全体体系（モデル・ビュー）

ドメイン(問題領域)
組織ビュープロジェクトビュー
ビュー
●ＳＷＯＴ分析シート ●ステークホルダ分析 ●プロジェクトシート
●匠ＢＳＣ戦略マップ ●ビジネスコンテキスト図ープロジェクトビジョン
ープロジェクトミッション
価値の
モデル ●要求分析ツリー
●プロジェクトゴール記述
●ステークホルダ価値関連モデル ●プロジェクト初期プラン

●業務モデル（As-Is）
業務 ●業務モデル(To-Be)
モデル ●概念モデル

●ビジネスユースケース図
機能 ●システムユースケース図
モデル


匠Method for Product 全体体系（モデル・ビュー
）
ユーザビュープロダクトビュープロジェクトビュー
◆ビジネスコンテキスト図 ◆プロダクトビジョン ◆プロジェクトシート
◆ユーザコンセンサスモデル ◆プロダクトコンセプト -プロジェクトビジョン
◆プロダクト戦略 -プロジェクトミッション
◆プロダクトロードマップ -プロジェクト初期プラン
◆プロジェクトゴール記述書
価値の ◆要求分析ツリー
モデル ◆想い図
◆プロダクトバリューシミュレーション
-ポートフォーリオマルチビュー
-パンフレットイメージ
-プロトタイプシナリオ
-ユーザライフスタイルデザイン
◆ステークホルダ分析 ◆プロダクトステークホルダ
◆ユーザビジネスモデル分析
業務
-プロセスモデル ◆業務モデル
モデル
-情報モデル ◆組織モデル
◆製品体系図

機能 ◆機能体系図
モデル ◆問題・課題分析

構造 ◆アーキテクチャモデル
モデル


狙っている事
エンジニアが
• ビジネス企画の早い段階からチャレンジ！
– ＩＴ側からのイノベーションを起こす仕組み
– フィジビリティ検証等、リスクマネジメントを行う仕組
み
協業による匠メソッドサービス新たなIT企業としてのイメージ確立ビジネス視点のNewソリュー
の社外展開それに基づく企業戦略の見える化ションの確立

ビジネスメソッドの展開企業戦略の開発ビジネス視点による
新ソリューションの確立
製品企画 BPMソリューション
匠Method for Product 匠Method for BPM
事業戦略・部門戦略
策定・見える化支援
ビジネス企画 BRMソリューション
匠Method for Service 匠Method for BRM
企業イメージ・ブランド
外に向けた要求開発確立支援
ERPソリューション
価値向上匠Method 要求開発匠Method for ERP

Ｗｅｂ企画メソッド
匠Method for Web

クラウドビジネスメ
要求開発ソッド


ご清聴ありがとうございました

hagimoto@takumi-businessplace.co.jp


匠には誰もがなれるわけではない
匠を目指そうとするものだけに、その権利は与えられる


モデリングの神髄

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (11)

Semelhante a モデリングの神髄

Semelhante a モデリングの神髄 (20)

Mais de bpstudy

Mais de bpstudy (17)

Último

Último (9)

モデリングの神髄