みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」

  • 日経BP
3.00
  • (0)
  • (3)
  • (5)
  • (1)
  • (1)
本棚登録 : 308
レビュー : 6
  • Amazon.co.jp ・本 (256ページ)
  • / ISBN・EAN: 9784296105359

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • IT界隈では有名なみずほ銀行システム統合について書かれた本。経営層がITを理解する重要性や要件定義の大切さが実例を通して示されており、結果論ではあるもののシステム障害対応の考察もあるので、学べる点は多いです。一方で、上手く纏まりすぎているので、失敗事例から学びたい人にとっては物足りないかもしれません。多くの人が知りたいリアル感ある混沌とした状況までは書かれていませんでした。

  • エンジニアリングをする際の、そしてレガシーと向き合う際の組織アンチパターン。
    2011年、2002年の障害に関しては組織構造や社内政治の混沌が生み出す不協和音について掘り下げられており、小規模ながらそこかしこでも見られるような課題が山盛りだ。
    対岸の火事ではなく、明日のみずほになるかもしれないという危機感を持つことができる。

    一方で2019年に完成した新システムについては、工程の膨らみや開発途上で発生した課題に対しての掘り下げが浅いのではないか。
    なぜ大規模リプレイスを経てもCOBOLが残存しているのか、ここでは肯定されているコード自動生成ツールに課題はないのか(入力する数式のメンテナンス性はどうなのか、など)、ソフトウェアエンジニアが感じる疑問への回答はなく少し肩透かしを食らった気分だ。

    しかし、19年にも及んだ大規模な案件に踏み込み、これからのシステム開発でニの轍を踏まないようにと本書をまとめた意義は大きい。

  • とにかく完成しないことで「IT業界のサクラダファミリア」と揶揄されたみずほの勘定系システムMINORIがいかにして開発されたのかをまとめた本です

    東日本大震災の義援金振り込みによる大障害までのみずほ銀行のシステム開発の方針は笑ってしまうほどお粗末でしたが、意外とそれ以降本腰を入れた後のプロジェクトマネジメントは二回の遅延はあったとは言えお見事でした

    ・ベンダー間であるべきシステムを議論させる
    ・コード自動生成ツールによる品質均一化
    ・現在のシステムの要件定義をしない
    ・業務フロー図を現場のユーザーに書かせて、あるべき業務を明確化する
    など、この実行力があるなら最初からやれば良かったのに、と思いました

    基本システムの話というよりは政治と歴史の話でしたが、読み物として面白かったです

  • 話題になっていたのもあり手にとった。

    圧倒的な規模のプロジェクト。こんだけ大規模のマネジメントを複雑な組織の中でやるのは本当に大変だっただろうなぁと頭が下がるになった。

    トップコミットメントと方式設計や仕組みの標準化、漏れをなくすためのコミュニケーション設計が重要だったんだと理解した。

  • 「みずほ銀行のATMの下には数多のITエンジニアの死体が埋まってゐる!」と梶井基次郎がかつて書いたか書かなかったかは不明だが、本書はそうしたエンジニア達へのレクイエムとして、日経コンピュータが長年のみずほ銀行のシステム開発の取材をまとめた一冊である。

    メインは2019年7月にようやく完了したみずほ銀行・みずほコーポレート銀行・みずほ信託銀行ら3行のシステム統合のプロジェクトマネジメントでの詳細である。4,000億円という開発費、そしてそれを稼働のタイミングで減損処理し、以降のPLへの減価償却費のヒットを避ける、というあまり例の見られない会計処理がなされた点でも異例と言える本プロジェクトについての実態が知れる点では、非常に面白い。

    ただし、残念なのは統合プロジェクトがテーマなのは本書の1/3程度で、残りは過去2回(2002年のみずほ銀行統合直後、2011年の東日本大震災の義援金受付に端を発するシステム障害)の既出記事のエディットが残りを占める点。もう少し、統合プロジェクトに関する記事が多いと読み応えがあるのだけど。

  • 期待したものとは違った。ベトナム戦争の地獄のレポを期待して読んだら、我ら米軍はいかに勇敢に試練に立ち向かったかみたいなくっそどうでもいい話が延々と書いてある。

全6件中 1 - 6件を表示

日経コンピュータの作品

みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」を本棚に登録しているひと

ツイートする