円滑に事を進められるコミュニケーションって

メモっておくかーってという気分になったので書いている。

私は会社でアプリの新機能を開発したり、バグの修正を行っている。いわゆるエンジニアという職種で働いている。

新卒として入社した頃は「エンジニアって設計してコードを書くのが仕事でしょ」という考えを持っていたが、ミーティングや立ち話だったり、チャット上で色んな人とコミュニケーションを行うことが多いなと思った。

当時の私にはコミュ力の高いメンター*1がいて、その人のコミュニケーションの取り方が勉強になった。

実際にあったコミュニケーションの例

入社した当時私がいたチームは Product Manager (PM) や Customer Support (CS) という非エンジニアメンバーも所属しており、一緒に機能開発もしていた。

よく彼らがエンジニアへ質問をしていた内容を簡単に振り返ってみる。

Product Manager
- 実現可能性
- 開発スケジュール
  - スケジュール内で理想的な仕様をリリースできそうか
Customer Support
- プロダクトの仕様、細かい仕様（リリース前）
  - 問い合わせ内容が仕様かバグか
- インシデントが発生した時の対応方法（リリース後）
  - 影響範囲はどれくらいか
  - お知らせに〇〇という内容を含めてもいいか

メンターは同じチームにいて、色んな人とコミュニケーションをしていた。

PM とのコミュニケーション

ある時 PM からメンターへ実現可能性や工数について質問されていたが、メンターは

実現に必要なある部分がどうすれば実現できるか分からないことを伝える
- 把握するために時間がどれくらい必要か伝える
仕様を削れるとしたらどういった部分か PM に聞く

というコミュニケーションを行い、その時の話し合いを短い時間で切り上げて後日まとめて回答していた。

改めて思い返してみると、このようなメリットがあるんじゃないかと感じる。

分からないことも調査した上で、後日回答したほうが相手の時間も節約でき、的確な回答を行える
予めどの仕様を削れるか聞いておくことで、理想的な仕様と妥協した場合のスケジュールプランを提示できる
- 話し合う回数が減らせる可能性

そしてこのコミュニケーションは若干エスパーなところがある。それは「どの仕様を削れるか聞いておく」ことを思いつくかである。

PM が現状の仕様での「実現可能性」を聞いてることから、もし今の仕様が厳しい場合にその場で終わってしまうようなコミュニケーションを取ってしまうと、妥協案を考えてからもう一度エンジニアと同じようなコミュニケーションを取ることになってしまう。このことまで考えきれないと先程挙げた判断ができないだろうなと思う。

CS とのコミュニケーション

CS とのコミュニケーションは新機能をリリースする直前だったり、リリース後に発生したインシデントの対応方針についてだったりする。

個人的に CS との会話はインシデントが発生した時に行うことが多かったため、ここではそれに焦点を当てる。

インシデント対応のコミュニケーションはチャット上で行うことが多かった。チャットのインシデント対応部屋で CS から「お客様からの入信が〇件あります。このように対応しようと思いますがどうでしょうか」と対応方針がメッセージで送られてくる。

本来であれば「良いと思います」や「〇〇と答えておいてほしいです」など返信すべきだが、エンジニアとしては早く原因特定と修正もしないといけないため、修正方針だったり怪しい箇所はどこだのとエンジニア同士で会話を続けてしまう。そうなると最初に CS が質問したメッセージは埋もれていってしまい、質問を見失ってしまうことが多かった。

メンターはよくエンジニアと CS のファシリテーションをやっていた。

例えば、原因特定の作業をしてるエンジニアに

どんな状況なのか
どう修正できるか
どれくらいの時間がほしいか

を定期的に聞き、その内容を簡潔にまとめて CS にこのように伝えていた。

今がエンジニアが何をしているか
どんな回答ができそうか
文言の良し悪し

このおかげで CS の作業は、エンジニアからの回答待ち状態から開放され、本来やりたかった作業ができる。エンジニアも原因の特定や修正に集中ができる。

誰かがファシリテーションをしてくれるだけで、全体的に効率よく対応できるようになることを知ったのは驚きだった。