ビジネス系のシステム開発では、まったくの新規システム開発は少なく、すでにあるシステムの再構築プロジェクトがほとんどです。このようなプロジェクトでは既存システムを調べる作業が必ず発生します。その割には公開された情報として、既存システムを分析する方法を説明したものを見かけません。多くは開発者がその場その場で臨機応変に対応しています。
実際のプロジェクトでは開始早々この既存システムの分析で手間取り、時間を大きくロスするケースが見られます。この連載ではコストをかけずに分析するモデルベースの方法を5回に分けて紹介します。第1回目となる今回は、詳細に踏み込まずにトップダウンでモデル化していくための考え方を示します。
プロジェクトが置かれた状況
既存システムは土台にできるか
既存システムの調査分析は時間ばかりかかり、なかなか成果が現れません。そんなプロジェクトでは以下のような会話が飛び交います。
佐藤さん: 「既存システムを分析して、その上で要求をベースにトップダウンで 仕様を考えていたら、いつになったら開発が始められるか分からない。 既存システムの構成をもとに開発する方がいい」 木村さん: 「そんなことをしたら既存システムと同じものになり、課題の解決も 付加価値をつけることもできなくなる。時間がかかっても既存システム を分析して、トップダウンで要件定義から進めた方がいい」 佐藤さん： 「それは分かるけど既存システムの分析や要件定義に時間がかかりすぎて、 納期に間に合わなくなる」
既存システムを分析し、要件定義からはじめると時間がかかるから、ほぼ同じシステムなら、その構成を参考に進めた方が混乱が少なくていい、という考え方に傾くのも分かります。しかし、混乱は少なくなりますが、既存システムの制約をそのまま取り込む可能性は高くなります。
例えば古い本を内容はそのままに、新しく本を書き起こす場合を考えてみましょう。内容は同じと言っても、より魅力的な内容にする必要があります。その古い本を土台として部分的に魅力を追加していくのか、その本のエッセンスを整理し、一から本を書き起こすのかの違いに似ています。
どちらも大変な作業ですが、エッセンスを抜き取ることが出来れば、新たに本を書き起こす方がより魅力的な本に仕上げることが容易になります。古い本を土台にしてしまうと、ストーリー展開が同じになる、登場人物を追加することが難しくなる、難解な箇所がそのままになってしまう可能性があります。
同じように既存システムをベースにシステム化すると制約を引き継いでしまう可能性があります。では既存システムのエッセンスを整理するというのはどういうことでしょう。今回の連載はその考え方と具体的な手法を説明します。
システムの再構築案件
既存システムの多くはドキュメントが整備されておらず、頼りは少数のドキュメントとプログラムという現場を多く見かけます。
おまけにシステムを利用している方の多くは自分が操作しているシステムが「なぜこうなっているのか」を説明できません。自分が担当したときにはこのシステムがすでにあり「使い方を聞いているだけ」という状況です。同じく情報システム部門は業務について一般的なことは分かっても、業務固有のことについては詳しく知りません。
つまり既存システムについて全体を網羅的に知っている人はおらず、ビジネスルールもシステムに埋もれ、システムの挙動に合わせて作業を進めているケースが一般的です。
このような状況の中では、まず網羅的にシステムを語れることと、埋もれたビジネスルールを明らかにすることがとても大事になります。
一般的な対応
一般的に既存システムを調べる作業は、一覧を作り、手に入る資料に基づいてドキュメントを新たに作成する作業をしています。例えば機能一覧やプログラム一覧、画面一覧などです。その一覧を頼りに個々の画面や機能などの要素ごとに資料としてまとめます。
しかし、手に入る資料をベースに情報を整理する、この方式は効率的ではありません。資料を調べることが目的になり、本来の目的である「網羅的にシステムを語り、埋もれたビジネスルールを明らかにする」という視点が欠ける可能性が高いからです。なぜならばシステム全体を見る視点が薄くなり、必要な情報と不要な情報を識別することなく、ただ対象を調べることに意識が向かってしまいがちになるからです。
何よりも重要なことはシステムの対象業務の中でシステムがどのように使われ、そのためにどのような機能があるのかを、システム全体から語れることが必要です。当たり前の言葉ですが「木を見て森を見ず」にならないことが求められます。
