忍者ブログ
プロフィール
メニュー
最新コメント
最新トラックバック
1  2  3  4  5  6  7 
 いわゆる「宙に浮いた年金記録」、「消えた年金記録」の問題が発覚してから10年近くが経ちますが、とても解消とは言えない状態のようです。最悪の場合、記録の不在により受給できるはずのものが受給できなくなるのですから、社保庁の責任は重大です。立派な「債務不履行」であり、民間企業であれば破綻していておかしくない事態です。ただ、記録の性質上、こうなるだけの十分な理由もまた存在します。

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

拍手[1回]

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

拍手[0回]

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

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

拍手[0回]

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

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

拍手[0回]

author : ITS 
 それまで順調に動いていたシステムが、突然ダウンしました。よくよく調べてみると、データベースの定義に余計なユニーク指定のあるのが原因でした。この手の話は良く聞きますが、何かのヒントを含んでいるように思えます。

 ベテラン技術者の曰く、データベース設計をした担当者は、ユニーク指定の意味が、指定のデータでレコードを一意に特定「できる」ことにあるのではなく、一切の重複データの存在を「許さない」ものであることを、理解していなかった。例えば、請求テーブルがあったとして、取引先と請求日を合わせれば、通常はまずユニークになるものです。しかし、そのようなものにユニーク指定すれば、何かの例外データ(例えば、移行データ)を遭って、たちまちアベンドしてしまいます。何よりも、わざわざユニーク指定する「意味」がありません。同じデータ項目の重複を許さない、そのことを、システムを強制終了させてでも貫徹させなければならない場合こそが、ユニーク属性の出番なわけです。
 話を法律に移して、業務提携の契約書を作る場面を考えます。この場合、取扱商品や営業地域が(放っておいても)現にこうなっている、ということは書く必要がありません。プレゼン資料などに、書きたければ書いても構いませんが、それだけの話です。契約書に書くべきは、取扱商品や営業地域の切り分けをして、(破りたくても)その切り分けは守らなければならない、という場合です。自社の主力である「○○端子」を提携先が扱ってもらっては困る、そのことを、裁判に訴えてでも貫徹させなければならない場合こそが、契約書の出番なわけです。こちらの方は、そうでなくても、契約書が無駄に長くなる以上の不都合はないかも知れませんが。
 言葉を換えれば、「世界がどうなっているか(As-Is)を記述する」ことは、ユニーク指定がそうであるのと同様に、契約書の役割ではありません。「世界がどうあるべきか(To-Be)を宣言する」ことが、ユニーク指定がそうであるのと同様に、契約書の役割です。

拍手[0回]

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