要求仕様戦争（その1）

■要求仕様とは

　要求仕様とは、開発するシステムに対する顧客のニーズのこと。要するに「お客さんがやりたいこと」そのもの。仕様調整で紛糾したときの決め台詞「結局アナタは何がしたいの?」の【何】に相当する。仕様トラブルの100％はこのスレ違いによる。

　要求仕様について考えるために、ちょっとした質問に答えてみよう。以下のa. b. のうち、「要求仕様」を表現しているのはどちらになるだろうか?

　　a. 身長57メートル体重550トン

　　b. 汎用人型決戦兵器

　まず a. を考えてみる。これは「何」だろうか? これは「何」かのスペックだ（しかも部分的だ）。身長・体重は分かるが、横幅や厚み、姿かたち、素材 etc... は分からない。これは受注側が「○○はどうするの?」といちいち問い合わせる必要がある。当然、聞くのを忘れたスペックは製造者の「思い」で作られるリスクを負う。

　次に b. はどうだろう。身長・体重その他もろもろは分からないが、「何」かは分かる。要求されているのは「兵器」だ。したがって、スペックは分からないにせよ、次の質問は、こう続くだろう。何を想定した「兵器」なのか? 必要な性能は? 操作方法は? … 身長や体重といったスペックは、その結果によって決まってくる。

　正解はもうお分かりだろうが、本当の問題はここから始まる。要求仕様として最初に「身長57メートル」と提示されると、スペックからの視点に引きずられ、結果として仕様モレにつながることこそ、大問題。一見、矛盾しているようだが実はよくある話。

　いや、スペックを書くなといっているわけではない。もちろんスペックは重要であり、できる限り詳細に書いておくべきだ。しかし、本当に欲しいものが書いていなければ、スペックの羅列は罠になる可能性が非常に高い。欲しい「何」が書いてない場合、作り手はスペックの羅列から「想像」しはじめるからだ。

　その結果、どうなるか?

■「仕様書に書いてある！バグだ！」　vs　『読み取れない！追加要件だ！』

　萌芽は要求仕様書にある。一瞥しただけで分かる。表紙はご大層だが中身はスカスカ。経営層が決定を先送りしてきたからだ。「要求」をまとめ、仕様化し、レビューするだけの時間は、常に省みられない。「何が欲しいのか」が読み取れない要求仕様書が契約のテーブルに載る悲劇。それで見積もってくる営業に石を投げても詮なし。

　いっぽう受注者は、そこに書かれた「仕様」を逐一実装すれば、「要求」を実現できると信じる…わけねぇだろ！それは「仕様」の体を成しておらず、ひょっとすると「要求」どころか要望すら突き抜けた希望的観測の羅列となっている。

　それでも、「要求仕様書」と表紙に書いてあるので、恭しく頂いて、そこを起点に「仕様」を補完することになる。いくばくも進む前に気づく。これは穴だらけの仕様ではなく窓だらけ、ドアだらけだというべきことに。

　スケジュール上では「設計フェーズ」になっているので設計書みたいなアウトプットを作るのに注力することになる。実際は「何がしたいのか?」を想像したり尋ねたり、仕様の穴埋めをせっせとしているのだが。

■仕様戦争の起爆装置

　その結果、仕様の穴埋めは「製造フェーズ」まで持ち越される。仕様戦争が勃発する起爆装置の代表例は次のものが挙げられる。

• 片仕様…最もポピュラーな起爆装置。「○○の場合、△△をする」とあるが、「○○でない場合」が未決定。放っておくとプログラマは「何もしない」ルートにつなぐ
• error漏れ…片仕様のエラー版。エラーだった場合何をすればいいかが未決定。放っておくと最悪の場合「読み捨て＝何もしない」ルートにつなぐ。今ならexception漏れというべきか
• 状態考慮漏れ…「○○の場合」は値なので漏れも気づきやすいが、「状態」は通常外出しテーブルで定義される。状態を参照して判定するロジックは、安易に追加される「新状態」を考慮されない
• 仕様の賞味期限漏れ…その仕様が影響する開始時点と終了時点（仕様の賞味期限）が明記されてないがため起きる仕様間衝突

　なんせ「作りながら仕様決め」に等しいため、作り手は決めながら実装してるような気になる。コードの可読性は後回しとなり、「できるだけ早く」が合言葉になる。

　当然、当初の「要求仕様書」は省みられず、「メモ」「メール」「議事録」「資料の朱書き」といった形であちこちに飛び散った断片が実装されることになる。

■仕様戦争の勃発

　上記の起爆装置が作動するのはいつだろうか?

　　　　「顧客からの仕様変更が多すぎて…」

　　　　「やってるうちに要求の追加がつぎつぎと…」

　　　　「実装フェーズで見積もりの甘さが露呈して…」

　よくある上のセリフは的外れな場合が多い。ぶっちゃけ、ホントのところは作っている最中に仕様を検討しているからなんだが、さすがにおおっぴらに言えん。まさか仕様も決めずに受注しちゃってリソースを投入しているなんて、経営層にバレたら懲戒モノだぜ。

　王様は裸じゃないから、一度ついたウソは続けなければならない。ホンネとタテマエの使い分けが上手いSE/PMが出世する。マジメに取り組む奴ぁ出世する前に胃に穴があく。開き直った連中がテストファーストとかスパイラルとか名前を変えているだけで、やっている本質はまるっきり同じ。むしろ現実にタテマエを追随させようとしているに過ぎぬ。

　経営層が先送りしたIT戦略意思「未」決定のツケがスカスカ仕様書に化け、スカスカ仕様書を押し付けられたSE/PMはプログラマへ華麗にスルーパス。そして、全てのシワヨセがプログラマへ。

　ところが、プログラマは正直者だから、

　　　　「if (hoge)の後のelseには何を実装すればいいんでしょうか?」

　　　　「HogeException を受け取ったらどうすればいいんでしょうか?」

　　　　「状態テーブルの値と case 判定が一致しませんケド?」

…と訊いてくる。あたりまえだ。知らないと書けないから。しかし、誰も答えられない。当然だ、誰も考えてなかったから。

　さあ、仕様戦争の始まりだ。野郎ども、準備はいいか? ハイホー！ハイホッホー！