エスクローファイナンス ブログ

みずほ証券が世間を賑わしています。
インターネット取引ができないという不具合のようで、原因はネットワークの「人為的な設定ミス」が原因とのこと。
ここでいうネットワークの設定ミスというのが、OSの設定なのか、ルーティングの問題なのか、はたまたプログラム上でのバグなのかわかりませんが、今回は大手企業が行うIT開発現場がどういったものなのかを簡単に書いていきます。

ソフトウェア開発はゼネコン構造

ソフトウェア開発の現場はマンション建設の現場とよく似ています。
発注主がいて、それを受注する元請け(一次請け)がいて、元請けから発注される二次請けがいて、二次請けから発注される三次請けがいて、三次請けから発注される四次請けがいて………………。

まさにゼネコンのそれと一緒ですね。
プログラマーやシステムエンジニア(SE)はIT土方と揶揄されることがありますが、このワードは不動産、建設業界の開発現場と似ていることからきています。

このピラミッド型の開発業態はいかにも昭和的で古く、時代のニーズから逆行していることから個人的にはほんとイケてないやり方だなーと思っています。

プログラマーやSEの質低下を招いている原因にもなりますし、今回のみずほ証券の問題のように担当者が内部構造を理解できていないために復旧までに時間がかかってしまったりしますしね。

開発モデルが大きく4つ

一概にシステム、ソフトウェアと言っても様々な種類(社内システム、決済システム、HP、ゲーム等)があり、開発するシステムによって、開発手法を適正に分けていく必要があります。
ソフトウェア開発のモデルは大きく4種類の手法があります。

・ウォーターフォール型
・アジャイル型
・プロトタイプ型
・スパイラル型

金融機関の決済システムや、大企業の社内システムなどはウォーターフォール型を採用するのが一般的。
ウォーターフォール型はまさにゼネコン構造を絵に描いたようなモデル。
ウォーターフォール型は、各工程別に分けてWBSを組み立てるため、前の工程を飛び越して先に進むことができないことからデスマになりやすいですが、それでも日本では今でも一番メジャーな開発モデルです。

要件定義から実装まで

開発は要件定義から始まりテストで完結し納品します。大まかな流れは下記の通り。

・要件定義→基本設計→機能設計(プログラム設計)→実装→テスト→納品　※現場によって外部設計や内部設計等呼び方や名称が違います。

①要件定義：発注者がどんなシステムを作りたいのか、どんな機能をつけるのかヒアリングする期間
②基本設計→要件定義で抽出した顧客ニーズを実現するために、システム全体の設計を行う
③機能設計→基本設計の内容を具体的なプログラムに落としていく工程。各メソッドの呼び出し、パラメータなどを記載することもある。
④実装→実際にプログラムを組み立てていく。
⑤テスト→設計書通りにシステムができているかを検証する。外部に依頼することが多いが、実装者本人が担当することもある。テスト工程の最終段階は発注者の社員複数名が実際にシステムを操作する。

要件定義から機能設計までは割と時間的にも余裕があり、現場もまったりしていることが多い。
一番の佳境は実装工程からテスト工程の間。
この期間は徹夜をすることもままでてきます。

元請けがシステムを理解していないことが多い

元請けは発注者とのやりとりがメインとなっているため、システム内部のことを理解している者は少なかったりするのが実情です。

開発期間中は下請けのSEが仕様を理解しているため、元請けのSEが理解していなくてもなんとかなる場合があるのが実情ではありますが、今回のみずほ証券の問題のように元請けの担当者が内部構造を理解していないと一挙手一投足が遅れ、簡単なバグすら直すのに時間がかかるケースがあります。
※バグの内容によってどこのクラスでどんな問題が発生しているのかはおおよそ予測がつきます。
今回のネットワーク障害の問題も実装者や設計者は原因の特定自体は一瞬だったと思います。時間がかかったのは、対象のバグを修正すると別の機能でエラーがでてしまうことや、テスト後の影響調査、及び解析に時間がかかったものと推測します。

まとめ

システム開発において、最も重要な工程はテストです。
テストをおろそかにすると本番環境で予期せぬ障害を生み出しかねず、更にそれが決済等お金に関わる機能で発生したら尚のこと大変です。

今回のみずほ証券の問題は、「人為的な設定ミス」が原因とのこと。
本番環境にあげる前にテスト環境で正常に稼働するかを確認した上で、本番環境に反映するのが普通ですが、その工程を怠ってしまったんですかね。
真相は謎ですが、今回の障害対応に結構な数のエンジニアが派遣されたと思います。おそらく徹夜で障害対応をしていたんだと。
もう少しプログラマーやシステムエンジニアを大切に扱う環境づくりをしていってほしいですね。