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

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

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

1．はじめに

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

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

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

2．要求仕様フェーズの振り返り

　図1から、要求仕様フェーズを振り返ります。

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

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

　前回は、図1の中の「ヒアリング」に着目し、ECサイトのトップページに関するヒアリング例を作成しました。今回は、「要求仕様書作成」です。

3．要求仕様書とは

　要求仕様書とは、発注側が実現したいことを文書形式でまとめたものです。

図2　ソフトウェア開発での要求仕様書［クリックで拡大］

　図2では、一般企業が業務のコンピュータ化を思い付き、それを開発会社に発注して、目的となるプログラムを受領するまでを表しています。業務改善のアイデアが発注側の頭の中にあって、それを言葉で開発側に伝える方式は、高校での「情報」の授業で作る豆粒プログラムでは可能でしょうが、数百kステップの業務用ソフトウェアでは不可能です。ソフトウェアが実行する機能を詳細まで書かないと、機能に漏れがあったり、「言った、言わない」で訴訟になったりします。要求仕様書がキチンと書けていれば、ソフトウェア開発の80％は成功と筆者は思っています。

　過去、要求仕様書は、「発注側からヒアリングした内容をまとめたもの」と言いましたが、初めての人にとってはどんな文書か分かりづらいと思います。そこで、ECサイトを例とした話はいったん置いておき、ジャンケンの要求仕様書を書くことで、何をどの程度まで書かねばならないかのイメージを深めていきたいと思います。