「ユーザのための要件定義ガイド」（以下、ガイド）第4章－１「ビジネス要求の獲得」の冒頭「現状の把握」の項目では、要件定義以前の大問題が提起されています。
それは、以下の状況に照らして、どうやって現状を把握するかと言う問題なのですが・・・
1.
業務をシステム化してから時間が経過するとともに、システムで実現している業務がなぜ
そのような形態になっているのかを理解する人が業務部門にも少なくなっている。
2. システム化されているからといって、システム部門には業務の精通者が残っているというわけでもない。
3. システムや業務の理解が浅いにもかかわらず「現行踏襲」という本来受け入れてはいけない要求を受け入れてしまい、業務仕様や機能仕様が不明瞭なままプロジェクトを進め、あとで問題になるようなことも起きている。
このような状況で採るべき手段として書かれていることは・・・
（まとめ直して書けないので原文を載せます。）
勘どころ① 現行システムから可視化する
システムは業務の写像である。現行業務を理解する手がかりがない場合、もしくは現存するドキュメントが全く最新化されていない場合は、実際に動いているシステムからどういう動作をしているかを可視化することが現行分析の第一歩となる。以下に可視化できる情報の例を挙げる。
•データモデル (データベースから)
•モジュール構成・クラス構成 (プログラムコードから)
•処理ロジック (プログラムコードから)
•ジョブスケジュール (ジョブ管理ツールの設定から)
•OS、ミドルウェア、ソフトウェア設定 (設定ファイルから)
•接続先システム情報(データ連携ツールの設定から)
これらには、リバースツールなどが用意されているものもあるので、利用すると良い。
勘どころ② 全体像を可視化する
可視化の目的は、現行業務、システムの理解である。したがって、精通者でない担当者でも理解できるよう、概略化し全体像を文書化する必要がある。あるべき業務像を検討するために、単に寄せ集めるのではなく、広い視野を持って俯瞰的に整理するよう留意していただきたい。また、再構築対象が複雑で広範囲な場合には、全体像を可視化することが有効である。以下に、全体像の概略の可視化例を示す。
•システム間関連図
接続先システム情報、ジョブスケジュール、データモデルなどをもとに、どのシステムからどのシステムへ、いつ、なにが、どのように連携しているかを可視化する
•システム構成図
OS、ミドルウェア、ソフトウェア設定などからシステムの構成、サーバー間の関連性を可視化する
•概念データモデル
どのような情報が保持され、どう関連しているかを可視化する
•画面遷移図
処理ロジックなどから画面遷移を可視化する
•業務スケジュール
ジョブスケジュールなどから業務スケジュールを可視化する
勘どころ③ 現行業務を再学習する
現行システムの復元だけでは、システムでは対応していない領域は可視化できない。その中には、現行業務担当者の頭の中にだけあり、形式化されていない情報もある。したがって、稼働中のシステム、その運用ドキュメントや現行業務担当者本人からの再学習(リラーン)を通じて、現行業務、システムの可視化結果の補完を行うと良い。再学習とは、理解するために現行システムを調査したり、操作したり、利用されている現場を観察したりして、システムや業務の理解を促進する手法である。
現行業務を再学習することで、要件定義メンバが単に業務の流れ、システムの使い方を知るだけでなく、潜在する問題、ニーズ、課題を一人称で、あたかも自分事のように考えられるようになる。そのような状況で導かれた課題やその課題を解決する要求は、現行業務の担当者に納得感のあるものとして受け入れられやすくなる。
勘どころ④ 埋もれている既存資料を発掘する
社内には多数の資料があるはずである。まずは、対象の業務、システムや周辺業務、システムに関する資料を探すことから始めると良い。以下にドキュメント例を挙げる。
•現行業務、システム稼働時の説明資料
•業務分掌規程など業務に関わる規程、基準
•新人研修用ドキュメント
•運用マニュアル
• SLA
•契約書
勘どころ⑤ 実態と照らし合わせて確認する
既存ドキュメントを使って、関係者全員で理解を深めるための現行の業務シナリオを作成する。ただし、業務シナリオを作成して終了ではない。業務シナリオの作成による可視化はあくまで現行理解への第一歩である。真の理解を得るためには、作成した業務シナリオを、実際の業務担当者に弟子入りする位の気持ちで、実態と照らし合わせて確認すると良い。実態に照らし合わせた確認方法の例を以下に挙げる。
•現行システム操作
まずは、現行システムを実際に操作し、作成したシナリオを確認する。試験環境や擬似本番環境があればそれを使うほうが望ましい。操作をしている中でさまざまなケースでどのようにしているのか疑問に思う点があるはずなので、記録し業務担当者に確認すると良い。
•業務担当者へのインタビュー
作成した業務シナリオを使って、業務担当者にインタビューして確認してもらうと良い。あわせて、前述のシステム操作で出てきた疑問点を確認する。インタビューを通して、さまざまなシナリオが抽出できるし、現行業務、システムへの不満、ニーズなども抽出できる。
•実作業の観察 (エスノグラフィー)
次に、業務担当者の作業環境に同行、陪席し、実作業を観察しながら作成した業務シナリオを確認すると良い。業務担当者は日々の作業で当たり前に感じている部分が第三者の目からすると問題に感じられたり、こうしたほうがよくなるのではないかといったアイデアを発想できたりする。
•業務作業のシャドーイング
さらに、業務担当者と一緒に、もしくは業務担当者に代わって業務を遂行する方法もある。実際に経験することにより、現行業務を一人称で捉えられるようになるだけでなく、「なぜこのような作業が必要なのか?」といった、ドキュメントでは到底表現できない背景や文脈を理解する足がかりを掴むことができる。
上記から読み取れることは・・・
1. これはユーザによる要件定義の問題ではなく、ＩＴ部門が中心となってユーザの協力を得ながら、また、リバースツールなどを提供するベンダーも巻き込んで展開すべき一大プロジェクトになっている・・・と、言うこと。
2. これらをしなければならない組織では、そもそもシステム開発に限界がある、それも末期的な意味でであり、新しいシステム案件はそもそも無理がある・・・と、言うこと。
3. 従って、ＩＴ部門は至急経営層に対して状況をエスカレーションし、改善のためのプロジェクトを立ち上げなければならない・・・と、言うこと。
・・・だと言えます。
本ガイドにおいて、このような「警告」ともとれる内容が書かれていると言うことは、実際にこのような状態に陥っている企業や団体があると言うことなのでしょう。経営者にはすぐにも自社の状況をチェックして必要な対策をとって貰いたいと思います。