テックリードとプロダクトマネージャーの分担|何を決めるか

テックリードとプロダクトマネージャーの分担|何を決めるか

テックリードになってまず戸惑うのが、プロダクトマネージャー(PM)との距離感ではないでしょうか。

仕様の相談に来られたときに、どこまで自分が決めてよいのか判断がつきません。

逆に、技術的な都合でスコープを削りたいときに、それを言い出す立場が自分にあるのかも分かりにくいところです。

筆者もテックリードを目指して学んでいる途中で、この線引きは最初につまずいた論点でした。

そこで、公開されている一次情報をたどりながら、二つの役割の境界がどこに引かれているのかを整理しておきます。

読者として想定しているのは、これからテックリードを任される人と、任されたばかりで PM との役割が重なって困っている人です。

「何を」と「どう」で線を引く

もっとも引用される整理は、テックリードという役割を定義したパット・クア氏によるものです。

同氏は Tech Lead を「チームを率い、技術的な方向性を揃えることに責任を持つソフトウェアエンジニア」と定義しています。

そのうえで三つの役割を、プロダクトマネージャーは「何を(What)」、テックリードは「どう(How)」、エンジニアリングマネージャーは「人とチームの成長」という軸で切り分けました。

The Definition of a Tech Lead

The Definition of a Tech Lead

この三分割は乱暴に見えて、実務ではかなり使えます。

「この決定は、作るものの中身を変えるのか、作り方を変えるのか」と自問すれば、たいていの相談はどちらかに寄るからです。

利用者に見える振る舞いが変われば PM の領分で、見える振る舞いを変えずに実現方法だけが変わればテックリードの領分、という当てはめ方になります。

同じ記事では、テックリードは最低でも業務時間の30%はコードを書くべきだという指針も示されました。

決める人が現物から離れると、判断の精度が落ちるという理屈でしょう。

境界が曖昧になりやすい三つの場面

線引きの原則が分かっても、現場ではきれいに割れない場面が残ります。

代表的なものは、見積もり・スコープ・技術的負債の三つでしょう。

一つ目が見積もりです。

「いつ出せるか」は一見スケジュールの話なので PM の領分に見えますが、根拠になる工数と不確実性を出せるのはテックリード側しかいません。

ここは「数字はテックリードが作り、その数字を持って外部と約束するのは PM」と分けると混乱が減ります。

幅のある数字を相手にどう伝えるかは、見積もりだけを扱った記事で掘り下げました。

見積もりの技術|不確実性をどう伝えるか

二つ目がスコープの削り込みです。

締切が動かせないときに何を落とすかは、PM が決める問題として扱われがちでした。

ただし「どれを落とせば工数がいちばん減るか」を提示できるのはテックリードだけなので、選択肢を作る側として関わるのが自然な形になります。

三つ目が技術的負債です。

返済そのものは利用者から見えないため、放っておくと優先順位づけの土俵にすら乗りません。

だからこそテックリード側が「返さなかった場合に将来どれだけ遅くなるか」を言語化し、PM が扱える形の材料に変えておきたいところです。

分担が壊れているときのサイン

役割分担が機能していないチームには、いくつか共通した症状が出ます。

分かりやすいのが、技術的な選択の理由を PM が説明させられている状態です。

これは How の説明責任がテックリード側に置かれていない証拠なので、判断そのものを引き取り直したほうがよいでしょう。

逆のパターンもあります。

テックリードが「この機能は要らないと思う」と価値の判断まで引き受けてしまい、What の議論が技術者の好みで決まっていく状態です。

どちらも片方の役割が空席になったぶんを、もう片方が埋めているという同じ構図になります。

なお、ここで扱っているのは PM が価値に責任を持つチーム構成が前提です。

シリコンバレー・プロダクトグループが「フィーチャーチーム」と「プロダクトチーム」を区別しているように、そもそも与えられた仕様を作るだけの体制だと、What の担い手が組織の外にいることもあります。

Product vs Feature Teams

Product vs Feature Teams | Silicon Valley Product Group

自分のチームがどちらなのかを先に確かめておくと、分担の議論が空回りしません。

最後に

テックリードと PM の境界は、「利用者に見える振る舞いが変わるか」で切ると実務上はほぼ足ります

そのうえで見積もり・スコープ削り・技術的負債の三つは、材料を出す側と決める側に分けて考えると噛み合いやすいはずです。

役割そのものの全体像は、テックリードとは何かを整理した記事のほうが詳しいので、あわせて読んでみてください。

テックリードとは何か?EM・アーキテクトとの違いを整理

シニアエンジニアから役割が切り替わる地点については、境界線を扱った記事にまとめました。

シニアエンジニアとテックリードの境界線|何が変わるのか

線引きに迷ったら、「これは What か How か」と一度声に出してみる、それだけでも会話はずいぶん整理されます。

以上です。