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

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

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

2．前回の振り返り

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

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

　特に、前回は、たこ焼き模擬店の異常系を階層構造で洗い出しました（図1）。

図1　たこ焼き模擬店の異常系の洗い出し結果（前回から一部修正）［クリックで拡大］

　図1を見ると、模擬店とはいえさまざまな異常系が存在することが分かりますね。人間なら異常事態が発生してから対策を考えればいいのですが、コンピュータの場合、事前に異常事態を全て洗い出して対策する必要があります。銀行のシステムがクラッシュして現金を引き出せない、ロケットが爆発したなどの事故は、想定できなかった異常事態が発生した結果です。想像力の限界が品質の限界なのです。

3．どこまで対応して、どこで諦めるか

　コンピュータは、プログラムが書いてある通りでしか動作することはできません。そのため、さまざまな異常系を事前に考え、対応策を検討する必要があります。対応策を事前に検討できない場合は、どんな動きをするか予想できません。例えば、たこ焼き機が故障した場合を考えましょう。

（1）たこ焼き機が故障し、明日、出店しなければならない場合は、下記を検討する
- （ア）業者に代替え機材が手配できるか確認する
- （イ）手配できなければ、ホームセンターで家庭用のたこ焼き機を購入する
- （ウ）たこ焼き機が購入できない場合は、フライパンを購入し、お好み焼き屋に変更する
- （エ）お好み焼き屋も困難な場合は、委員会にホットケーキや屋に変更できないか確認する。変更承認がもらえたら、ホットプレートを購入し、ホットケーキ屋に変更する
（2）どうにもならない場合は、出店を停止する

※写真はイメージです

　文化祭とはいえど、学校行事をドタキャンできません。人間ならば、たこ焼き機が故障したと分かってから、柔軟に対応策を検討しますね。コンピュータは臨機応変に動作できないため、事前にいろいろなトラブルの対応策を考える必要があります。これをキチンと考えるのはものすごく大変です。「キャンパスに隕石（いんせき）が落下した」場合は、「別の安全な場所を確保してたこ焼きを続行する」ではなく、「諦める」でイイと思いますが、「小麦粉がなくなった」場合は、「近くのスーパーで買ってくる」程度の対策を考慮する必要があります。「対応する異常事態、諦める異常事態」をきっちり仕様として考えなければなりません。

　今回は、前回の異常系に関する分析の続きとして、どこまで対応して、どこで諦めるかを検討します。

異常系を考えるポイント（前回の続き）と今回のお題

　　　　　　 1|2|3 次のページへ