risk = nil;

機能安全については，一区切りつけて，しばらくは，KAOS法について書いてみたいと思う．ただ，概説を書くつもりはなく，Lamsweerde氏の著書 ¹を吟味しながら，思うところを書いていく．興味のあるところは，先になかなか進まないと思う．ちなみに今回は，最初の2行のみが対象になっている．

さて，メタで考えてみる．要求工学が解くべき問題とはなんだろうか．いま，要求者が何かをしたいと思った．何故思ったかにはいろいろある．(a) 業務上の面倒な手作業に疲れたかもしれない．或いは，(b) パフォーマンスを上げない限り，ビジネスが成立しないという切実な問題に向き合っているのかもしれない．または，(c) 魅力的な製品のデモを見たなどのきっかけで，本当はこんなことがしたかったんだと自分の欲望に気づいた場合である．

(a)(b)の要求分析は簡単で，(c)が難しそうに見えるかもしれない．しかし，難しさの種類は違っても，全て難しいことに変わりはない．

(a) の場合

手作業をシステム化するということは，オーバーヘッドを伴うことが多々ある．今までは，手書きで好きな場所に記録をとっていたのに，そういう融通がまったく利かないかもしれない．また，対象業務のうち50%が仮に10倍速くなったとしても，残りが変わらないと，全体の効率UPが50%を超えることはないという見落としがちな現実がある．システム化による手間で，その効果も相殺されているかもしれない．今のプロセスをシステム化によって変更した時の新たなプロセスは，想像が難しいというのが，困難さの一番の理由だろうか．体験のみがイメージを作る．

(b) の場合

この場合の切実な例は，天気予報である．明日の天気予報のための計算は，今日中に終わらないといけない．明後日になったのでは意味がなくなる．ただ，極端な話としてはそうなのだが，その天気予報であっても，何らかの妥協がなされるに違いない．例えば，必要な時間に終了できるように，計算アルゴリズムを簡略化するとか，提供する情報を可能な範囲にとどめるといったことである．もちろん一般には，これほどの切実さはないだろう．しかし，どの程度の性能にしておけばよいか，といった非機能に類する要求はやはり定義が難しい問題である．

(c)の場合

ビジネスにおいて，個人的な理由から費用をかけてソフトウェア開発がなされるのか？という疑問を持つかもしれない．しかし，大概はそういうものではないかと想像している．Lazzarato氏がいうように，今やソフトウェアに占める「情動」の割合が大きい以上，ますます個人的動機からスタートする場面も多くなっているに違いない．もちろん，この個人は誰でもよいというわけではなく，プロジェクトをスタートさせるだけの力を持った個人ということになる．また個人的な理由が前面にでることもなく，通常は合理的に見える説明が表に出る．こうなるととてもややこしい．表面上の話には，「こうしたい」というのが現れていないわけだから，普通には分析しようがないということになる．

Lamsweerdeさんが言うように，問題定義は容易ではない．解くべき問題が定義できたときに，問題は解決しているという言葉が，頭をよぎる．

（nil）