2024年9月30日月曜日

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の構造をもう少し掘り下げてみます。

2024年8月31日土曜日

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

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

まとめ

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

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

2024年7月31日水曜日

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システムの開発までつなげていくことになります。

2024年6月30日日曜日

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 BooksBSPieris Booksビジネス全体
ECBSPieris BooksのEC機能
店舗BSPieris Booksの実店舗
在庫管理BS実店舗での在庫管理
EC利用者BAECサイトの利用者
店舗利用者BA店舗の利用者
外部ECサービスBA見本品を購入する際に使用する外部のECサービス
決済サービスBAECまたは店舗での商品販売に使用する決済サービス
配送サービスBAECでの商品販売を依頼する配送サービス
店舗運営者BAビジネス上の店舗運営を行う
販売管理者BA店舗での商品管理などを行う
システム管理者BAPieris BooksのITシステムの管理を行う

まとめ

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

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

2024年5月31日金曜日

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 として格納します。

まとめ

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

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

2024年4月30日火曜日

Cozyモデル駆動開発/ビジネス・ビジョン

ビジネスで必要とされるソフトウェア・システムの開発を開始するにあたって、ソフトウェア・システムを利用するビジネス側の文脈を明確にしておく必要があります。

ビジネス側の文脈のモデルとしてビジネス・モデルを作成しますが、今回はその最初としてビジネス・ビジョンを作成します。

インセプション・フェーズ

UP(Unified Process)にならってソフトウェア開発のフェーズを以下の4つと考えることにします。

  • インセプション・フェーズ (Inception phase)
  • エラボレーション・フェーズ (Elaboration phase)
  • コンストラクション・フェーズ (Construction phase)
  • トランジッション・フェーズ (Transition phase)

インセプション・フェーズは、システム開発の方向性を確定するためのフェーズで、仮設に基づく実装を行いその結果を評価します。

エラボレーション・フェーズでは、複数のイテレーションで開発を勧めながらシステムの最終型に向けて必要な技術要素を決めていきます。

これらの作業の結果を受けて、コンストラクション・フェーズでは具体的な肉付けを行っていきます。

一通り開発が終了した後、トランジッション・フェーズではプロジェクトのクロージングや保守体制への以降を行います。

今回からプロジェクトの立ち上げとなるインセプション・フェーズの活動を進めていきます。

開発システムの概要

今回の開発ターゲットはブック・カフェの販売システムです。

このブック・カフェでは、新刊・古本などの書籍に加えてアクセサリーや日用品などのセレクト商品の販売をしています。

もともと新刊・古本の販売も行うブックカフェでしたが、新しくアクセサリーや日用品のセレクト商品販売を併設することにしました。

このセレクト商品は見本品の展示を基本と考えており、見本品に対してECでオーダをする方式を主に考えています。また見本品はECサイトでの販売も行います。

とはいえ、見本品中心ではありますが小型の品は少量の在庫を持って即時販売も可能にしたいと考えています。

開発体制

以下の開発体制を想定しています。

  • フロントエンド開発者 1人
  • バックエンド開発者 1人
  • ブックカフェオーナー 1人 (発注者)

ブックカフェオーナーのX氏から個人でシステム開発を受注したA君がバックエンド開発を行い、フロントエンドエンジニアのB君にUI開発を依頼するという体制です。

ブックカフェオーナーはITには疎いので、A君がヒヤリングを行いながら自前でビジネス・モデルと要求モデルを作成していく想定です。

フォーマット

ビジョンの記述には以下のフォーマットを使用することにします。

FOR ターゲット顧客
WHO 利用者
THE 製品名 is a 製品カテゴリ
THAT キーとなるメリット、製品を買う理由
UNLIKE 競合商品
OUR PRODUCT 競合商品との違い

このフォーマットを使ってビジネス・モデルのビジョンとシステムの要求モデルのビジョンの2種類を作成していきます。

ビジネス・ビジョン

