« 2005年10月16日 - 2005年10月22日 | トップページ | 2005年10月30日 - 2005年11月5日 »

女はツンデレなのよ、気をつけなさい

年頃になったなら、あきらめなさい
子猫の顔していても、結婚したら
ツンケンのツノが出る、そーいうものよ

このヒトだけはー大丈夫だなんてー
うっかり信じたらーダメダメ、ダメ、ダメダメよ

D・V・D! D・V・D! ホラホラ呼んでいるよ
今日もまた誰か、VIPのピンチ~

… … … …。

… …。

…。

 ついカッとなって書いてしまった。今は反省している。

 和風で挙式する花嫁の頭に「角隠し」が被せられる。ありゃ「ツンデレのツノを隠す」と勝手に解釈していたが、間違い。女の長い髪には霊力が宿るとされていたので、嫁ぐ際に災いを一緒に持ち込まないようにという考えが基となっているらしい。

 しかし、今じゃ誤解の方が正しいのではないか? 先般の記事「ツンデレを嫁にするとどうなるか」[参照]の反響を見ると、激しく勘ちがいしてる方がいる。この記事の結論は、ツンデレは2次元のキャラ属性であって、3次元では「すべてがツンデレになる」んだよ。

女はみんな、ツンデレになる

 これ真。いまツンデレじゃなくっても、いずれそうなる。そしてそうなることが分かるのは、ダンナさんだけという悲劇に全米が泣いた。異論がある方はどうぞ。偽である反証をたった一つでも示してくれ。「ウチのヨメはツンデレじゃない!」と。

 反例→「ツンデレじゃなくって、いつもツンケンしてる」

 飲み屋やネット界隈で「ツン」だけを強調する話を聞くが、それは半分だけ。必ずある「デレ」を意図的に伏せて、「ウチのヨメはこんなに鬼嫁」と自嘲のような自慢(?)をする。それは「それでも家族をやっているオレサマ偉い」の反語だよ。

 だから、聞かされるほうは「はぁはぁ大変ですねー、私も覚悟しときます」なんて調子あわせておくだけでいいんだよ。間違っても「ツンが全て」と思わないように。「デレ」の範囲が人によって違うだけ。

デレの範囲は人それぞれなのだが…

 ツンデレを嫁にすると、デレ範囲が「人目あり/なし」から「おんなスイッチオン/オフ」に変化することは先のエントリで書いたが、一つ抜けがあった。それは、「ツンデレに子どもができるとどうなるか?」の答えだ。

 答え→デレ範囲がもっと狭くなる。子どもの目は他者の目。「こら、子どもが見てるでしょ!」「もぉ、赤ちゃん起きちゃうよ?」は子持ちなら一度は聞いたセリフ。それでも、「いいじゃないか」「でも」「ホラ、ここ、こんなに(以下自粛)」と続くのは一度ならず二度三度だろ。

 ポイントは子どもができるとツン範囲が拡大すること。だから究極の形態は、布団の中でだけ、となる。布団の中だけデレ、他の全てがツンの世界。逃げちゃダメだ。リアルとはそういうもの。

 嫁までの距離と手を動かせる範囲は極めて狭い。そう、まるでディスプレイとマウスで形作られる世界と同じぐらい。かつて、この狭い世界から抜け出るべく、PCの電源を落とし、リアルに女を求め、嫁を得、親となり… そして、こうして狭い布団の中であらためて気付く、「還ってきたんだ」と。

ツン→デレ脳内変換の重要性

 範囲だけではない。夫婦も長くなってくると、「ちょっ、おまっ…これが人に放っていい言葉か!?」と叫びたくなるほどキツいのが来る。まるで精神攻撃への耐性を試すアスカ使徒のごとく、情け容赦のない口撃を浴びせてくる。先の記事でも述べたように、極化するツンだ。

 これに、「なんだよ!」といきり立つのは良策だろうか? いや、それは逆効果というもの。やれば分かるが、口喧嘩では女に勝てない。すると、泥沼化させないために、受け流すことがどうしても必要になる。

 このとき、とても役立つのが脳内変換だ。どんなにツラい「ツン」がきても、嫁はツンデレなんだとひたすら念ずることで、以下の通りに変換できる。
 
 ξ*゚⊿゚)ξ アンタと一緒だとイライラするの!
 (〃▽〃) あなたの前だと素直になれなくて…てへ

 ξ*゚⊿゚)ξ さあ、さっさと会社行って稼いできてよ!
 (〃▽〃) は、早く行ったら早く帰ってこれるでしょっ
 
 ξ*゚⊿゚)ξ 汗くっさー、帰ったらまずフロ!そのままこっちこないで!
 (〃▽〃) 男のにおい…やだ、なんかもじもじしちゃう

