先日，Science 誌をつらつら眺めていたら，Wrens（ミソサザイ）という小鳥がデュエットするときの神経学的調整機構に関する論文がありました（DOI: 10.1126/science. 1209867 著者による動画はここです．実際にデュエットを聞くことができます）．ミソサザイは，常にあるパターンに従った鳴き方をするのではなく，相手の声に反応して，素早く自分の鳴き方を変える．それによって，デュエットが成立します（勝手に雌雄で歌っているわけではない）．そのためには，一般に鳥が鳴くときに動作するHVCニューロンとは異なる回路，例えばCPG（中心パターン生成器）が関与するのではというのが，論文のテーマになっています．
***
さて，今回は機能安全における成果物のうち文書について考えてみたいと思います．文書というのはこうすれば良いという正解があるわけではなく，あくまで書き手ー読み手間の関係で定まります．技術文書といえどもその構図は変わらないだろうと思います．本当は，黙ってても伝わるというのが良いのでしょうが．
少し前に，文書チェックをお仕事となさっているから正しい技術文書の書き方といったお話しを伺って，幾つか昔のことを思い出しました．文書は，時間的・地理的に離れた人とコミュニケーションする上でソフトウェアの世界でも重要なものです（そもそもプログラムは，ある種の文書です）．最初に，一般的な技術文書が持つべき特性について考えます．IEEE Std 830-1998（ソフトウェア要求に対する推奨される実践，以下IEEE文書）という文書があります．特にSRS（ソフトウェア要求仕様書）を書くときにとても参考になるガイドラインです．ここで，SRSは，次のような特性を持つべきとしています．
- 正確である
- 明白である
- 完全である
- 一貫している
- 重要性，そして/または，安定性に従ってランク付けされている
- 検証可能である
- 修正可能である
- 追跡可能である
このうち，今回は (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の管理をみると，前者に関する内容が主になるので，どういう表現かというよりは，安全要求の論理構造を議論していると考えた方がよさそうです．もちろん，その方が自然な気もしますが，表現に関する規定も含んでいるので分かりづらくなっています（本来，論理構造と表現は不可分です）．
さて，自動車の場合は一般にOEM-サプライヤの境界が存在します．この部分のインターフェイスは26262では，DIA（Development Interface Agreement）でとることになります．もちろん，この3文字で済ませても良いのですけれど，実際にDIAに記述されるべき内容は，ライフサイクル上の位置によって異なることになります．従って，かなり悩ましいことになりそうです．先の書き手ー読み手間の経済合理性を考慮した文書化というのも，OEMーサプライヤのインターフェイス位置によって表現を変える必要がでてきます．部位によって概ねそのインターフェイス位置は，現実的に決まっているとすれば，それに応じて適切な表現レベルを*合理性に基づいて*定めると云うことになるのだろうと思います．
***
ミソサザイのデュエットの話ですが．記事を読んで，少しショックを受けました．デュエットをリードしているのは，必ず雌とのこと．むかし，ペアのダンスをしていたことがあります．そのときに，注意されていたのは，リードするのは男性なのでしっかりしなさいと．陸上のダンスも，氷上のダンスも同じです．しかし，遠い目で，昔を振りかえってみると，決してリードしていたわけではなく，リードしやすいようにリードされていた気がしてきました．すべからくそうなのかもしれません．
(nil)