今日は、少しフランクなメンバーで馳走になりながら中華。その会合って、うまく表現しにくいけど、今から述べることは、営業獲得できたお祝いの席みたいに読んでもらえると良いかも。
顧客立場のメンバーを含めて打ち合わせして、機能面で削ったり追加したり。今日で概要確定して、合意形成。その後の馳走。知り合いは、どっちかというと構築側。
知り合い：「そう言えば、私『要求工学』の本読んでるんですよ」
私：「ふーん」
知り合い：「．．．．．．」
(何か言葉待ってる感じだったので）
私：「勉強するなとは言わないし、基本は知っとくべきだけど、今日のに役に立った?」
知り合い：「．．．．．．」
私：「お客さんが言ってる事って、超希望だったり、間違ってることあるんだから。」
知り合い：「そう言えば、お客さんが間違ってるという意識はあまりなかったな～。ちょっと作ってみて、後になって違うと言われることはあるとしても。」
私：「そんなのは、ある意味、最初のお客さん要望が間違っているから。」
「多分だけど、『要求工学』の本読んでも、お客さんを疑えとは書いてないよ。」
「しかも、現代でネックなのは、無料で使えてるシステム多すぎ。自分の所で構築する場合に、コストがかかるという意識がない。」
「なので、最初はお客さんが間違っているとの前提に立った方が良いくらい。」
「結構多いのが、要望として書かれているのが、新しい受注の人の知らない旧システムのこと。お客さんは、ほんとはそのシステムでの、使いたくない部分は少なくない状況。でもシステムを文書にしにくくて、旧システムのコピー＆ペーストで渡される。」
知り合い：「じゃ、どうすればいいんですかね～」
私：「心理学系とか、話術や交渉の本かな。でも、深層に描いているものを引き出すには”アクションラーニング”がいいかも。」
知り合い：「”アクションラーニング”っすね。読んでみようかな。」
うん、ネットでも良いから読んでみてと。あっ、ネットでも良いと明言したかは、紹興酒を結構頂いたので記憶が定かじゃない。また、”アクションラーニング”自体は会議などでの使い方なので、対人で使うにはちょっと応用すべきだろう。
要求(分析)→要求工学の本が解決してくれそうに思う人が少なくないような気がする。要求工学も、ある意味ではツール。そのツールを使う前に、考えとくべき事は少なくない。
知り合いさん、頑張ってね。
