今年のみずほ銀行の大騒ぎは、 当事者はともかく、 傍目から見ていると面白い現象だった。 特に面白かったのは、 代表者の記者会見で、 「社会的には影響は出ていないだろう」みたいなことを言っていた。 確かに、騒いだ割には、 あれで会社が潰れたとかいう話は聞いたことがない。 もちろん、責任は銀行側にあるのだから、 被害は全部みずほ銀行が被る仕組みになっていないとおかしい。

※ システム統合後にトラブルが続出した。

トラブルの責任は誰にあるのだろう。 例えば、システム担当者は何をしていたのか?　 ソフトウェアに関しては同業者だから雰囲気は何となく分かる。 3月末の時点で、トラブルは予測できていたという説がある。 業界的には当たり前の話だ。 4月1日に稼動させてあれだけのトラブルになるのであれば、 かなり前から予測できていたはずである。 ということは、 爆弾を抱えたシステムを稼動させるというギャンブルを行った人が問題だ、 ということになる。

※ 稀には、本番稼動前日に致命的なバグが発見された、 みたいなこともない訳ではないが。

トップがトラブルを甘く想定すれば、 多少のトラブル発生よりも、 予定通りに4月1日から稼動させることを優先させようとする可能性はある。 それも一つの選択肢だとは思うが、 だったら、影響が出る見込みがある顧客に対して、 事前に説明があって当然だと思うのだ。 例えば、 今回は公共料金の引き落とし処理が大幅に遅れるというトラブルが発生した。 かなり重大なトラブルのように見えるかもしれないが、 こんなことは事前に分かっていれば騒ぎになるような問題ではないのだ。 実際、 あらかじめ見込みの金額を振り込み、後で清算するという案が出たようだが、 毎回の入金額が割と決まっているのだから、そういった回避手段もあるわけである。 それをトラブル前に提案しておくというのが通常のリスク対策なのである。

この異常事態の根本的な原因は、 やはり、大銀行という驕りがどこかにあったのではないかと思う。 多少トラブルがあっても、業界トップの当行は選んでもらえるだろう、 という甘い見込みで動いてしまったのではないだろうか。 銀行が淘汰されつつあるといっても、まだまだ選択肢はたくさんあるのだ。 気が付いた時には世界が終わっているものだ。 どうしても未来を予想したいのなら、 フェイルセーフとなるように、 最悪のシナリオ側にバイアスをかけて想像した方がいい。 ソフトウェア技術者的には、ある意味常識のはずだ。

§

Bフレッツが使えるようになったので速度測定サイトで調べてみると、 上り下りとも約15Mbps程度出ていることが分かった。 今まで64kbpsだったから、200倍以上速くなったことになる。 流石にこれだけ違うと違うものを使っているような気がする。

※ それまでは ISDN だった。

Bフレッツのサービスプロバイダに@niftyを選んだら、 3月30日から使い始めたため、きっちり2日分で7,000円の請求が来た。 3月1日から使っても、3月30日から使っても、3月の請求分は7,000円になる。 こういうことをしているプロバイダは、そう長くは持たないと思う。 アコギな商売だというのではない。 単に日割りで計算する程度のシステムが未だに構築できないようでは、 IT業界の厳しい競争に勝ち残れないと言っているのである。 時間計算してもいい位だ。 実際、@niftyを選んだのは、あまり深い意味はない。 単にそこしかなかったのだ。 他に日割りで課金するプロバイダがあったら、そちらを選択していただろう。

※ よくある対策として、 当月は無料、翌月から、というやり方もある。 それなら利用者としては損していないような気分になれるかもしれない。 私見としては、利用開始から1か月無料、の方がずっと魅力的なのだが。

だったら4月1日まで待てばいいだろ、というご意見はもっともである。 20日からならともかく、30日からわざわざサービスを開始させなくても…、 というのも理屈だ。 実は、あえて30日から使い始めたのには深い理由がある。 つまり、皆さんが既に想像されている通り。 こういう原稿のネタになるかなと期待したのである。 実際、なったし。

§

C Magazine の Web サイトには、 インターネットから質問を投稿できるコーナーがある。 ここに4月頃、 「自動販売機のシミュレーションプログラムを作れ」といわれたがどうすればいいか、 という感じの質問が出ていた。 この質問への回答は実際にWebを見てもらうのが早い。 この問題は、会社の研修で出てきたという想定になっている。 つまり、新人プログラマー(?)に対する質問なのだろう。 となると、まず気になるのは、 研修担当者が一体どのような意図でこの問題を出したかということだ。

もしこれが学校の「プログラミング言語」の授業なら、 今まで授業で出てきたことをとにかく元にして、コーディングすればいいだけだ。 しかし、実際に質問文を見てもらうと分かるが、 現場でこんなに曖昧な要求仕様が与えられることはまずないのだ。 もし、プログラマーに対して 「自動販売機のシミュレーションプログラムを作れ」 というような仕事が来たら、 極端な話、 「こんな曖昧な仕様でプログラムを作れるか!」と突っ返してもいいのである。

