実装（プログラム）に左右されずに仕様を明らかにする

システムを理解する上で大事なことは

• 主要な機能は？

• 主要な情報は？

• 機能と情報の関係は？

整理された可視化資料は混とんとしたシステムを表せるのか

システムは長年の保守開発で信頼できるドキュメントがなく、プログラムも混とんとしている。これを綺麗に整理できるのか？　整理できたとしてそれは現実と乖離しているのではないか？

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

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

以下の２つの視点で整理します

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

• DBからビジネスで管理している情報を洗い出す

手に入る資料を整理し欠けてるピースを補う

手に入る資料を集めRDRAの形式に整理することで、欠けているものが明らかになります。そこから各情報をつないで欠けているピースを補います。これをトップダウンとボトムアップの両方からつなげることで全体像が把握できるようになります。

ヒアリング可能な関係者

ヒアリングできる人が使っている資料は信頼性が高いといえます。従って資料の信頼性を関わる人の役割から把握し、その資料を中心に全体を形づくって行きます。

入出力とデータの資料を集める

システムの利用者が接する入出力と扱っているデータを明らかにする

入出力に関わる資料

• • • 画面一覧を調べ、なければ画面のハードコピーを取る

    • 外部とのインターフェース一覧を調べる

    • なければバッチ処理／APIから連携している部分を探す

    • 連携する会社との資料（契約書など）を調べる

データに関わる資料

• DBのスキーマ情報を出力する

• ファイルフォーマットの資料を探す

機能に関わる資料

• 機能詳細などの機能一覧に対応する詳細な記述

• 上記資料があれば条件や区分を洗い出すのに利用する

信頼性の高い資料からRDRA形式に変換する

• 入出力から整理

  • ①画面を整理する

    • ②画面を分類しユースケースを求める

    • ③画面を使っているアクターを求める

  • ①イベントを整理する

    • ③イベントと外部システムの関係を整理する

    • ②イベントを分類しユースケースを求める（画面から求めたUCを再利用）

• データから整理

  • DBのスキーマを整理する

    • DBのスキーマ情報を出力しビジネスにつながる（IDが識別できる）データ（情報）を洗い出す

    • ファイル一覧を分類し、役割別（情報）に整理する

    • ④情報とUCをつなぐ

    • ⑤情報から状態を洗い出し遷移にUCを当てはめる

ソースコードと格納しているフォルダーを分析

フォルダー構成やプログラムの分割単位などから仕様として取り出せるものを探します。

フォルダーの分析

トップダウンで分析したBUCやUCなどの名前とフォルダーの対応関係を整理し、ソースコードへのインデックスとして使用します。

ソースコードの分析

フォルダー分析の結果をもとにソースコードを分析する。トップダウンで分析したUC、画面、イベント、情報とソースコードの対応を整理する。

代表的な資料とRDRAの対応関係

手に入ったものをベースとして整理する。対応するものがなければ類推して整理します。

• 機能一覧

  • 大中小の分類を一旦、業務・BUC・UCに当てはめる

  • 全体を俯瞰しながら適切な単位に変えていく

• 画面一覧

  • 現在使われている画面をベースに整理する

• インターフェース一覧

  • なければ外部企業との資料から整理する

• テーブル一覧・ER図

  • スキーマ情報から整理する

• 機能詳細

  • 機能一覧に対応する形で詳細な機能を記述した資料

既存システムの可視化の目的は大きく分けて、以下の２つに分かれます

• システム再構築に向けた既存システムの分析

  • ToBe開発のためにAsIsを理解するために現状のシステムを理解する

• 保守開発の品質向上に向けた既存システムの分析

  • 影響度分析ができるようなベースを作成する

• 何を調べたいのか

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

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

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

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

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

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

  • 必要以上に分析を進める必要はない

• アクター・外部システム

  • 関係するアクターと外部システムを分かる範囲で洗い出す

• 情報

  • RDBのテーブルを情報とはしない

  • ビジネスで管理しているIDを洗い出す

• 状態

  • 状態の存在を認識できた場合に洗い出す

• 条件

  • ビジネスルールを洗い出す（存在が分かる程度）

  • ※仕組みとしてのルールは含めない

• バリエーション

  • 区分・種別からバリエーションを整理する

• 業務・BUC・アクティビティ

  • ToBeの議論の広がりのために業務を網羅的に出す

  • アクティビティはUCを出すためのもので正確でなくてよい

• UC周辺

  • 調査で明らかになった画面とイベントを適用させる

  • アクター／画面からUCを洗い出す

  • 外部システム／イベントからUCを洗い出す

• 方針

  • 保守品質を上げるために行う

  • 網羅的に各々の関係者の詳細な資料と紐づけられる内容で整理する

• 目的

  • システム化関係者が共有できる要件レベルで全体俯瞰できるように整理する

  • 保守開発の影響度分析を行えるようにする

• 変更起点を明らかにする

  • ビジネスルールの変更はバリエーションと状態モデルの変更に現れる

  • 画面、イベントなどの入出力が変更起点になる

• 重要なUCの確認

  • 状態を変えるUCは重要なUCになる

  • UCは情報を操作し状態を変える

• アクター・外部システム

  • 関係するアクターと外部システムを定義して整理する

• 情報

  • RDBのテーブルを情報とはしない

  • ビジネスで管理しているIDを洗い出す

  • 情報間の関連を明らかにする

• 状態

  • 状態の存在を認識できた場合に洗い出す

  • 状態遷移にUCを適用し欠けてるUCを洗い出す

• 条件

  • 契約書などの文書からビジネスルールを条件として洗い出す

  • 条件もUCにつなぐ

  • 条件につながるバリエーションを全て出す

  • ※仕組みとしてのルールは含めない

• バリエーション

  • 区分・種別からバリエーションを整理する

• 業務・BUC・アクティビティ

  • ビジネスで使われている言葉で業務を洗い出す

  • アクティビティはUCを出すための仕事を洗い出す

  • 業務・BUC・アクティビティ・UCは関連部署の担当者と共通認識が取れるベースを目指す

• UC周辺

  • 調査で明らかになった画面とイベントを適用させる

  • アクター／画面からUCを洗い出す

  • 外部システム／イベントからUCを洗い出す

  • 画面・イベントから洗い出したUCを適用する

  • 上記の整理をUCに結び付けながら行う