全銀システム障害の原因判明、メモリー不足でインデックステーブルが不正確な状態に
銀行間送金を担う「全国銀行データ通信システム（全銀システム）」で2023年10月10～11日に発生した障害の原因が10月16日、分かった。全銀システムと各金融機関のシステムをつなぐ中継コンピューター（RC）において、メモリー不足に起因し、金融機関名などを格納したインデックステーブルに不正な値が紛れ込んだ。 インデックステーブルはRCのディスク上にあるファイルから展開する。このファイルを作成するプログラムを実行したタイミングで、一時的に確保するメモリー領域が不足し、ファイルの内容が不正確になったという。 全銀システムの障害を巡っては、三菱UFJ銀行やりそな銀行などで他行宛ての振り込みに遅れが生じた。全銀システムを運営する全国銀行資金決済ネットワーク（全銀ネット）によると、概算値ながら10月10～11日の2日間で仕向けと被仕向けを合わせて500万件超の送金に影響が出たとしている。
チーム開発実践入門を頂きました - garbagetown
著者の池田さんより、レビューを担当させて頂いた書籍「チーム開発実践入門 ～共同作業を円滑に行うツール・メソッド」 を頂きました。ありがとうございます。 チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus) 作者: 池田尚史,藤倉和明,井上史彰出版社/メーカー: 技術評論社発売日: 2014/04/16メディア: 単行本（ソフトカバー）この商品を含むブログ (3件) を見る チーム開発の現場 本書の第一章に書かれている通り、複数人でシステムを開発する場合に気を付けなければならない課題が山のように存在します。リソース管理、課題管理、報告・連絡・相談、リリース管理などなど、タスクの八割以上はこれら課題に関連するものと言ってもいいと感じるほどです。 また、ひとりで開発する場合でも、過去の自分は赤の他人なので、本書に書かれている内容はやはりとても重要なも
ANA、国内線の旅客システムをオープン化、34年間のメインフレームの歴史に終止符 | IT Leaders
30年以上にわたり使い続けたシステムを入れ替える。企業ITに携わる人間ならば、その困難さを想像するのは難しくないはずだ。このほどANAは、8年間の歳月をかけて、国内線の予約、発券、搭乗業務を支える旅客システムをオープン化。34年間、ビジネスを支えたメインフレームに別れを告げた。プロジェクトの指揮官に話を聞く（文中敬称略）。聞き手：田口 潤 IT Leaders発行人 Photo：陶山 勉 ――今回、8年間にわたる国内旅客システムの刷新という大規模プロジェクトを終えた訳ですが、もともと、いつ頃から検討を始めたのですか？金子：“次”を考え始めたのは、2000年頃だったと思います。30年以上にわたって、メインフレームを使い続けてきましたが、そのころから限界を感じ始めていたのです。 コストについては、必要経費ですから、それほど問題視していませんでしたが、むしろ、技術者の確保には頭を悩ませていました
みずほ銀行のマルチベンダー化について解説する - novtan別館
はてブではすでにボロクソ言われてますね。フラグ立ちまくりと。ちょっとこれは解説せねばなるまいか… 以下はすべてとある人からの伝聞です。伝聞なんだってば。 みずほ銀行が次期システムの開発をマルチベンダー体制で進めることが日経コンピュータの取材で判明した。富士通、日立製作所、日本IBM、NTTデータの4社に分割発注する。 ［スクープ］みずほの次期システムはマルチベンダー、4社に分割発注 | 日経 xTECH（クロステック） 周知の話だけすると、現行システムにおいては 勘定系（ホスト）…富士通 営業店端末システム…富士通 インターネットチャネル（ダイレクトバンキング）…IBM 情報系システム…IBM 周辺系（中継系）…IBM 外部接続系…日立 コーポレート銀行勘定系…日立 等々、すでにここに出てきているベンダーがマルチベンダーの状態で仕事をしている。また、ここ重要なところだと思うけれども、ベンダ
第3回 詳細設計工程のITアーキテクト
ITアーキテクトが作成する成果物に注目し、何のために作るのかを明らかにします。システム開発のライフサイクルを軸にし、今回は詳細設計工程を対象にします。詳細設計工程では、主に次の5つの成果物を作成します。 （1）機能パッケージをまたがる状態遷移図 （2）排他制御（ロック）仕様書 （3）コンポーネント図 （4）インピーダンスミスマッチの解決手順書 （5）物理データモデル図 この工程のポイントは「変化への対応」です。システムへの要求仕様は決して確定しません。開発途中も初期リリース後も変化し続けます。この「変化」にどう対応するのか、これが情報システムの「本質的な複雑さ」の正体です。検証しやすさを最大化し、変化対応時の影響範囲を局所化するように、モジュール分割の基準を決定します。 ITアーキテクトは、要求仕様の全体整合性に責任を持ちます。準正常系や異常系の仕様など、これまで明文化されなかった「暗黙の
第2回 基本設計工程のITアーキテクト
ITアーキテクトが作成する成果物に注目し、何のために作るのかを明らかにします。システム開発のライフサイクルを軸にし、今回は基本設計工程を対象にします。基本設計工程では、主に次の5つの成果物を作成します。 （1）論理データモデル図 （2）パッケージ図（永続化視点） （3）パッケージ図（機能視点） （4）アーキテクチャー設計ドキュメント （5）アーキテクチャー評価ドキュメント ITアーキテクトのはこの工程で、アプリケーションの構造を創出し、その構造を評価します。基本設計工程ではサブシステムごとに設計作業を進め、要件定義の深堀や、要件の変更（改善）が発生しているはずです。そこでITアーキテクトのタスクとしてポイントになるのは、並行する設計作業間で矛盾が生じないようにサブシステム間の依存関係を整理し、また、そのアプリケーション構造を支えるインフラを含めてアーキテクチャーを設計することです。 ITア
第1回 要件定義工程のITアーキテクト
ITアーキテクトが作成する成果物に注目し、何のために作るのかを明らかにします。システム開発のライフサイクルを軸にし、今回は要件定義工程を対象にします。要件定義工程では、主に次の5つの成果物を作成します。 （1）Vision Document （2）利害関係者マップ （3）概念機能モデル図・概念データモデル図 （4）非機能要件定義書／品質特性シナリオ （5）グランドデザイン ポイントは「ビジネス視点」と「システム視点」の両方を持つこと。技術者は総じて「How（どのようにつくるか）」への思考（＝システム視点）が先行しがちです。これでは「間違ったものを正しくつくる」ことになってしまいます。それを避けるには、「Why（なぜつくるのか）」と「What（なにをつくるのか）」を明らかにすること、つまり、ビジネス視点を持つことです。 ITアーキテクトは、アーキテクチャー設計に対する「説明責任」が伴います。
日本のシステム開発は“井の中の蛙”か
日本のIT現場で、日々当たり前に進められているシステム開発。そのやり方に、疑問を抱くことはまずないだろう。しかし、第三者の目で見ると、そこには世界の常識とは異なる部分がある。 別のやり方を知る外国人の目を通して日本のシステム開発を眺めることで、日本のやり方の良い点や他国に見習うべき点が浮かび上がってくる。日経SYSTEMS 2012年9月号の特集1「ここがヘンだよ 日本のシステム開発」の取材活動で、日本のIT現場で活躍する外国人エンジニアや、グローバルなシステムの開発に携わることが多い日本人エンジニアに、日本と外国のシステム開発の違いについて聞いた。取材を通じて、日本のシステム開発で独自性の高いところが多数明らかになった。ここでは、複数の人から「これはおかしい」と指摘された3点に絞って紹介する。 開発者は常に文句を言われる立場 香港出身で中国と米国、日本においてシステム開発経験が豊富なある
最強のIT系かあちゃんからたかしへのアドバイス
バーンれっどさーん @ledsun たかしへ あなたの勤怠確認しました．こんなに残業が多い割に大して売上が上がってないのはどうしてですか？顧客との信頼関係の構築も甘いとと思います．来月からは頑張って下さい．ちなみに母さんは今月、10人月で作ったシステムを3000万で売ってきました。 バーンれっどさーん @ledsun たかしへ あなたの立てたスケジュール読みました。作成工数だけでバッファがありません。予想外の事態が起きた時はどうするのですか？残業でカバーですか？お客様が参加するイベントが入っていません。都度調整ですか？事前に提示していないと都合がつかなくても納期延長できませんが大丈夫ですか？ バーンれっどさーん @ledsun たかしへ あなたの作った機能仕様書読みました。技術的面ではチャレンジグで素晴らしかったです。でも、このシステムを使う人にどういうメリットがあるか分かりませんでした。
富士通の3万人SE職務転換大作戦は成功するのか？ - GoTheDistance
全文は紙面でないと読めないのが残念ですが、非常に気になるニュースが飛び込んできました。 富士通、余剰ＳＥ変身作戦 富士通がグループで抱える約３万人のシステムエンジニア（ＳＥ）の大がかりな職務転換に乗り出した。一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むＳＥは仕事がなくなり、余剰人員問題が顕在化するからだ。野副州旦元社長の急進的な改革路線を修正した富士通はＳＥ余剰問題で軟着陸を目指すが、クラウドの奔流にのみ込まれる危うさもはらむ。 富士通、余剰ＳＥ変身作戦 実は富士通グループさんには弊ブログを頻繁にご覧頂いておりまして、企業ドメインの中では最もアクセスの多いドメインであります。クロールしにきているのかなと思うぐらい。ブログで言及している「なんでもかんでも受託開発では、もうSIビジネスで成長することは出来ない」という危機
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
