« USBメモリを用いたソーシャル・エンジニアリング | トップページ | 要求仕様戦争(その3) »

要求仕様戦争(その2)

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

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

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

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

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

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

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

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

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

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

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

■要求仕様戦争の犯人

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

|

« USBメモリを用いたソーシャル・エンジニアリング | トップページ | 要求仕様戦争(その3) »

コメント

あー今まさにこの状態です。オレオレ仕様に振り回されっぱなし。終わりがまったく見えませーん。

投稿: 開発側SE | 2006.06.28 19:08

お金は動いているけどね。しかも増えてる。てことは経済価値はなんとか満たされてるということ?でも、不幸すぎるよね。みんな十分すぎるくらい経験して。でもなお糸口さえ見えない。てことは、この不幸はかなり大きな構造の帰結。ということかな??タイヤブランコとジェットコースターを交換してる絵には流石考えさせられますね。契約というか、市場というか、その辺りどうにかならないと、回避は難しいよーな

投稿: nasu | 2006.06.29 18:55

>> 開発側SE さん

あー、ご愁傷サマです。オレオレ仕様、なんとかする方法を書いてまいりますので、ご期待くださいませ

>> nasu さん

同じ悩みを組織的に解決しようとする試みがあります(Openthology)。この連載でも取り上げますので、ご期待くださいませ

…お二人に共通するのは、わたしも含め、「その悩みは人類初めてではない」ということ。先達たちが同じように悩み、解(の案)を遺しています。利用しないテはありませんぞ。

投稿: Dain | 2006.07.01 01:05

コメントを書く



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




トラックバック

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

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

« USBメモリを用いたソーシャル・エンジニアリング | トップページ | 要求仕様戦争(その3) »