PalantirもSpotifyも「真似するな」と言っている ── SaaS企業がフレームワークに飛びつく構造

関連記事：

第1章：「あの会社がやっている」の引力

SaaSに関わっていると、定期的にこういう場面に出くわす。

経営会議やSlackで誰かが言う。「PalantirがFDEで伸びている」「SlackはPLGだから営業なしでスケールした」「Spotifyの組織モデルがすごいらしい」。そして「うちもやろう」。

気持ちはわかる。成功企業のやり方には説得力がある。名前がついていて、構造が整理されていて、成果が数字で示されている。社内を通しやすい。「なぜそれをやるのか」の説明コストが低い。「Palantirがやっているから」で半分くらい通ってしまう。

そして厄介なのは、大抵の場合、誰もそこに疑問を持たないことだ。提案された側は言葉を知らないから、「おおすごい」「へえ、そんなことまで知ってるんですね」で終わる。条件が違うのではないか、と立ち止まる人がいない。全員が善意で、全員がなんとなく正しそうだと思って、検証なしに走り始める。自分も含めて、これは本当によくある光景だと思う。

成功企業のフレームワークをそのまま持ち込んでうまくいったケースは、正直あまり聞かない。課題意識は合っている。解法の選択がずれている。そういうパターンが多いのではないかと思う。

なぜそうなるのかを整理してみたい。

第2章：カーゴカルトとは何か ── 形だけ揃えても飛行機は来ない

第二次世界大戦中、南太平洋の島々に米軍が飛行場を建設し、大量の物資を空輸した。戦後、米軍が去った後、島の住民たちは竹で管制塔を作り、木の棒をアンテナに見立て、滑走路を整備した。形を再現すれば、再び空から物資が降ってくると考えた。

物理学者リチャード・ファインマンはこれを「カーゴカルト・サイエンス」と呼んだ。形式は正しいが、それが機能するための本質的な条件が抜け落ちている。

SaaSの世界でも似たことが起きている。成功企業の「何をやったか」は詳しく語られる。だが「なぜそれが機能したか」──顧客単価、組織規模、プロダクトの成熟度、人材の質──は、あまり検討されないまま導入が進む。

以下、4つの具体例で見ていく。

第3章：FDE（Forward Deployed Engineer）── Palantirの真似をしてはいけない理由

課題意識は正しい

FDE（Forward Deployed Engineer）は、エンジニアを顧客先に常駐させ、提案書ではなく動くプロトタイプで課題を解くアプローチだ。Palantirが確立し、最近ではOpenAIやRampも採用している。

「SaaSは入れて終わりじゃない、入れてからが本番」──これはSaaSに携わっていれば誰でも感じることだと思う。導入後に使いこなせず解約される。オンボーディングが足りない。機能はあるのに活用されない。FDEはこの課題に対する一つの解法であり、課題の捉え方そのものは正しい。

問題は、この解法が成立する条件にある。

Palantirの数字

Palantirのトップ20顧客の平均年間収益は約8,300万ドル（2025年Q3時点のTTMベース、前年同期比38%増）。なお、2025年通期ではこの数字は9,400万ドル（前年比45%増）にまで拡大している。新規顧客でも数ヶ月で7桁ドル（数億円）のACV契約に至るケースが報告されている。同四半期のTCV（総契約額）は27.6億ドルで過去最高、前年同期比151%増。

FDE1人の年間コストは、給与・福利厚生・渡航費込みで2,000〜3,000万円程度。顧客単価が数億〜数十億円なら、余裕でペイする。

では、日本のSaaS企業でARPAが年間数百万〜数千万円の場合はどうか。FDE1人貼り付けた時点で、その顧客からの粗利はほぼ消える。パイロットで1〜2社ならなんとかなっても、3社目からは同じ工数がかかるのでスケールしない。

顧客単価の桁が違えば、同じ手法でも経済性がまったく違う。

人材とプラットフォームの前提

