『みずほ銀行システム統合、苦闘の19年史』を読んだ。
銀行とか社会のインフラとして重要で、昔から動いているシステムは規模もそうだろうし内容も複雑だったり古かったり大変だろうなぁと思いつつ読んだ。
規模も内容も違うとはいえ基本として学ばせてもらえるところもあると思う。
人月という単位がなんか自分の理解を超えた別物に見えてくる。
こういう難しい開発があるからこそ、そこまで難しくない開発案件での対処方法などにいかされていくところもあるんだろうなぁ。
みずほＦＧの経営トップは勘定系システムの刷新を現場任せにして、情報システムのことを理解せず、必要な資金や人員を投入する決断ができなかった。情報システムの開発に際して業務部門が情報システム部門に全面的に協力したり、関係各所の利害を調整したりできるようリーダーシップを発揮することも怠った。経営陣のＩＴ軽視、ＩＴ理解不足が、大規模システム障害の根本的な
丸投げの結果、、、という感じか。
要件定義周りの話とか
難関だったのが要件定義だ。みずほＦＧはユーザー部門主体で要件定義をやり直した。その際は旧システムの要件や現状の業務フローを踏襲する「ＡＳ ＩＳ（アズイズ）」の要件定義を全面的に禁じた。 「過去の苦い経験から、要件定義においてユーザー部門が『今のままで良い』『アズイズでよろしく頼む』との態度をとるのが最悪だと学んだ」。
どういったものが必要か？をどう決めるのか？という話。
そもそも何が必要？？みたいなのがはっきりしていないとかはありそうだし、リニューアル的なものは現状維持みたいな曖昧な言葉でごまかされることはあるわなぁ、、、
現状維持というより現状の詳細を知らないから見た目上現状維持、みたいなところか。
しかし計画を立てたのは本格的な要件定義に入る前のタイミングだ。あくまで段取りとしての計画であり、工程ごとの期間は他の大規模プロジェクトを参考に決めていた。実際に要件定義を終えて改めてスケジュールを精査した結果、設計工程やテスト工程を長く見積もる必要が出て
んじゃ必要なものが見えてきたということで改めて考えてみると・・・？という話。
要件定義をしたり仕様をつめていって見えてくるものがあるとは思うのだけど、要件的なものが出揃っていなかったり、後に続くものがはっきりしていない中での計画・見積はやっぱり予測でしかないわけで、それが確定事項として考えてしまうのは自分からリスクを産んでるとしか思えないんだけど、そういう進め方を発注側がしたりするのはどういうことなんだろうな。
九回の移行に一年をかけたのは、重要な移行作業に三連休を充てたためだ。三連休初日が移行作業の本番で、二日目の午後までに「移行対策統括本部会議」を開き、切り替え中止（フォールバック）をするか判断した。同会議までに作業が予定通り進捗していなければ移行作業を中断し、既存システムへの切り戻し作業に入るわけだ。三連休なら三日目は予備日に充てられる。「移行には想定外のことが起こり得る。必要な予備期間だった」
どんなに準備をしてもうまくいかないことを想定しておく、くらいじゃないといけないよなぁ。
銀行とか重要なシステムだからこその検討フローとか。
こんなところにも、上限値の設定があったのか──。システム担当者たちは驚きを隠せなかった。情報システムの運用拠点で作業に当たっていたシステム担当者は、一括処理にも上限値が存在することを知らなかっ
この規模だと予算が〜とかはないかもしれないが（多重下請けだからそういうところもあったのかもだけど）、予算が少なくなればなるほど事前テスト的なところからコストが削られる訳で、そうなればやってみたときにうまくいかなくなることが発生するリスクは高くなる。
みずほ銀行は、異常時のシナリオを自動運行システムに組み込んでおかなかったどころか、紙の運用マニュアルとしても用意していなかった。そのためシステム担当者たちは、まずどの処理を進めて、それが終わったら次にどの処理を実行して、という具合に、異常時のシナリオをその場で考え組み立てながら作業する羽目になった。
本来、シナリオを考える作業は、じっくり時間をかけてこなすものである。シナリオを組んだ後は、その内容に誤りがないかどうか、何度もテストをこなす。システム障害の最中に、誤りが一つもないシナリオを考え、その内容に沿ってシステム担当者がミス一つなく実行命令を入力するのは、どう考えても
なので、せめて予備をちゃんととるなり、うまくいかなくなる想定だけでも意識しておくとか。
手作業でミスなしは無理だろうな、さすがに。
銀行のシステム担当者が、異常時に使える運用マニュアルを用意していなかったのは、システム部門の責任である。だが、現場のシステム担当者に無理を強いたみずほ銀行の経営陣の責任は、それ以上に重い。システム部門は、経営陣から命じられたら、最善を尽くそうと考え、前進してしまう。運用マニュアルを用意していなかったという非があるだけに、なおさらだ。システム障害の全面復旧に向けて張り切るシステム部門に「待った」をかけて、銀行全体にとって最適な判断を下すのが、経営陣の責務である。
受発注の関係でも似たようなところだろうけど、発注者が上で受注者が下だとどうしてもそういう関係になってしまうだろうから、双方対等で話ができるなり、上（発注者側）もそういう判断を下す必要があるってところだろうなぁ。
最初の話じゃないが現場（受注者）に丸投げだとダメだよね、といったところか。
今の時点で、過去のシステムが古いという話ではあるけど。
そういう話は今作ったシステムもいずれは古くなるだろうし、今だったらそういうことしないよねー、というのを直していったのがこの移行の話だった訳だから、今見えていない問題がこれからまた色々出てくるんだろうなぁと。
あとで言えることはいくらでもあるし。
開発要素がないプロジェクトだとそこまで問題にはならないかもしれないが、開発の規模が小さいとしても、全体の工程だったり、各工程で考えることだったりってのは大体似てるところはある訳で。
検討し始めたら見えてきたこと。設計し始めたら、実装し始めたら、というのがあって出てくることはあるんだろうから、そういうときに柔軟に対応できるようにするとか。
途中途中の内容を絶対のものとしてしまうと後戻りできなくなるだけなので、そうならないようにってかんじだろうなぁ。
中の人というよりはニュースがベースみたいな感じなところはあるけど。
細かい失敗の話はそこまで具体的じゃないとはいえ、成功事例ではなく、うまくいかなかった事例の概要なりを知ることができたというのがありがたい。
プロジェクトに関わった方々おつかれさまでした。