アカウント名:
パスワード:
そして法律を要求仕様から作り直せと。
http://ja.wikipedia.org/wiki/%E8%A6%81%E6%B1%82%E4%BB%95%E6%A7%98 [wikipedia.org] から引用。よい要求仕様理論上、よい要求仕様は次の特徴を満たす:必要性 - 含めなければならない事項や他のシステムコンポーネントで補えないような重要なシステム要素が網羅されている。明確性 - 何通りにも解釈できる書き方をしない。簡潔性 - 読みやすく簡潔に書かれており、何が必要かという要点は抑えている。一貫性 - 各要求事項間で矛盾がなく、他の関連する要求仕様とも矛盾しない。さらに、用語の使い方も一貫している。完全性 - 1つの文書に全てが書かれており、読者が意味を調べるために他の文書を読まなければならなくなるようなことがない。到達性 - 前提条件となる費用と期間に対して、要求されている機能の程度に実現性がある。検証性 - 要求内容が正しく実装されたかどうかを検証する方法が記されている（インスペクション、分析、デモンストレーション、テスト）。
本当に法律を考えるなら、”運用で回避”とか”解釈の変更”ができるように文言を選定するのが、腕の見せどころでしょ。
法律って、制定するまでにはいろいろと手続きがあって時間がかかるうえ、基本的には現状の後追いしかできないので、確定した時点ですでに陳腐化が始まっています。立法時に想定していなかった事態が生じても対処しなければならないことも多々あるので、あまり厳密に定義してしまうと事実上役に立たないんですよ。だからといって始めから「何でもあり」で何やったら違法なのかわからんような実装をされたんじゃ、たまったもんではありません。その辺のさじ加減が難しいんですよね。
法律って、制定するまでにはいろいろと手続きがあって時間がかかる
これは日本ローカルの事情です。
例えば米国などでは結構早いです。憲法でさえもバリバリ修正します。（米国産の刑事ドラマや法廷ドラマでも合衆国憲法修正第何条とかちょこちょこ耳にしますがアレです。）連中にとっては法は小まめに修正するもののようです。そういう修正が前提と言う精神を体現しているのが法文に修正履歴として修正前の条文と修正後の条文がそのまま含まれることでしょう。
一方日本では法制度の権威と安定性を重視してきたため一旦決めた法の改訂や判例変更が難しく、司法の利用コストが高い（人口当たりの法曹人口が少ない）ため異議を唱えることすらも難しいという歴史的な経緯を伴う事情があります。これは日本の法制度が自前ではなく多くは英米仏普あたりからの輸入品のローカライズだからです。そのため最初から修正の必要が少ない高い完成度である一方、国民が自分達で考えて決めたものではないので上意下達で従わせるには権威も必要だったのでしょう。（という歴史を知ると「自主憲法制定！」とか気勢をあげている人を見るたび「プッ」と思うわけですが。）
間違いに気付いても簡単に修正できないという事情が慎重な制定作業を必要とし、長い時間を要する原因になっています。（XPのような反復開発 vs 古典的ウォーターフォール開発…みたいなものですね。）このため”運用で回避”とか”解釈の変更”が「必要悪」として黙認されてきたわけです。これぞ日本の特殊事情であって決して一般普遍的なものとはいえませんし、このまま続くのが良いこととも思われません。
たとえ瞬時に法改正できたとしても、目の前で起こった現状の半歩先行く犯罪（と呼んでいいかどうかは法が決めるのですが）には対処できません。うまく抜け道を使ったからOKとするか法解釈の余地によってアウトだとみなすかは、あくまで現行法によるのですが、厳密すぎる条文だと俎上に載せようもありませんよ。
そう言うグレー案件への対処（世論の評価も含めて）ってのにも、国民性が影響してくるんでしょうけどね。ま、日本では法律を一旦決めたら手を入れるなどまかりならんという雰囲気があること、それゆえに改正にはある意味ムダな労力と時間が費やされるという指摘には、ある程度は同意します。
”自由”や”平等”なら技術用語として使えるくらいの定義はありますよ。仕様記述内で使うには多少対象を限定することが必要ですが。
どちらもシステムのデフォルトの挙動を記述する言葉で、自由はシステムのあるモジュールが他のモジュールに干渉しないことですし、平等はシステムが行う資源配分についてそれを偏らせないことです。簡単でしょ？
曖昧なコードで記述しておき、コンパイラや実行時のオプションで変化させるってのは、”運用で回避”とか”解釈の変更”ということで、現状と同じになります。
このような現状理解には概ね同意しますが、法の曖昧さの多くは挙げられたような法的技術用語の厳密な定義とは少し違うところから発生しているように思います。
例えば法の中で定義された対象の定義が曖昧（抜け、矛盾）であるとか他の法と整合していないとかいったものです。あるいは法文の定義自身に曖昧さはないが、「詳細は別紙」式にしておいて運用担当者であるお役所が好きに決めると言う事例もあります。また定義の厳密さには問題がないが定義どおり運用したら現実的でないような定義をしておいて運用でうんと緩めて運用しておき、恣意的に厳密適用する、所謂「運用でなんとかしますから」式っていうのもあるようです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
まずはそのカウボーイコーディング変えれと(ry (スコア:4, すばらしい洞察)
そして法律を要求仕様から作り直せと。
http://ja.wikipedia.org/wiki/%E8%A6%81%E6%B1%82%E4%BB%95%E6%A7%98 [wikipedia.org] から引用。
よい要求仕様
理論上、よい要求仕様は次の特徴を満たす:
必要性 - 含めなければならない事項や他のシステムコンポーネントで補えないような重要なシステム要素が網羅されている。
明確性 - 何通りにも解釈できる書き方をしない。
簡潔性 - 読みやすく簡潔に書かれており、何が必要かという要点は抑えている。
一貫性 - 各要求事項間で矛盾がなく、他の関連する要求仕様とも矛盾しない。さらに、用語の使い方も一貫している。
完全性 - 1つの文書に全てが書かれており、読者が意味を調べるために他の文書を読まなければならなくなるようなことがない。
到達性 - 前提条件となる費用と期間に対して、要求されている機能の程度に実現性がある。
検証性 - 要求内容が正しく実装されたかどうかを検証する方法が記されている（インスペクション、分析、デモンストレーション、テスト）。
Re:まずはそのカウボーイコーディング変えれと(ry (スコア:2, すばらしい洞察)
”自由”だの”平等”だの”幸福”だのを定義することからやらないと。
いくら要求仕様を煮詰めても、言語仕様が曖昧なんじゃ実装まで行けません。
曖昧なコードで記述しておき、コンパイラや実行時のオプションで変化させるってのは、”運用で回避”とか”解釈の変更”ということで、現状と同じになります。
Re:まずはそのカウボーイコーディング変えれと(ry (スコア:1)
本当に法律を考えるなら、”運用で回避”とか”解釈の変更”ができるように文言を選定するのが、腕の見せどころでしょ。
法律って、制定するまでにはいろいろと手続きがあって時間がかかるうえ、基本的には現状の後追いしかできないので、確定した時点ですでに陳腐化が始まっています。立法時に想定していなかった事態が生じても対処しなければならないことも多々あるので、あまり厳密に定義してしまうと事実上役に立たないんですよ。
だからといって始めから「何でもあり」で何やったら違法なのかわからんような実装をされたんじゃ、たまったもんではありません。
その辺のさじ加減が難しいんですよね。
”運用で回避”とか”解釈の変更”は歴史的な事情で黙認されてきただけ (スコア:1)
法律って、制定するまでにはいろいろと手続きがあって時間がかかる
これは日本ローカルの事情です。
例えば米国などでは結構早いです。憲法でさえもバリバリ修正します。（米国産の刑事ドラマや法廷ドラマでも合衆国憲法修正第何条とかちょこちょこ耳にしますがアレです。）連中にとっては法は小まめに修正するもののようです。そういう修正が前提と言う精神を体現しているのが法文に修正履歴として修正前の条文と修正後の条文がそのまま含まれることでしょう。
一方日本では法制度の権威と安定性を重視してきたため一旦決めた法の改訂や判例変更が難しく、司法の利用コストが高い（人口当たりの法曹人口が少ない）ため異議を唱えることすらも難しいという歴史的な経緯を伴う事情があります。これは日本の法制度が自前ではなく多くは英米仏普あたりからの輸入品のローカライズだからです。そのため最初から修正の必要が少ない高い完成度である一方、国民が自分達で考えて決めたものではないので上意下達で従わせるには権威も必要だったのでしょう。
（という歴史を知ると「自主憲法制定！」とか気勢をあげている人を見るたび「プッ」と思うわけですが。）
間違いに気付いても簡単に修正できないという事情が慎重な制定作業を必要とし、長い時間を要する原因になっています。（XPのような反復開発 vs 古典的ウォーターフォール開発…みたいなものですね。）このため”運用で回避”とか”解釈の変更”が「必要悪」として黙認されてきたわけです。これぞ日本の特殊事情であって決して一般普遍的なものとはいえませんし、このまま続くのが良いこととも思われません。
Re:”運用で回避”とか”解釈の変更”は歴史的な事情で黙認されてきただけ (スコア:1)
たとえ瞬時に法改正できたとしても、目の前で起こった現状の半歩先行く犯罪（と呼んでいいかどうかは法が決めるのですが）には対処できません。うまく抜け道を使ったからOKとするか法解釈の余地によってアウトだとみなすかは、あくまで現行法によるのですが、厳密すぎる条文だと俎上に載せようもありませんよ。
そう言うグレー案件への対処（世論の評価も含めて）ってのにも、国民性が影響してくるんでしょうけどね。
ま、日本では法律を一旦決めたら手を入れるなどまかりならんという雰囲気があること、それゆえに改正にはある意味ムダな労力と時間が費やされるという指摘には、ある程度は同意します。
Re:まずはそのカウボーイコーディング変えれと(ry (スコア:1)
”自由”や”平等”なら技術用語として使えるくらいの定義はありますよ。
仕様記述内で使うには多少対象を限定することが必要ですが。
どちらもシステムのデフォルトの挙動を記述する言葉で、
自由はシステムのあるモジュールが他のモジュールに干渉しないことですし、
平等はシステムが行う資源配分についてそれを偏らせないことです。簡単でしょ？
曖昧なコードで記述しておき、コンパイラや実行時のオプションで変化させるってのは、”運用で回避”とか”解釈の変更”ということで、現状と同じになります。
このような現状理解には概ね同意しますが、法の曖昧さの多くは挙げられたような法的技術用語の厳密な定義とは少し違うところから発生しているように思います。
例えば法の中で定義された対象の定義が曖昧（抜け、矛盾）であるとか他の法と整合していないとかいったものです。
あるいは法文の定義自身に曖昧さはないが、「詳細は別紙」式にしておいて運用担当者であるお役所が好きに決めると言う事例もあります。
また定義の厳密さには問題がないが定義どおり運用したら現実的でないような定義をしておいて運用でうんと緩めて運用しておき、恣意的に厳密適用する、所謂「運用でなんとかしますから」式っていうのもあるようです。
Re:まずはそのカウボーイコーディング変えれと(ry (スコア:1)