銀行はなぜ合併しなければならなかったのか
江戸時代の日本は米・金・銀という三種類の通貨システムを平行して扱っていた。徳川幕府と諸侯領(明治時代以降藩と呼ばれるようになるやつ)が入り乱れた連合国家であった。諸侯領間における政治経済システムの違いは大きかった(要するに戦国の遺風を引きずった藩とそうでない藩があった)。上記のような事情があった結果金融業の発達は著しく、幕末には多くの諸侯がこうした金融業者の支配下に置かれるありさまだった。 明治政府は戊辰戦争後、 近代的金融システムの成立戊辰戦争の戦費として発行された政府紙幣の償還金貨の流出が著しいという現状の対処などといった問題に対処するために、新貨条例および国立銀行条例が制定した。これらの制度は 実質金銀複合本位制国立銀行というが国立銀行条例という法令に基づいているが実際は民間資本による銀行である民間銀行が国債を担保に兌換券を発行することができるというなにがなんだか分からない制度になっ
見積もりがブレるメカニズム
三者三様の見積もり結果となった。工程別に工数を積み上げるやり方，ステップ数を生産性係数で割って工数を算出するやり方，FP法を使うやり方など見積もりプロセスはまちまち。コストの見積もり結果も165万円から300万円までと，大きな差があった 3人はいずれも10年以上のキャリアを持つベテランSEである。にもかかわらず，見積もり結果には大きな開きが出た。なぜこんなに差が出たのか。彼らが使った手順とそのコメントから考えてみよう。 銀行のシステム開発・運用を担当する小沢勉氏（仮名，46歳）の場合，最初にプロジェクトを「基本設計」「詳細設計」「プログラミング」といった工程別に分割し，それぞれに必要と思われる工数を積み上げた。ただ，小沢氏はWebシステムの開発に携わった経験がない。「ホスト系の開発と同じような感覚で素直に計算すると，実績とズレた値が出ると思った。なので，工数の一部を修正した」と言う。 中堅
世界最大のプロジェクトをこう見積もった
大規模，複雑，厳しい納期――。昨年秋に完全統合したJAL/JASの情報システム。成功を収めたプロジェクトの裏に，見積もり精度の高さがあった。プロジェクト・マネージャ（PM）を務めた岡村正司氏に，どのように見積もったのかを聞いた。（聞き手は本誌 池上俊也） JAL/JAS統合とはどんなプロジェクトだったんでしょうか。 岡村：昨年10月に完全統合しましたが，日本航空（JAL）と日本エアシステム（JAS）の約160のシステムを，JAL側のシステムに片寄せするものでした。工数は全体で1万2000人月，規模は8000万ステップと，とんでもなくデカいものです。IBMが手掛けてきた案件の中でも世界最大級でした。 時間の制約も厳しい。2002年初頭に始まったプロジェクトは，2年間で中核部分をすべて統合しなければならない。失敗は許されませんでした。 岡村さんがPMとして招かれたときの様子を聞かせてください。
20万人月の作業を1人でやる話 〜1万7千年生きたSE〜 - 特別天然記念物
昔々、具体的には約1万7千年前の旧石器時代、大学の情報工学科を卒業して、新卒22歳でSIerに就職した男(以下SE)がいました。 SEはある日、上司に言われました。 「2016年くらいに、銀行で大規模な基幹システムが必要になるらしいから、今から君一人で作り始めて。工数は20万人月ね。」 そういうと、上司はシステム企画構想やそれに伴う提案書、ノートPCを1つSEに渡して、自分は狩りに出かけました。 途方にくれるSE氏、ここから彼の約1万7千年(1万6666年)にも及ぶ、20万人月のシステム開発が始まるのでした。 約1万7千年前 |- 要件定義書を作成着手。 | 周りの人達は狩りをしながら生きている。 | 約1万6千年前 |- 要件定義書の作成が完了する。 | 基本設計に着手する。 | 土器を作り始める人が現れる | 徐々に日本列島が大陸から離れ列島になっていく。 | 約1万4100年前 |-
ソフトウェアの納期見積もりは、星占いレベルのものであると思う - メソッド屋のブログ
このエントリでは、ソフトウェアの見積もりがどういうものであるかをシェアした上で、今後日本はどのような方向に向かえばよいのでは？という私のアイデアをシェアしたいと思う。 注：このエントリは、某銀行の件とは全く関係ありません。考えるきっかけになっていますが、中の人がどんな状況だったかもわからないのに、勝手なことを想像して、人や企業を叩くのは私の趣味ではないからです。 ソフトウェアの見積もりの正確さ ソフトウェア見積もりのことを知りたければ、下記の本がお勧めだ。 books.rakuten.co.jp この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と16倍もあり、概算見積もりのレベルでも4倍の開きがある。画面帳票仕様を「確定」したレベルでやっと1.6倍程度の開きになる。 請負開発を実施するときに、
みずほ銀行次期システム関連のまとめ（2016/11/24 追記あり） - Akio's Log
(追記1：2016/7/11 7/7以降のブログ記事などを追加) (追記2：2016/11/24 延期発表の記事を追加) こんばんは。SE兼PM見習いです。 例のみずほ銀行の次期システム開発が話題になってますね。 blog.livedoor.jp blog.livedoor.jp 毎年この時期に、みずほ案件がグダグダだよね、という情報が出てくるのはもう恒例行事となってますが、開発工程終盤を迎えていよいよヤバイ状況が隠しきれなくなっているようです。 趣味が悪いと言われますが、デスマウォッチャーでして、特にこのみずほ銀行案件をウキウキとウォッチングしているのですが、ここでブックマークしている過去の情報を時系列に振り返ってまとめてみたいなと思います。 2002年〜合併時のシステム障害〜 次期システム案件の話に入る前に、みずほ銀行合併時の大規模システム障害に触れておく必要があります。 https:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
