イチから全部作ってみよう（6）要求仕様フェーズにおける開発の標準化やスパイラルモデルの有効性：山浦恒央の“くみこみ”な話（175）（2/3 ページ）

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

　ソフトウェア開発において、組織でルールを定め、それに従って開発することで、やるべき作業が確実に実施でき、工業製品として高品質なプログラムを開発できます。例えば、組織で定めた要求仕様書の開発手順の例を以下に挙げます（図1）。

図1　開発手順の例［クリックで拡大］

　図1は、要求仕様書を定義する手順として、開発プロセスとして以下のことの実施を求めています。

• （1）発注者にヒアリングを実施し、ヒアリングシートを作成する
• （2）要求仕様書を作成する
• （3）レビューを実施し、レビュー記録にまとめる
• （4）作成した要求仕様書を発注側にレビューしてもらう

　この方式に従えば、誰が担当しても、ヒアリングからレビューまでを同じ手順で確実に同じ作業で実施できることが担保できます。よって、要求仕様書の記述ミス／抜け／誤解などを未然防ぐことにつながります^※1）。

※1）注意点は、決まりごとを作ったとしても、エンジニアが順守するとは限らないことです。このような問題が別途発生し得るので注意してください。監査チームがある組織では、上司が是正を求められるケースもあります。

2.2 過去の仕様書を再利用する

　要求仕様フェーズに限らず、過去の資産を活用することは重要です。例えば、アルバイトに応募するときに、履歴書を書くことをイメージしてください。この場合、自分独自で履歴書のフォーマットを作る人はまれで、書き方の例題に沿って書くことが一般的です。

　要求仕様書フェーズでも、過去の成果物を再利用することが一般的です。これによって、章構成、書くべきイメージをある程度、イメージできますし、流用できます。その結果、最低限、書くべき内容を担保でき、要求仕様の抜けを防止できます。

　もちろん、作るものによって、再利用しにくいものがあるかもしれませんが、章立てぐらいは流用可能でしょう。何もないところから、ゼロから作っていくこだわりを持つことも大事でしょうが、使えるものは使うことをオススメします。

2.3 小さい単位で開発し、仕様変更に対応する

　要求仕様定義、設計、コーディング、デバッグ、テスト、保守のフェーズに分けて開発するウオーターフォールモデルにおいて、世界中のプロジェクトマネジャーが最も緊張するのがデバッグフェーズです。「ひょっとして、とんでもない誤解をしていて、全くの別物を作っているのかもしれない」とか、「性能要求を満足できないと作り直しになるかも」「バグだらけだと、リリースが半年遅れてしまう……」など、心配のタネは尽きません。

　中でも最大レベルのリスクは「大きな誤解をして、プログラムを開発していないか？」です。顧客の要求通りのプログラムであれば、少々バグが多くても、力技で品質向上を進めれば製品は出来上がりますが、全くの別物なら、振り出しに戻って作り直しです。

　ウオーターフォールモデルでは、「ダメだ、作り直しだ……」と分かるタイミングが非常に遅く、コストや開発期間を60〜70％を投入した後です。そこで、実現可能性と性能をなるべく早い時期に保証し、悲惨な作り直しを避けたいとの思いで登場したのがスパイラルモデルです。

　図2にスパイラルモデルの概要を示します。

図2　スパイラルモデルの概要［クリックで拡大］