rdra4越境アジャイル

バックエンドに切り込む

既存システムの全体像を把握する

わたしは…

• ㈱バリューソース– 代表取締役 社長– 神崎 善司– zkanzaki@vsa.co.jp– 要件定義の散歩道：https://www.facebook.com/youkennotsubo– twitter：@zenzengood

• 要件定義手法の開発

– RDRA Relationship driven requirement analysis

• 普段は– システム企画・要件定義などの支援– セミナー開催（要件定義、モデリング）– 要件定義用ツールの開発

• 要件定義との関係は– 25年ほど前からオブジェクト指向を中心にシステム開発全般に関わる– 20年ほど前から上流工程を中心としたセミナー・コンサルティングを行う– その間一貫してモデル中心で行う– その経験を活かしてモデルを使った要件定義の手法をRDRAとしてまとめる

システム価値

システム外部環境 システム境界 システム

コンテキスト

利用シーン

業務

イベント

ユースケース

概念

画面・帳表

機能

ドメイン

データ

要求

機能複合モデル

利用シーン＆ＵＣ

業務＆ＵＣ

状態

ＵＣ：ユーケース

ＵＣ＆画面

ＵＣ＆機能

RDRAとは

プロトコル

依存

画面

ユースケース機能

データ・ドメイン

外部システムイベント

要求

バックエンドシステム

サービスフロント

システムの地図を作る

バックエンドシステム

何をどう表現するどのように作成する

システムの地図を作る

何が

どこにある

地図は何を表している

区役所 XXホテル病院

駅

何が

役割の名前で対象を理解する

どこにあり

北

南西

東

道路を中心に住所を表す

一方通行

指定方向外進行禁止

目的地に進むためには

道路のルールに従う

ローカルなルールも

出典livedoor.blogimg.jp

システムに置き換えると

バックエンドシステム

＜何が＞

入出力が

＜どこにあるのか＞どのサブシステムのどのユースケース（画

面）

入出力 サブシステム

分類

UC UC UC UC

UC

UC

UC

UCUC

UC

UC

UC

UC

システムに切り込むには

バックエンドシステム

変更機能追加

ビジネス要求

影響範囲をどう見つけるのか

ルール

影響範囲

影響範囲

ルールの可視化

データ

影響範囲

影響範囲

機能

機能

機能

機能

機能 機能

機能

機能とデータの関係を可視化する

何がどこに

ルールが見えない

システム境界 システム

UC 機能

ビジネスルールの表現

システム

入出力

構造のルール

振舞のルール状態の変化

＜式＞金額＝単価＊数量

式、表形式のルール

状態

１ ＊

情報の時系列の変化

コスト構造 収益構造

パートナー

顧客セグメン

ト

価値提案リソース

主要活動

チャネル

顧客との関係

概念

取引先 商品 取引

組合せによる特報を分析

ビジネスモデル分析

リッチピクチャ

会社顧客

デリバリ

パートナー商品

商品

サービス

パートナー

サービス営業

購買

物流

取引

バリエーション分析

ビジネスルールの洗い出し

ビジネスルール

ビジネスモデルキャンバス

ビジネスルールがロジックに埋め込まれる

データ

機能

機能

機能

機能

機能 機能

機能

＜式＞金額＝単価＊数量

状態

１ ＊

振舞のルール

構造のルール

式・条件

システム価値

システム外部環境 システム境界 システム

コンテキスト

利用シーン

業務

イベント

ユースケース

概念

画面・帳表

機能

ドメイン

データ

要求

機能複合モデル

利用シーン＆ＵＣ

業務＆ＵＣ

ＵＣ：ユーケース

ＵＣ＆画面

ＵＣ＆機能

システム地図の構成要素

プロトコル

既存システムを調べ方

まともなドキュメントもないし、全体を理解している人もいない

プログラム単位のドキュメント化

