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

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

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

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

拍手[0回]

PR
author : ITS 
 いわゆる「宙に浮いた年金記録」、「消えた年金記録」の問題が発覚してから10年近くが経ちますが、とても解消とは言えない状態のようです。最悪の場合、記録の不在により受給できるはずのものが受給できなくなるのですから、社保庁の責任は重大です。立派な「債務不履行」であり、民間企業であれば破綻していておかしくない事態です。ただ、記録の性質上、こうなるだけの十分な理由もまた存在します。

 相当大規模な組織のデータ管理を行った経験のある人であれば分かり過ぎるほどに分かるでしょうが、過去のデータの正確性(情報セキュリティ的に言うと完全性)を保つ作業は容易なものではありません。「正確性を保つ」どころか、システム再構築の際のデータ移行などになると、データの素性自体が分からない場合が多々出てきます。そこにデータはあっても、それが何を意味するのか分からない、という事態です。
 それでも大事に至らないのは、通常のデータでは利用期間がそれほど長くないからです。トランザクション・データは、一連の取引が終われば文字通り歴史的な記録の意味しか持たなくなりますし、マスタ・データも、時間が経つにつれて事実上アクティブでなくなっていきます。次第に「ゴミデータ」化していきますが、ともかくそれで済むわけです。
 しかし、ある種のデータには、利用期間が極端に長いものがあります。年金記録がその典型ですが、最長で10代、20代で納付した分の記録が、60代の受給時になって初めて使われるわけです。たとえ最初の記録化が正確であっても、40年以上の間、数次のデータ移行(昔であれば帳簿の転記?)に耐えなければなりません。これは想像以上の難事です。
 実証できるものではないでしょうが、昔話や伝説の類は一代ごとに歯が抜け代わりに尾ひれがついていく、という話があります。子供の頃に祖父や祖母から聞いたものを、自身が老年になって初めて人に語って聞かせるから、というのがその理由です。しかし、昔話や伝説と違って年金記録では、歯抜けも尾ひれも許されません。そうであれば、青年期や壮年期にも語り続けるほかありません。年金でも記録の送付・開示など、遅まきながらの対策は始めているようですが...

拍手[1回]

author : ITS 
 スルガ銀行と日本IBMとの間の訴訟に控訴審判決が出され、即上告となってから1年以上が経過しました。日本IBMのぼほ全面敗訴となった第一審判決では、ベンダの責任の重さがが耳目を集めましたが、控訴審判決では時期を区切ったプロジェクトマネジメント義務違反の判断手法に注目が集まりました。第一審と同様に契約責任に縛られない不法行為責任と捉えた点が特徴的ですが、結果的にベンダの責任が若干軽減されたことにも表れているように、システム開発紛争において中間的な結論を導く可能性が秘められており、その射程が気になるところです。
 
 ただ、控訴審判決そのままの理論構造は、限定的な通用範囲にとどまると思われます。控訴審判決の理屈をごく大雑把に言えば、海外パッケージの邦銀ユーザへの初適用という、(ギャップが大き過ぎて)不可能であったがそれが明らかではなかったプロジェクトが、その進行に従って不可能と判明したにもかかわらず、中止も軌道修正もないまま続行され(これがプロジェクトマネジメント義務違反)、無駄なプロジェクト費用を発生させた(これが賠償すべき損害)、というものです。このような判決は、義務違反の時期が賠償すべき損害の画定とストレートに対応する、きれいな枠組みに事案が嵌ったからこそ可能であったという見方もできます。
 例えば、不可能と判明した時点で直ちに中止され、その後に無駄なプロジェクト費用が発生しなかった場合、義務違反はなく賠償すべき損害もゼロということになるのでしょうか。結局のところプロジェクトは頓挫したのだから、それ以前にかかった費用も遡って無駄になったのではないか、というのがこの種の紛争での従来からの問題認識であったと思われます。義務違反の内容を控訴審判決のように捉える限り、それ以前の費用は初めから不可能だったことを不可能と正しく認識するためのやむを得ない費用だったと考えるほかありません(実際、フィット&ギャップ分析の本質はこのようなものです)。いずれにしても、控訴審の考え方から先の問題認識に直ちに答が出てくるものではありません。
 もちろん、別の注意義務(違反)を想定することはできます。実際、よほど背伸びしたプロジェクトでない限り、プロジェクトが途中で頓挫するのは、それが初めから不可能であったからではなく、可能ではあったがユーザかベンダ(あるいは双方)に何らかのやり損いがあるからです。この場合、もしそのやり損いが注意義務違反と評価されるのなら、その前後を問わずプロジェクトに費やされた費用は、賠償されるべき無駄になった費用というほかないのではないか。これは先ほどの議論より一般的で、しかもより強力です。そしてやはり、控訴審の考え方からは答は出てきません。
 もともと、「プロジェクト・マネジメント義務」という抽象的なラベルには殆ど意味はありません。重要なのは、事案の具体的状況に照らした注意義務の具体的内容であり、具体的な損害の範囲です。その意味では、控訴審判決は、注意義務違反の具体的行為と、それと相当因果関係に立つ損害を拾うという、ある意味当たり前の、しかしその限度では通用範囲の広い判決ということになるのでしょう。

