開発プロセスとは、ユーザとの共通認識を作っていくプロセスである

システム開発には多くのメンバーが参画します。それぞれのメンバーがシステムに対するイメージを持っているわけですが、このイメージは各メンバーの頭の中にある漠然としたものです。

開発が進むにつれてシステムがどんどん具体化していくことによって、それぞれのメンバーのシステムに対するイメージも徐々に共通認識として明確になっていなければなりません。

しかし、実際にはシステム開発も終盤のテスト工程になって、はじめてシステムのイメージが異なるということが発覚することが多発します。

それは、システムが目に見えないものであるといことが大きな要因です。

システム開発が徐々に進んでいき、より具体的なものになっていくとしても（ウォーターフォールを前提にしています・・・）、実際にユーザの目に明確な形で入ってくるのは、プログラム開発が終了した時点（すなわち、テスト工程に入れるようになった段階）であることが多いからではないでしょうか？

プログラム開発が終了した時点（テスト工程が開始された時点）になってはじめて欠陥（プログラムのバグだけではなく、仕様の漏れや仕様の誤りを含みます。）が明らかになってくるということになれば、当然手戻り工数が大きくなっていきます。

Xupperの方法論では、まず、論理モデル（業務モデル）を明確にして、その後に物理モデル（実装モデル）を定義していくという手順にこだわっています。

それは、開発側とユーザ側でシステムに対する共通認識を醸成するための有効な手段であるからです。

この論理モデル（上流工程の成果物）について、ユーザとの共通認識を得ていく必要があるわけです。

ウォーターフォール型の開発の場合は、各工程ごとに成果物についてユーザ承認をとって次の工程に進むという手順を踏むわけですが、このユーザ承認というものが形式だけになっていた場合は、あまり意味がありません。

ユーザ承認というのは、その時点でのシステムに対するイメージが開発側とあっているかどうかの確認を行う行為と捉えるべきです。
成果物を認めてもらうということを目的とするのではなく、システムに対するイメージが合っているかどうかを確認してもらうということが、ユーザ承認の目的であるべきです。

開発側としては、「次工程の作業のよりどころとなる成果物について、ユーザに承認を頂きたい」と考えるわけですが、その目的は開発側にとってのよりどころを作る（後から何か言われても反論できる根拠を作る）ということではなく、お互いが共通認識としている部分を確認するということであるべきです。

システムを開発する過程では、このような承認行為（共通認識内容の確認）を繰り返して実施することにより、開発者とユーザは同じ認識を持つに至るわけです。

ある意味、お互いが歩み寄るということが必要になってくるのです。

開発者にとってみれば、ユーザ業務をより理解する（業務ノウハウを身に付ける）ということであり、ユーザにとってみればシステムの内容を理解するということが必要不可欠な行為になります。

別の表現でいえば、お互いがお互いを教育していくということを、繰り返し実施していくということです。

ユーザは業務のプロですから、業務についての教育を開発者に対して実施する必要があり、開発者はシステムのプロ（のはず）ですから、システムのあり方についてユーザに十分説明する責任があるはずです。

そういう相互のやり取りを繰り返すことにより、対象システムに関する共通認識を持つに至るわけです。