忍者ブログ
プロフィール
メニュー
最新コメント
最新トラックバック
1  2  3  4  5  6  7  8 
 ベンチャーに限らず、初め小さかった企業が成長していく過程には、様々な「テイクオフ」があります。外部から人を招き入れる、新たな店舗や工場に投資する...株式上場はテイクオフと言うより、一つの目標であるかも知れません。これらは、伝統的なヒト・モノ・カネに関するテイクオフですが、情報システムにも、どこかで乗り越えなければならないテイクオフがあります。

 今や、企業と呼べるほどの組織であれば、情報システムなしでは済みません。そこで、起業の際のゴタゴタの中、あるいはそれが一段落してから、必要に迫られて、ともかく業務を回すために、必要最小限のものを備えます。しかし、当初は必要最小限だったものが、やがて、メンテナンスを繰り返し、至れり尽くせりの「サボテン」システムに成長していきます。知り合いの技術者であれば無理も利くし、データ量も少ないし、セキュリティもそれほど気にしないから、それが出来てしまいます。
 しかし、次の二世代目の情報システムが必要になるほど成熟したころには、もはやそれは出来ません。普通の(しかし、無理のきかない)ベンダに、普通の(しかし、融通のきかない)開発手順で、普通の(しかし、初代より機能が低い)情報システムを開発してもらうしかありません。次のステップに進むはずの二世代目の開発が、一見すると後退であるかの様相を呈します。システム開発の過半数は、QCDの何れかに問題があると言いますが、このようになってしまった開発では、おそれらくQCDのすべてに問題を来たすでしょう。だからこそ、これを乗り切ることがテイクオフなのですが。

拍手[3回]

PR
author : ITS 
 契約書のリーガルチェックの目的は、契約にまつわる法的リスクへの対応です。リスクとは、「有利になるかも知れないが、不利にもなり得る」という不確定性を言いますから、単純な有利/不利とは話が違います。よく、リーガルチェックの際に、「出来るだけウチに有利に」と言う人がいますが、本当にそれだけのことならリーガルチェックなど要らなくなりそうです。有利にするには、(売り手であれば)代金をうんと上げれば良いだけのことで、難しい理屈は何も要らないわけですから。

 もっとも、リスクの所在が有利/不利に影響を与える場合は、いくらでもあります。例えば、損害賠償の制限条項は、損害賠償を請求したり請求されたりという法的リスクに直結しますが、損害を発生させる事象が起きた場合の損害負担という経済的リスクを当事者間にいかに配分するかという問題ですから、リスクを押し付けた方が有利で、押し付けられた方が不利であるのは間違いありません。その意味では、上のような言い分にも、一理あると言えないこともありません。
 ただし、代金などの有利/不利と違うところは、将来どのような損害が生じるのか、しないのかは不定であって、しかも多くの場合、当事者はこれに影響を与えることができるところです。システム開発の失敗による損害であれば、これを回避するためにマネジメント活動を行うことができます。その意味で、より良くこれをコントロールできる者(例えば、ベンダ)にリスク負担させる方が良い、という理屈があり得ます。つまり、適切なリスク配分は、当事者双方が直面するかも知れない「負のパイ」を小さくするのです。そうすると、すべての負のパイを相手方に押し付けられるほど強い交渉力を持っていない当事者は、自らコントロールしやすいリスクを引き受けることと、相手方に自らがコントロールし易いリスクを引き受けてもらうことを引き換えにする、という取引が勘定に合うことでしょう。
 リーガルチェックの役割の一つは、そのような取引の可能性を提示することにあるわけです。

拍手[1回]

author : ITS 
 以下は、ある著作からの引用です。「できるかぎり立派に○○を確立することがわれわれの目的であるからこそ、われわれはその○○をできるかぎり厳格にテストしなければならないのであり、コトバを換えていえば、その○○の欠点を見出そうとし、それを反証しようと務めねばならない」、「われわれの最善の努力にもかかわらずそれを反証できないという場合にのみ、○○は厳格なテストに耐えたということができる」、「ある○○を裏づける諸事例を見出したということは、もしわれわれがその反証を見出そうと努めて失敗しているのでなければ、それが意味するものはきわめて少ない」...

 ここで「○○」には何が入るかと問われれば、IT関係者なら、「システム」などと答えたくなるところです(耳が痛いので、答えたくないかも知れませんが)。しかし、「反証」という言葉が少々余計なヒントになっているとおりで、正解は(科学上の)「理論」です。原文は、K.ポパーの「歴史主義の貧困」(久野・市井訳)からのもので、著者のいわゆる「科学的発見」論を敷衍した部分です(著作全体の論旨からは、やや傍論ですが)。
 ITの世界にも、テストはバグの無いことを示すためにあるのではなく、バグを抉り出すためにある、という趣旨の格言がありますが、それにしてもピッタリきます。都合の良いデータで、都合の良いオペレーションをすれば、見掛け上はうまく動く。しかし、厳しいテストに耐えていないから、それより遥かに厳しい実際の運用にはとても耐えられないシステム。趣味のプログラミングならともかく、プロ(似非でしょうが)の仕事でも、このようなものが少なからずあるのが現実です。
 これに対して額面どおりのプロであれば、バグを抉り出すために、計画的・段階的なテスト、テスト密度や障害密度といったメトリクス、開発者と検証者の分離など、それなりの担保を用意します。しかし、いくらこうした担保があっても、システムを徹底的に「反証」しようとする「最善の努力」がなければ、それも空念仏に終わってしまうでしょう。ポパーは、科学上の理論を「反証」する「最善の努力」の担保として、どのようなものを心に置いていたのでしょうか。

