イチから全部作ってみよう（11）たこ焼き屋模擬店の要求仕様書を抜け漏れなく作る：山浦恒央の“くみこみ”な話（180）（1/3 ページ）

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第11回は、前回「機能分割」を用いて作成したたこ焼き屋の模擬店をの要求仕様書を抜け漏れのないようにブラッシュアップする。

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

1．はじめに

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

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

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

2．前回の振り返り

　まずは、前回までに解説してきた要求仕様フェーズの大まかな開発手順を示します（図1）。

図1　要求仕様フェーズの開発手順［クリックで拡大］

　図1は、要求仕様フェーズの一連の開発手順です。発注側が企画を考え、開発側がヒアリングを行います。ヒアリングした内容は、ヒアリングシート（議事録など）にまとめ、要求仕様書として定義します。作成した要求仕様書は、最終的に発注側とレビューし、合意できれば要求仕様フェーズ完了です。

　前々回と前回の過去2回は、図1の「要求仕様書作成」のイメージをつかむことを目標とし、文化祭のたこ焼き模擬店を題材として、機能分割の観点から要求仕様書の作成例を説明しました。機能分割をすると、「1つの機能が他と独立している」「仕様にまとまりができる」「作業分担ができる」というメリットがあります。

　前回記事を読んでいない方は、一度目を通してからまた本記事に戻ってきてください。

　今回は、前回作成したたこ焼き模擬店の要求仕様書をより詳細化します。

3．たこ焼き模擬店で考える要求仕様書の問題点

　理想的な要求仕様書は、正常時だけでなく、異常時、限界時も含めて、発注側の要求事項を漏れなく明確にまとめ、見聞きしたことがない人にも伝わる文書とすることです。しかし、これは簡単なことではありません。前回のたこ焼き模擬店の要求仕様書から発生し得る問題点を考えます。

　ソフトウェアの開発は、人類が作る人工物の中で、圧倒的に高難度です。これには、（1）規模が大きい、（2）適用しなければならない自然界の法則がない（考え方さえ正しければ、何でもOKの「芸術」を工学的に作るようなものです）、（3）目に見えない、（4）異常処理、境界処理、特殊条件が多過ぎる、という4つの理由があります。

※写真はイメージです

　（4）に関して、人間は一切間違えず、悪意満載の行為もせず、全ての機器が正常に動作するならば、世の中の処理や作業の80％はなくなります。まず、警察、軍隊、警備員は不要になり、あらゆる店では、商品の横に段ボール箱を置き、「ここに代金を入れてください。釣銭もお取りください」と書けばいいのです。事件や事故は、自然災害に関する物だけになります。航空機の運航では、異常事態を考えなくてよいので、CA（キャビンアテンダント）は飲み物と食べ物を乗客にサービスするだけで十分で、不時着時の対応は不要です。

　朝、起きて、学校や会社へ行くだけでも、無意識のうちに多数の判断をしています。どんなネクタイを締めるか、前から来る人をどう避けるか、どの車両が空いているかを考えているのです。例えばレシピ本に、「水を1リットル、鍋に入れて95℃に加熱する」と書いてある場合、「プログラマーの職業的な習性」として、「断水で水がなかったらどうしよう？」「コンビニへミネラルウオーターを買いに行こう」「コンビニが閉まっていたら？」「電車に乗って、隣の駅のスーパーへ行こう……」と際限なく考えてしまいます。筆者の経験では、プログラムの処理の80％以上は、異常処理、境界処理、特殊処理であるように思います。筆者の先輩は、「正常データしか入ってこないなら、Cコンパイラ程度なら、オレ1人で1週間で作れるよ」と言っていました。

例1：異常ケースの考察不足（天候不順になったらどうするかなど）

部員　雨で天候不順の場合はどうすればいいですか？

部長　中止になる場合は、朝7時までにこちらから中止連絡をします。連絡がない場合は、通常通り開催とします（厳しい部長の場合は、「そんな当たり前のこといちいち書いてられないよ」という場合もある）。

部員　分かりました。

例2：急な仕様変更（明日が文化祭なのにたこ焼きソースを増やしたいなど）

部長　たこ焼きソースにチリソースを加えたいです。今からでも可能でしょうか？（可能でしょうかと言いつつ、加えろと言っている）

調理係　チリソースは本当に必要でしょうか？

部長　顧問の先生がチリソース好きで、ぜひ加えてほしいそうです。

調理係　文化祭は明日なので、もう厳しいです。明日の朝スーパーに行って確認しますが、ない場合は提供不可とさせてください。

例3：仕様抜け（本来あるべき係がないなど）

部員　よくよく考えると、PR係がありませんね。たこ焼きを作っても売れないと意味がないので、PR係を入れる必要がありませんか？

部長　たこ焼きを作ることにしか目がいかず、PRのことを見落としていました。今から加えます。要員は、設営係が行ってください。

部員　この部長大丈夫かな……。

　人間なら、少々の異常事態は「臨機応変」に対処できます。6人で食事をすることになり、ワインを1本オーダーしたところ、参加者が1人増えた場合、1本のワインを7等分すればいいのですが、コンピュータの場合、「臨機応変」も細かくプログラミングする必要があるのです。

　文化祭で多少の問題が発生しても、人間なら「臨機応変」に対応できます。一方、コンピュータの場合、異常事態、境界処理を全て想定し、各異常にどう対処するかをきちんと定義しなければなりません。漏れがあると何が起こるか予測不可能で、いわゆる「プログラムが暴走する」事態になり、最悪、データ破壊、機器の誤動作、損傷につながります。よって、異常時の処理や仕様抜けがないかきっちり考える必要があるのです。