Qiita Night〜エンジニア×非エンジニアのコミュニケーション〜のイベントレポート

メリークリスマス🎄
アドベントカレンダー最終日ですが、アドベントカレンダーは25日を過ぎても過去の日付に遡って記事紐づけが可能です！
たくさんの紐づけ、投稿お待ちしております！

# 本記事の概要
- 2023年11月17日に開催された[Qiita Night〜エンジニア×非エンジニアのコミュニケーション〜](https://increments.connpass.com/event/297115/)のイベントレポート
- 当日は運営として参加したので、改めて皆様の発表を元に自分の学びを記事化

## ライブ配信のアーカイブ

<iframe width="560" height="315" src="https://www.youtube.com/embed/UiXQ5VECi9w?si=qJdhEchUh51G3B7C" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

# LT
- 非エンジニアとのコミュニケーションアンチパターン / @kinchiki 
- 類推化と定量化でつなぐ、非エンジニアとエンジニアによる開発指標を用いたコミュニケーション / @dai___you 
- エンジニア秘書が通訳する異文化コミュニケーションのあれこれ / @assu_ming 
- 要件を理解するために、非エンジニアと一緒に業務をこなした話 / @ysknsid25
- HRtechのPdMがプロダクトドリブンなBizDevコミュニケーションを実現するために取り組んだこと / @ryosuke77777 

# 非エンジニアとのコミュニケーションアンチパターン
- スピーカー：@kinchiki 
- 所属等：株式会社リンクバル SREエンジニア

## メモ
- その1：相手の知識を考慮せずに専門用語を使ってしまう
    - なぜよくないのか→**伝えたいことが相手に伝わらない**
        - 相手からの印象・評価が悪化する可能性も
        - 最悪の場合...「あの人はわからないことを言うから避けてしまう」となる場合も
    - どうすればよいか？
        - 相手の知識を考慮してコミュニケーションしよう
            - 相手が知らなそうな用語は使わない、または理解を確認する
            - 最初から専門用語は使わずに、伝わるように言い換える
            - 相手の立場で考えるべし
- その2：非エンジニアがいる会議で技術的な話の深掘りをしてしまう
    - なぜよくないのか→**その場の非エンジニアの時間が無駄になる可能性が高い**
        - エンジニアが実装の詳細を話しは始めるなど...
        - 「他で詰めてもらっていいですか？」は意外と言いづらい
    - どうすればよいか？
        - 技術的な話の深掘りは極力さける
            - 技術的な話は別で、もしくはさっと
            - 相手の立場で考えるべし
- その3：結論から話さない/質問に答えない
    - なぜよくないのか→**コミュニケーションが長引くから**
        - 結論の前の説明は頭に入りづらい
        - 質問に答えないと、質問者は知りたい情報をしれない
    - どうすればよいか？
        - 結論から伝える/質問に答える
        - 相手の立場で考えるべし
- すべてに言えること
    - **相手の立場で考えよう！**
        - お互いの歩み寄りが大事
    - ぶっちゃけエンジニア関係ない

# 類推化と定量化でつなぐ、非エンジニアとエンジニアによる開発指標を用いたコミュニケーション
- スピーカー：@dai___you 
- 所属等：ファインディ株式会社

## メモ
- なぜ、エンジニアと非エンジニアのコミュニケーション`むずかしい`のか
    - 事業活動における業務範囲がちがう
        - 作るプロセスには複雑性が伴う※他のプロセスも複雑ではある前提
        - 扱っている言語がちがう
            - 非エンジニア「なんもわからん」
        - 感覚がちがう
            - 非エンジニアは外側から見たシステムの様子しかうかがい知れない
            - エンジニアはCTスキャンを通すように内部の構造を理解している
        - 問題例：技術的負債の解消
            - 営業は営業プロセスでリードタイムを短縮（PL的）
            - エンジニアも開発のリードタイムを短縮（BS的）
- `むずかしさ`と向き合うためにはどうすればよいのか
    - 言語の違い→類推化
        - 抽象化すると、ほとんど業務プロセスは変わらない
            - インプット→スループット→アウトプット
        - エンジニアが言うところのPRを作成するとは、セールスプロセスでいうと提案書作成なんだな、と感覚的にわかる
            - コードコミット・PR≒提案書
            - レビュー・修正≒提案
            - マージ・デプロイ≒受注
    - 感覚の違い→定量化
- 類推化と定量化でつなぐ、非エンジニアとエンジニアによる開発指標を用いたコミュニケーション

# エンジニア秘書が通訳する異文化コミュニケーションのあれこれ
- スピーカー：@assu_ming 
- 所属等：株式会社ZOZO

## メモ
- はじめに
    - エンジニアだから偉い、エンジニアじゃないから話が通じない...という思い込みはない方がすべて円滑に進む
- こんなことありませんか（エンジニア、非エンジニアそれぞれの立場から）
    - 上からの指示で旧に納期早まった
    - こっちの改修を先にやったほうがいいのに
    - 上流のMTG参加させてくれ
    - 経費精算とか社内規定とか読むのもやるのもめんどい
    - エンジニアこわい
    - よくまわらないけどなんかすごい！こっちもやって！
    - ちょっと何言ってるかわからない、テキストにして/直接話して
- 異文化コミュニケーションとは
    - 文化や価値観の違いがある中での交流
        - 立場特有の曖昧な表現、発言の仕方や内容の違い
    - 最も大切なこと
        - 相手との相違点を客観的に見て理解・尊重
        - 文化や相手を否定しないこと
    - いつ・どこで
        - ビジネス部門（営業・企画）
        - バックオフィス部門（総務・経理・人事）
        - カスタマーサポート部門
    - 異文化でモヤるのは？
        - お互い周囲の環境が違うから
        - どう対処する？
            - 個性として受け止めましょう
            - 歩み寄りましょう
- お互い試してほしい解法
    - 共通
        - 相手は敵じゃない
            - 全員見方
            - わからないことは素直に聞く
            - 聞ける雰囲気を作る
    - エンジニア→非エンジニア
        - 情報の構造化・自動化・効率化
        - 図を使った視覚的表現にトライ
        - ならではの指摘、どんどんする
    - 非エンジニア→エンジニア
        - 情報の構造化にトライ
        - 優先度の明確化・スケジュールの早め共有
        - エンジニアの成果をFB
- 明日からできること
    - ランチ会・Coffee Chat
    - Slackでtimesチャンネル作成
    - リアルタイムでの議事録共同編集
- 目指す世界
    - 見方を増やすこと
    - 適度な関係性を作りつつ、お互い良いFBを惜しみなく共有

# 要件を理解するために、非エンジニアと一緒に業務をこなした話
- スピーカー：@ysknsid25
- 所属等：虎の穴ラボ株式会社

## メモ
- 背景等
    - アパレル企業のシステム開発時にドメイン知識を有していたPdMが産休、育休に
    - 先方社長の提案で実際に現場で働いてみることに
- 非エンジニアと関わる上で、エンジニアが意識すべきこと
    - よく話を聞く
    - 開発速度
    - 技術寄りの話をしすぎない（技術力が１番大事なのは間違いない）
        - 非エンジニアにとって恐怖or関心がないことかも
        - 身近ななにかに置き換えて話してあげる
        - 技術を使うこと＞ユーザーの欲求になりやすい
- 非エンジニアはエンジニアに何を求めているのか
    - 改善
        - 技術スタックにはあまり関心がない
        - 技術スタック等の話はエンジニアしかいない場で
        - 改善があるかどうかがすべて
    - 安心感
        - 自分たちの話を聞いてくれること
        - 自分たちにもわかるように話をしてくれること
- まとめ
    - エンジニアは生産性、拡張性、保守性、再申請、ゆとりある開発工数を求める
    - 非エンジニアは素早い改善と安心感を求める
    - 両者の考え方はトレードオフなので、どこまで歩み寄れるか
    - 信頼関係が大切
    - 相手の話をよく聴き、相手が理解できるように話すこと

# HRtechのPdMがプロダクトドリブンなBizDevコミュニケーションを実現するために取り組んだこと
- スピーカー：@ryosuke77777 
- 所属等：株式会社HRBrain プロダクトマネージャー

## メモ
- プロダクトドリブンな状態とは
    - 顧客がまだ気づいていない課題を発見し、顧客のニーズを満たすために、エンジニア・デザイナー・セールス・CSなど組織一体となって、プロダクトをあるべき姿に進化させている状態
- タックマンモデルを参考に組織・コミュニケーションを構築してみよう
    - 組織の成長段階を示すモデル
        - 形成期→混乱期→統一期→機能期→散会期
- 形成期の取り組み
    - 課題：
        - 各職種で相互のことを怖がっているのでは？
        - どんなコミュニケーションを取ったらいいかわかってないのでは？
    - 思考：仕事を通じたコミュニケーションの親睦を図ろう
        - 同じ目的を持つ仲間であることを理解
        - 同じ人間であることを理解
    - 施策：
        1. ドラッカー風エクササイズ
        1. プロダクトに期待する思い、どんな組織でありたいかを書く職種目線から共有する会
        1. 他職種に期待したいことを共有する会
    - 結果：
        - 他職種に貢献できそうな領域を知ることができた
        - それぞれに共感するエモい時間に
- 混乱期の取り組み
    - 課題：
        - 何を目指すかの理解がそれぞれ異なる解像度
        - 議論次第では何を話していいかわからなくなってしまう
    - 思考：
        - 共通の絵を同じ解像度で見るためにプロダクトビジョン策定に巻き込んでしまおう
    - 施策：
        - プロダクトビジョン策定の検討段階から巻き込んだ
        - 議論内で「自分が持つ専門性から見てどう思いますか？」と意図的に問いかけた
    - 結果：
        - プロダクトビジョンが完成
        - 各職種の相互理解促進、情報共有の活発化
        - 今ではプロダクトロードマップをエキスパートが率先してBizサイドに安全に説明してくれている
- まとめ
    - タックマンモデルを参考に、状態の整理と施策を検討
        - →想定通りに心理的安全性が作られていく実感、自分の精神的にも後手にならずに組織運営できた
    - 自身持って発言できるよう意図的に役割の帽子を被せて話を振った
        - →ファシらなくても職種間で勝手に議論が盛り上がるように、共通の目的が揃っているのでポジショントークでマウント取ることもない

# 今後のイベントについて
2023年も多くの方にイベントに参加いただきました、ありがとうございました！
Qiitaは2024年もエンジニアの皆さまにお楽しみいただけるイベントを開催予定です！

https://qiita.com/official-events