Cozyモデル駆動開発/ビジネス・プロセス(4)

Pieris Books(ブックカフェ併設のセレクトショップ販売店)のシステム開発のプロジェクトを進めています。

現在はビジネス・モデルの作成中で以下のモデルを定義してきました。

• ビジネス・ビジョン
• ビジネス・ゴール
• ビジネス・コンテキスト図

続けてBusiness.md内に以下のビジネス・オブジェクトから構成されるビジネス・モデルの核になる部分を作成しました。

• ビジネス・システム
• ビジネス・プロセス
• ビジネス・アクター

このビジネス・モデルをビジネス・プロセスを中心に肉付けしていきます。

ビジネス・プロセスの構成要素

ビジネス・プロセスはビジネス・システム内で行われる活動を抽象化したモデルで、様々なビジネス・オブジェクトから構成されます。

ビジネス・プロセスを構成する主なビジネス・オブジェクトは以下になります。

ビジネス・オブジェクトの種類

ビジネス・オブジェクトの種類は以下になります。括弧内はステレオタイプです。

• ゴール (goal)
• 情報 (information)
• 抽象 (abstract)
• 物理 (physical)
• 人 (people)

リソースは「情報(information)」または「コト(things)」に分類されます。「コト(things)」は「抽象(abstract)」または「物理(physical)」に分類されます。そして「物理(pysical)」の中で人を「人(people)」とします。

ビジネス・オブジェクトとの関係

ビジネス・プロセスとビジネス・オブジェクト間の関係の種類は以下になります。括弧内はステレオタイプです。

• 入力
• 出力
• 達成 (achieve)
• 制御 (control)
• 提供 (supply)

入力と出力はビジネス・プロセスに対する入力と出力です。

