記事内に広告を含みます

iDeCo-スルガ銀行、手数料0円やめるってよ

思うところがありまして、iDeCo(個人型確定拠出年金)の各金融機関のプランの差を調査していたところ、表題のスルガ銀行で手数料0円を中止するとの記事を見かけました。

スルガ銀行はIT業界ではおなじみの金融機関で、大きな民事裁判を起こし、IT業界の慣習すら変えてしまったこともありました。

今回、スルガ銀行を題材に記事を書かせていただければと思います。

■スルガ銀行を知ったきっかけ

今から8年近く前、当時の節税サラリーマンの勤務先では、確定給付型年金から企業型確定拠出年金へ移行したものの、3年程度で親会社に吸収合併されることとなりました。

問題は、親会社には企業型確定拠出年金制度が無く、個人型確定拠出年金に移行せざるを得ない状況となりました。

※吸収した側の会社に現在も勤務しております。

長年勤務してきたベテラン社員もいましたので、彼らは20~30年分の確定給付年金の資産をそのまま企業型確定拠出年金に移行しており、その資産金額はかなり(おそらく数百万)の金額になっていました。

iDeCo(個人型確定拠出年金)へ移行するにしても、大きな資産(数百万)を維持したまま定年で受け取りたいと考えている人や、子供が3人いて新たに資金を拠出する事が難しいなど、運用指図者(新たに掛金を出すことなく、金融商品の運用だけを行う人)になりたいと考える人が多く、新たに資金を拠出する人は少数派だったと記憶しております、

その当時、手数料が安かったスルガ銀行、SBI証券に口座を移す人が大多数でした。

このあたりの経緯にご興味ある方は、下記ご参照ください。

企業型確定拠出年金、自動移換にご用心は真実か?

■スルガ銀行がIT業界に与えたインパクト

●スルガ銀行が日本IBMを提訴

2008年2月にスルガ銀行が日本IBMを訴え、最終的には約42億円の賠償が日本IBMに命じられました。

スルガ銀行が新たに導入しようとしていた基幹システムを、日本IBM側で開発、稼動できなかったことがそのきっかけになります。

数字の内訳としては、日本IBMに直接支払った費用が65億円、日本IBM以外に支払ったハード・ソフトウェア費用が9億円、合計74億円の内、約42億円の賠償が命令されました。

この約42億円は第二審(東京高等裁判所)で出た判決で、こちらを日本IBMが上告、最高裁が棄却し確定となりました。

IT業界にインパクトを与えたのはその前の第一審(東京地方裁判所)で出た判決で、スルガ銀行が支払った74億円満額を賠償するよう、日本IBMへ命令いたしました。

●ITシステムの導入手順

大規模なITシステムの導入に際しては、
概ね以下のようなプロセスを踏みます

①システム要望が出ると、各システムベンダーへ
概要提案依頼を出します。(RfIと呼びます)

②システムベンダー各社は、その要望に対して
どのように進めるべきかユーザへ提案します。

③ユーザは提案の中から、自分たちが進むべき方向性をきめ、
その内容を書面にします。

(RfPと呼びます。開示先は②から絞り込んで提示する場合が多いです。)

④システムベンダー各社は、RfPに記載されている内容を
実現できるITシステムを提案します。

⑤ユーザは各社の提案を比較し、
最も妥当な提案を行ったベンダーと詳細を詰めた上で
契約を行います。

⑥ユーザと契約したシステムベンダーは、
実際の導入はどのように行うべきかを関して検討を行います。

(これを要件定義と呼びます。)

また、E/U側では必要な機能一覧を提示し、ベンダー側では提案内容で実現できること、出来ないことを明確にし、合意を得ます。(フィット&ギャップと呼びます。)

補足
「RfPにフィット&ギャップに含めれば良いのでは?」と思うかもしれませんが、RfPはせいぜい数十ページ、要件定義書とフィット&ギャップは数百~数千ページ規模になります。