拍手[0回]

author : ITS 
 世の中に、標準やガイドラインの類は、数多くあります。IT関係でも、昔からシステム開発方法論というのがありましたし、共通フレームやモデル契約書なども、その範疇に入るでしょう。

 これらの「出来」そのものは、それぞれでしょうし、人により考え方により、評価も異なることでしょう。しかし、これらの全てに共通する、最大の欠点があります。それは、大部に過ぎることです。
 これはある意味、避けがたいことではあります。標準やガイドラインを謳って世に出す以上、最大規模のプロジェクトで利用される可能性がありますから、あれもこれもと詰め込みます。プロジェクトの性質も多岐にわたりますから、最大公約数的に論点を取り込もうとします。学術的(?)にも、せっかく考察した論点を切り捨てるのは、忍びないことでしょう。何より、ガイドラインには、網羅性の要求があります。項目を落とせば、「欠けている」、「不完全」との批判を受けかねません。
 しかし、実務では、大部過ぎるガイドラインは、かえって役に立ちません。不可欠の5項目、10項目をどうしようかと躍起になっているところで、300項目のガイドラインがあっても、使いこなせません。これは特に、中小のプロジェクトあるいは企業という、最も手助けが必要なところでの偽らざる実感でしょう。さりとて、あえて絞り込んだガイドラインを世に問うのも、かなり勇気が要りそうですが...

拍手[0回]

author : ITS 
 議事録の重要な役割は、エビデンスとしての役割です。後になって蒸し返しのようなトラブルがあった時に、議事録によって既決事項であることを示せれば、交渉力が違ってきます。もちろん、訴訟になれば証拠にもなります。スルガ銀行と日本IBMの訴訟でも、議事録が証拠として重用されていたことは、記憶に新しいところです。

 議事録で一番の問題は、会議で重要な決定があったのに、議事録がきちんと作られていないというものです。つまり、事実に対応するエビデンスが欠けているという場合です。それでは会議をやった甲斐がありませんから、議事録の作成を励行すべし、ということになります。それはそれで、正しいことです。
 しかし、逆の問題もあります。議事録は一応作られているのに、実態がそれに追いついていないという場合です。例えば、ベンダが重要なシステム方針について資料を作り、会議でさんざん説明して異議は出ず、議事録も作って承認をもらい、その後数か月かかって設計と実装を進めた。ところが、システムが出来上がった段階で話を蒸し返されて、議事録を示しても、「当時は良く分かっていなかった」などと言われてしまう...
 もちろん、この場合の責任は、既決事項を蒸し返したユーザ側にあります。そのような勝手が許されるものではありません。しかし、この段階になって責任論を云々してみても、ユーザが当初の方針に本当に納得してないのなら、事は収まりません。既決事項と言えるほどに機が熟していなかった場面での「エビデンス」は、裁判の証拠にはなるかも知れませんが、事後のトラブルに対する抑えにはなりません。残念ながら、トラブルの種でしかなかったわけです。
 これと似た話に、議事録の「みなし承認」というのがあります。「1週間以内に議事録案の確認がなされなかったら、記載どおりに承認したものとみなす」という取り決めです。これで承認する側の意識が高まれば良いのですが、逆に承認を求める側の詰めが甘くなりそうです。会議で苦労して「言質」を取ったと考える担当者は、議事録確認の段階でそれを覆されたくないと考えます。そうすると、議事録案を作成して1週間経った時点で、胸をなでおろしてそれで終わりにしてしまうでしょう。同じ蒸し返しをされるなら、実装後よりは会議直後の方がはるかにマシなわけですが、その「機会」は失われてしまうわけです。

拍手[0回]

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