オープンコミュニティ「要求開発アライアンス」(http://www.openthology.org)の2011年2月定例会発表資料です。 Open Community "Requirement Development Alliance" 2011/2 regular meeting of the presentation materials.

1. As-Is ステム分析は入出力から始めよ
既存システムの全体像を把握する
株式会社バリューソース 神崎善司

2. わたしは
 ㈱バリューソース
 代表取締役 社長
 神崎 善司 要件のツボ
 zkanzaki@vsa.co.jp
 はてな：good_way
 twitter:zenzengood
http://www.vsa.co.jp/ka
 普段は name
 要件定義のコンサルテーション
 オブジェクト指向やUMLのセミナー開催
 要件定義ツール「要件のツボ」開発
 経験
 ２０年ほど前からオブジェクト指向を中心にシステム開発全般のコンサルティングを行う
 １０年ほど前から上流工程を中心としたコンサルティングを行う
 その経験を活かしてモデルを使った要件定義の手法をまとめる
 大規模システムの保守性向上のための既存システムの分析を行う

3. 既存システムを取り巻く状況は
 ドキュメントがない
 ドキュメントは最新ではない
 ソースが最新かどうか分からない
 さまざまな言語で開発されている
 聞いたことがない言語である
 アーキテクチャが明確ではない
 システムの利用者
 普段使っている機能だけ知っている
 なんでこうなっているのか分からない

4. 問題のはじまり
 新システムの企画段階で
 今のうちに既存のシステムを調べよう
 システムのドキュメントを再度作成する！

5. よく起こること
 システムのドキュメントを整理する → プログラム単位の
ドキュメント
 数千本のプログラムについて細かい仕様を調べる
 複数の担当者が担当を割り振られ黙々と作る
 キングファイルが積み上がる

6. プログラム単位のドキュメント化
 混沌とした一枚岩のシステムをプログラム単位で調べてもシステム化
の判断には役に立たない
Prg
Prg Prg
Prg
Prg Prg Prg
Prg
Prg
Prg Prg Prg
Prg
Prg Prg Prg
Prg

7. そんな現場では
 何を書くんですか？
 どの範囲まで書くんですか？
 どの粒度で書くんですか？

8. 一ヶ月後
 いつまでやるんですか？
 やれと言われればやりますが。 ？？？？？？
 目的が曖昧なままスタートしたので終わるタイミングが分か
らない

9. そして…
 As-Isの資料作成がいつのまにかTo-Beの資料作成に
 この部分は君が詳しいから次期システムもここは君が担当してくれ
 細かいことは分かるけど、次期システムについて判断出来ない
 結局方向性のない焼き直しシステムができあがる
 データ構造の見直しは行われず 保守性はいっこうに改善しない

10. 迷信
 保守中のバグは新システムでは再現させたくない
 何でシステムで同じようなバグが出るの？
 既存のシステムとほとんど同じだから…
 「ほとんど」とはどこですか？ ？？？？？
イメージ 実際は
ほとんど同じ
 「細かいことを知っている」は「システムをよく知っている」ことに
ならない
 結局システムは何をしているのですか？ ？？？？？

11. どうすりゃいい

12. 何を調べたいのか
 現在のシステムはこうなっている
 次のシステムの方向性はこうだ！
 だから次のシステムはこうする
 必要なことを判断出来る情報が重要！
 判断するためには何を何のためにが分かる必要
がある
 つまり つじつまのあう説明ができる

13. 目指すべきは
 プログラムに左右されずにシステムが何を行っているかを明
らかにする
 システムにとって大事なことは
 何ができればいいのか
 どう整合しているのか
 主要な機能は？
 主要な情報は？
 機能と情報の関係は？
そこで…
 本質を捉えるためにモデリングだ

14. えっ モデリング ほんとか？
 既存のシステムを調べているんだ
 モデルと既存のシステムの関係は？
 既存のシステムは綺麗ではない
 綺麗なモデルは現実と離れていく
 綺麗なモデルは結局何を表しているんだ！

15. どうモデルを活かす
 現実とつながりながら現実の混沌に影
響されずに 整理する
 そのためには…
 前提
 細かなルールにこだわらなくていい
 既存システムの仕組みは無視していい

16. 既存のシステムとは
 様々な制約によってプログラムが混沌としている
Prg Prg
Prg
Prg Prg
Prg Prg
Prg Prg
Prg Prg
Prg Prg
Prg Prg
Prg Prg

17. 何を捉える
 システム境界とデータを捉える
だから～ 情報のない中でどうやってやるんですか？

18. ドキュメントがないと言っても
 たいてい以下のドキュメントはある
 テーブル定義書
 電文レイアウト
 ファイル交換のファイル定義書
 保守されているシステムについては
 データと他システムにつながる部分の情報
はある

19. システムをよく知らないといっても
 この機能はこういうことを行っている
 ここでこうするとあそこに影響する
 こうしたいときはここをこうすればいんだよ
 制約の説明
 ここは時間がなくてこうしちゃったんだ！
 この時代はこういうルールだったんだ

20. 具体的にどうするの？
分析

21. 分析方針
 集めやすい情報から集める
 抜けたピースを探す
 集めた情報の特徴から切り込む
 分類する
 関係をつかむ

22. 現実とつながりながら現実の混沌に影響されずに整理する
入力 モデル 出力
情報 情報
タイミング タイミング
機能 機能
機能 機能
機能 機能
システム境界のレベルで一致させる
入力 既存システム 出力
情報 情報
タイミング Prg Prg タイミング
Prg Prg
Prg Prg
Prg Prg
Prg Prg
Prg Prg
物理制約 時間制約 開発時制約

23. 認識する情報
 入出力
 画面 稼働しているシステム
 帳票 〃
 通信 電文レイアウト
 データ交換
 File Fileレイアウト
 DB テーブル定義書
 データ
 テーブル定義書
 ファイルレイアウト

24. システムの入出力を捉える
 データ集約的なシステム
 入れポン 出しポン
 入力と出力を把握できればいい

25. システム境界を捉える
帳票
画面
データ交換
DB
受信
送信
システム
通信
受信
送信
File
データ交換

26. システムが関心をもつ状態を捉える
 状態監視的なシステム
 監視対象があって今を意識
 一連の手続きの管理 プロセス管理、ロングトランザクション管
理
 状態としてルールを整理
 ユーザが認識している状態を把握するために
 画面上の情報
 オペレータが画面の振る舞いとして認識しているもの
 テーブル上の区分やフラグなど
 テーブルの関係
 ビジネス上の概念

27. 状態を振る舞いのルールとする
A画面
受信 DB
受信
A画面
開始前 開始済み
A_File
受信
B_File B画面
システム
解約待ち
送信
送信 送信 A_File
XXX / YY機能
状態 状態
状態の遷移として整理

28. 入出力をイベントで統一的に扱う
 システム境界をイベントとして
画面
扱う
受信
 ポイント
送信
 画面やデータ交換は
送信 File 実体に合わす
受信 DB 画面
受信 システム
イベント 送信

29. 隠れた情報をあぶり出す
 隠れた情報
 複数の意味をもつデータ
 意味の違うものを一つのレイアウトで扱う
 複数のイベントを一度に扱う
 タイミングが隠れる
システム
情報

30. 既存のプログラムに影響されずに機能を記述す
る
画面
機能
受信 <CU>
受信 <U>
機能
機能 <R>
受信
システム
システム
<R>
機能
送信 <RD
機能 >
送信 送信 CRUD
File

31. データと機能の整理
 データ
 ほとんどの場合DBのテーブル整理
 ER図の作成： 主要なテーブルを識別
 サブシステムに分類する
 機能
 イベントに対応付ける
 バッチに対応付ける イベント 機能

32. バッチを洗い出す
 バッチの種類
 定期監視
 本来のバッチ処理
 入出力のバッチ
 File交換
 DB経由
 ポイント
データ交換の処理とバッチ処理を切り分ける

33. 記述のパターン
画面処理 Fileによるデータ交換
画面 機能 File交換入 機能 File
File交換出 機能 File
通信
システム 受信 機能
DBによるデータ交換
DB交換入 機能 データ
電文
DB交換出 機能 データ
送信 システム
機能 電文 定周期
定周期 A機能 送信 YY機能
日

34. システムを適切な大きさに分割する
 事実 規模２５のシステムを分けると重複
分を含めて規模３０に増える。
 ある閾値を境に開発費は急激に上昇する しかし、それが閾値よりも低ければ
 システム開発に関わる変化を止めることは 重複分５は無視できる
できない
規模１０ 規模２０
重複５
 いかに分けるか
規模３０
 データ中心にわける
 機能を中心にわける ４５
４０
 業務を中心にわける 工数
３０
２５
コスト ２０
１５
１０
 綺麗に分けようとしない ５
５ １０ １５ ２０ ２５
 その企業の文化に併せて分割する 規模 閾
値

35. サブシステムに分類する
画面
機能
受信 機能
受信
機能
受信
システム 機能
送信
送信 送信 機能
File

36. 分け方の例
分けやすいところ
 データ中心 から分ける
 データを役割から分ける
その分類に他のも
 業務別にデータを分ける のを寄せる
 データに機能を紐付け分類する
特徴をつかみ方
針を決める
 機能中心
 機能の役割から分ける
 業務別に機能を分ける
 機能にデータを紐付け分類する 暗黙的な分類を引き出す
制約を意識する

37. 掘り起し岩を砕く

38. 特徴をつかみそこから切り込む
 トップダウンアプローチ
 ビジネスモデルから把握する
 会社の外の登場人物を整理する
 会社の中の登場人物を整理する
 ビジネスモデルとしての分類を求める
 ボトムアップアプローチ
 CRUD表
 正確なCRUD表ではなく妥当なコストで把握できる精度のものを目指
す
 マクロにながめる
 プログラムの分類を見直す
 テーブルの分類を見直す

39. トップダウンアプローチ
会社外の登場人物
登場 登場
人物 人物
登場 登場
人物 人物
登場 会社 登場
人物 人物
会社内の登場人物
部署 部署
会社
・切り込めるところから切り込む 部署 部署
・いろいろな手を試す

40. ボトムアップアプローチ
分類をモデルとあわす
CRUD表 テーブル
プ
ロ
グ
ラ
ム

41. RDRA（リレーションシップ駆動要件分析）全体像
システム価値 システム外部環境 システム境界 システム
画面・帳表 データ
業務
業務＆ＵＣ
ＵＣ＆画面
機能複合
コンテキスト モデル
概念
ユースケース
ＵＣ＆機能
ドメイン
要求
利用シーン
＆ＵＣ
プロトコル
利用シーン
機能
② イベント ① ＵＣ：ユーケース

42. どう管理するのか
コンテキスト
ドメインモデル
システム論理構成
サブシステム
パッケージA
画面・帳票モデル
イベントモデル
データモデル
機能複合モデル
プロトコルモデル
パッケージB

43. まとめ
モデル
 システム境界とデータで
機能
機能
機能
合わせる
機能
機能 機能
 特徴をつかみ洗練化す
る
システム境界のレベルで一致させる
既存システム
 分類し整理する
Prg Prg
Prg Prg
Prg Prg
Prg
Prg
Prg
Prg
Prg
Prg  得られる情報から切り口
を探し整理する