優秀なエンジニアはアーキテクチャについて意見が異なります。それは健全なことです。TLの仕事は、議論に勝つことではなく、意見の相違を良い決定とコミットしたチームに変えることです。ほとんどの紛争は、みんなが基準に同意すれば解消します。
なぜ重要なのか
text
1. AGREE on the criteria first — what are we optimizing for?
(scale, simplicity, time-to-ship, team familiarity)
2. Let each side make its STRONGEST case — steelman, don't strawman
3. Look for DATA — spike it, benchmark it, prototype it
4. If still tied — the TL decides, and explains why
5. DISAGREE AND COMMIT — once decided, everyone rows together
具体例
2人のエンジニアがマイクロサービス対モノリスについて議論しています。あなたは次のように再構成します:「来年、何を最適化しようとしていますか?」という答えは、小さなチームで素早く出荷することであり、モノリスが明らかな選択肢になります。議論は本当は述べられていない目標についてでした。
決定するべき時と延期するべき時
可逆的な決定については、素早く決定して先に進みます。決定を誤るコストは小さいです。一方通行のドアについては、速度を落とし、データを集めます。熟慮を可逆性と照らし合わせることで、自転車小屋の問題と無謀な決定の両方を回避できます。