アカウント名:
パスワード:
今の職場でうぜえと思っている文化なのだが、とある問題について、それが他にどう影響するのか、自分なり他人がそれについていつまでに何をしなければならないのかという観点がないままに、問題の経緯だけを何分もぐずぐず話しつづけたりする。特定の人間の問題ではなく、複数人いるのでどうもそこの文化らしい。経緯に時間をかけるな結論を言えと遮ると、一生懸命話しているのに何を言うんだという顔をされる。#現代のITの会社なのかそこはと思う。
というか、そもそも、話して数分かかるものは誰も全ては聞いてないし、話しても後に残らないんだから、記録して管理しろと言っても聞かない。最近、気がついたのだが、意識しているのかしてないのかわからないけど、要するに結論を用意していない、もしくは自分で結論を出したくない、後に残したくないだけなんだけどね。
しかも、ファイル名、関数名、変数名などを口頭で伝える事をおかしいと思わない....。
コミュニケーションスキルが高いこと=よく喋ることと見られていると、そういう人間はスキルが高いと見られてるのかなあとうんざりします。
> 話して数分かかるものは誰も全ては聞いてないし、
たかだか数分程度の話しぐらい身を入れて聞けばいいのに。
> しかも、ファイル名、関数名、変数名などを口頭で伝える事をおかしいと思わない....。
数個程度であれば、その場でメモを取り出してスペルを確認しながら書けばいい。で、その場で相手にメモを確認させればいい。
このやり取りが面倒くさいと相手が思えば、自然と資料を用意するようになる。
身を入れて相手の話を聞き、わからなかったり正確に聞き取る必要があることはその場で確認するためということができない人間は、どこでも「コミュニケーション能力のないやつだ」と思われる。
そしてその評価は正しい。
元コメがどんな職場にいるのか分からんから、問題の緊急性や規模がどの程度まで行くのか分からんけど。
ぶっちゃけ、結論を用意してない人間の話なんて身を入れて聞いた所で何の足しにもならんし、そもそも関数名をメモってくる知恵さえ持たない人間の記憶力なんて当てにするだけ無駄。「話しても後に残らないんだから、記録して管理しろ」ってのは至極真っ当だと思うけど。
というか、口頭で話を持って行く場合は、許可を得るなら「こういう問題が起きていてこういう対応が必要なので、承認下さい」、相談なら「こういう問題があって対応に悩んでいるので相談させて下さい」っつー結論を先に伝えておかないと、相手は自分が何をしたらいいのか話から類推するって言う無駄な労力を割くことになる。それが出来ない人間からのヒアリングもコミュニケーションスキルの一つではあるんだろうが、そればっかり求められてもなぁ……
>たかだか数分程度の話しぐらい身を入れて聞けばいいのに。
さて、ここで問題です。数人のミーティングで各人が各自数個の課題に対してそれをやると消費される時間はどれくらいになるでしょうか?結果としてまったく関係ない人たちに対しても同様に時間を費やさせる事に良心の呵責は感じませんか?
>> しかも、ファイル名、関数名、変数名などを口頭で伝える事をおかしいと思わない....。
>数個程度であれば、その場でメモを取り出してスペルを確認しながら書けばいい。>で、その場で相手にメモを確認させればいい。
さて、ここで問題です。あなたの目の前の箱は何のために使うのですか?(箱という言葉自体は慣用句なので、まあ勘弁してください)情報を劣化させる可能性のある行為を他人に繰り返させる事に対して良心の呵責は感じませんか?非IT系の業種ならある程度はしかたないかなあと思わんでもないけど、名実ともにITな会社らしいんでなんだそりゃと思う。
単に無能な人間が集まってるだけのような…染まらないように気をつけてね。
上司や同僚と仲良くする=コミュニケーションスキルだよ。特に上司を説教するのだけはやめたほうがいい。意見を積極的に発言するのを評価するとか言われても、真に受けないように。
部下を指導して良くしていくというのはやるべきだけど、同僚以上は無駄だし報われないので、諦めるか別のところへ行くべきだと思う。
求められているのが「問題解決」でなく「会話」そのものだから#対女性との対話でもそうらしい
問題解決用の会話というのもあるはずだが、それは察しろといわれる…
>>コミュニケーションスキルが高いこと=よく喋ることと見られていると
日本でのコミュニケーションスキルは大多数の意見と同じ事を言う事、その大多数の意見をリードできる人だったりする。その意見が正しいかどうかなんて関係ない。
コンピュータの世界でも多数決や政治力はあってデファクトスタンダートに合わせたり多機種・多アプリの挙動を調査して折衷案で実装したりしてる
対象が異なるだけでプログラマーはコミュニケーションばっかりやってる職業じゃないかな言語を操ってプロトコルやフォーマットに従いデータを送受信するわけで
トピ主はソースにコメント書く位の気軽さで人と雑談すればいい
有能な営業は客と雑談ばかりしているというが客と対面しない他の職種でも無駄ではないと思ってるスラドなんて雑談サイトだ
私も業務と関係ない技術の調査してもなぜか役に立ったりする(ときもある)し
それは危険だ。否定的なコメントばかりになる。
むしろ何も言えなくなるので危険
>トピ主はソースにコメント書く位の気軽さで>人と雑談すればいい
多分ねー。そういうだらだらしゃべる人が書くコメントって
/*1を代入する*/int coin = 1;
とかそういうコメントのような気がする。#コインいっこいれるとか書きたくなるけど
/* ここまで読んだ */
結論だけ言え、とよく言うけど、その人の判断が間違ってて結論も誤っている事ってままある。
> 話しても後に残らないんだから、記録して管理しろと言っても聞かない。議事録的にまとめを残しておくのは良いと思うが、そんなのは糞で、リアルタイムに対面でコミュニケーションする事に最大の意義があると思う。
「結論を先に言え」ってのはよく聞くけど、「結論だけを言え」ってのは聞かないなあ。よっぽど簡単な問題なら別だけど。
「結論を先に言え」とせっつく人にあわせてると、「何でそんなことになったんだ」の逆向きトークになって面倒な時ありますね。
まずタイトル、つぎにダイジェスト、最後に具体的詳説、プログレッシブモードで報告したほうが聞く側もコンテキストを共有しやすいけど話の枝葉に噛み付いていちいち脱線したがる人にはそれも難しい。
それ、逆にはなってないよね。元々、そういう順番で話そうとしてたわけだから。
理由を聞こうとしない人はたまにいて、そういうのは困るけど。
>「何でそんなことになったんだ」の逆向きトークになって面倒な時ありますね。
そうですねえ。あまりに斜め上の結論なり、状況になっていて、踊っているAAが頭をぐるぐる回る事がありますね。現実歪曲空間とはこの事かと。
RDBってよくわからないから全部CSVと実ファイルで管理したいとお客さんが言ったと思われる(多分、作る人間も詳しくなかったらしい)→バックアップとかよくわからないので二重化も作り込め→パフォーマンスが低いのでサーバを多重化するけど、どうすればいいかわからないので作り込め
で、できあがったと思われるシステムが目の前にあります。異常系とか考えてないみたいで、データに不整合があったら全面的に動かないんだけど...。
>結論だけ言え、とよく言うけど、その人の判断が間違ってて結論も誤っている事ってままある。で、その結論の妥当性の判断および、修正、承認がミーティングの場をもうける理由なわけですよ。疑念があればその場でその根拠を確認するわけで。ある事柄に対して、自分なりの見解および判断を持てない人とみなすなんて、メンバーに対してそんな失礼な事はできないですねえ。
>リアルタイムに対面でコミュニケーションする事に最大の意義があると思う。が、口頭という手段はレスポンスタイムは最高だが、情報伝達の手段としてはスループットおよびS/N比が悪い(痕跡が残らないなど、もっと欠点はある。というか、レスポンスタイムしか利点がないのではないか?)ので、やりとりする情報は最小限にすべきであると言えます。大体、ベストな方法はドキュメントドリブンで行い、承認/決定の有無、その時点でドキュメント未記入の情報のみ口頭でやりとりする(すみやかにドキュメントにフィードバックする)でFAじゃないかと思いますが。
結論ってそういう意味じゃないですよ。最終決定という意味の結論を持ってるなら相談する意味がないじゃないですか。「ここが不明確です」「ここを助けて欲しい」という、結論というか話の主題の事を指すでしょう。
「ここを助けて欲しい」と示してから、現在の到達点や経緯を話さなきゃダメ、ママに泣きついてるのとはわけが違うんだから。大元のコメントも、自分のコミュニケーションスキルに疑問を持ってるわけじゃなく、周囲の人間にコミュニケーション能力が無いと嘆いているわけでしょ。
あと、「記録して管理」は絶対やらないといけない、お仕事なんですから言質をとるっていうのは絶対に必要な行動ですよ。リアルタイムに対面でコミュニケーションを取ったら、特に決定事項が含まれる場合はその内容をまとめてプロジェクト全員に見える所に置きましょう。
# 自分の社会人人生の中で、全部議論の余地が無い事柄ばかりなんですが...。
口頭で指示が飛ぶようになったら
残念ながら、君はリストラの対象だと思えいくら君がメモを取ろうが、上司にメモを確認してもらおうが数日後「そんなことは言っていない」で始末書を書かせられ減給もしくは出勤停止メールでなければ、証拠にはならない。怒鳴り合いになって、肩を持たれるのは上司やSEなのよ世の中
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
情報伝達の手段の特性を意識しろ (スコア:1)
今の職場でうぜえと思っている文化なのだが、
とある問題について、それが他にどう影響するのか、自分なり他人がそれについていつまでに何をしなければならないのかという観点がないままに、問題の経緯だけを何分もぐずぐず話しつづけたりする。
特定の人間の問題ではなく、複数人いるのでどうもそこの文化らしい。
経緯に時間をかけるな結論を言えと遮ると、一生懸命話しているのに何を言うんだという顔をされる。
#現代のITの会社なのかそこはと思う。
というか、そもそも、話して数分かかるものは誰も全ては聞いてないし、話しても後に残らないんだから、記録して管理しろと言っても聞かない。
最近、気がついたのだが、意識しているのかしてないのかわからないけど、要するに結論を用意していない、もしくは自分で結論を出したくない、後に残したくないだけなんだけどね。
しかも、ファイル名、関数名、変数名などを口頭で伝える事をおかしいと思わない....。
コミュニケーションスキルが高いこと=よく喋ることと見られていると、そういう人間はスキルが高いと見られてるのかなあとうんざりします。
Re:情報伝達の手段の特性を意識しろ (スコア:2, すばらしい洞察)
> 話して数分かかるものは誰も全ては聞いてないし、
たかだか数分程度の話しぐらい身を入れて聞けばいいのに。
> しかも、ファイル名、関数名、変数名などを口頭で伝える事をおかしいと思わない....。
数個程度であれば、その場でメモを取り出してスペルを確認しながら書けばいい。
で、その場で相手にメモを確認させればいい。
このやり取りが面倒くさいと相手が思えば、自然と資料を用意するようになる。
身を入れて相手の話を聞き、わからなかったり正確に聞き取る必要が
あることはその場で確認するためということができない人間は、
どこでも「コミュニケーション能力のないやつだ」と思われる。
そしてその評価は正しい。
Re:情報伝達の手段の特性を意識しろ (スコア:5, 興味深い)
元コメがどんな職場にいるのか分からんから、問題の緊急性や規模がどの程度まで行くのか分からんけど。
ぶっちゃけ、結論を用意してない人間の話なんて身を入れて聞いた所で何の足しにもならんし、
そもそも関数名をメモってくる知恵さえ持たない人間の記憶力なんて当てにするだけ無駄。
「話しても後に残らないんだから、記録して管理しろ」ってのは至極真っ当だと思うけど。
というか、口頭で話を持って行く場合は、許可を得るなら「こういう問題が起きていてこういう対応が必要なので、承認下さい」、
相談なら「こういう問題があって対応に悩んでいるので相談させて下さい」っつー結論を先に伝えておかないと、
相手は自分が何をしたらいいのか話から類推するって言う無駄な労力を割くことになる。
それが出来ない人間からのヒアリングもコミュニケーションスキルの一つではあるんだろうが、そればっかり求められてもなぁ……
Re: (スコア:0)
>たかだか数分程度の話しぐらい身を入れて聞けばいいのに。
さて、ここで問題です。
数人のミーティングで各人が各自数個の課題に対してそれをやると消費される時間はどれくらいになるでしょうか?
結果としてまったく関係ない人たちに対しても同様に時間を費やさせる事に良心の呵責は感じませんか?
>> しかも、ファイル名、関数名、変数名などを口頭で伝える事をおかしいと思わない....。
>数個程度であれば、その場でメモを取り出してスペルを確認しながら書けばいい。
>で、その場で相手にメモを確認させればいい。
さて、ここで問題です。
あなたの目の前の箱は何のために使うのですか?(箱という言葉自体は慣用句なので、まあ勘弁してください)
情報を劣化させる可能性のある行為を他人に繰り返させる事に対して良心の呵責は感じませんか?
非IT系の業種ならある程度はしかたないかなあと思わんでもないけど、名実ともにITな会社らしいんでなんだそりゃと思う。
Re:情報伝達の手段の特性を意識しろ (スコア:1)
単に無能な人間が集まってるだけのような…
染まらないように気をつけてね。
the.ACount
Re:情報伝達の手段の特性を意識しろ (スコア:1)
上司や同僚と仲良くする=コミュニケーションスキルだよ。
特に上司を説教するのだけはやめたほうがいい。
意見を積極的に発言するのを評価するとか言われても、真に受けないように。
部下を指導して良くしていくというのはやるべきだけど、
同僚以上は無駄だし報われないので、諦めるか別のところへ行くべきだと思う。
Re:情報伝達の手段の特性を意識しろ (スコア:1)
求められているのが「問題解決」でなく「会話」そのものだから
#対女性との対話でもそうらしい
問題解決用の会話というのもあるはずだが、それは察しろといわれる…
Re: (スコア:0)
>>コミュニケーションスキルが高いこと=よく喋ることと見られていると
日本でのコミュニケーションスキルは大多数の意見と同じ事を言う事、
その大多数の意見をリードできる人だったりする。
その意見が正しいかどうかなんて関係ない。
Re: (スコア:0)
コンピュータの世界でも多数決や政治力はあって
デファクトスタンダートに合わせたり
多機種・多アプリの挙動を調査して折衷案で実装したりしてる
対象が異なるだけでプログラマーは
コミュニケーションばっかりやってる職業じゃないかな
言語を操ってプロトコルやフォーマットに従い
データを送受信するわけで
トピ主はソースにコメント書く位の気軽さで
人と雑談すればいい
有能な営業は客と雑談ばかりしているというが
客と対面しない他の職種でも無駄ではないと思ってる
スラドなんて雑談サイトだ
私も業務と関係ない技術の調査しても
なぜか役に立ったりする(ときもある)し
Re:情報伝達の手段の特性を意識しろ (スコア:3)
それは危険だ。
否定的なコメントばかりになる。
Re: (スコア:0)
むしろ何も言えなくなるので危険
Re: (スコア:0)
>トピ主はソースにコメント書く位の気軽さで
>人と雑談すればいい
多分ねー。そういうだらだらしゃべる人が書くコメントって
/*1を代入する*/
int coin = 1;
とかそういうコメントのような気がする。
#コインいっこいれるとか書きたくなるけど
Re: (スコア:0)
>トピ主はソースにコメント書く位の気軽さで
>人と雑談すればいい
/* ここまで読んだ */
Re: (スコア:0)
結論だけ言え、とよく言うけど、その人の判断が間違ってて結論も誤っている事ってままある。
> 話しても後に残らないんだから、記録して管理しろと言っても聞かない。
議事録的にまとめを残しておくのは良いと思う
が、そんなのは糞で、
リアルタイムに対面でコミュニケーションする事に最大の意義があると思う。
Re:情報伝達の手段の特性を意識しろ (スコア:1)
結論だけ言え、とよく言うけど、その人の判断が間違ってて結論も誤っている事ってままある。
「結論を先に言え」ってのはよく聞くけど、「結論だけを言え」ってのは聞かないなあ。よっぽど簡単な問題なら別だけど。
Re: (スコア:0)
「結論を先に言え」とせっつく人にあわせてると、
「何でそんなことになったんだ」の逆向きトークになって面倒な時ありますね。
まずタイトル、つぎにダイジェスト、最後に具体的詳説、
プログレッシブモードで報告したほうが聞く側もコンテキストを共有しやすいけど
話の枝葉に噛み付いていちいち脱線したがる人にはそれも難しい。
Re:情報伝達の手段の特性を意識しろ (スコア:1)
「結論を先に言え」とせっつく人にあわせてると、
「何でそんなことになったんだ」の逆向きトークになって面倒な時ありますね。
それ、逆にはなってないよね。元々、そういう順番で話そうとしてたわけだから。
理由を聞こうとしない人はたまにいて、そういうのは困るけど。
Re: (スコア:0)
>「何でそんなことになったんだ」の逆向きトークになって面倒な時ありますね。
そうですねえ。あまりに斜め上の結論なり、状況になっていて、踊っているAAが頭をぐるぐる回る事がありますね。
現実歪曲空間とはこの事かと。
RDBってよくわからないから全部CSVと実ファイルで管理したいとお客さんが言ったと思われる(多分、作る人間も詳しくなかったらしい)
→バックアップとかよくわからないので二重化も作り込め
→パフォーマンスが低いのでサーバを多重化するけど、どうすればいいかわからないので作り込め
で、できあがったと思われるシステムが目の前にあります。
異常系とか考えてないみたいで、データに不整合があったら全面的に動かないんだけど...。
Re: (スコア:0)
>結論だけ言え、とよく言うけど、その人の判断が間違ってて結論も誤っている事ってままある。
で、その結論の妥当性の判断および、修正、承認がミーティングの場をもうける理由なわけですよ。
疑念があればその場でその根拠を確認するわけで。
ある事柄に対して、自分なりの見解および判断を持てない人とみなすなんて、メンバーに対してそんな失礼な事はできないですねえ。
>リアルタイムに対面でコミュニケーションする事に最大の意義があると思う。
が、口頭という手段はレスポンスタイムは最高だが、情報伝達の手段としてはスループットおよびS/N比が悪い(痕跡が残らないなど、もっと欠点はある。というか、レスポンスタイムしか利点がないのではないか?)ので、
やりとりする情報は最小限にすべきであると言えます。
大体、ベストな方法はドキュメントドリブンで行い、承認/決定の有無、その時点でドキュメント未記入の情報のみ口頭でやりとりする(すみやかにドキュメントにフィードバックする)でFAじゃないかと思いますが。
Re: (スコア:0)
結論ってそういう意味じゃないですよ。最終決定という意味の結論を持ってるなら相談する意味がないじゃないですか。
「ここが不明確です」「ここを助けて欲しい」という、結論というか話の主題の事を指すでしょう。
「ここを助けて欲しい」と示してから、現在の到達点や経緯を話さなきゃダメ、ママに泣きついてるのとはわけが違うんだから。
大元のコメントも、自分のコミュニケーションスキルに疑問を持ってるわけじゃなく、周囲の人間にコミュニケーション能力が無いと嘆いているわけでしょ。
あと、「記録して管理」は絶対やらないといけない、お仕事なんですから言質をとるっていうのは絶対に必要な行動ですよ。
リアルタイムに対面でコミュニケーションを取ったら、特に決定事項が含まれる場合はその内容をまとめてプロジェクト全員に見える所に置きましょう。
# 自分の社会人人生の中で、全部議論の余地が無い事柄ばかりなんですが...。
Re: (スコア:0)
口頭で指示が飛ぶようになったら
残念ながら、君はリストラの対象だと思え
いくら君がメモを取ろうが、上司にメモを確認してもらおうが
数日後「そんなことは言っていない」で始末書を書かせられ減給もしくは出勤停止
メールでなければ、証拠にはならない。
怒鳴り合いになって、肩を持たれるのは上司やSEなのよ世の中