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

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

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

2．前回の振り返り

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

　理想的な要求仕様書は、正常時だけでなく、異常系、限界時も含めて、発注側の要求事項を漏れなく明確にまとめ、仕様を見聞きしたことがない人にも伝わる文書とすることです。これは簡単ではありません。

※写真はイメージです

　例えば、野球を1回も見たことがない18人の高校生に「野球の仕様書」を渡し、読んでもらい、「じゃあ、早速、2チームに分かれて野球をやろう」と宣言して、整然と野球を始めるのと同じです。この「仕様書」の中には、「打球がワンバウンドで観客席に入った場合」「ジャンプして大きな外野フライを捕球した外野手が、そのままフェンスの向こうへ落ちてしまった場合」程度の異常系の対処法は書いてあります（前者は二塁打、後者は、外野手が捕球の瞬間、片足でもフェアフィールドに着いていればアウトですが、両足が離れていればホームラン）。

　もっとレアなケース、例えば、「審判によるプレイボールの宣言の後、守備側の一塁手と二塁手が味方同士で殴り合いのけんかを始めた場合」「打者が安打性の打球を外野へ打った瞬間、外野席の数人の観客がグラウンドに球を投げ入れた場合」のような異常系は規定していません。考えられる事態は発生します。想像力の限界が品質の限界なのです。

　プログラムの中には、異常系の処理がそれほど重要でないものもあります。例えば、プログラミングの授業で書く10行程度のプログラムでは、正常ケースが動作すれば十分です。期末試験の点数を集計し、分析するプログラミングでも同様で、異常系を意識しないことが多いと思います。しかし、エアバッグの作動のように、人間の身体を傷つける可能性のあるソフトウェアや、銀行の口座処理のように、財産に影響するプログラミングでは、異常系にきちんと対処する必要があります。

　今回は、「異常系の考察」をターゲットとして、たこ焼き模擬店の要求仕様書をブラッシュアップします。

3．コンピュータは臨機応変には動作できない

　文化祭でたこ焼き模擬店を出店する場合は、担当者は人間で、よほど重大なことでない限り臨機応変に対応できます。例えば、料金の釣銭切れの場合は、「取りあえず、自分の手持ちのお金で立て替えて支払う」「販売しない」などの対応ができます。

　一方、コンピュータはプログラムを書いた通りにしか動作できません。ソフトウェアの開発者が釣銭切れを事前に考慮できていないと、実際に釣銭切れが発生した場合、プログラムがどんな処理を実施するか予測できません。「お釣りを出さない」「支払った金額が戻る」「フリーズする」程度なら、大事件にならないでしょうが、「どんな処理をするかは予測不能」ではプロの作ったプログラムと言えません^※1）。

　よって、異常系をしっかり検討して、不測の事態に対処する必要がありますが、キリがありません。そのため、どこまで対応して、どこまで諦めるかを考えることが大事です。そこで今回は、たこ焼き模擬店で考えうる異常系を洗い出します。

※1）例えば、プログラミング入門の授業で習う「ファイル入出力」で考えましょう。授業では、ファイル入出力用の関数で、ファイルからの入力や出力を確かめるだけにとどまっていると思います。授業の内容をもう一歩進めて異常系まで考えると、少なくとも下記に挙げる事象を考慮する必要があります。