エンジニアのコミュニケーション能力
自分はおしゃべりの力や世間一般でいうコミュニケーション能力や雑談力は低いのだけど、プロダクト開発を早く進めて行くというコミュニケーションに関してはそこそこできると思っています。 そこで、自分が気をつけていることをちょっとまとめて見ようと思いました。
今回はチーム外とのエンジニアとのコミュニケーションに対して気をつけていることを考えてみました。
ほぼ全ての技術的な仕事は問題を解決するために、チームの外の人とコミュニケーションを取る必要があると思っています。 例えば、自分はプログラムが動く環境のOS全てスクラッチでプログラミングしていると行ったって、プログラミング言語を使っている時点でそのコンパイラーやインタープリターに依存しているわけだし、コンパイラーを作っている人だって、CPUやMemoryを作っている人とコミュニケーションすることはあるだろうし、CPU作っている人もその素材を作っている人とコミュニケーションすることはある気がします。
チーム内とは進捗や問題をほぼ毎日共有したりする単位。例えばスクラムで行ったら同じスプリントのタスクをやるようなイメージで、チーム外とはそのチームにいない人ということです。 私はアプリやWEBサービスを作る仕事をしていますが、社内、社外を含めlibraryの作者、サーバーなのどのインフラを提供してくれるチーム、連携するWEB APIの開発者など様々な人と一緒に仕事をしています。 マイクロサービスなどが流行ったこともあって、社内でもそういうコミュニケーションが必要な場面は多いのじゃないかなと思います。
心構え
- コミュニケーションの取り方次第で驚くほど柔軟対応してくれる
- 相手側はついついブラックボックスと考えがちだけど、内部構造や相手の事情を推測したりすることやまた同じエンジニアであることを意識する
- 自分と相手との関係は理解しておくといい
- もちろん全てのやり取りする相手を尊重するべきだけれど、やり取りすることで相手の時間を奪うことになるので相手がどれぐらい時間と労力を使ってくれそうかを考えてコミュニケーションするといいと思う 例えば、OSSの使用者と作者、有料サービスサポート付きのユーザーと提供側では使ってくれる時間と労力が違う
チーム外と連携を取る場面
- バグがありそうな時
- 使い方がわからない時
- 公式のドキュメントやFAQを読んだり、社外のものであればWEBで検索したり、社内のもの出れば社内のwiki的なこのを検索したりして解決できないか調べる
- 共同で開発する時
- 出来るだけ早く連携する
- 自分たちが必要と思う部分だけではなく背景も伝える
- リリース日に依存関係がある場合十分にバッファーを持ったスケジュールにする
コミュニケーション全般で気をつけること
- 曖昧さをできるだけ排除する
- やり取りの中で出てくるAPIなどは公式ドキュメントのリンクとともに伝える
- やり取りはログが残り形にする
- 使っている言葉が違うことがあるので相手の使っている言葉に合わせる
こちらに書いていることは、チーム外とのコミュニケーションに限らないことも多いと思いますが、チーム内であればもうちょっと雑でもいい気がしているので、個人的にチーム外の人とコミュニケーションするときに特に気をつけていることをあげてみました。
