Re-Introduction to Openthology
•
1 gefällt mir•1,631 views
オープンコミュニティ「要求開発アライアンス(http://www.openthology.org)」2008年5月度定例会の発表資料です。 Open Community "Requirement Development Alliance" 2008 May regular meeting of the presentation materials.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Andere mochten auch
Andere mochten auch (20)
Mehr von Kent Ishizawa
Mehr von Kent Ishizawa (20)
Re-Introduction to Openthology
- 1. 要求開発再入門 萩本 順三 MAMEZOU The solution beyond the solution.
- 2. 要求は「開発」するもの • 「要求分析」、「要求定義」などは、要求がすでに存在 しているという前提に立っている • ユーザからヒアリングした要求の実現が業務効率化 に結びつくとは限らない。 – ユーザの理解の範囲内で生まれた属人的なもの – 直感的、場当たり的であることが多い • 要求は、業務を分析することによって開発される。ロ ジカルに導かれる必要がある。 MAMEZOU ２．要求開発方法論とは The solution beyond the solution. 動機編より抜粋
- 3. なぜよいシステム開発ができないのか？ – 最悪のシナリオ 業務理念を統制し、業務効 率化を図るための業務とは ○○あるべきだよ。 業務管理者の論理 あの業務は、○○パッケージや 我々のやり方がベストなん ○○フレームワークを使って開発 だ。これにあわせてシステム すれば簡単だよ。 業務は、それにあわせればいい 壁 を作ってくれよ。 。 システム開発者の論理 業務担当者の論理 MAMEZOU ２．要求開発方法論とは The solution beyond the solution. 動機編より抜粋
- 4. それは、正しいシステム要求がだせないから • うまくいきそうで駄目なシナリオ（その１） – トップ・業務管理者の考えどおりのシステムを作ったが、業務担当から大クレー ム。 – 結局使われないシステムになった。 業務理念を統制し、業務効 率化を図るための業務とは ○○あるべきだよ。 業務管理者の論理 わかりました。おっしゃるとおり、 あの部長、業務の事をなに も分かっていないんだよね。 業務効率化案に基づいた要求を 考えていきましょう。 壁 でも、あの人のいう こと本当にただしい のかなあ？ まあ、いっか。 システム開発者の論理 業務担当者の論理 MAMEZOU ２．要求開発方法論とは The solution beyond the solution. 動機編より抜粋
- 5. それは、正しいシステム要求がだせないから • うまくいきそうで駄目なシナリオ（その２） – 業務担当者からそれぞれ要求を聞きだした。 » 業務の標準化ができない。 » 効率化を考慮していない業務にあわせて システムを作ってしまう。 業務理念を統制し、業務効率化を図るた めの業務とは○○あるべきだけど、業務 担当は、みんな既存システムのやり方に 慣れてしまって本当に改善しようとおもっ ていないんだ。 業務管理者の論理 我々のやり方がベストなん 分かりました。業務担当の方々 だ。これにあわせてシステム に合わせて、システムを開発しま す。 壁 を作ってくれよ。 だけど、それぞれの 担当者から出てくる 要望を開発するのは 大変だよな。 ま、いっか。 システム開発者の論理 業務担当者の論理 MAMEZOU ２．要求開発方法論とは The solution beyond the solution. 動機編より抜粋
- 6. 要求開発とは – 正しい要求の獲得と合意のための活動 業務理念を統制し、業務効率化を図るため の業務とは○○あるべきだ、しかし現実は △△だから、それをどう改善できるか現場と 話し合ってみよう。 業務管理者の論理 あの業務は、○○パッケージや○○フレー ムワークを使って開発すればよさそうだ、し 我々のやり方がベストだと思っていたけど、 かし、本当に求められている業務の姿を明 見方を変えれば欠点が多いね。問題分析ツ 確にして３者で合意しなければ、真の要求 問題の視覚化(モデル)と リーでもう少し業務のあるべき姿を考えてみ など獲得できるはずがないね。 改善プロセスによる活動 よう。 コタツ 開発された要求 システム開発者の論理 （システム要件） 業務担当者の論理 モデル MAMEZOU The solution beyond the solution.
- 7. 要求（正確に言うと要求仕様）はどうにでも定義できる！ ビジネス戦略 最適解はどれだ！ ＩＴによる付加価値注入 現場の問題解決 問題解決 MAMEZOU The solution beyond the solution.
- 8. 要求の重要性 • 米国Standishグループの調査によれば、システムに作りこんだ機 能のうち、結果として利用されているのは３６％だということです。 これは言い換えると３分の２のシステムが「役に立たない」という ことにもなります(Standish group study report in 2000 chaos report)。このような「大いなる無駄」を排するためには「正しい」要 求にもとづくシステム開発が必要となります。要求開発は、システ ム企画の段階からRFP（Request For Proposal）の作成まで、一 貫して「目的と手段の連鎖」を見える化していくプロセスです。こ れにより、ステークホルダー間の合意をとりながら、企業経営への 貢献という最終的な目的を実現させるためのシステム開発を推 進していきます。 MAMEZOU The solution beyond the solution.
- 9. 開発プロセスオーバービュー 広義の要求開発（要求定義） 狭義の要求定義 ＢＤＡ 経営分析 要求開発 広義のシステム開発 ビジョン、ミッションの 確立 問題点分析 準備 立案 デザイン 移行 ビジネスゴール設定 狭義のシステム開発 ビジネスユースケース システム開発 システム化範囲の導出 財務的解決やマーケ 業務フロー（As-Is、To-Be) 方向付け 推敲 構築 移行 ティング的解決で終わ ロードマップ作成 業務レベルの概念モデル る課題もある システムユースケースの 抽出と個別プロジェクト へのブレークダウン 第１ プロジェクト 方向付け 推敲 構築 移行 ビジネス戦略の見 える化、プロジェク トスコープとリソー 業務要求の獲得 スを確定しゴール とプロセスの見え 第２ プロジェクト を明確化。 る化、ITの基本要 方向付け 推敲 構築 移行 求の獲得。 狭義のプロジェクト 第３ プロジェクト 広義のプロジェクト 9 MAMEZOU The solution beyond the solution.
- 10. 要求開発方法論（Openthology）構造とモデル • 戦略とサービス構造中心でモデル化 – ビジネス戦略からプロジェクト戦略へ – 業務のサービスの明確化 • 企業の意思決定層とビジネスオペレーション層の構造を確立（見える化） – 企業の意思決定層の戦略を、ビジネスオペレーション層のサービスまで具体的に 落とし込むメソッドを持つ。 ビジネス戦略 ビジョン：ゴール構造 ビジネス オペレーション サービス構造 ビ プロセス構造 情報構造 ジ ネ オブジェクト ス ビジネス・プロセス ビジネス要求 モデル システム要求 データ アプリケーション・プロセス I モデル T シ ス アプリケーション テ ム フレームワーク 実装アーキテクチャ MAMEZOU The solution beyond the solution.
- 11. Openthology構造とモデル Openthology ユースケース記述 ユースケースモデル BSC戦略マップ 業務フロー（アクティビティ図） ビジネスユースケースモデル ビジネス概念モデル ビジネス戦略 分析・設計モデル ビジョン：ゴール構造 クラス図 ビジネス DB モデル ビ プロセス構造 サービス構造 情報構造 ジ ネ ス オブジェクト ビジネス・プロセス ビジネス要求 モデル システム要求 データ アプリケーション・プロセス モデル I T シ アプリケーション ス テ ム フレームワーク 実装アーキテクチャ 11 MAMEZOU The solution beyond the solution.
- 12. 要求の基本（ビジネスからシステム開発につなげる表と裏） 戦略 オペレーション ビジネス ビ ジ ビジネス戦略 オペレーション ネ ス What 表（価値） How 裏（実現） What 表（価値） 裏（実現） How シ ス 表（価値） What How裏（実現） テ ム システム要求 システム設計 MAMEZOU The solution beyond the solution.
- 13. 戦略のトリアージ 課題 オペレーション ビジネス戦略 ビジネス戦術 トリアージさ れた戦略 ビ 改善・改革が必 要な業務処理 ジ ネ ス 製品要求 トリアージ（triage）：要求を戦略的に取捨選択する事。 製 もともとは医学用語で、有限のリソース（医師や医薬 品 品など）を最大限に活用し、各患者の病状や状況に 開 合わせて、より多くの傷病者の治療をするために優 発 先順位を決定することを指す。 付録：発刊予定書籍 トリアージされた 「成功する要求仕様、失敗する要求仕様」日経ＢＰ 要求 アランＭデービス著、安井・萩本監訳、高嶋訳 MAMEZOU The solution beyond the solution.
- 14. Structure Openthology ver2.0 モデル・ストラクチャ図 ビジネス戦略 ビ 戦略ビュー ビジネス戦略 ＩＴ戦略 ジ ネ プログラム戦略 ス プロジェクト戦略 サービス ビュー プロセス ビュー 情報 ビュー ビジネス要求 ビジネス・プロセス オブジェクト モデル Ｉ Ｔ アプリケーション システム要求 データ シ ・プロセス モデル ス テ ム アプリケーション フレームワーク 実装アーキテクチャ MAMEZOU The solution beyond the solution.
- 15. Structure Openthology ver2.0 Structure & Reference Business Strategy Reference Model IT Strategy Reference Model ProgramStrategy ビジネス戦略 Reference Model ビ 戦略ビュー ビジネス戦略 ＩＴ戦略 ジ プログラム戦略 Project Strategy ネ プロジェクト戦略 Reference Model ス サービス ビュー プロセス ビュー 情報 ビュー ビジネス要求 Information オブジェクト ビジネス・プロセス モデル Reference Model Ｉ アプリケーション システム要求 データ Ｔ ・プロセス モデル シ ス アプリケーション Openthology 本質 ビュー テ フレームワーク ム 戦略 実装アーキテクチャ サービス Service Reference Model プロセス 情報 Process Reference Model MAMEZOU The solution beyond the solution.
- 16. モデルの役割(Ver1.0) 観点の ビジネス課題 ビジネス・オペレーション システム要求 システム設計 流れ 業務プロセスからIT要求へ プロセスモデル サービスモデル ・業務フロー ・システムユース ケース 戦略モデル サービスモデル アーキテクチャモデル ・BSC戦略 ・ビジネス マップ ・ERD/DB設計 ユースケース ・IT貢献度 マップ 情報モデル ・アーキテクチャモデル ・プロジェクト ゴール記述書 TFP分割手法 ・SOAモデル ・Thing図 ・Function図 ・Place図 ビジネス概念からITアーキテクチャへ 要求開発 フェーズ 準備 立案 デザイン シフト システム開発フェーズ ８．要求開発ビジネスモデリング応用編 MAMEZOU The solution beyond the solution.
- 17. Structure （要求開発） 戦略ビュー サービスビュー プロセスビュー BSRM PJSRM SRM PRM 財務 顧客 プロセス コタツモデル 教育 BSC戦略マップ 原価計算方式 の見直しと 経理部の 豆蔵の チェック作業 自動化 入力の分散 負荷の削減 ad ア クテ ィビ テ ィ 決算早期化（経費･勤怠） 早期の決算報告連結決算 提出期限の の自動化 手作業の自動化 厳守 ud ユースケースモデル 社会的 適正な 内部統制の ﾘｽｸﾎﾟｲﾝﾄの把握 ｺｽﾄ･売上 信用度の向上情報開示 新規事業の 確立 良質案件 コ ントロール予測の正確な 営業マンを 発生元での リアルタイムの把握 業務 増やす 直接入力 立上げ 値上げ 差別化 営業の 二重入力の データ連携 プロジェクト （事業部、福数人で） ｽﾃｰﾀｽ一覧 売上増 提供価格 営業力強化 新規を増やす 事務処理 付加価値増 信用度 削減 維持･向上（間違いの防止） （付加価値向上） （単価）をあげる 負荷軽減 案件の適切な システムによる 金額 実績 優先順位つけ案件情報の 見落とし案件 営業会議での 契約期間、 既存事業の稼働率を上げる 案件件数を リピートを増やす 提供 時期 の撲滅 適切な営業 ToDo作業の 職務経歴の情報共有 売上拡大 増やす 生産性向上 入力作業の 簡素化 二重入力の排除 把握 活動 迅速な提供 タイムリーな 個人別スキル 開始 終了 人数 積極的採用 操作性向上 レスポンス アサイン状況 提案 情報の把握 利益向上 回線障害の回避 （企業価値 利益の （要員数） 離職率を モチベーション 社内情報 のタイムリーな 向上） 維持 把握 減らす アップ 案件情報 契約管理 適正な評価 個人売上の の共有 リアルタ イムな 事業の円滑 プロジェクトの 適切な 予算 収支管理表 ゴール記述書 な運営 円滑な運営 予実管理 精度ある 実績 把握 売上･経費 プロジェ クト情報 適正な運用 情報 （経費･工数･アサイン） タ イムリーで 事業部、ﾁｰﾑ コスト減 チャンスロス 事業部単位での売上予測 予算と実績の のタイムリーな入力 高精度な把握 毎に異なる (ロスセーブ) （機会損失） 予実管理 同一粒度での 社内振替の ﾋﾞｭｰが必要 対比 管理 厳正な評価 精度ある 情報共有 適正な 稼動予実一覧 （アサイン表） ･活用 アサインメント （ 適正な 勤怠の承認 （スキル･思考） 労務管理 概念アクティビティ図 要求リスト 要求分析ツリー ビジョン分析ツリー プロジェクト定義 ビジネスユースケース 問題分析ツリー ステークホルダー分析 ターゲット分析 情報ビュー 概念クラス図 ☆TFP分割 （Thing図、Function図、Place図） cd 論理 モデ ル 0..* 1..* 0..* 0..1 1 0..* IT貢献度マップ 技術マップ ゴール記述書 プログラム計画 ITSRM What What PSRM IRM How How MAMEZOU The solution beyond the solution.
- 18. Structure（要求開発からシステム開発へ） 要求開発 システム開発 プロセスビュー サービスビュー プロセスビュー PRM ? s d 相互作用 論理モデル:: 論理モデル:: 論理モデル:: 論理モデル:: 論理モデル:: イベントフロー ad ア クテ ィビ テ ィ 業務 情報 開始 終了 シーケンス図 概念アクティビティ図 要求リスト ud ユースケースモデル cd 設計クラス図 cd 設計クラス図 情報ビュー 情報ビュー システムユースケース 概念クラス図 ユースケース記述 cd 分析クラス図 設計クラス図 ☆TFP分割 （アーキテクチャ） アプリ ケー id コンポ ー ネントモデ ル 0..* （Thing図、Function図、Place図） スコー ション 1..* パッケー ジ 0..* プ 0..1 cd 論理 モデ ル パッケー ジ 0..* 1..* 0..* 0..1 1 0..* パッケー ジ アプ リケー 配置図 レ ベ ショ ン エンター ズレベル ル プライ What What IRM How How ＥＲ図 MAMEZOU The solution beyond the solution.
- 19. システム開発におけるＶ字モデル システム要件 受け入れテスト サブシステム要件 サブシステムテスト コンポーネント要件 コンポーネントテスト モジュール要件 単体テスト MAMEZOU ３．要求開発の意義 The solution beyond the solution.
- 20. 要求開発の目指す・変形Ｖ字モデル 要求 ビジネス要求 Verification Validation 開発 評価 ビジネステスト 結果イメージの予測 シス 評価 システム要件 受け入れテスト テム 開発 評価 サブシステム要件 サブシステムテスト 評価 コンポーネント要件 コンポーネントテスト モジュール要件 単体テスト MAMEZOU ３．要求開発の意義 The solution beyond the solution.
- 21. ToBeビジネス（結果イメージ）の予測 戦略の根拠 Why 戦略の根拠 戦略の根拠 Why Why ビジネス戦略 What 準 ビジネス戦略 ビジネス戦略 備 What What 立 案 デ ザ イ ン ・ 方式 How シ 方式 フ How ト 方式 How 方式 方式 How How MAMEZOU The solution beyond the solution.
- 22. ビジネス価値とビジネス方式関係 価値 価値 価値 What What What A 方式How 方式How 方式How 要求開発（時間軸） 価値 価値 価値 What What What B 方式How 方式How 方式How 要求開発（時間軸） MAMEZOU The solution beyond the solution.
- 23. ビジネス戦略のトリアージ 優先順位 ビジネス戦略 ２００７年３月 新たに見つけられた戦略 引き継がれる戦略 １年 トリアージ後選 択された戦略 要求を開発 ２００８年３月 （実現） 新たに見つけられた戦略 引き継がれる戦略 トリアージ後選択さ れた戦略 ７ヶ月 要求を ２００８年１０月 開発 トリアージ後選択さ れた戦略 MAMEZOU The solution beyond the solution.
- 24. これからのアーキテクトの課題 ビジネス IT システム システム 現状 ビジネスとITを分けて考える 要求 設計 実装 （WhatとHowの分離） What How ビジネス IT システム ビジネス ビジネスオペ システム NEXT ビジネスの見える化手法を確立 戦略 レーション 要求 設計 実装 （戦略と実現の分離） What How What How What How ビジネス IT システム 見える化を目的で繋げる ビジネス ビジネスオペ システム NEXT 戦略 レーション 要求 設計 実装 （分離したもの同士の 最適なリレーション） What How What How What How NEXT Howからの突き上げ によるビジネス価値 増大のための見える化 MAMEZOU The solution beyond the solution.
- 25. 要求開発プロセス（プロセスキャビネット）のイメージ Structure Phase： 段階的に詳細化・具体化していく Disciplines 準備 立案 デザイン シフト Plan 作業項目名 作業項目名 Do P P P P D D D D Check C C C C Act A A A A ７．要求開発プロセス MAMEZOU The solution beyond the solution.
- 26. 実際のプロセスキャビネット 要求開発プロセスキャビネット 段階 初期知識の可視化と合意に基づく計画 ビジネス課題に関する概観の可視化 新ビジネスのデザイン システム開発への移行 Phase 準備 arrangements 立案 draft デザイン design シフト shift Decipliens ・フェーズ基本計画 ・フェーズ基本計画 ・フェーズ基本計画 ・フェーズ基本計画 ・要求開発プロジェクトのゴールの設定 ・モデリング戦略策定 ・ToBeモデルの評価方法の策定 ・システムToBeモデルの評価方法の策定 ・要求開発チーム編成計画 ・ビジネス要求評価方法の策定 ・IT基本要求の評価方法の策定 ・IT基本要求の評価方法の策定 Plan ・準備教育計画作成 ・教育計画の作成 ・ビジネス可視化プロトタイプ計画 ・システム移行計画書達成評価基準の明 ・ビジネス可視化プロトタイプ計画 の見直し 確化 ・システム基本構想策定計画 ・システム基本構想策定計画 ・要求開発プロセスのカスタマイズ 計画 ・実施計画書作成 ・ビジネス課題の理解 ・概観ビジネスモデリング ・ビジネスToBeモデリング ・システムToBeモデリング ビジネスモデル ・プレビジネスモデリング(Option) ・ビジネス要求の開発 ・IT基本要求の開発 ・IT基本要求の開発 Do 要求モデル ・コアメンバー教育 (Option) ・要求開発メンバー教育 ・動機付けセミナー(Option) 教育 ・教材の作成(Option) ・プロトタイプ開発 ・プロトタイプ開発 ・システム移行計画書作成 システム化 ・承認権限者による検証 ・承認権限者による検証 ・承認権限者による検証 ・承認権限者による検証 ・メンバー責務・スキルの確認 ・プロジェクトミッションの評価 ・ビジネスToBeモデルの評価 ・システムToBeモデルの評価 Check ・モデリングの評価（Option） ・モデリング戦略評価 ・IT基本要求の評価 ・IT基本要求の評価 ・ビジネス課題の評価 ・概観ビジネスモデリング評価 ・プロトタイプの評価 ・システム移行計画書内容の評価 ・教育実施評価 ・システム基本構想の評価 ・計画の見直し・改善 ・計画の見直し・改善 ・計画の見直し・改善 ・計画の見直し・改善 ・メンバー構成の見直し ・構想の見直し・改善 ・構想の見直し・改善 ・すぐやるカイゼン ・教育計画の再計画 ・すぐやるカイゼン ・すぐやるカイゼン Action ・必要であればビジネス課題の理解のやり 直し ・メンバー構成の見直し ・必要であれば、再教育を期間を検討する ・すぐやるカイゼン ７．要求開発プロセス MAMEZOU The solution beyond the solution.
- 27. 要求開発のフェーズ 準備 ■ビジネス戦略の把握とプロジェクト課題の見極め ・ビジネス戦略、ＩＴ戦略の見える化 ・プロジェクト課題の見極めのための、ざっくりとした見える化 ・必要人材のアサイン（我々で果たしてプロジェクト課題を解決できるか？：リソース） ・プロジェクトターゲット範囲の決定（どの領域をどこまでやるの？：スコープ） ・要求開発プロジェクトゴールの策定 立案 ■概観の把握と可視化 ・モデリング戦略（ToBe、AsIs業務モデルの把握のための順序戦略） ・プロジェクトゴールにスコープしたビジネス領域の外観を見える化（攻略点の把握） ・当初から課題とされているビジネス要求の抽出と整理（本質的見極め） デザイン ■ToBe業務の設計 ・ToBe業務の設計 ・ビジネス要求開発、IT基本要求の開発 シフト ■システム計画 ・IT基本要求の抽出 ・システム移行計画書の作成 ７．要求開発プロセス MAMEZOU The solution beyond the solution.
- 28. 要求の開発および獲得 • 要望 – 業務視点でだされた、ビジネスおよびシステムに対 する「XXXのためにXXXしたい。」といった要望。 • 要求 – 要求開発チームで、意味不明な要望、要望の重 複排除、似ている要望を整理することで要求に格 上げされる。 • 要件 – 期間コストを踏まえて、どのシステム開発で取り入 れるのか決定されたシステム要件。 ３．要求開発における要求 MAMEZOU の開発および獲得 The solution beyond the solution.
- 29. 要望-要求-要件への変化 トップ・品質管理 例： 「検査業務を早く、安く、正確に！」 管理者・品質管理（業界標準等） ビジョン 例：管理者「 効率化を図るために、再測を止める」 品質管理「セキュリティのために、個人特定機能が必要」 方針 目的 対策 現場 例：担当者「業務ミスを犯さないために、二重チェックを行う」 個別方針 要望 要求 要件 （会議体で分析） ・システム化対象の選択 ・システム化実現方法の 選択検討と合意 （会議体で検討） ･リリース予定日の設定 ・重複を省く 業務要求 業務要件 ･グループ分け ・重要度の管理 0…＊ ・業務かシステムかの判断 （会議体で分析） ・コンセプトの再確認 システム要求 システム要件 ・要求の優先度付け ・運用方法の確立 ・目的に対する対策を分析 ・例外事象の洗出 要求 し、参加者の納得できる ・システム利用方法 方法を仕上げる。 ・上記の標準化 機能要求 ユースケース コンポーネント ３．要求開発における要求 非機能要求 アーキテクチャ MAMEZOU の開発および獲得 The solution beyond the solution.
- 30. 要求の生息地 • 原住民 – 初めから企業ミッションの中に生息している、そもそも達成 すべき最優先要求。 – いままでの業務の延長から見つかる要求。 – いままでのシステムの中に生息して、今後も必要となる要 求。 • 未開の土地 – 業務改善により始めて姿を見せる要求。恥ずかしがりやで 、まだ形がはっきりとせず、個人の意識の中に眠っているの で、みんなで目に見えるように可視化しないと出てきてくれ ない。 • 暗黙知域 – 業務メンバーと開発メンバーの意識の中に暗黙知として眠 っており、これが基で様々なトラブルを引き起こす。 ３．要求開発における要求 MAMEZOU の開発および獲得 The solution beyond the solution.
- 31. ＴＦＰ分割概要（なぜＴＦＰ分割か？） • データモデル – 長所 • 物と場だけに着目する。所詮はデータ集合を静的に現すものなの で、非常に解りやすく曖昧性がない。 – 短所 • 機能（業務）との関係が希薄。業務処理の概念化が異なる図 (DFD)として表現するしかない。 • オブジェクト（クラス）モデル – 長所 • 機能的なクラスを抽出するために、機能概念を含んだ自然な概念 世界を表現できる。 – 欠点 • 概念の中に機能的なクラスが存在すると、機能の中に関連が隠さ れてしまったり、機能の入出力関係と、「もの」と「もの」との関係が 混在することになり非常に曖昧になる。 MAMEZOU The solution beyond the solution.
- 32. Thing、Function、Placeにクラスを分類する Thing …もの（情報）として識別された単位。 Entity(属性の集合が一般的) •イベント（事象）やトランザクション（取引） イベント トランザクション の結果・記録も「もの」に分類 イベントの記録として Thingに置くのがポイント 概念（クラス） Function …機能として識別された単位 Control(機能名がクラス) 通常、属性と操作がない。 Place …場所を示す MAMEZOU The solution beyond the solution.
- 33. クラスを Thing、Function、Placeの中でさらに分類する 大分類 小分類 事例 リソース系 科目 商品 顧客 店 モノ Thing イベント系 仕訳 取引 注文 コト 機能系 取引業務 注文業務 概念（クラス） Function スル ルール系 Ａ取引 Ｂ取引 キソク Place 場所系 会社 バ MAMEZOU The solution beyond the solution.
- 34. Thing図の例 Thing図 には Function と Place を含めてはならない。 Thing図例 ピンク系統で表現。またはステレオタイプ<<Thing>>を使う cd 論理モデル cd 論理モデル +貸し方 0..1 1..* 客 顧客 仕訳 勘定科目 +借り方 1 1..* 0..1 1..* 1 +対象科目 0..* +購入商品 1..* 1..* +月次単位 商品 BS/PL 累積データ 科目 - 借り方計: int 1 1 - 貸し方計: int ものとものとの関係 MAMEZOU The solution beyond the solution.
- 35. Function図の例 Function図 には Thing を含めてよい Function図例 グリーン系統で表現。またはステレオタイプ<<Function>> cd ? +貸し方 仕訳 0..1 1..* 勘定科目 +借り方 0..1 1..* 支社 支社 月次更新 累積データ BS/PL - 借り方計: int 科目 - 貸し方計: int 1 1 ものの使われ方（ものの価値証明） MAMEZOU The solution beyond the solution.
- 36. Place図の例 Place図 には Function と Thing を含めてよい Place図例１ クラス表現の場合 …ブルー系統で表現。またはステレオタイプ<<Place>> パッケージ表現の場合…特になし cd もの・ことを置く場の 本社 +購入商品 定義場により価値が出る！ 商品 顧客 1..* 0..* <<購入される>> 店舗 売上 MAMEZOU The solution beyond the solution.
- 37. ＴＦＰ分割手法まとめ ビジネス具現的概念 ビジネス普遍概念 （ビジネスの価値に着目） （ビジネスの本質に着目） Place図 Function図 Thing図 Thing Function Thing Place ものとものとの関係 Function ものの使われ方 ものとことをおく場の定義 ビジネス 分析対象 ＳＯＡ オブジェクト 汎用概念 開発に移行 可能な概念 分散協調設計 アーキテクチャ設計 ＤＢ設計 MAMEZOU The solution beyond the solution.