タグ

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

  • 「なぜ?」をやめたら簡単に原因究明できた話 | コマースデザイン

    理由がわからないときに使う言葉で、「なぜ?」「どうして?」というものがあります。ビジネスでもプライベートでも、この言葉で原因を究明し、事にあたられる方も多いかと思います。 しかし、ときどき、「なぜ?」では、うまく原因を引き出せないことがありませんか。 たとえば、「なぜ、締め切りに間に合わなかったの?」と相手に聞いても、「対応する時間がありませんでした」といった”原因っぽい答え”しか出てこない的な。 ゆっくり時間をかけて考えれば、また具体的な原因も出てくるのでしょうが、とはいえ、忙しいとなかなかそうも行かないもの。 そこで、今回は「なぜ?」と全く変わらない手間と時間で、原因を数倍は究明しやすくする(かもしれない)、あるテクニックをご紹介します。 誰でも、いますぐ簡単にできますので、ぜひ試してみてください。 「何があったの?」 結論としては、「なぜ?」の代わりに「何があったの?」を使います。

    「なぜ?」をやめたら簡単に原因究明できた話 | コマースデザイン
  • 「速く回す人」と「少なく回す人」 - assertInstanceOf('Engineer', $a_suenami)

    このエントリは アジャイルCasual Advent Calendar 2014 の 2 日目のエントリです。 前日は shin_semiya さんの「インセプションデッキを作る上での危険信号」でした。インセプションデッキを銀の弾丸と勘違いしている人には僕も会ったことがありますし「あるある…」という内容でしたのでみなさんも何かしらこういった経験はあるのではないでしょうか? さて 2 日目の僕は PDCA サイクルについて書いてみたいと思います。 自己紹介 すえなみと申します。漢字で書くと末並です。「末波」とよく間違われますが「末並」です。 とても希少な名字なので勉強会等で「すえなみ」と名乗ってる人間がいたら間違いなく僕のことだと思ってください。 オンラインでは a_suenami とか a.suenami とかで活動してます。 Twitter: https://twitter.com/a_

    「速く回す人」と「少なく回す人」 - assertInstanceOf('Engineer', $a_suenami)
  • 教えるという技術 | DevelopersIO

    渡辺です。 自分は「教える」ことにやり甲斐を感じます。 大学時代を思い返すと、家庭教師やサポートセンターのバイトをやってました。 ボードゲームをする時は、ルール説明などを行っていました。 ゲームのインストの一環としてインストカードやサマリを作ることもあり、プレゼン資料作りも得意になりました。 IT業界に入ってからは、勉強会の講師や資料作成・ハンズオンのチューターなどを行うようになりました。 技術書の執筆やIT系専門学校講師も経験しています。 最近では趣味のスノーボードで、インストラクターの資格をとり、スノーボードスクールで教えています。 「教える」ことが好きなんでしょう。 これまで、様々な分野で技術を教えてきました。 畑はまったく違ったとしても、解りやすく「教える」ための技術は大きく変わりません。 今回はそんな「教える」技術をまとめてみました。 なお、エントリーの対象は、その分野に初めて

    教えるという技術 | DevelopersIO
  • 350年前の「相手に考えを変えさせる方法」が効果的と現代の心理学者が支持

    By Eddi van W. 17世紀のフランスの哲学者/数学者/物理学者のブレーズ・パスカルが提案した「パスカルの賭け」は、「神の存在を証明できなくても、神の存在に賭けることは合理的な選択である」というもの。神を信じて生きる人は幸福な人生を送ることができ、もし神が存在しなくても損をすることはないためであり、この考え方は歴史的に確率論の新しい領域を開いたともいわれています。そんな350年も前に生まれた考え方は、「有効的に相手を説得する手法」として現代の心理学者によって支持されています。 How to Change Minds: Blaise Pascal on the Art of Persuasion – Brain Pickings https://www.brainpickings.org/2015/05/20/blaise-pascal-pensees-persuasion/ To

    350年前の「相手に考えを変えさせる方法」が効果的と現代の心理学者が支持
  • Slackにより断片化した集中タイムを取り戻すための、Bot開発 - Qiita

    Slackは、チーム内のコミュニケーションを取るためにはとても便利なツールです。 しかし、おそらくあなたが気付いているように、Slackはあなたの「集中タイム」を断片化します。投稿をしたら反応が気になる、投稿をしていなくてもどんな話題が交わされているのか気になる、時には重要な情報が飛んで来ることもあるから見逃せない・・・こうして、Slackのタブに灯る「*」マークは一瞬にして集中していた作業時間をストップさせてしまいます。 堅苦しい会議も時間の無駄になりがちですが、その一方でこうしたチャットツールによる「コミュニケーションの断片化」もまた問題であると言えます。 そこで今回考案したのが、Slack Refereeです。これは、端的にはSlackチャンネルを休憩スペースにするというアイデアです。つまり、休憩時間中だけ会話が可能で、それが終わったら作業を行う集中タイムに戻る、ということです。 コ

    Slackにより断片化した集中タイムを取り戻すための、Bot開発 - Qiita
  • マネジメントの秘伝のタレ - Flicker's Style++

    今回は私が今までチームマネジメントやヒューマンマネジメントを通して学んだTIPSを整理してみたいと思います。 マネジメント(≒コミュニケーション)を支える技術について都度メモして、自分への戒めとして利用していたものを箇条書きにまとめました。 ある特定の状況だけでしか適用できないものが多いですが、応用はいろいろ効くと思っています。 マネジメントの立場にこれからチャレンジしていきたい人の一助になればと思ってます。 ※自分向けのメモを整理しただけなので、一般的にこうあるべきという内容ではありません。 会議編 -全員の参加を促そう 全員の発言機会が均等になっているか常に意識しよう 一言でも意見を言うことによって、その議題を決めたという意識を持てる - 自分自身(チーム自身)で決めたという感覚に落としもう 「決められたこと」ではなく、「自分たちで決めたこと」という意識を促そう その決定が実行されなか

    マネジメントの秘伝のタレ - Flicker's Style++
  • 「バックログに入らないタスクを可視化する仕組み」という話を技術勉強会でしました - Hatena Developer Blog

    こんにちは。アプリケーションエンジニアの id:daiksy です。 はてなでは毎週木曜日に技術勉強会を開催しています。 参考: 寿司と勉強会とエンジニア - Hatena Developer Blog 先週、当番が回ってきたので、「バックログに入らないタスクを可視化する仕組み」というトークをしました。 speakerdeck.com 詳細はスライドを見ていただくとして、この発表で定義された「税」などの用語が、さっそく社内でのコミュニケーションでも使われだして、エンジニア同士で、ある概念について共通の認識を持つためにもこういった場は効果があるな、と実感しました。 はてなでは、アプリケーションを構築する技術だけではなく、プロジェクトマネジメントやチームビルディングの知見などもこうして技術勉強会で共有されています。

    「バックログに入らないタスクを可視化する仕組み」という話を技術勉強会でしました - Hatena Developer Blog
  • 効果的な 1 on 1 ミーティングのためにマネージャができること

    2016 年に逝去した、元 Intel CEO の Andy Grove による High Output Management の日語訳が復刊され、さらに Hard Things の Ben Horowitz の序文がついたことで、改めてスタートアップ界隈でも 1 on 1 (ワンオンワン) ミーティングの効果が注目され、各社や各人の 1 on 1 のノウハウが共有されるのではないかと期待しています。 Y Combinator の Sam Altman はスタートアップ初期でのコミュニケーションの重要性を何度も説いています。特にスタートアップは業務が複雑になりがちで、かつ状況の変化も早いため、コミュニケーションがボトルネックになりがちです。 コミュニケーションの遅れは意思決定の遅れにつながります。そして意思決定の遅れは事業の進捗を遅らせたり、トラブルの兆候を見逃してトラブル発生の原因にな

    効果的な 1 on 1 ミーティングのためにマネージャができること
  • 1