イチから全部作ってみよう（3）MINORIに学べ、全ての悪は要求仕様書から生まれる：山浦恒央の“くみこみ”な話（172）（1/4 ページ）

ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第3回は、ソフトウェア開発における全ての悪を生み出す元凶、要求仕様フェーズの問題点を解説します。

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

1．はじめに

　連載第170回から、入門者をターゲットとして、「イチから全部作ってみよう」というシリーズを始めました。このシリーズでは、多岐にわたるソフトウェア開発の一連の業務を理解することが目標です。連載第170回を読んでいない方は、以下のリンクから一読していただけるとありがたいです。

　今回は、要求仕様フェーズを進める時の問題点を解説します。ソフトウェア開発の全ての悪は、要求仕様書から生まれます。「パンドラの箱」のようなものですが、ちゃんと「希望」も残っています。

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

2．要求仕様フェーズでは何をするのか

　図1に、新しいソフトウェアのアイデアを思い付き、それを製品化するまでの流れを示します。

図1　ソフトウェア開発の流れ［クリックで拡大］

2.1 要求仕様フェーズ

　ソフトウェア開発の最初の工程が「要求仕様フェーズ」で、頭の中のアイデアを具体的に記述する工程です。製品にできることや機能を細かく書いた要求仕様書を作ります。「要求仕様書」と聞くと、「大統領所信表明書」のように物々しく感じますが、電気製品を買うと付いてくる「製品取扱説明書」と完全に同じものです。

　取扱説明書は、一般ユーザー向けのドキュメントで、そこには「（1）以下の部品がそろっていることを確認してください……、（2）以下の手順で操作してください。［1］電池を入れる［2］スイッチをオンにする……」などが10ページほど書いてあり、さらに、「こんな使い方はしないでください」と禁止事項も列記してあります。「要求仕様書」は、「取扱説明書」と同一と考えても構いません。

　製品にできることを漏れなく正確に書くには、高度な技術と知識が必要で、ソフトウェア開発で最も重要なフェーズがこれです。いわゆる「上流工程」がここで、技術力、想像力、創造力に優れた技術者が担当します。

　「ソフトウェア開発で、要求仕様書が最も難しい」は、「野球を一回も見聞きしたことがない人に対し、野球の進行手順やルールを詳細に書き、それを読んだ瞬間に、野球ができるようになる説明書」を作ることを考えれば分かると思います。自分がよく知っていて、十分に理解しているつもりの野球でさえ、知らない人に文書で分かってもらうのは非常に困難です。世界で最も複雑怪奇なソフトウェアを搭載するスマートフォンの要求仕様書を記述するには、想像を絶する労力が必要となります。

　要求仕様書を定義することは、ソフトウェア開発フェーズで最も困難であると同時に、要求仕様書が完成した時点で、その製品がどの程度売れるか、どれぐらい有用か、品質はどの程度かも予測できます。

2.2 設計フェーズ

　設計書は、要求仕様書をベースにして、ソフトウェア開発エンジニアが仕様を理解してソースコードを書く準備段階の文書で、処理のアルゴリズム、データの形式、サイズ、名称などを詳細に定義します。詳細は、今回の記事内で解説します。

2.3 コーディングフェーズ

　ソフトウェア開発技術者が設計書を読んで、コーディングするフェーズで、コンピュータが理解できるプログラムを作ります。詳細は、以降の本講座で解説します。