小さなごちそう

プロダクトマネジメントや日々の徒然について

良いテックリード、悪いテックリード

本記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。


この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。
ベン・ホロウィッツの「良いプロダクトマージャー、悪いプロダクトマージャー」からインスピレーションを得ている。

チームワーク / Teamwork

良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだと考える。面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにする。チームの技術的能力を拡大し、システムの重要な知識が属人化しないように務める。

悪いテックリードは注目の集まる仕事で自分の成果を示すことを好む。その成果は部分最適に留まり、開発チームのアウトプットを増やすにはエンジニアの人数を増やすしかない、という状況から脱することができない。

技術的ビジョン / Technical vision

良いテックリードは技術の方向性について俯瞰したビジョンを持ち、それをチームが正しく理解できるように努める。良いテックリードは他のチームメンバーに権限を委ね、主要な事項に関してはメンバー自身の意思決定を促す。良いテックリードはチームメンバーは賢く信頼に足ると信じてプロジェクトの重要な部分の取り扱いをチームメンバーに委ねる。

悪いテックリードは説明責任を果たしたり方針を言語化して伝えることを嫌がり、自分の決定にただ従うように命令する。彼らは組織で共有すべき知識を抱え込む。ドキュメントを作って知見を広め、自分と同じくらい効率的に仕事を進められる人材を増やす、といったような活動をしない。

議論 / Discussion and debate

良いテックリード聞く耳を持ち、議論を促す。チームの議論が紛糾して収集がつかないときは、問題を解決するための考え方やフレームワークを示し、チーム自身で解に到達できるように助ける。過去の議論を蒸し返すようなことはせず、チームの出した結論の方が自分のアイデアより優れていると思った時はそれを認めて受け入れる。

悪いテックリードは結論がなかなか出ない議論をそのまま放置して、チームの生産性を損なう。あるいは「それはもう議論済みで結論が出てる」と言って議論を途中で遮る。悪いテックリードはチームが正しい結論に到達することよりも自分が議論に勝つ事を重要視する。

プロジェクトマネジメント / Project management

良いテックリードは先を見越して行動する。彼らは技術課題の解決が予定通り進捗していることを確認する。良いテックリードはチームと一緒に見積もりを行い、中間マイルストーンをたてる。懸念事項を予め明らかにし、問題が実際に起こる前に言及する。技術的な障害を特定してチームで問題解決に当たれるようにする。全体を見て同じタスクを重複して行わないようにし、逆に、注力できていない部分を見つけ出してリソースをきちんと振り分けられるようにする。

悪いテックリードは問題が起こってから対処する。彼らは権限を委譲するがその後進捗に問題ないか確認してフォローしようとはしない。中間ゴールを設定しないし、ちゃんと良い結果が生まれるかどうか気にかけず、複雑なエンド・ツー・エンドのテストを行う直前まで何もしない。興味深いものだがさして重要ではない仕事に時間を浪費することをチームに許してしまう。

f:id:tannomizuki:20180222175113j:plain
@blackmadによる素晴らしい漫画化

悪いテックリードは「その問題は解決済みだ」と言う 良いテックリードはディスカッションを促す
悪いテックリードは手柄を自分のものにしようとする 良いテックリードはチームの能力向上に努める

現実主義 / Pragmatism

良いテックリードは現実主義で、正しい事を行うことと仕事を片付けることのバランスを心得ている。時には近道を通ろうとするがそれは怠惰だからではない。最低限必要な仕組みをローンチするために、全体の進捗の妨げになっている問題を回避したり一時的に棚上げすることをチームに推奨することもある。良いテックリードにとって細部はとても重要である。コードの品質、コードレビュー、そしてテスト。こうしたことを製品を予定通り出荷するのと同じくらい重要だと考える。

悪いテックリードは短期的な視点で時間を短縮しようとして技術的負債を蓄積し、後からその分のツケを払うことになる。彼らはその場しのぎで良い状況と完璧を期さなければならない状況の区別がつかない。

コミュニケーション / Communication

良いテックリードは自分の役割がコードを書く以上のものだとということを知っている。効果的なコミュニケーションが自分の仕事に必要不可欠であり、チームがより効率的に働けるようにすることに自分の時間を割くことが求められていると理解している。チームで働く上でコミュニケーションの重複は発生してしまうものだし、チーム全体の生産性を上げるために個人的な生産性を多少犠牲にするのはやむを得ないことだと思っている。

悪いテックリードは自分自身がコードを書くことが最も生産性が高いことだと考え、コミュニケーションすることは集中の妨げになると考える。チームの生産性を最適かすることではなく自分の仕事を最適化することを重視し、チームを引っ張らなければならないことをフラストレーションを感じる。

プロダクトとの関係 / Relationship with Product

良いテックリードはプロダクトマネージャーやデザイナーとプロダクトがどうあるべきかについて会話する。同意できない意思決定に反論することを厭わないが、プロダクトのゴールを達成できるよう落とし所を意識している。良いテックリードは技術的な成約に対して独創的な回避策を見つけ、より技術的な要求が緩いプロダクトの構成を代替案として提示し、プロダクトマネージャーやデザイナーが技術的な課題を理解してトレードオフを受け入れられるよう手助けをする。

悪いテックリードはプロダクトの意思決定に無関心で、プロダクトについてオーナーシップを持とうとしない。技術的な制約があればそれは不可能だといって拒否し、代替案を提示したり理由を説明しようとしたりはしない。

柔軟性 / Resiliency

良いテックリードは仕様の変化に対して柔軟で、突発的な出来事にも穏やかに対応する。彼らは変化を予期し、変化に対応できるように設計する。

悪いテックリードは仕様変更に苛立つ。あるいは、仕様の変更が発生しそうにないところまで汎用的な設計しようとする。

性格 / Personality

良いテックリードは寛大だが自己主張ははっきりしている。悪いテックリードは対立的な態度で攻撃的だ。良いテックリードは技術的な能力や経験によって自然と尊敬を勝ち得ていく。悪いテックリードは与えられた肩書や権威によって尊敬が得られるものだと思っている。

良いテックリードは常により良くする方法を探す。悪いテックリードは他人からフィードバックを受ける時に防衛的になる。

良いテックリードは謙虚であり、自分以外のチームメンバーが確信を持てるように後押しする。悪いテックリードは傲慢であり、チームメンバーに「自分はテックリードより劣る」と認識させることに喜びを感じる。