イチから全部作ってみよう（3）MINORIに学べ、全ての悪は要求仕様書から生まれる：山浦恒央の“くみこみ”な話（172）（2/4 ページ）

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第3回は、ソフトウェア開発における全ての悪を生み出す元凶、要求仕様フェーズの問題点を解説します。

[山浦恒央 東海大学 大学院 組込み技術研究科 非常勤講師（工学博士），MONOist]

3．顧客からのヒアリング

　本シリーズでは、ECサイトを例に、要求仕様、設計、コーディング、デバッグを実際に進めます。最初の要求仕様フェーズの目標は、顧客と協議し、顧客が求めるECサイトをヒアリングし、要求仕様書を作成することです。

　上記のように、要求仕様書とは、「カゴに商品を入れて、購入ボタンを押すと注文処理を行う」といった「ECサイトでできることの一覧」で、「こんなこともしたい」「これも盛り込んでほしい」という顧客の意見を聞きながら、ECサイトの機能を決めていきます。簡単な例を下記に示します。

• 顧客の要求例：会員のためのログイン機能をつけたい
• 要求仕様書：IDとパスワードを入力し、ログインボタンを押下すると、ログイン処理を行う

• 顧客の要求例：商品点数が多いため、検索する機能をつけたい
• 要求仕様書：検索キーワードを入力し、検索ボタンを押下すると、ヒットする商品を表示する

　これらは要求仕様の簡単な例です。顧客の求めるECサイトの要求事項を確認し、要求仕様書としてまとめます。要求仕様書は、開発業務の指針となるもので、これがないと開発担当は具体的な作業ができません。そのため、忙しい顧客にアポを取り、繰り返しヒアリングを行いながら要求仕様書を完成させる必要があるのですが、簡単には進みません。プロジェクトによっては、この要求仕様フェーズを乗り越えられずに開発中止となったり、進行困難となることも少なくありません。

4．みずほ銀行のシステム「MINORI」の大混乱

※写真はイメージです

　伝説の「OS/360」をご存じの方は多いと思います。これは、1960年代、IBMの世界制覇の原動力になったメインフレーム用のオペレーティングシステムで、仮想記憶を世界で初めて実装しました。20世紀における世界最大規模のソフトウェア開発プロジェクトがこのOS/360で、開発期間は5年にもおよびました。ピーク時には1000人超のエンジニアがアセンブラ言語と格闘。6万人月を要した大混乱の超大型プロジェクトで、人類史上、新規開発でこれを越える超大規模ソフトウェアはあり得ないと世界中の研究者やエンジニアが信じていました。そんな予想を裏切り、OS/360の6倍近くも大きいシステムになったのが、みずほ銀行の「MINORI」です。その開発は2004年に始まり、2019年7月に大混乱の中で完成しました。

　15年にわたり、OS/360の6倍近い35万人月を投入し（開発コストは4500億円）、ピーク時はプログラマーが年に8000人（OS/360では1000人）も従事しました。完成後も、何度もシステムダウンが発生し、そのたびに大きなニュースになったことは記憶に新しいと思います。果てしない大混乱の原因は明白で、「上層部がITに無知だったこと」に尽きます。

　大きな銀行の合併は、三菱銀行、東京銀行、UFJ銀行が合併した三菱東京UFJ銀行（現在は三菱UFJ銀行）、住友銀行とさくら銀行が合併した三井住友銀行などの例がありますが、システムの統合でトラブルは起きていません（みずほ銀行の大混乱を反面教師にしたためでもありますが）。これは、三菱東京UFJ銀行や三井住友銀行における合併の力関係が明らかであり、吸収される「子供」が「親」のシステムに合わせたためです。

　一方、みずほ銀行は、政府系銀行のトップである第一勧業銀行（当時のシステムは富士通が開発を担当）、民間系銀行トップの富士銀行（IBMが担当）、企業系銀行トップの興銀（日立が担当）の3行が合併したメガバンクです。官業民3つの部門のトップ銀行が合併したため、互いに譲らず、政治的な駆け引きや思惑が渦巻き、そのしわ寄せが銀行システムに集結しました。みずほ銀行は、パンドラの箱を開けたのです。

　みずほ銀行のシステム統合は、フレンチの有名三ツ星シェフ、中華の国民的料理人、和食のカリスマ調理師の3人が、スープから始まり、前菜、魚料理、肉料理、デザートで終わる1つのコース料理を作るようなものでした。どれか1つの料理に統一すればよかったのですが、結局、3つの特徴を残すことになりました。客は、中華風でフレンチ風味の刺身、中華風で和のテイストのエスカルゴ、和風でフレンチの風味のあるマーボー豆腐……と、奇妙奇天烈な料理を食わされるようなものです。MINORIでは、この複雑怪奇な要求仕様書を作るのに7年もかかっただけでなく、今でも、複雑怪奇な仕様書由来のバグに悩まされ、「高いツケ」を払っているのです。

　全ての原因は、要求仕様書にあります。その後の設計やコーディングでいくら頑張っても、基本思想が正しくないと、きちんとしたシステムはできません。アメリカで言う「Garbage in, garbage out（ごみを入れたら、ごみが出てくる）」です。正しく要求仕様書を作る重要性を認識していただければ幸いです。