SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

モデルベースの手法でコストをかけずに既存システムを分析する

既存システムを分析するコツは「システムの地図」を作ること

モデルベースの手法でコストをかけずに既存システムを分析する(1)

  • X ポスト
  • このエントリーをはてなブックマークに追加

 既存システムの分析のためにプログラムを一つ一つ調べているあなた。その作業に疑問を持っていませんか? 「なんだかな~」と思いながら作業していませんか? それを指示したプロジェクトリーダーのあなた。既存システムを調査することのゴールを明確にせず、とりあえず手に入る資料をベースに作業させていませんか? このような方に少しでもヒントになればと思い、この記事を書きました。

  • X ポスト
  • このエントリーをはてなブックマークに追加

 ビジネス系のシステム開発では、まったくの新規システム開発は少なく、すでにあるシステムの再構築プロジェクトがほとんどです。このようなプロジェクトでは既存システムを調べる作業が必ず発生します。その割には公開された情報として、既存システムを分析する方法を説明したものを見かけません。多くは開発者がその場その場で臨機応変に対応しています。

 実際のプロジェクトでは開始早々この既存システムの分析で手間取り、時間を大きくロスするケースが見られます。この連載ではコストをかけずに分析するモデルベースの方法を5回に分けて紹介します。第1回目となる今回は、詳細に踏み込まずにトップダウンでモデル化していくための考え方を示します。

プロジェクトが置かれた状況

既存システムは土台にできるか

 既存システムの調査分析は時間ばかりかかり、なかなか成果が現れません。そんなプロジェクトでは以下のような会話が飛び交います。

佐藤さん:
「既存システムを分析して、その上で要求をベースにトップダウンで
仕様を考えていたら、いつになったら開発が始められるか分からない。
既存システムの構成をもとに開発する方がいい」

木村さん:
「そんなことをしたら既存システムと同じものになり、課題の解決も
付加価値をつけることもできなくなる。時間がかかっても既存システム
を分析して、トップダウンで要件定義から進めた方がいい」

佐藤さん:
「それは分かるけど既存システムの分析や要件定義に時間がかかりすぎて、
納期に間に合わなくなる」

 既存システムを分析し、要件定義からはじめると時間がかかるから、ほぼ同じシステムなら、その構成を参考に進めた方が混乱が少なくていい、という考え方に傾くのも分かります。しかし、混乱は少なくなりますが、既存システムの制約をそのまま取り込む可能性は高くなります。

 例えば古い本を内容はそのままに、新しく本を書き起こす場合を考えてみましょう。内容は同じと言っても、より魅力的な内容にする必要があります。その古い本を土台として部分的に魅力を追加していくのか、その本のエッセンスを整理し、一から本を書き起こすのかの違いに似ています。

 どちらも大変な作業ですが、エッセンスを抜き取ることが出来れば、新たに本を書き起こす方がより魅力的な本に仕上げることが容易になります。古い本を土台にしてしまうと、ストーリー展開が同じになる、登場人物を追加することが難しくなる、難解な箇所がそのままになってしまう可能性があります。

 同じように既存システムをベースにシステム化すると制約を引き継いでしまう可能性があります。では既存システムのエッセンスを整理するというのはどういうことでしょう。今回の連載はその考え方と具体的な手法を説明します。

システムの再構築案件

 既存システムの多くはドキュメントが整備されておらず、頼りは少数のドキュメントとプログラムという現場を多く見かけます。

 おまけにシステムを利用している方の多くは自分が操作しているシステムが「なぜこうなっているのか」を説明できません。自分が担当したときにはこのシステムがすでにあり「使い方を聞いているだけ」という状況です。同じく情報システム部門は業務について一般的なことは分かっても、業務固有のことについては詳しく知りません。

 つまり既存システムについて全体を網羅的に知っている人はおらず、ビジネスルールもシステムに埋もれ、システムの挙動に合わせて作業を進めているケースが一般的です。

 このような状況の中では、まず網羅的にシステムを語れることと、埋もれたビジネスルールを明らかにすることがとても大事になります。

一般的な対応

 一般的に既存システムを調べる作業は、一覧を作り、手に入る資料に基づいてドキュメントを新たに作成する作業をしています。例えば機能一覧やプログラム一覧、画面一覧などです。その一覧を頼りに個々の画面や機能などの要素ごとに資料としてまとめます。

 しかし、手に入る資料をベースに情報を整理する、この方式は効率的ではありません。資料を調べることが目的になり、本来の目的である「網羅的にシステムを語り、埋もれたビジネスルールを明らかにする」という視点が欠ける可能性が高いからです。なぜならばシステム全体を見る視点が薄くなり、必要な情報と不要な情報を識別することなく、ただ対象を調べることに意識が向かってしまいがちになるからです。

 何よりも重要なことはシステムの対象業務の中でシステムがどのように使われ、そのためにどのような機能があるのかを、システム全体から語れることが必要です。当たり前の言葉ですが「木を見て森を見ず」にならないことが求められます。

図1 既存の資料に依存した調査分析
図1 既存の資料に依存した調査分析

次のページ
大事なことは何か

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
モデルベースの手法でコストをかけずに既存システムを分析する連載記事一覧

もっと読む

この記事の著者

神崎 善司(カンザキ ゼンジ)

(株)バリューソース代表大手SIerにおいて大小10システム以上のプロジェクトリーダを勤め、20年ほど前に独立。2002年から5年間(株)豆蔵での社員も兼任しながら要件定義などの上流工程のコンサルティングを行う。2008年に要件定義手法「リレーションシップ駆動要件分析(RDRA)」を開発し現在はその...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/6487 2012/04/10 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング