ユーザーの思いを汲み取り、論理モデルに落とし込む
システム開発の作業を困難なものにする大きな要因として挙げられるのが、開発側とユーザーの間のコミュニケーションギャップだ。それはシステムの仕様を決める段階から発生しており、「要求仕様」を引き出すことと「要件定義」自体を行うことを混同しているケースも多いと赤氏は指摘する。
「要求」とはユーザーが情報システムで実現したいことであり、「要件」とは要求を踏まえて情報システムに落とし込むべきもの。開発側としてはどうしても要件定義を急ぎがちだが、まだ要求が明確でない段階で要件定義を進めようとしても歪みが生じ、1つ1つの機能が無駄に膨らんでしまう。 要求と要件を整理するためには、最初の上流工程が重要となる。システム開発を川の流れに例えれば、ユーザーが本当にやりたいこと、つまり「要求」が源流であり、そこから流れ出す思いを汲み取って整理し、下流への流れを作るのが上流工程の役割といえる。
また、赤氏は上流工程について「システムのプロと業務のプロとの間で相互翻訳作業を行う工程」とも表現し、単にシステム屋（開発側）が業務屋（ユーザー）の言葉を翻訳するのではなく、相互に理解し合うことが大事だと強調。その際、「おもてなしの心がとても重要になる、お互いを思いやる気持ちがなければ相互理解は難しい」と述べた。
さらに、上流工程を「論理モデルを作成する工程」と捉え、上流工程のアウトプット（成果物）は「何を作るか」を明確にした論理モデルであり、それは「下流工程のインプットとして役立たなくては意味がない」とした。
リポジトリによる一元管理で3つのモデルの精度を高める
続いて赤氏は、上流工程における「翻訳の元ネタ」として使うモデルについて説明。まず、ビジネスの静的側面をデータモデル、動的側面をプロセスモデルで表す。そして、静的側面と動的側面の交点を、CRUDマトリクスで表現する。下流工程ではいろいろなモデルを使う必要が出てくるが、上流工程においては、この3つのモデルの精度を極限まで高めることを赤氏は重視している。それは、最小の管理（成果物）で最高の成果を得るためだ。また、データモデルもプロセスモデルも、「トップダウンで骨組」を作り、「ボトムアップで肉付け」することを原則とすべきだという。
データモデル、プロセスモデル、CRUDマトリクスを、例えばExcelやVISIOなどでそれぞれ作り、手作業でブリッジするという方法で管理することもできないわけではないが、規模が大きくなればなるほど、手作業の管理では無理が生じる。Xupper IIを活用すれば、これらをリポジトリにて一元管理し、わかりやすい形にまとめることが可能だ。赤氏はその点を、「これだけきちんと一元管理できるツールは、なかなか存在しない。まさにケン・システムコンサルティングの企業コンセプトでもある『究極の生産性と品質向上の追及』を実現してくれるツール」として、高く評価している（図1）。
