「ユーザのための要件定義ガイド：4.2.2要求の具体化」（P127）は以下の文章で始まっています。
「〜したい」という要求(業務レベルの目的や業務手段、IT手段)を具体化•現実化するための新しい業務の姿を描くことを「要求の具体化」と表現することにする。業務の姿を描くためには業務モデルを利用する。業務モデルは大きく、データ構造のモデル、プロセスのモデル、相互作用のモデルの3つがある。この3つのモデルを使って要求を反映した業務を描いていくことを本項では述べる。
本項は、要求が抽出されていることを前提として記載しているが、業務を描きながら、新たな課題や要求が発生したりするので、進め方はスパイラル的なものになる。
（中略）
このように、システムのアーキテクチャ以前に業務自体を見直すことも重要であり、To-Be業務を創り上げるのは、要件定義工程の重要なミッションの一つである。
⑴ 情報構造の観点から業務を可視化し、新しい業務として具体化する
【解決したい問題】
•要求を反映した業務の情報構造にならない
・業務 (情報)の整理ができてない
・業務の複雑さを低減できない
・業務用語を正しく理解していない
・業務の構造を把握していない
・データモデルは業務部門には難しい
データモデルも業務を表現する業務モデルである。データモデルを作成することで、業務の見直しや新しい業務の共通認識につなげなければならない。また、データモデルで表現できるTo-Beの業務ルール、すなわちシステムの仕様を明確にして設計につなげなければならない。
昨今は、情報が大量になり複雑さも増している。データモデルを使って、データすなわち情報の整理を実施することも重要である。
データモデルは、業務部門の人員では作成が難しいと思っている企業は少なくない。データモデルをシステム部門などが作成したときに、それをどのようにして「業務部門に確認するかも課題となっている。
本ガイドは「要件定義」について書かれているのですが、引用した文中の太字部分では「システムのアーキテクチャ以前に業務自体を見直す」と書かれていて、要件定義でシステムのアーキテクチャを見直すかの如く読み取れます。
また、文中のアンダーラインを筆者が引いた部分は、情報、用語、データ、データモデルについて書かれています。特に「データモデルは業務部門には難しい」及び「データモデルをシステム部門などが作成したとき」の表現部分には、大きな認識相違があるように感じられます。
ここで述べられているデータモデルは、著者が後で述べているように「概念データモデル」なのですが、このモデルの作成は成果物の前に作成プロセスが非常に重要視されます。と言う意味は、業務部門とＩＴ部門が協働作業で議論を重ねつつ「データの概念（コンセプト）」をすり合わせることが重要なのです。
その作業については、「ＩＴによる業務変革の正攻法～ＪＦＥスチールの挑戦」安保秀雄著 日経ＢＰ社にさわりが記載されています。以下にご紹介します。
Ｐ40
新統合システムのプロジェクト初期段階では、業務部門とシステム部門が一体になって作業を行った。まず概念データモデルを作成した。モデリング作業には数人から十数人がメンバーとして参加したが、7割が営業、製造、流通、工程計画など業務部門出身者や旧ＮＫＫや旧川鉄の情報システム部門
出身者から成る新統合システム推進班メンバー、３割がエクサやＪＦＥシステムズのシステム担当者だった。
業務担当者が自分たちの頭の中にあるビジネスの姿をモデルに写していった。 2002年ごろの初期段階あるいは2006年以降のグループ会社における概念データモデル作成では、特定非営利活動法人技術データ管理支援協会のコンサルタントがモデリングを支援することもあったが、J-Smile構築では大部分のモデルをＪＦＥスチールが自力で作成した。
そのうち、関係者が他部門も含め全社の業務内容を明確に把握するようになった。自部門のみならず他部門のビジネスのやり方、用語の食い違い、他部門が必要としている情報などが見えてきた。「私の部門のビジネスをデータで表すとこうだ。そっちは、そういう仕組みだったのか。このデータを共
有すれば、お互いにこんな連携ができそうだ」 そんな会話がモデリング中にあちこちに出てきたという。
ITに詳しくない業務担当者でも概念データモデルの設計に入っていくことができたが、モデリング開始直後は、そもそもモデリングとは何か、どうやればよいのかを業務担当者が理解できないこともあった。その場合、システム担当者がコーディネータ役を務めた。業務担当者の頭の中の概念が明確になるように、識別子と呼ぶ管理単位などを質問し、業務で扱っているものとその管理の仕方をデータとしてモデルに写し取るという要領を、業務担当者に教えた。
モデリングが終わって概念データモデルが一通り仕上がると、「漠然と考えていた製品や工程がはっきり捉えられるようになった」と喜ぶ声が業務担当者からも挙がった。ただ、「できあがったモデルは見ると当たり前。何でこんなものを作るのに、これはどの時間が掛かったのか」と思う人も出てきた。
システム担当者から見るとそういう感想が出るのが望ましいという。「他部門も含めてみんなで話し合いながら、業務の認識を合わせ、問題を共有することができるのが概念データモデルの良いところ。みんなが合意して認識がそろい、当たり前と思うモデルができれば成功だ」（渡部氏）と言う。
概念データモデルは、業務担当者が単独で描くものでもなく、ＩＴ担当者が単独で描くものでもありません。その主たる目的は「業務担当者とＩＴ担当者の間のコミュニケーションの改善を行い、データオブジェクトやデータ要件について共通の認識を構築する」ことなのです。
また、筆者がいろいろ調べていると概念データモデル＝ＥＲ図（Entity Relation Diagram）としている情報が多いのですが、筆者は、概念データモデルはＥＲ図を含むもっと大きな領域をカバーしているものだと認識しています。
ガイドでは以下のように続きます。（タイトルとサブタイトルのみ掲載します。）
勘どころ① 管理対象のバリエーションを整理する
•管理対象の種類の整理
•漏れなくダブりなく整理せよ
（ミッシー (MECE : Mutually Exclusive and Collectively Exhaustive)になるように分類
する。）
•名前のない分類に名前を付けよ
•用語の定義として共通認識せよ
•企業文化に依存するので注意せよ
勘どころ② 管理対象のバリエーションを削減する
•分類の廃止を検討せよ
•分類の統合を検討せよ
勘どころ③ 業務ルールと照らし合わせて概念データモデルを描く
概念データモデル (ER図)は業務を表現するモデルである。業務は、業務の管理対象を扱うものであり、業務で扱う管理対象であるデータやそのデータに関する業務ルールを調査し、エンティティとその関連として構造化した概念データモデルは、実業務の管理過程をよく表している。（以下略）
勘どころ④ 工夫して業務部門と確認する
ここに列挙された事項は、すべて概念データモデルの作成過程で行われることの一部であり、筆者としては「概念データモデルを業務担当とＩＴ担当が協力して作成しましょう。」と一言で収まってしまうと考えます。ガイドでは概念データモデルの作成方法を詳しく説明しては下さっていないのが残念な感じがします。