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

　要求仕様フェーズでは、クライアントから作りたいソフトの概要をヒアリングし、要求仕様書にまとめます。要求仕様書は、開発の根幹に関わる文書で、これを作れないと開発に取り掛かれず、場合によっては、プロジェクトが頓挫します。

　要求仕様書をきちんと書く大変さは、「野球を一回も見聞きしたことがない人に対し、野球の進行手順やルールを詳細に定義し、それを読んだ瞬間、野球ができるようになる説明書」を考えれば理解できると思います。非常に高度な技術力が求められますね。

　今回は、前回記事で紹介しきれなかった要求仕様フェーズの問題点を取り上げます。

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

2．要求仕様フェーズの問題（その2）

2.1 実現可能性を過小に考える

　要求仕様書は、製品の取扱説明書的なものであり、実物ではありません。そのため、実現可能性（本当に仕様通りの機能や性能を備えたソフトウェアを実現できるか）を見通すことが困難です。実物が目の前にないのでしょうがないですね。

　次の例から考えてみましょう。

仕様の例
- 商品検索は、3秒以内で画面に表示すること。
- 商品の登録点数は、100万点とすること。

　上記のように、「最大100万点の商品を3秒以内で表示すること」と依頼があったとします。この際、「検索なら3秒もあれば終わるだろう」とか「100万点の登録は楽にできる」と過小評価し、いざソースプログラムが出来上がってデバッグ段階に入ったところ、要求（特に、性能要求）を達成できずに苦労するケースが少なくありません。

　個人商店のECサイトならば、仕様変更で対応できるかもしれませんが、ミッションクリティカルな製品ではそうはいきません。例えば、「エアバッグが衝突を検知して1ms以内に作動指令をONとする」との仕様があるとします。1ms以内に動作しないと、エアバッグの意味がない場合、商品として成立しません。気軽に決めた仕様の中に、実現可能性を保証できるか注意する必要があります。

2.2 要求仕様書の優先順位は全てMUST

　クライアントによっては、依頼した仕様は「MUST（マスト）」であり、全て実装してくれると思っています。スケジュールに余裕があれば問題はありませんが、切迫していると話が変わります。筆者は、要求仕様の重要度や優先度を「松」「竹」「梅」の3段階に分類して開発するべきだと考えています（最重要の「松」は全体の50％以下、次の「竹」が20％以上、優先度が最も低い「梅」を30％以下にするといいでしょう）。実際は、その考え方に同意しないクライアントは少なくありません。

※写真はイメージです

　例えば、15カ月でリリースする予定だったけれど、顧客の都合で要求仕様が二転三転して、なかなか凍結できず、3カ月の予定だった要求仕様フェーズに9カ月も要した場合、開発スケジュールを守ることは困難です。残りの6カ月で、設計、コーディング、デバッグ、テストは進められません。そんな場合、現実的な解決法は、リリースの日程と、全機能の実装のどちらが顧客にとって重要かをヒアリングすることです。リリースの日程を死守することが最優先なら、優先度が最も高い「松」の機能のみに絞って実装し、一方、全部の機能が必要なら、スケジュールを6カ月延ばすしかありません。どれだけ、仕様凍結が遅れても、本来のスケジュール通りにシステムが完成すると考える顧客は意外に多く、絵に描いたように「デスマーチプロジェクト」となります。結局、6カ月遅れでバグだらけの物ができ上がり、顧客のビジネスでは使い物にならず、開発チームも疲弊して、共倒れになります。

　要求仕様を決める段階で、仕様の重要度や優先度を「松」「竹」「梅」の3段階に分類し、スケジュールの遅延が顕著になった場合に備え（デバッグ工程で遅延が顕著になることが多い）、「工学的な手抜き」を事前に考えておきましょう。

要求仕様書が完成しても安心できない

　　　　　　 1|2 次のページへ