ソフトウェア技術者のためのバグ百科事典（7）要求仕様書がバグってる：山浦恒央の“くみこみ”な話（128）（1/3 ページ）

ソフトウェア技術者に向けて、バグに関する基礎知識をまとめていく新シリーズ「バグ百科事典」。第7回は、ソフトウェアのライフサイクルで最も重要な要求仕様に焦点を当てます。要求仕様書をしっかり作成しないと、その後のフェーズでさまざまな問題が発生し、プロジェクトの進行に大きく影響するのです。

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

※本記事はアフィリエイトプログラムによる収益を得ています

1．はじめに

　このバグ百科事典では、筆者が気になったバグを紹介し、読者の方々に「バグの早期発見」と「バグの未然防止」に役立てていただくものです。本コラムによって、より良いソフトウェア開発のお役に立てればと思います。

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

2．要求仕様フェーズ

※写真はイメージです

　ソフトウェア・ライフサイクルの中で最も重要なフェーズは、もちろん、要求仕様フェーズです。このフェーズでは、顧客が求める「機能」をキチンと聞き取り、要求仕様書にまとめます。例えば、エアコンのソフトウェアの場合、「機能」には、「室内を冷やす」「室内を暖める」「除湿する」「除菌する」などがあります。

　要求仕様書をしっかり作成しないと、その後のフェーズでさまざまな問題が発生し、プロジェクトの進行に大きく影響します^※1）。今回は、全工程の「最重要フェーズ」である要求仕様書のバグを取り上げます。

※1）今回の範囲外ですが、開発プロジェクトの工程が要求仕様フェーズにある場合、プロジェクト進行を妨げる主な問題を以下に示します。

2.1 要求仕様が凍結できない

　顧客自身、求めるものが分かっていない場合、仕様変更が多発し、要求仕様が凍結できません。この結果、プロジェクトは、「正しく」デスマーチ化し、以降の工程、特にテストフェーズの工数を食いつぶすことは「ソフトウェア開発あるある」ですね。「仕様を凍結できない」原因として、意外に多いのが、「組織内の縄張り争い」です。例えば、役所の「教育部門」と「産業部門」が共通で使う「コンピュータ教育振興システム」を開発する場合、処理自体は非常に簡単ですが、お互いが、「ウチの事務処理方式はこれでなきゃならない」と譲らないと、なかなか仕様が決まりません。

2.2 顧客の要求を受け入れすぎる

　予算に対して要求が多すぎる場合も、プロジェクトは「正しく」デスマーチ化します。顧客の要望を聞くことは重要ですが、機能が増えても開発コストを増してもらえることは「絶対に」ありません。要求項目と予算が釣り合っているか、しっかりチェックしましょう。