要求仕様戦争（その3）

■仕様書をどうこうする――「要求」の見える化

　「要求を仕様化する技術・表現する技術」がオススメ。「要求とは」「仕様とは」からはじめて、仕様戦争までの経緯、回避するための具体的施策までが分かる。「Excel を用いた仕様書」はなかなか興味深い。

　著者は「要求」と「仕様」の関係をロジックツリーに見立てる。こんなカンジ。仕様1～n を実装すれば要求Ａが実現する、という仕掛けだ。

┌───┐
│要求Ａ │
└┬──┘
　 ├─仕様1（スペック1-1,1-2,1-3...）
　 ├─仕様2（スペック2-1,2-2,2-3...）
　 ├─　…
　 └─仕様n（スペックn-1,n-2,n-3...）

　まぁ、こんなにキレイにならないだろうが、「このスペック（群）で"やりたいこと"は実現していると言えるのだろうか?」という視線が、どのフェーズでも配れるという点は素晴らしいと思う（実際に目配りするかどうかは別として）。

　本書のポイントは、「仕様書に要求"も"書け」に尽きる。つまり、仕様書に「スペック」だけ書くなと。「要するに何がしたいのか＝要求」も併記しろとしつこく主張する。なぜか?

　なぜなら、要求は「その仕様になった理由」を表すから（←超重要）。だから、要求とセットで仕様を検討することで、仕様モレは防げる。「その要求を実現するためにその仕様で必要十分か?」 という視線がつきまとうから。ホントのところ、実装フェーズになったらそれどころじゃないって、確定仕様をコードに落とすのに精一杯で、見る箇所も極めて狭い範囲に限られている。それでも仕様書を見る度に要求が目に入れば、「この仕様だけで要求は実現できる?」という問い直しをすることになる。言われたとおりに書いたはいいが、やりたいことは結局できませんでした、という悲しいよくあることは、これで、無くなる。

　あるいは、仕様の衝突を事前に察知→顧客レベルで回避する。仕様の衝突の根本は、要求の衝突だからだ。その場合、どちらか、あるいは両方の「要求」が曖昧性を含んでいる。要求を仕様に分解するのではなく、要求をロジカルに分解する。これにより、仕様化する前に要求同士で矛盾を起こしていることが「見える」ようになる。そうなればシメたもの。

　どっちを仕様を優先するかは、どの要求を優先するか、の議論になる。A担当の「要求A」とB担当の「要求B」で決める話。ひどい場合は、A担当が先月言った「A要求」と、昨日言った「A'要求」との衝突。Aさんに判断してもらえるよう「要求の見える化」をしよう。道理が引っ込む無理な要求の狭間で苦しむことは、やめよう、仕様バグの温床だ。

　しかし、一つのドキュメントに「要求」と「仕様」が混ざると分かりにくい、といった弊害が出てくる。あるいは、仕様書を開くと要求が見えるため、オーバースペックになる恐れがある。著者に言わせると、これを回避するための「Excel仕様書」だそうな。「要求」の階層と「仕様」の階層を分けて記述するところがミソ。Excel のオートフィルタを使えば階層ごとの表示／非表示をコントロールすれば問題解決。詳しくは本書で。

■「要求の見える化」の実践と効果

　その実践。Excel で仕様書は邪道じゃーと思っているので、著者が推奨するExcel 仕様書は作らなかったが、要求を念頭においた仕様管理は確かに効果があった。チームメンバーにこう周知したのだ→「顧客へのレポートの先頭、仕様書の各セクションの冒頭、ソースヘッダコメント、さらにメモ／メール／ホワイトボードに至るまで、関係する"要求"を必ず書け」ってね。そして、要求は「○○をするために…」という表現形式でロジックツリーで分解せよとレクチャー。

　その結果、変わったのは、ペーパーではなく、質問のやり方。曰く

　　　「この機能が実現すれば、本当に○○要求が実現したことになりますか?」

　　　「やりたい○○が曖昧なため、△△機能は追加仕様がありますね」

　　　「○○をやるにあたって、足りないスペックはありますか?」

そして極めつけが、プロジェクトに火がついてケンアクな雰囲気で出てくるセリフ、

　　　「とどのつまり、何がしたいのでしょうか?」

が、かなり早い段階で（したがって比較的なごやかな空気の下）、お互いに口にするようになった。これは進歩。

　これまで、部分的に五月雨で放り出される「仕様」をキャッチして、ジグソーパズルのピースを当てはめるように組み上げていたものが、最初に「やりたいこと」を念頭におきながら作業を進めるようになった。もちろんモレは絶滅したとは言わないが、行き違いは格段に減った。さらに、仕様がぶつかりそうなとき、その仕様が支えている要求どうしを並列して見せることにより、顧客に優先順位付けをしてもらえるようになった。

　冒頭の質問例になぞらえると、こんなカンジになる。

┌─────────────┐
│身長57メートル体重550トン　　│
└┬────────────┘
　 ├─素材（超合金）
　 ├─横幅（?）
　 ├─　…　　←←←←ココ★
　 └─動力（超電磁）

　…このやり方だと間違いなく★で取りモレが出るだろう。プロジェクトの途中で超電磁ヨーヨーの「要求」が挙がったとしても対応できるだろうか?

┌────────┐
│汎用人型決戦兵器│
└┬───────┘
　 ├─汎用（陸・海・空、メンテナンス、パイロット）
　 ├─人型（スペックサイズ）
　 ├─決戦（使徒撃退?第3新東京市防衛?、勝利条件）
　 └─兵器（敵の定義、戦闘方法、装備）

　…このやり方だと、それぞれのノードからさらに要求が定義され、要求のブレークダウンによりスペックが決まってくる（当然、エヴァ単体を作るだけでは意味がなく、チルドレン、セントラルドグマ、マギ、第3新東京市そのものを準備・運用・メンテナンスする必要が出てくることが分かる）。さらに、人類補完計画は想定外の運用であることも見えてくる（顧客は誰かにもよるが…）

　本書のやり方をそのまま適用できるかは分からないが、考え方は非常に使える。経験を積んだ方なら「そんなのアタリマエじゃねーか」ということばかりあるし、あるいは身につまされるエピソードが多々あるかもしれない。しかし、著者の主張・方法を知るにつれ、「わたしならこうする！」というアイディアが必ず浮かぶ。読んで分かった気になってオシマイという無駄本と違い、本書を読むと何らかの具体的アクションができるはず、しかも自分の中から湧いてくる、そういうスゴ本。