何でも自動化 へのコメント http://michys.com/blog/2005/04/post_191.html マダムになりたいアホな理系オタク女子が奮闘するはず Mon, 14 Mar 2011 10:06:01 +0900 http://wordpress.org/?v=2.8.4 hourly 1 bewaad institute@kasumigaseki より http://michys.com/blog/2005/04/post_191.html/comment-page-1#comment-316 bewaad institute@kasumigaseki Fri, 22 Apr 2005 19:25:00 +0000 http://michys.com/michy-wp/?p=224#comment-316 <strong>[computer][law]リーガルパターンの可能性</strong> 「オープンな法体系（SF小説風）」（@isologue4/17付）において、法令や契約書のxml文書化を通じた自動処理の可能性が語られているわけですが、webmasterの見立てとしては、そちら方面には進まないように思います。 というのも、その補足に当たるエントリで紹介されてい... [computer][law]リーガルパターンの可能性

「オープンな法体系（SF小説風）」（@isologue4/17付）において、法令や契約書のxml文書化を通じた自動処理の可能性が語られているわけですが、webmasterの見立てとしては、そちら方面には進まないように思います。
というのも、その補足に当たるエントリで紹介されてい…

]]> michy より http://michys.com/blog/2005/04/post_191.html/comment-page-1#comment-315 michy Fri, 22 Apr 2005 17:16:13 +0000 http://michys.com/michy-wp/?p=224#comment-315 >>グッサン 構造化された契約書、理想だね。 契約書はプログラムが実現したいことによって違うのと同じく、実現したいビジネスによって書くべきことが違うの。そして、人間が解釈するので、人間が理解できることは飛ばして書いても間違っていても恥ずかしい思いはするけど許させるし、実行できちゃう。 でも、間違いに途中で気づく（締結前の回覧に出してる段階で気づく）人が多くて、しかも日本語にみえるからみんな好き勝手に直すんだよねー。 多人数が好き勝手に直したプログラム、しかもデバッグしなくても動く、、、怖くない？？ そして、その上、そのうち事情が変更になって「あのビジネスやっぱ辞めます」ってことになって、「元の契約書のここをこう読み替えましょう」っていう差分だけが締結される。（最初から変更しようとすると、やたらと文句いう人がいるのと、変更点を明確にしたい意図からこうすると思われる） ……解読できないっす。 きちんとできる人は構造化や抽象化が上手なのは私もそう思う。先輩はやっぱりそういうの上手。でもね、日本語だから他の部署の人もみんな好き勝手文句言うんだよね…。それが苦労。もちろん、最後はうまく抽象化した文書でまとめるべく法務が腐心するわけですが、全部の契約書が全部、そういう技術のすぐれた法務部員の手にかけられるかというとそうでもなく。 >>nbdyさま アメリカはJob Discriptionがあって、曖昧さがないようですね。でも、私は曖昧さは日本のよいところだと思うので、あまり排除しすぎる考えは好きじゃないです。 とはいいつつ、矛盾するようですが、マニュアルづくり好きですよー。私も共通かする部分は暗黙知を組織知に変更したいんです。 思うに、暗黙知のままがいい部分とそうじゃない部分があって、その基準ってどの一定程度の期間、一定程度の人数が恒常的やるか、ってことによると思うんです。一人でもずっと続くようならマニュアル化が必要。もちろん、多人数でやるにも必要。 今まではその期間×人数の値がある程度大きくなるまで、みんな引き継ぎで許容してたんだけど、さすがに消費者側の情報の共有化が進んで異なる対応をしたら目立つようになってきたので、その値が下がって来た。 実は人に引き継ぎをするだけのほうが工数が無駄になったりしないし、そうでなくても、そのほうがその人の創意工夫があらわれやすくて業務の効率化にかなう、っていうのはあると思います。 >>グッサン
構造化された契約書、理想だね。
契約書はプログラムが実現したいことによって違うのと同じく、実現したいビジネスによって書くべきことが違うの。そして、人間が解釈するので、人間が理解できることは飛ばして書いても間違っていても恥ずかしい思いはするけど許させるし、実行できちゃう。
でも、間違いに途中で気づく（締結前の回覧に出してる段階で気づく）人が多くて、しかも日本語にみえるからみんな好き勝手に直すんだよねー。
多人数が好き勝手に直したプログラム、しかもデバッグしなくても動く、、、怖くない？？
そして、その上、そのうち事情が変更になって「あのビジネスやっぱ辞めます」ってことになって、「元の契約書のここをこう読み替えましょう」っていう差分だけが締結される。（最初から変更しようとすると、やたらと文句いう人がいるのと、変更点を明確にしたい意図からこうすると思われる）
……解読できないっす。
きちんとできる人は構造化や抽象化が上手なのは私もそう思う。先輩はやっぱりそういうの上手。でもね、日本語だから他の部署の人もみんな好き勝手文句言うんだよね…。それが苦労。もちろん、最後はうまく抽象化した文書でまとめるべく法務が腐心するわけですが、全部の契約書が全部、そういう技術のすぐれた法務部員の手にかけられるかというとそうでもなく。
>>nbdyさま
アメリカはJob Discriptionがあって、曖昧さがないようですね。でも、私は曖昧さは日本のよいところだと思うので、あまり排除しすぎる考えは好きじゃないです。
とはいいつつ、矛盾するようですが、マニュアルづくり好きですよー。私も共通かする部分は暗黙知を組織知に変更したいんです。
思うに、暗黙知のままがいい部分とそうじゃない部分があって、その基準ってどの一定程度の期間、一定程度の人数が恒常的やるか、ってことによると思うんです。一人でもずっと続くようならマニュアル化が必要。もちろん、多人数でやるにも必要。
今まではその期間×人数の値がある程度大きくなるまで、みんな引き継ぎで許容してたんだけど、さすがに消費者側の情報の共有化が進んで異なる対応をしたら目立つようになってきたので、その値が下がって来た。
実は人に引き継ぎをするだけのほうが工数が無駄になったりしないし、そうでなくても、そのほうがその人の創意工夫があらわれやすくて業務の効率化にかなう、っていうのはあると思います。

]]> nbdy より http://michys.com/blog/2005/04/post_191.html/comment-page-1#comment-314 nbdy Fri, 22 Apr 2005 14:56:41 +0000 http://michys.com/michy-wp/?p=224#comment-314 業務プロセスを定義して、アプリ作成自動化ですかぁ。 かなり眉唾ですよね（笑）。 私はシステムエンジニアをしていましたが、やはり定義 することは困難でした。それは技術的な面よりも、 むしろ業務それ自体が曖昧なもので成り立っているた めでした。 　最近は、そういった曖昧さをなくして、業務定義を 行い、暗黙知を組織知に変えていこうという考えもあ ります。つまり「業務のマニュアル化」を進めましょ うということですが、これによってみんなの力で業務を より善くしようというのがねらいです。 このアプローチの最大の成功例は、なんと言ってもト ヨタ自動車ですよね。 業務プロセスを定義して、アプリ作成自動化ですかぁ。
かなり眉唾ですよね（笑）。
私はシステムエンジニアをしていましたが、やはり定義
することは困難でした。それは技術的な面よりも、
むしろ業務それ自体が曖昧なもので成り立っているた
めでした。
　最近は、そういった曖昧さをなくして、業務定義を
行い、暗黙知を組織知に変えていこうという考えもあ
ります。つまり「業務のマニュアル化」を進めましょ
うということですが、これによってみんなの力で業務を
より善くしようというのがねらいです。
このアプローチの最大の成功例は、なんと言ってもト
ヨタ自動車ですよね。

]]> グッサン より http://michys.com/blog/2005/04/post_191.html/comment-page-1#comment-313 グッサン Thu, 21 Apr 2005 14:37:35 +0000 http://michys.com/michy-wp/?p=224#comment-313 こんばんは(=ﾟωﾟ)ﾉ 逆に俺は構造化なしで進む契約書とか恐ろしいな (^^;) 多分はっきりと明示しなくて、なんとなくみんなそれぞれのカラーでやっているのだと思うけど、それを一度決まったフォーマットにしてあげれば後々仕事が楽になるのではないかな。とはいえ俺にはわからない苦労がたくさんあるのだと思うけど。 XML 化といってもそんなに構える必要はなくて、定義が自由なDTD という仕組みがあるのでどんなフォーマットでもちゃんと構造化すればXML(DTD)仕様としてOK なのですよ。 ただしどんなにCPU が高速でも、それに何をさせるかは人間の脳みそを使わないといけないものね。 構造化スキルは僕も勉強中です。 職場でも、ちゃんとしたエンズニアはそういう能力も高いですよ。 こんばんは(=ﾟωﾟ)ﾉ
逆に俺は構造化なしで進む契約書とか恐ろしいな
(^^;)
多分はっきりと明示しなくて、なんとなくみんなそれぞれのカラーでやっているのだと思うけど、それを一度決まったフォーマットにしてあげれば後々仕事が楽になるのではないかな。とはいえ俺にはわからない苦労がたくさんあるのだと思うけど。
XML 化といってもそんなに構える必要はなくて、定義が自由なDTD という仕組みがあるのでどんなフォーマットでもちゃんと構造化すればXML(DTD)仕様としてOK なのですよ。
ただしどんなにCPU が高速でも、それに何をさせるかは人間の脳みそを使わないといけないものね。
構造化スキルは僕も勉強中です。
職場でも、ちゃんとしたエンズニアはそういう能力も高いですよ。

]]>