as-isシステム分析は入出力から始めよ

As-Is ステム分析は入出力から始めよ

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

株式会社バリューソース 神崎善司

わたしは

㈱バリューソース 代表取締役 社長

神崎 善司

zkanzaki@vsa.co.jp

はてな：good_way

twitter:zenzengood

普段は 要件定義のコンサルテーション

オブジェクト指向やUMLのセミナー開催

要件定義ツール「要件のツボ」開発

経験 ２０年ほど前からオブジェクト指向を中心にシステム開発全般のコンサルティングを行う

１０年ほど前から上流工程を中心としたコンサルティングを行う

その経験を活かしてモデルを使った要件定義の手法をまとめる

大規模システムの保守性向上のための既存システムの分析を行う

要件のツボ

http://www.vsa.co.jp/kaname

既存システムを取り巻く状況は

ドキュメントがない

ドキュメントは最新ではない

ソースが最新かどうか分からない

さまざまな言語で開発されている

聞いたことがない言語である

アーキテクチャが明確ではない

システムの利用者 普段使っている機能だけ知っている

なんでこうなっているのか分からない

問題のはじまり

新システムの企画段階で

今のうちに既存のシステムを調べよう

システムのドキュメントを再度作成する！

よく起こること

システムのドキュメントを整理する → プログラム単位のドキュメント

数千本のプログラムについて細かい仕様を調べる

複数の担当者が担当を割り振られ黙々と作る

キングファイルが積み上がる

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

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

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

PrgPrg

Prg

Prg

そんな現場では

何を書くんですか？

どの範囲まで書くんですか？

どの粒度で書くんですか？

一ヶ月後

いつまでやるんですか？

やれと言われればやりますが。 ？？？？？？

目的が曖昧なままスタートしたので終わるタイミングが分からない

そして…

As-Isの資料作成がいつのまにかTo-Beの資料作成に

この部分は君が詳しいから次期システムもここは君が担当してくれ

細かいことは分かるけど、次期システムについて判断出来ない

結局方向性のない焼き直しシステムができあがる

データ構造の見直しは行われず 保守性はいっこうに改善しない

迷信

保守中のバグは新システムでは再現させたくない 何でシステムで同じようなバグが出るの？

既存のシステムとほとんど同じだから… 「ほとんど」とはどこですか？ ？？？？？

「細かいことを知っている」は「システムをよく知っている」ことにならない 結局システムは何をしているのですか？ ？？？？？

ほとんど同じ

イメージ 実際は

どうすりゃいい

何を調べたいのか

現在のシステムはこうなっている

次のシステムの方向性はこうだ！

だから次のシステムはこうする

必要なことを判断出来る情報が重要！

判断するためには何を何のためにが分かる必要

がある

つまり つじつまのあう説明ができる

目指すべきは

プログラムに左右されずにシステムが何を行っているかを明らかにする

システムにとって大事なことは

何ができればいいのか

どう整合しているのか 主要な機能は？

主要な情報は？

機能と情報の関係は？

そこで…

本質を捉えるためにモデリングだ

えっ モデリング ほんとか？

既存のシステムを調べているんだ

モデルと既存のシステムの関係は？

既存のシステムは綺麗ではない

綺麗なモデルは現実と離れていく

綺麗なモデルは結局何を表しているんだ！

どうモデルを活かす

現実とつながりながら現実の混沌に影

響されずに整理する

そのためには…

前提

細かなルールにこだわらなくていい

既存システムの仕組みは無視していい

既存のシステムとは

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

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

何を捉える

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

だから～ 情報のない中でどうやってやるんですか？

ドキュメントがないと言っても

たいてい以下のドキュメントはある テーブル定義書

電文レイアウト

ファイル交換のファイル定義書

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

データと他システムにつながる部分の情報はある

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

この機能はこういうことを行っている

ここでこうするとあそこに影響する

こうしたいときはここをこうすればいんだよ

制約の説明

ここは時間がなくてこうしちゃったんだ！

この時代はこういうルールだったんだ

具体的にどうするの？

分析

分析方針

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

抜けたピースを探す

集めた情報の特徴から切り込む

分類する

関係をつかむ

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

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

機能

機能

機能

機能

機能

機能

出力情報タイミング

既存システム

Prg

Prg

Prg

Prg

Prg

Prg

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

Prg

Prg

Prg

Prg

Prg

Prg

システム境界のレベルで一致させる

入力情報タイミング

出力情報タイミング

認識する情報

入出力

画面 稼働しているシステム

帳票 〃

通信 電文レイアウト

データ交換

File Fileレイアウト

DB テーブル定義書

データ

テーブル定義書

ファイルレイアウト

システムの入出力を捉える

