前回までは，システム振舞いと画面設計に関する工程成果物の書き方のコツとレビューのコツを紹介してきました。今回からは，［データモデル編］と題して，データモデルのレビューのコツを紹介していきます。 始めに，データモデルを表現するための工程成果物を説明しておきましょう。データモデルに必要な成果物は，各社でさまざまな定義をしていますが，「発注者ビュー検討会」では，次の4種類を，データモデルに関する工程成果物として定義しました。 ■ER図 情報のまとまりを「エンティティ（Entity）」，情報の相互関係を「リレーションシップ（Relationship）」で表したものです。

前回は，データモデル全体が俯瞰できること，データモデルが適切にグルーピングされていること，各グループ間の関連が把握できることの重要性について説明しました。今回は，業務の流れに沿って，システム全体を俯瞰することの重要性について説明しましょう。 業務間連携や外部システム連携を発注者と合意する 複数の業務にまたがるシステムを設計・開発する場合，個々の業務ごとに画面→機能→データ設計を進めてしまいがちです。 業務間の連携について全く考慮する必要がないシステムならこれでも問題ないのですが，受発注システムのように，データベースやファイルに登録された伝票データが複数業務にわたって参照・更新されていくシステムでは，業務間連携について十分に考慮する必要があります。 さらに，外部システムとの連携についても考慮する必要があります。例えば，得意先別に仕訳された請求データを外部システムとして既に存在する財務管理シス

業務の流れやシステム構造といった、目に見えないものを可視化するためのシステム構築技法。記号を使って平面図（モデル）を作成する。 モデリングは、システム構築の工程で、序盤から中盤にかけて実施する。例えば、開発者がユーザーの目的を聞き出す際や、システムの設計図を作る際に用いる。 可視化の目的は、システムの構築にかかわるユーザーや開発者たちが、開発対象の業務やシステムに対する共通の認識を得て、問題点を洗い出すこと。また、システムの設計図は、プログラム開発や保守にも利用する。 業務の可視化を「ビジネス・モデリング」と呼び、最近注目を集めている。ユーザーの要求を適切に分析することが、近年ますます重要かつ困難になっており、業務の可視化が分析に有効だからだ。 モデリングによる可視化とは、情報の整理ともいえる。業務やシステムに存在する情報、情報間の関係、情報の流れを、四角や矢印といった記号を使って表現する

前回は，「要求開発は，ユーザー企業のためのもの」ということを知ることで，方法論（Openthology）のモデリングやプロセスの目的と価値について，改めて考えるようになったことを書きました。 この論議に続いて，ある方が「モデリングには目的がある，目的のないモデルには意味がない」と言われました。私には，衝撃的な言葉でした。そこで，今回はモデリングの目的について，考えてみようと思います。 筆者は，SI企業のSEという立場で，ユーザー企業のシステム開発プロジェクトに参画します。システム要求がきちんと整理されたRFPが存在する場合は，どうやって実装するかについてモデリングを行います。これは，「正しく」システムをつくるためのモデリングです。 一方で，そこまでの具体性がないままに発注されている場合もよくあります。この場合，ユーザー企業側でも，ビジネス要求に基づくシステム要求が整理しきれておらず，まずは