プロダクトをつくる役割はすべてがグラデーション

リーナーのプロダクト開発

リーナーでは、プロダクト開発をプロフェッショナルな専門知識・技術のユニットに分けていません。プロダクトの設計、実装はもちろん、企画やデザイン、QA、リリース、運用監視もすべてが「Dev」という大きな括りのチームでやっています。（単一のStream Alignedチームが、担当するプロダクトのライフサイクルのすべてに関わっています）

「開発の優先順位はPdM、POが決める」
「デザインはデザイナーの専門知識が必要だからエンジニアは関与しない」

というわかりやすい役割分担はしていません。

「顧客理解が足りないならチームみんなでキャッチアップする」
「デザインはみんなでできる仕組みを整える」

という感じでやってます。

なぜこうなっているのか：楽しいから

一番の理由はシンプルに仕事が楽しいからです。リーナーにはこういう感覚を楽しめる人が集まっているからできています。会社の向かう方向や、顧客の課題に、自分自身の興味関心を共存させることができる人にはとても楽しいと思います。

なぜこうなっているのか：プロセスを育てるため

別の観点の話をすると、専門性が細分化されるとプロダクト開発のプロセスが脆弱になります。専門ユニット内外で境界線が引かれるため、話がややこしくなります。特に評価制度が専門知識・技術と関連を持つと非常にややこしいです。

その点、みんなで全体を見る仕組みが整っていると、プロセスのどこにボトルネックがあるのか、どこを強化すべきか、という話もフラットに会話できます。

プロダクト開発はすべてがつながっている

プロダクトの価値はすべての工程がつながった上で初めて価値を届けられます。 toB SaaSプロダクトの開発は、顧客のリード獲得、アポ取り、商談、トライアル、オンボーディング、本契約、長期サクセス、解約抑止という流れの中にすべて紐づいてます。

そのため、一つひとつの工程を滑らかに、滞りなく流れるようにする必要があります。その全体をうまく流すプロセスに、チーム全員が責任を持つべきだ、という思想です。特定の専門ユニットだけを取り出して価値を出すことはできません。

役割がグラデーションであるとは

簡単に言うと、「チームにその時必要だと思える役割を自分で考える」です。チームを取り巻く状況は日々変化します。その変化をキャッチして、役割を柔軟に動かしていると、自然とグラデーション的な役割になります。

エンジニアでも必要ならデザインを考えるし、デザイナーも必要ならコードを書きます。 実際やるかは別の話として、自分なりに最善を考えてチームのために動けるか、という心意気はリーナーで働く上では必須です。

リーナーに合わない人

「わたしはPdMです！」「わたしはデザイナーです！」「わたしはSREです！」という自分のキャリアにこだわりが強い人には合わないかもしれません。

専門性を軽視してるわけではない

エンジニアとして、デザイナーとして最新の知識・技術をキャッチアップして専門性を高めることは大事なことでありリーナーでもやってます。最近だとDevinやCursorを活用してプロダクト開発に活かすことにも取り組んでいます。ただし、プロダクト開発全体のプロセスを踏まえると、専門性を重視しすぎると弊害の方が大きくなると思ってます。