イチから全部作ってみよう（5）難題だらけの要求仕様フェーズにどう対処すべきか：山浦恒央の“くみこみ”な話（174）（2/2 ページ）

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第5回は、さまざまな問題がある要求仕様フェーズの対処法について解説します。

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

2.2 要求仕様書のレビュー

　要求仕様書の抜け／漏れ、記述ミス、誤解を防止するため、開発者やクライアントも含めて、レビュー（チェック作業）を実施します。期末テストで、答えが正しいかを見直すのと同じ考え方ですし、作業自体、よく似ています。時間がかかるし非常に原始的なチェック方法ですが、効果は絶大です。

　要求仕様書のレビューで見つけられなかったバグや抜けは、そのまま、設計書に潜り込み、ソースコードとなって、市場にリリースされてしまいます。かくして、利用者やクライアントから、「この機能が動かないんですが……」とクレームが入り、莫大（ばくだい）な時間とコストをかけて、製品の回収、プログラムの入れ替え、再配布をすることになります。仕様書のレビューで問題が見つかればその修正コストは100円以下で済みますが、マーケットにリリースした後ではバグ修正1件に数千万円かかることも珍しくありません。

　要求仕様書は、完璧と思っても、問題点だらけです。「駐車場の料金表のバグ」の例を見れば、「仕様にはバグが満載」であることが分かるはずです。皆さんも、完璧と思ったにもかかわらず、チェックを依頼すると、ボロボロだったというケースを経験したことがあるでしょう。例えば、「今回は期末テストで100点だな」と思っていると、凡ミスが何個も見つかって落胆することも少なくありませんね。

　要求仕様書（実際には、設計書、コーディング、テスト項目など、全ての成果物）も、確実にレビューを実施します。さらに、レビューで受けた指摘事項をまとめて「レビュー記録表」を作成し、指摘事項が正しく修正できたか、実際に修正済みかを確認します（表2）。

No.	指摘箇所	指摘項目	Open／Close
1	10ページ	ワインは食品なので、配送方法は冷蔵便としてください。	Close
2	15ページ	記述が分かりにくいので修正してください。	Open
3	129ページ	在庫がない場合のエラーケースが考慮されていないので、修正してください。	Open
表2　レビュー記録例

　表2は、レビュー記録表です。「指摘箇所にドキュメントのページ番号」「指摘項目に指摘事項」を記入し、チェックした記録を作成します。

　要求仕様のレビュー時にどこを見るかは、人それぞれでしょうが、特に筆者が気にするのが下記の点です。

• 最大構成を考えているか？　例えば、同時に何人までアクセスできるか、顧客のデータの最大容量を考慮しているか？
• 応答性能がどれくらいか？　現実性があるか？
• 稼働時間はどれだけ必要か？　1日24時間、365日の稼働を想定しているか、1日10時間のみか？
• 業務フローが明確になっているか？
• 今回作成するプログラムの範囲は明確か？
• エラーケースについて考察があるか？

　上記が、要求仕様にしっかり書いてあるか確認しましょう。

2.3 プロトタイプを作成する

　「実現可能性が分からない」「応答時間を予測できない」「実物がないと判断できない」という場合は、プロトタイプを作成します。例えば、下記のような場合です。

• 客におススメを提示する「商品レコメンドアルゴリズム」が複数あり、最適なもの探したい
• 客が、どの商品に興味を持っているのか判断したい
• 使用したことはないが、便利そうなプログラミング言語、ライブラリを試したい
• 新しいWebサービスを活用したソフトを作りたい
• 応答時間を確認したい

　このようなものは、事前にプロトタイプを作成し、クライアントが求めているものを実現できるかめどを立てて進めましょう。これによって、「実際にやってみたけどできません」という「土壇場での致命的な大問題」を防げます^※1）。

※1）とはいえ、実現場ではプロトタイプを作ったにもかかわらず、考慮していない事象が見つかり、実現できるかヒヤヒヤなんてケースがたくさんあります。

3．終わりに

　今回は、要求仕様フェーズの問題点を整理し、対処法を紹介しました。要求仕様フェーズの問題点は、解決するのが非常に大変で、どんな組織であっても何らかの悩みを持っています。皆さんは、今回の対処法があることを頭に留めて置いていただければと思います。

　次回も、要求仕様フェーズの問題点と対処法に触れます。

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

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

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

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

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

【 筆者紹介 】

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

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

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

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