「達成(achieve）」はゴール(goal)を関連付けます。

「制御(control)」はビジネス・プロセスを制御するリソースを関連付けます。ビジネス・プロセスに対して能動的に参加するリソースということになります。

「提供(supply)」はビジネス・プロセスから利用されるリソースを関連付けます。ビジネス・プロセスに対して受動的に参加するリソースということになります。

ビジネス・プロセス図

上記のビジネス・オブジェクトとビジネス・プロセスの関係をビジネス・プロセス図では以下のように記述します。

これと同等の情報をCozyモデルの記述方式でBusiness.mdに記述します。このモデルからビジネス・プロセス図が自動生成することを想定しています。

ビジネス・プロセスの振る舞い

ビジネス・プロセスの振る舞いモデルとして以下のモデルを作成します。

• ビジネス・ユースケース
• ビジネス・フロー

ビジネス・ユースケース

ビジネス・プロセス内でビジネス・アクターの目標を達成するために実行される物語です。

ビジネス・ユースケースを作成することでビジネス・プロセスに参加するビジネス・アクターを抽出することができます。

ユースケース・シナリオによって、このビジネス・アクターが対話するITシステムと、その対話内容を抽出することができ、ここからシステムの利用方法が分かります。

また、ユースケース・シナリオの中で以下のビジネス・オブジェクトを抽出することができます。

• ビジネス・イベント
• ビジネス・エンティティ
• ビジネス・ルール

ビジネス・フロー

ビジネス・プロセスの振る舞いをアクティビティ図などを使ったフローとして記述したものです。

ビジネス・ユースケースの物語を実現する業務の流れをモデル化します。

ビジネス・ユースケースと同様にビジネス・フローによって以下のビジネス・オブジェクトを抽出することができます。

• ビジネス・イベント
• ビジネス・エンティティ
• ビジネス・ルール

ビジネス・プロセスを実現するビジネス・オブジェクト

ビジネス・プロセスを実現するために使用するビジネス・オブジェクトの中で、ITシステム内で管理する候補となるものは以下になります。

いずれもビジネス・ユースケース、ビジネス・フローで抽出しています。

• ビジネス・アクター
• ビジネス・イベント
• ビジネス・エンティティ
• ビジネス・ルール

ビジネス・アクター

ビジネス・アクターはビジネス・システムの活動に参加する人や外部システムです。

人の場合は前述のビジネス・オブジェクトの種類では「人(information)」に分類されます。

ビジネス・プロセスに人として参加している場合、必ずしもITシステムと接点があるわけではありません。このためビジネス・アクターの中でITシステムと接点のあるものがITシステムのアクターの候補となります。

ビジネス・イベント

ビジネスの活動の中で発行されるイベントです。ビジネス・ユースケースまたはビジネス・フローで抽出します。

ビジネス・オブジェクトの種類では「情報(information)」に分類されます。

ドメイン・イベントの候補となります。

ビジネス・エンティティ

ビジネスの活動の中で管理して更新するエンティティ(永続オブジェクト)です。

ビジネス・ユースケースまたはビジネス・フローで抽出します。

ビジネス・プロセスの動的モデルはエンティティの状態遷移が基本となります。

ビジネス・オブジェクトの種類では「情報(information)」に分類されます。

ドメイン・エンティティの候補となります。

ビジネス・ルール

ビジネス・プロセスの振る舞いを規制したり、各種計算を行う規則です。

ビジネス・オブジェクトの種類では「情報(information)」に分類されます。

ドメイン・ルールの候補となります。

まとめ

今回はビジネス・プロセスの構成要素について整理しました。

次回からビジネス・プロセスを構成する個々のビジネス・オブジェクトの検討に入っていきます。

次回はビジネス・ユースケースについて検討します。

Cozyモデル駆動開発/ビジネス・プロセス(3)

今回はビジネス・モデルを記述するBusiness.mdの構造についてみていきます。

Business.mdの基本構造はCozyのオブジェクト・モデル記述に則っています。Cozyのオブジェクト・モデルを使ってビジネス・モデル用のモデル要素を導入することでオブジェクト・モデルを記述しています。

基本文法

Cozyモデルの文法はMarkdown文法の基本部を使用しており、ニッチな機能を使わなければ基本的にはMarkdownとして記述して大丈夫です。またMarkdownにない文法を必要に応じて追加しています。

基本構造

セクションの階層でモデルの基本構造を記述します。

第1階層であるセクションでは、セクション内に記述するモデルの種類を記述します。

ビジネス・モデルでは以下のモデル種別を使用しました。

• Overview : 概要
• System : ビジネス・システム
• Process : ビジネス・プロセス
• Actor : ビジネス・アクター

第2階層であるサブセクションでは、サブセクション名にモデル名を記述します。

オブジェクトの定義

オブジェクトの定義はオブジェクト用のサブセクションの中で行います。

クラス名

オブジェクトのクラス名はサブセクション名で記述します。

特性

特性(property)は以下の3つの形式で記述することができます。

• 表
• リスト
• プロパティ

オブジェクトに関する特性をプロパティとして記述します。

属性

属性(attribute)は以下の3つの形式で記述することができます。

• 表
• リスト

表

表で属性情報を記述する場合、以下のように名前(Name)、Type(型)、Multiplicity(多重度)のカラムにそれぞれのデータを記述します。

| Name  | Type   | Multiplicity |
|-------+--------+--------------|
| id    | token  |            1 |
| name  | string |            1 |
| price | int    |            1 |

型(Type)の対象はデータ型またはValueです。

属性の情報を記述した表と判定する方法は以下のとおりです。

まず以下のようにキャプション名Attributesの表が属性の対象となります。

: Attributes
| Name  | Type   | Multiplicity |
|-------+--------+--------------|
| id    | token  |            1 |
| name  | string |            1 |
| price | int    |            ? |

キャプション名がない場合は以下のルールで属性対象の表を特定します。

サブサブセクションAttributesがある場合は、その配下から属性の情報を特定します。

サブサブセクションAttributesがない場合、サブセクション直下に最初に現れた表またはリストが属性用の情報と判断されます。

リスト

リストで属性情報を記述する場合、以下のようにUMLベースの記法で属性名を記述します。

- id: token
- name: string
- price: token [?]

多重度は省略すると1となります。またUMLの記法に食わえて以下のマークを使うことができます。

• ? : 0..1
• + : 1..*

属性の情報を記述したリストと判定する方法は以下のとおりです。

サブサブセクションにAttributesがある場合は、その配下から属性の情報を特定します。

サブサブセクションAttributesがない場合、サブセクション直下に最初に現れた表またはリストが属性用の情報と判断されます。

関連

関連(association)も属性と同様に以下の2つの形式で記述することができます。

• 表
• リスト

表

表で関連情報を記述する場合、以下のようにName(名前)、Type(型)、Multiplicity(多重度)のカラムにそれぞれのデータを記述します。

| Name  | Type       | Multiplicity |
|-------+------------+--------------|
| items | OrderItems |            * |
| user  | User       |            1 |

型(Type)の対象はEntityです。

属性の情報を記述した表と判定する方法は以下のとおりです。

まず以下のようにキャプション名Attributesの表が属性の対象となります。

: Associations
| Name  | Type       | Multiplicity |
|-------+------------+--------------|
| items | OrderItems |            * |
| user  | User       |            1 |

キャプション名がない場合は以下のルールで関連対象の表を特定します。

サブサブセクションAssociationsがある場合は、その配下から関連の情報を特定します。

リスト

リストで関連情報を記述する場合、以下のようにUMLベースの記法で関係を記述します。

- items: OrderItems [*]
- user: User

属性と同様に多重度は省略すると1となります。またUMLの記法に食わえて以下のマークを使うことができます。

• ? : 0..1
• + : 1..*

属性の情報を記述したリストと判定する方法は以下のとおりです。

サブサブセクションにAssociationsがある場合は、その配下から属性の情報を特定します。

ビジネス・モデルの場合

今回のモデルでは、前述のモデル記述方法がどのように使われているかを確認します。

ビジネス・モデルでは以下のモデル種別を使用しました。

• Overview : 概要
• System : ビジネス・システム
• Process : ビジネス・プロセス
• Actor : ビジネス・アクター

Overview

Overviewセクションではモデルのスコープをリストによるプロパティ形式で記述しています。

- scope : business

System

以下の3つのシステムを定義しています。

• Pieris Books
• 店舗
• ECサイト

Pieris Booksシステムでは、Pierisシステムの説明文とともにシステムを構成する関連を定義しています。

店舗システムとECサイトシステムは現段階では文章のみです。

Process

以下の3つのビジネス・プロセスを定義しています。

• 店舗販売プロセス
• EC販売プロセス
• 在庫管理プロセス

各ビジネス・プロセスの詳細は現段階では文章のみです。

Actor

以下の9個のビジネス・アクターを定義しています。

• 店舗顧客
• EC顧客
• 外部ECサービス
• 決済サービス
• 配送サービス
• 店舗販売者
• 店舗運営者
• 販売管理者
• システム管理者

各ビジネス・アクターの詳細は現段階では文章のみです。

まとめ

今回はCozyモデル記述言語の基本的な文法とビジネス・モデルでの適用について説明しました。

次回はCozyモデル記述言語を使ってビジネス・プロセスの定義を行っていきます。

Cozyモデル駆動開発/ビジネス・プロセス(2)

Pieris Books(ブックカフェ併設のセレクトショップ販売店)のシステム開発のプロジェクトを進めています。

現在はビジネス・モデルの作成中で以下のモデルを定義してきました。

• ビジネス・ビジョン
• ビジネス・ゴール
• ビジネス・コンテキスト図

この中でビジネス・コンテキスト図はビジネス・モデルを記述したBusiness.mdから生成するアプローチをとっています。

前回はビジネス・モデルを記述するBusiness.mdのフォーマットについて説明しました。

今回はBusiness.mdを使ってPieris Booksのビジネス・モデルを記述します。

Business.md

作成したBusiness.mdは次のものです。以下で各項目について説明します。

# Overview
- scope : business
# System
## Pieris Books
Pieris Booksビジネス。
- 店舗
- ECサイト
- 店舗販売プロセス
- EC販売プロセス
- 在庫管理プロセス
店舗とECサイトで商品販売を行う。
店舗には売れ筋商品のみ実商品を在庫として保管し、その場で販売を行う。
通常の商品は見本品のみ展示し、注文があった場合はEC販売プロセスで決済と配送を行う。
EC販売プロセスでは外部ECサービスを用い、決済や在庫管理、配送処理を外部ECサービスが
提供するものを利用する。
ただし、店舗顧客には通常の店舗での購入と同様にレジによるオペレーションで販売処理を行う。
## 店舗
Pieris Booksの実店舗。
## ECサイト
Pieris BooksのECサイト。
# Process
## 店舗販売プロセス
店舗で商品販売を行う。
- 店舗
- 店舗顧客
- 店舗販売者
- EC販売プロセス
- 在庫管理プロセス
- 決済サービス
## EC販売プロセス
ECサイトで商品販売を行う。
- 在庫管理プロセス
- 外部ECサービス
## 在庫管理プロセス
実店舗での在庫管理を行う。
- 販売管理者
- 配送サービス
在庫管理の延長で配送サービスへの受け渡しも行う。
# Actor
## 店舗顧客
店舗の利用者。
店舗に在庫がある場合は直接購入することができる。
店舗に在庫がない場合は、見本品を参考に購入し配送で商品を受け取ることができる。
## EC顧客
ECサイトの利用者。
## 外部ECサービス
見本品を購入する際に使用する外部のECサービス。
## 決済サービス
ECまたは店舗での商品販売に使用する決済サービス。
## 配送サービス
ECでの商品販売を依頼する配送サービス。
## 店舗販売者
店舗で商品の販売を行う。
店舗顧客に対して接客を行い、購入時はレジから購入登録を行う。
## 店舗運営者
ビジネス上の店舗運営を行う。
ダッシュボードから各種のメトリクスを確認し、必要に応じてビジネス上の施策を行う。
## 販売管理者
店舗での商品管理などを行う。
## システム管理者
Pieris BooksのITシステムの管理を行う。

Overview

モデルの先頭のセクションはOverviewとなっています。ここにこのモデルの全体情報を記述します。

以下のようにscopeにbusinessが指定されているので、このモデルのスコープがビジネス・スコープであることを示しています。

- scope : business

System

最初のセクションはSystemです。このセクションはビジネス・システムを構成するシステムを記述します。システムはそれぞれ子セクションに記述します。子セクションの名前がシステム名です。

本モデルでは以下の3つのシステムが記述されています。

• Pieris Books
• 店舗
• ECサイト

それぞれのシステムの内容を自然言語(日本語)で記述しています。

システム「Pieris Books」には以下の記述があります。

- 店舗
- ECサイト
- 店舗販売プロセス
- EC販売プロセス
- 在庫管理プロセス

これはPieris Booksの構造を記述した箇所です。

より正確に書く場合は以下のようになります。これはUMLの属性記述の文法に準拠しています。

- <<composition>> 店舗:店舗 [1..*]
- <<composition>> ECサイト:ECサイト 1
- <<participant>> 店舗販売プロセス:店舗販売プロセス
- <<participant>> EC販売プロセス:EC販売プロセス
- <<participant>> 在庫管理プロセス:在庫管理プロセス

ビジネス・オブジェクト間の関係の種類はステレオタイプによって指定します。ターゲットのビジネス・オブジェクトによってデフォルトが変わります。

システムからシステムの場合はcomposition、システムからプロセスの場合はparticipantがデフォルト値です。

Process

次のセクションはProcessです。このセクションではビジネス・プロセスを記述します。

本モデルでは以下の3つのビジネス・プロセスが記述されています。

• 店舗販売プロセス
• EC販売プロセス
• 在庫管理プロセス

店舗販売プロセス

ビジネス・プロセスの店舗販売プロセスでは以下の記述があります。

- 店舗
- 店舗顧客
- 店舗販売者
- EC販売プロセス
- 在庫管理プロセス
- 決済サービス

これらは店舗販売プロセスを構成するビジネス・オブジェクトです。以下の情報が分かります。

• ビジネス・システム「店舗」の提供するサービスを利用する
• 参加するビジネス・アクターは「店舗顧客」、「店舗販売者」
• 連携するビジネス・プロセスは「EC販売プロセス」、「在庫管理プロセス」
• 使用する外部サービスは「決済サービス」

EC販売プロセス

ビジネス・プロセスのEC販売プロセスでは以下の記述があります。

- 在庫管理プロセス
- 外部ECサービス

これらはC販売プロセスを構成するビジネス・オブジェクトです。以下の情報が分かります。

• 連携するビジネス・プロセスは「在庫管理プロセス」
• 使用する外部サービスは「外部ECサービス」

在庫管理プロセス

ビジネス・プロセスの在庫管理プロセスでは以下の記述があります。

- 販売管理者
- 配送サービス

これらは在庫管理プロセスを構成するビジネス・オブジェクトです。以下の情報が分かります。

• 参加するビジネス・アクターは「販売管理者」
• 使用する外部サービスは「配送サービス」

Actor

次のセクションはActorです。このセクションではビジネス・アクターを記述します。

アクターごとにサブセクションを設けます。サブセクション名がアクター名、サブセクションの内容がアクターの説明になります。

本モデルでは以下の9つのビジネス・アクターが記述されています。

• 店舗顧客
• EC顧客
• 外部ECサービス
• 決済サービス
• 配送サービス
• 店舗販売者
• 店舗運営者
• 販売管理者
• システム管理者

アクターについて、構造化した情報を記述できるようになっていますが、現段階では自然言語による説明文のみとなっています。

モデルの完成度

ビジネス・プロセスの定義はより詳細化していくことも可能ですが、今回はITシステムを開発する上での補完的な予備モデルという位置づけなので一旦ここまでにしておきます。

まとめ

今回はコンテキスト図を描くのに十分な情報量を持ったビジネス・モデルをBusiness.mdに記述しました。

次回はBusiness.mdの構造をもう少し掘り下げてみます。

Cozyモデル駆動開発/ビジネス・プロセス

Pieris Books(ブックカフェ併設のセレクトショップ販売店)のシステム開発のプロジェクトを進めています。

現在はビジネス・モデルの作成中で以下のモデルを定義してきました。

• ビジネス・ビジョン
• ビジネス・ゴール
• ビジネス・コンテキスト図

この中でビジネス・コンテキスト図はビジネス・モデルを記述したBusiness.mdから生成するアプローチをとっています。

Business.md

Business.mdはPieris Booksのビジネス・モデルをMarkdown形式で記述したものです。

前回作成したモデルは以下のモデル要素で構成されていました。

System

ビジネス・システム

Process

ビジネス・プロセス

Actor

ビジネス・アクター

ビジネス・コンテキスト図を描くために必要なモデル要素はビジネス・システムとビジネス・アクターですが、これに加えてビジネス・プロセスを記述しています。

ビジネス・プロセスを使用しないモデルも可能ですが、ビジネス・プロセスはビジネス・モデルを束ねる重要なモデル要素なので使ってみました。

今回はこのビジネス・プロセスについて説明します。

ビジネス・プロセス

ビジネス・プロセスはアクティビティを拡張したモデル要素でビジネスの構成を記述します。

ビジネス・モデルの具体的な振る舞いを記述するのではなく、ビジネスの構造を各種ビジネス・オブジェクトとの関係を中心に記述します。

ビジネス・プロセスの基本形は以下になります。

ビジネス・プロセスに対する入力オブジェクトがありビジネス・プロセスが実行された結果、出力オブジェクトが出力されます。

ビジネス・プロセスの実行の過程で様々なビジネス・オブジェクトが関係してきます。

ビジネス・プロセスがどのように実行されるのかは、さらにモデリングを進めて明確にしていきます。

今回の開発はITシステム開発に必要な文脈を確定するためにビジネス・モデルを作成するので、必要最小限のざっくりとしたモデルの作成を目指します。

ビジネス・オブジェクト

ビジネス・プロセスは以下のビジネス・オブジェクトを束ねます。

Goal

ビジネス・ゴール

Actor

ビジネス・アクター

Entity

ビジネス・エンティティ

Event

ビジネス・イベント

Rule

ビジネス・ルール

Information

ビジネス・インフォメーション

Physical

物理的なもの

UseCase

ビジネス・ユースケース

BusinessFlow

ビジネス・フロー

Goal

Goalはビジネス・ゴールを記述します。

Actor

Actorはビジネス・アクターを記述します。

Entity

Entityはビジネス・エンティティを記述します。

Event

Eventはビジネス・イベントを記述します。

Rule

Ruleはビジネス・ルールを記述します。

Information

Informationはビジネス・プロセスの遂行に必要な情報を記述します。

Physical

Informationはビジネス・プロセスの遂行で使用される物理的なものを記述します。

UseCase

UseCaseはビジネス・ユースケースを記述します。

ビジネス・ユースケースはビジネス・システムの利用者などのアクターがビジネス・システムを通して目標を達成する物語を記述します。この物語をビジネス・システムの要求仕様とします。

BusinessFlow

ビジネス・プロセスの具体的な振る舞いはアクティビティ図によるビジネス・フローで記述することができます。

関係

ビジネス・プロセスはビジネス・オブジェクトを入力し、ビジネス・プロセス実行の結果作成されるビジネス・オブジェクトを出力するのが基本構造です。

そして、ビジネス・プロセス実行では様々なビジネス・オブジェクトが関係を持ちます。主に以下のようなビジネス・オブジェクトが使用されます。

archieve

達成

service

サービス

worker

ワーカー

client

クライアント

manager

管理者

maintainer

保守者

control

コントロール

supply

提供

archieve

archieveは達成する関係を記述します。ビジネス・ゴールをビジネス・プロセスに設定する時に使用します。

service

ビジネス・プロセスの外にあるサービス(アクターとしてモデル化)を設定します。

worker

ビジネス・プロセスを遂行する人間(アクターとしてモデル化)を設定します。

client

ビジネス・プロセスを利用する人間や組織(アクターとしてモデル化)を設定します。

manager

ビジネス・プロセスを管理する人間(アクターとしてモデル化)を設定します。

maintainer

ビジネス・プロセスを運用する人間(アクターとしてモデル化)を設定します。

control

ビジネス・プロセスを制御するビジネス・オブジェクトを設定します。

supply

ビジネス・プロセスの遂行に必要なビジネス・オブジェクトを設定します。

まとめ

今回はビジネス・プロセスの概要について説明しました。

次回はビジネス・プロセスの具体例について説明する予定です。

Cozyモデル駆動開発/ビジネス・コンテキスト(2)

Pieris Books(ブックカフェ併設のセレクトショップ販売店)のシステム開発のプロジェクトを進めています。

現在はビジネス・モデルの作成中で以下のモデルを定義してきました。

• ビジネス・ビジョン
• ビジネス・ゴール
• ビジネス・コンテキスト図

この中でビジネス・コンテキスト図はUMLで作成しました。

UMLは強力なモデリング言語ですが、以下の理由によりプレインテキスト・ベースのモデルの方が利便性が高いのではないかと考えています。

• UMLでは自然言語による仕様記述がうまく扱えない
• グラフィカル言語は複雑なモデルの記述が煩雑になる
• Gitによるバージョン管理などテキスト形式向けのサービスが受けられない

Cozyではプレインテキストによって、仕様記述の中にモデルを埋め込む形のモデル記述ようのフォーマットを用意しています。ただし、UMLのメタ言語は強力であり業界標準でもあるのでそのまま踏襲し、必要に応じて必要なスコープ、粒度のUMLを生成する、というアプローチを取っています。

いわゆる文芸的モデリング(literature modeling)です。

Cozyでは、ここまで見てきたようにorg形式で記述したCozyモデルを使用して以下の処理を行うことができます。

• Relational Databaseの入出力
• UML図(クラス図)の生成
• Webでのエンティティの参照更新

このCozyモデルからビジネス・コンテキスト図を生成したいわけです。

Cozyモデル

Pieris Booksプロジェクトを通してCozyの機能とモデルをリブートするにあたり、Cozyモデルの記述形式として広く使われているMarkdownを可能にすることにしました。

今回からMarkdownによるCozyモデルの記述を行っていくことにします。

ビジネス・コンテキスト図を生成するためのCozyモデルですが、ビジネス・モデルをCozyモデルで記述し、ここからビジネス・コンテキスト図を生成することになります。

そのためビジネス・コンテキスト図を出力するのに十分な情報を記述できる必要があります。

ビジネス・モデル

ビジネス・モデルの第一弾を以下のBusiness.mdとして記述しました。

このビジネス・モデルはビジネス・コンテキスト図を出力するのに十分な情報を持っています。

# Business
## System
### Pieris Books
Pieris Booksビジネス。
- composition :: 店舗, ECサイト
- use :: 店舗販売プロセス
- use :: EC販売プロセス
- use :: 在庫管理プロセス
店舗とECサイトで商品販売を行う。
店舗には売れ筋商品のみ実商品を在庫として保管し、その場で販売を行う。
通常の商品は見本品のみ展示し、注文があった場合はEC販売プロセスで決済と配送を行う。
EC販売プロセスでは外部ECサービスを用い、決済や在庫管理、配送処理を外部ECサービスが
提供するものを利用する。
ただし、店舗顧客には通常の店舗での購入と同様にレジによるオペレーションで販売処理を行う。
### 店舗
Pieris Booksの実店舗。
### ECサイト
Pieris BooksのECサイト。
## Process
### 店舗販売プロセス
店舗で商品販売を行う。
- actor :: 店舗顧客
- actor :: 店舗販売者
- use :: 在庫管理プロセス
- use :: 店舗
- use :: EC販売プロセス
- use :: 決済サービス
### EC販売プロセス
ECサイトで商品販売を行う。
- use :: 在庫管理プロセス
- use :: 外部ECサービス
### 在庫管理プロセス
実店舗での在庫管理を行う。
- actor :: 販売管理者
- use :: 配送サービス
在庫管理の延長で配送サービスへの受け渡しも行う。
## Actor
### 店舗顧客
店舗の利用者。
店舗に在庫がある場合は直接購入することができる。
店舗に在庫がない場合は、見本品を参考に購入し配送で商品を受け取ることができる。
### EC顧客
ECサイトの利用者。
### 外部ECサービス
見本品を購入する際に使用する外部のECサービス。
### 決済サービス
ECまたは店舗での商品販売に使用する決済サービス。
### 配送サービス
ECでの商品販売を依頼する配送サービス。
### 店舗販売者
店舗で商品の販売を行う。
店舗顧客に対して接客を行い、購入時はレジから購入登録を行う。
### 店舗運営者
ビジネス上の店舗運営を行う。
ダッシュボードから各種のメトリクスを確認し、必要に応じてビジネス上の施策を行う。
### 販売管理者
店舗での商品管理などを行う。
### システム管理者
Pieris BooksのITシステムの管理を行う。

「#」で始まる行はMarkdownの見出しですが、この見出しを使ってモデルの木構造を表現します。

レベル1見出しが「Business」なので、ビジネス・モデルを記述していることを示しています。

レベル2見出しには以下のものが並んでいます。

• System
• Process
• Actor

これはモデルの種類を示します。Systemはシステム、Processはプロセス、Actorはアクターです。

そして、それぞれの中にあるレベル3見出しはモデル名になります。

各ビジネス・オブジェクトでは各オブジェクト間の関係を以下のフィーチャーで設定しています。

• composition
• use
• actor

compositionはUMLの合成(composition)を示します。

useはUMLの使用(use dependency)を示します。

actorはシステムやプロセスを使用するアクターを示します。

ビジネス・モデル

Business.mdでは以下の3つのモデル要素を記述しました。

• システム
• プロセス
• アクター

それぞれについてみていきましょう。

システム

「システム」はビジネス・システムを示します。

以下の3つを定義しました。

• Pieris Books
• 店舗
• ECサイト

Pieris Booksではcompositionによって店舗とECサイトを保持していることを定義しています。このため、店舗とECサイトはPieris Booksの中ではサブシステムということになります。

プロセス

「プロセス」はビジネス・プロセスを示します。

システム開発用に作成するビジネス・モデルではビジネス・プロセスを軸にモデルを記述すると適切な抽象度でモデルを記述できます。

ビジネス・プロセスは以下の3つを定義しました。

• 店舗販売プロセス
• EC販売プロセス
• 在庫管理プロセス

ビジネス・プロセスは次回に説明する予定です。

アクター

「アクター」はビジネス・アクターを示します。ビジネス・システムの外部に居て、ビジネス・システムと対話を行うビジネス・オブジェクトです。

Business.mdでは以下のビジネス・アクターを定義しました。

• 店舗顧客
• EC顧客
• 外部ECサービス
• 決済サービス
• 配送サービス
• 店舗販売者
• 店舗運営者
• 販売管理者
• システム管理者

ビジネス・コンテキスト図

ビジネス・コンテキスト図は、ビジネスを構成するシステムの境界、システム間の関係、とアクターとの関係をざっくり可視化します。

このためBusiness.mdに記述した内容をUML化すると以下になります。

前回の図に対して以下の変更を行っています。

• 名前変更：EC利用者→EC顧客, 店舗利用者→店舗顧客
• 名前変更：EC→ECシステム
• 追加：店舗販売者, 外部ECサービス
• 在庫管理サブシステムは一旦省略

Cozyでは、まだMarkdownからビジネス・コンテキスト図を出力する機能はありませんが、本記事の内容をベースに実装していく予定です。

まとめ

今回はビジネス・コンテキスト図の出力をきっかけとしてビジネス・モデルをCozyフォーマットで定義しました。

次回以降このモデルを拡張する形でITシステムの開発までつなげていくことになります。

Cozyモデル駆動開発/ビジネス・コンテキスト

「ブックカフェ併設のセレクトショップ販売店」のシステム開発のプロジェクトを進めています。

現在はビジネス・モデルの作成中で以下のモデルを定義してきました。

• ビジネス・ビジョン
• ビジネス・ゴール

今回はビジネス・コンテキスト図を作成します。

「ブックカフェ併設のセレクトショップ販売店」の名前をPieris Booksとします。

ビジネス・コンテキスト図

Pieris Booksのビジネス文脈を以下の観点からビジネス・コンテキスト図で記述します。

• ビジネスの境界を定める
• サービス利用者
• サービス提供者
• 使用する外部サービス

このビジネス・コンテキスト図はシステム開発のためのビジネス文脈を明確にするために、ビジネス・オーナーにヒアリングしながら開発側で作成しものです。抜けなどがある可能性はありますが、まずは起点となる土台を明確化する目的です。開発中に抜けなどが分かれば、随時追加していく想定です。

この結果作成したビジネス・コンテキスト図は以下になります。

ビジネス境界

ビジネス境界として、ビジネス・システムPierisBooksを作成しました。ステレオタイプにbusinessを設定しています。

ビジネス・システムPierisBooks内に以下の3つのビジネス・サブシステムを定義しました。

• EC
• 店舗
• 在庫管理

PierisBooksに関係する各種アクターを定義しています。

サービス利用者

PierisBooksのサービス利用者は以下の2つのアクターです。

• EC利用者
• 店舗利用者

利用者に対してECの口と実店舗の口を持っているので、それぞれの利用者をアクターとして記述しました。

EC利用者と店舗利用者が同じケースもあると思いますが、そのあたりのモデリングは後のフェーズで行う予定です。ここでは、ビジネス・システムの文脈がざっくりつかむことを優先しています。

サービス提供者

PierisBooksのサービス提供者は以下の3つのアクターです。

• 店舗運営者
• 販売管理者
• システム管理者

PierisBooksの運営・管理を行うロールですが、ビジネスのレイヤーによってさまざまなロールがあります。

店舗運営者はビジネス上の店舗運営を行います。販売管理者は商品の管理などを行います。

システム管理者はビジネスとは距離をおいた形でITシステムの管理を行います。

使用する外部サービス

PierisBooksが使用する外部サービスは以下の3つのアクターとしてモデル化しました。

• 外部ECサービス
• 決済サービス
• 配送サービス

PierisBooksでは商品のショーケースとしての運営を行います。このため利用者が商品の購入を考えた場合には、PierisBooksのシステムを経由して外部ECサービスに販売・配送を依頼します。

決済サービスは店舗に在庫があった場合のECや店舗での購入で使用する想定です。

配送サービスは店舗在庫の配送を依頼します。

外部ECサービスと決済サービス、配送サービスは一部機能が重なるのでケース・バイ・ケースで使い分けることになるでしょう。このあたりの具体的な処理は今後のモデリングで考えていくことにします。

用語集

ビジネス・コンテキスト図に登場する用語をまとめて用語集を作成します。

種別には以下のものが入ります。

BS

Business System

BA

Business Actor

用語	種別	意味
Pieris Books	BS	Pieris Booksビジネス全体
EC	BS	Pieris BooksのEC機能
店舗	BS	Pieris Booksの実店舗
在庫管理	BS	実店舗での在庫管理
EC利用者	BA	ECサイトの利用者
店舗利用者	BA	店舗の利用者
外部ECサービス	BA	見本品を購入する際に使用する外部のECサービス
決済サービス	BA	ECまたは店舗での商品販売に使用する決済サービス
配送サービス	BA	ECでの商品販売を依頼する配送サービス
店舗運営者	BA	ビジネス上の店舗運営を行う
販売管理者	BA	店舗での商品管理などを行う
システム管理者	BA	Pieris BooksのITシステムの管理を行う

まとめ

今回はビジネス・コンテキスト図のたたき台を作成しました。

次回は、ビジネス・コンテキストをCozyで取り扱う方法について考えます。

Cozyモデル駆動開発/ビジネス・ゴール

前回はプロジェクトのターゲットとなるビジネスとして「ブックカフェ併設のセレクトショップ販売店」そのビジネス・ビジョンを定義しました。

今回はビジネス・ゴールを定義します。

背景

ビジネス・ゴールを考える上で難しいのが本開発におけるビジネス・オーナーの立ち位置です。

本開発のビジネス・オーナーだあるブックカフェオーナーはITには疎く、本開発ではA君がヒアリングしながらビジネス・モデルを作成しています。このため、大企業のCEOが作成するような詳細なビジネス・モデルを作成して、これをベースにソフトウェア開発を進めるということは考えられません。

ここではソフトウェア開発に必要な指針レベルのざっくりしたものを、あまり時間をかけずに作成する 方針にしましょう。

また現段階では、ソフトウェア開発のフェーズはインセプション・フェーズなので、まずはたたき台レベルのビジネス・モデルにしておいて先を進めることを優先するのも合理的です。

アプローチ

前回挙げた開発システム概要をまとめると以下になります。

• 新刊・古本の販売も行うブックカフェだったが、新しくアクセサリーや日用品のセレクト商品販売を併設することになった
• このセレクト商品は見本品の展示を基本と考えており、見本品に対してECでオーダをする方式
• 見本品はECサイトでの販売も行う
• 見本品中心ではあるが小型の品は少量の在庫を持って即時販売も可能

この情報を元にビジネス・ゴールを考えていきましょう。

KGI/KPI

ビジネス・ゴールを考える上で重要な概念がKGIとKPIです。

• KGI : Key Goal Indicator
• KPI : Key Performance Indicator

KGIはビジネス上のゴールとなる指標で、売上高や粗利益といった会計などを中心とした目標を使うのが一般的です。

ただ、売上高や粗利益といった大きな枠組みの目標では、日々のビジネス活動に直接当てはめることは難しいので、中間目標としてビジネスのパフォーマンスの指標であるKPIを導入します。

つまり一つのKGIに対して、KGIを達成するための中間目標であるKPIが複数存在するという親子関係になります。

本来はこのKGI/KPIをビジネス・ゴールに盛り込みたいところです。

ただ、ビジネス・オーナーはもちろん最終的な収益には関心がありますが、KGIやKPIといったような指標化にはあまり興味がないようです。まだインセプション・フェーズでもあるので、システムが動作して大まかな状況が見えてくるまでKGI/KPIについては保留にすることにします。

ビジネス・ゴール

今回は作業を進めるためにざっくりという方針で以下のビジネス・ゴールにしてみました。

- ブックカフェにセレクト商品販売を併設
- セレクト商品は(1)店舗在庫あるものは直接販売、(2)店舗在庫のないものはECで販売、(3)WebのECサイトでEC販売

ビジネス・ゴールはMarkdown形式で記述しています。前回挙げた開発システム概要をまとめたレベルのものですが、まずはここからざっくり始めたいと思います。

保存

ビジネス・ゴールは src/main/cozy/business 配下に goal.md として格納します。

まとめ

今回は開発システム概要を元にビジネス・ゴールを作成しました。本来はビジネス・オーナーが作成するのが理想ですが、システム開発を進めるためにビジネス・オーナーにヒアリングしながら開発側で作成したものになっています。

次回もビジネス・モデルの作成を続けます。