本動画は、元MetaのL8級エンジニアであるKun Chenが、MicrosoftからFacebookへの転職、Facebook Gamesでのプロダクト成長、マネージャー経験、そしてAI時代におけるエンジニアの生存戦略を語る対談である。単にコードを書く能力ではなく、好奇心に従って学び続ける姿勢、ビジネス成果に直結する課題を見抜く力、そしてAIエージェントを使いこなして仕事の抽象度を上げる能力が、これからのエンジニアにとって決定的に重要になるという内容である。
- 成長が止まったと気づいた瞬間
- 10歳前から始まったコンピューターとの出会い
- 大学とMicrosoftでのインターン経験
- スポンサー紹介 Linear
- 大規模検索エンジンの複雑さを理解するまで
- ジュニアでも自分でスコープを作れる
- FacebookのブートキャンプとNewsチーム
- Facebook Gamesで学んだプロダクトマーケットフィット
- マネージャーになる決断とVPからの警告
- マネジメント経験から学んだ「コントロールを手放す」こと
- StaffからE7へ進んだプロジェクトとインパクト
- 物事がうまくいきすぎると不安になる
- マネジメントではなくICとして事業を立ち上げる
- ジュニアに必要なのは大量に作ること
- シニア以上はレバレッジと交渉を理解する
- AIは誰の仕事を奪うのか
- AIツールはいつ成熟するのか
- AI時代のジュニアとミドルは先輩を飛び越えられる
- シニアエンジニアのアイデンティティ危機
- 既存システムをAI時代にどう移行するのか
- Bullish, Bearish or BS
- Big Techを離れてソロビルダーへ
成長が止まったと気づいた瞬間
今日はKun Chenさんとお話しします。今日は来てくれて、この会話に参加してくれてありがとうございます。
こちらこそ呼んでくれてありがとうございます。
ええ、もちろんです。Microsoftを離れて別の会社に行く必要があると、どうやって気づいたんですか？
私がMicrosoftにいて、Facebookに移ろうと決めた年は、自分があまり成長していないと気づいた年でした。
多くの人は、昇進できなくなって初めて、ああ、自分は成長していないんだ、と気づくと思います。でも、それはかなり遅れた指標だと思います。実際には、自分が成長しているかどうかは、もっとずっと早い段階で分かると思います。
私が自分の成長が止まっていると判断した方法は、今月、自分は先月できなかった何をできるようになったのか、と自問することでした。
そして数か月ほど、その問いにうまく答えられない時期がありました。自分はこれまでやってきたことをそのままやっているだけだと感じました。これをどうやればいいかは、もう分かっている。もちろん、それをより速く、より良くやる方法を探し続けることはできます。でも大きく見れば、同じことをしているだけでした。そこで、ああ、自分はここでは成長していないんだ、と気づいたのです。
それを解決する方法の一つは、当時のマネージャーと協力して、自分の力を伸ばせる良い機会を見つけることだったと思います。でも私は、まったく違う経験を得ることを選びました。その方がもっと多くを学べると感じたからです。
当時のFacebookは株価が非常に伸びていました。Seattleにオフィスを設立しているところで、多くの人が非常に刺激的な場所だと話していました。なので、よし、試してみようと思いました。そしてそれは、おそらく私が下した最高の決断の一つでした。金銭的にも、個人としての成長という意味でも、本当に有益でした。
そのテスト、すごくいいですね。今月できるようになったことのうち、先月はできなかったことは何か。
そこでは期間がとても重要だと思います。人は日々のことに埋もれてしまうか、あるいは年単位でしか振り返らないことが多い。でも、この1か月という単位はいいですね。今、自分でも考えています。自分は今、何において成長しているのか。今月できるようになったことで、先月できなかったことは何なのか。これは素晴らしいテストですね。盗ませてもらいます。
ええ。特に今は物事の変化が非常に速いので、人々はその時間軸をさらに圧縮し続けるべきだと思います。
AIは常に変化していますよね。人々が使っているツールも、1年前とはまったく違いました。まったくではないにせよ、かなり違います。ツールの人気、有用性、そしてツールそのものも進化しています。
だから、世界は本当に速く変化していると思います。そして私たちは常に、自分は実はあまり学べていない場所にとどまってしまっているのではないか、何か変えるべきではないか、と問い続けるべきです。必ずしも会社を変える必要はありません。役割全体を変える必要も、ポジションを変える必要も、自分の仕事を丸ごと変える必要もありません。でも、どんな変化が可能なのかを見つけるために、その問いを立てる価値はあると思います。
あなたは私の友人の中でも、おそらく私が見てきた中で最も速いキャリアの進み方をした一人です。Microsoftにいて、それからFacebook、Microsoft、そして他にもいくつかの場所にいたと思います。Facebookではどのレベルまで行ったんですか？
E7まで行きました。
E7まで行ったんですね。そしてMicrosoftではPartnerレベルで、たしか私より5歳くらい若いですよね。どうやってそこまで行ったんですか？
10歳前から始まったコンピューターとの出会い
私の歩みを説明するには、おそらく本当に最初から話す必要があります。
私はとても早い時期からコーディングやものづくりを始めました。10歳になる前くらいだったと思います。ある夏休みに、私は家に一人でいて、母が職場からノートPCを持って帰ってきました。そしてそのノートPCを家に置いていったのです。私は他にやることがなかったので、そのノートPCで遊び始めました。
たしかPhotoshopか何かが入っていました。それにものすごく興味を引かれました。他にやることがなかったんです。だから、ノートPCの中で見つけられるものを何でも触って遊びました。Photoshopで遊び始めて、コンピューターを触ったことがない人間にとって、そこからできることに本当に魅了されました。すごく面白かったんです。
それで、さらにいろいろやるようになりました。その後、小学校のサマーキャンプでプログラミングを教えるものがありました。当時の私は、それが何なのかまったく分かっていませんでした。ただ先生のところへ行って、ここでは実際に何を学べるんですか、と聞きました。両親と祖父母は、私をそこに行かせるかどうか決めようとしていました。
先生はこう言いました。ほら、このゲームを見て。これは私が作ったんだ。プログラミングを学べば、君にも作れるよ。
それで私は非常に興味を持ちました。子どもをプログラミングに引き込むには、本当に良いフックでした。そこで授業を受け始めました。
面白かったのは、その2か月間のプログラミング学習の間、誰もコンピューターにアクセスできなかったことです。ホワイトボードで学び、紙に書き、先生がそれをコンパイルして実行してくれて、結果を返してくれるという形でした。コンピューターは、誰もが使えるリソースとしてはまだそれほど一般的ではなかったからです。
つまり、ペンと紙でプログラミングを学んだんですね。
はい。
それはすごいですね。
ええ。BASICを書いていました。変数を書き、だんだん複雑なフローを書いていきました。そしてサマーキャンプの2か月が終わるころになって、ようやく実際にプログラムを入力して実行できるコンピューターを使えるようになりました。
それが本当に面白くて、私はどんどん夢中になっていきました。サマーキャンプの後は、いくつかの競技会にも参加するようになりました。そしてコンピューターも、より手に入りやすく、一般的になっていきました。高校には、誰でも行って触れる実験室があったと思います。そこでさらにのめり込んでいきました。
私はものを作っていました。とにかくものを作るのが好きでした。高校生の頃、本屋に行って、「ホームページの作り方」のような本を買ったことがあります。その本は、メモ帳を使ってHTMLを一文字ずつ書く方法を教えるものでした。その本に従って、私はウェブサイトを作りました。
当時は無料のウェブホスティングサービスがありました。私はその一つを使って、自分のウェブサイトをホストし、他の人に見せました。それは本当に刺激的で面白い旅でした。
それによって、より高度なことに進んでいきました。つまり、学術的に競技会に出るとか、基本的なパスコードのようなプログラミングをするだけではなく、実際にものを作る方向に進んでいったのです。ウェブサイトを作り、アプリを作りました。
そして私はビデオゲームもたくさん遊んでいました。Counter-Strikeなど、ああいうゲームです。ゲームに非常に多くの時間を費やしましたが、それは他の人がどのようにプレイするか、どのようにチートするかを見る面白い機会にもなりました。人々はチートが好きです。
そして私はコンピューターについて、つまりコンピューターがどう動くのか、ソフトウェアがどう動くのか、ゲームがどう動くのかについて知識があったので、チート用のソフトウェアを作ることができました。いくつか作って、実際にそれをお金で売りました。
Counter-Strike用ですか？
Dragon RajaというMMO用です。覚えている人がいるか分かりませんが、今でも運営されています。そのゲームには多くの設計上の欠陥がありました。多くの計算がクライアント側で行われていて、サーバーはそれをそのまま信頼していました。だから、チートをする機会が大量に開かれていたんです。
私はかなり多くのソフトウェアを書きました。ソフトウェアを動かしておけば、ほぼ自動でファーミングなどをしてくれて、リソースを手に入れられるようなものです。
大学とMicrosoftでのインターン経験
教育はどのようなものでしたか？伝統的なルートでコンピューターサイエンスを学んだんですか？
はい。大学の専攻はコンピューターサイエンスでした。4年間そこにいましたが、正直、大学からそれほど多くを学んだとは感じていません。寮の部屋で、他の数人と一緒に、自分たちでいろいろ作っていました。ただ作って、作って、作り続けていました。私の経験のほとんどは、そこから来ていると思います。
そして大学3年生のときだったと思いますが、Microsoftでインターンをすることになりました。Microsoftが私たちの大学に来て、テストを実施しました。誰でもそこに行ってテストを受けることができ、十分に良ければインターンとして採用されるというものでした。私はMicrosoftのインターンになり、夏をそこで過ごしました。
そこでエンジニアたちと多くの面白いことに取り組み、Microsoftに非常に感銘を受けました。当時、大規模ソフトウェアを構築する経験を持つテクノロジー企業は、それほど多くなかったと思います。そこには非常に多くの才能ある人々がいました。2か月そこにいるだけで多くを学びました。そしてそこを自分の最初のフルタイムの仕事にしようと決めました。そうして私のキャリアが始まりました。
インターンのときは何に取り組んだんですか？
Bingです。Bing検索エンジンです。当時はBingとは呼ばれていませんでした。Live SearchかMSN Searchか、そのどちらかでした。何度も名前が変わっていました。でも検索エンジンでした。私はそこでいくつかの機能の構築を手伝いました。たしか自動サジェストでした。
なるほど。
検索ボックスに入力すると、自動補完が出る機能です。その一部を手伝いました。
スポンサー紹介 Linear
このエピソードはLinearの提供でお送りします。Linearは、話す価値があると思うものを公開しました。新しいマニフェストの冒頭は、「課題管理は死んだ」です。
それが意味するのは、その周辺にある行動、つまり手動で課題を記録すること、優先順位をめぐる往復、バックログの中に何があるのかを部屋の半分の人が理解しようとしているだけのグルーミングセッション、そういったものはLinearでは過去のものだということです。
私はAmazonでこの悪夢を経験しました。私たちには何にでもメカニズムがありました。誤解しないでほしいのですが、私はメカニズムを強く信じています。ただ、多くの場合、仕事を追跡するプロセスが、仕事そのものと同じくらいのエネルギーを消費していました。
スプリント計画ミーティングから出てきて、こう思うのです。8人のエンジニアが、自分たちがすでに作る必要があると分かっているものを確認するために、2時間を費やしただけだったな、と。
Linearが行ったのは、そうしたことが自動的に起こるようにプラットフォームを再構築したことです。コード、意思決定、顧客フィードバック、そうした文脈がすべて一つの場所に存在し、Linearは実際にそれをもとに動作します。だから何かが入ってきたとき、システムはそれが何で、どこに位置づけられるのかをすでに理解しています。誰かが手動でトリアージする必要はありません。
あなたがエンジニアリングリーダーで、チームに仕事の管理ではなく構築をしてほしいなら、Linearをチェックしてみてください。リンクは概要欄にあります。
大規模検索エンジンの複雑さを理解するまで
それはすごいですね。自分でコンピューターをハックしたり、紙にプログラムを書いたりするところから、MMOでチートを作るところへ行く。その段階でも、まだクライアント側なら小さいですよね。何が起きているかはまだ理解できる。
でもそこからインターンとして、ああ、検索エンジンを作るにはこういうことが必要なんだ、と知る大きなジャンプがある。それは本当にすごい景色の変化ですね。
本当にそうです。そして、Microsoftにいた最初の2年くらいは、検索エンジンがどのように動いているのかを完全には理解していなかったと思います。
多くの図があり、多くのドキュメントがあり、それぞれの部分を説明していました。検索エンジン構築の最初の頃からそこにいた人が作った巨大な図もありました。その図はすべてを説明していました。
でもその図を見ると、それぞれの部分は理解できます。しかし、それらがどう組み合わさり、実際にスケールして動くのかは理解できませんでした。業界に入ったばかりの人にとって、すぐに把握できるようなものではありません。
でも、それでよかったんです。私は自分が関わるコンポーネントに取り組み、自分に提示された問題に対処しました。それが私の始まり方でした。そして時間とともに、知識は蓄積されていきました。本当に深く取り組むことによって、ようやく全体像を理解できるようになります。私の場合、それには2年か3年くらいかかったと思います。
Microsoftにフルタイムで入社したんですよね。そこでは何に取り組んだんですか？戻ったときも検索に取り組んでいたわけではないんですか？
いいえ。フルタイムの仕事を始めたときは検索エンジンでした。その後、いくつかの機能の間を移りました。自動補完もありましたし、ローカル検索もありました。ローカル検索、つまり場所などを検索する機能です。それからデータマイニングもありました。
毎日非常に多くのログが入ってきますよね。その膨大なデータからどう価値を取り出すのか。MapReduceのパイプラインが必要で、システム全体が必要になります。そこも手伝いました。なので、いろいろなシステムの間を移りました。
ただ、キャリア初期のその部分で面白かったのは、私はとても速く仕事をしていたことだと思います。以前の経験のおかげです。その時点で、私はおそらく10年近くものづくりをしていました。だから非常に速く仕事ができました。
割り当てられたものは、すべてとても素早く終わらせました。その結果、自由時間がたくさんできました。あまりにも早く終わらせてしまうので、他の人たちは次に何を割り当てればいいかまだ決められていなかったからです。
ジュニアエンジニアの場合、通常は誰かが方向性を設定しますよね。何かを割り当てる必要があります。私はとにかく非常に速く働いたので、多くの自由時間ができました。
その自由時間を使って、追加でできることを探索しました。他の人たちがどのような問題に取り組んでいるのかを見ました。検索エンジンに取り組む人々には、とても興味深い問題がありました。ユーザーがクエリを送信した後、検索結果ページとどのようにやり取りしたのかというデータに、簡単にアクセスできないことがあったのです。
特定のクエリについて、プロダクトチームがユーザーからフィードバックを受けることがよくありました。たとえば、この検索結果は本当にひどい、というものです。すると私たちはデータを確認して、それが何を意味するのかを見なければなりません。本当にひどいとはどういう意味なのか。誰もクリックしない間違った結果を表示したのか。それとも実際には興味深い結果を表示していたけれど、この特定のユーザーの好みには合わなかっただけなのか。
それを理解する必要があり、そのためにはデータが必要でした。当時のBingには、クエリを入力して、人々が実際にどこをクリックしたのかを簡単に確認できるツールがありませんでした。そこで私はそれを行うツールを作りました。
誰にも頼まれていません。ただ自由時間があり、その問題があることに気づき、作ったのです。それはチーム内で非常に人気になり、ますます多くの人が使うようになりました。それが、最初の数回の昇進を助けてくれたのだと思います。
私は非常に自律的で、こうしたアイデアを出し、有用なものを作るために主体性を発揮しました。それによって群衆の中から目立つのがとても簡単になりました。才能あるエンジニアは非常にたくさんいましたが、最初の頃にかなり速く昇進できたのは、それが理由だったと思います。
ジュニアでも自分でスコープを作れる
ジュニアエンジニアだったとき、割り当てられた仕事をできるだけ早く終わらせていたと言いましたよね。あなたは夜遅くまで働いたり、週末も働いたり、机の下で寝たりするタイプだったんですか？それとも出社したら無駄なく全部終わらせて、5時になったらすぐ帰るタイプだったんですか？
時には遅くまで残ることもありました。でもそうするときは毎回、それが続けずにはいられないほど面白いものを見つけたときでした。問題に入り込んで、あと15分あれば解けるかもしれない、と思うことがあります。そして結局、一晩中使ってしまう。そういうことはあります。
でも多くの場合は、時間通りに帰っていました。そして自分の場所に戻って、コーディングを続け、別のものを作っていました。
なるほど。つまり、それをゲーム化していた、あるいはそれ自体がゲームだったんですね。どれだけ早くできるか、どれだけ速くできるか、という感じで。品質は犠牲にしていたんですか？それとも品質も高かったんですか？速いけれど。
品質は犠牲にしていなかったと思います。自分がやったことはすべて、本当に有用なものであり、質の高い仕事であるようにしようとしていました。
ただし、やることのスコープについてはトレードオフをしました。私は通常、とてもラフに始めます。すでに存在している構成要素を何でも使います。車輪の再発明は避けるようにしますし、面白いけれどそれほど有用ではないものを解くために2週間費やすような穴に入り込まないようにします。
スコープを非常に正確にコントロールして、人々にとって有用なものを素早く届け、フィードバックを得られるようにしました。時には、これは有用だと思っていた、作ってくれてありがとう、でも実際に手にしてみると想像していたほど有用ではなかった、という反応もあります。だから現実世界のフィードバックを得ることはとても有益だと思います。
検索結果ページを顧客がどう使っているかを知るために作ったそのツールについてですが、誰かが、ああ、ありがとうKun、くらいの反応をする世界もありえましたよね。それについてはすぐにフィードバックを得られたんですか？それとも大きく一気に作って、機能をたくさん入れてから人々に見せたんですか？あるいは、そのツールを作ることがあなたの正式な任務の一部だったんですか？
いいえ。私は、人々が価値を感じるだろうと思う形でツールを作りました。最初のバージョンを作り、数人に見せました。その人たちは、どの部分が有用で、どこを変えたいかというフィードバックをくれました。そこで私はそのフィードバックを受け取り、反復し始め、どんどん有用なものにしていきました。なので、時間はかかりましたし、何度かの反復が必要でした。
そのときはジュニアでしたか？それともミドルくらいでしたか？
ジュニアです。エントリーレベルでした。
分かりました。Microsoftのエントリーレベルがたしか59とかでしたよね。
59です。
59だったんですね。まだ次のレベルには行っていなかった。59で、それを自分でやっていたんですね。
はい。
なるほど。
私は多くの人のキャリア相談に乗っていますが、彼らは私のところに来て、Steve、マネージャーがスコープを割り当ててくれません。どうやって昇進すればいいんですか。どうやってキャリアを伸ばせばいいんですか、と言います。あなたはジュニアエンジニアでもツールを作りに行けると言っているわけですね。誰も止めていない、と。
そうです。そしてジュニアエンジニアであることの重要な側面は、自分は割り当てられたことだけをやるべきだと思い込まないことだと思います。
さらに言えば、割り当てられたことだけをやるべきではありません。なぜなら、それは期待されていることだからです。期待されていることをやるだけなら、昇進させる理由は何ですか、という話になります。もちろん、マネージャーが意図的に、今のレベルの期待を超えるような仕事を与えてくれている場合は別です。でもそれが起きないこともあります。
だから人々は主体性を持ち、他の人が抱えている問題、ユーザーが抱えているかもしれない問題、チームメンバーが抱えているかもしれない問題、会社が抱えているかもしれない問題を特定し、それに取り組むべきだと思います。価値あるものを届けられれば、それは足場を得て、成長し、より大きなインパクトを持つものになります。
では、こう言ったらどうでしょう。そんな余分なことをやる時間が足りません。既存の割り当てだけで全部の時間が取られていますし、締め切りに追われています、と。
自分の仕事が上手であることは重要だと思います。私にそれをする自由時間があった理由は、割り当てられた仕事を非常に速く終えていたからです。なので、ベースラインの期待を満たすために必要な経験や専門性を積むことは重要です。それは最低条件です。
だから間違いなく、基礎を良く、あるいは堅固にするために時間を使うべきです。そしてそこから少し自由時間を切り出し始めるのです。
ジュニアエンジニアが会社に入って、締め切り、締め切り、また締め切りという仕事に100％割り当てられているケースは、非常にまれだと思います。たいていジュニアエンジニアにはある程度の余裕があります。特に、マネージャーと期待値について一緒に話し合っている場合はそうです。
もし、締め切りのある仕事が多すぎて学ぶ時間がないと感じるなら、そのことをマネージャーと話し、期待値を少し調整するべきです。ビジネス上のプレッシャーによって、その人に仕事を押し込みすぎている場合もあります。それは正しくありません。なので、ある程度の交渉も有効だと思います。
FacebookのブートキャンプとNewsチーム
Microsoftをシニアとして離れて、そこからFacebookに行ったんですね。
はい。
ではFacebook時代について話しましょう。そこでは何に取り組んだんですか？
Facebookに入ったのですが、Facebookには新入社員を会社に導入する非常に面白い方法がありました。ブートキャンプと呼ばれていました。Facebookに入った全員が、1か月か2か月かけて学び、立ち上がり、さまざまなチームと話し、どのチームに入るかを本当に見極めるのです。
私はNewsに取り組むチームを選びました。そのチームには検索に関する問題があり、私はそこに馴染みがあったからです。自分の過去の経験を活かせる領域を見つけようと思いました。
そこでNewsチームに入り、検索の問題に取り組みました。それは面白かったのですが、かなり早い段階で、これは自分のものではないという感覚を持ちました。かなり興味深い問題に取り組み、それらを非常にうまく解決しました。人々もそれを称賛してくれました。そのチームで非常に重要な役割を果たしている自分の姿も見えました。
でも何かがしっくり来ませんでした。当時のマネージャーとの雰囲気があまり合っていなかったと思いますし、問題空間全体もFacebookの中核とは少し違っていたと思います。Facebookはソーシャルプロダクトでした。一方で検索エンジン、検索問題はより情報検索寄りで、同じものではありません。だから、自分は正しい場所にいないという感覚がありました。
それで6か月後、別のチームに移りました。それがFacebook Gamesでした。
それは何年のことですか？
2016年です。
その検索チームの問題は何だったんですか？大量のニュースを素早くインデックスして提供するにはどうすればいいか、という問題でしたか？主な技術的課題はコールドスタート問題のようなものだったんですか？
そこには多くの興味深い問題がありました。私が解決を手伝った問題は、より技術的なものでした。
私たちにはメモリに制約のあるマシンがありました。より多くのメモリを持つマシンへ垂直スケールさせると高価です。では、検索インデックスをできる限り多く、そのマシンにどうロードするか。それが私が取り組んだ問題でした。
私がそれを解決した方法は、ロードされているデータを調べ、データを大幅に圧縮できるパターンを特定することでした。私は9ギガバイトのインデックスを400メガバイトにしました。非常に大きな圧縮でした。
それはデータを見て、ああ、私たちは256を超えることが絶対にない数値に対して、こんなに多くのビットを使っているんだ、と気づくことによって実現しました。そういう問題が非常にたくさんありました。データを扱い、分析することによって、機会を見つけることができたのです。
面白いですね。では、Newsはサイドクエストで、メインクエストはGamesだと思ったんですね。そこに本筋がある、と。
実は、最初からそう気づいていたわけではありません。面白い話があります。
Zuckが、上院議員、私たちは広告を運営しています、そう言っていたミームを知っていますよね。Facebookは間違いなく広告の会社でした。そしてFacebook内のチームは、社内のエンジニアを自分たちのチームに採用するために、Facebook上で広告を出していたんです。
私はスマホでFacebookをスクロールしていました。すると広告が出てきました。それはGamesチームからのものでした。そのチームが広告を出していて、こう書いていました。私たちはここで非常に刺激的なプロダクトに取り組んでいます。BlizzardやZyngaなどの企業と協力して、Facebook上、Messenger内、そしてあらゆる場所で非常に面白いゲームプラットフォームを作っています。
それに私は強く引き込まれました。私は自分自身がかなりのゲーマーでした。ゲームに取り組めば、とても楽しいだろうと思いました。そこで移ることに決めました。
待ってください。Facebookが社内の開発者ポジション向けに、社内広告を出していたと言っているんですか？
そうです。
今でもやっているんですか？
今は分かりません。でも当時はそういうことがありました。
彼らはあなたがFacebookをスクロールしていると分かっていたわけですから、あなたに届く最善の方法を知っていたんですね。
ええ。社内で広告を出す場合、誰も自腹を切る必要はありませんよね。なので、人々は採用のためにそれをやっていました。Facebook内では、ブートキャンパーを獲得するために、異なるマネージャー間で実際かなり競争が激しかったんです。
新しく会社に入った人たちは、自分がどのチームで働くかを選ばなければなりません。だから欲しい人材を獲得するのは非常に競争的でした。常に多くのチームに空きポジションがありましたが、そのチームはブートキャンパーのところへ行って、自分たちのチームに誘い込まなければなりませんでした。マネージャーたちは人を引き入れるために、非常に面白いことをたくさんしていました。
Facebook Gamesで学んだプロダクトマーケットフィット
Games部門の中核的な技術課題は何だったんですか？
そこでもっと面白かった問題は、プロダクト上の問題だったと思います。技術的な問題については、Facebook内の多くのものに非常に良いインフラがありました。キャッシュを再発明する必要はありません。データベースを再発明する必要もありません。そうしたものはすべてすでに作られていました。
プロダクトチームが主に扱うのは、プロダクトマーケットフィットでした。どんな機能が実際にユーザーに採用され、実際に価値を持つのか、ということです。
当時、私はゲーム開発者と話すことに多くの時間を使い、彼らがどのようにゲームを設計するのかを理解しようとしました。どんなゲームがFacebookプラットフォームでうまく機能するのか。ソーシャルゲームは、まだ答えが確立されていなかったからです。
Facebook Gamesの時代より前は、誰もがよりスタンドアロン形式でゲームを作っていたと思います。ゲームを作り、それをSteamで売る。それで終わりです。
でもFacebookはソーシャルプラットフォームです。人々は会話の中で物事について話します。ニュースフィードに物事を投稿します。コミュニケーションのプロトコルがまったく違います。だから私たちは、そのソーシャルな力学にうまく合うようにプラットフォームを設計する必要がありました。
それには、プラットフォームとゲーム開発者の共同開発が必要でした。時にはユーザー自身も関わりました。私はゲーム開発者と話し、どんなゲームがうまく機能するかを共同で設計することに多くの時間を使いました。
また、ゲーマーとも話しました。FarmVilleをプレイする人、Messenger内のバスケットボールゲームをプレイする人、Words with Friendsのようなゲームを遊ぶ人たちです。そうしたユーザーと話して、どんな状況で実際にゲームをプレイするのか、誰とプレイするのか、ゲーム活動についてどんなプライバシー上の前提を持っているのか、そういったことを理解しました。
成功するプラットフォームが何なのかを見極めるには、そうしたあらゆる側面を理解する必要があったと思います。それがおそらく、私が取り組んだ中で最も興味深い問題でした。
そうしたパートナー全員と話した後、アウトプットは何だったんですか？開発者に公開するAPIや機能の使いやすさを考えていたんですか？実際のアウトプットは何だったのでしょうか？
一つの例を挙げます。そのプロジェクトを始めたとき、私たちはバスケットボールゲームから始めました。今でも覚えている人は多いかもしれません。Messengerでバスケットボールを投げてスコアを得ることができ、そのスコアがスレッドに投稿され、人々が競争するというものです。
私たちはそれを見て、多くの人がその形式でゲームをするのを好んでいることを見ました。そこで、ハイスコアの仕組みを持つ他のゲームも同じように入ってきて遊べるようなプラットフォームを作れば非常に面白いだろうと考えました。
そのため、私たちはハイスコアとリーダーボードの仕組みを前提に、プラットフォーム全体を設計しました。そしてそれは大きな間違いでした。
私たちは数か月かけてその仕組みを作り、ユーザー体験のあらゆる部分をその前提で構築しました。そしてプロダクトをローンチしました。プラットフォームをローンチしました。いくつかのゲームも同時に公開されました。たしかクリスマス前にローンチしました。
休暇後に戻ってきて、ユーザーリテンションの数字を見ると、非常に悪かったのです。そこで私たちはゲーム開発者と話し、理由を理解しようとしました。
最初のローンチ時、私たちは多くのゲーム開発者とすら話していませんでした。ただ自分たちが有用で成功すると考えたものを作っただけでした。これはうまくいくはずだと想定し、ゲーム開発者には、この形式で私たちと一緒にやってください、質問はしないで、私たちの言う通りにしてください、と伝えました。SDKを渡し、こういうものです、と言っただけです。
それが本当に機能していないと分かった後、なぜだろうと考えました。そして、ゲーム開発者と話して、彼らがこれについてどう考えているかを見てみようと気づいたのです。彼らは何十年もゲームを作ってきた経験があります。
そこで彼らと話すと、彼らはこう言いました。ハイスコアの仕組みは制約が強すぎるのです。ここにはWords with Friendsのようなゲームがたくさんありますよね。それはハイスコア形式にはうまく合いません。ハイスコアが存在しないからです。ターンごとにプレイする、ターン制のゲームです。
他の人たちには、リアルタイムマルチプレイヤーゲーム、IO系ゲーム、その他さまざまなゲームがありました。それらは、私たちが提供した形式にはうまく適合しませんでした。
そこで私たちは、間違った前提を置いていたことに気づき、プラットフォームを再設計する必要があると分かりました。SDKの提供方法やユーザー体験の提供方法を作り直しました。ハイスコアに関する前提をすべて取り除きました。どんな活動を投稿する価値があるのか、その柔軟性をゲーム開発者自身に渡しました。
すると物事が動き始めるのが見えました。人々はクイズゲーム、トリビアゲーム、ターン制ゲーム、そうした非常に面白いものを作りました。そして人々はどんどんプレイするようになりました。
顧客と話して理解しないという、典型的な罪を犯したわけですね。そして作って、使われていないと気づいた後で、初めて彼らと話すという最初のステップを始めた。
そうです。Gamesプラットフォームでは面白い点があります。三つの当事者がいるのです。一つはプラットフォーム、一つはゲーム開発者、そして実際のプレイヤーです。この三者はそれぞれ異なる関心事を持っています。だから本当に良いフィットを見つけるには、その三者すべての間を行き来しなければなりません。
マネージャーになる決断とVPからの警告
このゲーム開発の仕事の間に、あなた自身のキャリアも成長していたんですよね。この期間にジュニアからE7まで行ったわけです。
はい。そして途中で2年間、人のマネージャーになるという寄り道もしました。その旅も非常に興味深く、多くを学びました。
ではそこを掘り下げましょう。マネージャーになる話はどういうものだったんですか？何を学びましたか？その後、ICに戻ったと思います。だから恒久的なものではなかったわけですよね。
そうです。私は自分の好奇心に従っていたのだと思います。長い間ICとして働いていました。キャリアの中でICとして8年目くらいだったかもしれません。ピープルマネジメントの役割がどのようなものなのか、一度も探ったことがないと感じました。好きになるかもしれないと思いましたし、それが最終地点になるだろうとかなり確信していました。
機会が訪れたので、私はただイエスと言いました。それも面白い話でした。マネージャーが私のところに来て、チームをスケールさせる必要がある、チームが成長しているから、その一部を支えるマネージャーが必要だ、と言いました。人がどんどん増えているからです。そこで、そのマネージャーになりたいかと聞かれました。私はすぐにイエスと言いました。
それが自然な次のステップだと思いましたし、なぜやらないのか、という感じでした。その役割がどのようなものなのか見てみたいという好奇心もありました。
その後、VPが私と1対1の面談をしました。そのVPは、今OpenAIでApplicationsのCTOを務めているVJです。
おお。
当時、Facebook Gamesの私たちのVPでした。彼と話しました。彼は私との1対1を設定し、部屋に入ると、なぜマネージャーになりたいのですか、と聞きました。私はいろいろ話しました。そして最後に彼は、それは全部レッドフラッグだと言いました。君はマネージャーになるべきではない。マネージャーになるべきではない。それは正しい動機ではないし、おそらく好きにならないだろう、と。
待ってください。何を言ったんですか？その中で最大のレッドフラッグは何だったんですか？
私は、おそらくこういうことを言いました。もっと大きなインパクトを出したい。自分のスコープを本当に広げたい。もっと大きなプロジェクトに取り組みたい。自分一人ではなく、人々のグループに影響を与えたい。一人でできることを超えて働きたい。
それは、私がマネージャーを誰か捕まえて、マネージャーになったときの話を聞かせてください、VPやディレクターに、なぜマネージャーになりたいと言ったんですか、と聞いたら出てきそうな答えですよね。彼らも同じことを言ったでしょう。
そうです。そうしたことは、マネジメントの役割を経験したことがない人が、その役割とはこういうものだろうと想定する内容だと思います。そして多くのマネージャーにとっては、実際にそれが当てはまります。彼らはそうやって動き、その役割から価値を得ています。
でも私が2年間マネジメントの役割にいた後では、そのVPに同意します。あの動機は正しい動機ではありませんでした。大きな問題に取り組むことだけがマネジメントに行く動機なら、それはマネジメントにならなくてもできます。人々に影響を与えることも、大きな問題に取り組むこともできます。多くのICがそれをやっています。私も今それをしています。
マネジメントとは、本当はもっと他者を支えることです。ここにチームがある。どうすれば彼らがもっと多くのことをできるように助けられるか。どうすれば彼らがキャリアで成長できるよう助けられるか。多くの時間がそこに費やされます。そしてチームを強くするために、どうすれば適切な人材を採用できるか。つまり、その多くは支援的な役割です。
それが私がICに戻る決断をした理由でした。何週間も何週間も、自分のカレンダーを見ると、毎週70％ほどがすでに埋まっていました。それは定期的なものです。毎週同じことを繰り返し続ける。1対1が非常にたくさんあり、チームミーティングが非常にたくさんあり、他組織とのミーティングなどもあります。そうした定期的なものです。
私は、これはすごく消耗するな、これを20年続けるとしたら、できるかどうか分からない、と思いました。
あなたのVPは、あなたがレッドフラッグだらけの答えをした後でも、マネージャーをやらせてくれたんですね。
そうです。面白いですよね。なぜそうなったのか。面談の後、私は自分のマネージャーのところに戻りました。当時の私のマネージャーは本当にスケールさせる必要がありました。チームは非常に速く成長していました。Gamesプラットフォームはうまくいっていて、もっと人が必要でしたし、チームはスケールしなければなりませんでした。彼がすべての直属部下を抱え続けるのは無理でした。
そこで私のマネージャーは、何を言えばいいかを教えてくれました。
テストの答えを教えてくれたんですね。
正しい答えは何か、ということです。私はそれを実行しました。そして再びVPのVJのところへ行き、その答えを伝えました。
VJはとても賢かったです。彼はこう言いました。こういう一晩での変化は信じていない。君の答えは完全に変わっている。それは、物事の進み方として自然ではない、と。彼は何が起きているか分かっていました。
それでも彼は、君にチャンスを与える、と言いました。私はチャンスを与えるのが好きだ。君はこの機会を本当に大切にした方がいい、と。
彼は私の働き方を見ていました。彼は、私が他の人をコーチし、教育するのを助けられる非常に良いエンジニアだと信頼してくれていました。だから基盤はあり、信頼はありました。VPは、よし、チャンスを与えよう、という感じでした。
マネジメント経験から学んだ「コントロールを手放す」こと
マネージャーになって何を学びましたか？事前に想像していたことと、現実があったと思います。期待通りだったものと、完全に予想外だったものは何でしたか？
期待通りだったのは、そうでなければおそらく触れることがなかった多くの問題に触れられたことです。チームが成長し始めると何が起こるのか。どんな問題が表面化し始めるのか。そうしたものはエンジニアの視点からは明らかではありません。でもマネジメントの視点からは、それに対処しなければなりません。
チームに適切な人を実際に採用する方法もそうです。それには実際、多くの投資が必要です。だから学びや好奇心の観点では、期待に合っていました。多くを学びましたし、その一部は非常に面白いものでした。
今でも、たとえばエージェントと仕事をするときに、マネジメント経験からかなり恩恵を受けたことの一つは、コントロールを失うことを学んだことだと思います。
チームを持ち、自分自身ではなく他者を通じて働くとき、問題に対する直接的なコントロールを失います。コードベースをコントロールすることはできません。コードベースは見た目が悪いかもしれないし、自分は気に入らないかもしれません。
それは今日、AIエージェントと働くときと同じです。AIと働くときに、すべてをマイクロマネジメントする人がいます。AIが自分の好まないコードを生成すると、それを微調整したり、まさに自分が望む通りにやらせようとプロンプトしたりすることに多くの時間を費やします。それは間違いだと思います。
AIと働くときにも、多くの同じパターンが当てはまると思います。組織の視点から考え、直接的なコントロールを持たないところから始めなければなりません。すべてのエージェントがより良く働けるように、どんな原則を書き下せるかを考える。そしてその方法で方向性をコントロールするのです。
だから、たとえICに戻ったとしても、マネジメント経験の多くは実際にはかなり有益でした。
本当に驚いたことは何でしたか。そして最終的に、ICに戻って再びコードを書くことを望ませたものは何でしたか？
それは消耗する側面だったと思います。2年間マネージャーをやった後、私は実際にはかなり良いマネージャーでした。チームは私を気に入ってくれていましたし。
自分で言うなら、ですね。
サーベイの結果も非常に良かったです。会社がサーベイを実施し、私はそれを見て、平均や他のチームと比較しました。かなり良かったのです。私はその役割にしっかり向き合い、自分の動き方を変えました。マネージャーとしてどう振る舞うべきかについて、良い本もたくさん読みました。なので、うまくやれたと思います。
でも、うまくやると何が起きるかというと、人々はもっとやってほしいと思うようになります。より大きなチームを引き受けてほしいという依頼を受け始めました。チームはまだ成長していて、他のマネージャーが会社を去ったこともあり、チームを少し再編する必要がありました。そこで、このより大きな組織を引き受けたいか、と聞かれました。
それが私に本気で考えさせるきっかけになりました。突然、自分がこれからの10年で何をすることになるのかが見えた気がしたのです。私はこのより大きな組織を引き受ける。その後、VPではないにしても、おそらくディレクターがやっていることをする。そして彼らが何をしているのかが見える。でもそれは私にとってそれほど楽しくありませんでした。
突然、これから10年自分が何をするのか予測できるなら、それは自分がいたい状態ではないと思いました。私はもっと冒険的な働き方が好きです。毎週何をするかが分かっている状態は望んでいません。潜在意識の中に、今はそれをやらない方がいいかもしれない、と告げるものがあったように思います。だから、そのトラックをさらに深く進むのは今ではないと判断しました。
つまり、その軌道を見たわけですね。この道を進み続けたら、VJの仕事を得ることになる。でも彼がしていることは好きではない。彼のことは好きだけれど、という感じですか？
実際には、VJの仕事は好きでした。ただ、彼の仕事にたどり着くには長い時間がかかると思いました。VJは非常に強い人物で、VPだったとき、ビジネスのあらゆる側面を管理できていたと思います。もはや単なるエンジニアリングマネージャーではなく、実際にはビジネスオーナーに近いものでした。
それは好きですし、楽しめると思います。でもそこに到達するにはかなり時間がかかります。最終地点としては良いかもしれないけれど、その時点でそのトラックを進み始める場所ではないと感じました。
だから、少なくともあと10年くらいはICとして過ごし、自分のモチベーションを保ち、起きている面白いことを本当に学ばせてくれる問題に取り組もうと思いました。このマネジメントの役割に長期的にコミットすることなく、そうしたいと思ったのです。
マネージャーになるよう求められたとき、あなたはシニアエンジニアだったんですか？
E6でした。Staffだと思います。
Staffで、そこでマネージャーになるよう求められたんですね。そしてStaff Engineerに戻った。Gamesにはそのまま残ったんですか？
はい。
そして同じGamesでE7まで行ったんですね。
はい。同じチームです。私が話した人の中には、マネジメントに入った後、同じチームでICに戻ることに不安を感じている人もいました。人々が自分を違う目で見るのではないか、失敗したと思われるのではないか、などと感じていたのです。そうした小さなエゴが、それをやるなと彼らに言っているわけです。
でも、それは間違った見方だと思います。少なくとも私の経験では、私は同じチームにいました。マネージャーからICに戻りました。それは実際に素晴らしい決断だったと思います。
もし違うチームに移っていたら、私の生活はもっと大変になっていたと思います。同じチームなら、人々はすでに私を信頼しています。私はチーム内の非常に多くの人とすでに働いていました。だからICとして、すぐに強い影響力を確立できました。以前から一緒に働いていた多くの人と、非常に簡単に仕事ができました。
正直なところ、あなたが何であるかなど誰も気にしていません。私たちは時々、人々が実際よりもずっと自分のことを気にしていると思いがちです。
スポットライト効果ですね。
そうです。
みんなが自分を見ていると思うけれど、実際には見ていない。
その通りです。マネジメントかICかについて、誰もあなたが何をしているかを考える帯域は本当にありません。彼らには彼ら自身の仕事があります。自分自身のキャリア成長があります。それを管理しているのです。あなたが何をしているかは、おそらく1週間くらい話題になる価値はあるかもしれませんが、その後は誰も気にしません。
だから、ICの役割に戻りたいけれど、見られ方を心配している人がいるなら、それをあまり考えすぎない方がいいと言いたいです。
StaffからE7へ進んだプロジェクトとインパクト
シニアからStaffへ、そしてマネージャーになった後にStaffからSenior Staff、つまりE7へ行くきっかけになったプロジェクトや状況は何だったんですか？
それは主に、私たちが行ったことのインパクトです。
シニアからStaffに行ったのは、主にMessenger上のGamesプラットフォームを立ち上げ、実際にプロダクトマーケットフィットがある状態に持っていったことでした。そこには多くのゲームが走っていて、かなりうまく機能していました。私はその大きな一部でした。
だから、ビジネス上の成果がそれを正当化したと思います。そしてその成果を達成するために、私は実際に多くのゲームスタジオへ出向き、開発者たちと話し、シニアエンジニアが通常やることを超えた動き方をしなければなりませんでした。プロダクト上の意思決定などにも、より多く関わりました。そこでの私の経験の戦略的な影響力が、Staffへと導いたのだと思います。
Facebookは有名な話として、特に初期にはプロダクトマネージャーを採用することに非常に慎重だったと思います。今は強力なプロダクトマネジメントチームがあることは知っていますが、これはその移行期のようなものだったんですか？ソフトウェアエンジニアにも、もっと大きなプロダクトインパクトが期待されていたということですか？
はいでもあり、いいえでもあります。チームによってはそうでした。一部のチームでは、エンジニアがプロダクト上の意思決定も担うことが実際に期待されていました。でも会社全体で一律にそうだったわけではありません。
当時の私のチームでは、それは期待ではありませんでした。プロダクト思考の役割を果たさなくても、うまくやることはできました。必ずしもそれをする必要はありません。多くのエンジニアは、良いエンジニアであるだけでかなりうまくやっていました。
でも私はそれをするのが好きでした。そしてそれがビジネスのボトルネックだと感じていました。プロダクトマーケットフィットを理解すること、ビジネスを本当に正しい軌道に乗せることです。もしそれをしなければ、そのプロジェクトはあのインパクトもプロダクトマーケットフィットも持てなかったでしょう。だから私は、プロジェクトを成功させるためにそれをやらなければならないと感じました。私のインパクトを正当化したのも、プロジェクトの成功でした。
純粋なエンジニアとしてやることだけをやっていたら、プロジェクトはおそらくあそこまで成功しなかったでしょうし、私も昇進していなかったと思います。
ゲーム会社へ飛行機で行き、彼らに会って話したわけですよね。自分で必要だと気づいて、航空券を予約して行ったんですか？それともマネージャーが、こういう人たちと話した方がよさそうだ、と言ったんですか？
それはグループでの意思決定でした。私だけではありません。休暇から戻ってきてデータを見ると、良くありませんでした。そこで私たちは、どうすればいいのかと話し合っていました。
Facebookには当時すでに、人々と会うために行くイベントがいくつかありました。そこで、そうしたイベントを活用しよう、ゲーム開発者を招待してイベントに来てもらい、そこで話そう、ということになりました。イベントに来なかった開発者については、私たちが彼らのところへ行きました。なので、グループでの意思決定です。
でも、オフィスにいて、自分はここにいます、イベントには行きますが、この隔離されたサイロの中でこれをやっています、という態度でいることも簡単だったはずですよね。
そうです。特にエンジニアがグループでイベントなどに出張するとき、内向的な人にとっては特にそうだと思います。私自身も内向的です。デフォルトでは、自分の隅に隠れて、自分のことをやる、という感じになります。誰かが助けを必要としたら助けに行く、というだけです。
でもビジネスの成功に本当にインパクトを与えるには、そこから抜け出す必要があると思います。境界から抜け出して、自分を単なるエンジニアだと考えないことです。自分を、自分が関わっているどんなプロジェクトでも大きな役割を果たせる非常に賢い人間だと考えるのです。
そのプロジェクト以来、私はこの考え方を持つようになりました。肩書きは重要ではない。自分がエンジニアであろうと、他のどんな肩書きを人々が与えようと、自分がやることは変わらない。自分がやることは常に、このビジネスを成功させるために自分ができる最もインパクトの大きいことは何か、ということです。
E6からE7へのジャンプはどうでしたか？そこではどんな状況がありましたか？
それはGamesプラットフォームの継続的な成長と、GamesプラットフォームがMessenger中心の体験からFacebook全体のプラットフォームへ進化したことだったと思います。
多くのゲームも進化する必要がありました。私たちはMessenger内から始め、その後プラットフォームをどのように成長させるかを考えなければなりませんでした。Facebook News Feedは、実際にはまだそれほど深く探索されていない非常に大きなサーフェスでした。そこでいろいろなことを行いました。
その後、ライブストリーミングプラットフォームもありました。Facebook Gamingのライブストリーミングプラットフォームです。それによって、チーム全体のミッションも変わりました。私はそこで、どのように戦略を合理化するか、Messengerスレッド内のターン制ゲームからより大きなエコシステムへとプラットフォームを進化させるかに、大きく関わりました。それがおそらく私のE7のインパクトだったと思います。
その中で、E6の期待範囲だった部分と、より大きなインパクトだった部分がどこなのか気になります。Messenger内のターン制ゲームの外へ、もっと大きなスコープを追うべきだと、どうやって嗅ぎ分けたんですか？
物事がうまくいきすぎると不安になる
一般的に、私は物事を次のレベルへどう持っていけるかという感覚を持っています。どんなプロジェクトに取り組んでいても、常に自問しています。私は決して満足しません。
プロジェクトが順調に進み、すべてがスムーズに動いているとき、私はパニックになります。何かがおかしいのではないか。なぜこれはこんなにスムーズに進んでいるのか、と思います。
物事が非常にスムーズに進んでいて、自分がいてもいなくてもそのまま進むだろうと感じるなら、自分は価値を加えていないということだと思うからです。では、なぜ自分はここにいるのか。もっと有用な別のことをした方がいいのではないか。
だから私は、その状態になるたびにパニックに近い感覚を持ちます。そして物事をまったく別のレベルに持っていくにはどうすればいいかを、本当に一生懸命特定しようとします。
それにはしばしば、ステップ関数的な変化に主体的に取り組む必要があります。単に同じことを続けて、少しずつ成長し、同じことをもっと速くやるということではありません。物語を考え直すのです。本当にまったく違うことができるのか。戦略全体を考え直せるのか。
なので、私は自分が取り組んでいるものを再発明したり、再構築したりする一定のリズムを持っているのだと思います。
物事がうまくいっていると不安になるんですね。
はい。
カオスの中で力を発揮するんですね。多くの人はカオスの中にいると、何が間違っているんだ、この会社はひどい、このカオスは何なんだ、と思います。そして一生懸命働けば、物事がある程度自動で回る穏やかな海にたどり着けるかもしれない、と考えます。だから彼らは逆のことをする。ほとんどの合理的な人は、カオスに直面すると不安になると思います。でもあなたは逆のモードでできていて、スムーズすぎると不安になる。そういう不安を感じるんですね。
そうです。物事がカオスなとき、私はそのカオスを解決しようとします。そしてそれが楽しい部分です。物事がカオスで、それを見て理解しようとする。なぜこんなにカオスなのか。何が起きているのか。どうすれば解決できるのか。どうすれば良い状態に持っていけるのか。その問題を解くことが、私を動機づける楽しい部分でした。
物事がただ順調に進んでいるとき、私は、なぜ自分はここにいるのか、自分は人生で何をしているのか、という危機感を持ちます。そしてもっとカオスなものを探し続けます。
それが、私がFacebookからMicrosoftへ戻った理由の一つでした。Gamesプラットフォームは確立されたと感じたからです。まだ新しくやれることはいくつか見えていましたが、大部分はもうそこにありました。私はもっとゼロから始めるようなものを試したいと思っていました。
当時Microsoftは、MSN上にGamesプラットフォームを作ろうとしていました。私は助けられると思いました。Gamesプラットフォームの作り方を知っていたからです。そこでMicrosoftに行き、それをゼロから始めました。完全なゼロから一です。非常に楽しく、非常にカオスでした。私は本当に楽しみました。
MicrosoftにはPartnerレベルで戻ったんですよね。ゼロから一。再びカオスを見つけた。ただし今回は、ずっと多くのドメイン専門知識を持った状況だった。問題を解決して、それがまた穏やかになったから次に進んだんですか？
それも理由の一部です。私はMicrosoftで2年間、そのGamesプラットフォームをゼロから一へと構築しました。話していた開発者は、ほぼ同じ人たちでした。
ああ、君のこと覚えてるよ、みたいな。
そうです。でも私にとっては非常に違う経験でした。Facebookでは、私を支える他の機能がすべてありました。開発者たちとビジネス契約を結ぶことを心配する必要はありませんでした。彼らが十分にお金を稼いでいるか、稼げていなければプラットフォームからゲームを引き上げてしまうのではないか、と心配する必要もありませんでした。
ゲーム内に広告を出し、全員がお金を稼げるようにする広告主をどう見つけるか、どんな広告主がいるのか、といったことも心配する必要がありませんでした。以前はそれらの問題を一切心配する必要がなかったのです。
でもMicrosoftでは、これをやろうと提案したのが私でした。彼らは新しいプラットフォームを立ち上げることにある程度関心を持っていました。それが私が参加した理由です。でも実際にプラットフォームをどう構築するかについて、誰もアイデアを持っていませんでした。そこで私は、新しいプラットフォームはこうやって作る、と提案しました。
そのとき私は、新しいビジネス全体を本当に確立することがどれほど複雑なのかを理解していませんでした。ビジネス開発の側面、そしてお金の側面、全員を満足させる方法を完全に過小評価していました。だからその2年間でも多くを学びました。以前のようなエンジニアリングリーダーとしてというより、ビジネスオーナー、プロダクトグループリードとして学んだことが多かったと思います。
マネジメントではなくICとして事業を立ち上げる
再びディレクターレベルや、マネジメント、人のマネジメントに戻ることに誘惑されることはなかったんですか？
ああ、それははっきりノーと言いました。Microsoftが当時私に連絡してきたとき、その役割は明確には定義されていませんでした。彼らは新しいプラットフォームを立ち上げたいだけでした。それはマネージャーやディレクターになるのか、それともそれを助けるICになるのか、彼らは決めていませんでした。
そこで彼らと話し、私はこう説得しました。ここで本当に必要なのはICだけです。ディレクターである必要はありません。そして、私はマネージャーにはならない、と言いました。ICとしてそれをやるなら楽しめる。マネージャーやディレクターとしてそれをやるなら、それほど楽しめないだろう、と。
その感じは分かります。仮にディレクターレベルで連れてこられたとしても、あなたはおそらく何らかの方法でICに戻り、貢献しようとしたでしょうね。
Philip Suにこのポッドキャストに何度か出てもらったことがあります。彼はE9まで行ったと思いますが、その後、構築に戻らなければ、コードに戻らなければ、と思った。そして再びコーディングを始めるために降格を受け入れました。同じ雰囲気を感じます。ビルダーであり、カオスの中で力を発揮する人は、どうしても作っていなければならないのだと思います。
今のソフトウェアでは、そのサイクルがあると思います。そして今は、あなたが構築するには完璧な時期です。AIについてはすぐに話します。
まずキャリアアドバイスについて話しましょう。あなたがICとしてFacebookやMicrosoftで働いていた頃から、状況はかなり変わりました。今、業界に入ろうとしている人たち、そして中堅の人たちには、どんなアドバイスをしますか？彼らはどうすれば自分のキャリアを最もよく守れるでしょうか？どうすれば際立てるでしょうか？
私のアドバイスは、ジュニアの人、中堅、シニア以上でかなり違います。
まず、特にジュニアの人たちには、自分がやることに本当に優れていることが非常に重要だと言いたいです。それがすべての土台です。とにかく作ることです。自分が面白いと思い、楽しんでやれるものを作る。たくさん作る。
Microsoftでキャリアを始める前、私はおそらく100個くらい、さまざまなおもちゃのようなものを作っていました。そのうちいくつかは実際にお金で売れました。チートツールなどです。でも多くは一銭にもなりませんでした。多くは純粋に楽しみのためのものでした。
それはいいですね。人々はいつも私に聞いてきます。Steve、注目されるためにはどんなサイドプロジェクトを作るべきですか、と。あなたは、100個作れ、と言っているわけですね。
そうです。一つのものにコミットしすぎないことです。そうしたサイドプロジェクトや趣味で作った面白いものから得た最大の価値は、本当にさまざまな技術やツールに触れられたことでした。本業では触れることがなかったものです。
特に大企業では、技術スタックは安定しがちです。Cだけを使うとか、非常に特定のシステムだけを扱うとか、それを2年間ずっとやることになります。だから私たちは、業界の幅を探索するために、こうしたサイドプロジェクトが必要だと思います。それが一つです。
もう一つは、楽しみのためにただやるというマインドセットに本当に入ることです。それも非常に重要です。そうでなければ、モチベーションを失いがちです。楽しむ方法を持たない人は、時間があると他のことをします。TikTokをスクロールしたり、他の楽しいことをしたりします。それ自体は問題ありません。
でもソフトウェア開発のキャリアを本当に深く進めたいなら、何時間でも続けられるような、自分を動機づけ続けるものを見つける必要があると思います。
私はよく、時間があると、長い一日で疲れ切って座ったとき、自分が自然に引き寄せられるものは、自分が面白いと思うものを作ることでした。それが私にとって最もリラックスできることだったのです。そうした心の状態、そのメンタリティを見つけることは、この領域で本当に深いスキルを育てるうえで非常に有用だと思います。なので、間違いなく勧めます。
ジュニアに必要なのは大量に作ること
それはすごくいいですね。たくさんのことをするのは本当に重要だと思います。あなたはBingの自動補完に取り組みましたが、自動補完だけでは深掘りできる範囲には限界がありますよね。
そうです。
大企業で働くと、あなたはより大きな組織の一部になります。だからスタックの非常に特定の部分に取り組むことになります。InstagramのAndroidクライアントのアプリ読み込み時間を担当して、さらに10ミリ秒削る、といったことをやっているかもしれません。その追加の10ミリ秒を得るには、何が起きているのかを本当に理解する必要があります。でも見ているのは、そこにあるもののごく小さな表面領域です。
そうです。
だから、ゲーム化できるかという考えはとてもいいですね。そして、自分がやることに非常に優れているという考えも好きです。あるものの90パーセンタイルの実装がどのようなものか分かっているか。そしてそれを、単なるチェックボックスとして完了させるのではなく、実行できるか。
完全にそうです。
ジュニア向けのあなたのアドバイスは、最初の仕事を得る前にも良いと思いますし、仕事に就いた後にも良いと思います。自分のスキルの幅を温かく保ち続けることです。たとえ仕事で狭い表面領域に取り組んでいたとしても。
では中堅エンジニアについてはどうですか？
中堅、そしておそらくシニアの役割の一部にとっても、私が最も恩恵を受けた要素は、自分の好奇心に従うことでした。
退屈だと感じたとき、成長していないと感じたとき、もっと学んでいないと感じたとき、私はジャンプします。出ていくのです。
不安になるんですね。
そうです。別の取り組むものを見つけます。振り返ると、それは自分にとって非常に有益でした。もしそうした快適な場所にとどまり、すべてが順風満帆で、これまでやってきたことを続けていたら、毎月給料はもらえたでしょう。何の問題もなかったはずです。でも、今触れられたような新しいものすべてを学ぶことはできなかったでしょう。
だから、好奇心に従い、これまでやってきたことをそのままやるだけで快適になることを決して許さないことが重要だと思います。
日々の仕事とはまったく直交する何かを学ぶと決めた、好奇心に従った例を挙げてもらえますか？
何度もあります。MicrosoftにいたのをやめてFacebookへ移ったとき、それは一度でした。退屈だと感じていました。自分はすでにやってきたことをしているだけだと感じました。だから新しいことを試したいと思いました。そしてFacebookは新しいものでした。Facebookがどう動くのか分かりませんでした。あれほど大きなソーシャルネットワークは、どう動いているのか。特に内部はどうなっているのか。私はその好奇心に従ってFacebookへ移りました。
そしてFacebook内でも、NewsではなくGamesに取り組むために好奇心に従いました。Gamesの方がもっと学べると思い、働くのももっと楽しいだろうと感じたからです。
その後、マネジメントに移ったことも好奇心に従ったものでした。その役割がどういうものなのか知りませんでした。一度試してみたかったのです。そしてどこに着地しようと、何か新しいことを学べると分かっていました。学びが、そうした変化の多くを選ばせる原動力でした。
その後、FacebookからMicrosoftへ戻ったのも、好奇心に従ったものでした。私が最も繰り返したパターンは、自分が常に何か新しいことを学んでいるようにすることでした。好奇心が導く場所へ従う。それが私を学び続けさせ、モチベーションを保たせてくれました。だから私はいつも自分がやることにエネルギーを持っていました。それも非常に重要だと思います。何かに本当に情熱を持っていると、最善を尽くします。単に給料をもらうためにそこにいる多くの人よりも、本当に上回ることになります。だから、その場所を見つけることは非常に有益です。
新しい場所へ移ったとき、好奇心に従っているとき、その瞬間はその一つのことに一点集中していたんですか？それとも、サイドクエストをすることもありましたか？たとえばゲームの仕事をしているときに、JPEGがどう動くのか気になる、と深掘りしたり、日々の仕事とは関係ないけれどReactを学ぼうとしたりしたことはありますか？
それはあまりしませんでした。私はたいてい、自分がサイドクエストを探索していることに気づいたら、それはおそらくメインクエストがもうそれほど面白くなくなっているというサインだと捉えます。
だからメインクエストを引き受けて、それが非常に面白いと感じたときは、その問題に全力で取り組みます。あらゆる時間をその問題に費やし、できる限り成功させます。そしてそれをやり終えたら、他の問題に移りたくなるかもしれません。
シニア以上はレバレッジと交渉を理解する
締めくくりましょう。シニアまたはStaffレベルのエンジニア、かなりシニアな人たちには、どんなアドバイスがありますか？
よりシニアな人たちにとっては、状況が大きく違います。少なくとも私の経験では、よりシニアになると、他社から引っ張られることが増えました。
そうなると、どこへ行くかを探る必要があります。以前のマネージャーや、一緒に働いた人たちが他の場所へ移っていて、彼らと良い経験をして信頼関係が築けていれば、おそらく彼らはあなたに連絡してきます。こちらに人が必要なんだけど、来ないか、と。
私はシニアレベルになるほど、それをかなり頻繁に受けるようになりました。そうした状況では、自分のレバレッジを認識し、交渉することを知ることが重要だと思います。
よりシニアなレベルでは、一つの交渉が非常に大きな違いを生むことがあります。時にはレベル一つ分まるごと違うこともあります。別の会社へ移るとき、少し交渉し、その会社があなたを必要としていることを知っていて、自分にレバレッジがあるなら、それを使うべきです。そしてその転職で、場合によってはレベルジャンプを得るのです。
多くの場合、そのレベルジャンプはあなたにふさわしいものです。なぜなら、同じ会社で同じレベルにしばらくいたかもしれないからです。すでに次のレベルでパフォーマンスを発揮していたかもしれません。ただ、まだ昇進を得ていなかっただけです。あなたは成長していたのに、その成長がレベルに反映されていなかったのです。
だから別の会社へ移る機会を使って、この新しい役割における自分の適切なレベルは何なのかを本当に考え直し、それが適切なフィットなのかについて新しい会社と少し交渉できるかを考えるべきです。
デフォルトでは、人々は横滑りの移動をします。なぜなら、あなたを採用している他社には、できるだけ少なく支払いたい、あるいは少なくとも最初からずっと高いポジションを提示しないインセンティブがあるからです。だから人々はそれを理解し、自分のレバレッジを本当に活用する必要があります。
シニアやStaffエンジニア、特にBig Techの人たちは、そのレベルに到達するだけでも非常に有能で高パフォーマンスですよね。そして好奇心に従っていたり、他に何があるかを見ていたりするなら、完全に同意します。彼らが望むのは横滑りかもしれません。新しいドメインでは必ずしもその高いレベルで動けていると感じないからです。でももちろんそうです。移る先は別のドメインなのですから。だから移行のタイミングで、実際には自分にレバレッジがあると認識することは非常に強力だと思います。
そうです。自分を引っ張っている他社が何を必要としているのか、何を探しているのかを理解することです。そして自分がそのニーズを満たす適切なスキルを持っていると感じるなら、そこにはレバレッジがあります。それを使うべきです。
AIは誰の仕事を奪うのか
この話題を少し後回しにしていましたが、AIについて話しましょう。
はい。
ジュニアまたは中堅エンジニアだとして、日々の中でAIをどう考えるべきかから始めましょう。今後数年で、それはどこへ向かうと思いますか？
まず場面設定から始めましょう。人々がよく聞かれる質問の一つは、AIは自分の仕事を奪うのか、だと思います。
AIは100％人々の仕事を奪うと思います。問題は、それが誰の仕事かということだけです。そしてAIが一部の仕事を奪う一方で、AIは新しい仕事も生み出しています。したがって社会全体としては、実際にはソフトウェア開発者、ビルダーが増えるかもしれません。でも一部の人は仕事を失い、他の一部の人は、そうでなければ得られなかった仕事を突然得ることになります。
だから、こうしたダイナミクスが起きていることを見ることが重要だと思います。
私の前職では、多くのCTOと一緒に働き、多くの会社のCTOとも話していました。そのため、多くのチームで何が起きているのかについての視点を得ました。そして彼らには多くの共通点があると思います。
多くの会社が見ているのは、これらのAIツールが勢いを得て、採用されつつあるということです。ほとんどの開発者は、すでに何らかの形でAIを使っています。GitHub Copilot、Cursor、Claude Code、その他のツールを使っています。
でも会社全体を見ると、会社の生産性はおそらく10％、15％しか上がっていません。巨大な増加ではありません。これは、人々がTwitterやソーシャルメディアでAIについて話している様子とは大きく違います。
何が起きているのか。CTOたちがズームインして見ると、会社の中におそらく2％くらい、AIを非常に効果的に使う方法を実際に見つけた人たちがいるのです。この2％の人々は、それによってはるかに生産的になっています。
しかし会社の大多数、主流派はまだAIを非常に浅い方法で使っています。はい、AIは使っています。でもそこから最大の価値を本当に引き出しているわけではありません。主流派の人々には、その2％の人々がやったように次のレベルへ到達するだけの好奇心も足りないように見えます。
だから平均して会社全体を見ると、たしかに10％の向上かもしれない。それほど大きくはありません。そして一部の人は、AIはそれほどインパクトがないと結論づけるかもしれません。
でもそこで彼らは、その2％の中で何が起きているかという全体像を見落としていると思います。そこでは巨大なことが起きています。私たちの動き方、働き方、ソフトウェアを生み出す方法における巨大な変化です。
だから人々は、これは目の前で起きている産業革命だと認識する必要があります。手作業の木工から蒸気機関へ移ったとき、蒸気機関から電気へ、そしてインターネットへ移ったときのようなものです。こうした技術変革は毎回、最初は小さな規模で起き、その後世界全体を覆いました。
まだAIを使うべきか、もっと深く入り込むべきか疑っている人々は、これを本当に理解するための切迫感を持つ必要があります。もし人々が数か月、あるいは今後数年のうちにAIから価値を得る方法を本当に見つけられなければ、企業で起こることは、インパクトのあるプロジェクトがその2％の人々へ移されるということです。
彼らには、トークンをたくさん与えます。そのトークンを好きなだけ使っていい。とにかく前に進み続けてくれ、と言うのです。そしてインパクトのあるプロジェクトは、その2％の人々の手でずっと速く実行されます。
大規模で動きの遅いチームでよく見るのは、たとえばこのボタンの名前を変えましょう、このテキストの一部を変えましょう、という話です。すると彼らは、3か月です、と返してきます。CTOはそれを見るのが好きではありません。そういう動き方を望んでいるわけではありません。
そして時間が経つにつれて、チームがまだ古いやり方で動き、3か月という見積もりを出し続けるなら、ある時点でCTOは、なぜここにこのチームがあるのか、と言い始めます。そしてますますその2％に賭けるようになるでしょう。これは多くの開発者にとって非常にリスクの高い立場だと思います。
Mark Zuckerbergが出てきて、PRを投げ、みんなが承認に入り、おそらくフィードバックを与えるという話がありました。それは実際に起きている。そして私は大きな落ち込みに入りました。自分は何をしているんだ、と。自分のキャリア全体でやってきたすべてのことが、最終的にはAIに取って代わられるのが見えました。
そして私は、AIやAIエージェントにできることについて、自分がゴールポストを動かし続けていたことに気づきました。そして今自分が持ち出しているもの、今自分が入れている慰めは、ただゴールポストを少し動かしているだけで、それは自分を追いかけてくるのだと気づきました。
その後、1月、2月になって、よし、大丈夫だ、これは起きていることの大きな変化にすぎない。自分はそこに入り込み、何が起きているかを理解しなければならない、と思いました。
それで私は火をつけました。Claude Codeは少し前から使っていましたが、本当におもちゃのようなものに対してでした。そこからClaude CodeとCodexに本格的に入り込んでいます。今、私たちが生きている世界はまったく違います。本当に信じられません。
自分の仕事の多くが、エージェントによってできてしまっただろうことが完全に見えます。今では冗談として、ボタンを追加して配置を変えるのに3か月かかる、という話をしますよね。でもそれは、シニアエンジニアが出していた非常に現実的な見積もりです。プロダクトマネージャーは、なぜボタンの挙動を少し変えるためにつなぎ込むのに3か月かかるのか、と言います。すると彼らはこう言います。データが4つの異なるサービスを流れていて、それぞれのサービスに新しいAPI値を通さなければならず、テストのためのバッファ時間も入れる必要があるからです、と。
でも今は入っていって、ボタンを動かして、と言うだけでいい。すると、はい、もちろんです。他に何をしましょうか、となる。
そうです。
AIツールはいつ成熟するのか
先行者利益はあると思いますか？今、その2％の人たちがエージェントに本気で入り込んでいますよね。彼らは98％を置き去りにしていると思いますか？それとも98％の人たちも、ツールが成熟したら入り込めばいいと思いますか？
それは本当に掘り下げる価値のある面白いことです。
私の仮説は、AIモデルが頭打ちになるまで、ツールは決して成熟しないというものです。
過去3年で何が起きたでしょうか。最初はGitHub Copilotが世界で最も先進的なAIコーディングツールでした。そしてその後に起きたことを見ると、Cursorがそれをある種引き継ぎました。Claude Codeがワークフローを完全に変えました。そして今、人々はClaude Codeの上やGitHub Copilotの上にオーケストレーターを作っています。GitHub Copilotはどこへ行ったのでしょうか。
企業環境で強制されている人以外に使っている人を知りません。
そうです。この3年で物事がどれほど速く変わったかを見てください。たった3年です。私たちが使ってきたツールの中には、何十年も存在しているものもあります。そのたった3年で、すでにこれほど変わっているのです。
だから私は、ツールはAIの能力とともに進化し続ける継続的なプロセスだと思います。AIの進歩が止まるまで、ツールの形も変わるのを止めません。
今AIツールを使っているすべての人には、すべては一時的な足場にすぎず、6か月ごと、あるいはもっと速く、すべてを作り直すつもりでいるマインドセットを勧めます。
Cursorを見ると良い例です。Cursorは最初、非常にCopilot的で、GitHub Copilotのようなコード補完から始まりました。その後エージェントを追加し、最近Cursor 3を発表しました。それはCodexに近く、よりエージェント的です。
これらのプロダクトは進化しています。なぜなら、進化せざるを得ないからです。AIが良くなっているからです。そして私たちはもはや、コード補完だけでは十分な価値を得られません。タスクをエージェントに委任し、彼らにそのタスクをやらせることから、より多くの価値を得ます。これは変化し続けます。
Steve YeggeにはGAS Townというコンセプトがあります。今ではそれがより成熟しつつあると思います。最初に出てきたときに試しましたが、それほどよく動いてはいませんでした。でも、それは実際に未来の状態だと思います。オーケストレーションがあり、すべてがAIによって行われる状態です。AIエージェントの軍隊全体があなたのために働きます。そしてこれは変化し続けるでしょう。
GAS Townが最終状態だとは思いません。ただ変化し続けると思います。だから特定のツールにあまり多くの時間を投資することは勧めません。むしろ、継続学習という別のマインドセットに時間を投資すべきだと思います。本当にAIで遊ぶことに入り込み、AIを非常に価値ある新しい働き方として見ることです。それは過去数十年に私たちがやってきたこととはまったく違いますが、未来になるものです。
だから最終的には、そのマインドセットが、ツールの進化についていく力を私たちにもたらすと思います。
完全に同意します。でも、誰もがこのオーケストレーションの終局は何なのか、どこへ向かうのかを理解しようとしている状況は見えます。基盤モデルが頭打ちになったとき、その周辺ツールにある程度の安定性が見えるかもしれないというあなたの指摘はいいですね。
ジュニアは、奇妙なことに、ある意味で良い場所にいると思います。AIを受け入れ、AIネイティブであるなら、です。Cloudflareは最近、111人のインターンを採用するという話がありました。彼らは、AIファーストの若い人たちが組織に多くのエネルギーを注入していることに気づいたのだと思います。
そうです。
おそらく、その2％という数字を押し上げようとしているのかもしれません。
次の論理的な質問は、中堅なら何をすべきか、ということです。ミドルレベルで、おそらくシニアに近づいている、シニア、あるいはシニアに向かっている人にとって、今はこのツール、AIに全力で取り組むべきときなのでしょうか？
AI時代のジュニアとミドルは先輩を飛び越えられる
ジュニアと中堅のエンジニアについては、今二つの陣営が見えます。
一つの陣営は不安になっています。過去数年で学んだことが、AIによってあまりにも簡単に行われるようになっているからです。言語やフレームワークなどを学ぶために多くの時間を費やしてきたのに、今ではAIがそれらをより速くやっています。だから不安になっている人たちがいます。
もう一方には、まだAIを本当に理解していない人たちがいます。大したことではないと思っています。ほとんどの場合スロップを生成していて、それほど有用ではないと考えています。
私は一般的に、ジュニアと中堅のエンジニアの両方に、これを一部のシニアエンジニアを飛び越える非常に良い機会として見ることを勧めます。
何十年も働いてきて、非常に特定のメカニクスを前提にスキルを築いてきた人たちがいます。たとえばJavaを書くのが本当にうまい人がいます。その人のキャリア全体がJavaです。彼らは本当にそれが得意です。Cが非常に得意な人もいますし、特定のフレームワークや言語が非常に得意な人もいます。
そうした人々はシニアで、何十年もの経験を持っています。その一部は今でも非常に価値があります。しかし、彼らが築いた筋肉記憶や、長年にわたって学んできた多くのメカニクスは、今では以前ほど価値がありません。
そのため、そういう人と、今日キャリアを始めたばかりのジュニアとの差は大きく縮まりました。だから、今日始めるジュニアや、まだキャリア初期にいる中堅なら、多くの人、とくに多くの経験を築いてきたけれどAIをまだ信じていない人たちを、十分に飛び越えられます。
彼らは、自分たちが持つレバレッジの面で後れを取ることになります。今、ジュニアと中堅のエンジニアが、AIを活用する方法、すべてのコンピュートを活用する方法を本当に見つければ、非常に多くのGPUがあなたのために働いてくれます。その計算資源は巨大な力です。
その力をどう使って自分のために働かせるかを知っていれば、非常に特定のメカニクスに関する経験だけに頼っている人たちよりも、ずっと多くのことができます。
その再定義はいいですね。人々を飛び越える機会として捉える。私は今年の初めにXを使い始めました。Xでは何が起きているんだろうと思ったんです。そして、世界で最も最先端に触れられる場所の一つである一方で、本当にひどい場所でもあり、エコーチェンバーでもあると感じました。
多くの人が、キャリアはもう終わった、みんな荷物をまとめろ、配管工になる時間だ、と言っています。でも私は、この再定義が好きです。いや、パイプライン問題はないのかもしれない。ジュニアエンジニアは完全に今後も採用されるかもしれない。ただし、それは違うタイプのジュニアエンジニアになる、という見方です。
実際に、人口構造上の爆弾は見えないんですか？シニアエンジニアはジュニアエンジニアから生まれる。もし私たちがもうジュニアエンジニアを採用しないなら、将来シニアエンジニアがいなくなる、という物語がありますよね。
いいえ、活動が変化しているのだと思います。以前に私たちがジュニアやシニアと定義していたもの、その定義はもはや成り立たなくなります。
だから、特に新しい人々には大きな機会があると思います。一部の長くそこにいるシニアよりも価値を持てるようなスキルセットを、十分に築くことができます。
シニアの人たちも、自分のシニア性をどう活用するかを知るべきです。長年かけて築いた経験の多く、特にシステムアーキテクチャの視点から考える方法は重要です。すべてのコード行ではなく、どうすればスケーラブルなシステムを維持できるか。どうすれば不安定な本番環境に対処できるか。どうすれば多数のユーザーにスケールできる健全なシステムを実際に維持できるか。
そうした問題について、AIモデルはまだ特別に得意ではありません。だからその一部のスキルは今でも非常に重要です。そしてシニアエンジニアは、多数のAIエージェントをオーケストレーションして仕事をさせ、それが混乱に変わらないようにできる立場にあります。
そうした経験がなく、工学をまったくやったことのない人がそれをやるとどうなるか。バイブコーダー、本当のバイブコーダーです。本当のバイブコーダーがものを作ると、ある段階までは持っていけます。
本当のバイブコーダーというのは、コードすら見ない人という定義ですか？
そうです。私の以前のバイブコーダーの定義は、生成されているコードを理解していない人でした。彼らは取り組んでいるプロダクトだけを見る、ということです。
私の定義もかなり変わりました。今では自分がやることの中にも、コードをまったく見ないものがあります。でも私はそこで何が起きているかは理解できます。ただ、頻繁にそれを見る必要がないだけです。だから「本当のバイブコーダー」と言い始めました。AIを使ってソフトウェアを作っているけれど、作られているものを本当に理解していない人たちがいると思うからです。
経験を持つ人々は、そうした本当のバイブコーダーに対して大きな優位性を持っています。本当のバイブコーダーは今、何かをプロトタイプ、おそらくMVPまで持っていくことはできます。ローンチもできるでしょう。
でも一度、数千人のユーザーを抱え、本物の本番環境、セキュリティ、商取引の問題などが入ってくると、彼らには続けていくスキルがありません。その時点で、実際にエンジニアリングを理解している誰かを呼ぶか、雇わなければなりません。
だから、大規模システムで働いた経験の年数は、今でも価値を持ちます。そして人々はそれをどう活用するかを学ぶ必要があります。それを活用する方法は、もはやすべてを自分でコーディングすることではありません。自分の監督下で、多数のエージェントに多くの作業をさせるよう、本当にオーケストレーションすることです。そこが、シニアエンジニアが、同じくエージェントを学んでいて、同じく非常に速くコードを書けるジュニアと差別化できる場所だと思います。
シニアエンジニアのアイデンティティ危機
今、多くのシニアエンジニアは板挟みになっていると思います。安全性への懸念から、AI生成コードに対するプルリクエストレビュー、CR、コードレビューをすべてやっています。一方で、C-suiteからは、すべてのプロダクトにAIを入れろ、社内のAIプロセスを革新しろという大きな圧力も受けています。
今、非常に大きなアイデンティティ危機が起きていると思います。自分の実際の役割は何なのか。そしてこの新しい世界で成功とは何なのか、ということです。
私がAIモデルの進化を見るとき、それは最初、監督なしでは何もできないインターンのようなものでした。何を望むか非常に具体的に伝える必要がありました。そして小さな仕事を持ち帰ってきて、それをおそらく使える、という程度でした。
その後、モデルは良くなり続け、今度はジュニアエンジニアのように感じられるようになりました。今ではタスク全体を割り当てることができ、多くの場合、正しい結果が得られます。これは良いことです。そしてこれは続いていきます。大規模システムとどう働くか、すべてのコードベースを混乱に変えない方法を学んでいくでしょう。そこに到達すると思います。
そして私たちの役割を見ると、以前のソフトウェア開発者はコードを書くことに多くの時間を使っていました。しかしコードがAIによって非常に速く書かれるようになると、私たちの時間は、何をコード化するかを定義することに使われ始めます。
これは今、多くの会社で起きています。人々は要求事項を定義し、何を作るのが正しいのかを見極めることに時間を使い始めています。そうしないと、非常に興味深いことが多くのチームで起きます。
AIと働く方法を学び始めた人々は、ああ、プロトタイプをこんなに速く立ち上げられるのか、なら20個プロトタイプを出そう、そしてPRをレビューして、これらのプロトタイプをマージするのを手伝って、と言い出します。チーム全体が混乱に変わります。時には、こうしたプロトタイプを出しているのがVPやディレクターやマネージャーだったりします。
ありますね。
チームに負担がかかり始めます。だから人々は、AIを本当に効率的に使う方法を見つける必要があります。そのプロセスにはしばらく時間がかかるでしょう。
私は数年前に現場を離れています。だから私が会社を去ったとき、AIはまだ許可すらされていませんでした。でもこうしたシニアエンジニア、とくにAmazonのシニアエンジニアには同情します。彼らには非常に大規模な障害がありました。どうやらクラウド上のあるエージェントが、特定の種類のプロンプトに対して非常に効率的な解決策として、いくつかのサービスを削除することを決めたらしいのです。
その結果、すべての変更はシニアエンジニアを通さなければならないという広範なポリシーができました。
そうですね。
だから彼らの一日は丸ごとコードレビューです。しかも、AIにコードレビューをさせればいいというわけではありません。彼ら自身がそこにいなければならないのです。
そのようなタイプのシニアエンジニアに、その問題から抜け出すためにどんな助言をしますか？いや、それは対処するしかない、ということですか？物事が変わるまで待つ以外に、もっと良い答えはありますか？
素晴らしい質問です。そして実際、今のところ完璧な答えを持っている人はいないと思います。少なくとも私が話してきた人たちは皆、まだこれを理解しようとしているところです。
ソーシャルメディアで人々が話していることを見ると非常に面白いです。多くの場合、それは非常に具体的なテクニックです。これを使うと計画がずっと良くなるスキルがあります、このMarkdownファイルがあります、Gary TanにはGStackがあります、というようなものです。そのリポジトリはGitHubで6万スターを獲得しています。Markdownファイルのセットにすぎません。
人々はそうしたことについて多くの時間を費やして話しています。それは面白いですし、投資して、どんな最適化ができるかを理解する価値はあります。でも、それが主要な会話であるべきではないと思います。
私たちは実際には、新しい働き方は何なのか、この新しい世界でどう運用するのかを見極めるために、もっと多くの時間を使う必要があります。
たとえばコードレビューについて話しましょう。誰もが、コードレビューが今や問題であり、ボトルネックであると認識しています。なぜなら、誰もがはるかに多くのコードを書いているからです。そこで人々はPRレビューを見て、なぜこんなに遅いのか、それを速くするプロダクトやツールを作ろう、と言い始めます。実際に人々はそれをしています。Cursorはコードレビュー問題を解決するためにGraphiteを買収しました。多くの会社がこれをやっています。
でも私たちは一歩引いて、PRレビューはまだ存在すべきなのか、と問うべきです。私たちは、もはや存在すべきではないものを最適化しているのでしょうか。
私がそう言う理由は、PRレビューは一人の人間がコードを書き、別の人間がそれをレビューし、チェックアンドバランスをかけ、ガードが整っていることを確認し、別の視点を提供する世界で行われていたからです。その世界では、PRレビューがそのための仕組みでした。
この新しい世界では、AIエージェントがコードを書いています。作者がチェックアンドバランスです。作者はすでにAIのコードを見て、それが良い状態にあることを確認してから提出しています。そこでさらに別の人間がもう一度見ることで、どれほどの価値が得られるのでしょうか。
だから私たちは実際に考え直す必要があります。この新しい世界で、私たちはどう運用するのか。まだPRレビュープロセスが必要なのか。それともコンプライアンスや規制などを変えて、PRレビューはもはや正しいものではない、と言うべきなのか。
実際には、最初の作者がAI生成コードを見るときに起きることをもっと重視する必要があるのではないか。どうすれば、その人がコードが良いと確認し、自信を持ってマージできるように助けられるのか。そこには探索すべき大きな空間がありますが、十分には起きていないと思います。人々はそれについてもっと話すべきです。
ただ、あなたの質問に戻ると、みんながAIスロップを出してきて、それが良いものかどうか確認する責任を負わされているシニアエンジニアに対して、私の助言は、その負担を手作業で背負わないことです。もしシニアエンジニアが、すべてのAIスロップのレビュワーとして自分を置くなら、その戦いには100％負けます。
ただし彼らにできることは、その苦痛の多くを自動化するのに役立つシステムを作ることです。シニアエンジニアがコードをレビューするとき、実際には何を気にしているのか。AIでは簡単に特定できなかった問題として、彼らは実際に何を見つけてきたのか。それをスキルに変えられるか。それを、今後それを代わりにやってくれるエージェントに変えられるか。そこにはやるべきことがたくさんあります。
それを大規模にどう行うかについて、非常に実証されたプレイブックがあるとは思いません。皆がこれを見極めているところです。でもある程度成功している人たちも見てきました。シニアの人々は、自分たちが見ている問題に対抗できるシステムを作ることに時間を使うべきだと思います。
まだ答えはない、ということですね。私は、コードのリファクタリング、アーキテクチャのリファクタリングをして、爆発半径を小さくすることが必要だと思います。一般的にはそれが正しい答えになるでしょう。
また、AIコードが生成されたプロンプトを提供することも非常に重要だと思います。そしてそのプロンプトの一部には、本番環境の問題が大量に発生しないことをどう確認するか、どう保証するかも含めるべきです。そしてそれをレビューの中にも含める、と。
では聞きます。コード生成と本番へのプッシュに関して、人間が常にループに入ることになると思いますか？
短く言えば、いいえです。今起きている変化は、ソフトウェア開発者の役割がより高い抽象レベルへ移っていることだと思います。
AIがジュニア開発者として動作しているとき、人間の開発者はシニア開発者の役割を果たします。AIがシニア開発者として動作するとき、人間の開発者はエンジニアリングマネージャーの役割を果たさなければなりません。そしてAIがエンジニアリングマネージャーの役割を果たし、チーム内で自律的にオーケストレーションできるようになると、人間のエンジニアの役割はディレクターへ移る必要があります。
それはどういう意味か。ディレクターが自分の組織を見るとき、開発者生産性を気にします。50人のエンジニアがいる会社のCTOは、組織内の開発者生産性を非常に気にします。どんなものが開発者たちを遅くしているのか。どうすれば彼らを速くできるのか。どうすれば障害を取り除き、ツールを改善できるのか。すべてを気にします。
同じことがエージェントにも起きなければなりません。人間のエンジニアはエージェントを見て、どうすれば彼らをもっと速く働かせられるか、そこで起きている非効率をどう特定できるかを問う必要があります。だから人間の役割は、現在の組織階層のより高いレベルへと移り続けると思います。
私たちはエンジニアリングマネージャー、ディレクター、VP、そして最終的にはCEOとして働き、組織の残りはエージェントになるでしょう。AI能力が進歩し続けるという前提を置くなら、それが起きることについての私の理論です。
その前提でエンジニアリングマネージャーが何をするかを見ると、彼らは常にコードをレビューするわけではありません。
ほとんどしません。
ほとんどしません。では、彼らはどうやってプロダクトが出荷可能だと分かるのでしょうか。彼らは質問します。テストについて何をしましたか。エンドツーエンドテストをしましたか。ドッグフーディングをしましたか。誰かが実際にプロダクトを使ってフィードバックをくれましたか。スケーラビリティテストをしましたか。負荷、プレッシャーテストなどはしましたか。そうした質問をします。
そうした質問は、人間がコードを見ることを必要としません。もしAIがICエンジニアとして動作し、私たち開発者がEMの役割へ移るなら、私たちはもうコードに触れなくなります。そして私たちはそれを受け入れてよいと思います。AIがより有能になるにつれて、最終的にはそこへ移っていくと思います。
ここで先ほど触れた、コントロールを失うという話につながります。AIの世界では、コントロールを失うことを学ぶことが実際に非常に重要なスキルだと思います。すべてをマイクロマネジメントし、本当にすべてをコントロールする必要がある人は、自分自身がボトルネックになっていることに気づくでしょう。
既存システムをAI時代にどう移行するのか
そこにどうやって到達するのかが分からないんです。何百万行ものコードがあり、非常に多くの人々、多くのユーザーにサービスを提供している本番システムがあります。文書化されたことのないエッジケースがあり、それはそこにだけ存在しています。メトリクス、モニター、アラーム、ギガバイト、テラバイト単位のログがそこにあります。
シニア開発者からエンジニアリングマネージャー、ディレクターへどう移るのか、その見通しが分かりません。
ゼロから一を完全にAIでやる場合には、道筋が見えるかもしれません。そしてそこから構築していくこともできるでしょう。でも既存のものを取り、それを内側から引き出すようなことについては、あまり見えていません。
それは即座には起きないと思いますし、大規模に一夜で起きるとも思いません。ただし、特にスタートアップのような会社で、そのように運用し始めるところは見え始めるでしょう。そしてそれが起こるためには、どんなシステムを整備する必要があるのかを示し始めるはずです。
一歩引いて見ましょう。AI以前の世界、純粋に人間だけの組織を見ても、私たちは依然として障害を起こしていました。システムを壊し、そうしたミスをしていました。Facebookも何度かダウンしました。全員が人間だったときです。AIはいませんでした。Amazonもそうです。AWSもそうです。
AIはおそらくそうした問題やシステムの弱点を悪化させ、増幅しているのかもしれません。でもAIが根本原因ではありません。本当の問題は、こうした障害や爆発半径を最小化できるように、システムをどう確立するかだと思います。
おそらく、変更はより制御されるようになるでしょう。たとえば、本番環境へ大規模にロールアウトする前に、フィーチャーゲートやA/Bテストの観点でコントロールされるようになるはずです。そうしたシステムは、爆発半径を制御するためにより活用され始めると思います。
Bullish, Bearish or BS
では、Bullish, Bearish or BSというセグメントに移りましょう。いくつかのトピックを挙げるので、それについて強気か、弱気か、それともBSだと思うかを教えてください。
いいですね。
Facebookが有用なフロンティアモデルをリリースすること。
強気です。
強気なんですね。
強気です。彼らは多く投資しています。良い人材もいました。非常に才能ある研究者を大量に採用しましたし、必要な投資もありました。これまでの実績はそれほど有望ではありませんでした。彼らはこれにしばらく投資してきました。
でも適切な人材がいて、適切な投資があり、必要なものがすべて揃っている。材料はすべてあります。だから何かは起きるだろうとかなり強気です。そして、もしオープンソース、オープンウェイトモデルを作るという同じ哲学を維持するなら、それはエコシステムにとって非常に有益なものになると思います。
では、Open Clawについては強気、弱気、それともBSですか？
Open Clawは強気です。強気です。そして、BSだとはまったく思いません。これは、エージェントハーネスのセットアップの非常に興味深い組み合わせだと思います。それによって、エージェントが自分たちに何をできるかについて、主流の採用と認識が可能になりました。それ自体が非常に価値のあることでした。
ChatGPTと同じです。ChatGPT以前にも大規模言語モデルはすでに存在していました。Googleが最初に発明しました。でも誰も有用なアプリケーションを作りませんでした。だから主流派はそれについてあまり考えていませんでした。このAI進化を始めることはありませんでした。
ChatGPTには、主流の人々がAIの良さを認識できるほど十分に良くなる瞬間があったと思います。そしてOpen Clawも同じことをしました。だからその意味で有用だと思います。
それがどれほど防御可能か。Claude Codeのような他の誰かが、彼らのやっていることをすべて再現し、より多くの採用やマインドシェアを得るのか。それは分かりません。それはそれ自体として進化し続けるダイナミクスだと思います。ただ、業界に対してすでに成し遂げたことは非常に大きいです。
本当にそうですね。そしてオープンソースであることが好きです。私は自分のOpen Clawを常に自動更新させていますが、同時にリリースノートを要約させて、何が変わったのか正確に分かるようにしています。そのプロジェクトの変化速度は本当に驚異的です。私も強気です。ただ、その意見をあまり知られないようにしています。みんながそれを少しけなす感じがあるからです。
ローカルLLMについてはどう思いますか？
私はおそらく、今ローカルLLMに取り組んでいる平均的な人よりは弱気です。ローカルLLMに非常に強気な、いじるのが好きな人たちのコミュニティがあります。彼らはそれを最大限活用しようとしています。それは良いことだと思います。そして、ローカルで動かせて人々のために何かをできるモデルについて、もっと多くの探索があるべきだとも思います。
ここでの私の理論は、ローカルハードウェアはデータセンターができることには決して匹敵しないというものです。だから常にギャップは存在します。
起こりそうなのは、ローカルハードウェアが多くのことに対して十分に良い状態に到達し、私たちはそれらを無料で動かすようになるということです。それがローカルを活用する方法になります。それ自体は価値があります。でも、それが新しい産業の礎になるとは思いません。知能には非常に多くのリソース、非常に多くの計算が必要だからです。それはインフラによって行われなければなりません。
電力をどう得るか、水をどう得るか、インターネットをどう得るかと同じです。すべてを自宅で発明するわけではありません。それもできます。発電機を作ることもできます。でもそれはそれほど効率的ではなく、主流にはなりません。多くの人にとっては楽しいでしょう。ただ、ローカルがフロンティアとの差を完全に埋めるとは見えません。
オフグリッドになりたがる人たちのようなものですね。ソーラーパネルとバッテリーを設置して、素晴らしい、あなたは解決策の一部で、貢献している。でも最終的には周縁的なものになります。電力網につなぐ方が最も費用対効果が高いと思います。
強気、弱気、BS。AI PMは今テックで最もホットな役割だ。
なぜですか？なぜそうなるのですか？それに対する議論はあるんですか？
その議論をまとめると、要するにコードが解決された今、何を意味するにせよ、かなり技術的なプロダクトマネージャーが自分の審美眼を持って入ってきて、これが作られるべきものだと言えるようになった、というものです。そして今では、開発者をループに入れる必要がまったくありません。彼らは十分に技術的で、何らかの閾値を越え、ソフトウェアがどう作られるかをある程度理解しています。だからこれまで以上に強力になっている。
あなたの階層の考え方、インターンからシニア開発者、エンジニアリングマネージャーへという流れを信じるなら、そこに到達したとき、PMはおそらくこう言えるわけです。自分にはAI開発チームがある、と。そして自分の審美眼こそがプロダクトを成功させるものになる、と。
なるほど。思考プロセスは非常に合理的だと思います。ただ、その議論にはいくつか欠陥があります。
すべてのAI PMに優れた審美眼があるとは思いません。実際に成功するものへ変換できる優れた審美眼を持つPMは、かなり稀です。多くの人は、自分には優れた審美眼がある、あるいは美しいものをモックアップできると主張します。でも本当に有用であり、かつ優れた審美眼を持つものを作ることはできません。それには非常に良いバランスが必要で、それ自体が非常に複雑なプロセスです。
そのプロセスには、必ずしもPMは必要ありません。だから私は、その議論に対して最初の反応としてBSと言いました。誰もがその人になれると思います。誰もが自分の作るものに審美眼を持ち込めますし、PMがやるような形でAIを本当に活用できます。エンジニアは多くの価値を得られます。エンジニアはこれまで以上に強力になっています。デザイナーもこれまで以上に強力になっています。
何かを作る情熱を持つ誰もが、それを助けるスーパーパワーを今手にしています。そして彼らがするべきことは、解くべき正しい問題は何かに集中することです。どうすれば問題の解決に判断力と審美眼を持ち込めるか。そうすれば実際に注目を集め、本物の問題を解決できます。それはPMという職能に結びついたものではありません。
だから、PMはこれまで以上に強力になっていますが、彼らだけではありません。
Marc Andreessenがメキシカンスタンドオフについて話していましたよね。デザイナー、PM、開発者が、なぜ他のグループが存在するのか、あるいは他のグループの存在はもう長くないのではないかと互いに問い合っている、と。
組織が進化する中で、デザインリーダー、PMリーダー、開発リーダーが協調して働く状況が見えますか？それとも、より一人の人間がすべてをまとめて、自分で作るようになると見ていますか？
おそらく後者に近いと思います。誰もが他の職能からスキルを獲得し始め、その職能についてより上手になり、より自律的に動けるようになると思います。
特にAIによって、AIはある意味で底上げをします。Go-to-marketについて何も知らない人でも、AIと話すだけで、プロダクトのための良い戦略を作るかなり合理的なレベルに到達できます。プロダクト、ビジネス、デザインについて何も知らない人でも、AIからある程度の能力を得られます。そして他の職能から学ぶことができます。
私の前提では、人材スタックは崩壊し、誰ものスキルはより均質になっていくでしょう。人々は専門特化が少なくなり、よりジェネラリストで、より多才になります。そうした人々は他の人に対して優位性を持ち、それがさらに多くの人をそうさせるインセンティブになるでしょう。
大きな組織の中で、開発者やこうしたスーパー・ジェネラリストたちが一緒に働いてエージェントをオーケストレーションする世界を考えていますか？それとも、互いに排他的な所有範囲を切り出し、その範囲内で責任を持つが、あまり協力し合わない世界を考えていますか？
人間同士の協力は依然として残ると思います。一人ができることと、多くの他の人間と協力してできることを比べると、本当に多くの賢い人々が同じ方向に向かって働いている場合、後者が常に勝つと思います。だから人間の協力はなくならないでしょう。
ただし、どのタイミングでその協力が必要なのか、どこが適切なトレードオフなのかについてのハードルは上がります。
今、多くのスタートアップにおける黄金の道は、一人で何かを作り、ある程度妥当なトラクションを得て、資金を調達してチームを成長させるというものだと思います。より多くの人々が一緒に働くようにするためです。
でも今は、一人でそれをせずにもっと遠くまで行けます。一人で非常に多くのことができます。資金調達をする必要もありません。必要なのはサブスクリプションの200ドルだけです。それでかなり遠くまで行けます。だからハードルは上がりますが、人間の協力の価値が消えることはありません。
Big Techを離れてソロビルダーへ
次はあなたにとって何ですか？
私はBig Techを離れました。キャリア全体を通して大企業にいました。そして次のステップを見たとき、自分が本当にまったく新しいことを学べる場所はどこかを考えると、非常に違う経験に飛び込まなければならないと思いました。
今はAIがあるので、非常に違う経験を得るにはちょうど良い瞬間のように感じました。今、私はソロビルダーです。時間をかけて蓄積してきたたくさんのアイデアがあり、それらを探求したいと思っています。
また、自分の旅や学んだことについて、もっとコンテンツを作り、他の人と共有し、コミュニティと関わっていきたいとも思っています。それは私にとって非常に楽しい役割になると思いますし、多くを学べるでしょう。そして願わくば、私が作るもののいくつかが有用なものになるといいなと思っています。
素晴らしいですね。あなたのYouTubeチャンネルやTwitterのリンクはすべて概要欄に入れておきます。今日は会話してくれて本当にありがとうございました。素晴らしかったです。
こちらこそ、ありがとうございました。
コメント