元記事: https://www.youtube.com/watch?v=AmdLVWMdjOk
インタビュイー: Boris Chney (元Meta IC8、現Anthropic Claude Code開発者)
日時: 2026-02-07
翻訳: 完全日本語翻訳（1時間24分）
Boris Chneyは、Metaでプリンシパルエンジニア（IC8）として活躍し、FacebookグループやInstagramの基盤を築いた人物だ。現在はAnthropicでClaude Codeの開発に携わり、「エンジニア一人当たりの生産性70%向上」という驚異的な成果を実現している。
このインタビューでは、彼のキャリアを形作った重要な決断、Metaでの3段階の昇進プロセス（IC4→IC6→IC7→IC8）、何百人ものエンジニアをスコーピングした経験、そしてAI時代のソフトウェア開発の未来について深く掘り下げている。
特に注目すべきは、彼が実践してきた「潜在的需要」に基づくプロダクト開発の原則、組織横断コラボレーションの難しさとその解決策、そして「タイトルなし文化」がもたらす信頼ベースの働き方だ。Meta時代の具体的なエピソード——技術設計コンペティション、Cometプロジェクトへの先取り参加、パブリックグループの実装——は、技術リーダーシップの実践例として示唆に富む。
概念
Borisが「プロダクトにおいて最も重要な原則」と断言する潜在的需要とは、ユーザーが既に持っている意図を発見し、それをより簡単に実現できるようにすることだ。人々に新しい行動をさせようとするのではなく、彼らが既にやろうとしていること（時には製品の本来の用途を「悪用」してまで）を観察し、それに基づいて製品を作る。
実例：Facebook Marketplace
Facebookグループの投稿の40%が物の売買だった。グループはコマースのために設計されていなかったが、人々はそれをそのために使っていた。この観察から「売買グループ」が生まれ、最終的にMarketplaceという独立した製品へと進化した。ユーザーが持っていた意図の自然な延長だったからこそ成功した。
実例：Facebook Dating
プロフィールビューの約60%が「友達ではない異性」だった。つまり、人々は既にFacebookを使って「こっそり」お互いを見ていた。この潜在的需要を基に、Datingという機能が正式に提供された。
プロダクト原則
「人々にまだやっていないことをやらせることは決してできない。できることは、彼らが持っている意図を見つけて、その意図をより良く活用できるように導くこと。その意図をより簡単に実現できるようにすること。」
この原則は、AIプロダクトにも適用できる。ユーザーが既にやろうとしていること（LLMに無理やり指示を出す、プロンプトをハックする）を観察し、それを製品の一部として統合することが成功の鍵となる。
MessengerとFacebookの悪夢
BorisはMessengerとFacebookグループを統合するプロジェクトに関わったが、これは「困難なんて控えめな表現、悪夢だった」と振り返る。
文化的価値観の対立
この価値観の違いは単なる表面的なものではなく、組織設計、目標設定、評価システムの深部まで及んでいた：
解決策
異なる価値観を持つ組織を成功させるには：
Borisは振り返って「もしZuckのところに行って『Messengerを組織的にFacebook側に移動させるべき』と言っていたら」と語る。実際、その後Messengerは何度も組織の内外を行き来した。
教訓
文化的価値観の違いは、会話だけでは解決しない。組織構造、目標設定、評価システムを根本から見直す必要がある。
背景：「新しい組織としてのコミュニティ」プロジェクト
ZuckがFacebookアプリを「すべてコミュニティについて」にしたいと考え、Borisがピッチしたプロジェクトに大量の人員（150人→600人規模の組織）が投入された。問題は、これらの人々が何をすべきかを決めなければならなかったことだ。
スコーピングの実践
ある週には：
これを何度も繰り返し、「完全にクレイジーじゃない」という確信を持つまで、エンジニアの数をプロジェクトにおおよそ合わせ、基本的な技術的スコーピングを行った。
技術設計コンペティション：Facebookグループとページのデータモデル統合
最も印象的なエピソードは、データモデルの統合で行き詰まった時の解決策だ：
問題: Facebookグループとページをデータモデルレベルでマージする必要があったが、非常に厄介な移行で、何年もかかり何百人ものエンジニアが必要だった。シニアエンジニアが決断に苦しんでいた。
解決法:
結果:
重要な学び:
スコーピングのアドバイス
「最大の敵は、人々が時間をかけすぎて細かいところに入り込むこと。細部は無限にある。ハイレベルから始める。ほとんどの技術的スコーピングは30分以内でできる。」
サイドクエストを持つ人を雇う理由
Borisは「クールな週末プロジェクト、サイドプロジェクト、コンブチャ作りに夢中な人でもいい。メインの仕事以外のことに興味を持っている全面的な人間と働きたい」と語る。
Undux: Redux の複雑さへの反抗
Reactの状態管理フレームワークUnduxは、Reduxが「理解できなかった」ことから生まれた。「自分を平均的なエンジニアだと思っている。リデューサーのような概念、複雑なフローが理解できなかった。だからシンプルなものを作った。」
Facebook入社後、内部グループで人々が同じ質問をしているのを見て、これが共有されている問題だと確信。20〜40回のテックトークをMetaキャンパスで自転車で回って実施し、Facebookで最も人気のある状態管理フレームワークになった。
TypeScript: 怪我から生まれた関数型プログラミングへの道
10年前、オートバイ事故で両腕を骨折。1ヶ月コーディングできず、その後も手が痛くてJavaScriptが書けなかった。文字通りキーストロークが少ない言語を学ぶ必要があった。
CoffeeScript → Haskell → Scala → TypeScript という旅を経て、「型で考える」エンジニアになった。「コードで最も重要なのは型シグネチャ。これはコード自体よりも重要。」
必読書: 「Functional Programming in Scala」 「エンジニアとして最も影響を受けた一冊。コーディング方法を完全に変える。」
驚異的な数字
「Anthropicの規模が3倍になったにもかかわらず、エンジニア一人当たりの生産性は約70%も向上した。Claude Codeのおかげだ。」
AI時代の見積もりの変化
過去（2016年頃）：
今日（2026年）：
6ヶ月後（2026年後半）：
「みんながただ複数のClaudeを並行して走らせて、数時間放置。PRを持って戻ってきて、Puppeteerか何かでUIを見て調整する。それがほとんど全部。」
重要な原則: 未来のモデルのために作れ
「今日のモデルのために作るな。6ヶ月後のモデルのために作れ。」
モデルの進化があまりにも速いため、3ヶ月後、6ヶ月後には答えが全く違うものになる。この前提で設計することが重要。
Member of Technical Staff という唯一のタイトル
Anthropicでは、エンジニアもPMもデザイナーも、全員が「Member of Technical Staff」というタイトルを持つ。Metaでも似た文化があったが、Anthropicはさらに進んでいる。
メリット
「自分のレーンの外で働く。個人的に期待されていることに関係なく、ただやるべきことをやる。こういう文化がそれを可能にする。」
デメリット
「大企業では、誰かに連絡を取る時、タイトルがディレクターだと『どれくらい真剣に受け止めるべきか』のショートカットになる。」
本質的な価値
「信頼を得なければならない。どの会社にいても、常に信頼を獲得しなければならない。過去に素晴らしいエンジニアだったとしても、新しい会社、新しい環境で権威に値するわけではない。」
「どのレベルにいても、常に少しのインポスター症候群を感じるべき。感じないなら、十分に自分を押していない。」
戦略的に低いレベルで入る
Borisは多くの経験があったにもかかわらず、Metaにミッドレベル（IC4相当）で入社した。「振り返ると、レベルが低い状態で入れてラッキーだった。」
理由
「単に期待値が低い。レベルが低い状態で入ると、探索する余地ができて、クールなものを作るためだけにクールなものを作ることができる。」
大企業では各レベルに特定の期待（プロジェクトインパクト、人へのインパクト）があり、それをチェックするには時間がかかる。
効果
ミッドレベルで入って期待を大きく超えると：
アドバイス
「多くのエンジニアは転職時にレベル+1を強くプッシュするが、実際にはデメリットが多い。」
「人々にまだやっていないことをやらせることは決してできない。彼らが持っている意図を見つけて、その意図をより良く活用できるように導くこと。」
背景: Facebook Marketplace（投稿の40%が売買）とFacebook Dating（プロフィールビューの60%が非友達異性）の成功事例から導き出された原則。ユーザーが製品を「悪用」している様子を観察し、データで裏付け、それを正式な機能として提供する。
現代への示唆: AIプロダクトでも同様。ユーザーがプロンプトをハックしたり、回避策を使っている行動を観察し、それを製品の一部として統合することが成功の鍵。潜在的需要は「新しい行動を作り出す」のではなく「既存の意図を発見し、実現を容易にする」ことだ。
「2チームに分けて3時間でアーキテクチャを考えさせた。結果は80%同じだった。何を実行すべきか明白になり、20%の相違点でリスクの所在が明確になった。」
背景: Facebookグループとページのデータモデル統合という、何百人ものエンジニアと何年もかかる厄介な移行プロジェクト。シニアエンジニアが決断に苦しんでいた時、Borisは全テックリードを集めて「設計ゲーム」を実施した。開始時は「どうやるか全く分からなかった」が、終了時には明確な道筋ができていた。
実践的な教訓:
「12人のエンジニアで2年かかったFacebookグループの移行は、今なら5人のエンジニアで6ヶ月。6ヶ月後には1人かもしれない。」
背景: 2016年頃のComet（facebook.comの書き直し）プロジェクトと、2026年のClaude Code環境の比較。Anthropicでは規模が3倍になったにもかかわらず、エンジニア一人当たりの生産性が70%向上した。
技術的な変化: 「複数のClaudeを並行して走らせ、数時間放置。PRを持って戻ってきて、Puppeteerでチェック。」コーディング自体はAIが担当し、人間はアーキテクチャ判断とレビューに集中。
重要な前提: モデルの進化があまりにも速いため、「今日のモデルのために作るな。6ヶ月後のモデルのために作れ。」見積もりや計画は3〜6ヶ月で陳腐化する前提で考える必要がある。
「常に信頼を再獲得しなければならない。過去に素晴らしいエンジニアだったとしても、新しい環境で影響力に値するとは限らない。」
背景: MetaもAnthropicも「タイトルなし文化」を採用。Metaでは最もシニアなエンジニアでも「Software Engineer」、Anthropicでは全員が「Member of Technical Staff」（エンジニア、PM、デザイナー関係なく）。
哲学: タイトルは「どう接するべきか」のショートカットを提供するが、それは本質的な価値ではない。新しい会社では、過去の実績に関わらず信頼を再構築しなければならない。これは健全なことであり、真のメリトクラシーを実現する。
デメリットの存在: 大企業で誰かに連絡する時、タイトルがないと「どれくらい真剣に受け止めるべきか」が分かりにくい。しかし「メリットがデメリットを上回る」。
実践的な意味: 「自分のレーンの外で働く」文化を可能にする。個人的な肩書きや期待に縛られず、「ただやるべきことをやる」。プロダクトマネージャーがコードを書き、エンジニアがユーザーリサーチを行う文化の基盤。
「エンジニアとして最も影響を受けた一冊。今日Scalaを使うことはないが、コーディング問題について考える方法を完全に変えた。コードで最も重要なのは型シグネチャ。これはコード自体よりも重要。」
背景: オートバイ事故で両腕骨折後、キーストローク数の少ない言語（CoffeeScript、Haskell）を学ぶ必要に迫られた。同僚Rickに勧められて「Functional Programming in Scala」を読み、関数型プログラミングの世界に入った。
変容: 「型で考える」エンジニアになった。型シグネチャを正しく設計することが、非常にクリーンなコードにつながる。FacebookのFlow/Hack、InstagramのPython、AnthropicのTypeScript/Pythonすべてで活きる考え方。
より深い教訓:
現代への示唆: TypeScriptの条件付き型、リテラル型、マップ型は「最も厄介なHaskellerでさえ感銘を受ける」レベルの言語機能。関数型プログラミングのアイデアは主流言語に浸透している。
「VP レビューでは常に3つのオプションを提示する。80%の時間で、彼らは真ん中のオプションを選ぶだけ。」
背景: 仕事から遠い意思決定者は、「正しいオプションを見つけるデューデリジェンスをやったこと」を知りたいが、同時に「何らかの形で決定に貢献したい」とも思っている。真ん中のオプションはそれを実現する簡単な方法。
重要な注意: Boris自身が「これは冗談。すべてのリーダーがこうではない」と強調。多くのリーダーは自分で仕事をし、チームを信頼する。しかし一部の非技術的リーダーには当てはまる傾向がある。
より深い洞察: リーダーシップのレベルと意思決定プロセスの関係。シニアマネジメントに報告することの「下流の効果」は会社の文化次第。Metaではスコープ発見が重要だったが、Anthropicでは報告レベルは関係ない（元CTOがラインマネージャーのケースも）。
「ユーザーリサーチャーがいなかった。だから昼食時にカフェテリアに行って、従業員に新機能を見せた。みんなが同じことを始めて、従業員を困らせるようになった。」
背景: 初期Facebookの文化で、エンジニアがコーディング以外のこと（UXR、デザイン、プロダクト）を全てやった。Borisはチームにこの観察的ユーザーリサーチの方法を教え、すぐにみんなが実践し始めた。
ジェネラリストの価値: 「コーディングするエンジニアでありながら、プロダクトワークもできる。デザインもできる。プロダクトセンスがある。ユーザーと話しに行きたいと思う。こういうエンジニアと働くのが大好き。」
現代のAnthropicでも継承: 「すべての職種でこのように採用している。プロダクトマネージャーはコードを書き、データサイエンティストもコードを書き、ユーザーリサーチャーも少しコードを書く。」
より広い文脈: 「大企業では特定のレーンに押し込められる感じがするが、それは単に公式的なもの。実際にやっていることは製品を作るかインフラを作るかで、コードを書く以外にエンドツーエンドで行うにはもっと多くのことが必要。」
「エンジニアとして、問題に直面した時、時々それは自分だけ。でも多くの場合、他の人も同じ。この問題が他の人と共有されているかもしれない時の勘を養うことが重要。」
Unduxの誕生: Reduxが理解できなかった→シンプルなものを作った→非営利団体が使い始めた→Facebook入社後、内部グループで同じ質問を見つけた→20〜40回のテックトークを実施→Facebook最人気の状態管理フレームワークに。
重要な勘: 「自分が困っているなら、他の人も困っている」可能性。サポート投稿やチームの苦労から確証を得る。この勘を養うことが、サイドクエストを実際のインパクトに変える鍵。
レバレッジの原則: 「もしあなたが問題を抱えているなら、おそらく他の人も同じ問題を抱えている。自分のために構築することが、他の人々にも価値があるの良い指標。」（Y Combinator の教え）
具体的なアプローチ:
「インポスター症候群を克服するアドバイス？考えすぎないこと。誰も本当に何をやっているか分かっていない。どのレベルでも。」
背景: IC7昇進プロジェクトで、同じレベルのシニアエンジニア（Henry Long、Joe Chamなど）を指揮しなければならず、インポスター症候群を感じた。「レベルは隠されているとはいえ、頭の中では同じレベルだと知っていた。」
現在の見方: 「レベルは全く重要ではない。非常にジュニアな人々がはるかに高く飛び、素晴らしい結果を出すことがある。非常にシニアな人々がひどい結果を出すこともある。」
健全なインポスター症候群: 「どのレベルにいても、常に少しのインポスター症候群を感じるべき。感じないなら、十分に自分を押していない。」単一の「気づきの瞬間」はなく、時間とともに消えていくもの。
実践的な意味: レベルやタイトルではなく、実際の成果と信頼で評価される文化の重要性。これがタイトルなし文化の哲学的基盤。
「機能を追加するだけだと、一部のユーザーにはクールだが、その機能を使わないほとんどのユーザーにとっては悪い。使用バーを満たさない機能は削除する。一部のユーザーは怒るが、平均してみんなにとって本当に素晴らしい。」
Instagram文化の特徴: 「素晴らしい製品を作ること、人々が使わないものを『アンシップ』すること、データの観点だけでなく人間の観点と経験の観点から物事を考えることに大きな重点。」
限られた不動産の原則: 「画面は限られたサイズ。それが限られた不動産。すべての異なる機能が競い合っている限られたリソース。機能を追加することで、人が使えたかもしれない別の機能から機会を奪っている。」
Facebook vs Instagram: FacebookとInstagramの間で「エンジニアリング、製品、デザインの文化が完全に異なっている」。Facebookはスピード重視、Instagramは職人技と製品品質重視。この違いがアンシッピング文化を生んだ。
Note: このアーカイブは、1時間24分のインタビューの主要トピックと洞察を詳細に解説した「読み物」として構成されています。各セクションは独立して読めるよう、背景情報と実践的な教訓を含めています。元のインタビュー全文は上記YouTubeリンクでご覧ください。