モデリングの神髄

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

モデリングの神髄～ビジネス戦略モデル、要求モデル、アーキテクチャモデルの

関係性とその本質的有効性を理解する～

萩本順三


モデリングって難しい？

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

でも…

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

　　


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

• Step1– 構造化手法（機能の階層化、機能の概念化）

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

• Step2– オブジェクト指向設計モデル（オブジェクト指向プログラミングからの延長）

　　クラス図（静的モデル）

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

ＣＯＢＯＬで活用カッコエ～。でもかなり概念的。

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

凄い！プログラムイメージをそのまま表現できる！（クラス図は、正規化理論の知識を応用）



• Step３– 分析モデルをとことん疑う

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

　　

当初：概念的でよ～わからん。しかも、実世界をコンピュータの疑似世界に持ち込んでどうするんだ？

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

概念モデル

概念モデル



• Step５– 要求モデル

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

　　

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

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

ユースケースモデル

概念モデル


（自分の中で）決めた事

分析モデル

設計モデル

悩み中

分析結果が設計に繋がらない

決めた後

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

理解のモデル（責務）・分かり易い事

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


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

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

ソフトウェア対象分析モデル（概念モデル）（ロバストネス分析）

設計モデル

ソフトウェア設計に入ってからの分析モデルに価値を感じられないロバストネスなどは教育的には論理的だが、詳しくは「論理的美の虚像」で検索！

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

情報モデル（概念モデル）

設計モデル

プロセスモデル（業務フロー）

概念モデルは、ビジネス（業務）レベルで記述すべき。また、要求の根拠には業務モデルがあるべき。要件定義の前のフェーズが必要。（そもそもこういう考えは以前から存在して　いたけれど、 2000 年頃には陳腐化していた）


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

情報ビュー（概念モデル）

プロセスビュー（業務フロー）

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

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

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

戦略ビュー（戦略マップ）


要求開発のモデル・ストラクチャ図

ビジネス戦略

ビジネス・プロセス

　　　　　　　　　　　　

ビジネス要求

システム要求

アプリケーション

フレームワーク

実装アーキテクチャ

プロセス　ビューサービス　ビュー

情報　ビュー

　　戦略ビュー

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

データモデル

オブジェクトモデル

ビジネス

ＩＴシステム

ビジネス戦略

プロジェクト戦略


ビュー別の代表的なモデル図

戦略ビュー

プロジェクト戦略

データモデル

オブジェクトモデル

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

ビジネス・プロセス

　　　　　　　　　　　　

ビジネス要求

システム要求

ビジネス

アプリケーション

フレームワーク

実装アーキテクチャ

ビジネス

ITシステム

プロセスビューサービスビュー

情報ビュー

●ビジネス　ユースケースモデル●業務フロー

システムユースケースモデルユースケース記述

　●ビジネス概念モデル

　 DB　　モデル

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

●BSC戦略マップ

ビジネス戦略

●要求分析ツリー　　ゴール記述 ●ステークホルダ


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

戦略ビュー　

サービス　ビュー　

プロセス　ビュー　情報　ビュー　

目的　

目的　

手段目的

目的　

手段　

サービス　ビュー　

プロセス　ビュー　情報　ビュー　

目的　

手段

目的　

手段

手段　

システム

ビジネス

手段目的


ビジネス戦略

ビジネスオペレーション

戦略・要求オペレーション

ビジネス

表（価値）　裏（実現）

システム要求システム

表（価値）　

裏（実現）

システム設計表（価値）裏（実現）

What How

What

How

What How

要求開発４象限


価値

戦略

業務

機能

構造

描く力

作る力オブジェクト指向方法論Drop 1997

　　要求開発　方法論 2005

匠メソッド　方法論 2009

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


新時代のプロセス

要求開発段階システム開発段階

分ける（作業の見える化）

要求開発段階システム開発段階

繋げる（プロセス）

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

14


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

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

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

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


要求は、あるものではなく、開発するものである。

戦略的視点

IT活用の視点

業務問題解決の視点

ビジネスにとって価値のある

要求・要件

