この本の第4講では、みずほ銀行のシステム障害と、東証売買システムの障害が取り上げられている。システム開発に関わるものとしては、思い当たることばかりの話だった。
みずほ銀行の場合、当初はしごく真当な「新しいシステムを作る」という方針だったのが、合併する3行のシステムベンダが異なったことから、その3社で激しく競合することを避け、3つのシステムを合わせれば良いと考えたのが間違いだったと指摘する。
システムの移行や接続が、非常に難しい作業であることはシステム屋の常識だ。たとえば電子カルテのベンダを乗り換える場合は、昔のデータは参照しかできなくなるのが普通である。以前のシステムで発行した処方箋があっても、それを新システムにコピーすることはほぼ不可能になる。客観的な数値データのはずの検査データですら移行できないことがある。
畑村はトラブルの根本的原因は「付加設計」だという。付加設計とは、「条件などが変化して新たな要求が生じた際、設計全体を一から見直すのではなく、小出しに新たな機能を付け足していくことで対処する方法(151ページ)」をいう。付加設計の例として畑村は山の中の温泉旅館を例にあげる。増築に増築を重ねて、内部が迷路のようになっている旅館のことだ。大浴場から自室に帰り着くまでに大変な思いをする。火災の際は逃げ遅れること必至だ。
実は「付加設計」が必ず悪いわけではない。今流行りの「アジャイル開発」は付加設計の進化したものと言っても良いだろう。違いは、初めから拡張を前提に設計されているということだ。それこそ「デザインパターン」を導入し、プログラムの構造を整理しておけば、後からの機能追加もスムーズにできる。ただし、機能追加をするプログラマもデザインパターンを熟知した人間でないと、構造を壊してプログラムを台無しにしてしまうのは、『ゲーム プログラミング パターンズ』でナイストロムが指摘していたとおりだ。
まだまだ書きたいことはあるが、読み終わった本が溜まってきたので、この本について書くのはこれで最後としよう。面白い本だった。
みずほ銀行の場合、当初はしごく真当な「新しいシステムを作る」という方針だったのが、合併する3行のシステムベンダが異なったことから、その3社で激しく競合することを避け、3つのシステムを合わせれば良いと考えたのが間違いだったと指摘する。
この背景には、三行の主導権争いもあったようです。どこか一つの会社にシステムを担当させると、そこと取引がもともとある銀行が優位に見られるという程度のつまらない考えが働いたのでしょう。しかも、こうした判断を下したのは、システムエンジニアリングのことをまったく理解していない経営陣でした。裏を返せば、半ば素人だから「三つのシステムをうまくつなげれば、ちゃんと運用できる」というぬるい判断ができたという解釈もできます。(150ページ)
システムの移行や接続が、非常に難しい作業であることはシステム屋の常識だ。たとえば電子カルテのベンダを乗り換える場合は、昔のデータは参照しかできなくなるのが普通である。以前のシステムで発行した処方箋があっても、それを新システムにコピーすることはほぼ不可能になる。客観的な数値データのはずの検査データですら移行できないことがある。
畑村はトラブルの根本的原因は「付加設計」だという。付加設計とは、「条件などが変化して新たな要求が生じた際、設計全体を一から見直すのではなく、小出しに新たな機能を付け足していくことで対処する方法(151ページ)」をいう。付加設計の例として畑村は山の中の温泉旅館を例にあげる。増築に増築を重ねて、内部が迷路のようになっている旅館のことだ。大浴場から自室に帰り着くまでに大変な思いをする。火災の際は逃げ遅れること必至だ。
実は「付加設計」が必ず悪いわけではない。今流行りの「アジャイル開発」は付加設計の進化したものと言っても良いだろう。違いは、初めから拡張を前提に設計されているということだ。それこそ「デザインパターン」を導入し、プログラムの構造を整理しておけば、後からの機能追加もスムーズにできる。ただし、機能追加をするプログラマもデザインパターンを熟知した人間でないと、構造を壊してプログラムを台無しにしてしまうのは、『ゲーム プログラミング パターンズ』でナイストロムが指摘していたとおりだ。
まだまだ書きたいことはあるが、読み終わった本が溜まってきたので、この本について書くのはこれで最後としよう。面白い本だった。