要求仕様の抜け、漏れとは、本来必要な要求が抜けたまま次のフェーズへ進んでしまうケースです。例えば、完成したECサイトをテストする段階で、クライアントから「決済方法に抜けがあるのですが……」「在庫切れの商品は非表示にしたいのですが……」と指摘がある場合です。ごくまれに、「ワインは未成年では購入できない」という重大なレベルまで抜け落ちている可能性もあります。
この事象の数ある原因の一つが、業務知識の不足による記入漏れです。イメージとして、野球をやる場合を考えてください。バッターが投手の投げた球を打つと一塁に走ることが当たり前ですね。しかし、野球を全く知らない人は三塁に走る可能性があります。経験者は、「一塁に行くのが当たり前で、わざわざ説明する必要ない」とあきれますが、知らない人には分かりません。
例えば、下記のやりとりは日々発生しています。
この要求仕様は、ワイン販売に精通している人には当たり前のもので、わざわざ仕様に書くべきものではありません。こんなことまで書いていたらキリがありません。
われわれは、要求仕様書をベースに開発しています。申し訳ありませんが、この文書に書いていないことは考慮しませんし、考慮できません。
クライアントとしては、全てを仕様に書けないので、一丁目一番地のような超基本は開発担当に補完して欲しいと考えます。一方、開発担当は、書いてないことを開発するわけにもいきません。この攻防が日々起こっています。
要求仕様書は、自然言語である日本語を使い、図や表もブレンドして書くため、人によっては仕様を誤解するケースがあります。
上記は、「レバーの角度を90°回す」「レバーの回す回数を90回」とするかの解釈例です。筆者の感覚では、解釈Aの「角度として90°回す」と考える人が大多数になると思うのですが、解釈Bと考える人の気持ちも分かります。このように、誰が見ても誤解がない記述する必要がありますが、きちんと書くことは簡単ではありません。
今回は、要求仕様フェーズの簡単な振り返りと、問題点を解説しました。要求仕様フェーズでは、クライアントが求めるソフトウェアの機能、動作、性能をヒアリングして要求仕様書にまとめますが、簡単ではありません。誰でも知っている「野球」の仕様書を書くことの大変さや、みずほ銀行の大混乱を思えば、要求仕様書がいかに重要で、正確に記述することがいかに困難か、理解できると思います。
要求仕様書は開発業務の源泉となる非常に大切な文書ですが、要求仕様書をまとめられず、プロジェクトが頓挫したり、頓挫しなくても業務遂行の妨げとなったりすることがあります。今回の問題を十分認識し、要求仕様フェーズを乗り越えてもらえればと思います。パンドラの箱のように、要求仕様書は、ソフトウェア開発の全ての悪の根源ですが、悪が出尽くしてしまえば、「希望」だけが残るのです。
本連載で取り上げた「ソフトウェア技術者のためのバグ百科事典」を大幅に加筆、修正した山浦恒央先生の書籍「ソフトウェア技術者のためのバグ検出テキスト」が日科技連出版から好評発売中です。連載でも取り上げた、「要求仕様書のバグ」「実装抜けのバグ」「テスト業務のバグ」など、バグを36種類に分類して解説しています。囲碁や将棋であれば、「相掛かり」「矢倉」「四間飛車」「藤井システム」のような戦法を網羅した内容になっています。
前著「ソフトウェア技術者のためのバグ検出ドリル」(2019年11月刊行)も好評発売中です。実際にバグを含む要求仕様書、設計書、コーディング、デバッグ、保守を具体的に取り上げ、練習問題として31問を出題しました。同書は、囲碁や将棋における「次の一手」的な問題であり、ピンポイントの場面を取り上げ、実践力を鍛えることを目的としています。
両書とも興味のある方は、Amazon.comや書店でチェックしてください!
東海大学 大学院 組込み技術研究科 非常勤講師(工学博士)
Copyright © ITmedia, Inc. All Rights Reserved.