データ集約的なシステム

入れポン 出しポン

入力と出力を把握できればいい

システム境界を捉える

画面

システム

受信

送信

DB

File

送信

受信

帳票

データ交換

データ交換

通信

システムが関心をもつ状態を捉える

状態監視的なシステム 監視対象があって今を意識 一連の手続きの管理 プロセス管理、ロングトランザクション管

理

状態としてルールを整理

ユーザが認識している状態を把握するために 画面上の情報 オペレータが画面の振る舞いとして認識しているもの テーブル上の区分やフラグなど テーブルの関係 ビジネス上の概念

状態の遷移として整理

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

A画面

システム

受信

送信

DB

A_File送信

受信受信

送信

解約待ち

開始済み開始前A画面

B画面

A_File

B_File

状態 状態XXX / YY機能

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

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

ポイント

画面やデータ交換は実体に合わす

画面

受信

送信

DB

File

受信

送信

システム画面

受信

送信イベント

隠れた情報をあぶり出す

隠れた情報

複数の意味をもつデータ

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

複数のイベントを一度に扱う

タイミングが隠れる

システム情報

システム

CRUD

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

機能

機能

機能

機能

画面

システム

受信

送信

File

送信

受信受信

送信

機能

<CU><U>

<R>

<R>

<RD>

データと機能の整理

データ ほとんどの場合DBのテーブル整理

ER図の作成： 主要なテーブルを識別

サブシステムに分類する

機能 イベントに対応付ける

バッチに対応付ける 機能イベント

バッチを洗い出す

バッチの種類

定期監視

本来のバッチ処理

入出力のバッチ

File交換

DB経由

ポイント

データ交換の処理とバッチ処理を切り分ける

記述のパターン

定周期日

YY機能送信A機能

システム 受信 機能

通信

送信

機能

システム

画面 機能 機能 FileFile交換入

機能File交換出

電文

File

電文

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

定周期

機能DB交換入

機能DB交換出

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

データ

システムを適切な大きさに分割する

事実

ある閾値を境に開発費は急激に上昇する

システム開発に関わる変化を止めることはできない

いかに分けるか

データ中心にわける

機能を中心にわける

業務を中心にわける

綺麗に分けようとしない

その企業の文化に併せて分割する

規模１０ 規模２０

重複５

規模

工数コスト

５ １０ １５ ２０ ２５

規模３０

５

１０

１５

２０

２５３０４０４５

規模２５のシステムを分けると重複分を含めて規模３０に増える。しかし、それが閾値よりも低ければ重複分５は無視できる

閾値

サブシステムに分類する

機能

機能

機能

機能

システム

受信

送信

File

送信

受信受信

送信

機能

画面

分け方の例

データ中心

データを役割から分ける

業務別にデータを分ける

データに機能を紐付け分類する

機能中心

機能の役割から分ける

業務別に機能を分ける

機能にデータを紐付け分類する 暗黙的な分類を引き出す制約を意識する

分けやすいところから分ける

その分類に他のものを寄せる

特徴をつかみ方針を決める

掘り起し岩を砕く

特徴をつかみそこから切り込む

トップダウンアプローチ ビジネスモデルから把握する

会社の外の登場人物を整理する 会社の中の登場人物を整理する ビジネスモデルとしての分類を求める

ボトムアップアプローチ CRUD表

正確なCRUD表ではなく妥当なコストで把握できる精度のものを目指す

マクロにながめる プログラムの分類を見直す テーブルの分類を見直す

トップダウンアプローチ

会社登場人物

登場人物

登場人物

登場人物

登場人物

登場人物

会社

部署

部署

部署

部署

会社外の登場人物

会社内の登場人物

・切り込めるところから切り込む・いろいろな手を試す

ボトムアップアプローチCRUD表 テーブル

プログラム

分類をモデルとあわす

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

コンテキスト

利用シーン

業務

イベント

プロトコル

ユースケース

概念

画面・帳表

機能

ドメイン

データ

要求

機能複合モデル

利用シーン＆ＵＣ

業務＆ＵＣ

ＵＣ：ユーケース

ＵＣ＆画面

ＵＣ＆機能

RDRA（リレーションシップ駆動要件分析）全体像

①②

どう管理するのか

コンテキスト

ドメインモデル

システム論理構成

サブシステム

パッケージA

画面・帳票モデル

パッケージB

イベントモデル

データモデル

機能複合モデル

プロトコルモデル

まとめ

システム境界とデータで合わせる

特徴をつかみ洗練化する

分類し整理する

得られる情報から切り口を探し整理する

モデル

機能

機能

機能

機能

機能

機能

既存システム

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

Prg

システム境界のレベルで一致させる