アカウント名:
パスワード:
今の職場でうぜえと思っている文化なのだが、とある問題について、それが他にどう影響するのか、自分なり他人がそれについていつまでに何をしなければならないのかという観点がないままに、問題の経緯だけを何分もぐずぐず話しつづけたりする。特定の人間の問題ではなく、複数人いるのでどうもそこの文化らしい。経緯に時間をかけるな結論を言えと遮ると、一生懸命話しているのに何を言うんだという顔をされる。#現代のITの会社なのかそこはと思う。
というか、そもそも、話して数分かかるものは誰も全ては聞いてないし、話し
結論だけ言え、とよく言うけど、その人の判断が間違ってて結論も誤っている事ってままある。
> 話しても後に残らないんだから、記録して管理しろと言っても聞かない。議事録的にまとめを残しておくのは良いと思うが、そんなのは糞で、リアルタイムに対面でコミュニケーションする事に最大の意義があると思う。
「結論を先に言え」ってのはよく聞くけど、「結論だけを言え」ってのは聞かないなあ。よっぽど簡単な問題なら別だけど。
「結論を先に言え」とせっつく人にあわせてると、「何でそんなことになったんだ」の逆向きトークになって面倒な時ありますね。
まずタイトル、つぎにダイジェスト、最後に具体的詳説、プログレッシブモードで報告したほうが聞く側もコンテキストを共有しやすいけど話の枝葉に噛み付いていちいち脱線したがる人にはそれも難しい。
それ、逆にはなってないよね。元々、そういう順番で話そうとしてたわけだから。
理由を聞こうとしない人はたまにいて、そういうのは困るけど。
>「何でそんなことになったんだ」の逆向きトークになって面倒な時ありますね。
そうですねえ。あまりに斜め上の結論なり、状況になっていて、踊っているAAが頭をぐるぐる回る事がありますね。現実歪曲空間とはこの事かと。
RDBってよくわからないから全部CSVと実ファイルで管理したいとお客さんが言ったと思われる(多分、作る人間も詳しくなかったらしい)→バックアップとかよくわからないので二重化も作り込め→パフォーマンスが低いのでサーバを多重化するけど、どうすればいいかわからないので作り込め
で、できあがったと思われるシステムが目の前にあります。異常系とか考えてないみたいで、データに不整合があったら全面的に動かないんだけど...。
>結論だけ言え、とよく言うけど、その人の判断が間違ってて結論も誤っている事ってままある。で、その結論の妥当性の判断および、修正、承認がミーティングの場をもうける理由なわけですよ。疑念があればその場でその根拠を確認するわけで。ある事柄に対して、自分なりの見解および判断を持てない人とみなすなんて、メンバーに対してそんな失礼な事はできないですねえ。
>リアルタイムに対面でコミュニケーションする事に最大の意義があると思う。が、口頭という手段はレスポンスタイムは最高だが、情報伝達の手段としてはスループットおよびS/N比が悪い(痕跡が残らないなど、もっと欠点はある。というか、レスポンスタイムしか利点がないのではないか?)ので、やりとりする情報は最小限にすべきであると言えます。大体、ベストな方法はドキュメントドリブンで行い、承認/決定の有無、その時点でドキュメント未記入の情報のみ口頭でやりとりする(すみやかにドキュメントにフィードバックする)でFAじゃないかと思いますが。
結論ってそういう意味じゃないですよ。最終決定という意味の結論を持ってるなら相談する意味がないじゃないですか。「ここが不明確です」「ここを助けて欲しい」という、結論というか話の主題の事を指すでしょう。
「ここを助けて欲しい」と示してから、現在の到達点や経緯を話さなきゃダメ、ママに泣きついてるのとはわけが違うんだから。大元のコメントも、自分のコミュニケーションスキルに疑問を持ってるわけじゃなく、周囲の人間にコミュニケーション能力が無いと嘆いているわけでしょ。
あと、「記録して管理」は絶対やらないといけない、お仕事なんですから言質をとるっていうのは絶対に必要な行動ですよ。リアルタイムに対面でコミュニケーションを取ったら、特に決定事項が含まれる場合はその内容をまとめてプロジェクト全員に見える所に置きましょう。
# 自分の社会人人生の中で、全部議論の余地が無い事柄ばかりなんですが...。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
情報伝達の手段の特性を意識しろ (スコア:1)
今の職場でうぜえと思っている文化なのだが、
とある問題について、それが他にどう影響するのか、自分なり他人がそれについていつまでに何をしなければならないのかという観点がないままに、問題の経緯だけを何分もぐずぐず話しつづけたりする。
特定の人間の問題ではなく、複数人いるのでどうもそこの文化らしい。
経緯に時間をかけるな結論を言えと遮ると、一生懸命話しているのに何を言うんだという顔をされる。
#現代のITの会社なのかそこはと思う。
というか、そもそも、話して数分かかるものは誰も全ては聞いてないし、話し
Re:情報伝達の手段の特性を意識しろ (スコア:0)
結論だけ言え、とよく言うけど、その人の判断が間違ってて結論も誤っている事ってままある。
> 話しても後に残らないんだから、記録して管理しろと言っても聞かない。
議事録的にまとめを残しておくのは良いと思う
が、そんなのは糞で、
リアルタイムに対面でコミュニケーションする事に最大の意義があると思う。
Re:情報伝達の手段の特性を意識しろ (スコア:1)
結論だけ言え、とよく言うけど、その人の判断が間違ってて結論も誤っている事ってままある。
「結論を先に言え」ってのはよく聞くけど、「結論だけを言え」ってのは聞かないなあ。よっぽど簡単な問題なら別だけど。
Re: (スコア:0)
「結論を先に言え」とせっつく人にあわせてると、
「何でそんなことになったんだ」の逆向きトークになって面倒な時ありますね。
まずタイトル、つぎにダイジェスト、最後に具体的詳説、
プログレッシブモードで報告したほうが聞く側もコンテキストを共有しやすいけど
話の枝葉に噛み付いていちいち脱線したがる人にはそれも難しい。
Re:情報伝達の手段の特性を意識しろ (スコア:1)
「結論を先に言え」とせっつく人にあわせてると、
「何でそんなことになったんだ」の逆向きトークになって面倒な時ありますね。
それ、逆にはなってないよね。元々、そういう順番で話そうとしてたわけだから。
理由を聞こうとしない人はたまにいて、そういうのは困るけど。
Re: (スコア:0)
>「何でそんなことになったんだ」の逆向きトークになって面倒な時ありますね。
そうですねえ。あまりに斜め上の結論なり、状況になっていて、踊っているAAが頭をぐるぐる回る事がありますね。
現実歪曲空間とはこの事かと。
RDBってよくわからないから全部CSVと実ファイルで管理したいとお客さんが言ったと思われる(多分、作る人間も詳しくなかったらしい)
→バックアップとかよくわからないので二重化も作り込め
→パフォーマンスが低いのでサーバを多重化するけど、どうすればいいかわからないので作り込め
で、できあがったと思われるシステムが目の前にあります。
異常系とか考えてないみたいで、データに不整合があったら全面的に動かないんだけど...。
Re: (スコア:0)
>結論だけ言え、とよく言うけど、その人の判断が間違ってて結論も誤っている事ってままある。
で、その結論の妥当性の判断および、修正、承認がミーティングの場をもうける理由なわけですよ。
疑念があればその場でその根拠を確認するわけで。
ある事柄に対して、自分なりの見解および判断を持てない人とみなすなんて、メンバーに対してそんな失礼な事はできないですねえ。
>リアルタイムに対面でコミュニケーションする事に最大の意義があると思う。
が、口頭という手段はレスポンスタイムは最高だが、情報伝達の手段としてはスループットおよびS/N比が悪い(痕跡が残らないなど、もっと欠点はある。というか、レスポンスタイムしか利点がないのではないか?)ので、
やりとりする情報は最小限にすべきであると言えます。
大体、ベストな方法はドキュメントドリブンで行い、承認/決定の有無、その時点でドキュメント未記入の情報のみ口頭でやりとりする(すみやかにドキュメントにフィードバックする)でFAじゃないかと思いますが。
Re: (スコア:0)
結論ってそういう意味じゃないですよ。最終決定という意味の結論を持ってるなら相談する意味がないじゃないですか。
「ここが不明確です」「ここを助けて欲しい」という、結論というか話の主題の事を指すでしょう。
「ここを助けて欲しい」と示してから、現在の到達点や経緯を話さなきゃダメ、ママに泣きついてるのとはわけが違うんだから。
大元のコメントも、自分のコミュニケーションスキルに疑問を持ってるわけじゃなく、周囲の人間にコミュニケーション能力が無いと嘆いているわけでしょ。
あと、「記録して管理」は絶対やらないといけない、お仕事なんですから言質をとるっていうのは絶対に必要な行動ですよ。
リアルタイムに対面でコミュニケーションを取ったら、特に決定事項が含まれる場合はその内容をまとめてプロジェクト全員に見える所に置きましょう。
# 自分の社会人人生の中で、全部議論の余地が無い事柄ばかりなんですが...。