risk = nil;

問題解決が持つ再帰的な性質は，問題空間と解決空間を，絡み合わせる (p.44)

昨年ICSEに出かけたときに，一日だけツインピークスという，そのときが二回目となるワークショップに出席した．場所がサンフランシスコだから，こういう名前がついたわけではない（そもそも第一回は別の場所であった）．

ツインピークスという二つの山頂のうち，一つは要求を示している．もう一つは，アーキテクチャを示している．

議論になったのは，そもそもこの両者の間にギャップがあるのかないのかという話だった ¹．ないとみんなが思っていれば，こんなタイトルをつけることはないので，主催者がギャップがあると心の中で思っているか，少なくとも，それは共通認識としてあると考えているに違いない（この場合，同時にギャップを埋めることは可能と考えている可能性が高い）．

午後2時間ほど，小グループに分かれて議論した．「ツインピークスと空間（これまでも何度か出ている問題空間・解決空間，あるいは，世界と機械といった空間）」というテーマのグループに入った（全部で10名ほどだっただろうか）．

私の主張は次の通り．

両者のギャップは本来的なものではなく，他の要因（例えば政治的に）決まる．共に適切にモデル化すれば，シームレスに繋ぐことは可能である

自分では気に入っていたが，なぜか，とても評判が悪かった．

さて，KAOSに戻る．要求分析は，プロジェクトの初期段階で実施する．従って，様々な他のアクティビティと関係する．

• ソフトウェアプロトタイピング
• アーキテクチャ設計
• ソフトウェア品質保証
• 実装と統合
• 文書化
• 保守
• プロジェクト管理

もちろん，これらアクティビティの入力となる．しかし，単なる入力では済まず，相互に絡み合うのである．

実現が見えない要求は，そもそも成立しない．アーキテクチャを考えたときに，要求が示している性能は，そもそもがムリだと分かったとする．そうなると次に要求に戻って，システムの目的が達成可能な妥当な線を見つけないといけない．前回でいえば，新規開発でラディカルな設計を必要とするタイプはそうなる．或いは，アーキテクチャを考えたときに，実は見落としていた要求があることに気がつく．そうすると，新しい要求項目を追加する必要が生じる．

この「絡み合い」は，何も要求とアーキテクチャに限ったことではない．山頂は，あちこちにある．しかし，プロジェクトのタイプによっては，一度深い谷におりないと，隣の山頂には行けない（ISO 26262 におけるDIAによるやりとりはその一つだろう）場合もある．

ただ，このことは，一般論（世間の常識？）としての要求と設計の間にあるギャップではなくて，文脈上そのことを考慮すべきというだけに過ぎない．両者は本質的にはつながっている．谷を作るのは，政治的人間であり，それには理由のある場合とそうでない場合がある．

(nil)