“コラボラティブである”ために（1/2）
要件をだす側と開発側とのコラボレーション
“欲しいモノ”と、“手に入ったモノ”とのギャップが、アジャイルへの関心を集める理由のひとつであることは、疑う余地もありません。要件をだす側と開発側とのコラボレーションに関して、アジャイルが従来のやり方と異なるのは、「要求定義活動の成果物に対する、詳細度・完成度の考え方」ではないでしょうか？
いまだ主流のウォーターフォール型の手法では、要求定義期間の中で、ソフトウエア要求仕様（以降は簡単に仕様としましょう）を早期に確定することを試みます。仕様の表現形式は、ER図、フローチャート、UML、そしてフリーテキストとさまざまありますが、共通するのは最終的に作成された仕様内容は、検証可能なレベルまで詳細化されかつ具体化されることを基本とする、という点です。 いいかえれば、成果物である仕様書は、それ自身が検証に耐えうるだけの厳密さを持つ必要があります。
ユーザー部門の要望というものは、具体性の度合い・詳細度はさまざまです（ある人は画面や操作を事細かに指定する一方、別なマネージャーは「うちにも”Amazon”作ってくれ」なんて言ったりする）。マーケティング部門やビジネスコンサルタントなどが絡んでくると、各種の調査結果や気高い理論（;o;）が、入力情報として考慮されたりもします。
それら多様な情報をまとめ上げ、最終的に検証可能なレベルの仕様書として確定する作業が重視されます。この決定過程を関係者の同意を得ながら進めるために、いわゆる要求管理モデルを作成します（図2：従来型の要求管理モデル)。適切な詳細度や具体性、およびその関係（目的と実装の関係）に合わせて、要求事項を整理するためのモデルを必要とするのです。
アジャイルの良さを殺してしまう原因
アジャイルな開発スタイルでは、極論を言えば要求管理を必要としません…というよりも、「毎日が要求管理」と言ったほうが適切でしょう。解決すべき課題に対して、システムが提供すべき機能性（フィーチャーとかユーザーストーリーですね）をラフなままでもリストアップしその優先順位付けに重点を置きます。おのおのの詳細は、それを実装するタイミングでやればよい、というアプローチです。
代表的なアジャイルアプローチであるSCRUMでは、プロダクトオーナー（Product Owner）がリリース時に製品がどういう状態になっているべきか（どのような機能性を有しているべきか？）をコントロールします。
しかし、利害関係者が多くなったり、あるいはプロジェクト規模が拡大して対処すべき要求事項が増大した場合には、制御可能な範囲を超えるリスクが高まります。具体的には、次のような事象がアジャイルの良さを殺してしまう恐れがあります。
- 本来顧客を巻き込むことによって、文書でのコミュニケーション以上の深い理解を共有するはずが、そもそも利害関係者が多くて対応しきれない。また、勤務地もばらばらで、情報が伝わらない。
- 「コードで会話する」を重視すると、詳細を議論する機会が従来よりも遅くなる。システムの仕様の詳細を開発時に議論するのはまっとうとしても、従来であれば仕様提示の前段階で議論尽くされているべきビジネス的な背景についてもタイミングが遅くなり、収拾がつかなくなる。
- 多様な利害関係者は利害が異なり、システム開発に関する素養も異なる。要求の表現の仕方も多様になる。従来行われていたようなきちんとした要求管理モデルの体系にそもそも当てはめることが難しい。また、その体系に整理していくための時間が取れない。
このような事象は、利害関係者が必然的に増えてしまうという意味で、製品開発よりもむしろシステムインテグレーションビジネスの現場でよく見受けられます。SCRUMのような運営をそのまま規模拡大するには無理があり、それなりの意思疎通のやり方を別途検討する必要があることは明らかですが、ツールとしてこれを実現するために必要な要件とは何でしょうか？次ページから見ていきましょう。
