-
- いいね！403
(๑╹◡╹๑)
@tsuchie88
これ以外にも、ハードウェアとしてはメインフレームを使っているが、OSはLinuxを使っている(z/Linux)部分は数多い。メインフレームの処理能力と信頼性はUNIXマシンやIAサーバと比べて圧倒的に高くこの選択肢自体は間違っていない。
2016-07-08 20:39:14
(๑╹◡╹๑)
@tsuchie88
その他のシステムでは、基本的にAIXまたはLinux上でJavaベースでシステム開発が行われている。大規模システム開発では、主に要件定義と基本設計、それからテスト工程に費用がかかるので、稼動プラットフォームが何だろうとシステム開発に与える影響は少なくなる。
2016-07-08 20:43:44
(๑╹◡╹๑)
@tsuchie88
Q「次期死すでは、マルチベンダー開発が取り入れられたと聞きましたが、これが諸悪の原因では？」 現代の大規模開発では、ほとんどといっていいほどマルチベンダー開発の体制になっている。たとえばBTMUの場合、勘定系はIBM、情報系は日立のようにシステムブロックごとに分散するのが一般的
2016-07-08 20:46:35
(๑╹◡╹๑)
@tsuchie88
問題は、さまざまなベンダーやプラットフォームを取り入れた状態で、最適調達・最適設計・最適開発を行うことがキモなので、発注者側の能力がこれまで以上に求められることになる。じゃなかったら、アウトソーシングでもしてなさいってこった。
2016-07-08 20:49:44
(๑╹◡╹๑)
@tsuchie88
Q「GoogleやAmazon、WebゲームのようなLAMPで構成されたシステムの方がはるかに高度なことをやってる気がします。アプローチが古いのではないでしょうか？」 キミ、ロケットのエンジンの出力と船舶等ディーゼルエンジンの出力比べて、ロケットの方がすごいとか言っちゃう系？
2016-07-08 21:00:39
(๑╹◡╹๑)
@tsuchie88
Q「STEPS(一勧のシステム)なんか使わずTOPS(富士銀のシステム)」使ってたらこんなことにはならなかったんでは？」 富士銀死ね(挨拶) TOPSはすでに10年以上前に開発が終了したシステムなので、今さら採用してたとしても大量の追加開発が必要だったはず。あんま意味ない
2016-07-08 21:08:02
(๑╹◡╹๑)
@tsuchie88
そもそも、TOPSが旧BK系システムに採用されなかった(こじつけ的)理由の一つに、PL/Iが基本で高速化のためにアセンブラ使いまくってたから、設計が新しい(基本的にCOBOLしか使ってない)STEPSがいいという判断もあった。まぁ旧BTMもアセンブラ上等だけど
2016-07-08 21:12:08
(๑╹◡╹๑)
@tsuchie88
そもそも、次期死すはアーキテクチャ自体の問題ではなくて、融資や為替などの業務系システムの仕様を旧CBの手順にあわせて、旧BKを滅ぼすというところに目的があるので、合併前の富士銀のシステムなんぞ考慮に挙がるわけがない
2016-07-08 21:14:08
(๑╹◡╹๑)
@tsuchie88
Q「やっぱりこれは旧三行の内部抗争が原因ですよね？」 富士銀死ね(挨拶) 基本的には、ラインハルト・フォン・サトゥ侯が権限を掌握した現在において、内部対立でシステム開発がどんずまった、というのはあんま考えにくい。
2016-07-08 21:20:09
(๑╹◡╹๑)
@tsuchie88
「CB系システム(C-Base)の設計で、BK系システム(STEPS)を刷新する」ところに次期死すの最大級の目的があるわけで、旧富士銀をベースにするシステムといったら、チャネル系システムや情報系は富士銀の設計がベースなんでシステムに内部対立が影響してるようには思えなんだ。
2016-07-08 21:30:23
(๑╹◡╹๑)
@tsuchie88
だいたい、合併して何年経ってるかって話だ。末端は大半が、合併後。40代以上のミドル層ならまだしも、DKBだのIBJだのクソ富士銀行だの以前に、CBかBKかってところが重要なわわけで三行対立って上の人の話じゃないか？
2016-07-08 21:43:17
(๑╹◡╹๑)
@tsuchie88
Q「銀英伝的に例えると？」 神聖みずほ銀行の基幹系システムは、協力会社SEの屍体によって舗装された！ ジークカイザー・サトゥハルト！ ジーク興銀！ ジーク one mizuho！
2016-07-08 21:51:58
ゆ〜げきぶちょーF/S&RWAs
@fstora
@tsuchie88 なるほどです。ということはやはり、純粋に高難易度の案件であったこと、要件定義フェーズに十分に時間を取れなかったことが要因ですかね…。
2016-07-08 23:13:10
ゆ〜げきぶちょーF/S&RWAs
@fstora
@Matsukaze_Taka (`Д´)ゞﾗｼﾞｬｰ!! しかし逆にそうなると死ぬほど時間をかけて地道になおすしかないですね(ヽ'ω`) @tsuchie88
2016-07-08 23:30:24
(๑╹◡╹๑)
@tsuchie88
@fstora @Matsukaze_Taka 問題はそこで、「時間をかければ＝追加の工数を入れれば直る問題」なのか「そもそも要件段階でのアプローチがダメだったのでかなり後戻りが必要な問題」なのかどっちなのか、ってところ。部外猫なので、まったく分からないのだけど、後者の可能性大
2016-07-09 07:38:43
(๑╹◡╹๑)
@tsuchie88
基幹系システムの刷新が難しいのは、技術的な問題というよりも影響範囲が大きいのでリスクのある刷新がやりにくいという点で、「欧米のシステムは新しいテクノロジーを使って費用安い！」なんてのは本当海外のシステム知ってるのか、と思う。
2016-07-09 07:41:35
(๑╹◡╹๑)
@tsuchie88
そらWeb系みたいな、新しい領域で新しくサービスを立ち上げる場合なら当てはまると思うのだけど、伝統的な企業が昔から使ってる基幹系を置き換える場合だと違うだろうよ、と(Amazon自体、クラウドで企業基幹系は領域違うで、といっとるしな)
2016-07-09 07:42:54
(๑╹◡╹๑)
@tsuchie88
もう一つあるのが、基幹系の中でも財務会計みたいなシステムは重要なことには違いないのだけど、「まぁちょっとくらい止まっても決算業務に支障がなけりゃいい(遊撃がチャレンジすればいい)」んだけど、銀行勘定系とか航空管制とかネットショップの販売システムとか、止まると業務が止まって客が困る
2016-07-09 07:48:28
(๑╹◡╹๑)
@tsuchie88
しかも、前者が業務を単純化してシステムの複雑化・個別化を防ぎやすい(業務は煩雑になるかもしれないが)のに対して、後者は現場の手順を変えることになるから、なかなか単純化がしにくい
2016-07-09 08:13:38
(๑╹◡╹๑)
@tsuchie88
たとえば、前者の場合今までキー一つで印刷されてた帳票を、遊撃が4本のテーブルからクエリ引っ張って来る手間を増やすだけで済む話だけど、後者の場合いったん着陸した飛行機に機能が集約化されたからもう一度着陸やりなおせ、とは言えない。
2016-07-09 08:15:16
(๑╹◡╹๑)
@tsuchie88
そういうわけで、基幹系の統合を行う場合には、たとえばAとBという異なるシステムを統合する場合には、AとBのシステムを比較してどちらのシステムに統合した方が工数が少なくなるかを分析する(F&G分析)。F&Gだけでなくそもそも企業の事業戦略にどちらのシステムが適しているかが加味される
2016-07-09 08:57:05
(๑╹◡╹๑)
@tsuchie88
たとえば、BTMUの基幹系統合の際は、システムのキャパシティとしては(2年前に統合したばかりなので新しかった)UFJ側のシステムではなく、BTM側のシステムが選ばれた。BTMは規模は大きいのだが、BOTとの統合から時間が経っていて、相対的にキャパシティが低かったにもかかわらずだ
2016-07-09 08:59:22
(๑╹◡╹๑)
@tsuchie88
みずほの場合も、規模の大きいBKではなくCBが存続会社としてBKを吸収合併した形になっているし、ホールセール業務など収益の根源はCBにある。ただしCBにはリテール業務がないので、CB側にあわせるとBTMUと比較にならないほど膨大な追加開発が必要になる
2016-07-09 09:03:25