先日，Science 誌をつらつら眺めていたら，Wrens（ミソサザイ）という小鳥がデュエットするときの神経学的調整機構に関する論文がありました（DOI: 10.1126/science. 1209867 ここ です．実際にデュエットを聞くことができます）．ミソサザイは，常にあるパターンに従った鳴き方をするのではなく，相手の声に反応して，素早く自分の鳴き方を変える．それによって，デュエットが成立します（勝手に雌雄で歌っているわけではない）．そのためには，一般に鳥が鳴くときに動作するHVCニューロンとは異なる回路，例えばCPG（中心パターン生成器）が関与するのではというのが，論文のテーマになっています．
***
さて，今回は機能安全における成果物のうち文書について考えてみたいと思います．文書というのはこうすれば良いという正解があるわけではなく，あくまで書き手ー読み手間の関係で定まります．技術文書といえどもその構図は変わらないだろうと思います．本当は，黙ってても伝わるというのが良いのでしょうが．
正確である
明白である
完全である
一貫している
重要性，そして/または，安定性に従ってランク付けされている
検証可能である
修正可能である
追跡可能である
このうち，今回は (2) の明白であるというのを取り上げてみることにします．ここでの明白さというのは「記述された要求がたった一つの解釈しか持たない」ということなのですが，様々なコミュニケーション理論が示すように，これは簡単なことではありません．どのように書いたところで，書かれたものの解釈は，多義性から逃れることはできず，多少なりとも保証してくれるとすれば，それはコミュニティ内の約束を前提とするしかありません．先の文書でも次のような注意事項があります．
“…しかしながら，これらのグループは，しばしば同じバックグラウンドを持つというわけではない．従って，同じような流儀でソフトウェア要求について記述しない傾向がある．開発者が要求仕様を変更した時の表現は，ユーザにとっては理解しづらくなる可能性があるという意味で，生産的でない可能性がある．逆も同様にあり得る． “
書き手ー読み手間の経済合理性 しかないのだろうと思います．誰も読まないと思えば，書かない．チーム内の同じ技術者が読むと思えば，同一の土俵上で，最小限の記載を行う．この合理性を考慮しない技術文書の書き方はおよそ意味がないだろうと思います（もちろん，時間の経った書き手は読み手でもあります）．もちろん，とりあえず作ったソフトウェアが長く使われるのだけれど，文書がなくて困るということも沢山あるだろうと思います．しかし，予知能力が人間に備わっていない以上，そこにはやはり経済合理性を求めるべきだろうと思います．逆に，そういう自体に対処できるソフトウェアであるべきということだろうと思います．およそ，このように合理性を考慮しないとアリバイ的文書だけが存在して，結果的に明白さを著しく損なう気がします．
***
ISO 26262では，機能安全に関する成果物が定められています．そこでの成果物の構造は，とても興味深いのですが，また別の機会に書きたいと思います．ここでは，成果物の持つ特性に対する規定をみたいと思います（ISO 26262-6 6. Specification and management of safety requirements）．安全要求の特性として以下を挙げています．対応とあるのは，先のIEEEの文書で要求している特性の番号です
a) あいまいさがなく，理解が容易であること 対応：（2）
b) 原子的であること 対応：?
c) 内部では一貫性のあること 対応：(4)
d) 実現可能であること 対応：?
最初の「あいまいさがなく，理解が容易」というのは，必ずしも，「明白である」こととは一致していません．しかし，概ね意図していることは同じと云って良いと思います．読み手側に対する配慮になります．b)の原子的であることというのは，特定のレベルで考えたときにそれ以上分割できないということを示しています．こちらは，要求の記述と云うより，そもそも要求がどのように識別されるかということであり，IEEE文書には含まれていません．c)の一貫性については，IEEE文書の(4)に対応します．この(4)は，内部での一貫性と外部との一貫性の2種類の意味がありますが，26262では，6.4.2で内部の一貫性を，6.4.3で外部との一貫性を要求しています．d)は，安全要求が実現可能であるか否かです．こちらも，成果物の特性と云うよりは，要求の特性だろうと思います．或いは，一般には要求の実現可能性とは，要求と別に議論されるべきで，要求に含むのは違和感があります．書くとすれば，IEEE文書にある(5)のランク付けによる色分けに対応可能かも知れません．総じて，IEEE文書は，SRS文書がどう書かれるべきかということに重点を置いているのに対して，26262では，安全要求はどうあるべきかということ，文書記述を混在させているように見えます．6.4.3の管理をみると，前者に関する内容が主になるので，どういう表現かというよりは，安全要求の論理構造を議論していると考えた方がよさそうです．もちろん，その方が自然な気もしますが，表現に関する規定も含んでいるので分かりづらくなっています（本来，論理構造と表現は不可分です）．
***
ミソサザイのデュエットの話ですが．記事を読んで，少しショックを受けました．デュエットをリードしているのは，必ず雌とのこと．むかし，ペアのダンスをしていたことがあります．そのときに，注意されていたのは，リードするのは男性なのでしっかりしなさいと．陸上のダンスも，氷上のダンスも同じです．しかし，遠い目で，昔を振りかえってみると，決してリードしていたわけではなく，リードしやすいようにリードされていた気がしてきました．すべからくそうなのかもしれません．
(nil)
構成管理をイメージしてみます．各構成品目が複数あり，それらを横に並べます，各品目は，図面でいえばサフィックスが増えていくように，プログラムでは各コンパイル単位のバージョンが増えていくように，速度差はあっても時間軸方向に縦に伸びていくとします．一つの構成・ベースラインはそれらに横串を刺したものとなります．私には，ベースラインは，波のようにイメージできます．
11月の葉山海岸（SPIN世話人会のあとで）
ソフトウェアの世界でここ十年ほどでよく使われるるようになった構成管理ということばは，もちろん，Configuration Management の訳語です．別の訳語もあります．形態管理という言葉で，いまでも航空宇宙の分野で良く使われていると思います（私は形態管理という名前で最初に覚えました）．
***
ハードウェアの場合は，完成品を頂点として，多数の部品を組み合せることで成立します（自動車の場合は，何万点の部品という云い方がされますが，アッセンブリレベルでの指定が多いので，ある車に関して，実際に部品表に記載される数はそれほど多くはないでしょう．また，概念的には木構造を構成しますが，構成はフラットに表現します）．この組合せにより，一つの＜形態＞が生まれます．
***
私が，形態管理という言葉を知ったのは，MIL-std-1679Aという規格です（これは以前にアイテムの回で触れました）．その後継となったDOD-std-2167Aでは，形態管理に関して興味深い使い分けをしていました．2種類の形態管理があります．一つは開発時の管理であり，もう一つは，出荷時の管理ということです．先の二つの訳語を用いると，前者が開発時の＜構成＞管理ですし，後者が出荷時の＜形態＞管理と対応しているということもできます．この区分は形態・構成管理を考える上できわめて重要になります．一つは経時的な問題であり，もう一つは発注者ー受注者問題です．
***
しかしながら，形態・構成管理を実務に適用しようとする場合に，考慮すべき事柄は上記に限定されるわけではありません．先ほど経時的な問題を考えましたが，より長い時間スパンにおける経時的な変化がその一つです．例えば，モデルチェンジを行うような場合（ソフトウェア的にはバージョンアップでしょうか）にどう対応するかといことがあります．このときは，（形態・構成管理がきちんとなされていると前提で）変更管理の枠組みを適用することで，多くの場合は対処可能です．逆の云い方をすると，製品が変化するのは必然なので，形態・構成管理と変更管理は，本来不可分だということになります．
***
さて，ここまでは一般的な構成管理の話になります．機能安全（例えば，つい最近発行された ISO 26262を例にします）についても基本は同じだろうと思います．結局はテストしましょうということで一般のプロセスの枠組みを用います．しかし，このままだと，一般のテストと同じ構図で，不具合の不在証明はできないという議論に辿り着きます．或いは，ここまでの構成の議論で考えた多様な変異に対しては，「全ての構成をテストすることが現実的でない場合，合理的にサブセットを選択しても良い（Part8 9.4.2.2 (c)」ということになっています．しかし，機能安全は最後の砦であり，全ての不具合を防止することを意図しているわけではない．あくまで安全性に関わる機能の故障に特化しているのですから，網羅性が担保されないのだとすると，「合理的構成の組（reasonable subset）」のみを選択してテストということが，該当する場面はないように思います．構成管理というのはきわめて色々議論されて安定した枠組みですが，こと機能安全との関係（更にはSILとの関係）を考えるときに，いろいろと議論すべきことがあるように思います．
(nil)
先日の日曜日，桐生市の無鄰館で，金原寿浩さんの展覧会にでかけてきました．「黒くぬれ！」がテーマで，福島原発事故をモチーフにしていました．墨で書かれた無残な建屋は，リアルな写真で見るよりも，心に残ります．今回は，コンピュータを用いたインスタレーションの可能性について，少し可能性を議論したのですが，お互い得意とする表現分野が異なるので，伝え合うのは難しい．
***
さて，今回は良く云われる「要求」のあいまいさについて考えたいと思います．いつも気になるセリフに「要求」が曖昧だからソフトウェアが作れないというのがあります．多くの場合，これは間違っています．例えば，誰かに竜の絵を描いてもらおうと思います（来年は辰年ですし，二年連続日本シリーズおめでとうというのもありますね）．
このとき，飛翔している姿にするか，どこかに潜んでいる姿にするか位は伝えた方がよいかもしれません．しかし，ヒゲの長さは，体長の12.98765%にすることとか，爪の幅は，耳に対して，1/11.23581321345589にしなさいとかはいわない．その数字が竜を表しているわけではないからです．事後的に，細かな数字をいうことは可能でしょう．しかし，それでは要求にならない．
この時点で，先の要求は十分に正確なのです．抽象度に応じて，必要な記述レベルは自ずと定まります．それをムリに記述しなければならないとするのは，誤りです．
では，仕様はどうかという議論もあります．要求は形式化の行為を経て仕様になります．ここでの形式性には，何らかの数学的な背景（例えば集合であったり時間的なふるまい記述）や，物理法則があります．その範囲では，或いはその側面では，無矛盾を担保できます．
ただ，ここにも問題があって，先の12.98765%を仕様として書くことはできますが，機械的に導出することはできません．それが可能なのは，線形で発展するシステムだけで（即ち，既存のささやかな改修），それ以外は別の手段をとる必要があります．形式性の持つ有効性は，あくまで存在するもの或いはコトの*形式上の*記述であること，また，形式性は新たなものを生み出すこととは別のことになります．
***
金原さんとは，先月末に同じ場所で個展を開かれた岸田孝一さんのパーティで知り合いました．岸田さんは画家として表現なさるのですが，「作者の意図を伝えない，そもそも意図はない」ということをおっしゃられます．誤解しているかも知れませんが，意図なき表現は，形式性を排除できる．また，より自由な表現を可能にすると，と理解しています．しかし，それもまたメタには意図だとすると，つくづく表現するということはムヅカシイと思います．
(nil)