要求開発に必要な事は、３つの視点のコタツ形成。これは、チームの役割だけを示すものではない。参加者全員が３つの視点を持つ事。

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

将来の価値を取りに行く傾向

現在の価値を取りに行く傾向

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

戦略部門に現場の問題課題を理解させる。


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

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

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

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


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





戦略的視点（将来の価値）

ビジネス戦略から見て業務 ITをどう変えるべきか？

問題解決的視点（現在の価値）

現在の業務改善から見て業務 ITをどう変えるべきか？

トップダウン

ボトムアップ

現在AsIs

新規ToBe

・業務要求・システム要求

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


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

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

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

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

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

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


点の要求

要求定義の根本的改善１

ビジョン

戦略要求

業務要求

IT 基本要求

システム要求

上位要求への階層的表現

上位 What-Why

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


面の要求

要求定義の根本的改善２

業務要求

IT 基本要求

システム要求

面の要求（業務変更、新業務からの要求）

業務変更


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

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

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

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

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


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

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

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

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


匠 Method for Serviceモデル体系◆SWOT分析シート ◆ 匠 BSC戦略マップ

◆ステークホルダ分析 ◆ステークホルダ価値関連図

◆プロジェクトシート

◆業務モデル（ AsIs,ToBe）

組織ビュー

ドメインビュー

プロジェクトビュー

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

顧客

商品一覧参照する

○○システム

　　　商品を購入する

会計担当

　　在庫の確認を粉う

在庫担当

　　売上集計を粉う

○○社

◆ビジネスユースケース図◆システムユースケース図

◆ビジネスコンテキスト図 ◆概念モデル


組織ビュードメイン (問題領域 )ビュープロジェクトビュー

価値のモデル

● ＳＷＯＴ分析シート● 匠ＢＳＣ戦略マップ

●ステークホルダ分析●ビジネスコンテキスト図

●プロジェクトシート　ープロジェクトビジョン　ープロジェクトミッション

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

業務モデル

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

機能モデル

●ビジネスユースケース図●システムユースケース図

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

●ステークホルダ価値関連モデル


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

ユーザビュープロダクトビュープロジェクトビュー

価値のモデル

◆ビジネスコンテキスト図◆ユーザコンセンサスモデル

◆プロダクトビジョン◆プロダクトコンセプト◆プロダクト戦略◆プロダクトロードマップ

◆プロジェクトシート　 -プロジェクトビジョン　 -プロジェクトミッション　 -プロジェクト初期プラン◆プロジェクトゴール記述書◆要求分析ツリー◆ 想い図

◆プロダクトバリューシミュレーション　 - ポートフォーリオマルチビュー　 - パンフレットイメージ　 -プロトタイプシナリオ　 -ユーザライフスタイルデザイン

業務モデル

◆ステークホルダ分析◆ユーザビジネスモデル　 -プロセスモデル　 -情報モデル

◆プロダクトステークホルダ分析◆業務モデル◆組織モデル◆ 製品体系図

機能モデル

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

構造モデル

◆アーキテクチャモデル


狙っている事• ビジネス企画の早い段階から

– ＩＴ側からのイノベーションを起こす仕組み– フィジビリティ検証等、リスクマネジメントを行う仕組み

要求開発

製品企画匠 Method for

Productビジネス企画匠 Method for

Service

ビジネスメソッドの展開企業戦略の開発

事業戦略・部門戦略策定・見える化支援

ビジネス視点による新ソリューションの確立

要求開発匠 Method 要求開発

BRMソリューション

匠 Method for BRM

BPMソリューション匠 Method for BPM

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

ERPソリューション匠 Method for ERP

企業イメージ・ブランド確立支援外に向けた

価値向上

ビジネス視点のNewソリューションの確立

新たな IT 企業としてのイメージ確立それに基づく企業戦略の見える化

協業による匠メソッドサービスの社外展開

クラウドビジネスメソッド

エンジニアがチャレンジ！


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

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

[email protected]

www.takumi-businessplace.co.jp

モデリングの神髄

Technology

Transcript of モデリングの神髄