　山浦恒央の“くみこみ”な話の連載第170回から、入門者をターゲットとして、「イチから全部作ってみよう」というシリーズを始めました。このシリーズでは、多岐にわたるソフトウェア開発の最初から最後まで、すなわち、要求仕様の定義、設計書の作成、コーディング、デバッグ、テスト、保守までの「開発フェーズ」の全プロセスを具体的に理解、経験することを目的にしています。

　なお、本シリーズ第1回目を読んでいない方は、以下のリンクから一読することをオススメします。

⇒連載「山浦恒央の“くみこみ”な話」バックナンバー

2．前回の振り返り

　理想的な要求仕様書は、正常時だけでなく、異常系、限界時も含めて、発注側の要求事項を漏れなくまとめ、誰にでも伝わる文書になっています。これによって、後々発生する問題を最小限にすることができます。

　連載第179～182回の過去4回は、要求仕様書のイメージをつかむことを目標として、文化祭のたこ焼き模擬店を題材とした要求仕様書を作成しています。興味がある方は、一度戻ってご確認ください。

　特に、前回の連載第182回は、たこ焼き模擬店の運営と販売に関する異常系の考察を行いました。異常系を俯瞰（ふかん）的に考える方法の一つとして取り入れてもらえれば幸いです。

　今回は、前回作成した「たこ焼き屋」出店で発生する可能性のある異常系の対処法（対策）を仕様書に反映します。

3．導入

※写真はイメージです

　高校の文化祭で、「野球部でたこ焼き屋を出店する」と聞いて、「楽しそうだね」とは思っても、「細かいことを決めなきゃならないんで大変だね」とは思いません。頭の中で、「簡単にできそう」と思っても、実際の「実行手順」をキチンと仕様として決めるのは簡単ではありません。「ここはテキトーにやればOK」の内容をキチンと書く必要があります。人間が普通に、簡単にやっている「臨機応変」は、実は、偉大な能力なのです。

　たこ焼き屋の出店でこれほど大変なら、「野球の仕様」はもっと大変で、携帯電話の仕様に至っては、人類が造った物の中で、最も複雑で巨大な人工物の一つでしょう。ソフトウェア開発では、どれほど複雑であっても、仕様書をキチンと書かねばならないのです。複雑な仕様書をどうすれば、漏れなくシステマチックに書けるか、どのようにすれば仕様のバグを見つけることができるかが今回のテーマの一つです。