« このツンデレ小説がエロい「ROOM NO.1301」 | トップページ | 「アート・オブ・プロジェクトマネジメント」読書感想文(その1) »

「仕様」という言葉の罠を回避する

 結論→ 「仕様」と「機能」を意識的に使い分けることで、顧客のテクニック「言葉のすり替え」を見抜くことができる。

 客先での仕様調整の場で、新人が手もなくひねられている(騙されているともいう)。もう少し手加減してやればいいのに、顧客の脅しが酷すぎる。


  1. あたりまえじゃないか、その機能が入っているのが仕様です
  2. なぜなら、いま私が現場に電話で確認したら、そういう運用になっているからです
  3. だから、その機能が入っていないのはバグなんです
  4. したがって、あなたは無償で今すぐこれを実装する必要があります

 テストフェーズ末期やリリース後、何らかの要求を満足していない場合、顧客より一方的に伝えられる最終通牒は、こんな論法だ。非常に強い口調で伝えられると、なんとなく「そうかも?」という気分になり、顧客が正しいという空気が場を支配する。

 その結果、ほとんどの場合、泣く泣く自腹で実装していることだろう。ひとつひとつは小さかろうと、チリ積も山にスケジュールは悲鳴をあげるかもしれない。あるいは、仕様通りに書いたプログラマにバグとして対応させることで、その良心に致命傷を与えるかもしれない。

 ここでは、「顧客の認識を再確認することで、本当のところを証明する」ことを目的とする。決して「顧客をやり込める」ではない。本当のところを明らかにして、後でどう扱うかを決めるべし(←カネの話ね)。結局自腹になるかもしれないけれど、ウソ暴論がまかり通ることはあってはならない。モチベーションが下がるからね。

 さて、先の顧客の言い分に戻ろう。上の1~4のうち、どれが間違っているだろうか? 答えは「ぜんぶ間違っている」なんだけど、あと一つ足りない「立場だけでこんな論を押し通す輩が仕様窓口の担当であることそのものが間違っている」が満点。

 では、なぜ間違っているか? それは、「仕様」と「機能」を巧妙に言い替えているから。こんなことを言い出す顧客とは、要件定義・分析フェーズでこんな会話をしているはずだ→「仕様はこうしてください」とね。

 ここで言う「仕様」は、「要求」だ。要求仕様と言い替えてもいい。

 つまり、○○のときは、△△というチェックをして欲しい、画面から操作者が△△というチェックを起動できるようにして欲しい… と、顧客からの要求のひとつひとつをとりまとめて、モレヌケ矛盾がないか確認してきたはず。

 そうした要求を実現するものが、「機能」なんだ。間違えてはいけない、要求(仕様)が先、機能が後なんだ。

 しかし、後になって「これが足りない」「あれが足りない」と騒ぎ出すのは、「機能」を指している。たしかに、要求が誤解、誤読されることもあるだろうが、その数はこの罠に比べると、微々たるものに違いない。思い出してみて欲しい、「この『要求』が実装されていない」という言い方をする顧客は、皆無だろう。後付けの「要求」であることがバレてしまうからだ。

 しかも、要求が足りなかったことを「機能不足」に置き換えている。その機能がない理由は、ほとんどの場合その要求をしなかったからだ。自分の誤りを棚に上げて声を荒げる。その機能が実装されていることを前提として、現場は待っているんだ、今電話で確認したんだ、と来る。たったいま見つかった要求が実装されていないことで、機能モレを主張するのは本末転倒なのだが、そのときのマジックワードが「仕様が実装されていない(抜けている・モレている)」。

 ここで言う「仕様」は、スペックそのものだ

 ある要求がないから、対応するスペックがない、そのスペックがないから、対応する機能が実装されてない ――この、ごくあたりまえの事実が、「仕様」という言葉を混ぜることで、見えなくなる。つまり、プロジェクトの最初は「仕様」を要求寄りの言葉として使い、プロジェクトの後半で、いざ要求をねじ込む段階になって、「仕様」を「機能」と等価と見なす(もしくは言い替える)。

 これは、狡猾というよりも、顧客の基本的な戦術だと思ったほうがいい。顧客の間で講習会でもやってるのかと邪推したくなる。「違うか!?」と詰め寄ってくるその場でロジックを粉砕してもいいのだが、間違いなくカドが立つ。実際、誤りを指摘すると、文字通り「顔を真っ赤にして」怒る。そりゃそうだ。みんなのいる場で、自分自身もダマしていたウソを暴かれるのだから。

 では、「顧客を言い負かす」ことが目的ではなく、本当のところを明らかにするには、どうすればよいか? それは、あなた自身が、「仕様」と「機能」を使い分けるしかない。気をつけないと、「仕様」と「機能」は、ごちゃごちゃに使ってしまうかもしれない。「この機能の仕様は…」なんてよく言うでしょ。

 ならば、どう使い分けるか? 顧客の言う「仕様」が「要求」である場合は、「ご要望」「要求仕様」とし、「機能」を指している場合は、「機能」と言い替えるんだ。

 例えば、顧客の言い分を反復するときに、こう言い替え【もどし】をする。


  1. つまり、その機能が入っていることがご要望だったんですね
  2. 現場に確認していただいて今分かったことは、そのような要求仕様があるということなんですね
  3. すなわち、その要求仕様が入っていない、というのですね

 するとどうなるか? 「機能が入っていない→仕様化されていない→要求していない」の順にさかのぼって考えることができる。あるいは「そんな"要求"がある、なんてことが"今"わかった」となる。前者は口に出さない方がいい。顧客を責めることになるから、みんなの脳内で遡及してもらおう。いっぽう、後者は、顧客の論理の言い替えのタイミングでさりげなく述べるといいかも。

 要求していないことが明らかになれば、触れる程度にとどめ、言い立てる必要は無い。すり替え戦略が破れたことが分かったならば(バカではない限り)、最後の結論にはもってこれないはずだ。すなわち、

  「したがって、あなたは無償で今すぐこれを実装する必要があります」

 …なんて、どう転んでも言えなくなる。顧客が自分の誤りを認めることは皆無だが、少なくともバーター対象にはしてくれるだろう。その機能は、結局無償で追加することになるかもしれない。しかし、手持ちのカード(いわゆる"貸し"というやつね)を増やし、今後の交渉を有利にすることはできる。カネにするのか、期間を調整してもらうかは、会議が終わった後、その顧客との二者間で決めればいい。

 立場でしか仕事ができない人の顔を潰すということは、その人の存在意義そのものへの問いを突きつけることになる。その場合、あなたの政治的立場に脅威となるかもしれない。そうしないためにも、この「言い替え」を上手に活用してみて

