はじめに
IT界のサグラダファミリアとして有名なみずほのシステムについて書かれた本です。
基幹系刷新案件が増えてきているので、身を守るために読んでみました。
技術的には浅い話ですが、PJの成功・失敗事例としては教科書に載せるネタかと思いますので興味がある方は読んでみると良いです。
お題
- ポイント
- 開発手法の考察
- 障害の考察(2011)
- 障害の考察(1999)
- まとめ
- 過去のPJ経験から補足
概要
- 1980年代から使用されている勘定システムの老朽化
- 法改正やサービス追加でブラックボックス化
- 経営体制ネックでシステム開発に投資できていない
- 勘定系のメイン業務であるリテール業務（預金）は利益が下がり投資意欲が低い
- 2度の規模システム障害とPJ延伸を経て完成
- 4000億を超える投資、35万人月の動員、参加ベンダー、スカイツリー７本分の費用
- ファイルベースのバッチおばけをオンライン化
- SOAで面作り直した
- シナリオ制御系でメインフレームとCOBOLが残ってるが大半はオープン化
開発手法の考察
- As Isの要件定義を全面禁止
- ユーザ部門に 業務フローやデータモデルを考えさせる（Xupper使用）
- 用語の統一（ユビキタス言語）
- コードの自動生成により属人性を排除（超高速開発ツール）
- 主要４ベンダーとNDA締結しアーキテクチャや実装方針を検討
- 開発１６社でトップマネジメント定例
- 仕様変更・改善要望などは１件ずつコスト・期間・インパクトを判断して可否を決定
- 横断PTを作り事業部同士が対立した場合は横断PTが軍配を持った
- 横断PTの傘下にテスト部会を配置してテスト計画を作成
- 四重のリスクチェック
- 第1線 ステム開発エンジニア
- 第1.5線 プログラムの品質チェック
- 第2線 システムリスク管理室 システム視点
- 第3線 業務監査部 業務視点
- プレユーザ受け入れテストの工程を追加、テスト工数が見積もりより肥大化
- システム移行の期間は１年間、ATM停止９回、移行は３連休を使用
障害の考察(2011)
- 三十の不手際
- システムの仕様や設定
- システム運用
- リスク管理
- 緊急体制
- 根本原因・・・経営陣のIT軽視、IT理解不足
障害の考察(1999)
- 根本原因・・・現場任せが諸悪の根源。CIO不在。３行がバラバラに対応
- ベンダーの覇権争い。できるはずのない工数を提示。
まとめ
- 他人事ではない。2025年の崖が待っている。
- 2025には20年以上稼働し続けている基幹系システムの比率が6割
- システムの老朽化によるリスクに伴う経済損失12兆
- 困難を乗り越えた結果人が育った
- ステークホルダーを集めて横断チームを作ることが必要
- 利害の対立があるなかで経営層がリーダーシップを発揮して横断チームに決定権を委譲しないと破綻する
- 要件定義で「As IsはNG」ユーザ部門に業務フローやデータフローを作らせる
- 移行や検証に莫大な工数がかかる。
- 一括処理は高リスク。オンライン化推奨
- サービス化して疎結合にしよう
過去の経験から補足
- 業務フローをエンジニアに任せてはいけない
- フロー作成の主体・責任はユーザ部門
- ユーザ部門も自らの業務フローを理解していないので絶対完成しない
- テストの工程でイレギュラーなケースが露呈する
- 業務の仕組みを根本的に見直すビジネス・プロセス・リエンジニアリングが目的にないといけない
- 要件も見えないのに○○人月でやれますとか時代錯誤な提案をしてはいけない
- 莫大な工数がかかることを自覚し、ビジネス面でどうペイするのか経営判断が必要
- 検証や移行の工程が逼迫するとリリース後爆発してコストや期間が余計にかかる
- 会議のための会議、報告のための報告は無駄
- 進捗会議は無駄。リカバリ案とか無駄。遅延している場合課題が発生しているのでステークホルダーが集まって課題を解消していく方に注力したほうがいい。進捗は健康チェックに使う