エンジニアのためのコミュニケーションベストプラクティス
ダイニーの urahiroshi です。 自分は前職のメルカリ、現職のダイニーで計3年くらい Engineering Manager を務めてきましたが、Engineering Manager の本質的な役割は「チームや組織のパフォーマンスを最大化すること」だと考えています。そのためには、チーム開発におけるメンバー間のスムーズなコミュニケーションが不可欠です。 これまでコミュニケーションに関するフィードバックを行ってきた中で、よく見られる改善点がいくつかあったため、それらをベストプラクティスとしてまとめてみました（それぞれのセクションで一つずつ本が書けるくらい多数のプラクティスが挙げられるテーマだと思いますが、特に頻出するポイントに絞っています）。皆さんのチーム開発にも役立てていただければ嬉しいです！ レビューをするときのプラクティス 指摘にはWhyを書き、Howを押し付けない ❌️ Ba
できていなかったことを"忘れてた"と言わない - Konifar's ZATSU
依頼された仕事の期日を忘れてできていなかった時に「すみません、失念していました」と伝えていたら、当時の先輩にしっかりめに叱られたことがある。もう10年以上昔のことだが、いまだに印象に残って意識しているのでよいフィードバックだったのだと思う。 叱られた内容を雑に書くとこんな感じだった。 できなくてもいいができるふりをするな。 「忘れてた」なんてことは依頼元には関係ない。「忘れてなければできる奴なんだな」なんて思われることもない。ただ「忘れてできなかった奴」と思われるだけだ。下手すると "言い訳をする奴" という印象を持たれて損をする。 できない奴と思われたくない気持ちはわかるが、すぐにバレる見栄を張るな。「忘れてた」と言う前に「できてなかった」なのかをよく考えろ。そうしないと相手にも失礼だ。 言葉選びだけの問題と思うかもしれないが、こういう細かいところが信用の積み上げになる。信用されることと
「何か質問や意見ありますか」の後の無言対策 - Konifar's ZATSU
オンラインのミーティングで「何か質問や意見ありますか」と聞いた後の無言がつらいんだよねという話を聞いた。わかる。自分はもはや慣れきってしまったけれど、今でもいい方法ないかなあと考えている。 いくつかやったことを書いてみる。組織によってもだいぶ違うと思うけれど、他の人の知見をめちゃくちゃ聞きたい。 最初に声を出してもらう 少しでも最初に声を出しておくと意見を言いやすいという研究があるらしい。なんとなく実感としても正しい気がしている。 ただ全員に雑談を振るというのもちょっとなあという時に自分がやっているのが「出席をとります」である。皆なつかしい気持ちになってほんわかするし、返事をするだけでもよいので楽。時間もかからない。 参加者の役割を最初に話す どういう役割や発言を期待しているかを明確にしてあげるとそのスタンスで意見を言いやすくなる。たとえば「○○さんにはモバイルの開発工数観点でかなり現実的
会議のファシリテーションをほめてもらった - Mitsuyuki.Shiiba
うれしかった。ので、メモ。 僕のいるチームのプロジェクトで、複数のチームにサポートしてもらいながら進める必要がある、ちょっと大きなものが始まりそうだったから、キックオフ前のキックオフやっとこかーってなって司会をした。オンラインミーティングね。 最初にこの会の目的を説明 今日のアジェンダのページのリンクは事前に共有もしていましたけど、いまSlackにもポストしておきましたー。 まだプロジェクトは始まってないんだけど、事前に調査とかをしたいから質問や相談をさせてもらいたいなと思っていて、そのときに「え？これなんの話？」って戸惑わせることがないように、プロジェクトの概要を共有しとこうと思ったー！だから、この会がうまくいったら、僕らが質問してもみなさんが戸惑わないようになっている！ Bさん、Slackにメモ残してってください。お願いしまーす！ からの、会の流れを説明 最初にPdMから10分くらいで
「指示の出し方が悪い人」は、一体どこがダメなのか。
「指示の出し方が悪い人」が、いる。 例えばこんな具合だ。 「安達さん、web制作会社からあがってきたページの確認をしておいて！」 そんな指示が上司から飛んだとする。 実際にそれを体験してみると、この指示が「良い指示」だと思うビジネスパーソンは、ほとんどいないだろう。 なぜならば、 １．「あがってきた」とは何か。メールで届いたものか。メッセンジャーで来たものか。他にもあるのか。何が全てか。 ２．「ページ」とは何か。webページのことか、または別の形式・フォーマットを指すのか。 ３．「確認」とは何か。何を基準とするのか。どうすれば作業終了となるのか。 など、作業を進めようとすればするほど、次々に疑問が湧くからだ。 酷いときには、よくわからない書類をぽんと渡されたり、謎のメールを転送されて 「これやっといて」 などという指示をする人もいる。 要するにこれらはすべて、「手抜き指示」だ。 こういう指
真意を確認している要注意ワード - Konifar's ZATSU
言った人と聞いた人の認識がずれやすい言葉というのがあると思っていて、その話を雑に書いておきたい。 自分はこれらを"要注意ワード"と呼んでいて、出てきたら真意を確認するようにしている。無意識的にやっている人は結構いると思うので、同じような"要注意ワード"の知見吸いたい。 リスク 「リスクがある」と言われたときは、何のリスクのことを言っているかを確認している。 たとえば何かの開発を1週間後にリリースしたい、と言った時に「いやーこれは結構怖いしリスクありますよね」みたいな話になったとする。ここでいうリスクは何を言っているのだろうか。なんとなく品質が担保しきれないリスクのことを言っているような気がするが、実は間に合わないかもしれないことをリスクと言っているのかもしれない。あるいは、チームメンバーのモチベーションが下がることをリスクと言っている可能性もある。 何のリスクのことを言っているのかすり合わ
"提案"のレベルを上げる - Konifar's ZATSU
組織で物事を進めるのが早い人は、"提案"のコミュニケーションを取っていることが多い気がする。 "指摘"で止まるのではなく課題の解決に向けた"提案"までやる方がいいんだけれど、そもそも提案って一言で言ってもまあ難しいよね。とある1on1で雑談していて、"提案"のスキルを上げていくにあたってはいくつかのレベルに分けて考えてみるといいかもしれないと思ったので、声かけのワード別に自分の考えを雑にまとめてみる。洗練されていないので意見がほしい。 レベル0: 「どうすればいいですか」 何か問題があった時の「どうすればいいですか」という聞き方は提案ではなく指摘で止まっている。 指摘してくれるということは気づいているということだし、それを伝えてくれること自体も素晴らしいことなのだけれど、そこからどうしていくかを決めるのが大変な部分なので次のレベルにも染み出していきたい。 レベル1: 「どれにしましょうか」
会議全部ふっとばして社員の集中力を10xした話(ビッグバン) - 10X Product Blog
こんにちは！経営企画の仕事をしているudonです。1年半前の見習いQA以来、2度目の文章です。今回は10X社内の会議のルールを整理し、そして全社員の未来のカレンダー予定を一旦全部消す、通称「ビッグバン」の第一回を実施したのでその背景や内容について書きます。 (イメージ) 10Xでは社内におけるコミュニケーションを大きく「同期」「非同期」に分けています。同期は会議や突発的な電話など同じ場にいることが前提であるコミュニケーションを指し、Slackなど非同期は必ずしも同じ時間での往復を前提としない文章やドキュメントによるコミュニケーションを指します。入った当初は「ドウキ・・？ヒドウキ？？」とドキドキしてた私ですが、2年も経つと慣れてしまいました。慣れって怖いですね。 話が長いという皆様の期待を裏切ることなく、タイトルにもなっているビッグバン(会議の全削除)の話にいくまで5,000文字嵩んでしまっ
質問をする技術 - くりにっき
以前社内に書いたポエムなんだけど年に1回くらい引用したくなるので公開した tl;dr; 質問をする時はゴールを提示する【MUST】 理由1 理由2 コンテキストを詳しく共有する【SHOULD】 期待してた結果(expect)と実際の結果(actual)を書く【IMO】 2020/7/22 12:30追記 2020/7/22 19:00追記 tl;dr; テンプレ 【質問内容】 【やりたいこと or 今困ってること or 質問の意図】 質問をする時はゴールを提示する【MUST】 なにかやりたい けど実現できない、うまくいかない それで質問する って感じに、質問をする動機としてまず やりたいことありき のはずなので、それを提示すべきです 理由1 質問される側（以下回答者）は質問内容がふわっとしていると色々なケースを想定して回答を組み立てます *1 例「Aの場合は～だけど、Bの場合は～」 こうい
女子高生が語る「LINEからインスタDM」に会話の途中で移動する理由。用途における「メッセージアプリの分散化」と受験期にスナチャがつかわれる話。｜アプリマーケティング研究所｜note
女子高生が語る「LINEからインスタDM」に会話の途中で移動する理由。用途における「メッセージアプリの分散化」と受験期にスナチャがつかわれる話。 スマホのメッセージアプリを用途でつかい分ける、スマホユーザーのO.Kさん18歳（神奈川の高校生 ※春から大学生）にインタビューしました。 目次： ・雑談するのに「LINEをつかわなくなってきた」 ・インスタのDMは「行きたい場所」を決めるときに便利 ・受験シーズンに「スナップチャット」がつかわれる理由 ・女子高生が悩まされる「個人情報のスクショ問題」 ・インスタが破壊した「メッセージするための理由」 ・ストーリーが「リアルタイム×動画」で拡散される話普段メッセージアプリって何をつかっていますか？前までは、LINEばっかりだったけど、最近は雑談するのにLINEをつかわなくなってきて、スナチャとインスタのDMをつかうことが増えました。 LINEは予定
こんな人は、会議に参加させてはいけない
先日、ある社内会議に外部協力者として参加した時のこと。 8名ほどの参加者にたいして、議長が「意見はありませんか？」と聞いた。 彼らのうち、3名は意見を述べたが、残りの5名は何も言わなかった。「本当になにもないのですか？」と議長が念押ししても、 「ありません」 というばかりだった。 会議はその後、つつがなく終わったが、議長は先の意見を述べなかった5名に、 「来週からこの会議には出席しなくて良い。」と告げた。 その5名は 「今日はたまたま意見を言えなかっただけです」 「情報を共有したいので、出席します」 というのだが、議長は「議事録は後から送ってあげるから」と言って、取り合わなかった。 議長に後で話を聴くと、「「最近無駄な会議が多い」という課題があり、会議を絞り込んでいる最中です。」という。 「大体、会議に来てぼーっとしている人や、内職をしている人に、会議に出て貰う必要はないですよね。」 「確
社内なら謝らなくて良いカルチャー
社内で仕事をしているとき、指摘や指導をすることがあるが、まだうちのカルチャーに慣れていない人は、すぐに「すいません」と謝る。でも、それは良くないよ、と言っている。 仕事の仕方や成果物に対しての指摘というのは、別に悪いことをしたからな訳ではないのだから、謝る必要などない。私に謝って欲しくて指摘している訳ではないのだ。 謝るってことは、私を向いて仕事をしていることになる。それは良くない。仕事はあくまでユーザやお客さまを向いてするものだ。社内の人に向いて仕事をするのではない。 だから指摘に対して謝る必要はない。良い仕事をしてもらいたい、成長してもらいたいから指摘をしているのだ。社長の顔色なんて見なくていい。良い仕事をすればいい。 同じチームにいて、良い仕事をして、成長していきたいというベクトルがあっているなら、謝ることなんてないのだ。そういうカルチャーの会社であり続けたいと思っている。 もちろん
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チームで盛り上げる ファシリテーション
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
「場」における心理的安全性 / psychological safety at a scene