ビジネス・システムのモデルでは、ビジネスそのもののビジョンをビジネス・ビジョンとして定めます。

X氏と話し合って以下のビジネス・ビジョンを定義しました。X氏はこういったドキュメントの作成に乗り気ではありませんので、ソフトウェア開発側で意識するビジョンとしてメモ的に作成したものです。今後の開発で随時調整していくことを想定しています。

FOR セレクトショップ販売店
WHO 本を読みながらカフェでのんびりしたい人
THE BCwSG is a ブックカフェ併設のセレクトショップ
THAT カフェの利用者にセレクト商品の紹介と販売を行うことができる
UNLIKE 通常のセレクト・ショップ
OUR PRODUCT ブック・カフェを併設することで商品の販売機会を増やすことができる

まずブックカフェ併設のセレクトショップの名前を仮にBCwSG(Book Cafe With Select Goods)と決めました。

ターゲットとなる利用者を「本を読みながらカフェでのんびりしたい人」とし、セレクトショップ販売店に「カフェの利用者にセレクト商品の紹介と販売を行うことができる」ことをビジネス上の価値としました。

これが通常のセレクト・ショップに対するアドバンテージと考えています。

保存

ビジネス・ビジョンは src/main/cozy/business 配下に vision.txt として格納します。

まとめ

今回からブックカフェ併設のセレクトショップBCwSGを題材に具体的なモデリングを進めていきます。

インセプション・フェーズの最初のモデルとしてビジネス・ビジョンを作成しました。

モデリングを行いながら各作業分野で定義していくモデルを明らかにしていきたいと思います。

2024年3月31日日曜日

Cozyモデル駆動開発/成果物の管理

今回はCozyモデル駆動開発で作成する成果物の管理方法について考えてみます。

ファイル構成

図はCozyモデル駆動開発におけるプロジェクトのファイル構成の案です。

プログラムはScalaによる記述を想定しているのでsbtのファイル構成を踏襲しています。

srcディレクトリの配下に以下のディレクトリを配置します。

main
メインのソースコード
test
テストのソースコード

さらにmain配下に以下のディレクトリ配置します。

cozy
Cozyモデル
scala
Scalaプログラム

以下でそれぞれの内容について説明します。

Cozyモデル

src/main/cozyディレクトリにCozyモデルを格納します。

Cozyでは、Cozyモデルと後述のScalaモデルの両方のコンテンツの情報を統合してプロジェクトのCozyモデルを作成します。

CozyモデルはScalaモデルで記述しきれない仕様をCozy形式で記述します。

cozyディレクトリには以下のディレクトリを配置します。それぞれのディレクトリが対応するモデルを格納します。

  • business : ビジネス・モデル
  • requirement : 要求モデル
  • analysis : 分析モデル
  • design : 設計モデル

ビジネス・モデル

businessディレクトリにはビジネス・モデルを格納します。

ソフトウェア開発におけるビジネス・モデルでは、開発するソフトウェアのビジネス上の位置づけや用途などのビジネス文脈を記述します。

ビジネス・システムを駆動するビジネス・モデルを作成し、これをソフトウェア開発の入力にするのが理想ですが、そのような本格的なアプローチが取れない場合はソフトウェア開発に必要な範囲でビジネス文脈を整理するのがよいでしょう。

前回はEssenseのアルファとしてビジネス・システム・アルファとして定義しました。

記述するモデルの候補としては以下のものが考えられます。

  • ビジョン
  • ゴール
  • ビジネス・コンテキスト
  • ビジネス・ユースケース
  • ドメイン・モデル

また、ビジネスの計測と結果のフィードバック・ループに対応するため以下のモデルについても扱っていく予定です。

  • KGI(Key Goal Indicator)
  • KPI(Key Performance Indicator)

モデルは基本的には通常ファイルに自然言語のテキストとして記述する形になりますが、コンテキスト・モデルは図として記述するのが適切なので、これをどのように記述するのかは工夫が必要そうです。

要求

