Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ビジネスモデル2 rdra

689 views

Published on

https://agilesapporo.doorkeeper.jp/events/60056

Published in: Engineering
  • Be the first to comment

ビジネスモデル2 rdra

  1. 1. ビジネスモデル2RDRA4DDD V0.4
  2. 2. コスト構造 収益構造 パ ー ト ナ ー 顧 客 セ グ メ ン ト 価 値 提 案リソース 主要活動 チャネル 顧客との 関係 登場人物 もの・サービス 配送手段 決済手段 ビジネスモデルキャンバス ビジネスコンテキスト ビジネスモデルキャンバスからRDRAへ ビジネスモデル分析 バリエーション分析 ビジネス ルール 業務設計 RDRA RDRA for DDD
  3. 3. ビジネスモデルの分析1 コスト構造 収益の流れ パ ー ト ナ ー 顧 客 セ グ メ ン ト 価 値 提 案 リソース 主要活動 チャネル 顧客との関 係 ビジネスコンテキスト 2.ビジネスコンテキスト 登場人物の洗い出し ・顧客セグメント ・パートナー ・商品・サービス ← 価値提案 主要活動 リソース 業務の洗い出し ・登場人物の役割や関係から業務を分類 ・業務と登場人物をつなぐ 1.ビジネスモデルキャンバス ・顧客を決める ⇒ 顧客セグメント別にシートを作成 ・価値を洗い出す ・パートナーを洗い出す ・主要活動を洗い出す ・顧客との関係チャネルの洗い出し ・主要活動のためのリソースを洗い出す 会社 顧客 パート ナー 商品 パート ナー サービ ス 営業 購買 物流 業 務 業 務 ビジネスモデルキャンバス ビジネスモデル分析
  4. 4. 業務設計 ビジネスコンテキスト 会社 顧客 パート ナー 商品 パート ナー サービ ス 営業 購買 物流 業 務 業 務 UC UC UC UC 利用 シーン 利用 シーン 利用 シーン 規模が大きい場合 中規模の場合 UC UC サービスの単位を利用シーンとして 洗い出す UC 情報 画面 イベ ント 小規模の場合 情報 画面 イベント ユースケース中心 業務設計 UC UC 情報 画面 イベント 利用 シーン 業務を1枚で表現 業務単位で業務 フローを定義 業務単位で複数の業務フ ローを利用シーンで表現 業務を複数の利用 シーンとして整理 利用 シーン UC 業務を1つの業務 フローとして整理 UC 情報 画面 イベ ント UC 情報 画面 イベ ント UC 情報 画面 イベ ント 業 務 業 務 構成のポイント ・業務の設計は「業務」単位 ・システム要件は「ユースケース」単位
  5. 5. バリエーション分析 コスト構造 収益の流れ パ ー ト ナ ー 顧 客 セ グ メ ン ト 価 値 提 案 リソー ス 主要活 動 チャネ ル 顧客と の関係 バリエーションの組み合わせからビジネスルールのベースを 明確にする バリエーション間の関係を整理 概念 組合せによる特性を分析 登場人物、商品、取引など重 要な概念のバリエーションを クラス図か一覧表で整理する 1.バリエーションの抽出 2.ルールの抽出 概念モデルが作成できる場合は、それで全てまかなえる。 モデルを使わない場合は、Excelでバリエーションを洗い出し、組 み合わせを表形式で作成し、ピボットテーブルを使ってマトリッ クス化する ビジネスコンテキスト 会社 顧客 パート ナー 商品 パート ナー サービ ス 営業 購買 物流 業 務 業 務 [XXX:モデル](バリエーション) [XXX:モデル] (条件_表) 番外編
  6. 6. システム価値 システム外部環境 システム境界 システム UC:ユーケース RDRA コンテキスト 利用シーン 業務 イベント ユースケース概念 画面・帳表 機能 データ 要求 機能複合 モデル 利用シーン &UC 業務&UC 状態 UC&画面 UC&機能 プロトコル 6
  7. 7. システム地図 7 画面 ユースケース 機能 データ・ ドメイン 外部システム イベント 要求 関係が整合性、網羅性を確保する システム地図の構成要素 利用シーン
  8. 8. システム価値 システム外部環境 システム境界 システム UC:ユーケース RDRA for DDD コンテキスト 利用シーン 業務フロー イベント 機能複合モデル 要求 状態 プロトコル オプション オプション UC 情報 or 情報 画面 イベント 「システム境界」の詳細化と「システ ムの分析」は開発側に任す 8 データではなく情報 ユースケースを安定させるた めに「情報」を活用 状態遷移をユースケース に対応させてもよい 業務フローか 利用シーンの どちらか 業務フローか利用シーンご とに機能複合モデルを作る 情報の構造化 はしなくてよい、 構造化はドメイ ンモデルで行う 現場で認識して いる状態を明示 することが大事 ビジネスユースケー スと捉えてもよい
  9. 9. システム価値 システム外部環境 システム境界 システム UC:ユーケース RDRA for DDD コンテキスト 利用シーン 業務フロー イベント 機能複合モデル 要求 状態 プロトコル オプション オプション UC 情報 or 情報 画面 イベント 「システム境界」の詳細化と「システ ムの分析」は開発側に任す 9
  10. 10. RDRA4DDD
  11. 11. RDRAとドメインモデルの関係  RDRAは本来開発方法を選ばない Howは扱わない  RDRA for DDDのスタンス  深い分析は開発側(ドメインの分析)に任せ、RDRAは整合のとれた要件を定義することに徹する  RDRA 広く浅く分析  ドメイン分析 深く分析 ガツンと中心となる概念 をつかんで、育てていく RDRA Domain RDRAが外から攻め ドメインモデルが中核から攻める ドメインモデル RDRA 広く網を張り徐々に固めていく 11
  12. 12. RDRAで枠組みを決める 12  RDRAの役割  構成要素の洗い出し 深い分析のための構成要素を洗い出す  スコープ決め 構成要素をつなげスコープを見極める  分類 コンテキストの見極め、業務分類の見極め 全体の枠組みを押さえながら進める RDRAで外枠を固めて安定したサイクル (タイムボックス)が回るようにする タイムボックスで育てていく
  13. 13. 要件と開発の両輪でまわす  要件定義と開発の両輪で回す  要求側 ⇒ RDRAの構成要素を洗い出し、分類とスコープを識別する  開発側 ⇒ 中核となる概念を中心に深い分析を行う  2つのチームが外側と内側から並行して進める 開発 要件定義 計画 プロト プロト 構築 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 分析 設計 実装 テスト 受入テスト プロト 継続的インテグレーション 要求側 (情シス) 開発側 13 RDRA ドメインモデル
  14. 14. 詳細な分析
  15. 15. 業務フローの分析:仕事の定義 コスト構造 収益の流れ パ ー ト ナ ー 顧 客 セ グ メ ン ト 価 値 提 案 リソース 主要活動 チャネル 顧客との関 係 取引の抽出 ビジネスモデルキャンバスの主要活動をベースに取引を洗い出す ・取引は価値を提供する単位として整理する ・取引を業務フローとして整理 既存システムの再構築の場合 複雑化した既存の業務を整理するために、登場人物間の関係から主要な取引を整理する システム化に先立ち仕事を明確にする ・業務フローは仕事の流れとして整理(作業を抽出しない) ・仕事には入力情報(伝票)と結果もしくは出力情報(伝票)となるインターフェースがある ・仕事は組織の責務に従って成果を出す単位で抽出する ・ 組織 責務 価値価値 ・組織の責務を再確認 ・取引を組織の責務から仕事を割り当てる ビジネスコンテキスト 会社 顧客 パート ナー 商品 パート ナー サービ ス 営業 購買 物流 業 務 業 務 ビジネスモデルキャンバス
  16. 16. ビジネスモデルの分析 ビジネスを変えるケース コスト構造 収益の流れ パ ー ト ナ ー 顧 客 セ グ メ ン ト 価 値 提 案 リソース 主要活動 チャネル 顧客との 関係 <10Types> 基本的な構造 ・利益モデル ・ネットワーク ・組織構造 オファリング ・プロセス ・製品性能 ・製品システム 経験 ・サービス ・チャネル ・ブランド ・顧客エンゲージメント 2.ビジネスモデルの幅を広げる場合 現状のビジネスモデルを10Typesを利用して 整理し、To-Beのビジネスモデルとして注力 するところを明らかにする 3.ROIを分析する 価値を提供するために必要なコストと集積の 流れを把握 分析 1.複数顧客への統一的な対応 2.ビジネスモデルの幅を広げる場合 3.ROIを分析する場合 ~~ コスト構造 収益の流れ パ ー ト ナ ー 顧 客 セ グ メ ン ト 価 値 提 案リソー ス 主要活 動 チャネ ル 顧客と の関係 コスト構造 収益の流れ パ ー ト ナ ー 顧 客 セ グ メ ン ト 価 値 提 案リソー ス 主要活 動 チャネ ル 顧客と の関係 コスト構造 収益の流れ パ ー ト ナ ー 顧 客 セ グ メ ン ト 価 値 提 案リソー ス 主要活 動 チャネ ル 顧客と の関係 コスト構造 収益の流れ パ ー ト ナ ー 顧 客 セ グ メ ン ト 価 値 提 案リソー ス 主要活 動 チャネ ル 顧客と の関係 1.複数顧客を統一的に対応する場合 顧客セグメント別のキャンバスを作成し、主要活動で統一する コスト構造 収益の流れ パ ー ト ナ ー 顧 客 セ グ メ ン ト 価 値 提 案リソー ス 主要活 動 チャネ ル 顧客と の関係 コスト構造 収益の流れ パ ー ト ナ ー 顧 客 セ グ メ ン ト 価 値 提 案リソー ス 主要活 動 チャネ ル 顧客と の関係 As-Is To-Be コスト構造 収益の流れ パ ー ト ナ ー 顧 客 セ グ メ ン ト 価 値 提 案リソー ス 主要活 動 チャネ ル 顧客と の関係 会社 顧客 パート ナー 商品 パート ナー サービ ス 営業 購買 物流 業 務 業 務 ビジネスコンテキスト ビジネスモデルキャンバス

×