Candy, Vitamin or Painkiller

He's half man and half machine rides the metal monster

「A Senior Engineer's CheckList」日本語訳

期のOKRを考えるにあたって見つけた記事が面白そうだったので、勉強を兼ねて日本語(超)訳してみました。
「翻訳してよい？」と著者にメールで尋ねたところ、「Go ahead!」と爆速で返信をいただきました。感謝🙏

元記事は各項目のカテゴリやインパクトなどでのフィルタリングができるリッチなフォーマットです。

littleblah.com

誤訳やより良い表現がありましたら、@todokrまで連絡いただけるとうれしいです:D

シニアエンジニアのチェックリスト

これはシンプルなチェックリストだが、どんなソフトウェアエンジニアにも役に立つ。特にシニアエンジニアに。

  1. 自分の仕事のビジネス的側面、そして何がお金を生んでいるかを理解すること。結局はこれが唯一の問題。
  2. 自身のチームや企業の採用活動に巻き込まれること。優れた候補者を採用するための高い基準を整備すること。
  3. 規模と拡張性、問題の範囲にふさわしいシステムをデザイン・開発すること。オーバーエンジニアリングを避ける。
  4. 問題と事態の核心にたどり着くまですべてに質問し、「なぜ」について繰り返し尋ねること。
  5. 責任とオーナーシップを他者から引き受けること。
  6. 会社が求めることを理解し、明確な像とよいデリバリ計画を持った、インパクトのあるプロジェクトを最低一つは率いること。
  7. ふわっとした課題をクリアにするよう努力すること。
  8. 他のチームとの関係を築き、信用を育てること。
  9. 自身の見解に固執しないこと。他者に耳を傾け、問題の見方や有効な解決策が複数あることを受け入れる。
  10. いくつものプロジェクトに助言者、レビュワー、メンターとして巻き込まれること。
  11. 「エクストリーム・オーナーシップ」の原則に従うこと。 (訳注: おそらくこのトークで話されていることか Extreme Ownership | Jocko Willink | TEDxUniversityofNevada - YouTube)
  12. 強力なメンターを持ち、自身の舵取りと会社での成長を支援してもらうこと。
  13. 高いリスク、高い見返りのあるプロジェクトに取り組むこと。
  14. 自分のチームが使っている技術についての高い専門性を持つ努力をすること。
  15. マネージャーに、ストレッチが要るプロジェクトを要求すること。またはそのような自分向けのプロジェクトを探す手伝いをすること。
  16. マネージャーのゴール、そして自身の仕事をそれにどのように適応させるかをマネージャーと議論すること。
  17. 先輩、同僚、後輩との関係性を育むために、時間を効果的に投資すること。
  18. 何人かのジュニアなエンジニアのメンターになること。
  19. 自身のチーム/企業のドメインについての知識の幅を広げること。
  20. 1on1を率先すること。次回の1on1にむけてトピックリストを管理すること。
  21. 予め解決案を持ったうえで、マネージャーと問題について議論すること。
  22. 技術的な知識の幅を広げること。
  23. 小さなプロトタイプを作り、新しい技術を調査すること。
  24. 毎年何冊かの技術書を読むこと。
  25. キラキラした大きめの新技術の本番投入を提案する前に、その長所と短所を徹底的に理解すること。
  26. マネージャーとの定期的な1on1を設定すること。
  27. 2階層上のマネージャーとの定期的な1on1を設定すること。
  28. [リマインド] 1on1は状況報告ではない。
  29. マネージャーを私生活に巻き込むこと(ちょっとだけ)。
  30. マネージャーからのフィードバックを積極的に求めること。
  31. 自身が関わっていることについて、マネージャーに都度伝えること。だが不必要な細部にこだわってはいけない。
  32. 自身の仕事をブロックするものについて、マネージャーに都度伝えること。
  33. 一緒に働くことが難しい人について、マネージャーに都度伝えること。
  34. マネージャーに建設的なフィードバックをすること。
  35. オーバーワークをしているなら、それをマネージャーに知らせること。
  36. 自身の能力を活用できていないなら、活用できる領域を見つけてもらうようマネージャーに頼むこと。
  37. もし無能だったり怠慢なマネージャーを持ったなら、マネージャーに自身の期待を伝えること。
  38. もしマイクロマネジメントをするマネージャーを持ったなら、マネージャーに自身の期待を伝えること。
  39. もし暴言を吐くマネージャーを持ったなら、証拠を持って2階層上のマネージャーや人事部と話すこと。
  40. もしマネージャーも2階層上のマネージャーも無能なら、チームや会社を変えること。
  41. もしマネージャーとの間に心のこもった関係性がないなら、チームや会社を変えること。
  42. [リマインド] レバレッジ = 生んだインパクト/使った時間。 レバレッジを効率の物差しとして使う。
  43. 改善したい対象を測定すること。測定可能になるよう努力すること。
  44. 高いリスクを持ったプロジェクトの「見える化」レベルを高く保つこと。
  45. 困った人たちを扱うために、マネージャーやメンターと話すこと。
  46. 困った人たちを扱うために、最初の原則に戻ること。
  47. 他のエンジニアが自分に接触できるようにしておくこと。
  48. デリバリに大きく傾いたとしても、品質について妥協しないこと。必要があれば突き返すこと。
  49. コードやシステム、アーキテクチャを絶え間なくシンプルにすること。
  50. 高い品質の仕事を他者に求めること。ただし現実的でいること。
  51. 開発のコストが増加を続ける場合、コードやシステム、アーキテクチャの技術的負債の返済を優先すること。
  52. 広範囲をドキュメント化し、それを他者にも求めること。"how"より"why"を記述すること。
  53. 政治を避けること。ただ自分の仕事を保証する適切な人を持つこと。
  54. 政治的な問題を扱う時には、最初の原則に戻ること。
  55. もしチームや会社の文化のせいで政治がはびこるようなら、チームや会社を変えること。
  56. オフィスのゴシップに巻き込まれないようにすること。
  57. 余力がなさすぎる状態を避け、成果を出すこと。
  58. 前からあるコードやシステムに敬意を払うこと。プロダクションの全てのコードや安全装置には理由がある。
  59. 大規模なリファクタを提案する前に、自身がシステムを深く理解しているかを確かめること。
  60. 主要なシステムをシンプルにリファクタしたくなる衝動に抵抗すること。結局はしばらくしてから同じように複雑なシステムになってしまうリスクがあるため。