技術者のための仕様書の読み方と書き方
―特別編―
書誌
| text | 唯野 |
| author | 藤倉俊幸, 金澤典子 |
| publisher | CQ 出版社 |
| year | 『Interface 2001.7 別冊付録』 |
履歴
| 2001.6.21 | 読了 |
| 2001.6.21 | 公開 |
| 2001.9.5 | 修正 |
感想
なかなか魅力的なタイトル(?)の記事。元々は Interface 誌での連載を再構成したものだが、連載時には難しそうで読んでいなかったため、こういうかたちで読む機会を得ることのできたのは幸いだった。しかし、文学理論を始めとする専門知識を背景にした「仕様の理解」というのは貴重な反面、やはりとっつきにくさがあるように思う。(特に 2 部構成のうち、第 2 部である「オブジェクト指向手法と仕様書」は文学理論色が強いため割愛した。本来ならば、ここまで読むべきなのだろうが...)
抄録
第1章 それはレトリックの問題か ?
システム開発は仕様書を受け取り成果物を納品することでサイクルを全うする。そこで第 6 章まででは仕様書におけるプログラム変換可能な論理性について考察する。第 1 章では文章のレトリック(rhetoric)によって生じる曖昧さ(解釈に対するグレーゾーン)の問題を考える。
仕様書は技術的要求事項とその実現手段を述べたものだが、それだけではなく履行を含めた契約書の一部という側面を持っている。日本語における多義性は語順や読点である程度避けることができる。また、数式を使える場所では数式を使い、列挙する項目の多い場合には箇条書きにする。そして、排他的論理和と包含的をはっきりさせなかったり余計な装飾を行うと、意味が分かりにくくなる。
[MIL 規格における助動詞の用法] shall 仕様書で拘束力を持つ規定 will ある目的の表明 should 強制力を持たない規定 may 強制力を持たない規定
排他的論理和 どれかひとつだけ
包含的論理和 少なくともひとつ、全部でもよい (and/or などの表記)
二重否定を使うことで主張を弱くするレトリック。「多い->少なくない」など。これに関連した部分否定(All...not...)と全体否定(Any...not...)の曖昧さもある。そのため全否定(すべて)は慎重に使わないと誤解される場合がある。ほかに受身を使うことによる主体の存在の隠蔽などもあるが、逆に仕様書で比喩や反復疑問といったレトリックの使われることはない。日本語特有の助詞の使い方から見ると、「にも」「のみ」「だけ」「さえ」などもグレーゾーンを生じやすい。
これが「読み方」になると経験やリテラシー(素養)などによる外部要因の度合が更に増える。それによるコノテーション(connotation:含意)が変化する。訳の分からない仕様書は一種の精神テストと同じであるが、その場合には書いた人などに問い合わせて全体像を補うための材料を集めなければならない。しかし、それでも材料の揃わない場合には(実際にそういう場合は多い)、推論(仕様書の記述を前提とした演繹)と推理(あくまでも推察)に頼ることになる。
仕様書の場合には目的と手段、目的と理由の区別(ため(為)/for)を明確にしなければならない。類似のものとして「どうして(How/Why)」、助詞の「に(へ:与格/から:奪格)」などがある。
このような自分に都合のよい解釈をしないためにも、グレーゾーンを避けるために以下のような読み替えによる変化を見るのがよい。それが妥当でない場合には仕様を書いた人に確認を取る必要がある。
読み替えの具体例
- 否定形を作ってみる、または肯定形を作ってみる
- 「も/しか/のみ/だけ/さえ/でも」などの助詞を取っみる、または挿入してみる
- 「〜ならば〜とする」の「ならば」を「なのに/だけど」に変えてみる
- 単数名詞を複数に解釈してみる
- 目的と理由を逆転させてみる
- 語順を変えてみる
- 「または」を「一方のみ」に変えてみる、或いはその逆をやってみる
- 「および」を「または」に変えてみる、或いはその逆をやってみる
- 「明らかに」「確かに」などに対する根拠への置き換えをやってみる
- 「など」「その他」に対する実例を考える
- 「一部の」を「全部の」に変えてみる、或いはその逆をやってみる
- 「常に」を「ときどき」に変えてみる、或いはその逆をやってみる
- 時制を変えてみる
第2章 論理的に明確な表現(否定)
論理学では同時に真にならないことと矛盾していることとは別の命題として扱われる。矛盾というのは完全に真偽が逆転し否定し合う関係をいう。だから、その関係を or でつなげば一方は真なので全体も真になる。これを排中律(law of the excluded middle)といい、矛盾関係ではこれが成り立たなければならない。(つまり一方の真偽が分かれば他方を調べる必要がない。)これに対して矛盾の故事にある矛と盾のような場合は、同時に真にならないというだけでなく同時に偽である可能性がありえる。このような関係は矛盾ではなく反対関係という。(反対関係のそれぞれを否定した場合の関係として小反対もある。)
ここから導き出されるのは「どんな〜でも/すべての/いかなる」といった言葉を強調程度の意味で乱用すると論理関係の曖昧になる場合があるという点である。重要なのは矛盾関係と反対関係をはっきり区別することで、プログラムをシンプルにするためには矛盾関係を仕様書へ明確に反映させなければならない。これは排他的論理和の「または」でも同様で、「〜または〜のどれかひとつ」と明示した方がよい。(排他的論理和はそのまま switch 文に書き換えられる。ちなみにプログラミング言語における or は包含的論理和を示す。)
矛盾・反対・小反対・含意
「以上」の否定が「未満」(矛盾関係)
「以下」の否定が「越える」(矛盾関係)
「以上/以下」は同時に真となることがあるが、同時に偽とはならない(小反対関係)
「越える/未満」は同時に真とはならず、同時に偽となることがある(反対関係)
「未満」が正しければ「以下」も正しい(含意関係)
これらの「以上/以下/越える/未満」は「前/以前/後/以降」と同じ関係にある。(「以前/以降」は起算日を含み、「前/後」は含まない。)
「すべて/いかなる/どんな/どれでも/みんな/いつも/どこでも/なんでも/なにも/まったく」などの言葉の含んだ文章を「全称命題」という。全称命題は例外を認めないので、これらの言葉の使い方が曖昧だと論理性を失う。全称命題の否定ではひとつでも例外のあることをいえばよく、これを存在命題という。例えば「すべての××は○○である」という全称命題の否定は「ある××は○○ではない」となる。定義の間違いを直接的に証明するのが難しい場合には、その定理の否定の正しいことを証明すればよい。
その際、数学では「すべての」を「∀(全称∀:universal quantifier:all の A の逆転)」で、「ある」を「∃(存在記号:existential quantifier:exist の E の逆転)」を使う。
このように矛盾関係と反対関係は自然言語の多義性の中では何に着目するかで変わってくる。これは「してもよい/しなくてもよい/すべきである/すべきでない」でもそうで、「すべきであるということはない」などは誤解を招きやすく、義務は明らかに「すべきである」とはっきりさせた方がよい。同様のことは「可能である」や「必然である」でも当てはまる。
第3章 論理的に明確な表現(推論)
推論における表現の基本は「A ならば B である(A という条件が真ならば B を行う : if(A){B})」だが、これが成り立たない場合は B をしてもしなくても仕様を満足するという解釈ができる。つまり、「A ならば B をする」は「A でなければ B をしない」という推論とセットになることが多い。この場合の後者を「裏」といい、裏を明確にしたいのであれば「A のときのみ B をする」と表現する必要がある。この「のみ」が示されることによって A の必要十分条件が揃うためである。そのため、「A ならば B をしない」という記述は A の如何にかかわらず B をしなければ仕様を満たすことになり、何もしないという解釈が成り立つことになる。
このとき「A ならば B である」の逆「B ならば A である」の裏である「B でなければ A でない」のことを対偶という。しかし、対偶は時間的順序を考慮しないとおかしくなることがある。例えば「叱らなければ勉強しない」をそのまま対偶としただけでは「勉強すれば叱る」となってしまう。これは時間を加味して「勉強しないのは、叱らないときだけ」といえば自然になる。仕様書における原因と結果では常に原因が結果より前になるので、この時制を把握する必要がある。(もっというと、対偶による推論はデバッグにおける推論パターンになりえる。)
一方、推論「A ならば B である」の逆となる「B ならば A である」は、逆が必ずしも真ではないよい例になる。しかし、プログラム形式では処理の実行結果として副作用を含んだ状態の変化をもたらすことがある。この場合は「B をすれば A' になる」であり、これは「A であれば B をする」とは全く別の話になる。
仕様としては「A ならば B である」よりも「A は B だ」などの表現の方が頻繁に現れる。この場合は A という概念が B というより大きな概念に属することを示す。但し、「B が A だ」と言い換えられる「A は B だ」は推論ではないから、これは概念ではなくデータ間かインスタンス間の関係を示している。仕様の場合にはこの両者の区別が必要で、「〜とは/〜というもの」は概念を示し、「ある〜/ひとつの〜」がインスタンスを示すといえるが、必ずしも仕様がそのような記述をするわけではない以上、その場合には内容で判断するしかない。(概念の表現としてはほかに「その他の」がある。例えば「内閣総理大臣その他の国務大臣」など。)
「A ならば B である」は「A は B の十分条件である/B は A の必要条件である」を共に満たす。仕様書で注意が必要なのは「〜必要である」と「〜十分である」の違いで、これらは場合によって論理的意味が違ってくる。そうでなくても日常会話では幅を持って使われることが多いため、余計に混乱を招きやすい。そして、前提部(A)に間違いがあると「A ゆえに B である」は B の真偽を問われなくてもよいことになってしまう。そのため、仕様書では前提部の真偽が分かるだけの情報がなくてはならないことになる。
第4章 時間に関する表現
組み込みシステムでは時間的正確性も重要な要素であるため、時制(テンス:tense)に関する記述も正確である必要がある。特に複数事象間の時間関係(temporal order/タクシス:taxis)における同時事象か継起事象(引き続いて起こること)かなどはタスク構成にかかわる重要な情報となる。そして、既に触れてきたように原因は結果に対する十分条件だけでなく、時間的順序との関わりから捉える必要がある。これは継続・完了に関する時相(アスペクト:aspect)との関係が基本となる。
日本語で継続や完了を示すには個々の動詞の使い方に依存することが多い。(動詞の使われ方自体に多義性があるため。)仕様書で時制や時相の明確さを示すには、(中国語のように)時間副詞や助詞を付ける必要がある。(例えば「〜し始める/〜し終わる」など。)もちろん、それとは別に「〜ている」など、時間を示さない文脈もある。
時制を更に細かく見ると構文時制と述語時制(時制が述語にしか係らない)がある。構文時制の場合には主語のテンスの不明になることがあり、特に本人には分かりきったことの抜けとして起こりやすい。また、「〜して」は意味が多いため曖昧になりやすい。できるだけ「そして/そこで/ので/のに」など、意味が分かるようにし、係り方が狭くなるようにする方がよい。或いは丁寧体を使うことで文の切れ目を明確にしてもよい。(これとは別に時相論理(temporal logic)を使うと、主語・述語・文章全体のいずれにも時制をつけることができる。)
次に継続の場合には動作の継続と動作の結果の継続とがある。仕様書の場合には「〜している/〜していた」は結果の継続と動作の継続の両方を検討するのが基本となる。そして書く場合には、動詞を名詞化して使ったり(例えば「切る」を「切断前/切断中/切断後/切断状態」など。)、仕様書の中に用語の定義やグロッサリ(glossary)を付けたりするのがよい。しかし、このような自動詞の場合だけでなく、他動詞の場合には更に主体と客体の入替(受動態か能動態か)にも注意する必要がある。
また、ふたつの事象に対してそれが同時なのか継起なのかは明確にする。例えば、「〜し、〜し、〜する」ではなく、「〜する(とき/前/後)、〜する」などのように具体化する。同時の場合の「する/した」は「している」で置き換えることができるが、継起の場合にはそれはできない。「あいだ/まで(継続)」と「あいだに/までに(完了)」の違いも区別が必要となる。しかし、「〜するとき」という表現でも同時進行である場合がある。その場合には「〜しているとき、〜していた/〜間」などとする。また、このように主文と従属文がオーバーラップすると、時間的ギャップのあるときとは異なり、これらを入れ替えることができない。
期間の場合には、「〜の間」は完全なオーバーラップを示し、「〜の間に」は従属文のどこかで主文が行われればよく、全期間での継続は必要ない。また「から」は、「区間/期間/範囲/変化/遷移」などではっきりさせる。因果関係の場合には、時間的前後関係を念頭に置いて「<原因>ので/から/ならば(後で/の間/したとき)<結果>」などと表現する。
仕様書から時間の概念が一般化されることは脱時間化(時間の起点の相対化)されることを意味する。そのため仕様書の書く行為を脱時間化、読む行為をその逆ということができる。
第5章 データ表現──中身と入れ物,実体と参照
データ量に関する概念について。一般に数値データに関する量はイタリック体とし、行列や集合のようなものはイタリック体にしない(ボールドなど)。(そのため図表で使う書体は本文でも書体を揃える。)高度(?)な要求仕様書では論文との区別が曖昧で、そういう中に数式などが突然現れると背景に相当の知識を要することになる。
速度をゼロにする // 物理量 速度変数をゼロにする // 入れ物 速度値をゼロにする // 中身 未定義の変数 // 変数がまだ存在しない 未設定の変数 // 変数は存在するが中身が不定
変数は変数値として明示した方がよい。他に 0 をゼロ、レイ、零など。ほかに初期化がコンストラクタの呼び出しだけなのか、実際にどこまで初期化するのかなどでも同様である。
データ表現の言葉
データ操作語
クリアする、設定する、初期化する、リセットする、代入する、更新する、
〜にする、変更する、リフレッシュする、〜とする、交換する、退避する、
定義する、割り付ける、確保する、解除する、解放する、返却する、削除する など
操作対象語
変数、バッファ、スタック、キュー、メモリ領域、入出力ポート、レジスタ、
フラグ、カウンタ、セマフォ、ファイル、ディレクトリ など
〜の値、〜値、〜の内容、〜データ など
再帰的なものや中身が別のものの入れ物である場合などは、操作対象をはっきりさせる必要がある。(例えば、オブジェクトをコピーするときに内部の参照値で参照だけコピーするのか、参照先までコピーするのかなど。)特にポインタの場合には、1) 変数としてのポインタ 2) ポインタが持つアドレス 3) ポインタが指すもの、を区別する必要がある。或いは「ポインタの配列」と「配列の(への)ポインタ」の区別など。
char (*f)(); // char を返す関数へのポインタ char* g(); // g は char へのポインタを返す関数
こそあど言葉 : これ、それ、あれ、どれ (指示代名詞)の場合。代理代名詞は「それ」しかないので、普通は名詞の部分反復を使う。例えば、「A 博士」を「博士」など。
我々が固有名詞を使う場合には、その前提として a) 名前(name) b) 指示対象(referent) c) 定義的特徴(defining feature) d) 属性(properties) e) 意味範疇(samantic category) の知識の共有が求められる。そのとき「〜とは、〜というのは」のように、対象が不明な状況で使われる言語形式をメタ形式と呼ぶ。このメタ形式は引用形式と使用される状況における共通性がある(「〜と」)。また、その中身の成立を考えると、音の連鎖としての側面(signifiant)と意味的側面(signifie)の関係(ソシュールのモデル)、そしてこれに対象物を加えたオグデン・リチャーズの意味の三角形という捉え方ができる。また、代名詞を使わないメタ形式は中身を問題にする表現だということもできる。
そして、時間表現の場合と同様、時制を脱時間化することで、内容の一般化を行うことができる。他に既知のものにメタ形式を使うことによる、内容の再定義という場合もある。
全文を読まれる場合はログインしてください
Up