白田秀彰の「現実デバッグ」
No. 3 法律作成者
http://wiredvision.jp/blog/shirata2/200711/200711211100.html
テーマ的には私としては興味深いと思うのだが、ここまで読んできてなぜか底の浅い感じがしてしまう。なんでだろう?…と、考えてみるとプログラム開発話をイキナリにコーディングとそのスキルについての話題から始めてしまっているために問題が矮小化されてしまっているからでないかという気がする。
というのも昨今の情報システム開発プロセスではコーディングのフェーズそのものより要求仕様の洗い出し、優先順位付け、既存コード再利用の検討などの分析フェーズの方がむしろ高難度の課題であり重きを置く必要があるとされていたりするのである。
当然、社会システムも目的・意図があって設計されるものであって、目的や意図に基づく仕様を洗い出すにはシステムに関するステーク・ホルダとなる人々を見つけ出してその要求を集約して優先順位を出すという作業がコーディングに先立つことになる筈。
社会システムの中でも国、法律の場合はユーザー/クライアントという重要なステーク・ホルダ群として(実態はどうあれ本来は)国民が居るわけであり、国会議員はそれらユーザ/クライアント代表という立場にある。
実際選挙という票数を数えるだけのシンプルな数学的手段を持つ手続きが保証するのは、選ばれた人間の法的知識のようなスキルではなく、統計的な標本として母集団を代表する傾向のある人間が選ばれる可能性が高いことであろう。(そういう意味では母集団からズレの大きいような相対的に「有能」な人物であるよりは母集団の意見をよく反映するようなある種「平凡」な人物であることがむしろ国会議員の資質といえるかもしれない。このあたり選挙の数学的な性質については以前にも書いた。)
そして現実の情報システムでもユーザー/クライアントは一般にプログラミング・スキルを持たないわけで、国会議員が必ずしも法の専門家ではないのもそこいら辺に理由があると思う。リンク先のブログでは米国の議会に法律家が多い例が上がっているが、米国でも別に議員が法律家であることを要請してはいない筈だし、そもそも米国は人口当たりの法律家の数が日本とは桁違いに多いのだから議員に法律家が多くてもそれほど不思議ではない。
(昔読んだことを確認するためちょっと検索してみたが、ちゃんとした統計は見つけられなかった。ネット上の数字には幅があるが10倍とも20倍とも言われているようだ。ところでちゃんと数えてみたわけではなく体感だが、これは向こう産のドラマの出演者に弁護士が多いことにも現れているように思う。日本で弁護士が登場したらまず法律家としての役どころだが、向こうではせいぜいちょっとしたキャラ付けくらいの比重で弁護士が気楽に出てくる。これは米国の生活において弁護士などの法律家が日本よりは格段にありふれた職業であることの反映であるように思う。)
そして米国は時に訴訟社会と言われるほどに社会システムにおける裁判という昨日が果たす役割が重く、また日本に比べると裁判は迅速で判例もよく変わる、つまり法律は裁判によって頻繁に修正され完成度が高められていく(後述の省令や行政指導とは違う形だが、元々裁判の判決も限定された立法行為の性質を持つ)という傾向が強い。言い換えると日本ほど法の安定性が強くない。そのため立法時に一気に細部まで完成度が高いことは日本ほどには求められていない。このため恐らく議員はある意味「気楽に」法律が作れる側面があると思われる。(長期自民党政権の日本とは異なり米国は議会や大統領選で現実に政権交代を実現してきている分、政策の違いを反映した法の改廃自身が日本より盛んだろうという推測もできる。)
また公務員試験を根拠に官僚を法律の専門家としているが、公務員の仕事は本来立法ではなく行政、つまり主に執行である。法律で記述されるような公的かつ社会的な「情報システム」について言えば、それはプログラマというよりは運用担当者、例えばオペレーターやアドミニストレータに近い筈。実際公務員試験は法的知識を一部に含むとはいえ、司法試験のように法的知識を主に問うものではないように思う。
確かに現実のシステム管理者など運用担当者は運用に当たって設定ファイルやスクリプトを書くなどプログラマ的な仕事をいくらかこなすし、システムの細部の挙動についてのノウハウを蓄えている人々ではあり、クライアントほどではないとしてもそれなりに重要なステーク・ホルダではある。そして省令や行政指導は限定的な立法行為でもあるわけでこれは設定ファイルやスクリプトを書くなど限定的なプログラミング行為と対応するだろう。とはいえ、それは部分的な修正が中心であり、必ずしも全体的なバランスを見通してシステムを設計するような行動ではなく、そういう仕事に習熟していたとしてもそれはシステム全体を設計するスキルには必ずしも繋がらない。
そして日本では近代以降、歴史的に法をフルスクラッチで開発することは少なく、時の先進国から丸ごと「輸入」して部分的に修正、つまりローカライズしたり、パッチを当てて利用するケースが多かったようだ(現在の憲法にしてからがそうだという改憲派の主張もあるし、明治憲法はプロイセンを範に取り…というのは歴史の教科書には大概書かれているんじゃないかと思う。)。こうやってシステムを構築した場合プログラマではなく運用担当者の重要性が相対的に高くなることは想像に難くなく、それが現在日本の官僚が立法で相対的に大きな役割を担っていることの理由の一つではないかと思える。(そして日本の大学の法学の授業が法解釈学中心であり、立法といえばいろいろひっくるめて「法哲学」とされてしまう傾向の原因でもあるのだろう。そしてそんな法学部の卒業生たちが公務員の中心勢力であるのだ。)
そして日本では時々忘れ去られているらしいが、情報システムの開発にはクライアントが業者に依頼してしまえば後はできるのを待つばかりという一方的なものではなく、問題領域の専門家である顧客と解決手段の専門家であるデベロッパの共同作業という側面がある。
これは社会システムについても言えるはずで、そうだとすれば法は議会や官僚が勝手に設計するものでなく社会全体の共同作業で作り上げられていくものであろう。実際、国民の多くを占めるのは職業人であるわけで、皆それぞれの職業に関する分野に関しては多かれ少なかれプロ、専門家である筈なのだ。そしてこの「社会全体で共同して社会システムの設計を行う」という問題解決を行うための社会的な仕組みの一つが、<自由な試行錯誤による並列的な解の探索-言論による世論形成(解の交換、評価)-選挙による集計>からなる民主主義的諸制度ということになるのではなかろうか。
No. 3 法律作成者
http://wiredvision.jp/blog/shirata2/200711/200711211100.html
テーマ的には私としては興味深いと思うのだが、ここまで読んできてなぜか底の浅い感じがしてしまう。なんでだろう?…と、考えてみるとプログラム開発話をイキナリにコーディングとそのスキルについての話題から始めてしまっているために問題が矮小化されてしまっているからでないかという気がする。
というのも昨今の情報システム開発プロセスではコーディングのフェーズそのものより要求仕様の洗い出し、優先順位付け、既存コード再利用の検討などの分析フェーズの方がむしろ高難度の課題であり重きを置く必要があるとされていたりするのである。
当然、社会システムも目的・意図があって設計されるものであって、目的や意図に基づく仕様を洗い出すにはシステムに関するステーク・ホルダとなる人々を見つけ出してその要求を集約して優先順位を出すという作業がコーディングに先立つことになる筈。
社会システムの中でも国、法律の場合はユーザー/クライアントという重要なステーク・ホルダ群として(実態はどうあれ本来は)国民が居るわけであり、国会議員はそれらユーザ/クライアント代表という立場にある。
実際選挙という票数を数えるだけのシンプルな数学的手段を持つ手続きが保証するのは、選ばれた人間の法的知識のようなスキルではなく、統計的な標本として母集団を代表する傾向のある人間が選ばれる可能性が高いことであろう。(そういう意味では母集団からズレの大きいような相対的に「有能」な人物であるよりは母集団の意見をよく反映するようなある種「平凡」な人物であることがむしろ国会議員の資質といえるかもしれない。このあたり選挙の数学的な性質については以前にも書いた。)
そして現実の情報システムでもユーザー/クライアントは一般にプログラミング・スキルを持たないわけで、国会議員が必ずしも法の専門家ではないのもそこいら辺に理由があると思う。リンク先のブログでは米国の議会に法律家が多い例が上がっているが、米国でも別に議員が法律家であることを要請してはいない筈だし、そもそも米国は人口当たりの法律家の数が日本とは桁違いに多いのだから議員に法律家が多くてもそれほど不思議ではない。
(昔読んだことを確認するためちょっと検索してみたが、ちゃんとした統計は見つけられなかった。ネット上の数字には幅があるが10倍とも20倍とも言われているようだ。ところでちゃんと数えてみたわけではなく体感だが、これは向こう産のドラマの出演者に弁護士が多いことにも現れているように思う。日本で弁護士が登場したらまず法律家としての役どころだが、向こうではせいぜいちょっとしたキャラ付けくらいの比重で弁護士が気楽に出てくる。これは米国の生活において弁護士などの法律家が日本よりは格段にありふれた職業であることの反映であるように思う。)
そして米国は時に訴訟社会と言われるほどに社会システムにおける裁判という昨日が果たす役割が重く、また日本に比べると裁判は迅速で判例もよく変わる、つまり法律は裁判によって頻繁に修正され完成度が高められていく(後述の省令や行政指導とは違う形だが、元々裁判の判決も限定された立法行為の性質を持つ)という傾向が強い。言い換えると日本ほど法の安定性が強くない。そのため立法時に一気に細部まで完成度が高いことは日本ほどには求められていない。このため恐らく議員はある意味「気楽に」法律が作れる側面があると思われる。(長期自民党政権の日本とは異なり米国は議会や大統領選で現実に政権交代を実現してきている分、政策の違いを反映した法の改廃自身が日本より盛んだろうという推測もできる。)
また公務員試験を根拠に官僚を法律の専門家としているが、公務員の仕事は本来立法ではなく行政、つまり主に執行である。法律で記述されるような公的かつ社会的な「情報システム」について言えば、それはプログラマというよりは運用担当者、例えばオペレーターやアドミニストレータに近い筈。実際公務員試験は法的知識を一部に含むとはいえ、司法試験のように法的知識を主に問うものではないように思う。
確かに現実のシステム管理者など運用担当者は運用に当たって設定ファイルやスクリプトを書くなどプログラマ的な仕事をいくらかこなすし、システムの細部の挙動についてのノウハウを蓄えている人々ではあり、クライアントほどではないとしてもそれなりに重要なステーク・ホルダではある。そして省令や行政指導は限定的な立法行為でもあるわけでこれは設定ファイルやスクリプトを書くなど限定的なプログラミング行為と対応するだろう。とはいえ、それは部分的な修正が中心であり、必ずしも全体的なバランスを見通してシステムを設計するような行動ではなく、そういう仕事に習熟していたとしてもそれはシステム全体を設計するスキルには必ずしも繋がらない。
そして日本では近代以降、歴史的に法をフルスクラッチで開発することは少なく、時の先進国から丸ごと「輸入」して部分的に修正、つまりローカライズしたり、パッチを当てて利用するケースが多かったようだ(現在の憲法にしてからがそうだという改憲派の主張もあるし、明治憲法はプロイセンを範に取り…というのは歴史の教科書には大概書かれているんじゃないかと思う。)。こうやってシステムを構築した場合プログラマではなく運用担当者の重要性が相対的に高くなることは想像に難くなく、それが現在日本の官僚が立法で相対的に大きな役割を担っていることの理由の一つではないかと思える。(そして日本の大学の法学の授業が法解釈学中心であり、立法といえばいろいろひっくるめて「法哲学」とされてしまう傾向の原因でもあるのだろう。そしてそんな法学部の卒業生たちが公務員の中心勢力であるのだ。)
そして日本では時々忘れ去られているらしいが、情報システムの開発にはクライアントが業者に依頼してしまえば後はできるのを待つばかりという一方的なものではなく、問題領域の専門家である顧客と解決手段の専門家であるデベロッパの共同作業という側面がある。
これは社会システムについても言えるはずで、そうだとすれば法は議会や官僚が勝手に設計するものでなく社会全体の共同作業で作り上げられていくものであろう。実際、国民の多くを占めるのは職業人であるわけで、皆それぞれの職業に関する分野に関しては多かれ少なかれプロ、専門家である筈なのだ。そしてこの「社会全体で共同して社会システムの設計を行う」という問題解決を行うための社会的な仕組みの一つが、<自由な試行錯誤による並列的な解の探索-言論による世論形成(解の交換、評価)-選挙による集計>からなる民主主義的諸制度ということになるのではなかろうか。
PR
トラックバック
トラックバックURL:
コメント
このエントリはリンク先のブログの記述に対するコメントという文脈がありまして。
実際には顧客サイドとデベロッパの性格がきれに二つに分かれるわけでないことはわかります。そこで言いたかったことは、よいシステムを作るには専門家に頼んだらお任せという一方的な活動ではダメで、発注側と開発側の持つ異なる知識を持ち寄ってシステムを構築するのに必要な情報を発見するという協調的な探索が必要ですよということであるわけです。
私自身は試行による探索、情報の伝達/交換による情報共有と比較、評価、集計、決定という様々な方法で実現される情報処理システムという観点から見た問題解決の営みの例としてソフトウェア開発プロジェクトも立法行為も眺めて、その共通点を考えるつもりでいるので、別に一方が一方のモデルや喩えと決めているわけではないですけどね。
ただリンク先のブログでの「プログラミング」の捉え方があまりにクラシックかつ視野の狭いものだったので今だと少なくとももう少し違った見方がありますよという話を書いた面もあるわけではあります。
ところで人間は複雑な存在であるとはいえ、高いところから落ちる時は重力の法則に従う物体としての側面を必ず備えていてその性質を無視はできないことが明らかになるわけです。
これと同じように物事を理解するにはある視点を選んで、そこからの分析を行うことはその対象の性質を知るのに役立つはずです。
ある対象が複雑でなんでもありだからといってそこで立ち止まって分析を諦めてしまっては得られるものはないのじゃないかなと思うわけです。
実際には顧客サイドとデベロッパの性格がきれに二つに分かれるわけでないことはわかります。そこで言いたかったことは、よいシステムを作るには専門家に頼んだらお任せという一方的な活動ではダメで、発注側と開発側の持つ異なる知識を持ち寄ってシステムを構築するのに必要な情報を発見するという協調的な探索が必要ですよということであるわけです。
私自身は試行による探索、情報の伝達/交換による情報共有と比較、評価、集計、決定という様々な方法で実現される情報処理システムという観点から見た問題解決の営みの例としてソフトウェア開発プロジェクトも立法行為も眺めて、その共通点を考えるつもりでいるので、別に一方が一方のモデルや喩えと決めているわけではないですけどね。
ただリンク先のブログでの「プログラミング」の捉え方があまりにクラシックかつ視野の狭いものだったので今だと少なくとももう少し違った見方がありますよという話を書いた面もあるわけではあります。
ところで人間は複雑な存在であるとはいえ、高いところから落ちる時は重力の法則に従う物体としての側面を必ず備えていてその性質を無視はできないことが明らかになるわけです。
これと同じように物事を理解するにはある視点を選んで、そこからの分析を行うことはその対象の性質を知るのに役立つはずです。
ある対象が複雑でなんでもありだからといってそこで立ち止まって分析を諦めてしまっては得られるものはないのじゃないかなと思うわけです。
posted by 椎路ちひろat 2007/11/29 02:44 [ コメントを修正する ]
ジョーク色強くつっこんだのでご勘弁を(^^;
元の記事自体、例がまずいとは私も思います。
しかも、プログラミングのとらえ方以前に、プログラミングやプログラムをさっぱりわかってない気がします。例えばOSべったりで何が悪いんだろう、理解できません。
# OSが下にいる以上、どれかがOSべったりになる必要があるのだが
システム開発において、こーゆーヤツが一番じゃまくさいんじゃなかろうか。