Palantirの元FDE Barry McCardel氏によると、FDEにはGoogleやMetaに行けるレベルのエンジニアを採用していた。Glassdoorのデータでは、PalantirのFDEのベースサラリーは12万〜20万ドル（25th〜75thパーセンタイル）で、ストックオプションも手厚い。FDEは「客先常駐の実装担当」ではなく、顧客環境で新しい技術やソリューションを発明できる人材だ。

さらに、PalantirにはFoundry/AIPという拡張性を前提に設計されたプラットフォームがある。FDEが現場で作ったものをコアプロダクトに還元する仕組みが組み込まれている。ただし元社員ですら「この還元を実現するのは、ほとんどの会社にとって極めて難しい」と認めている。

当事者が「やるな」と言っている

ここが一番重要かもしれない。Palantirの元FDE自身が、FDEモデルの安易な導入を明確に警告している。

約5年間FDE（社内呼称はDeployment Strategist/Echo）として勤務したBarry McCardel氏は、自身のブログで「FDEを導入すべきか」と聞かれたら、ほとんどの場合答えは「absolutely f%#&ing not!（絶対にやるな）」だと書いている。タイトルだけ真似しても、得られるのは「sparkling Sales Engineering（きらびやかなセールスエンジニアリング）」──受託仕事に格好いい名前をつけただけのもの──だ、と。

さらに、FDEモデルの本質はベンチャー投資に似ていて、「ほとんどの案件は失敗する。だが成功した案件が大きなリターンを生むから成り立つ」構造だと説明している。つまり、F500規模の企業や大規模な政府機関を相手に極めて高い単価を取れることが前提であり、そうでなければモデル自体が経済的に成り立たない。

成功企業の中の人が「真似するな」と言っているのに、外側からは「あの会社がやっているから」で導入が進む。この構造自体が、カーゴカルトの典型だと思う。

プロダクトで解ける課題をなぜ人で埋めるのか

FDEが取り組もうとしている「導入後の活用不足」は、多くの場合、プロダクト側の改善で対処できる。連携API、業務テンプレート、セルフオンボーディングの導線、カスタマーサクセスの仕組み。これらをプロダクトに組み込めば全顧客にスケールする。

もちろん、プロダクト改善にはリードタイムがかかる。その間を人で埋めること自体は、短期的には合理的な判断だ。ただ、それが常態化すると話が変わる。機能が足りないから人で埋める、が繰り返されると、プロダクト改善の優先度がいつまでも上がらず、SaaSが受託に戻っていく。人で埋めるのは応急処置であって、恒久策にしてはいけない。

第4章：PLG（Product-Led Growth）── Slackになれる会社はそんなに多くない

PLGが魅力的に見える理由

PLG（Product-Led Growth）はSlack、Notion、Dropboxの成功で一気に広まった。プロダクトそのものが営業・マーケ・オンボーディングの役割を果たし、ユーザーが勝手にサインアップして、勝手に広めてくれる。営業コストを抑えながらスケールできる。CAC（顧客獲得コスト）が劇的に下がる。

Slackの数字を見ると、PLGが機能したときの威力がわかる。2014年2月のローンチ時に約1.5万DAUだったのが、1年で50万、1年半で110万、5年で1,000万DAUを超えた。フリーミアムからの有料転換率は、高利用組織で約30%とされている（Slack経営陣の公開発言およびS-1期のデータに基づく推計）。B2B SaaSの平均的なフリーミアム転換率が2〜5%であることを考えると、突出した数字だ。Slackはこれを、ほぼ営業なしで達成している。

聞こえはいい。だが、PLGが成立するプロダクトの条件はかなり厳しい。

3つの条件

プロダクトだけで価値が伝わる。 Slackはチームの数人が使い始めた瞬間にコミュニケーションの改善を体感できる。Notionは1人で使い始めてもすぐに便利さがわかる。営業の説明もデモもいらない。「触ればわかる」。

セルフオンボーディングできる。 アカウントを作って数分で最初の価値体験に到達できる。設定が複雑だったり、既存システムとの連携が前提だったりすると、ここで詰まる。

