タグ

コミュニケーションに関するtsugiikimasu22のブックマーク (92)

  • わかりやすく話すためには「話しすぎない」というスキルが必要。

    なかなか、わかりやすく話せない…という方は多いかもしれません。 それどころかむしろ訓練を受けていない、ほとんどの人の話は、論理的でもなく、筋道も通っておらず、「わかりにくい」のが普通なのでしょう。 ただ、プライベートでは、それほど「話のわかりやすさ」を問われません。 何となくその場の雰囲気で、皆、うなずいてくれるからです。 「ま、言ってることはわかんないけど、追及するのも面倒だからいいや」とか 「大したこと言ってるわけじゃなさそうだから、適当に笑っておこう」とか。 通常、多少の分かりにくさは、すべて無視されてしまいますから、支障はないのです。 仕事では「話のわかりやすさ」は死活問題 しかし、仕事においては少々事情が異なります。 理解不足が、場合によっては責任問題に発展することもありますから、「面倒だから、まあ流しておけばいいや」では済まされません。 基的には、相手の話を細大漏らさず理解す

    わかりやすく話すためには「話しすぎない」というスキルが必要。
  • [PM向け]死んだMtgを立て直せ~議事録から考える"Mtgの型"について~

    背景 ゴリゴリ系エンジニア、pageoです。 TwitterMtgのあるべき姿についてツイートしたところ、ぼちぼちRT/いいねをもらえたので記事を書くことにしました。(お友達欲しいのでフォローしてください🙏) 最近大手クライアントとのPJに関わることが増えてきたのですが、事前アジェンダ共有なしに急にMtgが開催されるなどの無法地帯な場面に何度か遭遇したので、今回の記事では"Mtgの型"のあるべきについて自分の見解をまとめてみました。 はじめに Mtgの型 以下の章で紹介する"Mtgの型"はMtgというより議事録の書き方に寄っていますが、以下の章に書かれたことを実践することにより劇的にMtgの生産性は上がると思うので、この記事を機に是非自分/組織全体の"Mtgの型"について議論や検討をしてみてください。 いきなり結論 "Mtgの型"で説明する"教え"は以下の4つだけです 第一教: ~アジ

    [PM向け]死んだMtgを立て直せ~議事録から考える"Mtgの型"について~
  • 「離婚するほどじゃないけど……」な“小さな不安”を言語化して伝えるコツ - りっすん by イーアイデム

    パートナーと一緒に暮らす中で募っていくモヤモヤ。ひとつひとつは小さくても、胸の中で次第に膨れ上がっていき、あるとき爆発して大喧嘩に発展……なんて経験のある人も少なくないかもしれません。プライベートの空間ですれ違いが発生すると、日々に余裕がなくなり、仕事などオンの場に悪影響を与えてしまうことも。 『夫婦でつくるメンタル安全基地 〜「離婚するほどじゃないけどなんかモヤモヤするッ」を減らして持続可能な夫婦になる〜』(講談社)の著書ふっくらボリサットさんは、そんな“モヤモヤ“が爆発したことをきっかけに「自分の気持ちを言語化してきちんと相手に伝える」ことを意識するように。今では夫のサミ太郎さんと定期的な「夫婦ミーティング」の場を設け、心理的安全性の高い状態で話し合いができるようになったといいます。 小さな不満を溜め込まずに伝えた上で、良好な関係性を維持できている理由とは? ふっくらボリサットさんと、

    「離婚するほどじゃないけど……」な“小さな不安”を言語化して伝えるコツ - りっすん by イーアイデム
  • リモートワークで雑談を生み出す仕組み - JMDC TECH BLOG

    こんにちは。ユーザープラットフォーム開発部(UP部)の原です。 あなたのチームの雑談チャンネルは1日あたり何回ぐらい発言がありますか? 小さい仲良しチームなら頻繁に発言があるかもしれませんが20人,30人あたりになってくるとだんだん発言が少なくなってきますよね。 チームメンバーのエンゲージメントや生産性を高めるためには少なくともお互いがどんな人なのかを知っているようにしておくべきです。 JMDCは数百人いる組織だし、私の所属するUP部だけでも20名以上の社員が所属しており、しかもほぼ全員リモートで仕事をしている状況なので、いかに "チームメンバーがお互いにどんな人なのかを知っている状態" を作り出すかが課題になっています。 GitLabリモートワークガイド参考にする 自らを “A world leader in remote work” と呼んでいるGitLabも雑談を重要なものと捉え

    リモートワークで雑談を生み出す仕組み - JMDC TECH BLOG
  • 組織マネジメントのあれこれ|nishiba

    トピック部下への任せ方 部下の視座の上げ方 なぜ書くのか?最近、部下と話していて言語化が進んだのでメモとして書いておく。また、いつもどおり書きなぐりの文章です。推敲などはしていません。 前置き今回あえて部下という言葉を使っています。普段は部下という言葉よりもメンバーという言葉を使います。今回は上司と部下の関係であり、上司として私が気づいたことを書くので明確に部下という言葉を使っています。 部下への任せ方仕事を任せることは非常に難しいと思っていた。しかし、難しいと感じる場面が最近減った気がする。その理由を考えたのでメモとして残す。 私は1年ほど前に今の会社に転職した。今は執行役員/VPoEを担っている。入社当初からずっとマネジャーという立場である。最初は研究開発部の副部長という立場であり、数カ月後に部長、その数カ月後にVPoE、さらに数カ月後に執行役員になった。なので、全く現場のことや配下に

    組織マネジメントのあれこれ|nishiba
  • 忙しい人に判断を仰ぎたいときは松竹梅プランを作ってチェックボックスを埋めてメンションしてもらうようにすると合理的で便利 - Lambdaカクテル

    普段の暮らしにおいて、実装の仕様をエンジニア単独では決められないことがあって、そういうときにはマネージャーとかディレクターといった意思決定可能な立場の人の判断を仰ぐことになるのだけれど、そういう立場にある人は無限にミーティングをしていたり、無限に同じような意思決定を続けなければならないので、とにかく多忙だ。 そこで、ちょっと判断を仰ぎたいのですが、といったシチュエーションでは、GitHubのIssueなどの非同期なコミュニケーションチャンネルを使って、非同期に通知が飛ぶようにメンションしつつ、以下のことをすると良い。 松竹梅で候補をあらかじめ立てておく 松はハイコストだけれど理想に近い 梅は激安プラン夜行バスといった雰囲気 GitHubはリストの冒頭にチェックリストを入れることができて、しかもチーム内だったら勝手にいじれるはず - [ ] 松プラン: DBを1000xlargeにする (費

    忙しい人に判断を仰ぎたいときは松竹梅プランを作ってチェックボックスを埋めてメンションしてもらうようにすると合理的で便利 - Lambdaカクテル
  • 1on1をナイスにするためにEMのワタシが心がけていること - SMARTCAMP Engineer Blog

    スマートキャンプ、エンジニアリングマネージャーの入山です。 私は現在、弊社BOXIL SaaSの開発部長を務めており、タスクの管理や開発メンバーのマネジメントを中心に行っています。また、BOXIL EVENT CLOUD開発メンバーのマネジメントも兼務しており、弊社エンジニア組織の中でも直接業務で関わるメンバーの数が多い立ち位置となっています。 そんな私は、2つのプロダクトの開発メンバーだけでなく、上長やPM、他チーム開発メンバーなど、頻度はさまざまですが10名以上の方々と日々1on1をさせていただいています。 1on1は入社当時から今に至るまで役職や立場が変化しつつ色々なメンバーと実施していますが、最近では自分との1on1に対する満足度が高いという声をいただく機会が増えたように感じています。 今回は、私が1on1を実施する際に意識している内容について、紹介したいと思います! スマートキャ

    1on1をナイスにするためにEMのワタシが心がけていること - SMARTCAMP Engineer Blog
  • 相手に動いてもらえないのは、一言目で“地雷”を踏んでいるから 仕事でも私生活でも役に立つ、人を動かす「伝え方」の極意

    の学びを深めるオンライン講座「flier book camp」を運営する株式会社フライヤーが主催したイベントに、ゲストとして登場したのは、『無敗営業』シリーズ著者の高橋浩一氏。今回はファシリテーターにフライヤーアドバイザー荒木博行氏を招き、「言える・伝わる・あのひとが動く『伝え方の原則』」をテーマに対談します。高橋氏は、相手にうまく動いてもらえない時は“地雷”を踏んでいる場合が多いのだと語り、気持ちよく人を動かすための「伝え方」のポイントを解説しました。 相手にうまく動いてもらえない時は“地雷”を踏んでいる 荒木博行氏(以下、荒木):浩一さんはものすごく大量にいろんな人の営業トークやコミュニケーションの現場に立ち会われていて、ロールプレイもかなりやってらっしゃると思うし、そこでのフィードバックもけっこうされているわけですよね。 「やっぱりここでコミュニケーションが躓いちゃうのか」というも

    相手に動いてもらえないのは、一言目で“地雷”を踏んでいるから 仕事でも私生活でも役に立つ、人を動かす「伝え方」の極意
  • メンバーから「できてません」「進んでません」と言ってもらうために、考えたこと

    この記事で書きたいことは、以下のような内容です。 ・マネジメントをする上では、「出来てない」「進んでない」という情報は最重要であって、早く言ってもらえば言ってもらえる程傷が浅くて済む ・機械的に進捗を把握出来るのが一番だが、なかなかそうもいかない場合もある ・だが、「出来てません」「進んでません」というのは物凄く言いにくいことで、ベテランでもギリギリまで言えない人は多い ・「出来てません」と可能な限り言ってもらいやすい環境を作るのは上司仕事 ・個人差もあるが、ある程度「言いやすい」条件を整えることで、「言えない」人でも言えるようになってくれる場合もある よろしくお願いします。 さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。 皆さん、「進捗ダメです」って言えてますか? 「全然できてません」って言えてますか? これはどんな仕事、どんな分野、どんな業界でも同

    メンバーから「できてません」「進んでません」と言ってもらうために、考えたこと
  • 「何を言っているのか分からない」と言われないための「伝え方」のノウハウ - Qiita

    私自身、物事を分かりやすく伝えるスキルを身に着けるため、手あたり次第に、いくつかノウハウを読んだり、YouTube動画を観たりしてきました。記事では、や動画から得られたノウハウや、私が普段の仕事で発見した個人的に使っているテクニックをまとめてみました。 0 記事の最重要ポイント 記事がストックの墓場に行ってもいいように、記事の最重要ポイントだけ先に伝えておきます。 質問に答える時は、聞かれたことにシンプルに答える。 事実と解釈を分けて話す。 1 記事で伝えたいメッセージ 1-1 コミュニケーション能力の苦手意識はノウハウで解決する ITエンジニアの裾野が広がるにつれて、SNSでも「コミュニケーション能力の低いITエンジニア」の話題をちらほら見かけるようになりました。いわく「これからはITエンジニアにもコミュニケーション能力が求められる」「プログラミングができるだけでは生き残れ

    「何を言っているのか分からない」と言われないための「伝え方」のノウハウ - Qiita
  • 要件定義を担当する【ITエンジニア】に必要な【コミュニケーションスキル】 - Qiita

    はじめに タイトルの主張が少し強いですが、以下のを読んでコミュニケーションスキルについて書かれている部分が有益だなと思ったので メモ程度 にまとめました。 元のでは具体例などが書かれていてわかりやすいので、その点を押さえたい方は購入をお勧めします。 コミュニケーションスキル 以下の3つがある ヒアリングスキル ミーティングスキル プレゼンテーションスキル 1.ヒアリングスキル A.質問 Open-Close Open 5W2Hを用いた質問 Why,What,Who,When,Where How(程度),How to(手段) Close yes,noで解答できる質問 認識の不一致が連続すると信頼を下げやすいので注意する 深掘り 目的 原因 影響・結果 手段 反復 「それ以外にありますか?」 明確化 曖昧な表現を明確にする 例:「うまくできない」→「納期に間に合わない」 論理性チェック A

    要件定義を担当する【ITエンジニア】に必要な【コミュニケーションスキル】 - Qiita
  • 開発中のコミュニケーションには色んなところで想像が入り込む - Mitsuyuki.Shiiba

    例えば「会議が多い」という意見に、どう対応しよう? 普通に考えたら「無駄な会議を減らそう!」かな だけど、できれば僕は「だからどうしたいと思ってるんですか?」というのをその意見をくれた人に確認したい 十中八九「会議を減らしたい」ってことなんだろうとは思いつつ、でも「会議が多いから、」のあとには色んなことが想像できる (順当→)会議を減らしたい それぞれの会議に自分が参加しないといけない理由を知りたい 会議が多くて他のことをやる時間がないから、自分の担当タスクを減らしたい 会議が多いのはいいんだけど、間に休憩が欲しい 「そっかぁ、それは大変だよね。ありがとう」って話を聞いて欲しいだけ もしかしたら「だから、充実してるんです」って可能性もなくはない さらに「会議を減らしたい」だったとして、その内容も 「無駄な会議が多いから減らしたい」かもしれないし 「開催頻度を減らしてもいい会議があるのではな

    開発中のコミュニケーションには色んなところで想像が入り込む - Mitsuyuki.Shiiba