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