バイラル性がある。 1人が使い始めると周囲も使い始める構造がある。Slackは「チームで使わないと意味がない」。Figmaは「デザイナーが使うとレビュアーも使わざるを得ない」。プロダクトの構造自体が拡散を生む。

toBドメイン特化SaaSとの相性

この3条件を、toBのドメイン特化SaaSに当てはめると、だいたい無理が出る。

顧客はデモを見たい。営業に業務課題を相談したい。導入にはIT部門の承認がいる。セルフサインアップしても設定が複雑で、使い始める前に離脱する。仮にサインアップしても「で、何をすればいいの？」となる。プロダクトに触っただけでは価値が伝わらない領域で、PLGは構造的に成立しない。

Atlassianの教訓 ── PLGの象徴が営業チームを作った日

PLGの成功例として最も頻繁に引用されるのがAtlassianだ。「営業チームなしで1億ドルに到達した」──この話はSaaSの世界で伝説になっている。2016年にはBloomberg Businessweekが「この50億ドル企業には営業スタッフがいない」と報じた。

だが、その記事が出た頃、Atlassian自身はすでにその方針を転換し始めていた。2014年、平均販売価格が4,000ドルから48,000ドルに上がるData Center版の導入をきっかけに、初めてコミッション制の営業担当者を置いた。元CROのCameron Deatsch氏はこう語っている。「ASPが上がって初めて、顧客に電話をかける価値が出てきた」。

現在Atlassianにはエンタープライズ営業チームが確実に存在する（時価総額は市場環境により大きく変動しており、2025年末時点で約430億ドルだったが、2026年2月下旬時点では約200億ドルを割り込む水準まで下落している）。PLGの旗手ですら、年間契約額が一定の規模を超えると営業なしでは成長が止まることを認めたわけだ。SaaStrの分析によれば、PLGで始まった企業の多くが成長に伴い営業チームを追加している。Calendlyは約5,000万ドルARR、Canvaはほぼ10億ドルARRの時点で営業を追加した。

PLGは万能ではない。PLGの象徴と呼ばれた企業群ですら、規模の拡大に伴って営業を追加せざるを得なかった。「Slackは営業なしで成功した」という神話は、Slackの歴史の前半だけを切り取ったものだ。IPO時点では、Slackの成長の大部分はエンタープライズ契約から来ていた。

SLGからPLGへの転換はさらに難しい

ここまではPLGで始まった企業の話だ。では、すでにSLG（Sales-Led Growth）で事業を構築した企業がPLGに転換するのはどうか。

Harvard Business Schoolの講師であり、Stage 2 Capitalの共同創業者でもあるMark Roberge氏は、PLGをゼロから設計した企業がエンタープライズ営業を後から追加した成功例は多いが、ARR1,000万ドル以上に達したSLG企業がPLGに転換して成功した例はほとんど見つからないとしている。理由は2つ。既存の収益を食う恐れからフリー版に十分な価値を入れられないこと。そしてSLG最適化された組織文化がPLGの実験文化と根本的に合わないこと。

つまり、PLGは最初からその前提で設計されたプロダクトと組織でなければ機能しにくい。既存のSLG型SaaS企業が「Slackがやっているから」とPLGに転換しようとしても、プロダクトの設計思想、組織のDNA、営業の報酬体系すべてが逆方向を向いている。

PLGとSLGは、プロダクトの特性と顧客の購買プロセスで使い分けるものだ。Slackですらエンタープライズ契約にはセールスチームを使っている。問うべきは「PLGかSLGか」ではなく、「自社のプロダクトと顧客にとって、どちらが自然か」のほうだと思う。

第5章：Spotifyモデル（Squad / Tribe / Guild / Chapter）── 組織図を描き直しても文化は変わらない

美しい組織図の誘惑

2012年にSpotifyが公開した「Squad/Tribe/Guild/Chapter」という組織モデルは、アジャイル組織の理想形として広まった。

