BeProudコミュニケーションガイド¶
一般編¶
コミュニケーションの目的を考えよう¶
何のためのコミュニケーションなのかを考えよう
コミュニケーションの目的は、共有/依頼/相談/提案など、たくさんの種類がある
その目的を達成するためのコミュニケーションを心がけよう
目的や意図や効果から共有しよう(要見直し)¶
企画や提案、カイゼンをするときは内容からでなく目的や意図、その効果から伝えるようにしよう
そもそもそれはやる意味があるのか、何かの目的や意味があるのかを考え直して、ちゃんと共有しよう
目的が伝わっていないとお互いが勝手に解釈した意図のために手段を議論して不毛になりがちだよ
質問に、なぜ聞きたいのかがわからないと、求める回答ができない
なぜそれを頼まれたのかを知っていたほうが、納得して行動できる
質問する時は、前提、コンテキスト、状況を共有しよう
すぐに伝わる表現方法を使おう¶
キャプチャ＋説明、図、動画を使う
文章の場合、分類したり、箇条書き、矢印などを使用して読みやすくする
シンプルで、一意の文章を書こう
主語、述語、目的語をお互いが理解できるように書こう
コミュニケーション手段を使い分けよう¶
チャットがベースだが、目的にあわせてチケット、ビデオ会議などを利用しよう
目的に合わないと判断したら、別の手段に切り替えよう
事実と解釈は別物¶
事実を元に考えよう
事実と解釈を分けて伝えよう
大事なことを先に伝えよう¶
大事なことは先に伝えて、相手の回答を引き出そう
みんな自分の仕事を持っている。何が言いたいかわからないと、おいていかれるよ(要見直し)
率直に伝え合おう¶
良いものを作るために考えていることや「こうしたほうが良いのでは」は率直に伝えよう
誰かが傷つくかもしれないと思って何も言わないと、仕事や成果、製品が悪いものになってしまう
指摘やコメントを個人への攻撃と受け取らないようにしよう
仕事のことは仕事のことなので、自分の気持ちや心が悪いと思う必要はない
「〜してもらえますか？」ではなく「〜してください」「おねがいします」と言い切ろう
何かを発言しよう¶
雑談はNGではない
何も発言しないのは存在しないのと同じ
何もわからなければ「わからない」と発言すれば、わかりにくいということが伝わるよ
何かを発言して、どんどん入っていこう
質問するのもスキルです¶
質問しないで頑張るより、わかりやすく質問することを頑張ろう
質問をするために情報整理、情報共有ができるようにしよう
相手が素早く回答できるようにしよう¶
質問や相談に選択肢があるときは、判断材料を書こう
相手が「はい、それでOK」と言うことができれば、仕事のスピードが上がる
自分がかけるべき手間を他の人に押し付けるのはやめよう¶
自分がやるべきことは自分でやろう
意図が明確な整理された情報を送信しよう
やり取りの往復を減らせる
ポジティブな気持ちは積極的に伝えよう¶
ポジティブな気持ちも言葉にしないと伝わらない
感謝/素敵/よさそうなど、良いなと思ったら積極的に伝えていこう
レビューでも良いと思った箇所があれば伝えよう
すみませんより、ありがとうを伝えよう！
遠慮しないで行動しよう¶
積極的に質問、リマインドしよう
忙しい場合は「あとで返事する」ことを伝えよう
タイミングは気にしなくていい
非同期でのやりとりは、お互いに都合のいい時に対応できる
礼節を心がけよう¶
お互い気持ちよくコミュニケーションが取れるよう、砕けていても不快にならない言葉遣いをしよう
不快になったらコミュニケーションが滞り、チーム力が下がる
不快に感じたらそれを伝えよう
期限を明示しよう¶
期限が「なるはや」で対応がいつでもいい。は存在しない
「なるはや」ではなく期限を明示しよう
その期限である理由、優先度も伝えよう
お互いに期限を確認しよう
他のタスクの予定が変わるなら、あわせて確認しよう
許可を求めるのではなくて、報告しよう¶
「やるよ」と言ってから実施する
「やっていいですか?」ではない
ダメだったら戻せることは、実施してから報告しよう(要見直し)
例: 履歴の管理されてるドキュメントの修正はダメだったら戻せば良い
テキストコミュニケーション編¶
文字以上の情報を察しようとしない¶
テキストはあくまでも情報なので、感情を過剰に読み取ろうとしない
情報が不足していると思うときは、追加情報を確認する
正確な文章を心がける¶
typoは直そう
他の人が理解する時間を奪うことになる
書いた文章を推敲しよう
可能ならEnter押す前に
押した後でも気づいたら修正しよう
お客さんあてのメールなど、心配なら誰かにレビューしてもらおう
簡潔な文章を書こう¶
文章ではなく箇条書きでまとめよう
箇条書きが多いならカテゴリー分けする
文が短いと理解しやすい
情報が多いほど良い/親切とは限らない。理解が大変になる
過剰な敬語、丁寧語を使わないようにしよう
させていただきます
「、」が多い文章は分割しよう
記号文字を使って、わかりやすくしよう（段階や経緯の説明、状態遷移の説明など)
右矢印などを使って「ので」や「の結果」という説明にする → 視覚的に伝わりやすい
具体的な表現をしよう¶
自分の言いたいことが正確に相手に伝わるように心がけよう
「〜を確認。」と体言止めにするのでは無く、「〜を確認します」「〜を確認しました」と状態を書くこう
5W1Hや「誰が」「何を」を明確にしよう
相手がアクションを取れる
相手に意図が伝わる
代名詞を避け具体的な名詞にしよう
あれ、これ、それ、どれ
具体的な数値にしよう
NG: 大量のデータ(大量は主観)
OK: 20GBのデータ
事実と想像をわかるように書こう¶
事実と想像が混ざっていると読んででて誤解を招く
「お客さんが怒っている」とか言っているが、ただの想像だったことがあった
バグ調査系だとどこまで信じていいものかわからなくて困る
関連する文章をまとめて提示しよう¶
自分が持っている情報を最初から相手に伝えて、無駄なコミュニケーションの往復を避ける
質問や確認の依頼時に、関連ドキュメントを添付しよう
URLだと共有が楽なので貼りましょう
特に見てほしい箇所を抜粋して伝えよう
多いとどこをみたらいいのかわからくなるので、ポイントを伝える
温度感も伝えよう¶
テキストだけだと相手の表情がわからず、相手が怒っていたりするのでは？と心配になる。
絵文字・顔文字などを使って、うまくこちらの感情や表情を伝える。
ただし、使っていい相手かどうかは考ること
Slack編¶
チャンネルで話そう¶
DMは極力使わず、みんながいるチャンネルで話そう
チャンネルで会話することによって、他の人からいい意見がもらえるかも知れない
DMは他の人が見てはいけない内容が含まれているときだけにしよう
非同期なコミュニケーションをしよう¶
他の人がタイピングが終わってから発言しようとすると効率が下がる
タイピング中表示を見ると入力待ちしてしまう人は、タイピング表示をオフしよう
非同期コミュニケーションは会話が混ざるので、メンションやスレッドを活用しよう
質問するときはメンションをつけよう¶
質問時は回答して欲しい人をメンションしましょう
メンションがない質問は全員がスルーしても問題がないものだけにしましょう
複数の人を指定するときは
@channelではなく明示的にメンションを並べましょう
1つのメンションで1つの要件を伝えよう¶
1つのメンションに複数の依頼、質問があると、どれが終わったか分からなくなる
全ての回答をもらえなくなるし、回答者のハードルがあがる
やりとりの往復が短くなるようにお互い配慮しよう
1つの要件を1つの発言にまとめて伝えよう¶
1メッセージで伝えると、引用しやすいし、Activity表示に全文表示されるため、行動しやすい
メンションした後の文章を読まないと要件が完結しない場合、見逃される
Slackのテキストで全てを伝えようとせず、他のツールと組み合わせよう¶
画面キャプチャーに図示して共有しよう
音声通話を利用しよう
テキストコミュニケーションにこだわり過ぎない
口頭のほうが早い場合は、適宜、音声通話を利用する
画面共有で伝えよう
チケット化してまとめてから伝える方が伝わりやすいこともある
発言にリアクションしよう¶
発言者には、読まれたかどうか分からない
メンションした場合は用事があってメンションしたのだから、相手に伝わっていることを知らせよう
他の人の発言を読んで納得して終わりではなく、納得したことを伝えよう
emojiのリアクションやスレッドで反応しよう
メンションがなくても困っているようであれば、サポートしよう
リアクション欲しい場合は、@hereではなく適切なメンションを使おう¶
@hereメンションはActivityに表示されない
@hereはその時アクティブな人が返すかもしれないという程度
リアクションが欲しい範囲に応じて @channel や個別メンションを使おう
スレッドをうまく活用しよう¶
ある議題で盛り上がっているときに、別の議題を差し込むと、チャットが混乱する
スレッドをうまく活用すると、会話をグルーピングするのに便利
スレッドは、参加してない人にとっては存在しないのと同じ
スレッドのコメントは時々チャット本文にも投稿しよう
会議編(リモート含む)¶
会議の目的を明確にしよう¶
会議の目的を決めて議題を予め共有する
不明点を解決するため
仕様を決定するため
相談するため -> 悩みをざっくり共有や懸念点の相談
目的を達成したらMTGも終了
不要な定例会議はスキップしよう
議題を事前に共有されない場合は不要
目的がわからない会議は参加する前に目的や議題を聞こう
会議の時間の使い方¶
終了時間を明確にする
自分の役割がおわったら途中で抜けよう
残り5、10分程度で話をまとめよう
決まったことをおさらいする
次のアクション(宿題)を決めよう
呼ばなくて良い人は会議に呼ばないようにしよう¶
少ない人数のほうが話がまとまりやすいし、無駄な労力を使わずに済むよ
直接会議の内容に関係する人だけを呼ぼう
自分が必要な時間になったら呼んでもらおう
話を聞きながら内職したい人は、そう伝えておこう
全員で決めて合意したいことや、マインドを共有するときは全員で合意しよう
参加者の空き時間に会議を入れよう¶
社員の予定は、Google Calendar で共有されている。
空いてる時間に予定を入れて、連絡しよう。問題があれば、指摘が入る。
そうすれば、回答待ちで予定が決められないのを避けられる。
カレンダーの予定で会議の詳細を伝えよう¶
カレンダーの本文に、目的、議事録のリンクを書こう
参加する人は開催前に議事録を書く場所を準備をしよう¶
会議が始まる前に、議事録に決めたいことを書き出しておこう。
そうすれば、参加者は、会議で決めたいことが明確になる。
会議は、素早くみんなで何かを決めるための手段であることを認識しよう。
議事録をみんなで見ながら会議を進めよう¶
議事録はリアルタイムに同時書き込み・閲覧できるものを使おう
事前に準備しておいた議事録を見ながら、決めるべきことを決めていこう。
議論があれば、議論の内容を議事録に残しつつ、確認しながら進めよう。
そうすれば、会議が終わった後に、認識合わせすることもなく、スムーズに記録を残せる。
リモート会議では意識的に相槌をうとう。¶
リモート会議をしているときは、意識的に相槌をうとう。
意識的に相槌をうっていくことで、認識がずれたときがわかりやすい。
余計な説明を省くために、自分が理解して入れば理解していることを示そう。
進行の合間に認識がずれていないか確認を入れよう¶
確認を入れる事によって、会議の進行中に認識のズレを最小限に抑えれる
確認しても、曖昧な回答を「自分の期待した答えとして解釈」するとズレる
「リリース日（デプロイ日）は月曜ですよね」「はい（利用開始は）月曜です」
どこについて喋っているか具体的に発言しよう¶
資料のどこについて、喋っているかを具体的に発言しよう。
みんなが自分の画面を見ていたら、どこを見ているのかわからず、タイムロスが起きがち。
発言するのは、議事録の見出しでも良いし、チケット番号でもいい。同じ画面を見て、議論しよう。
リモート会議では画面共有は必ず使おう¶
リモート会議では、相手がどの画面を見ているのかわからなくなりがち。
特に、メンバーの一部がリモートの場合は、一人が置いていかれることになりがち。
リモート会議の場合は、必ず画面共有するようにして、余計なタイムロスを省こう。
画面でページを表示するときは、リンクをSlackで共有して各自でも見れるようにしよう
リモート会議では自分からビデオをつなごう¶
ビデオをつないだりつながなかったりするけど、積極的につないでいこう。
そのほうが、誰が話しているかわかりやすいし、会議をやりやすいよね。
Redmine編¶
オープンにコミュニケーションをしよう¶
全員が全ての情報にアクセス出来るように権限を設定して、情報共有のコストを下げよう
やってることを薄く、広く、常に共有しよう(Redmineではなくてもいいのでは？)
お客さんも自分たちも一つのチームとしてコミュニケーションしよう
タスクを依頼されたら、まずチケットを作る¶
チケット作成を習慣づけましょう
「必要ないチケット」を作ってしまったらクローズしたらいい。（コストが安い）
「チケット作らず、タスクを忘れちゃった」 -> あとでフォローが大変（コストが高い）
結果だけでなく、思考の過程や結果の理由をチケットに書く¶
同じ困ったことが起きたときに過去のナレッジから対処できるようになる
レビューを見て、こう考えたからこうなんだとレビューする人が判断しやすい。（仕事のエビデンス）
チケットの粒度を適切にする¶
あまり大きすぎると進め方がわからなかったり分担ができない
適度にすると進んでる感が出る
仕事の見通しが悪くなる
小さすぎるとチケットを作るのが目的のようになる
プロジェクトにあったテンプレート作ろう¶
雛形があると書き方について悩まず、要点だけでも投稿できる
テンプレートは生き物。必要な時はテンプレートを更新しよう
新しくテンプレートが必要になったら、ほしい人が作成しよう
こう書いて欲しい、というルールがあるなら、テンプレ化しよう（タイトルにこれを書いて、とか）
チケットには担当者をつける¶
「誰」が、「何」を「いつまでに」するか、明確に記録しておこう
担当者がはっきりわかっていると、すぐに着手できる
アサイン先候補が複数いる場合、botに
$choiceで選んでもらってアサインしましょう
担当者を変える際には担当者を明確にしよう¶
Slackや口頭だけでは後から確認しづらいので、必ずチケットの注釈に依頼内容を書こう
依頼内容には「誰に」「何やってほしいか」をコメントで明確にして担当者を変えよう
作成者はチケットの終了条件を書く（ゴールを書く）¶
ある「タスク」に対して、「アクション」が必要、その「アクション」の「結果」を記載する
終了条件が決まっていると、仕事の意図が共有できて差し戻しが少なくなる
チケットには期限を設定しよう¶
期限を設定するとbotが期限間近や期限切れになると教えてくれる
期限を過ぎたチケットをいつまでも放置しない
いつかやるチケットは、きっとやらない
チケットの本文を更新しよう¶
チケット本文だけを見て必要な情報を理解できるようにしよう
あとから終了したチケットをみたとき、本文だけでなにが起きたか分かると時間が節約できる
チケットの本文に必要な情報がすべて書いてあると、コメントを追うことなく内容が理解できる
Slackで議論したことを、まとめて起票する¶
Slackは「流れていく」会話
あとになって文脈がわからない、あとになって探すのは大変である
関連するチケットのコメントに、議論内容を残しましょう
(わざわざSlackの記録を書き直す必要はない)
重要なチケットについては、チャットでメンションしよう¶
すぐアクション、相談等が必要な内容はチャットでメンションしましよう
チケットを閉じるのは作成者¶
作成者は、「あるタスク」にたいして、「あるアクション」を求め、「ある結果」を期待する
そのため、「実際の結果」を確認するのは作成者である
GitHub編¶
レビューの流れ¶
レビュイーがレビュアーをアサインする
レビュイーはGithubのアサインをレビューワーに設定しよう
何らかの形でアサインした旨をレビュアーに伝える
LGTM だったらマージする人を決めておく（レビューアー or レビューイー）
マージして良いかどうかを明確にする（いいコードっていうのとマージしてよいコードを明確にする）
どこに何を書くのかを明確にしよう¶
ISSUEテンプレート、PRテンプレートを設定して、書くべき事を明確にしよう。
レビュー依頼の内容を明確にしよう¶
レビュー依頼するときはチケットやドキュメントのリンクを一緒に貼ろう
レビュアーがレビューする際に、情報を探すのはコストが高い
単に「レビューしてください」でなく、特にレビューして欲しい観点があればなるべく書こう
例: モデル設計の深い部分を理解していないので重複するモデルなどないか知りたいです
例: デザインはチームで合意できているので、〜の処理をする点を重点的に見てください
レビュー指摘の温度感を示そう¶
must/should/may/nits/質問 など温度感を伝えると、レビューイーに意図が伝わりやすい
自分がどこまで見て、どこまでをちゃんと保証できているかは伝えよう
設計まで深く見れたのか、コードの表面上まで見れているのか
気持ちよくコードレビューが進められるように注意しよう。
レビュー内容に自分の好みを含みそうな場所はそう伝えておこう
「〜の方がよいと思います」
ぶっちゃけ大差ない好みなら言わないでも良いと思う
issueを作ろう¶
issueを考えすぎずに作ろう
問題があったらそこで議論しよう
却下も受け入れよう
コードレビューでのコミュニケーションの心構え¶
プログラミングもテキストコミュニケーションだ
動けばいいでなく、読みやすい設計やdocstringも「意図を伝える」効果がある
レビュー依頼時、無駄な低姿勢をやめる
緊急の修正の場合は「緊急」と伝える。それ以外のときは遠慮せずに頼む。
「お手数ですが」「お手すきの際に」のような意味のない言葉をつけない
レビューが仕事のサイクルの中で必須ならいつかはやらなければいけない
期限がなければ手は空か
コード指摘後モチベーションが上がらない時なども、指針を共有しよう
「 とりあえず他の作業を進めて気持ちを切り替える」
テキストコミュニケーションの内容はコードレビューも共通する