「こんなに多くのドキュメントはそろえられない」──。NECソフトの杉本朋裕氏（静岡支社 ソリューションビジネス部 セールスマネージャー）は，こう言って社内で規定されたドキュメントに“ノー”を突きつけた。
NECソフト社内で規定されている現状調査に必要なドキュメント体系は，業務フローや画面/帳票といった外部仕様をはじめ，ソースコードやDBの内部仕様，テスト仕様やテスト結果など約100種類に上っていた。「大規模な再構築プロジェクトを除いて，ほとんどのプロジェクトは，現行システムの見える化に調査コストをかけられない。現場では最低限必要な情報をいかに早くそろえ，再構築プロジェクトに入ることが重要」。杉本氏はノーを突きつけた理由をこう打ち明ける。
杉本氏は，メンバーとともに100種類のドキュメントから最低限必要なものを選び出した。具体的には「業務フロー」「システム構成」「インタフェース仕様」「稼働仕様」の4分類9種類。これをすべてのプロジェクトで適用するドキュメントとした（図1）。
ポイントは「調査に時間がかかる割に，再構築にあまり重視されない内部仕様を削ったこと」（杉本氏）。再構築ではいずれ，現行システムを“捨てる”。この捨てるシステムが何を実現しているのかを見極め，どう実現しているのかを探ることは避けたのだ。
ただし，外部仕様ではない運用仕様書や障害対策仕様書といったドキュメントは削らなかった。「実際の運用状況をつかめば，現行システムの問題が見えてくる」（杉本氏）ためだ。
画面と帳票を「ID」で関連付け
調査対象のドキュメントのなかで，中核をなすのは「業務フロー図」である。組織の改編や業務の見直しに伴い再構築を行うことが多い。そのため現状のシステムと，業務の関係を明確に把握することが大切である。
ところが，視点や粒度が異なる「業務」と「システム」を密接に結びつけるには難しさがある。前出のアビームコンサルティングの財部氏も，何度もこの問題に直面した。「システムはビジネスを実現する手段に過ぎない。かといってシステムの仕様は業務の視点で書かれていない。この両者に連動性を持たせるため試行錯誤を繰り返した」。財部氏はこう説明する。
そして苦心の末に行き着いたのが，2種類のドキュメントを使って業務とシステムを関連させるテクニックだ（図2）。2種類のドキュメントとは「業務フロー図」と「CRUD図」である。業務フロー図は，部署ごとにレーンを分けて業務の流れを示したもの。CRUD図は，システムが持つ機能と，その機能が扱うデータの関係（追加/参照/更新/削除）を示したものだ。両者を画面や帳票といったインタフェースの「ID」でひも付けるのがポイントだ。
具体的には，業務フロー上には業務で利用する画面や帳票を書き込み，CRUD図の機能はインタフェースとなる画面や帳票に分解して関連付ける。
記述上の注意点は何か。財部氏は「業務フローを作業ではなく，業務の視点で書くこと」と説明する。ここでいう「業務」とは，何らかの価値を生み出す仕事の単位。例えば「在庫を引き当てる」「請求する」というのが業務となる。これに対して作業は「請求書を作成する」のように，「請求する」を人間が行う手順まで分解してしまうこと。「明らかにしたいのは業務とシステムの関係。業務なら何らかの画面や帳票が関連付くが，作業レベルになると関連しないものもある」（財部氏）。その結果，業務フローを作業レベルまで詳細化すると，システムと関連のない記述が増えて，業務とシステムの関係が埋もれてしまうという。
