プラットフォームチームで「仕事を発明する」ための11のシグナル
A Staff Engineer's Guide to Inventing Work
プラットフォームチームにはロードマップを渡すPMもなく、仕事はエンジニアが自ら発明しなければ存在しない。システム、ユーザー、組織、業界の4方向から届く11のシグナルを、どれが「議論済みで安いが遅行」か「自ら論拠を組み立てるが先行」かという2軸で整理。クラッシュ、コスト、ユーザーインタビュー、過負荷なユースケース、OKR、移行の残骸、業界の遅れなど、それぞれの読み方と落とし穴を解説する。
仕事を発明することは、シグナルを見つけることよりも、なぜ他の10個ではなくこれなのかを説明できることにかかっている。
HNでの議論
32- dabedee
> プラットフォームチームはプロダクト主導ではなくエンジニアリング主導である。ロードマップを渡してくれるプロダクトマネージャーはほとんどいないし、追うべき収益ラインもなければ、失う市場もない。
まさにこのような枠組みとメンタリティのせいで、プラットフォームチームは実際には人々に十分に奉仕せず、たいていは仕事を発明する人々の高度に機能不全なタワーと化している。
市場がないことへの修正は、あなたが奉仕するチームが去る可能性があるかのように振る舞うことだ。この記事全体がシグナルを列挙しているが、そのどれもこれではない。捕らわれているからといって、ユーザーや内部チームに他の選択肢がなく、気づかないわけではない。プロダクト主導であるとは、ユーザーを気にかけることだ。プラットフォームチームは、まさにこの狭い意味でプロダクト主導であるべきで、エンジニアリング主導であるべきではない。さもなければ、この記事が見事に暴いているように、仕事を発明することになる。
- fsloth
「その仕事はエンジニアが発明しない限り存在しない」
これはとても奇妙だ。私の考えでは、企業がエンジニアを雇う唯一の目的はビジネスを支援することだ。スタッフエンジニアは、ビジネス面で何が興味深いかを教えてくれるプロジェクトマネージャーを必要とすべきではない——たとえ目標が主に技術的なものであっても。
これが常に成り立つわけではないことは承知している。しかし、自分の仕事をビジネス指標で説明する理由を提供できないなら、それは学術的な演習に参加しているようなものだと思う。
- juancn
私は「次に我々を殺すのは何か」という哲学を使っている。
それが何かを見極め、それを避けるために何かをする。
洗って、すすいで、繰り返す。
- nmehner
「仕事を発明する」＝「要求工学」
「仕事を発明する」は、私見では奇妙な表現だ。
- stephbook
記事の内容は真実でもあり、奇妙な枠組みでもある。
著者は「プロダクトの顧客」が、愚かなプログラマー自動人形がコードに翻訳するだけでよい整然とした要件リストを渡してくれると思っているのだろうか？明らかにそうではない。顧客も自分が何を望んでいるか、あるいは望み得るかを知らない。有名な話だが、彼らはより速い馬が欲しいと言う。
そして著者は「クラッシュ主導の発見」を列挙しているが、まるで本番環境のバグを優先することとそんなに違うかのように。あるいは、何もアイデアがなければ、単に効率を改善するだけ。あるいは顧客と話す、おっと、ユーザーと話す。
これらすべては真実であり、どれも他のソフトウェアと何ら変わらない。ただ別の言葉に翻訳されているだけだ。