スタッフエンジニアはどうやって「解決すべき課題」を見つけているのか？価値を生むための視点

スタッフエンジニアの役割は、単にコードを書くことではありません。組織の成長を阻むボトルネックを見つけ出し、優先順位をつけて解決に導くことが求められます。私が日頃から意識している、価値ある課題を見つけるためのアプローチを紹介します。1. 現場の痛みを観察する：開発チームが繰り返し不満を漏らしているプロセスや、デプロイ時の苦労話に耳を傾ける。2. データで裏付けを取る：感覚的な「困った」を、メトリクスやログデータで可視化して客観的な事実にする。3. ビジネスの優先順位と同期する：プロダクトのロードマップと照らし合わせ、今取り組むことが最もROIの高い問題は何かを見極める。スタッフエンジニアとして技術的負債を解消するだけでなく、プロダクトを前に進めるための「戦略的な課題設定」こそが、チームを成功に導く鍵となります。

そんな悩みを持てるなんて幸せな人たちだね。私はキャリアのほとんどをスタートアップで過ごしてきたけど、解決すべき問題が起きている時間内にこなせる量よりもはるかに膨大だっていうのが常に私の経験だよ。だから「解決すべき問題を探す」んじゃなくて、どの問題が最も緊急か、あるいは一つの解決策で複数の問題を片付けられるものはどれかっていう判断をするようにしてる。チームや顧客を満足させて生産性を維持するために、そうやって優先順位をつけるスキルを磨いてきたことは、私のキャリアにおける大きな誇りだよ。

著者はこう指摘してるね。

補足として、私の経験は主に大企業でインフラや開発者ツールに携わってきたもので、エンジニアがボトムアップでロードマップに影響を与える裁量が大きいチームでのものだ。もっとトップダウンな環境なら、こういうやり方は難しいかもしれない。

近年のテック業界では、エンジニアのボトムアップな裁量が減って、トップダウンな管理環境が増えてるんじゃないかと思うんだ。エンジニアに裁量がある「技術主導」の会社から、より「プロダクトマネジメント主導」の会社へ、どれくらいのテック企業や平均的なエンジニアの経験が変化したのか気になるところだね。あくまで根拠のない推測だけど、テック業界の文化が（私の考えでは）技術重視からビジネス・管理・プロダクト重視へシフトするにつれて、エンジニアは単にビジネス目標を達成するためのパーツとして扱われるようになり、エンジニアの裁量は年々減っているような気がするよ。まあ、これも経験則に基づく仮説にすぎないけどね。

テック業界はどこも肥大化しすぎだと思う。大規模なレイオフがあったとしても、ほとんどの企業はビクともしないだろうね（もちろん個人の生活に害があるから冷酷だとは思うけど）。チームの人数が減ればコンテキストスイッチも減るし、エンジニアはより広い範囲を自分で所有できるようになる。わざわざ仕事を探さなくても、目の前にやるべきことはいくらでもあるはずだよ。今まで働いてきた多くのビッグテック企業では、やるべきことが足りていない人をたくさん見てきた。結局、彼らは時間を埋めるために会議を作ったり、ドキュメント作成みたいな無駄なことをしたりするんだ。マネージャーやディレクターは、大きな肥大化したチームを抱えたがるようだね。部下の数が多いほど、プロモーションのために要求を通しやすくなるからさ。

シニア〜スタッフエンジニアの境界線あたりで私が難しいと感じるのは、深い技術的知識があるせいで、短期的な問題を依頼通りに速く効率的に解決できてしまうことなんだ。著者は他チームのフラストレーションを理解するのに時間を使うべきだと言ってるけど、それには膨大な時間がかかるし、コードを書いたり新機能をリリースしたりせずに話し合いばかりしてる人間にはなりたくないんだよね。みんながこのあたりをどう経験してきたか聞いてみたいよ。

スタッフエンジニアのレベルでしばらく働いていたけど、鍵になるのはマネージャーを管理するディレクターの直下に就くことだと思う。そうしていた時はいつも上手くいっていたよ。プロジェクトの定義は簡単だし、人を説得するのも楽だった。他のIC（個別貢献者）を管理するマネージャーの下にいた時は、そのレベルの役割を担っても全く上手くいかなかったね。他のICがタスクを奪い合おうとするし、みんな必要なことがあっても相談に来てくれない。他のプロジェクトの情報を知るのが遅すぎるし、他チームは縄張り意識が強くて介入を歓迎してくれないからね。

とても良いアドバイスだけど、エッセイの冒頭でこの問いを投げかけているような人には、スタッフエンジニアになるのはお勧めしないかな。その役職が単なる昇進ステップの一つに過ぎず、明確な役割の違いがない会社にいるなら話は別だけどね。

これまで一緒に働いてきた成功しているスタッフレベル以上のエンジニアは、タイトルをもらうのが形式的なことだった。すでに現場でその役割を果たしていたからね。逆に「無能なレベルまで昇進」した人は、タイトルや給料アップだけを求めて、そこに至るための「ゲーム」をプレイしようとしていたよ。

問題を解決したいというモチベーションが、純粋に問題を解決するのが好きだからではなく、昇進のためだというなら、それは君に向いた仕事じゃない可能性が高いよ。

スタッフエンジニアじゃないけど、今の自分の状況とすごく重なる。やってきたシニアやリード開発者の役割の中で、取り組みたい問題にぶつかっても、手を出すことを許されないんだ。そういう問題に取り組む自由があるスタッフエンジニアになれたら最高なんだけど、どうやらその会社がそういう仕組みじゃないみたいなんだよね。

顧客と話すんだ。顧客へのプレゼンには営業チームと一緒に同席して、営業のコールにも参加してみなよ。彼らの抱える問題や不満点、そして現在どんな解決策を使っているのか直接聞いてみるのが一番だよ。

「解決すべき問題を見つける」という言葉を正直に言い換えると、「会議のたびに自分が文句を言っていることを探して、それを修正する権限が自分にあると気づくこと」だね。私がやってきた最高の仕事の半分は、結局のところ、自分が言い続けることに疲れ果てたストレスの解消から生まれているよ。