小さな自律的チーム（Squad）がプロダクトの特定領域を端から端まで担当する。複数のSquadがTribe（部族）を形成し、横断的な知見はGuild（同業者組合）やChapter（支部）で共有する。図にすると美しいし、説明しやすい。

多くの企業がこれを入れようとした。そして多くがうまくいかなかった。

前提条件

数百人規模のエンジニア組織。 Squad/Tribe構造は、大きな組織のチーム間調整コストを下げる仕組みだ。エンジニアが20〜30人なら、マネージャーが直接全員と話したほうが早い。4〜5人のSquadを4つ作ってTribeとしてまとめても、調整のオーバーヘッドが増えるだけで、スピードは上がらない。

自律的に動ける文化の蓄積。 Squadが機能するには、各チームが自分で判断し、自分でデプロイし、自分で結果を測定できる文化が必要だ。これは制度を入れれば自動的に生まれるものではない。承認待ちが常態化している組織に枠組みだけ入れても、中身は変わらない。

プロダクトが十分に分割できること。 各Squadが独立した領域を持てるだけの規模と複雑さが必要だ。単一プロダクトのスタートアップで無理に分けると、境界が曖昧になって依存関係がかえって増える。

Spotify自身が「真似するな」と言っている──そして実際にやめた

見落とされがちだが重要な話として、あのホワイトペーパーの著者自身が、冒頭で「これは我々の現在の働き方のスナップショットに過ぎない──進行中の旅であり、完了した旅ではない」と明記している。 つまり、他社が再現すべきテンプレートとして作られたものではない。Henrik Kniberg自身も後に「これは汎用フレームワークでも『モデル』でもない。一つの会社の働き方の一例に過ぎない」と述べている。

さらに重要なのは、Spotify自身がこのモデルから離れたという事実だ。2017年にSpotifyに入社した元プロダクトマネージャーのJeremiah Lee氏は、入社前にリクルーターから「Spotifyをアジャイルの理想郷だと期待しないように」と釘を刺されたと証言している。Lee氏によれば、あのSquadモデルは社内でも完全には実装されておらず、組織が3,000人規模に急拡大する中で、より伝統的なマネジメント構造へと段階的に移行していった。

失敗した理由も構造的だ。高い自律性を目指したが、チーム間の協業プロセスが定義されていなかったために、知識の共有が進まず、重複した作業が生まれた。Squad間で異なるやり方が許容された結果、チームをまたいで連携するたびに「このチームのやり方」を理解し直す必要が生じた。そして、既存の組織構造に新しい名前をかぶせたことで、実質的な変化がないまま「変革した」という幻想だけが残った。

書いた本人たちが「あれは存在しなかった」と言っている

Jeremiah Lee氏の証言だけではない。ホワイトペーパーの共著者Anders Ivarsson氏自身が、後にこう述べている。「人々が我々のやり方を見て、コピーして導入できるフレームワークだと思うのが心配だ。我々もまだ問題を抱えている。すべてがキラキラしていてうまくいっているわけではない」。

さらに、Spotifyの元アジャイルコーチJoakim Sundén氏（2011〜2017年在籍）はもっと踏み込んでいる。「書いた時点ですら、我々はそれをやっていなかった。あれは一部が野心で、一部が近似だった。人々が実際には存在しなかったものをコピーしようとして苦労している」。

存在しなかったものをコピーしている。これはカーゴカルトの定義そのものだ。

ING銀行 ── 最も有名な導入企業がたどった道

Spotifyモデルの外部導入で最も有名なのは、オランダのING銀行だ。2015年、ING Netherlandsは約350のSquadと13のTribeに組織を再編した。McKinseyのインタビューで当時のCOO Bart Schlatmann氏は、Spotifyを何度もスウェーデンまで訪問して学んだと語っている。

初期には成果が報告された。タイム・トゥ・マーケットの短縮、従業員エンゲージメントの向上。McKinseyの記事はこの変革を好意的に紹介した。

