スタッフエンジニアのための「仕事の発明」ガイド

Sujith Jay Nairの著作 © 2026. All Rights Reserved. Sujith Jay Nair スタッフエンジニアのための「仕事の発明」ガイド 2026年9月22日 • プラットフォーム プロダクトマネジメント プラットフォームチームは、プロダクト主導ではなくエンジニアリング主導です。ロードマップを渡してくれるプロダクトマネージャーはほとんどおらず、追うべき収益ラインもなく、失うべき市場もありません。これは、エンジニアが発明しない限り、仕事が存在しないことを意味します。私たちのプラットフォームがユーザーに提供する価値を高める方法を見つけ続けることが、継続的な課題です。プラットフォームチームのスタッフエンジニアの仕事の大きな部分は、チームが次に何を構築すべきかを判断することです。私はそれを「仕事の発明」と呼びたいです。幸いなことに、仕事を発明するのに役立つシグナルはすでに存在しており、4つの方向から届きます。システムから、ユーザーから、組織から、そして業界からです。以下は、それぞれを読み解くためのガイドです。 システムが発するシグナル クラッシュ主導の発見 クラッシュとその関連するポストモーテムは、適切に行われれば、何を修正すべきか、何を置き換えるべきかを明確に伝えるシグナルです。ポストモーテムが新しいものを構築することを示唆することは稀ですが、ユーザーがクラッシュによってどのように影響を受けたか、あるいはチームが長引くクラッシュを修正している間にユーザーがどのようにプロセスを機能させていたかに注意を払うと、時々起こることがあります。ポストモーテム全体にわたるパターンを特定することは、それが散発的なパターンの源であるため、チームが実践としてめったに行わないことですが、大局を見失わないようにしてください。クラッシュ主導の発見には大きな欠点があります。それは、最大の機会ではなく、最も騒がしく、最も最近の失敗にチームを偏らせることです。また、それは最大限に遅延した指標です。 コスト ドル建てのコストは、明白なものです。クラウド請求書は、収益の北極星がないことを補います。しかし、そこで止まらないでください。データベースクエリの最適化や、VPC間トラフィックコストの削減方法の調査を超えてください。ビジネスユニットのP/L（利用可能であれば）、またはチームのベンダー契約とクラウド請求書の明細を確認するか、アクセスまたはコストセンターの知識を持つ人に尋ねてください。各コストセンターについて、その機能を「アウトソース」することがチームにどのような利益をもたらすか、そしてそれをチームのスコープに引き入れることが何を意味するかを理解してください。この調査は逆方向にも機能します。スコープ内にあるが、ベンダー、クラウドサービス、または他のチームに委託すべきものです。ここでの中心的な教訓は、購入対構築は一度限りの決定ではないということです。スコープ、チームメンバーシップ、テクノロジー、市場が変化するにつれて、それを見直すことができます。 あなた自身の苦労 これは別のコストです。多くの人、時には苦労している人たちでさえ、それに気づきません。どのチームにも苦労はありますが、それはほとんど優先されません。しかし、あなたはすでにこれを知っていたので、苦労が発見されるのを待っている仕事があることを言うために、それ以上の言葉は使いません。落とし穴：あなたの苦労はあなたのユーザーの苦労ではありません。前者を修正することはユニット経済を改善しますが、後者を修正することはユーザーエクスペリエンスを改善します。 ユーザーが発するシグナル 継続的な発見 私は過去に、囲い込まれたユーザーは「ツールの理想的な状態について最良の見解を持っていない」と主張してきました。「ユーザーインタビューへの過度の依存は、プラットフォームのプロダクトマネジメントの災いである」とも述べてきました。本質的に、私が言いたいのは、人々に彼らが何を求めているかを尋ねれば、彼らはより速い馬を言うだろうということです。私はこれが真実であると信じ続けていますが、それはユーザーと話さない言い訳にはなりません。継続的な発見とは、ユーザーとの継続的な会話を持つことです。週/月/四半期ごとにN人のユーザーと話してください。次のような質問をしてください。プラットフォームに関わる最も最近のタスクを教えていただけますか？プラットフォームの使用で最も苦労した点は何でしたか？もし私たちがそれらの苦労を解決したら、それはあなたにとってどのような意味がありますか？他に誰が同じ問題を抱えていますか？彼らの苦労を徹底的に調べなさい。ほぼすべての実際の問題には、すでにハックがあることを理解してください。ハックがないということは、苦労が十分に深刻ではないということです。彼らの提案する解決策に反論してください。なぜ彼らがそれらの解決策を求めているのか、そしてそれらの解決策が現在の設計によって制限されているのかを理解してください。苦労を文書化してください。言及された頻度で索引を付けなさい。要するに、ユーザーインタビューは問題空間を共同で理解することに専念すべきです。解決策空間の設計は、別のフォーラムの問題です。 過負荷になったユースケース これは私のお気に入りのヒューリスティックであり、他の場所で何度も話してきました。一部のプラットフォームには偶然の特性があります。ユーザーは、設計されていないユースケースのためにプラットフォームをサービスに押し付けます。ユーザーが代替手段（もしあれば）よりもあなたのプラットフォームを使用して問題を解決することを好む理由を理解するために時間を費やすべきです。過負荷になったユースケースを、ユーザーがあなたのために構築したプロトタイプとして扱い、それらのうちどれを同化する価値があるかを判断してください。同化のためのリトマス試験紙は単純です。あなたのユーザーのうち、他に誰が同じ問題を抱えていますか？ パートナー・ツー・プロトタイプ 過負荷になったユースケースは事後的に発見されます。パートナー・ツー・プロトタイプは、意図的に配置された同じものです。あなたのチームとユーザーは、あなたのプラットフォーム上で彼らの問題を解決できる可能性のあるものをプロトタイプするために協力します。プロトタイプは、その機能がプラットフォームの一部になるという約束ではありません。それは単なる共同探求です。同化のためのリトマス試験紙は、過負荷になったユースケースと同じです。あなたのユーザーのうち、他に誰が同じ問題を抱えていますか？ 組織が発するシグナル OKR これはさらに明白なものです。完全性のためにリストアップします。もちろん、あなたのチームがOKRを設定した（またはそれが与えられた）場合、あなたはすでにこの仕事を発明したことになります。おめでとうございます！次へ進みましょう！ マネージャー・繰り返しヒューリスティック これはシンプルで、時には効果的です。マネージャー（またはそのマネージャー、あるいはそれ以上の役職の人）が1週間に2回何かについて話しているのを聞いたら、その背後には未解決の懸念がある可能性が高いです。これは、1対1のミーティングでメモを取ったり、LLMが生成したメモを読んだりする良い理由です。このヒューリスティックは、私の意見では、仕事を発明する多くの方法の中で最も弱いものです。その理由は、階層が上がるほど、ユーザーから遠くなり、HiPPO（Highest Paid Person's Opinion）に基づいて構築する可能性が高くなることです。 移行の残骸 プラットフォームのあらゆる主要な変更には移行が必要であり、重要な移行を主導したことのある人は誰でも、採用にはファットテールがあることを知っています。それは「キャズムを超える」の有名な曲線のように見えます。イノベーター、アーリーアダプター、アーリー＆レイトマジョリティ、そして最後にレガードがいます。足踏みするレガードチームや、最新のオファリングにオンボードしないチームは重要なシグナルです。それらは、あなたのオファリングが不完全である理由、そしてもっと仕事が残っている理由を教えてくれます。私は以前、内部プラットフォームは中央値ユーザーだけでなく、より広いオーディエンスに対応する必要があると主張しました。移行の残骸は、あなたの「中央値」ソリューションが対応していないユーザーを私たちに示しています。 業界が発するシグナル 記述的な文章が処方的な文章につながる アイデア出しは難しいですが、既存のシステムを改善する方法についての新しいアイデアを考え出し（そしてそれらの改善を処方的な形式、例えばRFCで提案する）のがあなたの仕事です。アイデアを思いつくための私の個人的なお気に入りの方法は、既存のシステムを記述することです（同僚、ユーザー、新入社員のため。聴衆を選んでください）。すでに存在するシステムのデザインドキュメントを作成し、類似または隣接するジョブを実行する最先端のシステムと比較してください。この記述行為は、もはや意味をなさない決定を表面化させます。これは、思考としての執筆の最高峰です。 遅延はあなたのアービトラージです 業界のトレンド（オープンソースリリース、他社のブログ、研究論文、カンファレンストークなど）を教育し続けることには真の価値がありますが、それらを読み、仕事の発明にそれらを使用するためのより鋭い方法があります。私は、単一のコンピューティングドメインは、バンドルとアンバンドルの世俗的なフェーズの間を揺れ動くと信じています。データウェアハウスでコンピューティングとストレージをバンドルし、次にデータレイクで分割し、そして今、レイクハウスエンジンで再びバンドルしています。この動きは