toppage memoranda
（ここはbewaad institute@kasumigasekiの過去ログ倉庫です。コメント等は仕様上受付けを停止しておりませんが、こちらではご遠慮いただければ幸いです。何かございましたら、現行サイトにお願いいたします。）
2005-04-23
■ [computer][law]リーガルパターンの可能性
「オープンな法体系（SF小説風）」（@isologue4/17付）において、法令や契約書のxml文書化を通じた自動処理の可能性が語られているわけですが、webmasterの見立てとしては、そちら方面には進まないように思います。
というのも、その補足に当たるエントリで紹介されているLegal XMLはどういうスキーマを定義しているのか公表されていないようですのでよくわかりませんが、例えばLegislative Documents in XML at the United States House of Representativesでは、かつてwebmasterがやっていた「法令XML文書化計画」同様、あくまで文書構造のマークアップのためのスキーマを制定しています。
＃Legal XMLは法律そのものよりも契約書や判例などのXML文書化がメインのようですので、実は話が違うのかもしれませんが。
したがって、XML文書化した際にエンリッチ化される情報は、あくまで意味の解釈には立ち入らない部分に限られることになります。察するに、法令そのものを抽象化するに、構造を抜き出すだけでも使い道が多々ある一方で、解釈にまで立ち入ると議論が多岐にわたりすぎ規格化が困難でしょうから、まずできることから先行させているのでしょう。
磯崎さんが考察の端緒としたISDAの定型契約などは、意味も固定化されているでしょうから、解釈についても規格化に向いているのでしょうけれども、法令一般となると、およそ森羅万象が対象となり得ますので、なかなか解釈にまで踏み込むことは将来においても難しいのではないでしょうか（webmasterが悲観的に過ぎるのかもしれませんが）。
むしろ、法令についてコンピュータ関連の知見を活用するのであれば、かつてコードといえばいわゆるプログラムを普通は指しますが、法律もまたコードでして、実際のところ俗に言うプログラミング（コーディング）と法案作成作業は非常に似通っているものです
とwebmasterは書きましたが、磯崎さんのエントリにtrackbackされていた「三権分立とプログラマー」（@404 Blog Not Found4/20付）において、逆にプログラミングをする立場からも常々思って来たことだが、法律というのはプログラムに似ている。そのものだといっても言い過ぎではないとすら思う
とのご意見が出ておりますので、この観点からのアプローチが考えられるのではないでしょうか。
＃当該エントリでは、政治家のみなさんも、そろそろシスアドどころかオペレーターに過ぎない役人に起法させるのではなく、立法家となってもらいたいものだ
との言及もありますが、これについては、コーディングなんぞ役所（議院・政党に専属スタッフを置くという手もありますが）にさせればよく、政治家には要求分析・定義や品質検証に注力していただくべきではないか、と思わないでもありません。
具体的には、システム開発プロセスについての膨大なノウハウの転用です。クライアントのニーズに基づいてコードを作り出すという点でソフトウェア開発と法令や契約書の作成が同じ構造であるのなら、webmasterはよく知らないので実は的はずれなのかもしれませんが、例えばRUPなどから官僚や弁護士が学べることは非常に多いのではないかと期待してしまいます。
＃個人的にはエクストリーム・プログラミングに興味があるのですが、ケント・ベック「XPエクストリーム・プログラミング入門」は訳が悪いと聞き、いい本は何だろうかと探しております。もしお薦めのものがありましたら、ご教示いただければ幸いです（原書を読め、というのは除いて（笑））。
少なくとも、webmasterが趣味的にUMLをかじっていることから感じる限りにおいては、モデリングの部分において学ぶことは多いといっていいでしょう。もちろん各種のギルド的な伝承として、少なくとも霞が関においては同様の作業が行われているわけですが、それはあくまで職人芸的・属人的な技の寄せ集めです。
その結果として生じるであろう結果のばらつきを防止するという意味もあり、役所の中では関係部署間での相互チェックが文書により頻繁に行うなど、組織として、その構成員による多人数チェックが行われているわけですが、以前書いたように霞が関における人員削減・人材の質の低下・仕事量の増加という傾向を踏まえれば、遠からずオーバーフローか品質の低下は不可避でしょう。
であるなら、わざわざ多大な時間とコストをかけて職人芸を伝授しなくともすむよう、作業自体を定型化しフールプルーフ的に一定のレベルを確保できるようにするのは、今後の霞が関にとって実効性のある対策ではないかとwebmasterは思います。ユースケース図を作成してニーズを分析し、クラス図を作成して枠組みを練り込み、・・・というUMLがベストかどうかはわかりませんが、ゼロから作るぐらいならベターであってもUMLでやる方が結果として有益でしょう。幸いにしてビジネスモデリングの実例はどんどん集積されていますから、転用も容易ではないかと思います。
＃という問題意識から、マーチン・ファウラー「アナリシスパターン」を読みたいと思いつつ、実現はいつのことになるやら・・・。
webmasterの勝手な思いこみとしては、こうした作業は霞が関以上に弁護士業界や企業の法務部門で進む余地があるのではないかと思います。段違いに従事者の数が多いので手法の統一が図られることのメリットは大きいでしょうし、なにより各種書式集の出版量が市場規模の大きさを伺わせます。上記「アナリシスパターン」やエリック・ガンマ他「デザインパターン」のように、「リーガルパターン」「コントラクトパターン」が出版されるようになれば、法律関連事務の効率化が相当程度図られるのではないかと思うのですが・・・。
＃でも、実際に法務に携わっている方による業務プロセス自動化についての見方を拝見する限り、webmasterが思うほどには単純な話ではないのかもしれません。
■ [sports]PRIDE GP 2005 1st ROUND 勝敗予想（その4）
第7試合:クイントン・“ランペイジ”・ジャクソンvsマウリシオ・ショーグン
ショーグンはいい選手だと思いますが、やはりジャクソンが上でしょう。シウバに勝てないがために弱いイメージで見られがちですが、実際のところ、最近はシウバ以外にはまったく負けていないわけですから。
第8試合:吉田秀彦vsヴァンダレイ・シウバ
シウバは立ってよし寝てよしの選手ですが、彼が負けるとすればスタンドだとwebmasterは思っています（エメリヤーエンコ・ヒョードルにも相通じますが）。とすれば、今回のトーナメントでシウバを倒す可能性があるのはボブチャンチンかベウフォートであって、吉田では難しいように思います。寝技にはつきあわず、スタンド中心でシウバの勝ちと読みます。
[http://www.bewaad.com/:title=bewaadさんのところ]でソフトウェア工学的な話が出ていて気になった、と思ったら”Plugin Error”になっているので、元記事を参照せずに、本職のクセにソフトウェア工学について勉強を始めたのは最近という不勉強なITエンジニアとして書い..
エクストリームプログラミング（XP）がどんなものか、というエッセンスを知るということであれば別に一生懸命分厚い本を読まなくても
http://www.objectclub.jp/community/XP-jp/
以下をちょろちょろっと流し読みしてみてはどうでしょうか。
あと掛け合い風でなんとなく雰囲気をつかめる「エピソード」とか。
http://agileware.jp/articles/xp/xpepisode.html
僕が以前部下君と一緒に「エセXP」で作ったときはほんとにこんな雰囲気でした。（設計図は書かなきゃいけなかったので「ちゃんとしたXP」ではなかったのです）
法律とプログラムの似ている点は多そうに思えます。
・細かく厳密な定義
・if-thenルールの集合体 （繰り返しループは無さそうですね）
バグになりやすいパターンも似ていますね。
・第9条3項、とか変数名がわかりにくい。（すべての変数を配列に入れてインデックスでアクセスしてるようなものか）
・思いも寄らないところから参照される。（グローバル変数？）
・あるモジュール（条文）の挙動がほかのモジュールの振る舞いによって大きく異なる。
・ある条件を与えられたときの挙動がコードのどこを通るのかわかりにくい
・if-thenの分岐が深すぎる
読みにくいプログラムは大抵バグになるので「コーディング標準」で読みにくいコードを禁止することでバグを低減するのですが…法律の条文は、「読みやすさ」には全く配慮してないように見えます。
UMLを使うこと自体は全然難しくないと思いますが、適切にユースケースを洗い出すこと、どのようにモデル化すれば美しいかを思いつくことはすごく難しいと思います。それから業務など（もちろん法律が扱う対象も）人の営みに関わることは絶対に完全にモデル化できないので、いかに納得感のある「割り切り」をするかというのも難しいですね。
アナリシスパターンは笑っちゃうほど難しいので頑張ってください（笑）どこまで理解しても理解できた気にならないのです。
こちらの方が読みやすいと思われます。
アジャイルソフトウェア開発の奥義
http://www.amazon.co.jp/exec/obidos/ASIN/4797323361/
＞tockriさん
いろいろと参考になる情報ありがとうございます。法律特有のやっかいなところとしては、レガシーな部分ときちんと互換性を図らなければならず、しかもそのレガシーはかつて知らない人が作ったもので関連のドキュメントも散逸していているなんてことも（笑）。逆に言えば、そうした状況の中でミスをこの程度にとどめている（しかもすべて人力が頼りで）内閣法制局の職人芸もたいしたものだと思います。
ちなみに条番号の参照は、昔のBASICの行番号を思い出してしまいます。行番号指定はやめろ、というのもかつてノウハウとしてあったような。
「アナリシスパターン」は、大きさ・重さからして通勤時に手軽に読むようなものでもなさそうなので、まず読み方から考えないと（笑）。
＞Kyonさん
ご教示ありがとうございます。挑戦させていただきます。
> レガシーな部分ときちんと互換性を図らなければならず、
> しかもそのレガシーはかつて知らない人が作ったもので関連の
> ドキュメントも散逸していているなんてことも
プログラムを作っている人の中にも、未だにそういう悩みを抱えている人はたくさんいるはずです。（僕も2年ほど前にそういう経験を…）
ソフトウェア工学は主にそういうことへの反省として発展してきたのだと思います。そこには「需要がとんでもない勢いで増えたが職人は増えず、納期は短くなって金はかけられない」という経済的に切羽詰まった圧力が要因としてあるのでしょう。
いち担当者レベルの問題意識だけでは学問が発展する圧力としては弱いのかもしれません。
＞tockriさん
引用いただいた部分で念頭にあったのは、プログラム間での、専用のインタフェイスなしでの変数のやりとりで、真の意味での「グローバル変数」みたいな変なことを法律ではやるケースがあります（例えば、「○○とみなして××の規定を適用する」なんていうのが典型で、勝手に他法律で直接ルーチンを呼び出して変数を放り込むようなものです）。
ちなみに、立法技術においてソフトウェア工学的なマニュアルが整備されてこなかったのは、しょせん法律のステップ数はプログラムのそれに比べれば圧倒的に少ないものだ（から、8bit CPU時代の人間アセンブラのように個人技で対応が可能だった）という理由によるというのが個人的な推測です。ですが、その路線は今後そう長持ちはしないのではないかと思っています。
社会はシステムですから，ルールの記述がプログラムのコーディングに対応するととらえるのはそのとおりだろうと思います。ただ，プログラマーがいればシステムができるわけではないので，原要求を分析したり，要求を設計したり，解決策を発明したり，それを実装したり，そうしたルールが活用されるようなインフラを設計したり...というように，上流にも，下流にもなすべきことが控えています。
そうした幅広い仕事を一人でやることはできないので，分担するメンバー間で構想全体を共有する手段として，概念モデルが有効なのではないかと思います。あと，リファクタリングも必要ですしね。
何年か前に，弊社の新人にデータモデリングの勉強をさせるために，相続税のモデルを書いてもらったことがあります。この法律に関する国税庁さんの解説は実によく書かれているので，新人でもまともなモデルが書けました。ただ，これは実装のモデルなんです。システムの問題に対する解決策のモデルではないんですね。
パターンランゲージは解決策なんです。建築におけるさまざまな問題を，“時間を超えて”解決する方法です。ソフトウエアパターンも同様に，システム構築あるいはソフトウエアの作成において直面する問題を，時間を超えて解決する方法です。
アナパタは概念モデリングにおける問題の解決例，デザパタはソフトウエア設計における問題の解決例です。確かに，「起法」をこれらとの対比で述べなおすと，おもしろいかなと思います。
アナパタは申し訳ないですが，訳が悪いです。何とかしたいけど。
＞Martinさん
プロとしてのご意見、ありがとうございます。
勝手に推測するに、ご紹介の国税庁の事例のように、霞が関には職人芸的ノウハウで無意識的にモデリングができている事例も多々あると思うのですが、それが統一されていないので省庁や時系列の壁を越えた（これはご指摘にもありますが）承継に問題があるのと、そうしたノウハウがないか、とぎれているところでは、一気にレベルが下がるリスクがあるということなんだと思います。
この問題については、継続的に考えていきたいと思っていますので、もし今後もご関心を寄せていただけるようでしたら、コメントをいただけるとありがたく思います。