イチから全部作ってみよう（9）ジャンケンで理解する要求仕様書作成の難しさ：山浦恒央の“くみこみ”な話（178）（3/3 ページ）

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第9回は、「ヒアリング」した内容をまとめる「要求仕様書作成」について、情報工学専攻の大学3年生でも悩む「ジャンケンの要求仕様書」を例にその難しさを解説します。

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

6．何が問題なのか

6.1 「複数人」は曖昧

　参加人数が「複数人」となっており、これでは1万人でも参加できることになり、曖昧ですね。また、上限値も記述していません（仕様書では、上限値、下限値は非常に重要です。ソフトウェアの最終テストをする品質保証部では、上限値が書いてない場合、例えば、上記の場合、1万人でジャンケンをするテストを実施します）。

　よって、2〜5人までなどの制限人数を付けるべきです。人数制限を設けない場合は、「6人以上なら、グーとパーだけを出し、少ない方が勝者として、5人以下まで人数を減らす。勝者が0人の場合、1つ前に戻る。勝者が1人の場合、その勝者を最終的な勝者とする」「教卓に立っている先生と同じ手を出した者を勝ちとし、5人以下になるまで続ける。勝者が0人の場合、1つ前に戻る。勝者が1人の場合、その勝者を最終的な勝者とする」などの対策を記述しておく必要があります。

　現実的には、「1万人集めることは不可能」「1万人ならそもそもジャンケンをやらない」となりますが、要求仕様書で定義したことをベースに設計書を書き、コーディングすると、1万人でもジャンケンをするプログラムができてしまいます。上限値、下限値の定義漏れは要求仕様書での典型的かつ致命的なバグであり、マーケットにリリース後、大きな問題になります。

6.2 手の形が明確ではない

　この要求仕様書では、「グー」「チョキ」「パー」の手の形の定義を書いていません。そのため、ジャンケンを知らない人が参加すると、意味不明な手を出してしまい、勝敗を決められませんね。よって、どこかに手の形を明確にする文書を入れる必要があるでしょう（写真や絵で見せるといいでしょう）。

6.3 合図のタイミング

　掛け声で、「ジャン」〜「ケン」〜「ポン」間の掛け声のタイミングを書いていません。例えば、「ケン」と「ポン」の間が1時間空いていてもよいことになります。「ジャン、ケン、ポンの発声はそれぞれ1〜3秒以内で行う」など、「各掛け声の秒数を均等にする」必要があります。また、「合図が合わない場合はやり直す」といった制限を付けるべきでしょう。

　ジャンケンの「ジャン」のタイミングをそろえるために、「最初はグー」と言って、開始のタイミングを整えるという考えを取り入れてもよいでしょう。

6.4 リアルタイムで互いの手を目視できるか

　3人でジャンケンをする場合でも、それぞれの居場所が10kmも離れていると通信回線を使わない限り、互いの手を目視できません。「参加者全員が互いの手をリアルタイムで目視できる」という条件が必要になります。

6.5 不正行為（ズル）が考慮されていない

　この要求仕様書では、「後出し」などのズルを考慮していません。

　要求仕様書には『「グー」「チョキ」「パー」のいずれかを出す。』と書いてありますが、「一度出した手を変えることはできない」とは書いてありません。現実のジャンケンでは、「ズルしてんじゃねーぞ」となります。要求仕様書としては、「後から手の形を変更できない」「不正があると指摘があった場合は、敗者とする」など制限を入れるべきです（この場合、誰がどのように不正を判定するかも、キチンと定義しなければならず、仕様書の複雑さは大きくなるばかりです）。

7．終わりに

　今回は、要求仕様フェーズの要求仕様書作成に着目し、ツッコミどころ満載ジャンケン要求仕様から要求仕様書をイメージしてもらう回としました。非常に簡単に見えるジャンケンでも、考えることがたくさんあります。特に、上限値、下限値、タイミング、異常時の処理まで考えることが重要です。これが抜けていると、仕様書のバグでプログラムが暴走し、結果が予測できません。ジャンケンの例なら、10億人が同時にジャンケンをすると100年たっても結果が出ないことになります。

　ジャンケンは、ほぼ全ての日本人全員が知っているゲームですが、ルールを漏れなく明確にまとめ、ジャンケンを見聞きしたことがない人に伝える文書とすることは簡単ではありません。ジャンケンでこれほど複雑なら、「野球のルールブック」はさらに複雑怪奇になるはずで、顕微鏡で見ながら重箱の隅を突くと、ルール間に矛盾があったり、未定義事項があったりすると思います。サッカーのルールブックが20ページほど、野球は200ページを越えます。そして、携帯電話機の要求仕様書は1万ページ以上になります。人類が作った最も複雑な人工物がソフトウェアです。ソフトウェアの要求仕様書を、漏れなくかつ簡潔に記述するのは簡単ではありません。

　要求仕様書には問題点が満載なので、興味がある人は、自分なりに問題点を洗い出してみるとよい勉強になると思います。

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

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

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

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

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

【 筆者紹介 】

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

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

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

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