巨大銀行の巨大システム開発で大変素晴らしい経験を得たという話
最近まで、ネット上のIT系ニュースで度々システム障害で我々にネタを提供してくれる某巨大都市銀行の次期システム開発に下請けとして新卒から参画していた。「某巨大都市銀行の次期システム」という時点でどこの銀行かピンとくると思う。次期システムとは大雑把にいうと80年代に構築され今なお稼働しているシステムのうち、外為、内為、預金などの業務にて稼働するサービス(実際のプログラムになる)を疎結合化してそれぞれのサービスを部品として再利用性やメンテナンス性の向上を図る、いわゆるSOA(サービス指向アーキテクチャ)で作り直そうというものだ。この辺も心当たりのある銀行と次期システムとかでググれば出てくると思う。銀行システムをSOAで構築するのは日本では初めて！！すごい！！先進的！！！という触れ込みだったらしいが、立ち上げからいるわけでもなくSOAの利点も結局実感できぬままこの業界から去ってしまったので本当に謎
ちょむメモ: SIerのジレンマ
2012年1月25日水曜日 SIerのジレンマ なぜ、AppleやGoogleやMicrosoftといった米国のIT企業は優秀な技術者を重視し、日本のSI企業は技術者を軽視するように見えるのだろうか。 実のところ、これは誤った問いだと思う。パッケージベンダやWebサービス企業とSI企業とでは利益構造が全く異なっており、技術者に対する態度の違いは、国の違いというよりは業態の違いに大きく依存している。 パッケージベンダやWebサービス企業について考えよう。彼らの売上はユーザー数に比例するが、コストはそうではない。コストの大半は開発費という名の固定費であり、ユーザーが一人増えてもコストは殆ど増加しない。だから、競合より優れたソフトウェアを作るために二倍の開発費がかかったとしても――それによってユーザー数が十分に増加すれば――価格はあまり上がらないか、場合によっては下がることさえある。 一方
20130423 #devlove 職場を劇的にさせる四十八手 —「n次請けSIerでも出来ること」のその続き—
2013/04/23に株式会社ぐるなび様で開催した「We energize us - 明日の現場を高揚させるプラクティス - ( http://devlove.doorkeeper.jp/events/3511 )」で発表した内容です。 「We energize us」では現場に活力を与えるプラクティスのパタン化「Energize Pattern」の創造を目指しています。興味のある方は是非Facebookグループ「We energize us - 全速前進アクション共有 ( https://www.facebook.com/groups/571206772891343/ )」にご参加下さい。 ※2022/04/11追記 Speaker Deckに移行しました。 https://speakerdeck.com/takigawa401/20130423-number-devlove-zhi-c
@tsuchie88さんによるスルガ銀行ｖｓ日本IBM裁判のまとめ
(๑╹◡╹๑) @tsuchie88 ［続報］スルガ銀-IBM裁判、東京地裁はITベンダーの責任を重く認定 - ニュース：ITpro http://t.co/URFcTOGF #itprojp ようやく判決か・・・業界注目の裁判だったけど、やっぱりIBMの無理は通らなかったか 2012-03-29 19:41:57 (๑╹◡╹๑) @tsuchie88 背景的な話をすると、地銀でもユニークな経営で知られているスルガ銀行は、ネット支店の先行例でありほとんど唯一といっていいほど収益を上げてるところなんだが、勘定系システムに関しては80年代に構築された三オンベースのシステムを使い続けている 2012-03-29 19:44:36 (๑╹◡╹๑) @tsuchie88 00年代に入って、都銀に続いて地銀でも三オンの更新時期を迎えると、NEC、富士通、NTTデータ、日立、UNISYSがそれぞれ自社開
SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道
某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか？という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、食わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と
[PDF] 調査報告書 平成２２年８月２０日 特許庁情報システムに関する調査委員会
調査報告書 平成２２年８月２０日 特許庁情報システムに関する調査委員会 目次 第１部 調査の経緯及び目的 ・・・・・・・・・・・・・ １ 第２部 事実関係の解明及び再発防止策について （事実解明チーム担当） ・・・・・・・・・・・・・ ３ 第１ 事実解明チームの調査方法等 ・・・・・・・・・・ ３ 第２ 事実関係 ・・・・・・・・・・・・・・・・・・・ ５ 第３ 法的検討 ・・・・・・・・・・・・・・・・・・・２２ 第４ 再発防止策の提言 ・・・・・・・・・・・・・３３ 第３部 特許庁情報システムの技術的検証及び今後 の開発に向けての提言（技術検証チーム担当） ・３８ 第１ 技術検証チームの目的、検証対象及び検証方法 ・３８ 第２ 最適化プロジェクトの概要 ・・・・・・・・・・４０ 第３ これまでの設計の経緯 ・・・・・・・・・・・・・４７ 第４ 「設計成果物」の技術的検証 ・・・・・・
システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道
どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ１０数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体（特に技能として）化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NTTデータ公式サイト
新生銀行 - 国内事例 - CASE FILE - CIO Online