|

« このツンデレ小説がエロい「ROOM NO.1301」 | トップページ | 「アート・オブ・プロジェクトマネジメント」読書感想文(その1) »

コメント

ためになりました。

投稿: aaa | 2006.09.27 22:41

いつも楽しく拝見させていただいてます。今回のストーリーはとても実感できました。
ちょっと話はそれるかもしれませんが、IPA-SECのページ(https://sec.ipa.go.jp/index.php)に「経営者が参画する要求品質の確保」(書籍もありますがアマゾンでみると在庫切れです)
というのがダウンロードできるみたいなので読んでみるつもりです。利用者登録専用ページの出版物ダウンロードのところです。会員登録はいるようですが、無償のようなので。

投稿: ぺーすケ | 2006.09.28 10:30

> ぺーすケ さん

 ご紹介ありがとうございます、書籍を入手しました。一見したところ「教科書」です。これを下敷きに、「こんな大変なことに遭ってさぁ」とか、「そうそう、○○というヒドい目にあって、ようやくここで言っている意味が分かったよ」とか、実体験を交えて語るとオモシロイかもしれませんね。
(面白がっちゃ不謹慎なのですけど…)

投稿: Dain | 2006.09.30 22:10

コメントを書く



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




トラックバック

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

この記事へのトラックバック一覧です: 「仕様」という言葉の罠を回避する:

» 「仕様」という言葉の罠を回避する [ゴシック&ロリータ写真家アキオのブログ]
わたしが知らないスゴ本は、きっとあなたが読んでいる: 「仕様」という言葉の罠を回避するこれは、狡猾というよりも、顧客の基本的な戦術だと思ったほうがいい。顧客の間で講習会でもやってるのかと邪推したくなる。「違うか!?」と詰め寄ってくるその場でロジックを粉砕して....... [続きを読む]

受信: 2006.09.27 23:49

» 機能と仕様と要求 [〜SleepingCat〜]
「仕様」という言葉の罠を回避する なるほど確かに あたりまえじゃないか、その機能が入っているのが仕様です なぜなら、いま私が現場に電話で確認したら、そういう運用になっているからです だから、その機能が入っ... [続きを読む]

受信: 2006.09.29 23:24

« このツンデレ小説がエロい「ROOM NO.1301」 | トップページ | 「アート・オブ・プロジェクトマネジメント」読書感想文(その1) »