PR

「データ」の抽出はリバースを活用

 再構築時の見える化でCRUD図を活用する現場は多い。しかし画面や帳票といった目に見えるユーザー・インタフェースと違って,テーブル構造やデータ定義を明らかにするにはDBの中身を見る必要がある。テーブルの数が少なければ目視で確認できるが,多くなると負担は大きい。

 ウルシステムズの石川智久氏(シニアコンサルタント)は,このデータの調査でリバース・エンジニアリング(リバース)を活用する。具体的には,リバース機能を持つ開発支援ソフトを使い,既存のDBからテーブル構造やデータ定義を自動抽出する。「アプリケーションと異なり,構造化されたRDBの情報は抽出しやすい」(石川氏)という。

 さらに,ボトムアップ的にテーブルやデータを調査すれば,抜けや漏れを防げるほか,未使用のテーブルやデータを洗い出せる利点もある。

 ただし,リバースで抽出できるのは,物理情報に過ぎない点に注意が必要だ。つまり,抽出した情報は,DBに格納する際のテーブル名やデータ名である。再構築時に必要な業務の視点でとらえた論理情報ではない。そのため実際には,物理情報のテーブル構造やデータ定義を論理情報に“翻訳”する必要がある。ここは業務知識が求められそうだが,石川氏は「実データを参照すれば,だいたいは想像できる」と語る。もし分からない場合は,利用者に尋ねるようにしているという。

ヒアリングに偏りすぎない

 再構築時には,現行システムの概要をつかむためにドキュメントの整備が重要となる。しかし,現実にはドキュメントの不備が多いのは第6回でも述べた通り。DBなど一部を除いてシステムの中身をたどっていくのも困難だ。当然,ユーザーに対するヒアリングに頼った情報収集が基本となる。裏返せば,ヒアリングの良しあしが,見える化成功のカギを握る。

 「漫然とヒアリングしても知りたい情報にはたどり着けない」──。こう唱えるのは,イントリーグの永井昭弘社長だ。再構築の現状調査を数多く手掛けてきた永井氏は,過去にヒアリングの難しさを幾度となく経験した。特に,具体的な情報になかなかたどり着けない,同じ質問を投げかけても相手によって主張が異なる,という2点について難しさを感じていた。

 その経験を踏まえ,永井氏は次ページの図1のような手順でヒアリングを実施している。ポイントは,ヒアリングの前後にある。まずヒアリングの前には,既存のドキュメントを徹底的に読み込む。もしドキュメントが無ければシステム開発者・運用担当者にレクチャーを受ける。それでも機能の目的などが分からない場合は,プロジェクト開始当時の見積書や提案書までさかのぼるという。

図1●ヒアリングの成否は前後の情報収集で決まる<br>場当たり的なヒアリングは失敗のもと。イントリーグの永井昭弘氏は,最初に既存のドキュメントを読み込み,ヒアリングではおおまかな仕事の役割や特有の業務をつかむことに重点を置く。ヒアリングで意見が分かれやすい現行システムの問題点の把握は,付せん紙に書き出してもらったものをベースにブレーンストーミングしてもらう
図1●ヒアリングの成否は前後の情報収集で決まる
場当たり的なヒアリングは失敗のもと。イントリーグの永井昭弘氏は,最初に既存のドキュメントを読み込み,ヒアリングではおおまかな仕事の役割や特有の業務をつかむことに重点を置く。ヒアリングで意見が分かれやすい現行システムの問題点の把握は,付せん紙に書き出してもらったものをベースにブレーンストーミングしてもらう
[画像のクリックで拡大表示]

 「何も知識がない状態でヒアリングに臨むのは相手に対してかなり失礼。既存のドキュメント内容をベースに,分からない部分のみを確認することが大事」(永井氏)。たたき台があるだけに,ヒアリングも具体的なものになる。これで最初の問題を克服する。

 もう一つの問題である人によって主張が異なる点は,ヒアリング後のブレーンストーミングで解消する。過去の経験を振り返ると,主張が異なるのは主に「現状の問題」だった。そこでヒアリング時には現状の問題には踏み込まず,「組織の役割は何か」「どんな仕事をしているのか」を中心に聞く。こうした内容であれば,多忙を極めるキーパーソンをヒアリング対象としなくても事が足りる。

 その上でブレーンストーミングでは,ヒアリング時に聞けなかった「現状の問題」を議論してもらう。ただし,いきなり議論に入ると,今度は声の大きい参加者の意見に流されやすい。そこで参加者には事前に「現状の問題」を付せん紙に書き出してもらい,それを整理した上で議論を進める。これにより「参加者全員が納得した形で現状の問題を見える化できるようになった」(永井氏)という。