risk = nil;

要求工学プロセスにおけるよりよい素早さ（Agility）は，前述のソフトウェアプロジェクトにおける障害に対処できるかもしれない．(p.53)

この節は，いわゆるアジャイルプロセスの話である．アジャイルプロセスとは，早い段階で，かつ継続的に顧客に機能を示すことで，要求工学に関わる労力と，要求からコードまでの距離を減らすることを目的としている．これは以前のスパイラル図をより早く回転させることを意味する．

しかし，このアジャイルプロセスを可能とするには，下記に示す前提があるとしている（ちなみに，アジャイルプロセスといっても様々な方法があり，ここで筆者がイメージしているのは，XP（eXtream Programming）だと思う ¹）．

• 全ての利害関係者の役割は（顧客やユーザの役割も含む），一つの役割に集約できる
• プロジェクトは，十分に小さい．そこでは，小さなサイズで同じ場所にいるたった一つの開発チームを割り当てることができる
• ユーザは，開発場所にいることが可能である．或いは，素早くかつ効果的に開発メンバーとコミュニケーションがとれる
• プロジェクトは，十分に単純である．また，クリティカルなシステムを対象としない．そこでは，非機能的側面・環境における前提・重要な目的・代替策・リスクをムシできるか，重視しないで済む
• ユーザーは，次の追加機能をどうするかを，素早く・一貫した内容として，示すことができる（従って，コンフリクト管理は不要である）．かつ，重要なものから，そうでないものへと順序立てて示すことができる（従って，優先度付けは不要である）．
• プロジェクト管理では，作業の調整や製品の保守のための文書を必要としない．コーディング前の正確な要求仕様書など，問題ではない
• コーディング前の妥当性確認は，早くリリースするためには，さほど重要ではない
• 新しい，ないしは変化する要求は，コードのリファクタリング・書き換えを必要とせず，製品保守を担当するのは，開発した人間で良い．

もちろん，これは極端な場合であり，実際には通常の開発とアジャイルプロセスの間にはスペクトルがある．しかし，素早さを求めるのであれば，他のアプローチもあるというのが，Lamsweerdeさんの主張である．

• ユーザにとっての価値としての機能的なゴールとシナリオを用いる
• 必要な場面では，漸次的な精緻化と分析に対する規範的な形式化に注目する
• 種々の経験的知識とパターンを用いて，モデルベースの要求工学におけるガイダンスを提供する
• 事務作業を減らすことができる統合的なツールサポートを行う

これが，KAOSを通じて，Lamsweerdeさんが，提案する方法ということになる．

(nil)