しかし、INGはその後、Squadモデルから段階的に離れ、LeSS（Large-Scale Scrum）の要素を取り入れる方向に移行している。理由は、Squad間のサブ最適化──各Squadが自分のスコープだけに集中し、全体最適から離れていく現象──が顕著になったためだ。LeSS導入の記録には「Squadは部分最適化を起こしていた」と明記されている。

これはJeremiah Lee氏がSpotify社内で目撃したのとまったく同じ問題だ。高い自律性を与えたが、チーム間の協業プロセスを定義しなかったために、知識の共有が進まず、重複した作業が生まれ、全体の生産性が下がる。Spotifyでもうまくいかなかった構造的な問題が、3,500人規模の銀行でも忠実に再現された。

組織図は一晩で描き直せる。文化は一晩では変わらない。

第6章：THE MODEL ── 一番身近で、一番よく壊れるフレームワーク

日本のSaaS企業のデファクト

FDE、PLG、Spotifyモデルは海外発で、導入を検討する企業も限られる。だがTHE MODELは違う。日本のSaaS企業ならほぼ全員が知っていて、多くが何らかの形で導入を試みている。マーケ→IS（インサイドセールス）→FS（フィールドセールス）→CSの分業モデル。Salesforceが体系化し、福田康隆氏の著書で日本に広まった。

THE MODEL自体は優れたフレームワークだと思う。役割を分担し、各プロセスの数字を可視化し、ボトルネックを特定して改善する。理屈は正しい。

だが、THE MODELの導入がきれいに機能している組織は少ないのではないだろうか。箱は作る。役割は分ける。でも中身が動かない。

箱だけ作って全部TBD

THE MODELの導入でよく見る光景がある。体制図を作り、IS、FS、CSと部署を分け、各部署のKPIを設定する。ここまでは一瞬でできる。

しかし、それぞれの部署が「なぜ自分たちが存在しているのか」「自分たちの仕事の成果が次の工程にどう影響するのか」を理解しないまま走り始める。箱は立派だが、中身は全部TBD（To Be Determined＝未定）の状態だ。

結果として、各部署はとりあえず自分の目の前の仕事をこなすことで精一杯になる。ISはアポを取る。FSは商談をする。CSは問い合わせに答える。それぞれが「自分の数字」を追うことに集中する。

「渡す」ができない

THE MODELの本質は分業ではない。各プロセスの「渡し」を最適化することで全体のスループットを上げることにある。ISがFSに何を渡すべきか。FSがCSにどんな情報を引き継ぐべきか。この「渡し」の設計がTHE MODELの肝だ。

ところが、実際に起きるのはこうだ。ISはアポの数を追っているから、とにかく数を渡す。FSは「このアポ、全然温まってないじゃないか」と不満を持つ。FSが受注してCSに渡すときも、顧客が何を期待して契約したのかの情報が消える。CSは「聞いてない」から始まる。

なぜこうなるか。各部署のKPIが部門最適に設計されていて、全体最適になっていないからだ。ISの評価がアポ数で決まるなら、質より量を追うのは合理的だ。次の工程に何を届けるべきかよりも、自分の数字を優先するのは、個人の姿勢の問題というより、設計の問題だと思う。

スタートアップ特有の壁

THE MODELの崩壊は、スタートアップが組織を拡大する過程で特に起きやすい。

創業期は3〜5人で全部やっている。誰かがリードを取り、誰かが商談し、誰かがサポートする。境界は曖昧だが、全員が全体を見ているから回る。

組織が20人、30人と増えていく過程で、THE MODEL的な分業を入れる。ここで「人数のマネジメントの壁」とフレームワーク導入が同時に来る。新しく入った人は全体像を知らない。自分の部署のKPIだけを渡されて、「これを追え」と言われる。前後の工程が何をやっているか知らないし、知る機会もない。

こうして、箱の中で自分の仕事をすることに精一杯で、隣の箱に何を渡すべきかわからない──という状態が生まれる。THE MODELを入れたことで、かえってサイロ化が進むという皮肉な結果になる。