requirementディレクトリには要求モデルを格納します。

記述するモデルの候補としては以下のものが考えられます。

  • ビジョン
  • ゴール
  • コンテキスト・モデル
  • ユースケース

ビジョン、ゴール、コンテキスト・モデル、ユースケースはビジネス・モデルと同じ項目ですが、開発対象となるソフトウェア・システムのビジョン、ゴール、コンテキスト・モデル、ユースケースという点が異なります。

またビジネス・モデルで定義したKGIやKPIも、必要に応じて要求モデルに引き継がれるでしょう。

モデルの記述方法はビジネス・モデルと同様に通常ファイルに自然言語で記述するものが中心となります。

分析

analysisディレクトリには分析モデルを格納します。

作業分野「分析」と「設計」はEssense標準ではShape the Systemアクティビティ空間に所属するアクティビティということになるでしょう。

分析はPIM(Platform Independent Model)を、設計はPSM(Platform Specific Model)を記述するというモデルの抽象度に違いがあります。

しかし、実装主導の開発では開発ではPIMを意識しつつPSM主体の設計になると思うので、実務的には要求から直接設計に進み、必要に応じて分析も行う、というところが実際のところかもしれません。この点も加味して分析について検討していく予定です。

設計

designディレクトリには設計モデルを格納します。

設計モデルでは、実装に直結したモデルを構築します。

設計モデルを考える上で重要なのはプログラム自身が設計になっているといる点です。特にオブジェクト指向プログラミングで記述した場合には、オブジェクト・モデルとのインピーダンス・ミスマッチが低いので、場合によってはそのままモデルと考えてもよいかもしれません。

しかし、プログラミングの場合はプログラム動作上のさまざまな処理を追加していくため、抽象的なモデルとずれてきたり、境界が曖昧になってきます。この問題に対応するためアノテーションの仕組みを使ってモデルとして扱う箇所とモデルとして位置づけを記述していくことになるでしょう。また、JavaやScalaではプログラム内に仕様を自然言語で記述する仕組みがあるので、これを用いてより詳細にモデルの情報を記述することができます。

すべてのモデルをアノテーション付きプログラムで記述することはできないので、この記述できない部分は別の形でモデルを記述することになります。

一つはドメイン・モデルなど定型化して形式で記述したモデルです。

このモデルからはインタープリタで直接実行したり、実装を自動生成することができます。

最後にアーキテクチャ全体の情報やコンポーネントやクラスなどの仕様に関して自然言語による記述を行う場合があります。このような記述は通常ファイルに記述した上でプログラム・モデルと統合して設計モデルを組み上げていくことになるでしょう。

Scalaプログラム

本シリーズではプログラミング言語にScalaを用います。

Scalaプログラムとして開発するソフトウェアの本体のプログラムとテスト・プログラムを作成します。

本体

開発ターゲットの本体のScalaプログラムはsrc/main/scalaディレクトリに格納します。

前述したようにScalaプログラムにアノテーションとScaladocを併用することで、モデルとして扱うことができます。

プログラミング言語としてScalaを使用するので、Scaladoc形式でインタフェース仕様を記述します。

Cozyは、モデル、プログラム、テスト・ケースからそれぞれに記述された仕様を集め、マージしたものをプロジェクトの仕様として統合します。

テスト

Scalaによるテスト・プログラムはsrc/test/scalaディレクトリに格納します。

Cozyモデル駆動開発ではTDD(Test-Driven Development)、BDD(Behavior-Driven Development)でテストを動く仕様(executable specification)として扱っていきます。

これはテストを要求仕様、コンポーネント仕様として作成して活用していくという意図があります。

この場合は、自然言語で記述した要求モデルとどのように連携していくのかがポイントとなるでしょう。

TDD, BDDの基盤としてscalatestを使用する想定です。

まとめ

今回はCozyモデル駆動開発で作成する成果物の管理方法について考えてみました。

次回はビジネス・モデルについて具体的に考えていく予定です。