忍者ブログ
プロフィール
メニュー
最新コメント
最新トラックバック
1  2  3  4  5  6 
         

 2011/10/03 独自ドメイン(blog.its-law.net)化しました。
 2011/04/13 事務所サイトの本館と分けました。
 2010/10/02 アドレスを「itslaw」に変更しました。
 2009/07/01 NINJAブログに移転しました。
 2008/06/22 ブログをリニューアルしました。
 2007/06/30 ブログを立ち上げました。

拍手[0回]

PR
author : ITS 
 喫茶店等で何事か熱心に話し合っていると言えば、以前は生命保険か先物取引の営業と決まっていたものでした。しかし、ここ数年でこれらを圧倒するグループが出現しました。それは、IT事業者です。
 
 しかも、生命保険や先物取引では、どことなくヒソヒソ話であったのが、IT事業者の場合、固有名詞や具体的数字の入ったスライド資料が上映され、進捗遅れの原因やシステムの欠陥が声高に語られます。その場にいない者との携帯電話での会話は、ますます声高になり、店内に響き渡ります。
 このようなIT事業者の「公開業務」は、以前から見られなくはありませんでしたが、普通の顧客は相手にしないような(Tシャツ姿の?)個人事業者が仕事場代わりにするくらいのものでした。しかし今や、それなりのプロジェクトに関与している(立派なスーツ姿の?)事業者が、自社の会議室であるかのように振る舞っています。これでは、顧客としても避けようがありません。
 このようなことが一種の流行なのだとすると、同じことが他の業界であっても不思議ではありませんが、金融業界でも不動産業界でも流通業界でもアパレル業界でも、絶えてないようです。IT業界は、要らぬところで「オープン」にしたがるようです。

拍手[0回]

author : ITS 
 今から十数年前、パリで行われた世界陸上の男子100メートル準決勝で、椿事が起こりました。メダル候補と見られていたアメリカの有力選手が、フライング(正しくは、false start)で失格となったのです。同選手はフライングの判定に抗議して、走路に大の字に寝て抗議したため、競技マナーや不服申立てのあり方にも議論は及びましたが、ここで問題にしたいのは、そもそもフライングとは何なのか、ということです。

 当時、競技場でもテレビでも、問題の場面が何度もスロー再生されましたが、少なくとも、肉眼では同選手が他の選手より早くスタートを切ったということは確認できませんでした。何度も再生を繰り返した挙句、実際のスタート前に、同選手の足が痙攣のように、一瞬だけピクリと反応したように見えた、それがスターティング・ブロックの反応装置に検出された、といようように(外野の議論は)落ち着いたようです。確かにスロー再正に目を凝らすと、そのような動きがあったように見えなくもありません。しかし、陸上競技規則のフライングに、その「ピクリ」が該当するのかどうかは明らかではありません。
 ところで、フライングの定義は、「ピストルの合図があってから、人体の反応限界であるゼロコンマ○秒未満でスタートした」となっているようです。もっとも、スパイク・シューズがスターティング・ブロックに置かれているだけで、それなりの加重はかかっているわけですから、ある加重限界を超えた時点でスタートしたとみなす、というような前提なのでしょう。(現状でどこまでやっているのかは不明ですが)これを更に精緻化すれば、ゼロ秒時点でのスタートとは言えない小さな加重状態から、合図後ゼロコンマ数秒後のスタートと言える大きな加重状態に向けて急速に立ち上がる、その波形を全体として評価してフライングかどうかを判断することになるでしょうか。
 そうなると、かなり複雑な判定アルゴリズムが組み込まれたシステムが介在することになってきます。その場合、ある選手がフライングを犯したということは、彼の作り出した波形が、そのシステムの判定アルゴリズムによってクロと評価されたということです。何か問題が起きたときに、こうしたものを検証することは、不可能ではないにしても著しく困難です。そこでは、ルールが適正な判定アルゴリズムの形で実装されるというのではなく、現に実装されている判定アルゴリズムがルールである、とでも言うしなかい状況が生まれます。この種の問題は、機械化された現代社会では実は少なくなかったのでしょうが、AIなどが実用化されれば更に増えるのでしょう。

拍手[0回]