THE MODELを機能させるための条件 ── IS・FS・CSの「渡し」の設計

THE MODEL自体が悪いわけではない。ただ、機能させるには条件がある。

全員が「なぜ分業するのか」を理解していること。 分業の目的はプロセスの可視化と改善であり、自分の仕事を楽にすることではない。

「渡し」の設計が先にあること。 箱を作る前に、ISからFSに何を渡すか、FSからCSに何を引き継ぐかを定義する。KPIも、自部門の数字だけでなく、次の工程への「渡しの質」を含めて設計する。たとえばISの評価にアポ数だけでなく「FSが初回商談で顧客課題を把握できていた割合」を入れるだけで、渡しの質は変わる。

定期的に全体を見直す仕組みがあること。 各部門が月に一度でも集まって、「渡し」がうまくいっているかをレビューする。これがないと、部門最適がどんどん進んで全体最適から離れていく。実際には、IS・FS・CSの担当者が一つの案件を一緒に振り返る場を作るだけでも、「渡し」の問題は見えてくる。大掛かりな仕組みを作る前に、まずこの「振り返り」から始めるほうが現実的だと思う。

FDEやPLGと同じで、フレームワークの「形」だけ入れても機能しない。THE MODELの場合、形を入れるのが簡単な分、中身のない導入がより頻繁に起きている。

第7章：なぜ誰も止められないのか

FDE、PLG、Spotifyモデル、THE MODEL。4つに共通しているのは、課題の捉え方は合っているのに、解法の選び方がずれるという構造だ。

そしてもう一つ共通しているのは、組織の中で誰もそのずれに気づかないということ。あるいは気づいていても止まらない。

提案する側もわかっていない

フレームワークを提案するのは、たいてい経営者やマネジメント層だ。カンファレンスで聞いた、記事で読んだ、書籍に書いてあった。「What（何をやるか）」は理解している。だが「Why（なぜそれが元の企業で機能したか）」まで掘り下げている人はほとんどいない。

自社の組織の座組──誰が何をできて、何ができなくて、チーム間の連携がどうなっていて、プロダクトの何が足りていないか──を正確に把握しないまま、外から持ってきた箱をかぶせようとする。箱の中身は全部TBD。「体制図は作った、あとは現場で回してくれ」。

これは怠慢ではなく、「なぜ成立するか」を調べることの認知コストが高いからだと思う。成功企業の決算資料を読み、元社員の証言を探し、自社の条件と照合する。この作業は地味で面倒で、「とりあえずやってみよう」の爽快感がない。

受け取る側も検証しない

提案された側──現場のメンバーや中間管理職──はどうか。大抵は誰も疑問を持たない。

フレームワークの名前を初めて聞く人が多い。「FDE」も「PLG」も「Spotifyモデル」も、知らないから評価のしようがない。知らないことを自信を持って語る上司に対して、「それ、うちの条件では成立しないんじゃないですか」と言える人はなかなかいない。

むしろ「そんなことまで知ってるんですね、すごい」という反応になる。検証以前に、検証すべきだという発想自体がない。

気づいている人がいても止まらない

では、組織の中に「これはうちでは無理だろう」と感じている人がいたらどうか。

正面から「それは条件が違うから無理です」と止めるのは、組織の力学として通りにくい。「やるとしたら何が必要か」を一緒に調べていくほうが現実的だと思う。元の企業の条件を洗い出し、自社の状態と照合していく。そうすると「ここの条件が全然違いますね」が自然に見えてくることがある。

ただし、このアプローチも万能ではない。調べた結果「やっぱり条件が違う」とわかっても、「でもやりたい」で押し切られるケースもある。

構造的に検証が起きない

まとめると、フレームワーク導入の現場では以下のことが同時に起きている。

• 提案する側はWhyを検証していない

• 受け取る側は検証するための情報も余裕もない

• 気づいている人がいても、組織の力学で止められない

