法律≒ソースコードで考えてみた：よがブログ：So-net blog

	ブログをはじめるログイン

Sony αの2007年新ズームレンズ予..｜壁紙～2007年04月05月06月の写真ブログトップ

法律≒ソースコードで考えてみた　[ぼやき系] [編集]

「論」というほど理路整然と展開しませんが、最近思いついたネタで、国会に提出され可決されていく法律(法案)をソフトウェアの開発になぞらえて考えてみることにします。

構成

ソフトのレイヤーというのはだいたい以下のような感じの階層構造になってます。
# 細かいこと言うと一般論では語れないものもありますが、まぁ細かいことは気にせず、
# 修正の際の手の入れやすさというぐらいの気持ちで。


  +---------------------------------+
   | コンフィグ・使い方など         |
  +---------------------------------+
         |
  +---------------------------------+
   | application                    |
  +---------------------------------+
         |
  +---------------------------------+
   | framework, middleware, library |
  +---------------------------------+
         |
  +---------------------------------+
   | OS+driver(Windows とか Linux)  |
  +---------------------------------+

一番基本になるのは憲法です。これは OS レイヤーですね。
その次にくるのは○○基本法とかの大きな法律でフレームワークとかインタプリタとかミドルウェアのレイヤーです。 MFC、 Win32 API、 Java、 .net framework、 GTK、 Perl などといったものです。
普通の法律はアプリケーション層でしょう。 Office 2007 とか Photoshop などです。
政令などはどちらかというと運用ルールに近いものなのでコンフィグと。
蛇足ですが、例外処理を行うのは裁判所ということになるでしょうか。

で、法律の文面というのがソースコードに相当するということです。

プロセス

以上の前提を踏まえて、一つのソフトを作るときにはだいたい以下のようなプロセスがあるでしょう。

- 要件整理＆仕様検討＆仕様レビュー
- 実装＆ソースコードレビュー
- テスト
- 出荷判定会議

もちろん実際の場面では各プロセスの前後を行き来しつつなんども検討や実装が繰り返されています。開発にもいろいろな方法論があって、このサイクルを短い期間で何度もまわして徐々に機能をリッチにしていくという作り方もあります。あるいはα版、β版、RC、RTM という形で徐々に完成度を高めていく方式もあります。いずれにせよ一回プロセスを通せばすべてうまくいくというものではありません。

法律（法案）で仕様検討＆レビューに相当するのは、何とか分科会とか小委員会でしょう。場合によっては諮問委員会や有識者会議からの提案をしてもらったりします。意見を聞くための懇談会みたいなのもあるでしょう。最近だと、「デジタル放送のコピーワンスを 9回に」とかの話が情報通信審議会（＝総務相の諮問機関）の検討委員会で議論されています。もちろん利害関係のある団体もこの案（仕様）に対していろいろとそれぞれの立場から意見の表明をします。
このフェーズでは、おおむね要求仕様（たとえば、コピーによる著作権侵害の被害を最小限にしたい）のとりまとめと機能仕様（たとえば、コピーは1回まで）に相当するものの検討を行っていると思います。
ここで要求仕様を見誤ると国民に迷惑な法律ができてしまうことになります。国民全員の要望を100%満たすことはなかなかできないのでみんなが少しづつ我慢すれば全体としては良い方向に行くというぐらいの落としどころを見極める作業といえるかもしれません。

実際の法律（法案）の文面を作る（コーディング）のは官僚の人や議員立法の場合は議員の裏方さんだと思いますが、よく知らないので「誰が？」というところは深追いしないことにします。このフェーズでは要求仕様を機能仕様にブレークダウンする際にもれた内容もそれなりに拾いつつ、既存の法律などとの整合性を考えながら文面の作成が行われていくことでしょう。
ここの作業がいいかげんだと、グレーゾーン金利のような法の抜け穴ができてしまいます。セキュリティーホールです。

ソフトウェアであればテストを行います。実際には単体、統合、境界値、ストレスなどなど重要視する観点によっていくつものテスト方法があるのですが、法律の場合はテストはできせん。一部には○○特区という形で実社会でのテスト運用が行われる場合がありますが、これはかなり特殊なケースでしょう。
その代わりにいろんなユーザーシナリオにもとづくシミュレーション（＝検討会や議論）を行って漏れをなくし、法律の質を高めていくのだと思います。

で、出荷判定会議に相当するものが国会です。ここを通って法律として成立したら国民はそれを守らなければなりませんので最後の砦です。この出荷判定会議（＝国会）に出てくる法案は、すでに何度もレビューを重ね、完成度は相当のものになっていることが前提です。
その上で、すべてのバグが修正されていること、他の法律と矛盾がないこと、そもそも要求仕様を満たしていること、著しく不利益をこうむる人がいないこと、実際に施行・運用可能であることなどさまざまな観点からさらにダメだしをクラって、それでも OK だろうとなれば投票で可決されます。しかもその最終レビューは衆議院と参議院で少なくとも2回行われているはずです。参議院で否決され衆議院でもう一度審議したら3回です。

懸念点

と、ここまで読んで勘の良い人ならもうわかっているかもしれませんが、私は最近とくに「国会（およびそのほかの政治・行政の場面）でこのようなテスト＆レビューのプロセスが誠実に実行されているのか？」ということに疑問を持つわけです。

言い換えると、「強行採決で法案を通すということ」＝「テストとレビューの放棄」なわけです。

役に立たないだけで存在価値のない法律ならまだしも、不便な思いをすることがいっぱい増えたり、われわれの常識では考えられないクイズネタのような内容だったり、はてには貰えるはずのものが受け取れなくなったり、その結果は想像するのもおぞましいでしょう。
大型機械の制御ソフトでテストもレビューもしなければ死人が出るでしょう。法案でもそれは同じだと思いませんか？

いろんな人がいろんな観点から物事を考えて意見を出す。テーゼに対するアンチテーゼが出てきたら両方をうまく満足させるように工夫する。場合によっては差し戻される。それをくりかえして、（たとえ不承不承でも）意見を出した人々の多くが納得できるものにする、そのプロセスが完成度を高めます。つまりスキがないということです。逆に練らないなら、政教一致の神様のご信託（しかも実際には神様じゃないし）と一緒（実際にはそれ未満）なのです。

つまり、「通した法案の数」＝「成果」という考え方は間違っています。これは説明責任以前の問題です。
きちんとレビューされていない法案を通したらマイナスカウントしないといけないのです。
レビュープロセスを無視するなら国民に対する背任でクビにするべきなのです。
ついでに言うと、そんな奴が憲法改正なんてちゃんちゃらおかしくて聞いてられないのです。

重要なのは、どれだけ要求仕様を満足させる法案を完成度を高めて法律にしたかということです。
その完成度の高い法律をちゃんと実行するように努力したかということです。
そして万一バグやセキュリティホールを見つけたらすばやく修正して被害を最小限にくいとめ、お客様（＝国民）に迷惑をかけないということです。