« 要求仕様戦争(その2) | トップページ | エロ文学「眠れる美女」で匂いに悶える »

要求仕様戦争(その3)

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

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

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

┌───┐
│要求A │
└┬──┘
  ├─仕様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新東京市そのものを準備・運用・メンテナンスする必要が出てくることが分かる)。さらに、人類補完計画は想定外の運用であることも見えてくる(顧客は誰かにもよるが…)

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

|

« 要求仕様戦争(その2) | トップページ | エロ文学「眠れる美女」で匂いに悶える »

コメント

ご無沙汰です
私も(汎用機COBOLの世界でも)プログラム設計書の冒頭、各セクション仕様の冒頭に、どんな要求に基づき何を実現したいのかを書かせるようにしています。ソース内にも出来る限り日本語のコメント文を書かせますね。
作るときもそうですが、これが一番役に立つのは仕様変更時とトラブル対応時。このセクションにこの修正は入れるべきでない、ココにはこんなロジックが入っているハズがないという、あるべき論でソースを追えるので、デバック時にも有効なんですよね。
で、結局は早く高品質のシステム完成と...はナカナカですが、本当に有効です。

投稿: 鉛のZEP | 2006.07.06 08:58

>> 鉛のZEPさん

お久しぶりです
本来ならば、「何を作るか」以前に「それで何をやりたいか」という質問をするべきなんでしょうね。そして、その答えが最初から分かっていれば、回りくどいソースになるはずがないんでしょうね…
「急がば回れ」とはよく言ったものです

投稿: Dain | 2006.07.07 00:07

おまけです
仕様書の書き方はプロジェクトにより様々でしょうが、会社やプロジェクトの姿勢、とりわけマネージャー、プロジェクトリーダーの姿勢が提案型、自分たちが作って使ってもらうんだという形であれば、自ずと仕様書=要求書となって行きますね。
同じ会社で似たようなシステムを開発していても、やる気の無いPJがユーザー部門の言われるがままに部下任せでダラダラやっていると最後必ず「そもそも論」で揉めることになってしまいます。
やはりマネージャーとかリーダーって影響力デカイと改めて感じる今日この頃であります。
明日、2年越しの開発がSを迎えますが、いやぁ~今回も大変勉強になりました。

投稿: 鉛のZEP | 2006.07.08 22:59

>> 鉛のZEP さん

あー、確かにそのとおりっ
マネージャーがプロジェクト全体の「色」というか「空気」といった雰囲気に与える影響は、はかりしれないものがありますね。「燃えさかるプロジェクトの火消し屋」として幾度か死線に投下されたことがありまが、似たような状況でもPMによって消防士だったりクラッシャーになったり、ヤル気満々だったり敗戦処理員だったり。

サービスリリース、おめでとうございます。いろいろあっても、そこまでこぎつけるのに大変な努力を強いられたかと忖度いたします。

投稿: Dain | 2006.07.08 23:51

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/18285/10741094

この記事へのトラックバック一覧です: 要求仕様戦争(その3):

» 要求を文書にするって大変だわ [ひよっこエンジニアリング]
出会ってしまった 以前大阪の千日前にあるジュンク堂にて出会った本「要求を仕様化する技術表現する技術 仕様が書けていますか?」に感銘し本書に沿って要求仕様書を作成しようと試みています。 アジャイルだなん...... [続きを読む]

受信: 2006.07.15 01:46

« 要求仕様戦争(その2) | トップページ | エロ文学「眠れる美女」で匂いに悶える »