脳内変換で夫婦円満。

'`,、'`,、'`,、'`,、(´▽`) '`,、'`,、'`,、'`,、

ツンデレ嫁の攻略

 ではいつも言われっぱなしかというと、違う。攻略法はある。だが、安易な気持ちで飛びつかないで欲しい。「釣った魚を再度釣るのは難しい」からだ。釣堀の魚を釣るほうが難しいのと一緒。以前「女房と仲良くなる7+1の方法」[参照]というエントリで詳説したが、ここでは、典型的なツンデレキャラである二人の茜(里村茜と涼宮茜)を用いる。

 両方の茜に共通するポイントは、「風邪」だ。どうアプローチしても「そんなことないです」「嫌です」と拒絶したり(里村)、会っていきなり「7点、5点、6点、4点、3点、5点、7点、合計37点…合格には程遠いですね~」と失礼なことを言う(涼宮)が、どちらもカゼひいて弱ってるところを優しくされることでフラグが立つ。弱ったときほど優しさが心に沁みやすいのは3次元にも言える話だし、ましてやナイチンゲール症候群は男だけじゃないゾ。

 さらに、涼宮茜の重要ポイントは「花束」だ。病院前で選んでもらった花束を「茜に渡す」選択肢がなんで無いんじゃぁぁと叫んだのは私だけでないはず。花束ってのは特殊なアイテムで、他にない以下の特徴を持つ(メモ準備!)

  1. 自分のシュミが出る(好き=欲しいが正直に現れるもの)
  2. 自分でわざわざ買わないけれど、もらったら嬉しいもの

 これを上手に使うのなら、

  1' 彼女に好きな花を選んでもらう
  2' それを彼女に渡す

 が良いかと。テレビなんかのネタから「女って、どんな花が好きなんだろ?」「んー○○じゃない?」と訊き出す。主語は女一般だが、訊かれた方は自分が好きな花を挙げるはず。んで、それを渡すわけだ。誕生日などの口実を作るよりも、「いつもありがとうと、なんとなく伝えたくなって」と突然渡すほうが良。 これは、嫁だけでなく意中の彼女に想いを伝えるにも効果的。いささか古典的だが、以下応用。

  1'' 女の子に誕生プレゼントしたいんだけど、何がいいかな?→選んでもらう
  2'' それを彼女に渡す(その子の誕生日じゃなくても可)

 上記は2次元キャラだけではなく、嫁に適用しても高い効果が得られたことを付け加えておく。念のため言っておくが、わたしの嫁は2次元ではないぞ。

野郎ども、がんばれよ

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

PG、SE、PM に求められるコミュニケーションスキルの違い

 この記事のまとめ。長文エントリごめん。

  1. 「コミュニケーションスキル」と一言でくくられるが、中身は多岐に渡る
  2. プログラマ(PG)は、「確認するスキル」が最重要
  3. システムエンジニア(SE)は、「絵にするスキル」が最重要
  4. プロジェクトマネージャ(PM)は、「言うことを聞かせるスキル」が最重要
  5. コミュニケーションは全人格的なスキルで、その真髄は「人を動かす」こと

 ン十年前、入社したての頃はCプログラマだった。その後、SEとして仕様折衝、設計に携わった。時折、炎の海に放り込まれ、コードを書いたりテストをしたり、リアルバトルを止めに入ったりと火消し屋のキャリアを積む。

 その後、PM見習いでチームリーダーをしているうちに、要件定義のさらに上流に引き寄せられ、今では開発現場を離れてコンサルタント(非IT)の丁稚をしている。

 システム開発の工程を河上へ遡及するにつれ、スキル不足を痛感した。わたしに最も足りないのはコミュニケーションスキルなのだが、どのコミュニケーションスキルが足りないのかは、その仕事にどっぷり浸かって初めて気付くのが常だった。

「コミュニケーションスキル」は多岐にわたる

 一般に、「コミュニケーションスキル」とひと括りにしがちだが、それは間違い。コミュニケーションスキルは多種多様にあり、一語にまとめるのは誤解を招く。

 例えばこうだ。

 コミュニケーションの「目的」からすると、「聞く」「伝える」だけでなく、「(相手の思いを)想像して汲み取るスキル」、「(汲み取った思いを)絵にするスキル」、「説得するスキル」、「自分の意思に従わせるスキル」が挙げられる。「言いたいことは分かったがダメ」では、ガキの使いやあらへんで。

 もっと掘り下げると、「自分の思いをしぐさや態度で伝えるスキル」と「情報は伝えるが思いを伝えないスキル(ポーカーフェイス)」が出てくる。必ずしも言葉を要しないところがポイントやね。

 コミュニケーションの「方法」から見てもスキルが沢山あるぞ。(1)会って話す→verbal/non-verbal 。verbal でも oral/literal 。oral でも1対1 、1対多、1対すげー多… (2)メールで伝える… (3)電話で伝える…と、それぞれのシチュエーションによって求められるものは全然別もの(適当な訳語が思いつかないので英語でカンベン)。

 てっとり早くいってしまえば、同じ writing でもホワイトボードを前にしたときとメーラーに打ち込む場合と別でしょ、ということ。理路整然とメールで言ってくるのに、ホワイトボードだとちっちゃな字で読めねぇ人、いるでしょ?

 さらに、同じ「コミュニケーション」でも、その間柄により変わってくる。例えば、「初めて会った人とうちとけられるスキル」、「慣れた間柄でも軋轢を生まないように厳しいことを伝えられるスキル」、「知っている人、知らない人大勢を前に伝えるスキル(プレゼンテーションスキル)」、「上下関係」、「請負元先」が挙げられる。

 もっと具体的に言うなら、こうだ。派遣社員のお姉さまとは楽しくおしゃべりできて、キツめの仕事もソツなく伝えられるのに、常駐先の部長には「全部優先じゃ分からないにょ」と言いたいのをガマンする(でも顔に出る)。

 これ全部「コミュニケーションスキル」の一言で片付けられる。コミュニケーションは全人格的な行動だけれど、くくり過ぎ。コミュニケーションスキルの重要性は誰も異論がないにもかかわらず、各論に入ると拡散したりテクニカルに走ったりして本質を見失うのは、これが原因。

 あらあら、前フリが長すぎた(あらあら禁止!)。以降、PG、SE、PMのステージ毎に必要なコミュニケーションスキルを考察してみる。

プログラマ(PM)の場合

 日経○○で「できるプログラマのコミュニケーションテクニック」という枕詞がよく使われる、本質は「確認するスキル、というかクセ」だろう。なんのこっちゃという前に、仕事ができるプログラマの口癖を思い出してみてみよう。

 デキるプログラマは、話をじっと聞いた後に必ずこう言い出すはず。「結局この件は、…にしたい、ということなんですね?」。つまり、「つまり」で始まるまとめを自分の言葉で返している。その結果、「そこは違うよ」「それでオッケー」がその場で得られる。

 一般に、プログラマは言葉を字義通り解釈しがち。いや、それはそれで正しいんだが、厳密に文字通り解釈しようとして、言葉と言葉の間にある「伝えたい意味」を取りこぼしてしまう場合がある。

 例えば、帳票仕様で「注文発注指示書」と「注文書」が出てきたとする。言葉が違っているので別物だと解釈し、がんばって両者の違いを見出そうとする。紆余曲折の末、訊いてみたら同じもので、後者が略称だったというオチはよくある(逆もまた然り)。

 だから、「それって…なんですよね」という確認は重要。よくある言い分「書いてある通りに作りました」「言われた通りにしてあります」は確かに正しいのだが、ホントにそれで良い? と自問してみるべし。

システムエンジニア(SE)の場合

 SEと言っても守備範囲は幅広い。顧客やPGとの相対距離で分類分けしたくなるが、ここでは共通して重要なコミュニケーションスキルを一つ挙げる。それは「絵にするスキル」。相手が言っていること、自分が言いたいことを簡潔な絵にして、見せるスキル。

 これはホワイトボードの前に立つ誰かを思い浮かべてみるといいかも。ミーティングが沸騰してくると、ツイと席を立ち、マーカーを手に、飛び交う論点を箇条書き+簡単な絵にまとめる。絵はシステム構成だったりUMLやDFDだったり、それらをごちゃ混ぜにしてあったり。

 いるでしょ、そんな奴。

 たいていかろうじて読める下手な字なのだが、不思議とすんなりと理解できる。ポイントは次の3点。

  1. 全員の意見がモレ・ダブリなく載っている
  2. 合意できているところ、議論すべきところが、きっちり描かれている
  3. 絵にした瞬間、全員に「分かる」形になっている

 1. と2. ができるということは、MECEができていること。そんな奴はえてして「MECEて何?」とくるが、用語を知らなくて体得できている好例。また、3. ができるということは、1 : n のコミュニケーションができている。

 PGなら極端な話、1 : 1 のコミュニケートだけで仕事になる。プログラマに仕様を伝えられる翻訳者を1人用意すればよいからだ。しかし、SEだとそんなわけにいかない。複数を同時に納得させる必要が出てくる。1 : n のコミュニケート。上手に言葉を尽くすのも一法だが、素早く的確に分かってもらうには絵が一番。

 また、絵には問題点をあぶりだす効用がある。「人 対 人」で議論がヒートアップしたときに有効なのが、ホワイトボード。

わたし →→→【問題】←←← あなた

 フツーの議論ならこれでいいんだが、白熱してくると、

【問題】 わたし →→→←←← あなた 【問題】

 となり、問題ではなく相手の言動に視線が行くようになる。テーブルをはさんであなたを熱く見るようになる。"you to me" の構図やね。このとき、ホワイトボードに絵を描くと上手くいく。

わたし と あなた →→→ ホワイトボード【問題】

 アラ不思議、"problem to us"の構図になる。文字のヘタクソを罵りながらホワイトボードの絵を理解しようとし、取り組むべきは【問題】であることに気付くというわけだ。育ってきた新人を「外」に出してもいいかな? と判断するとき、ホワイトボードの前の姿で決めている。

プロジェクトマネージャ(PM)の場合

 ここから自信たっぷりに書けなくなる。なぜなら見習いだから。だいたいわたしの周りのPMって、キャラとハートがおおまかカバーしてる人ばかり。オレについてこい!というやつやね。人情味あふれる親分肌で、仕事場よりも酒場で学ぶことが多いね。

 テクニカルなスキルはアレな人が多く、ほとんどの人は最新の技術なんて「知ったこっちゃない」と言い切る(をい!)。結果、「プロジェクトマネジメントって何?」「失敗プロジェクトの数だけ、成長できる」てな感じで、もはや時代遅れなのかもしれないが、巨大プロジェクトには必ず登板する。

 その人をアサインする監督の気持ちは痛いほど分かる。もはや経験則だけでマネジメントできないのに、その人をアサインせずにはいられないのは、

 ・成功した場合→やっぱりアノひとだったから
 ・失敗した場合→アノ人を投入してもダメ(だから誰を入れてもダメなはず)

つまり、どちらに転んでもアサインした自分の責任を追及されずにすむから。

 時代を感じさせる(かもしれない)PMの最重要コミュニケーションスキルはコレ→「言うことを聞かせるスキル」。情報を正確に伝えるのがコミュニケーションの基本かもしれないが、そもそもコミュニケーションの目的は、伝えた後に相手の行動を促すこと。それも、自分の望んだ方向へ動いてもらうことこそが、コミュニケーションの真髄なり。

 「言葉のキャッチボール」や「相手の気持ちを汲み取る」など、柔らかめに表現されるため、この真実が見えなくなっている。まといつく全ての修飾子を取り除くと、コミュニケーションの本質は「自分の意思を伝えて、相手に行動を呼び起こす」ことに尽きる。的確に伝える、過不足なく伝える、タイムリーに伝える、相手のコトバで伝える …等など、全ては「伝えた結果、相手に動いてもらう(自分の動かしたい方向へ)」のためなり。

 これに気付かないまま、自分ではキチンとコミュニケートしたつもりでいると、「ちゃんと言ったんですけどねー」「分かろうとしないアイツが悪い!」というグチになる。つまり、「意思を伝える」のが目的ではなく、「伝わった意思どおりに動いてもらっていない」からだ。

 スゴいPMは、人を動かす。ご自身の経験を思い出して欲しい。スゴいPMに重たい話を持ちかけたり、逆に持ってこられたとき、その会話の最後の言葉はこんな感じになってるはずだ。

キミの話はよく分かった。とても大変なことも分かる。だが、この仕事はキミにしかできない。それは私が保証する。だから、頼む、やってくれ。

 んで、スゴければスゴい人にけしかけられるほど、話の終わりごろにはヤル気、ソノ気、気合充分になっているはず。その具体的なやり方は、D.カーネギーの「人を動かす」に書いてあるが、これを読んでいる/読んでいないにかかわらず、彼らは体得している。

 やり方は分かる。人を動かすだ。しかし、それを身につける良い方法が分からん。まぁ、practice あるのみなのだが。 practice ついでに小話で締める。確か「達人のサイエンス」だったはず。

 ニューヨークを訪れた観光客が道に迷った。街角の老人に「カーネギーホールにはどうすれば行けますか?」とたずねると、老人はこう言ったそうな。

 " Practice ! "

人を動かす

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

« 2005年10月16日 - 2005年10月22日 | トップページ | 2005年10月30日 - 2005年11月5日 »