ダイニーの urahiroshi です。
自分は前職のメルカリ、現職のダイニーで計3年くらい Engineering Manager を務めてきましたが、Engineering Manager の本質的な役割は「チームや組織のパフォーマンスを最大化すること」だと考えています。そのためには、チーム開発におけるメンバー間のスムーズなコミュニケーションが不可欠です。
これまでコミュニケーションに関するフィードバックを行ってきた中で、よく見られる改善点がいくつかあったため、それらをベストプラクティスとしてまとめてみました（それぞれのセクションで一つずつ本が書けるくらい多数のプラクティスが挙げられるテーマだと思いますが、特に頻出するポイントに絞っています）。皆さんのチーム開発にも役立てていただければ嬉しいです！
レビューをするときのプラクティス
指摘にはWhyを書き、Howを押し付けない
❌️ Bad
レビューコメント:
ここで
Promise.all()は使わずに、Promise.allSettled()を使って、失敗した処理だけリトライしてください。
✅️ Good
レビューコメント:
Promise.all()の中で不安定なAPIを呼び出しており、一定確率でエラーが発生します。一部の処理が失敗しても他の処理の実行を継続し、失敗した処理だけリトライしたいため、Promise.allSettled()を使うのはどうでしょう。
💡 ポイント
- Why の部分で共通認識がなければ、How として提案された内容が正しいのか適切に議論することができません
- レビューコメントに Why の記載がないと、レビューを受けた方が Why を推測して作業を進めることになり、コミュニケーションミスのリスクが生じます。レビューを受けた方が Why を確認することもできますが、レビューを書く時点から Why を明記しておくのが最も確実です
- 「これは書かなくてもわかるはず」という思いもあるでしょう。明らかに自明な場合や、共通ルールとして明文化されている場合はよいかもしれませんが、そうでない場合はレビュー時に明記するのが効率的で確実です
- また、プルリクエストのやり取りは、将来的に第三者が「なぜこのコードがこう書かれているのか」を確認する際の参考資料となることも多いです。その時点では、レビュー当時は当然と考えていた前提（上記の例では、不安定なAPIを呼び出しているという状況など）が変わっているかもしれません。明示的に Why を記載したレビューコメントは、そうした場合でも有用なドキュメントとして機能します
なお、Why を書くというのは Google のコードレビューガイドラインにも記載しています。Google のコードレビューガイドラインはこの点以外にも網羅的にコードレビュー上のポイントを記載しているので、まだ見たことがない方はぜひ一読してみてください。
(上記の逆パターン) 指摘を受けたら Why について理解し、その上で How を議論する
❌️ Bad
レビューコメント:
ここで
Promise.all()は使わずに、 順番にawaitを使って処理してください。
返信:
順番に
awaitを使うと処理時間がかかりすぎるので、Promise.all()のほうが良いと思います。
✅️ Good
レビューコメント:
ここで
Promise.all()は使わずに、 順番にawaitを使って処理してください。
返信:
awaitを使うのはエラーハンドリングのためでしょうか？順番にawaitを使うと処理時間がかかりすぎるので、Promise.allSettled()で失敗した処理だけリトライできるようにするとどうでしょう？
💡 ポイント
- レビューコメントには常に Why が書かれているべきですが、実際には Why が書かれていないコメントを受けることも多いため、その対処法となります
- 指摘された How（この場合、
awaitを使う）に納得できない場合、すぐに反論したくなるものです。しかし、Why の共通認識がないまま How を議論しても余計な衝突を招いてしまい、時間の無駄になってしまいます。まずは「この指摘の背景にある理由は何だろう？」と考え、それを確認して共通の課題認識を持てることから始めましょう
議論をするときのプラクティス
チームとして共通の方向性を持てることを目指す
❌️ Bad
この機能はユーザーの体験を向上させるので、優先すべきだと思います。
✅️ Good
この機能は、チームのOKRである『ユーザーの注文時間短縮』に直結するので、優先度を上げるべきではないでしょうか？
💡 ポイント
- 議論が起きるのは、議論している内容について組織やチームとしての共通認識が定まっていないからです。「Aさんの意見 vs Bさんの意見」となるのではなく、組織・チームとしての優先度や共通認識を持てることをゴールとするため、チームとして共通で持っている目標や価値観をベースに議論を行いましょう
- チームとして共通の方向性を定めるにあたって、そのテーマに関するオーナーシップや責任を持つメンバー (通常、チームのリーダー・マネージャーなど) の意思決定が必要になる場合は、チームとしてのトレードオフを整理したうえで意思決定を仰ぎましょう
- Disagree and commit という言葉があり、意思決定を行う際には議論を尽くし、チームとして意思決定した後は（たとえ元々その方針に反対していたとしても）それにコミットするという意味のものですが、その前提になっているのは「チームメンバーに意思決定における背景が充分に伝えられ、反対意見を述べることができる」という環境です。こうした環境が作れたうえで、全員がチームを主語として活発な議論ができることが一種の理想像であると考えています
すれ違いの解消は同期コミュニケーションで行う
- これまでに挙げたような点に気をつけていても、 Slack や GitHub で議論をしていると、何かがすれ違ったまま議論が平行線になってしまうことがあります
- すれ違いの解消は非同期のコミュニケーションでは時間を浪費しすぎてしまうため、直接話すなどして早めに同期的なコミュニケーションでの議論に切り替えることを提案しましょう
- 同期的なコミュニケーションの中身は他のメンバーには見えないので、最終的に方向性が定まった場合は、議論をしていたスレッドなどに議論の要約・結論を記述すると良いです
報告・連絡・相談をするときのプラクティス
チャット上のコミュニケーションは public で行う
❌️ Bad
(Slack の DM で送信)
「新しく追加する xx 機能の仕様について確認させてください。」
✅️ Good
(Slack の public チャンネルに送信)
「@xxx 新しく追加する xx 機能の仕様について確認させてください。」
💡 ポイント
- public にすることで他のメンバーにもコミュニケーションが見えるようになり、複数のメリットがあります
- 同じ問題に関心を持ったメンバーが議論を参照することができる
- 他のメンバーを議論に巻き込むことが必要になった際に、簡単に巻き込むことができる
- メンションした人がすぐに対応できない場合でも他の人が対応できるケースもある
- 上記のメリットと比較して、DM などでコミュニケーションを隠すことのメリットはほとんどないので、基本的にすべてのコミュニケーションは public で行うことを意識できると良いです
- もちろん、個人情報やセンシティブな情報が含まれる場合は DM や private チャンネルを使いましょう
問題を抱え込まず、Working Out Loud する
❌️ Bad
- 何か問題に突き当たり、自分で解決しようと時間を費やしたものの解決せず、他の人に聞くとすぐに解決した
✅️ Good
- 15分など時間を決めて自分で調べてみて、それでも解決の目処が立たなければ他の人に聞く
✅️ さらに Good
- 「これからやること」「今やっていること」「今考えていること」を全部 public なチャンネル (作業スレッドなどでも良い) に書き出しながら作業を進める
- 明らかに他の人に聞かないとわからないケースの場合、その中で他の人をメンションして質問する
- 「既知の問題かも知れないが、まず自分で調べて、だめなら他の人に聞こう」と思ったとき、それを public なチャンネルに書き出すことで、自分で調査を進めつつも既知の問題であれば他の人からフォローが入れられるようにする
(Slack の public チャンネルに送信)
local でモバイルオーダーのアプリをビルドした時に以下のようなエラーが出て失敗してしまう。もう少しエラーを調査してみます{エラーメッセージ}
(15分後の投稿)
しばらく調べてみて、以下のことを試したがだめでした。
- {試したこと1}
- {試したこと2}
- {試したこと3}
@xxx すいません、こちらどなたか同じようなエラーになったことがある方はいるでしょうか？
💡 ポイント
- チーム開発において、問題を一人で長時間抱え込むのは一番避けるべきポイントです
- 一方で、何でもすぐ他の人に聞いていると、自分で問題解決するスキルも養われなかったり、人や課題によっては「もう少し自分で調べてほしい」となります。ケースバイケースなので塩梅が難しいです
- 一般的なプラクティスとしては「xxx 分は自分で調べて、解決の目処が立たなければ人に聞く」というアプローチですが、実際どれくらい調べる時間が必要かは本人のスキルや発生している問題の難易度によりまちまちです
- どういうケースでも使える方法は、自分の考えやアクションをすべて書き出しながら作業を進め、問題を共有しつつも自分が調べているといった情報をリアルタイムに伝えていくことです。他の人が必要に応じてフォローも出せますし、最終的に他の人に聞く場合も自分の試行の過程を伝えることができます。また、こうした試行の過程が、同様の問題に突き当たった人へのヒントにもなり得ます。これは Working Out Loud というプラクティスを用いたもので、以下の記事も参考にしていただけると良いです
相談と一緒に提案をする
❌️ Bad
コメント:
A 案と B 案、どちらが良いでしょうか？
- {A案の内容}
- {B案の内容}
✅️ Good
コメント:
A 案と B 案、どちらが良いでしょうか？
- {A案の内容}
- {B案の内容}
A 案と B 案を比較した場合、特に {良い点1} の部分が … の点から重要度が高く、逆に Cons は大きい問題ではないので A 案が良いと考えています。
A 案の Pros:
- {良い点1}
- {良い点2}
B 案の Cons:
- {悪い点1}
- {悪い点2}
💡 ポイント
- 自分より上の職位のメンバーが決める必要がある物事であっても、あなた自身が状況やモチベーションを把握しているなら、自分自身の意見を添えて質問できるとよいです
- 自分自身の意見を述べるために、より情報を整理する必要が出てくるため、質問された方もより回答がしやすくなります
- また、質問するあなた自身が意思決定に関する学びを得ることができます
ミーティングをするときのプラクティス
人を批判せず、プロセスを改善する
❌️ Bad
ミーティング中のコメント:
この時間帯判定において、0時をまたがった場合の考慮が抜けており、バグにつながってしまいました。レビューやテストもすり抜けてしまったので、もっとしっかりレビューやテストをしていただきたいです。
✅️ Good
ミーティング中のコメント:
この時間帯判定において、0時をまたがった場合の考慮が抜けており、バグにつながってしまいました。時間帯のロジックについては手動でのテストが行いにくいため、必ずユニットテストを実装するなどで対応するのはどうでしょうか？
💡 ポイント
- 「気をつける」みたいな振り返りは具体的な改善になっていないので、仕組みやプロセスとして改善できるアクションがあるかをまず考えましょう
- 個人の成長のためのフィードバックの意味で「気をつけて」と言いたくなるケースはあるかもしれませんが、個人に対する改善点のフィードバックは他の人が参加しているミーティングの中ではなく、DM などで個別に行いましょう
- ポジティブなフィードバックは多くの人が見ている中で、ネガティブなフィードバックは1対1で、というのも一つのプラクティスです
- 「気をつけて」というのはフィードバックとしても具体的ではないのであまり効果的ではないです。個人としてのミスが起因するものであれば、ミスが起きるまでのプロセスに着目して改善のアクションを考えられると良いでしょう
- その他、フィードバックに関してはあらゆる本やWebサイトなどでベストプラクティスが紹介されています (例: https://asana.com/ja/resources/tips-giving-feedback)。特にネガティブに受け止めかねられないフィードバックは逆効果になるケースもあるため、こうしたドキュメントを一読したうえでフィードバックを行えると良いでしょう
非同期でできることは非同期でやる
❌️ Bad
1時間の定例ミーティングのうち、30分くらいは情報共有に使われており、残り30分が議論に使われている。
✅️ Good
ミーティングを30分とし、情報共有は事前に議事録に書いておいて議論したい事柄だけをミーティング内で扱う。
💡 ポイント
- ミーティングは参加者全員の時間を強制的に奪ってしまいます。情報共有は非同期でもできるので、ミーティングはミーティングでしかできないことに時間を使いましょう
- 議事録などに書いているだけだと誰も読まない、という問題もあるかもしれません。それで諦めてミーティングにするのではなく、どうしても知ってほしい情報は Slack などでメンションするなど、別の方法がないか考えてみましょう
- ミーティング内での情報共有中に議論すべき点が見つかることが多い場合、情報共有が非同期になることでそれが見過ごされてしまうというリスクはあります。上記のようなケースが多い場合、どういう内容を議論・共有すべかを議事録のフォーマットで明示的にするなどの対応も行えると良いでしょう
- 組織として「口頭で解決する」が多くなることは、見えない属人化を促進している (議論すべき観点が特定の人しか持てていないなど) 側面があり、それに対処するという意味合いもあります
- また、情報共有のためだけに参加しているメンバーは任意参加とするなど、ミーティングの参加人数も極力絞れるとよいです
We’re hiring!
ダイニーでは、Frontend, Backend, Native App まで 全方位で TypeScript を用いて飲食業界向けのマルチプロダクト開発を行っています。飲食業界の課題を解決したいという熱い気持ちをもったメンバーが集まっていますので、事業や技術、組織に関心がある方はぜひ一度お話しましょう。
Discussion