-
- いいね！8
(๑╹◡╹๑)
@tsuchie88
具体的には、印刷帳票数、トランザクション数の数値(1618帳票、813業務フローの削減)を基本合意時点の削減目標として明記していて、今後の協議によっては更なる削減も可としている
2012-09-02 20:47:23
(๑╹◡╹๑)
@tsuchie88
基本合意から最終合意締結までのスケジュールが遅延したことに対して、すでいH17.10.15の協議(159頁)においてスルガ側から確認が行われている。スルガは担当常務より、1)期限が守られるのか、2)費用は収まるか、3)日本の銀行の標準機能は実現されるかの三点について重ねて確認
2012-09-02 20:53:27
(๑╹◡╹๑)
@tsuchie88
チュートリアルを三つほど。一般的なパッケージを用いたシステム開発案件では、事前の工数の見積もりをFit/Gap分析を用いて大まかな数字を確定させます。これは、パッケージによって実現できる機能(Fit)と、システムが最終的に実現したい機能との乖離(Gap)を洗い出しを行います
2012-09-02 20:59:30
(๑╹◡╹๑)
@tsuchie88
顧客の希望する機能をすべて実現させようとすると、Gapが大きくなるわけですが、たとえばSAPのようなERPパッケージを用いた開発では、ERPに自社業務を標準化させてGAPの数を少なくした上で、Fitしない機能について追加(アドオン)開発を行うことで、最終的な開発見積もりを行います
2012-09-02 21:01:50
(๑╹◡╹๑)
@tsuchie88
最終合意書添付の基本合意に規定されている、帳票やトランザクションの削減は、Fit/Gap分析によるものであると解することができますが、一方でCorebank/NEFSSがパッケージとしての完成度がなかったことを考えると、何を標準としてFit/Gap分析を行ったかが疑問となります
2012-09-02 21:04:08
(๑╹◡╹๑)
@tsuchie88
二つ目。H17.10.15の協議では、日本IBMの担当者より「IBMアジアパシフィック、FIS社を含めたチームにより今後の進め方についてレビューと開発方法の検討を実施中」とあります。NEFSSは、IBM本社の有する資産で、これをJapanizationする作業は日本IBMの担当
2012-09-02 21:07:03
(๑╹◡╹๑)
@tsuchie88
そして、Corebankのソフトウェアの所有権は外部のFISが保有していたため、こういった発言につながっています。つまり、Corebank自体はソースコードも含めて日本IBMもIBM本社も内容を知らないし、改変する権利もありませんでした。後の過程で大きな問題になります
2012-09-02 21:08:51
(๑╹◡╹๑)
@tsuchie88
三番目、スルガ側がなぜ最終合意書にあるH20.1.4稼動にこだわっていたのか？ 一般論ですが、銀行の基幹系システムは勘定系や情報系、ハブが重要といっても、多数のシステムやベンダーから構成されています。新経営システムにおいても、営業店システムは富士通、海外系システムは三菱UFJです
2012-09-02 21:10:54
(๑╹◡╹๑)
@tsuchie88
また、新経営システムの中核である情報系システムでも、独SAPの会計パッケージが使われる予定となっており、これらすべてがCorebank/NEFSSによる勘定系・情報系・ハブの更新を前提にプロジェクトが進められていました。仮に遅延するとなると大変な損害となります
2012-09-02 21:12:05
(๑╹◡╹๑)
@tsuchie88
さらに、既存の勘定系システムは、1980年代後半に構築されて以来同じシステムが使われているため、ハードウェアの保守期限も到来している状態でした。元々、スルガは積極経営から処理能力が不足していて、高速化を図るために勘定系の一部のシステムをPL/Iからアセンブラで書き換えていたほど
2012-09-02 21:14:00
(๑╹◡╹๑)
@tsuchie88
MVSのサポートも、2000年に後継OSの64bit化されたz/OSがリリースされ、31bit系のMVSは一般には2007年が最終サポート期限になっていました。つまり、ハードやソフトの両面で、保守に不安を抱えることになり、また仮に継続して使用するには多額の費用が必要です
2012-09-02 21:19:05
(๑╹◡╹๑)
@tsuchie88
しかしですねぇ ジュリ・金法ベースで90ページの判決分ってちょっと読むの根性がいりますわ・・・。逆に言えば、地裁判決レベルで全文が掲載されるってのは、関心の高さを伺えますけど、だからって同号の小林教授の判例評釈は、内容的に微妙すぎる印象がありますね。ちゃんと読んでたのか、と
2012-09-02 21:30:48
圓道至剛（まるみちむねたか）
@marumichi0316
長さゆえにちゃんと読むのを躊躇しておりましたが、読んでみます！RT @tsuchie88: しかしですねぇ ジュリ・金法ベースで90ページの判決分ってちょっと読むの根性がいりますわ・・・。逆に言えば、地裁判決レベルで全文が掲載されるってのは、関心の高さを伺えますけど、…
2012-09-02 21:42:39
(๑╹◡╹๑)
@tsuchie88
@marumichi0316 小林教授が指摘されているように、個別契約により改定を前提とした最終合意文書を前提にプロジェクトマネージメント責任と説明責任を認定した点について、若干疑問はありますが、大規模プロジェクトの運用実態から見ると結果的には納得できるかな、と思いました
2012-09-02 21:50:50
(๑╹◡╹๑)
@tsuchie88
スルガ「神原駿河だ！ 神原駿河！ 主な武器は加速装置だ！」 IBM「お前・・・サイボーグだったのか！」 スルガ「その声はIBM先輩だな。ちょっと待ってくれ。裸になるから」 IBM「なんでだよ！」 スルガ「要件定義段階とは言えIBM先輩と協議するのだから裸になるのが礼儀だ」
2012-09-03 20:16:58
(๑╹◡╹๑)
@tsuchie88
銀行の基幹系システムの構成要素のひとつとして、ハブをさらっと紹介しましたが、もう少し詳しく。一般的にハブというと、車輪部品とか、ネットワーク機器を言いますが、大規模オンラインシステムでは、Hub & Spoke modelの主要要素の意味で使います。
2012-09-03 20:27:14
(๑╹◡╹๑)
@tsuchie88
大規模なオンラインシステムでは、さまざまなシステムの間でデータを交換する必要あります。特に、銀行基幹系システムでは、多数のシステムが大量の情報を交換していますが、個々のプログラムが、それぞれ独自のフォーマットデータ交換を行っている例が多く、保守に非常に手間がかかっています
2012-09-03 20:29:55
(๑╹◡╹๑)
@tsuchie88
たとえば、インターネットバンキング(IB)のシステムで考えてみますと、勘定系とIBが直接接続されている形式だと、たとえば勘定系のプログラム改修を行ってデータフォーマットが変わると、IBのシステムも改修する必要が出てきます。ハブはこういった手間を省くため、データ形式を標準化する仕組
2012-09-03 20:39:45
(๑╹◡╹๑)
@tsuchie88
ただ、ハブ化には非常にコストがかかるため、地方銀行ではあまり進んでないのが実情です。特に、独自のオンラインシステムを保有している地銀が、パッケージでシステムを更新しようとする際に、ハブ化されていないため、機能別に分けて更新するということができない理由でもあります
2012-09-03 20:43:13
(๑╹◡╹๑)
@tsuchie88
言い換えると、地銀において既存システムを更新する際は、予算にも技術的にも余裕がある大手銀行と違って、すべてのシステムを一斉に更新する必要があります。ですから、ある程度標準化されたパッケージを用いて、リスクを低減させるというのは、定石的であると言えます
2012-09-03 20:46:13
(๑╹◡╹๑)
@tsuchie88
最終合意書締結からわずか5日後に開催された協議において、期限、予算、機能の三つの遵守ができるのかスルガ側から重ねて確認されたのは、基本合意書締結から最終合意書締結に1年を要したことが大きく影響していると思われるが、結局この問題は最後まで尾をひく問題になる。
2012-09-03 20:54:45
(๑╹◡╹๑)
@tsuchie88
H17.12.12に日本IBM側から提示された資料では、すでにプロジェクト破綻の根本原因の芽が伺える。日本IBMは、要件定義がパッケージを使ったシステム開発の一般的な手法であるパッケージベースアプローチではなく、現行踏襲型アプローチを取っていたため、工数の増大を招いたと認めている
2012-09-03 20:58:27
(๑╹◡╹๑)
@tsuchie88
パッケージベースアプローチとは、パッケージが備えている基本的な機能をベースに工数を見積もる手法で、Fit/Gap分析を行う上で前提となる要素である。しかし、実際に基本合意書の段階で行われていたのは、現行システムの機能をそのまま実現する現行踏襲型アプローチだった
2012-09-03 21:01:00