独断と偏見に満ちたエンジニア日本語・会議・取りまとめのコツ

Transcript

1. 独断と偏見に満ちた エンジニア日本語・会議・取りまとめのコ ツ 株式会社現場サポート 技術統括室　新山
2. プロフィール - 新山大介（ 37） - 株式会社現場サポート　技術統括室　 SRE - 普段はインフラメイン、 AWSよく触る - ラッパーの側面ばかり取り上げられる - CD欲しい人いたら声かけてください！
3. 会社紹介 - 株式会社現場サポート - 建設業向けのシステムとか作ってます - 「建設業のお客様が 10年後もいい仕事を残せる現場サポート」 - よろしくお願いします！　エンジニア募集中です！ - 自社プロダクト - 受発注者間情報共有システム「 One」 - 書類の決裁、ファイルの共有、コミュニケーションなど - コミュニケーションツール「 Conne」 - ゲスト機能付きのグループウェア - 重機管理システム「 Arune」 - 重機センサーと連動して重機の所在・稼働状況を管理
4. 今回は注意事項が多数 - 社内で発表したスライドの流用です - まずい内容あったらそっと教えてください - 正解が無い or経験則に基づく話があります - 自分はこういうところに気を付けてるよ、の共有です - 初歩的な内容だったら申し訳ない 🙏 - 会社内でのやり取りがスムーズになれば
5. 大前提：相手の事を考えた言葉選び - 相手の事を考えながら言葉にするだけでかなり違います - 相手に伝わるか - 内容 - 相手が不快にならないか（なってもしょうがない時もあるけど） - 言葉遣い - 相手の時間を奪わないか - スムーズに理解できるよう内容を洗練しているか - 余計な思考を要求しないか（ややこしい言い方をしていないか）
6. 大前提2：相手が敵とは限らない - 会話の相手の属性を踏まえたやりとりを心がけましょう - 例えば自分の会社内の人と話すなら、基本は「仲間」のはず - 好きで相手をなじるようなことはしてこない。前に進むための話 - 会社・プロジェクト・個人など、目指す先は違うかもしれない - ぶつかるかもしれないけど冷静に - 仲間であることと性格の良し悪しはまた別な点も注意 - 好き嫌いもそりゃーあるけど、切り分けて考える - 「パートナー」「客」「敵」など、相手に応じた内容を考える
7. 会話の考え方
8. 最小限の会話の例 テストして！ テストした！ Aさん Bさん
9. よくわからん
10. わからないこと - Aさんは「何の」テストをしてほしい？ - 現時点ではプロダクトもわからない - プロダクトがわかっても「何を」テストしてほしいのか分からない - 更に言えば、「いつまでに」テストしてほしいのか分からない - Bさんは「何を」テストしたのか？結果はどうだったのか？ - 依頼内容に対応するテストを行ったのか分からない - 結果問題なかったのか、問題があったのかもわからない
11. 意識したいこと Step1：何をどうしたい？ - 主語をつける - くどいくらい主語を付ける - 全部につける - 具体的な主語を付ける - 目的語もつける - Aさんは何をしてほしいかわかるように言葉を足す - Bさん側は何を行ったかわかるように言葉を足す
12. 意識したいこと Step1：何をどうしたい？ - 敬語を意識する - 普段通りの砕けた喋り：常体 - なんか丁寧にしゃべる：敬体 - 本当は言葉遣い、文章作法もある程度押さえたほうが良い - ただし相手も人間なので、丁寧に話そうとしていることがわかれば 基本無下にはしないと思う（経験談） - 敬意を払う払わないも大事だが、 相手が不快に思わないようにするには 、の視 点に立つ - 社内はまだ適当で良いが、社外の人と接するときは注意
13. Step1を踏まえて Conneのスペース機能の改修が完了したので、 動作が問題ないか確認をお願いします。 依頼されたスペースの動作確認が完了しました。 正常に動作していることを確認しました。 Aさん Bさん
14. 意識したいことStep2：具体的にしよう - 内容が細かくできる部分は無いか？ - 先の例では以下のようなポイントが考えられる - Aさんの「スペース機能の改修」はどんな修正？ - 何の修正なのか具体的にしよう - Aさんの「動作が問題ないか確認」はどうなっていればいい？ - 依頼やチェック手順を共有する - Bさんはどう「スペースを確認」した？ - チェック手順まで共有できると良い
15. 意識したいことStep2：具体的にしよう - 5W1H - When、Where、Who、What、Why、How - いつ、どこで、だれが、何を、どのような理由で、どのように - ニュースや文章作法の原則だが、実際あると助かる情報が多い - 上記呪文を意識しすぎない。エンジニア流にアレンジして使う。 - 納期、サーバー、担当者、対象機能、依頼理由、手順　など - エンジニアの喋りはくどいくらいが良い（持論） - 自分が前提としている内容が共有されているとは限らない - 自分が重要だと思う前提は全部共有するべき
16. Step2を踏まえて Conneのスペースタイトルが虹色に光るバグを修 正しました。 検証環境に反映して、スペースのタイトルが黒い 事、ホバーしても色が変わらない事を確認してくだ さい。 Bさん担当で、できれば今日中にお願いします。 依頼されたConneのスペースの修正に関する確 認が完了しました。 14時頃にgitからとってきて、検証環境に反映し てテストを行いました。 スペースを確認し、タイトルの通常時の文字色 とホバー時の色が黒いままなことを確認しまし た。 Aさん Bさん
17. Step1と比較してこれだけの効果が - Aさんの内容追加による改善 - 誤って本番環境を確認しなくて済む - 何の修正を確認しないといけないかわかった - どういうテストをすれば良いかも依頼段階で分かった - 例えばvisitedの場合の色のチェックは不要か？という確認もできる - 期限のおかげで優先度も決められる - Bさんの内容追加による改善 - 14時（When）を加えたので確認タイミングがわかる - Aさんがログチェックしたりして追加の確認が出来る - テスト内容に齟齬が無いかも確認できる - 全然違うテストをしている可能性を下げられる
18. 次の課題 - くどい - 特に口頭の話題は情報量が多いほどヌケモレが発生する - 誰だエンジニアはくどい位が良いとか言ったやつは！ - 伝達に時間がかかると本末転倒 - 例は1往復だが実際は何往復も発生しうる - 他人の時間を奪いすぎない配慮
19. 意識したいことStep3：削ろう - Aさんの内容を削る - 共有されている前提は外しても良い （かも） - 例えばConneプロジェクトメンバー間の話なら、明らかに Conneの話 その場合冒頭の「Conneの」は不要 - 伝えるべき内容は必要に応じて外だし - バグや検証内容は口頭で伝えずチケットや issueに書いて共有すると良い - グループウェアやslackなどでやり取りするならテキストに残るのでこのままでも - 相手の手間を省けるような内容は口頭で伝えても良い
20. 意識したいことStep3：削ろう - Bさんの内容を削る - 明らかな手順は外しても良い（かも） - デプロイ前にgitから取ってくるのは普通では？と思ったら外しても良い - 手順上重要であれば省略すべきではない - チェック内容で合意がとれていれば省略しても良い （かも） - チケット等で手順が明示されていれば「チケット通り実施」で良くなる - 不安がある場合等は手順などをきちんと共有することが大事 - 口頭ではなくテキストでやるとなおヨシ！
21. Step3を踏まえて：これで行けたら最高かも チケット#100の修正が完了したので、検証環境に 反映してチェックしてもらえますか？ 手順はチケットにまとめてあります。 できれば今日中にお願いします。 14時頃にチケットの内容に従ってテストを行い ましたが問題ありませんでした。 結果をチケットに記入しました。 Aさん Bさん
22. あくまで一例 - 会話は高度な文化 - あくまで新山が心がけている事の例なので、もっと最適解があると思う - Step3の前にStep2があることを忘れない - 前提の共有が無ければStep2が最適解になる - シンプルな会話の前には、会話に載せるかの前提の検証がある - Step2の後Step3まで検討するかは人による（あんまりしないかも） - 「文脈」という凄くめんどくさいものを読む - 実際仲間内では、ここまでしなくても伝わることのほうが多い - 求められている情報を読んでやりとりする能力が必要
23. 会議で気にしていること
24. 会議のポイント - 会議の目的を踏まえる - ブレーンストーミングなど意見が重要な場では、意見を出す事が大事 - まとまってない意見でも、場の状況を見て出す - 出てきた意見を笑わない。そこから何か検討課題が無いかを探す - 進捗会議などでは報告内容が伝わることが大事 - 資料をまとめるなど、報告内容を参照しやすくする工夫を - 終盤に確認を取るなど、報告内容が浸透したことを確認する工夫を - 仕様検討・意思決定の場では合意と結論が大事 - 議事録に残すイメージで、相手に結論の確認を取る - 「改めて確認ですが、～という事でよろしいですね？」
25. 会議のポイント - 言質取得バトル会場 - 言った言わないや決議内容は武器です。大事にしましょう。 - 「あの時言いましたよね？」で相手を抑えられることも多い - ひっくり返されることもあるけど、相手が言ったことを翻している点は 今後やり取りする際につつけるし、踏まえたやり取りも検討できる - 自分に不利な言質は取られないように、慎重に - 議論誘導はデフォルトくらいに思っておく - 取りたい言質があればその話題・結論になるよう持っていくのが普通 - 相手の狙いを踏まえて、阻止したい場合はきちんとその旨述べる - 「誘導が悪」ではないので、乗ったり乗らなかったりすること
26. 取りまとめ （議事録・メモ） で気にしていること
27. 取りまとめのポイント - 会議は再確認しにくい - 録画などでフォローできなくもないが、基本的に会議を見直す事は前提としない - そうなると情報を記録する作業の優先度が最も高い。 メモスキルを磨こう - 話題の構造を捉える - 個人的にはツリー形式が一番わかりやすい - 何かの話題に対して回答が下がる - 回答や応答から更に回答や応答が下がる、の繰り返し - やりとりの対応関係がわかるような記録をする事が理想 - ただし内容がメモできていれば、配置・構造は後で修正することも可能
28. メモの取り方 - メモスキルの種類と優先度 - 1. メモ速度：最優先、早いほど良い。最初はとにかくなるべくメモを取って鍛える - 3. メモ整理：メモした内容を会議に沿って取捨選択するスキル。速度と合わせて鍛える - 3. リアルタイム取捨選択：会議の内容を聴きながらメモするか判断するスキル。上級テク - 出来ると効率的にメモが取れるが、後から整理しても良いので。 - 記録に取ってない話題は話してないのと同じ - 重要な内容は必ずメモする - 重要じゃない話題はメモしない - メインの議題・予め決めていた質問・結論に絡みそうなものは記録 - 自慢・武勇伝、雑談などは休憩時間（ちょっと大げさ） - 言いたいことに繋げる枕話だったり、雑談から新しい議論が生えることもあるので聞くことは聞く
29. メモの取り方 - メモの目的の違い - 記録することで言った・言わないを回避する、決定事項を把握する - 相手の情報を収集する - 議事録には載せないが、相手が興味があること、課題などはメモしておくと助かる - 優先度はメインの議題よりは下がる点にも留意。 - メモを取っていて本題を聞き忘れるなどが無いようにする - メモしきれないとき - 「すみません、少し記録させてください」でいったん止める - 「改めて確認させてください」「つまり～ということでしょうか」などを用いる - 再確認や整理をする体でメモできていないところの確認を取る - 相手も当然正しい議事録があれば欲しいので、協力しない事はあまりない
30. その他
31. まとめ - 相手のことを考える - 相手が敵か味方か、協力的かそうでないかなどを踏まえる - 相手がわかりやすいように過不足なく話す。不足よりは多いほうが良い - 会議は目的に合わせて話す。言質やネタを見逃さない - 話の構造を大事にする - 議論でもなんでも要点を掴む - どの話題がどの話題と関連しているかを把握する - 把握できるようにまとめる - 困ったら聞く - 分からないところは聞く - メモが追い付かない時は言う
32. おまけ：だれか読んで感想聞かせてほしい - 理系の作文技術 - https://www.amazon.co.jp/dp/4121006240 - 論文のテクらしいが理系必読とか聞く。読んだことはないけど - 漫画版もあるらしい - 日本語の作文技術 - https://www.amazon.co.jp/dp/4022618450 - 日本語の書き方の参考になるとかならないとか
33. 皆様の気を付けていること - 普段自分が何かを伝える時に気を付けている事 - 五段落エッセイ - 結論＋3つの理由を書く - 議題に上げたり - 結論を言った上で実際はこうするのが良いよ、と話をする 相手の人のレベルを探りながら、たとえ話・具体例を交える - 話を崩して聞き取りやすい感じにする - レベルに合わせて言葉を選ぶ - 自分の意見を持っておく - 相手を見ながら顔色をうかがう（相手の様子を見る） - 文字で伝わらない事を文字で伝えるのに頑張りすぎない - ★詳細をボイピ等でまわしたり、画像などを活用する - ※でも口頭でやってもテキストにも残したいよね - 長くなりすぎないように気を付ける - キャッチボールでカバーする - 議論の内容は全部メモって後から削除するタイプ - 書くほうは意識している - 「思います」は使わない - エンジニアとして不確かな内容はちょっとね
34. 皆様の気を付けていること - 言い方の工夫で伝わった／改善したなと思った実例 - 事前に「このことについて確認します」を準備して始めた - 初めて時間通りに終わった - 相手が「無理だろ？」と思ってるような議題に対して否定して実現できるよ、と主張した - 対等な関係であることをアピールできた - ほか感想など - メモッてて本筋の話を聞き逃すことはあるので気を付けたい - 長くなりがちで悩む - GSは議論が活発な分意見が飛んだりする - ★事前の作戦会議が大事 - 相手が知っている前提では話ししないようにしている - 議事録、書いて整理は大事 - 新人の時は何もわからないので何でもメモッていた - 慣れてきたので、逆に内容把握のために会議に耳を傾ける →メモがおろそかに - 聞いた内容を体裁よくまとめようとしすぎてしまう - 終わった後に整理すべき - プレゼンの構成、prep法使う - 日本語は背景から結論に入りがち - point→reason→example→point - OREOもある - pointがopinionになる - 弁証法的な考え方で行く - https://mba.globis.ac.jp/about_mba/glossary/detail-20813.html - 「一番伝わる説明の順番」という本が当たり前の内容を抑えていてとても良かった
35. 最後に
36. 宣伝 - 定期開催イベント - SRE本読会 - 次回1月末or2月 - 普段はSRE本読んでますが、次回はちょっと違う事をするかもしれない - 立ち飲み屋もんそ - 奇数月開催になります！曜日どうするかなどは検討中、意見求ム。 - 次回1月 - Pycon Boot Camp - 1/11 13:00～17:00 +Monsoにて開催！　懇親会もあるヨ - https://pyconjp.connpass.com/event/334755/ - 参加者、TA募集中！