この三重構造によって、条件を満たしていないフレームワークの導入が、ほとんど何のチェックも受けずに走り始める。そして走り始めてから「なんかうまくいかない」が始まる。FDEを入れたら受託化した。PLGを目指したが誰もサインアップしない。Spotifyモデルを導入したが名前が変わっただけ。THE MODELを入れたがサイロ化が進んだ。

第8章：導入前に立ち止まって考えたいこと

フレームワークの導入を検討するとき、一度立ち止まって確認しておきたいことがある。自戒も込めて、3つ挙げてみる。

そのフレームワークが元の企業で成立している条件は何か。

中身を理解するだけでは足りない。顧客単価、組織規模、人材レベル、プロダクトの成熟度、文化的な蓄積。元の企業の決算資料や採用ページ、元社員の発信から、かなりの情報が拾える。Palantirの場合、決算資料で顧客単価を、Glassdoorで報酬水準を、元FDEのブログでモデルの実態を確認できる。この程度の調査は半日もあればできるし、半日で防げる判断ミスは少なくない。

自社は今、その条件を満たしているか。

「将来的には満たせる」ではなく、今の時点で満たしているかどうか。「ARPAが上がれば」「エンジニアが増えれば」「文化が変われば」──こういう仮定を置き始めると、どんなフレームワークでも導入できてしまう。だが条件が揃っていなければ、設計通りには動かない。

同じ課題を、自社の座組で解く方法はないか。

フレームワークは特定の課題に対する解法の一つだ。FDEが解こうとしている「導入後の活用不足」は、プロダクトの機能改善やCSの仕組みでも解ける。PLGが目指す「低コストでのスケール」は、営業効率の改善やコンテンツマーケでも追求できる。Spotifyモデルが狙う「チームの自律性」は、権限委譲の設計や1on1の改善でも前に進められる。THE MODELが目指す「プロセスの可視化と改善」は、まず「渡し」の設計から始めれば、大掛かりな組織改編なしでも実現できる。

借り物のフレームワークより、自社の現状から逆算した仕組みのほうが、だいたいフィットする。

第9章：「What」ではなく「Why」を持ち帰る

成功企業から学ぶ価値は大きい。ただ、持ち帰るべきものは「何をやったか」ではなく「なぜそれが機能したか」だと思う。

Palantirから持ち帰るべきは「FDEを置くこと」ではなく、「顧客の現場で価値を実証するプロセスがなぜ重要か」。Slackから持ち帰るべきは「PLGにすること」ではなく、「プロダクト体験だけで価値を伝えるとはどういう設計か」。Spotifyから持ち帰るべきは「Squad制にすること」ではなく、「チームが自律的に動くために何が必要か」。Salesforceから持ち帰るべきは「IS/FS/CS分業にすること」ではなく、「プロセス間の渡しを可視化し改善するとはどういうことか」。

Whyを理解した上で、自社の条件に合う形に翻訳する。その結果、元のフレームワークとはまったく違うものになることもある。それでいい。形が違っても、本質が合っていれば機能する。形だけ揃えても、本質が違えば機能しない。

たとえば、FDEのBarry McCardel氏自身がPalantirを離れた後に共同創業したHex社では、FDEモデルをそのまま再現するのではなく、「顧客と一緒に作る」というWhyだけを持ち帰っている。エンジニアを顧客先に常駐させる代わりに、顧客と密にコミュニケーションを取りながら素早く機能を発見・開発する「Commitment Engineering」というプロセスを設計した。形はFDEとまったく違うが、「顧客の現場で価値を実証する」という本質は引き継いでいる。氏はブログで「このアプローチを強く勧めるが、それをFDEと呼んだり、そうでないものをそう見せかける必要はない」と書いている。

竹の管制塔からは、飛行機は来ない。

ただ、飛行機が来る条件を理解していれば、自分たちの手元にある材料で、ちゃんと動く仕組みは作れる。フレームワークを「コピーする」のではなく「翻訳する」。自分の組織と事業に、それは本当に合っているのか。一度立ち止まって考えてみることが、たぶん一番大事なことだと思う。

2026年2月