« 2006年6月18日 - 2006年6月24日 | トップページ | 2006年7月2日 - 2006年7月8日 »

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

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

| | コメント (4) | トラックバック (1)

要求仕様戦争(その2)

■要求どおりに動かない、書いたとおりに動く

 「こんなときどうします?」なんて律儀に訊いてくるプログラマならまだいい。その度に顧客と丁丁発止して決めりゃいいから。しかし、世の中には律儀じゃないプログラマもいる。律儀じゃないプログラマは、いちいち確認しない。結果こうなる。

   「書いたとおりに作りました」
   「書いてあることしか作っていません」
   「書いてないことは作りこんでいません」
   「書いてないことは何がおきるか分かりません」

 つまり、メインルートから外れると何が起こるか(書いた本人も)分からないブツができあがる。あるいは良かれと思ってプログラマが仕様を創造することにある。経験豊かで優秀なプログラマが先回りすると喜ばれるが、失敗して「よけいなお世話」を作りこんでしまう場合もある。

 あるいは、最初からこうなることを承知の上で、「書いてないもの」を実装するために別料金を請求するベンダーもいる。いわゆるアドオン(add on)仕様というやつ。どこから add on 仕様となるかは力関係・責任分界・契約書によるが、わざとadd on になるように仕向ける悪質な連中もいる。

■仕様のねじれ・仕様の衝突

 ベンダーだけが悪なのではない。発注側が居直る場合もある。ありがちなのが「仕様のねじれ」や「仕様の衝突」だ。つまり、仕様同士が矛盾を起こす事象。

 これは、要求仕様書の不備が原因。実装する段階になって、要求仕様を「確認」する問い合わせが五月雨式に発生する。「確認」された仕様は要求仕様書そのものに反映されることなく、メールの返事、メモ、議事録といった断片化された形で散らばる。貧弱ゥな要求仕様書をメンテするより、確認できた仕様をコードに落とす方を優先されるからだ。

 仕様の確認作業で断片化された仕様同士が、あるとき(ほとんどがテストフェーズで)顕在化する。仕様AもFIXされ、仕様BもFIXされている。しかし、それぞれを実装すると、仕様Cで不具合が生ずる、というやつだ(経験あるでしょ?)

 でもって、仕様A,B,C の優先順位付けと不具合回避策が練られる。どれかの仕様が特定の条件下でねじ曲げられることになる。でもってその複雑怪奇なロジックの実装料金は、このセリフで断ぜられる。

   「仕様を出した時、指摘がもれたからです」
   「仕様は矛盾していません、実装で対応してください」
   「見つけられなかったことが問題です、したがってバグです」

■要求仕様戦争の犯人

 思い返してみると、わたしのキャリアは、この犯人探しの旅かもしれない。

 プログラマの頃は、穴だらけの仕様を持ってきたSEを恨んだものだ。片仕様、エラー対処が一切書いていない。書いてないからと適当に補完してプログラミングするとNG。プロジェクトもタケナワになって要求仕様がようよう見えてくると、

  要求仕様 ≠ 実装   >   「大きなお世話」「バグだ、直せ」
  要求仕様 ≒ 実装   >   「…」(金を請求すると居直り)
  要求仕様 ≒       >   地雷

 ペーパーからはとうてい読み取れない「要求」を、断片的なスペックから創造/想像する(まさにクリエイティブだよコレ)。生産性度外視して組み込んでも、感謝もされず、(違ってたら)罵倒され無償で修正させられる。これがくり返されると、最初から書かずに、何かあったら徹夜で突っ込むようになる。

 SEとして折衝しているとき、のらりくらりと決めようとしない顧客を恨んだものだ。決定を先送りし、曖昧な表現を多用することで自由度を上げ、プロジェクトがタケナワになる頃、ようやっとと突っ込んでくる。「この仕様が入っていない、その仕様はここに書いてある(読み取れる/判断できる/自明だ/常識だ)」とくる。あたかも、読み取れなかったオマエが悪いといわんばかりに。

 曖昧な仕様書、五月雨にやってくる「確定仕様」の"伝聞"、"メモ"、"メール"、"ホワイトボード"をつなぎ合わせて、なんとか形に仕立て上げる。断片的なスペックから「やりたいこと」を想像するしかない。顧客は「生産性を上げる」だの「変化に即応した」だの「効率的な運用」といった言葉を振り回すが、その定義はいつまでたってもフリーハンド。顧客の担当そのものが仕様、いわゆるオレオレ仕様に最後まで振り回される。

 顧客になり代わって、顧客の肩書で要件定義フェーズを進めたことがある。要求を取りまとめる期間が皆無であること、そのリソースが一切考慮されていないことを知ってガクゼンとした。そもそも意思決定者が「要件定義」の必要性をチリほども考えていない。コンサルタントの絵が全てだと思っている(画餅だが)。だって、こんなに潤沢のカネを使わせたんだから、この分厚なIT戦略資料をそのままシステム化すれば全てハッピー、と心の底から思っている。

 顧客の担当は社内調整に追いまわされており、肝心の要件定義に参加する機会は、ほぼ無い。さらにタチの悪いことにデキる人ほど調整役にひっぱりだこなので、残るのは相対的に低スキル者。しかも、口だけ達者・あしらい上手が窓口に据えられる。

 コンサルティングの経験から言い切る。そこでは要件定義なんてカケラほども考慮されていない。コンサルティングフェーズで必死こいてやっていることは、経営目標を業務戦略へいかにロジカルに緻密に落とし込むか、の一点だけ。仮にシステムに関わるとしても、いかに費用対効果につなげられるかの分析だけで、エンドユーザーにとってのシステム化要件は、皆無。

 あと、わたしがやっていないのは経営者だけだが、戦犯を探すことは無意味なことに気づいた。経営者には経営者の、コンサルにはコンサルの、発注側の担当には担当の、思惑がある。SEにはSEの、プログラマにはプログラマの言い分がある。その結果、

   ・リスクを負うことを恐れ、曖昧なままに先送り
   ・当事者意識の無さから、要件定義の重要性を軽視
   ・ヘタに言及・実装すると火中の栗になるので、ダンマリを決め込む

 誰か戦犯を仕立て上げ、石を投げても解決にならぬ。

■要求仕様戦争を回避するために

 ひとたび勃発したら、収拾はほぼ不可能と思ってよい。思いのスレ違いが増幅し、修復不能になった時点で表面化しているのだから。「もう作っちゃってるんですケド…」「もう出しちゃってるんですケド…」だから。がんばってなんとかなるレベルではない。ありがちなのは、「火消し部隊」と「仕様決め部隊」を分けて工程の引きなおす、深刻度と優先度とショーストッパーを分けて着手する等など。ホレ、かっちょいい言葉でいうならトリアージ開発やね。

 逃げるにせよ、立ち向かうにせよ、起きてしまった戦火をどうこうするのは皆さんご存知のようなので、「死なない程度にがんばろうね」という言葉を贈る。ここでは、そもそもそんな事態に陥らないようにするための手立てがある書籍をご紹介。合いそうな奴を参考にしてほしい。

 要求仕様戦争を回避するための切り口は、以下の3つ。

   ・仕様書
   ・開発工程
   ・人(PM)・組織

| | コメント (3) | トラックバック (0)

« 2006年6月18日 - 2006年6月24日 | トップページ | 2006年7月2日 - 2006年7月8日 »