アジャイル開発は文書が少ない分、コミュニケーションの善し悪しで成功するかしないかが分かれる開発方法だと思っています。そこで、ビジネスチーム（ユーザ側）と技術者（ベンダー側）との間で要件の誤理解がないように防ぐ工夫をおしえてください。特に、ベンダー側の工夫ではなく、ビジネスチーム側の工夫として、ベンダーが誤って要件を理解していないことを確認するような手法があると望ましいです。もしくは、ビジネスチーム側が持っている無言の前提をきちんと共有できているかどうか、などというところも重要だと思いますので、そういったところを確認する術があれば教えてください。

＞アジャイル開発は文書が少ない分

これは誤解です。文章を多くすることも可能です。

アメリカでは契約社会ですが、

文章に書かれていない要件に関して保障をえるのは難しいです。

＞ビジネスチーム側の工夫として、ベンダーが誤って要件を理解していないことを確認するような手法

要件の文章とともに

必ず数例の実例を明記

要件が理解できなくても、入力と出力例で最低限理解できるようにしておく

＞ビジネスチーム側が持っている無言の前提をきちんと共有

無理です。どんな開発手法を使っても無理です。

アジャイル開発では重要なことは、無理なことは無理と認め、努力しないことです。

無言の前提を共有なんてできません。できないというスタンスから、できなくても問題の内容に考えるのが

アジャイル開発の考え方です。

アジャイル開発の特徴に反復があります。

何度も同じ工程を行うことで、精度を高める手法です。

要件が間違って伝わってないかを何度も確認する手法を導入すべきです。

正しく伝わることに努力することよりも、間違って伝わったことを検出する方法を導入すべきなのです。

上記にあげるように、サンプル例をIN-OUTの形で提示するのも、検出する技法のひとつです。

アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)
ディーン・レフィングウェル 玉川 憲

具体的にはセッションノートの他にはどのような文章でしょうか？

セッションノートは単なる議事録です。

それよりも、以下のドキュメントの方が重要です。

• 開発標準
• 成果物共有方式
• ストーリー＆プラニング
• コードレビュー
• リファクタリングレビュー
• 受け入れテスト成果

ウォーターフォールモデルとアジャイルの違いは、

単に、前工程に戻ることを許容するかしないかの違いです。

アジャイルの開発手法を導入してるところでも

文書はほとんど、ウォーターフォールモデルと同じところがほとんどです。

ご存知のとおりアジャイル手法もだんだん考え方が変化してます。

http://d.hatena.ne.jp/mnishikawa/20100410/1271463563

＞コミュニケーションの善し悪しで成功するかしないかが分かれる開発方法だと思っています

これは、どの開発モデルでもそうです。

ウォーターフォールモデルでも同じです。