risk = nil;

システムというのは，本質的に（コンポーネントの）合成である．しかし，コンポーネントの相互作用から立ち現れてくる大域的な特性を通じて，システムを知ることができる．(p. 4)

とても，興味深いシステムの描き方である．

ちなみに，ここでのコンポーネントというのは，ソフトウェア開発でいうコンポーネントとは異なっている．作ろうとする（或いは作った）ソフトウェア自身は，それ自体で一つのコンポーネントである．他のコンポーネントとしては，以下がある．

• 人々ないしは，特定の組織の方針に従ってある役割を果たす事業単位
• 物理法則に従う特定の規則の下で動作する物理的なデバイス（例：センサー，アクチュエーター，測定器具，通信媒体）
• 他のソフトウェア．レガシーなソフトウェアや利用している商用ソフトウェアで，相互作用する必要があるもの

コンポーネントは，それ自体はブラックボックスである．トートロジー的な説明のようにも思うが，そういうコンポーネントを措定することは実務的に可能である．そうすると，コンポーネントの合成であるシステムは，（ブラックボックスであるコンポーネントの中身は見えないので）唯一観察可能なコンポーネントの相互作用を見るしかない．

例えば，発券システムとは，顧客と駅員の相互作用（会話）があって，機械を通して発券される．乗車券は，改札の機械において，（乗車券・改札の機械の相互作用において）問題なく認識される．

現状システム（system-as-is）を知るというのは，ここからスタートする．

ちなみに，リクエストと全く異なる発券をしてもらったことがある．Luxembourgの駅である．片道でよいというのに，往復の乗車券を提示された．乗車券の料金が日によって変動する欧州ならではかもしれない．往復のいわばセット料金が，片道の正規料金より安かったので，駅員さんが気を利かせてくれた ¹．

ここでの相互作用から，料金の変動があることを，観察を通じて見ることができる．そういうことは，要求として書けば済むのではないかといわれれば，その通りだろう．ただ，それでも抜け落ちる特性はあるかもしれない．抜け落ちてしまったものは，観察を通じてしか見つけることができない．

書けば済むというのは，要求者が全てを整理し把握しているということを前提としている．また，人は（私のように）想像界から決して抜け出ることができない以上，必ず抜け落ちる要素がある．その要求を受け取る側も同じであり，象徴界を具現化した要求書が全てではない．

(nil)