• 混沌とした一枚岩のシステムをプログラム単位で調べてもシステム化の判断には役に立たない

Prg

既存システムは…

• 様々な制約によってプログラムが混沌としている

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

既存システムをわかりやすく整理する

モデル入力情報タイミング

機能

機能

機能

機能

機能

機能

出力情報タイミング

既存システム

Prg

物理制約 時間制約 開発時制約

入力情報タイミング

出力情報タイミング

現実とつながりながら現実の混沌に影響されずに整理する

システム境界とデータを一致させる

既存システムの情報はあまりないと言っても

• たいてい以下のドキュメントはある– テーブル定義書（実DBのスキーマ定義）– 電文レイアウト– ファイル交換のファイル定義書

• 保守されているシステムについては

– データとシステム境界の情報はある

システム境界

システムをよく知らないといっても

• この機能はこういうことを行っている– ここでこうするとあそこに影響する– こうしたいときはここをこうすればいんだよ

• 制約の説明– ここは時間がなくてこうしちゃったんだ！– この時代はこういうルールだったんだ

具体的な分析法

分析

分析方針

• 集めやすい情報から集める

• 抜けたピースを探す

• 集めた情報の特徴から切り込む– 分類する– 関係をつかむ

システム境界とデータを捉える

画面

システム

受信

送信

DB

File

送信

受信

帳票

データ交換

データ交換

入出力画面 稼働しているシステム帳票 〃通信 電文レイアウト

データ交換File FileレイアウトDB テーブル定義書

データテーブル定義書ファイルレイアウト

入出力をイベントで統一的に扱う

• システム境界をイベントとして扱う

– ポイント

•入出力は実体に合わす

画面

受信

送信

DB

File

受信

送信

システム画面

受信

送信イベント

状態の遷移として整理

ステートマシン

状態を振る舞いのルールとする

A画面

システム

受信

送信

DB

A_File

送信

受信受信

送信

解約待ち

開始済み開始前A画面

B画面

A_File

B_File

状態 状態XXX / YY機能

状態の洗い出し• 画面上の情報• オペレータが認識しているもの状態• テーブル上の区分やフラグなど• テーブルの関係• ビジネス上の概念

CRUD

既存のプログラムに影響されずに機能を記述する

機能

機能

機能

機能

画面

システム

受信

送信

File

送信

受信受信

送信

機能

<CU><U>

<R>

<R>

<RD>

イベント、データ、ステートマシンを元に機能を洗い出す

記述のパターン

定周期日

YY機能送信A機能

システム 受信 機能

通信

送信

機能

システム

画面 機能 機能 FileFile交換入

機能File交換出

電文

File

電文

Fileによるデータ交換画面処理

定周期

機能DB交換入

機能DB交換出

DBによるデータ交換データ

データ

画面・データ・機能・バッチの整理

• 画面– 主要な画面を洗い出す– 画面の内容から状態を洗い出す– サブシステムに分類する

• データ– ER図の作成： 主要なテーブルを識別– サブシステムに分類する

• 機能– イベントに対応付ける（ステートマシン）– バッチに対応付ける

• バッチの種類– 本来のバッチ処理– 定周期処理 ⇒ イベント– 入出力のバッチ ⇒ イベント

• File交換、DB経由

– ポイントデータ交換の処理とバッチ処理を切り分ける

隠れた情報をあぶり出す

• 隠れた情報– 複数の意味をもつデータ

• 意味の違うものを一つのレイアウトで扱う

– 複数のイベントを一度に扱う• タイミングが隠れる

システム情報

モデルイメージ 軽め

モデルイメージ 重め

画面・帳票モデル イベントモデル

プロトコルモデル

データモデル 機能複合モデル（CRUD）

まとめ

モデル

機能

機能

機能

機能

機能

機能

既存システム

Prg

Prg

Prg

システム境界とデータを一致させる

画面機能 データ・

ドメイン

外部システムイベント

状態