プログラマのための「コミュニケーションを円滑化するコツ」 86
ストーリー by makeplex
結局はそこですよ、 部門より
結局はそこですよ、 部門より
insiderman 曰く、
マイコミジャーナルにて、「プログラミングは得意でもコミュニケーションは苦手?」という記事が掲載されている。元ネタは「Sometimes, The Better You Program, The Worse You Communicate」というsecretGeekの記事。
secretGeekの記事は、「プログラミングは上手いがコミュニケーションは下手」という人間がしばしばいることに触れ、「プログラミングにおいて良いといわれていることをコミュニケーションに当てはまると悪いことになる」という例を紹介するもの。紹介されているのは下記の4つ。
- D.R.Y. Does Not Apply. — D.R.Y（don't repeat yourself、同じことを繰り返すな）ということは（人間には）適用するな。初めて行うことは失敗しやすいから何回も同じことを繰り返したほうがよい、
- Humans don't mean what they say. — 人間は喋っているとおりには考えていない。プログラマなら間違ったことを喋っている人に対しそれを指摘したくなるかもしれない。しかし、それは賢さの若干のアピールになるかもしれないが、「いまいましいバカ野郎」という風にも思われてしまうだろう。
- Programs don't need to see an example. — プログラムは例を必要としない。しかし、人間には必要だ。例を与えて絵を描いてまた例を与えてまた別の絵を描いて……と苦労してやっと相手に自分が何を言いたいかを伝えられるのである。例を与えることなしに物事を伝えて相手が理解してくれなくても、キレてはいけない。コンピュータは人間がキレても気にしないが、人間はそうではない。
- Programs love definitions; Humans get flummoxed. — プログラムは定義が大好きだが、人間は定義で混乱する。プログラマではない人々の前で新しい物事や言葉を定義するな。彼らは思考停止して週末をどうやって過ごすかを考え始めてしまう。
以上を踏まえ、記事では4つの「Stop」と1つの「Start」を、コミュニケーションのコツとしてあげている。
- Stop defining new terms — 新しい物事や単語を定義するな
- Stop striving for brevity and conciseness — 簡潔にしようと努力するな
- Stop correcting other people — 他人の誤りを正すな
- Stop expecting people to understand you first time around — 一回で物事を理解することを他人に期待するな
- Start giving examples — 例題を与えよう
おっと (スコア:5, おもしろおかしい)
kusakabeさんの悪口はそこまでだ。
妖精哲学の三信
「だらしねぇ」という戒めの心、「歪みねぇ」という賛美の心、「仕方ない」という許容の心
Re:おっと (スコア:1, 参考になる)
だった頃、NetNewsでは、有名人でしたよ。
己の日本語レベルは高くない (スコア:3, すばらしい洞察)
自分に大甘で他人に激辛なことやってりゃ、コミュニケーションなんぞ成り立たん。
#自分ではきちんとした日本語話してるつもりだろうが、他人から見れば大したこと無いのだ。
自己言及の罠 (スコア:3, おもしろおかしい)
# 「正しい意見表明の仕方」的なストーリーに意見表明をするのは緊張します・・・。
Re:直感的に最もダメだと思った例 (スコア:2, 興味深い)
でもその人は直接会うといい人なんですよ。
技術的にもコミュニケーション的にも、文句無い能力の持ち主ですし。
【参考】敵を知り己を知れれば．．． (スコア:3, 参考になる)
管理職のためのハッカー FAQ [yamdas.org]
Re:【参考】敵を知り己を知れれば．．． (スコア:1, 参考になる)
日本人向けにはこっち [vector.co.jp]の方が参考になると思います。
Re:【参考】敵を知り己を知れれば．．． (スコア:1)
2chのコピペを延々読まされているような感じで読んでいて飽きてきます。こういうのは上のラブレターみたいに最初の何項目かだけやって「あとは皆さんやってね」と書く方がベターですね。
Best regards, でぃーすけ
Cじゃ無いんだから (スコア:2)
順番にサブルーチンを定義して最後にmain関数、みたいな構成で
人間に宛てたメールを書くのは止めて欲しい、と思うことはあります。
プロトタイプ宣言 (スコア:1)
プロトタイプ宣言が無いとつらいですね．
main を最初に書こうとすると，
やはりプロトタイプ宣言は無いと・・・
って，それは「Stop defining new terms」に反するのかな．
ここで宣言と定義は違います，と説明し始めるとだめなんだろう．
屍体メモ [windy.cx]
Re: (スコア:0)
Re:プロトタイプ宣言 (スコア:3, おもしろおかしい)
// ここまで作って面倒になってきた上に、時間も無いので、
// 以下、各人がおのおのの思いのタケを書き綴ってもらいたい。
//// 何をつまらない長文ネタをぶっこいてるんだよ
//// と、思われるかもしれないが、この手の文書は、
//// 既婚カップルの間で、意外な効力があるかもしれない。
Re:プロトタイプ宣言 (スコア:1, おもしろおかしい)
論理性と冗長性は共存する (スコア:2)
話をするときに理論立って的確なことを言うのはビジネスに不可欠。
それをヤメろというのでは、他の方が仰っているように「デスマーチに突入」に繋がりかねないです。
ただ、情報処理業界でも冗長性というものが認められるように
話の中にも冗長性というものを盛り込むことで、わかりやすさがアップする事があると思います。
だから、決して相手を馬鹿にするのではなく、自分のためを思って
相手が進んでやりたくなるような、ウィットに富んだ会話を心がけるべきだと考えます。
# これはプログラマさんだけに限ったことでは決して無いです
## 今回の記事は「的確なアドバイスだなぁ」と思わされました。面白かったです。
目的が違う (スコア:2)
目的が違うのではと思うことがある
・正確な情報の伝達
・相手が自分に従うかどうか
・味方か敵か
・気持ち良いか、あるいは相手を気持ちよくしているか
とかあるんじゃないかと思う。
何を言っているんだ? (スコア:1)
これは「プログラム書くような奴はコミュニケーションに難がある」っていう刷り込み前提のような気がする．
それと「プログラミングは上手いがコミュニケーションは下手」という奴は居るのかな?
自分が会った中ではプログラミングが上手い奴は周りと円滑にコミュニケーション取れてたけど．
コミュニケーションが下手な奴は往々にしてプログラミングも駄目だった．
Re:何を言っているんだ? (スコア:2)
機械を操作するように、手順書を書くように、プログラミングするように、
そんな風に人に説明するとかえって理解してもらえないよ、ってことなんじゃないでしょうか。
きちんと丁寧に説明しようとすると、往々にしてそうなってしまいませんか。
Re:何を言っているんだ? (スコア:1, 興味深い)
> 自分が会った中ではプログラミングが上手い奴は周りと円滑にコミュニケーション取れてたけど．
その周りの方もまたプログラマや技術者だったのではないですか？
元記事は、自分と同じ素養を持たない者に対するコミュニケーション能力のことを言ってるような。
私の周辺には、元記事のような例が割と見られます。
学生時代、特に数学などの分野の教授で、本人は非常に優秀なのだが、話がわかりにくく
理解しづらい、っていう方もおられました。
思うに、「コミュニケーションが苦手」という性質は、数学やコンピュータサイエンスの分野
では、ある種の優性的な性質ではないか、と思うのです。
論理思考や集中力など、コミュニケーションと相反する面を持つ作業が得意なのですから。
アスペルガー症候群の者がしばし優秀な技術者であったりもするようです。
Re:何を言っているんだ? (スコア:1)
炊事場のスーザン・ボイル [livedoor.jp]という例がありまして。。
Re: (スコア:0)
*なんでも自分が正しくあるいは優れていて、すべての人は間違っているあるいは劣っていると思うな
Re: (スコア:0)
> コミュニケーションが下手な奴は往々にしてプログラミングも駄目だった．
「言語の癖」や「環境の癖」と同程度に「冷静かつフェア」に、
自分の言語表現の癖や、相手の理解の癖を理解しようと努めていれば、
コミュニケーションに支障をきたす事は無いと思います。
ただ、相手によって冷静に対応出来ないと言う事はあるかも知れませんね。
馬鹿だと割り切ってる部下には懇切丁寧に根気強く説明するけど、
高く評価している相手には無理めな振りをしてしまう、とか、
単純に「嫌いだからコミュニケーションをとらない」とか、
Re: (スコア:0)
>状況に応じてスキルを使い分けられるかどうか
はぁ？それって動的型変換とか暗黙の型変換とかをするって事？
そういうのってバグの温床になるから嫌なんだよね。PHP死ねよ。
冗談はともかく、
コミュニケーションというと、スキルを使い分けられる＝態度を変えるとか
敬語や気遣いと思われがちですが、実は質問力とか確認力の精度だと思います。
それは要するに「自分が解っているから相手も解っているとは限らない」事実、
自分と相手のモノサシを同一視して考えて対応しないという事じゃないかと。
相手の型が何か知り、自分の型が何か知ってもらうという事に熱心かというと、
肩書きが
まずはペアプログラミング (スコア:1)
Re:まずはペアプログラミング (スコア:1, おもしろおかしい)
ご希望に沿う品かどうか分かりませんが、
「一回で物事を理解することを他人に期待するな」 (スコア:1, すばらしい洞察)
by 山本 五十六
Re:「一回で物事を理解することを他人に期待するな」 (スコア:3, おもしろおかしい)
Re:「一回で物事を理解することを他人に期待するな」 (スコア:1)
一廉の人であったのは間違いないでしょう。
「そこまでやってもダメな奴はダメ」と見切るかか、
「やるべきことはやっているか」と自戒するか。
新人教育って難しい。
〜後悔先に立たず・後悔役に立たず・後悔後を絶たず〜
共感する部分はあるけど (スコア:1)
> 2. Humans don't mean what they say.
言ってることが間違えていても、正しいことを考えているはず・・・・って、大きく捉えすぎのような。
主たるコミュニケーション手段の会話が、言葉の間違いで成り立たない人はどうにもならない気がするのですが、そんなコトはないですか？
# 話の流れで、意志を読みとれって話なんだろうけど。
Re:共感する部分はあるけど (スコア:1, おもしろおかしい)
># 話の流れで、意志を読みとれって話なんだろうけど。
元文章を見る限りはもっとミクロ的な、要は「ちょっとした言い間違え」や
「(意味は通じるけど)正しくない言葉」について、スルーしろってことだと思われます。
例えば、
A「このマシンのIPは何？」
B「IPはプロトコルです」
みたい受け答えはやめましょうってことなんだと。
Re:共感する部分はあるけど (スコア:1, おもしろおかしい)
A「このマシンのIPは何？」
B「v6 ですがなにか」
A「えっ？」
B「えっ？」
みたいな会話を横で聞いたことがあります。
B さんは別に悪気があったわけではなさそうで。
Re:共感する部分はあるけど (スコア:1)
個人的には相手のデバッグをしろということかなと思っています。
なので間違いを発見するだけではまだ作業が終わってません。
なぜ、どのようにして相手が間違うかまで突き止めないと。
＃あとはそのうえで修正コストと損害を秤にかけて。
結局は (スコア:1, おもしろおかしい)
プログラマ(というか日本では理系人間)がコミュニケーションがうまくいかない理由って
そもそも相手方の方の理解力が低いからでしかないんですよね。
早い話が幼稚園児に説明するつもりで話せばいいんですよ。大げさな話じゃなく。
それだけ理解できるかどうかでずいぶん仕事も楽にはなるんですが。
いまいち腑に落ちないのは、能力の足りてない努力するべき側が努力を放棄して
「(理解するための努力をしない)私が理解できないのは、お前がわかりやすく説明する努力をしないからだ。
お前はコミュニケーション能力が低い。」
って言い分が平然と出てくる事なんですよね。
どっちが能力低いんだよ、と。
＃「えー、わかんなーい。説明とかいいから全部やっといて！ね(はぁと)」って言われる方がまだ潔い。
というかプログラマでも普段そうやってプログラムを書いているヒト多いよね？ (スコア:1)
1. D.R.Y. Does Not Apply. — D.R.Y（don't repeat yourself、同じことを繰り返すな）ということは（人間には）適用するな。初めて行うことは失敗しやすいから何回も同じことを繰り返したほうがよい、
というかプログラマもよく繰り返しちゃうよね？
それで後からメソッドや変数や共通の親クラスにくくりだしたりすることはよくあるよ。
2. Humans don't mean what they say. — 人間は喋っているとおりには考えていない。プログラマなら間違ったことを喋っている人に対しそれを指摘したくなるかもしれない。しかし、それは賢さの若干のアピールになるかもしれないが、「いまいましいバカ野郎」という風にも思われてしまうだろう。
というかプログラマも書いてるコードの通りには考えていないことがよくあるよね。
打った内容＝考えてた内容になっているならバグはもうちょっとは少ないはず。
3. Programs don't need to see an example. — プログラムは例を必要としない。しかし、人間には必要だ。例を与えて絵を描いてまた例を与えてまた別の絵を描いて……と苦労してやっと相手に自分が何を言いたいかを伝えられるのである。例を与えることなしに物事を伝えて相手が理解してくれなくても、キレてはいけない。コンピュータは人間がキレても気にしないが、人間はそうではない。
というかプログラマも例を必要とするよね？
ループや再帰を3まで回してみて処理や終了条件を考えたりするよね。具象オブジェクトを幾つか書いて後から抽象オブジェクト書いたりインターフェース作るのもよくあることだし。
4. Programs love definitions; Humans get flummoxed. — プログラムは定義が大好きだが、人間は定義で混乱する。プログラマではない人々の前で新しい物事や言葉を定義するな。彼らは思考停止して週末をどうやって過ごすかを考え始めてしまう。
というかプログラマもよく定義を飛ばすよね。
定義が明確でなくてなんとなくメソッドや関数やサブルーチンの動作で実質意味が決まってるコードなんて珍しくもなんともないよね。
どっちかというと後でメンテが辛くなってコードを整理する努力を開始してようやく定義がすっきりとなされるなんてありがちなプロセスだよね。
…つまりリファクタリングはプログラム開発においてもコミュニケーションにおいても自然なプロセスである！（か？ｗ）
＃実のところプログラムはマシン及び将来のメンテナンス担当者とのコミュニケーションだからという考え方もあるしね。
そう言われてもなぁ…… (スコア:1)
それって、デスマや、「言った」「言ってない」の水かけ論を、引き起こす方法ですか？
と思ってしまうのも、プログラマの性(さが)なんじゃなかろうか。
一言で言うと (スコア:0, フレームのもと)
一言で言うと「聞き手は馬鹿だと思え」
Re:一言で言うと (スコア:3, すばらしい洞察)
・新しい物事を定義するなら先ずそれを伝えることに手間をかける覚悟が必要と気づけ
・説明の手間を省くために簡潔にしようと努力することは程度を超えると本末転倒だろ
・君でも気づくような他人の誤りなら本人だって言った側から気づいてるんじゃね
・一回で物事を説明できるような能力を自分に期待するなよ
・もしそんな能力があるなら例題ぐらいすぐ思いつけるだろ
という旨の指摘を，プライドだけが妙に強い人に，遠まわしに伝えようとするなら，
「聞き手って馬鹿なんですよねえ（笑）」という言い方になりますかね。
Re:一言で言うと (スコア:2)
ダウト。
他人がそんな完璧に全ての問題点に気付けることを期待するからには、
自分も完璧に全ての問題点に気付けなければならない。
しかしながら、自分は色々な点を見落していることを自覚している。してなきゃバカだ。
したがって、他人が気付いていることを期待するのは危険だ。
Re:一言で言うと (スコア:3, おもしろおかしい)
あ、簡潔にしちゃった
Re:一言で言うと (スコア:1)
* Stop striving for brevity and conciseness — 簡潔にしようと努力するな
でおｋ
「聞き手は馬鹿だと思え」だけで5項が全て把握できるなら別ですが。
Re:一言で言うと (スコア:1)
馬鹿とまでは言いませんが、相手に物事を伝えるときは幼稚園児だと思っています。
＃特にドキュメント類
そう思えば腹も立たないでしょ？
Re:一言で言うと (スコア:2, 参考になる)
「発表の時は、お母さん、もしくは彼女に説明すると思って発表しなさい」
と指導を受けた事があり、妙に納得。
Re:一言で言うと (スコア:1)
でも、田嶋センセにわかるように説明出来たら、
きっとお母さんにも彼女にも伝わると思ったり思わなかったり。
Re:一言で言うと (スコア:1)
＞一言で言うと「聞き手は馬鹿だと思え」
相手もその様に（説明ができない）思うかもしれないので、レベリングが必要でしょうね。
相手の様子を見ながらレベルを上げ下げしながら話すようにしています。
専門知識なので、
知ってる＝天才（適当な馬鹿の反対語が見つからなかった）
知らない＝馬鹿
とは言えないのです。
と言うことで、
＞* Stop striving for brevity and conciseness — 簡潔にしようと努力するな
＞* Stop expecting people to understand you first time around — 一回で物事を理解することを他人に期待するな
が出てくるんでしょうね。
相手の理解度を確認しながらレベルを変えて説明を繰り返す必要はあります。
＞* Start giving examples — 例題を与えよう
この例は相手からも（見当違いかもしれないけど）例を挙げて確認してくるかもしれません。
その時に自分にも例がないと話が平行線になる事あるかと思います。
具体的なイメージは必要ですね、
最後に、違和感があるのは
＞* Stop correcting other people — 他人の誤りを正すな
これです。
相手に正しく伝える事が目的なので、致命的でない所はスルーでいいでしょうけど、
基本的には指摘/確認は必要だと思っています。
# 営業さんってコミュニケーションが得意と言うことになっているけど、
# 本当にそうなのかな？ と思う今日この頃。
Re:一言で言うと (スコア:1)
＞他人の誤りを正すな
誤りだと思っても、そう信じるに至った理由や状況があるはずだから、頭から「誤り」と決め付けるな。
ってことじゃない？
the.ACount
Re:一言で言うと (スコア:1)
同意
# コンパイラのエラーレベルを変えろって事ですかね。
# ちと違うか・・・
Re:一言で言うと (スコア:1)
＞聞き手は馬鹿だと思え
対して「人の振り見て我が振り直せ」
そんなこと言われたって、初めて聞くことを１回で理解するなんて出来っこない。
the.ACount
まず、金を渡してみよ (スコア:0)
StopがSTEPに見えて (スコア:0)
STEPの5つのNO! [wdic.org]を思い出す。
汽水界 (スコア:0)
コミュニケーションの対象たる人間が
IT業界に自分以外一人も居ないのなら、
べつにそれでも構わないのですが、
不幸にして業界内つまり職場にも「人間」は居るんですよね。
で、そういった人間とコミュニケーションする方法として…
>他人の誤りを正すな
あーデスマで燃え死ねということですね。わかりますorz
だいたいお分かりかとは思いますが、
不幸は「自分と計算機の間に入り込んでいる人間」が居るという点なんです。
完全に人間用の扱いだけをするとその向こう側の計算機が動かなくなる。
計算機にターゲットを絞れば間の人間がキレル。
どっちつかずの中間の態度でも両方が旨く動かなくなるだけで効果なし。
Re:定義 (スコア:1, おもしろおかしい)