拍手[0回]

author : ITS 
 コンピュータ・チェスの世界では、既に10年前、IBMのディープブルーが当時世界チャンピオンのカスパロフ氏を打ち破り(盤外戦の故との話もありますが)、コンピュータ将棋でも、先日、米長元名人(現役は引退されていますが)に勝利しました。難しいと言われているコンピュータ囲碁でも、並みのアマチュアでは敵わないレベルにまで、格段の進歩を示しているようです。

 こうした状況は、「コンピュータ対人間」とか「機械対人間」という図式で語られがちです。しかし、機械が勝手にチェスや将棋を始めるわけもなく、その背後には創意工夫と苦心惨憺の末にゲーム・システムを創り上げた人間がいます。実際、最近の将棋や囲碁での進歩の裏には、新しいアルゴリズム上の応用があったと言いますし、ハード面でも並列処理の工夫が機械の利点を引き出しています。図式化して言うなら、「エンジニア対棋士」というところでしょう。
 さて、棋士よりコンピュータの方が強くなってしまった場合、ゲームの運命はどうなるのか、とは昔から(今も)問われる疑問です。チェスの場合、コンピュータに太刀打ちできなくなってからも何ら廃れることはなく、むしろ負けたカスパロフ氏自身が、棋士がコンピュータを参考にしながら指すという「アドバンスト・チェス」を主導し、より質の高いゲームを実現するという成果を挙げているようです。西洋式の合理的な割り切りとも言えますが、生身の人間の居場所が次第に狭められていく、ある不気味さを感じさせないわけではありません。少なくとも、棋士が命懸けで取り組んだ「棋理の追求」が(ここでも)コンピュータ経由になってしまうことに、味気なさを感じる向きはあるでしょう。
 法律の分野では、エキスパート・システムが一時期盛んに研究されていました。判決予測というようなものにはほど遠く、特定法令の特定条項への適用関係を推理するというレベルのものですが、その後さほどの進展はないようです。恐らく、ゲームよりも、自動翻訳よりも、難しく時間がかかるでしょうが、生身の裁判官が判断するよりも間違いがないシステムを作ることは、不可能ではないでしょう。ただ、それが客観的にいくら正しくても、それを使おうした途端、あの不気味さが前面に出てきます。それは、本当に正しいのかという検証不能に対する疑念であり、人間が背後に退いてしまったブラックボックスに人間の運命の(ほんのわずかな一端であれ)委ねることへの違和感でしょう。

拍手[0回]

author : ITS 
 協議条項という、恐らくは日本独特の契約条項があります。「本契約について疑義を生じた場合、信義誠実の原則に従い甲乙協議し、円満に解決を図るものとする。」というようなものです。日本人論で著名な山本七平氏は「日本資本主義の精神」の中で、協議条項は要らないと述べています。協議条項があってもなくても、日本人同士の契約は、結局は話し合いで決まるから、というのがその理由です。

 多くの法律家も、協議条項は不要であると考えます。ただし、その理由は山本氏とは違って、契約書は裁判所での判断の規範となるものであるが、協議条項はその役に立たないから、というものです。もっとも、契約書は何か事が起きたときに裁判所で機能するだけのもの、というわけではなく、事が起きないように当事者の行動を律する、言わば「導きの星」としての機能もあります。
 ただし、それは裁判所に行けば結局そのような判断を受けるのだから、という裁判規範としての担保があればこそ、というのが法律家の言い分です。協議条項で言えば、もし協議を尽くさないままに裁判に訴えても、裁判所は訴えそのものを認めない(いわゆる「門前払い」)、という効力が前提だということです。確かに、協議条項にそこまでの効力はないでしょう。
 しかし、例えば、システム開発契約のプロジェクト計画書に書かれた規範、「次工程に入る前に、前工程の完了判断を経ること」のようなものはどうでしょうか。これが裁判規範になるかと言われれば、プロジェクト計画書が契約内容に取り込まれているかどうかによる、というのが一応の答です。しかし、プロジェクトメンバーは、裁判所での最終審判を怖れてプロジェクト計画書に従うわけではありません。裁判所が何と言おうと言うまいと、プロジェクトを成功させるために、これに従うわけです。その意味では、厳とした規範性があるわけです。
 協議条項にも、もしかすると、そのような意図があるのかも知れませんが、山本氏は、そうしたことまで十分承知のうえで、あえて「書かずもがな」だと喝破したものでしょう。

拍手[0回]

author : ITS 
忍者ブログ | [PR]
 | PAGE TOP
write | reply | admin