author : ITS 
 人格訴訟とは、相手方に対する人格的非難を公に実現することを目的とした訴訟のことです。良く知られているところでは、離婚訴訟にはそうした傾向が色濃く出ます。そこでは、相手方(つまり現配偶者)を「有責」に追い込むために、徹底した非難の応酬が繰り広げられます。しかも、訴訟では、「(婚姻)破綻の原因は相手方の性格にある」といった抽象的な主張では意味がありませんから、「夫は某日、某所において『○▲○▲○▲』という暴言を吐いた」であるとか、「妻は某日、某所において『■▽■▽■▽』の暴挙に及んだ」といった、具体的・迫真的な(聞くに堪えない?)人格非難に至ります。

 これとそっくり生き写しなのが、システム開発訴訟です。プロジェクトが途中で破綻してしまった場合、客観的に破綻したことは争えませんから、その責任原因が勝敗を決します。訴訟で相手方(つまりプロジェクの元同士)を「有責」に追い込むためには、「(プロジェクト)破綻の原因は相手方の能力不足にある」といった抽象的な主張では意味がありませんから、「ベンダのリーダーAは、入門書に書いてある『○▲○▲○▲』の業務知識すら有していなかった」であるとか、「ユーザの業務担当者Bは、『■▽■▽■▽』程度の確認一つに3か月もかかった挙げ句...」といった、具体的・迫真的な(聞くに堪えない?)人格非難に至ります。
 しかもシステム開発訴訟の場合、プロジェクトがトラブルに陥ると相当のストレスが長期間続きますし、危機的状況に陥ってからも何とか破綻を免れようと双方が相当の妥協を強いられます。そうした状況を経て来ているわけですから、かなりの集団的「怨念」が溜まっています。また、自らがやってきたことに対する職業的なプライドの、ネガティブな発露ということもあるのでしょう。それで「人格訴訟」となるわけですが、最も合理的に進めなければならない開発プロジェクトの後始末が、最も感情的な要素を含んでしまうというのは、何とも皮肉なものです。ある裁判官曰く、「システム開発訴訟で出てくる陳述書は、どうにも読む気がしない」。

拍手[0回]

author : ITS 
 言うまでもないことですが、開発プロジェクトにリスクは付き物です。QCDを考えるだけでも、品質不良リスク、コスト超過リスク、納期遅延リスクがあります。そればかりでなく、目的不達成のリスクやプロジェクト自体の破綻のリスクまであります。そこで重要となってくるのがコントロール、その手段として出てくるのが契約やプロジェクト計画での「義務づけ」です。

 QCDはもちろんのこと、プロジェクトの目的達成や完遂は当然に契約上の義務となります。これらを支えるベンダのプロジェクトマネジメント義務、ユーザの協力義務も、契約上の義務として認められています。また、プロジェクト計画のレベルでは、双方にさまざまな行動義務が規定されます。しかし、プロジェクトのコントロールがこのような「義務づけ」だけで事足れりとするのは、実にナイーブな考え方と言わざるを得ません。
 相手方に義務を課すと一見、自分のリスクが軽減されるように思えますが、これは大きな誤りです。相手方にリスクを移転しただけのことであれば、プロジェクト全体のリスクは変わらないからです。むしろ、不自然・不合理な配分では、全体のリスクが増大するかも知れません。プロジェクトが失敗してしまえば、その後の損失配分をどうしたところで、もはや回復できません。
 より重大なのは、「義務づけ」しただけでは履行される保証がないことです。契約書やプロジェクト計画書に書いただけであれば、借用証一枚で大金を貸し付けるのと大差ありません。ビジネスの世界で担保(あるいは何らかの保証)のない取引は殆どあり得ないことですが、開発プロジェクトではなぜか「無担保取引」が横行しています。無担保どころか、初めから返済見込みのない貸付までが行われています。
 「義務づけ」の発想は、火災リスクは保険を買ってひとまず終わり、為替リスクはオプションを買ってひとまず終わり、とするようなものです。開発プロジェクトには保険もオプションもありませんが、これはリスク自体が不透明で誰も売り手にならないからです。そして、リスクが不透明なのは、それが買い手の側の行動に全面的に依存するからです。逆に言えば、買い手の側を含めた継続的なコントロールが可能であり、また決定的に重要だということです。

拍手[0回]

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