イチから全部作ってみよう（7）正しい要求仕様書の第一歩となるヒアリングの手順：山浦恒央の“くみこみ”な話（176）（3/3 ページ）

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第7回は、要求仕様フェーズで作り上げる正しい要求仕様書に向けた第一歩となる「ヒアリング」について解説します。

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

5．ヒアリングをきっちりできないとどうなるか

　要求仕様定義で最も致命的なバグが、「自分が正しいと確信しているが、実は正しくない」というケースです。自分が正しいと信じているので、相手に問い合わせません。例えば、駅の話だと、「間もなく1番線に新橋行きの急行電車が参ります。危険ですので、黄色い点字ブロックの内側でお待ちください」というアナウンスを聞くと、常識のある乗客には「電車から離れないと危険だ」との思いがあります。この基本的な考えを鉄道会社側と共有しているので、黄色い点字ブロックから後ろに下がります。

　しかし、鉄道の安全運航の共通認識がない場合、誤解した乗客が「え、黄色い点字ブロックの『内側』にとどまらなきゃならないの？　幅が30cmしかない点字ブロックの『内側』に立つのって大変だよ」と考える可能性があり、危険な状況になりかねません。そういった状況に陥らないように、発注側と開発側が共通認識を構築する手段がヒアリングです。「なぜ、そんな機能が必要なのか？」を理解する基本がヒアリングなのです。

　ヒアリングは、発注側の要求を引き出す作業ですから、きっちりヒアリングしないと要求仕様書の品質に大きな影響を与えます（全作業関係しますが）。どのようなことか、下記の例題で考えてみましょう（一部実話）。

• 発注側：ワインは飲料であるため、夏場の配送は冷蔵便で配送してほしい
• 開発側：分かりました。夏場は、冷蔵便で対応します

　このやりとりは、ワインの配送を通常便と冷蔵便（冷やした状態で配送するか）のどちらで行うかを示したやりとりです。しかし、ここでは下記の詳細をヒアリングする必要がありました。

1. なぜ冷蔵便にするのか？
2. 夏場は具体的に何月から何月までを指すのか？
3. 地域による違いはあるのか？
4. 夏場に合わせて、ソフト側で冷蔵便設定にするか、手動で行うのか？
5. 冷蔵便以外にどのような配送方法を考えているのか？
6. ワイン以外の商品は存在するのか？

　このように話を深堀しておかないと、後々問題となる可能性があります。

• 実は、冬場は冷蔵便にしないことが分かった
• 実は、ワイン以外にも書籍を取り扱っており、冷蔵便にしない
• 実は、冷蔵便の設定は、店側が季節に合わせて自由に設定したい

　その結果、きっちりヒアリングしないことで、要求仕様書の曖昧、抜け、漏れにつながります。設計の初期段階にこれらを見つけられればよいでしょうが、筆者はこのような話が開発終了後のリリース直前に見つかることとなり、反省しました。

6．終わりに

　今回は、要求仕様フェーズの中のヒアリングに着目しました。ヒアリングは、発注側の夢と希望の詰まった要望を確認し、実現可能な要求にするフェーズです。この際、発注側の話を深堀し、合意をしておかないと、要求仕様の品質に影響を与え、後々慌てることになるので、注意しましょう。

　筆者の経験上、開発担当側から見ると、発注側はお客さまということから少し高圧的に見えるかもしれません。そんな時でも、「聞かぬは一生の恥」と考え、きっちりヒアリングすることをおススメします。

　要求仕様書がキチンと書ければ、ソフトウェア開発の半分が成功したと考えて構いません。人類史上、最大のコンピュータシステムであるみずほ銀行の「MINORI」の開発は、2004年から2019年までかかっています。16年間で、4500億円、35万人月を投入した巨大システムですね。開発の16年のうち、要求仕様の決定だけで7年もかかっています。要求仕様書がキチンとできれば、後は時間とコストを注入すれば、必ず正しいシステムが完成します。この「正しい要求仕様書」の第一歩となるのがヒアリングです。

　ヒアリングには、時間とコストがかかります。機能追加や応答性能向上のように、第2バージョン以降の開発であれば、致命的な誤解は発生しませんが、第1バージョンの場合で、しかも、自分が熟知していない分野のソフトウェア開発では、慎重になり過ぎることはありません。くれぐれも、「黄色い点字ブロックの内側」に立たないようにしましょう。

山浦先生執筆の書籍が販売中です！

　本連載で取り上げた「ソフトウェア技術者のためのバグ百科事典」を大幅に加筆、修正した山浦恒央先生の書籍「ソフトウェア技術者のためのバグ検出テキスト」が日科技連出版から好評発売中です。連載でも取り上げた、「要求仕様書のバグ」「実装抜けのバグ」「テスト業務のバグ」など、バグを36種類に分類して解説しています。囲碁や将棋であれば、「相掛かり」「矢倉」「四間飛車」「藤井システム」のような戦法を網羅した内容になっています。

　前著「ソフトウェア技術者のためのバグ検出ドリル」（2019年11月刊行）も好評発売中です。実際にバグを含む要求仕様書、設計書、コーディング、デバッグ、保守を具体的に取り上げ、練習問題として31問を出題しました。同書は、囲碁や将棋における「次の一手」的な問題であり、ピンポイントの場面を取り上げ、実践力を鍛えることを目的としています。

画像クリックで出版社のWebサイトへ

　両書とも興味のある方は、Amazon.comや書店でチェックしてください！

【 筆者紹介 】

山浦 恒央（やまうら つねお）

東海大学 大学院 組込み技術研究科 非常勤講師（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科准教授、2016年より非常勤講師。

主な著書・訳書は、「Advances in Computers」 （Academic Press社、共著）、「ピープルウエア 第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ 第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。