報酬の発生しない提案段階で、そのような作業を無償で行うことは現実的ではありません。

⑦要件定義が固まれば、あとは各領域ごとに分かれ、
設計、実装作業を進めて行くこととなります。

今回の件では、⑥が終わらず、訴訟にいたっております。

●第一審判決後、IT業界の変化

(1)パッケージソフトから、スクラッチ開発へ

最近まで、基幹システムの入れ替えの際には、ERPと呼ばれるようなパッケージソフトに、カスタマイズを加え導入していくことが一般的になっていました。

これにはもちろん理由があり、パッケージソフトを提供するシステムベンダーは、顧客に導入するごとに要望を聞くのですが、その中で、システムベンダーが必要だなと思った機能は基本機能に追加されていくことが一般的です。

そうなりますと、導入実績の多いパッケージソフトは、ユーザにとって必要な機能があらかじめ実装されていることとなります。

そうすると、比較的簡単に導入が出来るうえに、そのパッケージソフト利用することで、業務フローまで最適化できます。

今回のスルガ銀行の訴訟の件では、システムベンダーが適切なパッケージソフトを選定していない点が問われました。

事実、そのパッケージソフトは日本での導入事例が1件もなく、その第一審判決を見た弁護士、ジャーナリスト、
企業の情報システム担当者が口々に本件を語りだし、パッケージソフトを選定、導入する場合、スクラッチ開発(※)と比べて責任が重いとの共通理解が醸成されました。

※の補足
パッケージソフトなどを利用しないで、一からプログラムを作っていく開発手法。パッケージに依存しないため自由な開発が可能ですが、バージョンアップ、一部回収の費用が高くなりがちです。

(2)検収と支払いは別タイミングへ

ITシステムの開発では、ひとつの工程が終わるごと、その内容に関してユーザに承認(検収と呼びます)を求め、
次の工程に進みます。

工程ごとに終わりを定めませんと、過去にさかのぼりながら修正を行う必要が生じて、いつまで経っても終わりが見えなくなるため、上記のような検収作業を行うと共に、その段階まで費用を請求することが一般的でした。

今回の第一審判決では、システムの稼動まで至らない場合、その費用の全額を日本IBMが負担することとの命令が出たため、段階ごとの請求を行う頃が出来なくなりました。

※補足
第二審判決では、上記の⑦以降部分が賠償対象となり、それが約42億円になります。⑥はユーザ、システムベンダ双方に責任が生じているという妥当性のある判決になっております。

●スルガ銀行がIT業界に与えた功罪

(1)パッケージソフトから、スクラッチ開発へ

(2)検収と支払いは別タイミングへ

正直なところ、この判決は企業のIT投資に暗い影を落とすかもしれません。

一見、ユーザ側にとっては、システムの稼働まで達しなければ費用を払わなくて済む、比較的枯れた(IT業界では古く安定したシステムをそう呼びます)システムを導入するために、情報システム担当者は新たな学習をしなくて済む、といった点が挙げられます

半面、先進的なシステム投資を行いたいと考えた日本企業があった場合、そういったシステム提案、導入には提供する側のリスクが高くなってしまうため、リスク回避のため提案を断られるケース、提供は行うものの、契約でガチガチにリスク排除を行った結果、合意に至らないケースがあるかもしれません。

■まとめ

いかがだったでしょうか?

タイトルは、「桐島、部活やめるってよ」を少々パクリ、映画同様、タイトルはきっかけに過ぎず、中身とタイトルの関係性が薄い点も真似てみました。

長年、iDeCo(個人型確定拠出年金)の手数料0円で頑張ってこられましたが、2017/1の法改正からこの半年で競争は激化しており、既存顧客の維持に舵を切ったのかもしれません。

定期預金では非常に有利な商品があることもあり、50代後半になった段階でお世話になるかもしれず、今後も頑張っていただければと思っております。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です