が、新人研修の場で「突っ返す」が正解なんてこともあり得ない。 ということは、 やはりここは要求仕様書から作成することが期待されていると考えるべきであろう。 言い換えれば、仕様を記述するスキルが問われているのでは、 という結論に到達するのである。 一昔前ならフローチャートか構造化チャート、 今ならUMLで記述しろということか。 最近はUMLからJava等の言語に変換するツールもあるから、 本格的にUMLで記述できれば、実質的にコーディングまで済ませたようなものだし。

※ 要求分析である。 今だと、 ビジネスモデリング系の本が多数あるから、 そういうのを読めば分かるだろう。

いずれにしても、 ここで最も重要なのは、要求仕様を正確に理解しているか、 ということになる。 プログラムの動作が不安定になる原因の一つは、 要求仕様が絞りきれていなかった、というものだ。 もちろん、eXtreme Programming のように、 開発しながらフィードバックをかけて、 実際の要求に合ったプログラムを完成させるという手法もあるのだが、 それにしてもある程度の仕様はきっちり想定しておいた方がいい。 必要なら、仕様自体を修正すればいいのだから。

§

あるいは、もう一歩外側で考えて、 ユースケースで利用者レベルの要求仕様を記述することとか、 そのあたりの作業が求められているのかもしれない。

※ Writing Effective Use Cases、 ユースケース実践ガイド、 アリスター・コーバーン著、 ウルシステムズ株式会社　監訳、 翔泳社　発行
ISBN4-7981-0127-3

ユースケースというのは、ざっくばらんに言えば、 利用者とシステムの関連をシナリオとして書く手法である。 例えば、自動販売機をイメージして簡単な成功シナリオを書いてみると、 List 1 みたいな感じか。

---- List 1 (自動販売機の成功シナリオ) ----

 1. 利用者がお金を入れる。
 2. 自動販売機は金額情報を更新する。
 3. 利用者が購入ボタンを押す。
 4. 自動販売機は商品を出す。

---- List 1 end ----

非常に簡単でしょ。 もちろん、実際はこんな簡単な処理だけで自動販売機は完成しない。 例外の記述も必要になる。 それは後から拡張する、というのがユースケースっぽい考え方だ。 例えば、List 2。

 ---- List 2 (拡張) ---

 3a. 利用者が購入ボタンを押すが、お金が足りない。
  3a1. 自動販売機は何もしない。
 3b. 利用者が返金レバーを押す。
  3b1. 自動販売機は投入金額分のお金を出す。

 ---- List 2 end ----

この時点でどの程度失敗する場合をイメージできるかがポイントになる。 漏れがあってもダメだし、細かすぎてもいけない。 他にも、主アクターとか、事前条件とか、 ユースケースには他にも記述すべき項目があるので、 それは参考書籍を見てもらいたい。

ソフトウェアにあれもこれもと機能追加しているうちに、 何を作りたかったのか分からなくなることがあるが、 ユースケースとしてドキュメントを残しておけば、 混乱を避けることができる。 ユースケース、とりあえずトレンドになりそうだ。

§

ところで、ちょっと気になったのが、 質問に出てくる自動販売機の仕様である。 「商品がなければお金を返却するかお金を足すか別の商品にするか問い合わせる」 というのだ。これはおかしい。

自動販売機というのは、 ユーザーインターフェースの実装例としてしばしば評価されてきた。 ただ、長年研究されている割には、 不思議なことに、タコな仕様の自動販売機が後を絶たないのだが… それはさておき、だいたい、 商品がない状態でお金を入れさせるというのが論外である。 商品がなければ、 当然、お金を入れる前にそのことをユーザーに知らせるべきだし、 大抵の自動販売機はそうなっている。 お金を入れてから「売り切れ」ランプが点灯するという自販機はあまりないだろう。

もっとも、 オンラインショッピングのような場合だと、 実際にお金を入れて注文する瞬間まで在庫が確認できない状況も考えられるから、 そこまで一般化した状況を想定したのかもしれないが。

とりあえず、 新人研修でこんな問題が出たら、 途方に暮れるというのはある意味正しい。 プログラムにできないのは当然で、 それ以前の要求仕様書のレベルに落とすだけでも至難の技だろう。 そうは言っても、 実際の現場でこのような要求がくるというのも事実である。 一般的に、お客様というのは仕様設計とかUMLとは縁がない世界に住んでいるので、 最初から論理的な要求仕様そのものが存在しなかったりするのだ。 単に「オンラインショップを始めたいのですが」 程度の話から仕事が始まるなんてのは、あまりにありふれた話だ。 そんな曖昧な仕様では実現できません、という訳にはいかない。 この場合は、曖昧なニーズから明確な仕様を作成するという、 プログラミングとはやや別の種類の能力が必要になるのである。 もしかすると、この問題を出題した人は、そこを要求したのかもしれない。

ソフトウェア技術者的仕様設計のコツは簡単で、 成功手順の他に、とりあえず最悪の失敗シナリオを考えてみるのだ。 それを相手に見せる必要はないかもしれないが、 「逃げる」でも構わないから、とにかく予期しておくことが重要だと思う。