設計でチームの意見が割れたら、どう決めますか

こう聞かれます

• 「設計の方針で、メンバーの意見が 2 つに割れたら、どうしますか」
• 「自分の案と、経験のあるメンバーの案がぶつかったら」
• 「全員が納得しないまま決めたことはありますか」

面接官が見ている点

• 好みや声の大きさではなく、物差しをそろえて比べているか
• 話し合いを終わらせて、期限までに決めきれるか
• 決めたあと、反対した人も含めてチームが動けるようにしているか

短い答え

• 案を比べる前に、今回なにを大事にするか (速さ、変えやすさ、運用の手間など) の物差しをそろえます。
• 案ごとの得失を並べ、事実で決まる所は小さく試して確かめ、決める期限と決める人をはっきりさせます。
• 合意できなければ理由を添えて自分が決め、選んだ理由と退けた案、見直す条件を記録に残します。

少し詳しい答え

よくある間違い

• 多数決で決め、少ない側の心配を記録しない心配が当たったときに、見直すきっかけがありません
• いちばん経験の長い人の案に、理由を聞かずに従う物差しで比べていません
• 全員が納得するまで、期限を決めずに話し合ういつまでも決まらず、作業が止まります
• 反対した人を、決まった案の実装から外すチームが割れたままになります

深掘りの問い

• 「決めた案が失敗だと分かったら」記録した見直す条件に当たったら早めに戻し、だれが決めたかではなく判断の流れを振り返る、と答えます
• 「あなたの案が負けたら」物差しで比べて負けたなら、その案で全力で進め、心配は見直す条件として残す、と答えます
• 「上の人の意見とチームの意見が割れたら」同じように物差しをそろえ、得失を並べて上の人に判断してもらう、と答えます

関連するコースと用語

• 決定を残す
  コース「System Design入門」
• 捨てたものを言う
  コース「System Design入門」
• 制約
  コース「System Design入門」

用語集で確かめる言葉は、トレードオフ、アーキテクチャ、非機能要件です。