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

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

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

5．要求仕様フェーズを進める際の問題点

　ここからは、要求仕様フェーズを進める時の障害となる問題点を整理します。

5.1 要求仕様書が正しいか判断できない

　クライアントと開発担当は、異なる業務領域を持っているため、お互い無関心です。その結果、お互いの業務領域に関して正しい要求仕様となっているか判断できませんし、興味もありません。両者の言い分を下記にまとめます。

クライアント側の考え

　われわれは、ワインの商品企画／販売の専門家であり、ソフトウェアの開発会社ではない。よって、商品企画／販売や運用を中心に考え、実開発は開発担当に任せたい。

開発担当の考え

　われわれは、ソフトウェア開発を主とする会社であり、ワインの知見がない。よって、クライアントが求める製品を忠実に作成したい

　整理すると、開発業務を丸投げしたいクライアントと、要求通りにソフトを作成しようとする開発担当の考えに違いがありますね。つまり、互いに両者の領域に関心がなく、要求仕様書が正しいかを判断できない可能性があります。

5.2 本当に欲しいものが分からない

　クライアントにとって、「自分達の本当にほしいECサイト」を考えることは、想像以上に困難です。例えば、「どうすれば自社の商品を買ってくれるか」「本当に売り上げが上がるのか」「他社とどのように差別化していくか」などを考え出すと、欲しいものがどんどん分からなくなってきます。この場合、要求が二転三転して開発が難航します。注文住宅を建てる場合も同様で、自分が本当はどんな家が欲しいか分からず、毎回、変更しては設計士を困らせる場合が少なくないそうです。

　みずほ銀行の場合、1つの銀行に絞らず、3行の業務フローをそのまま残したことが大混乱の原因となりました。

5.3 組織の力学が働き、仕様が決まらない

　学生からよく、「要求仕様なんて誰かが強引に決めればいいのでは」とのコメントを聞きます。確かにその通りで、権限がある誰かが一方的に「鶴の一声」として決定した方が早いことも少なくありません。しかし、組織で物事を進めることは簡単ではありません。

　会社組織には、平社員、係長、課長、部長、社長のような役職や、他社との縦の関係性、関係会社、法律やコンプライアンスなどの横の関係性などのさまざまな力学が働きます。例えば、「取引先との関係上、使いにくいサービスと連携する必要がある」「相手の部長のご意向と異なるため仕様修正となる」「法律上、この仕様では難しい」などさまざまな障害によって仕様が決まらなくなります。組織の力学や政治学が最悪の方向に働いたのが、みずほ銀行のシステムです。

5.4 要求仕様に間違いがある

　簡単な仕様でも、正しく、抜けや漏れがなく書くことは、簡単ではありません。仕様書を注意深く読むと間違いがたくさん潜んでいます。

　例えば、街で見かける「駐車場の料金表」は、抜け、漏れ、エラーだらけで、これまで、バグのない料金表を見たことがありません。大学のソフトウェア工学系の授業では、「自分の住居の近くの料金表の写真を撮影し、その中のバグを指摘せよ」との課題を出しています。

　例えば、以下のようなバグがあります（図2〜4）。

図2　駐車場の料金表とバグ（その1）

図3　駐車場の料金表とバグ（その2）

図4　駐車場の料金表とバグ（その3）