Rampの「Speed First Engineering」から学ぶ高速開発の秘訣

“

この記事は Building Ramp (Invest Like the Best / Colossus) と Ramp の公式 About / Intelligence / AI Principles / Bill Pay ページをもとに、時点依存の数字を除いて再構成しています。

この記事でわかること

• Rampが語る「Speed First」を、会社指標ではなく開発原則として読む視点
• 「バグを恐れない」ではなく「修正速度を上げる」組織の作り方
• AIを補助ツールで終わらせず、approval workflowに埋め込む考え方
• 日本企業でも小さく試せる高速開発の4ステップ
• valuation や顧客数より、ownership と feedback loop に注目すべき理由

3行でわかる要点

1. Speed First = 品質無視ではない: 学習サイクルと修正速度を上げ、長期的な生産性を最大化する考え方
2. AIは workflow に埋め込んで効く: 低リスクの承認や入力作業を自動化し、例外だけ人間に返す設計が要点
3. 数字より operating system を見る: valuation や顧客数は変わるが、ownership と feedback loop の原則は転用しやすい

本記事では、2025年10月21日に公開された Colossus / Invest Like the Best の episode 445「Building Ramp」で、Ramp co-founder / CTO の Karim Atiyeh 氏が語った内容を軸に、「Speed First Engineering」を解説します。

評価額や売上のような company metric は変化が早いため、このページでは現在も再利用しやすい原則とワークフロー設計に絞ります。

本記事で使われる用語

このインタビューの前提: Rampは何を作っている会社か

Rampはfinance operations platform

Rampの現在の公式ページでは、同社を finance operations platform と位置づけています。法人カードや経費管理だけでなく、請求書処理、調達、承認、travel、treasury、会計自動化までを一つの workflow にまとめるのが軸です。

• Corporate cards / expense management
• Bill Pay / procurement / approvals
• Travel / treasury / accounting automation

この領域は approvals、policies、ERP 連携、fraud check など依存関係が多く、少しの待ち時間が全体の速度を大きく落とします。だからこそ、この記事で持ち帰るべきなのは company metric より「どうやって複雑な業務を速く回すか」です。

話者プロフィール: Karim Atiyeh

Colossus の episode page では、今回の話者は Ramp co-founder and CTO の Karim Atiyeh 氏と紹介されています。

インタビューでは、エンジニアリングだけでなく、採用、マーケティング実験、AI を組み込んだ finance workflow まで一続きの operating system として語られています。そこがこの記事の読みどころです。

なぜ「Speed」が競争優位なのか

財務オペレーションのソフトウェアは、ユーザーが欲しい画面を作るだけでは終わりません。承認フロー、経費ポリシー、請求書、会計連携、監査対応までがつながって初めて価値になります。この環境では、機能数より「学習サイクルをどれだけ短くできるか」が効きます。

“

"素晴らしい成果とインパクトを目指すなら、物事が壊れていることを望むべきです。"

— Karim Atiyeh, Ramp co-founder and CTO

ここでいう競争優位は valuation ではなく、意思決定と修正の速さです。Rampの議論を日本企業に持ち込むなら、この一点だけで十分価値があります。

Speed First Engineeringとは何か

定義と基本コンセプト

Speed First Engineeringは、単に「速く作る」ことではありません。「持続可能な速さ」を追求する開発哲学です。

重要な区別として、Facebookの「Move Fast and Break Things」とは異なります。

“

"バグを出さない最高の方法を知っていますか？何も出荷しないことです。コードを書かなければバグはゼロです。それがこのアプローチの問題なんです。"

— Karim Atiyeh, Ramp co-founder and CTO

Karimが強調するのは、「バグを恐れすぎて何も出荷しないこと」が最大のリスクだということです。

重要でない部分は1日10回壊れても良い。重要なのは「修正速度」です。

従来のアジャイル開発との違い

従来のアジャイル開発では、スプリント計画や見積もりに多くの時間を費やします。Rampのアプローチでは、これらのプロセスを大幅に簡略化しています。

“

"シュレーディンガーの原理のようなものがあります。タスクにかかる時間の精度を高めるか、速く実行するか。両方は難しい。"

— Karim Atiyeh, Ramp co-founder and CTO

このインタビューでは、詳細見積もりの精度を上げることよりも、素早く出して学び、必要なら修正することが重視されています。

Rampが実践する5つの高速化原則

原則1. Bias to Action（行動優先）

完璧な計画を待たず、まず動きます。プロトタイプを素早く作り、実際のフィードバックを得ます。失敗を前提とした実験文化が根付いています。

身近な例: 「完璧な企画書を1週間かけて作ってから提案する」のではなく、「30分でラフ案を作って、まず上司に見せる」アプローチです。

フィードバックを早く得ることで、的外れな方向に時間を費やすリスクを減らせます。

Rampでは、アイデアから実行までの時間を極限まで短縮しています。マーケティング部門では「ブリーフ作成から実行まで2週間」だったプロセスを「10分」に短縮しました。

原則2. Simplicity by Default（デフォルトはシンプル）

技術選定では「今必要なもの」に集中します。オーバーエンジニアリング（過剰に複雑な設計）を徹底的に排除し、シンプルなソリューションを選びます。

新しい技術を追いかけるのではなく、既存の成熟した技術を組み合わせる戦略です。チームが最も生産性を発揮できる技術を選びます。

原則3. Fast Feedback Loops（高速フィードバック）

顧客との直接対話を重視し、データドリブンな意思決定を行います。A/Bテスト（2パターンを比較する実験）を徹底活用し、仮説を素早く検証します。

身近な例: 「3ヶ月かけて作った新機能が、リリースしてみたらユーザーに不評だった」という悲劇を避けるために、「1週間で最小限の機能を作り、10人のユーザーに使ってもらって反応を見る」アプローチです。

Rampの現在のAI訴求もこの原則と整合しています。低リスクの承認や coding を workflow の中で処理し、曖昧なものだけ人間に返すからこそ、feedback loop が短くなります。

原則4. Clear Ownership（明確な責任範囲）

チーム構造を明確に設計し、意思決定権を現場に委譲します。依存関係を最小化することで、各チームが自律的に動けるようにしています。

身近な例: 「この件、誰に聞けばいいの？」「A部署とB部署の両方の承認が必要」という状況をなくすことです。

「この機能はこのチームが責任を持つ。判断もそのチームがする」と明確にすれば、調整待ちの時間がなくなります。

「合意形成」ではなく「権限委譲」です。担当者が判断し、事後報告でOKという文化です。Ramp の現行 About ページでも Take ownership が value として掲げられており、ownership を operating rule として扱う姿勢が確認できます。

原則5. Automation Everywhere（徹底した自動化）

CI/CDパイプライン、テスト自動化、デプロイメント自動化を徹底しています。人間が手動でやる作業を極限まで減らすことで、開発者は本質的な問題解決に集中できます。

AI活用の2つの段階

Karimは、企業のAI活用には2つの段階があると説明しています。

第1段階: 既存業務の補助

• GitHub Copilotによるコード補完
• ChatGPTによる情報収集
• 既存の業務を「少し速くする」レベル

第2段階: LLMを製品に組み込む

• AIが workflow の一部として判断を支える
• 低リスクな定型作業を自律的に処理する
• 人間は例外や不可逆な意思決定に集中する

現在の Ramp Intelligence ページでも、AI は単独のチャット UI ではなく、expense review、invoice coding、fraud flagging、policy enforcement に散りばめられた layer として説明されています。この記事で大事なのも、その設計思想です。

なぜ経費精算は面倒なのか？

Policy Agentを理解するために、まず「従来の経費精算の面倒さ」を整理しましょう。多くの会社員が経験する悩みです。

従来の経費精算の3つの悩み:

1. 申請する側（社員）: 領収書を集めて、経費システムに1件ずつ入力して、上司に申請を出す
2. 承認する側（マネージャー）: 「この出張は本当に必要だった？」「この金額は妥当？」と1件ずつ確認
3. 経理部門: 月末に大量の申請を処理、不備があれば差し戻し、締め日に追われる

この「人間が1件ずつ目視で確認する」プロセスこそ、AI を workflow に埋め込む余地が大きい部分です。

Policy Agent: 何がdurableな学びか

“

"私たちのポリシーエージェントは、今日の取引を審査する人間よりも多くのコンテキストを持っています。"

— Karim Atiyeh, Ramp co-founder and CTO

重要なのは、初期顧客の精度や倍率といった benchmark の数字ではありません。現在の Ramp 公式ページが強調しているのは、「何を agent に任せ、どこで human checkpoint を置くか」です。

Rampの current AI workflow から読み取れる要点:

• Policy / controls で学習する: 会社ごとの承認ルールや spend pattern を前提に動く
• Approves when it's safe: 低リスクで定型的なものは agent が処理する
• Escalates when it's not: 曖昧・高リスク・不審なものは人間へ即座に戻す
• Transparent and auditable: 判断根拠が見え、調整でき、不可逆な判断は人間が最終責任を持つ

Ramp の AI Principles でも、Outcomes, not interfaces と Take ownership が明示されています。再利用しやすい学びは、「AI をチャット窓口として足す」ことではなく、「ガードレール付きで仕事を進める workflow に埋め込む」ことです。

消費者グレードUXへの執着

“

"ビジネス製品に消費者グレードのユーザー体験を構築することへの執着... InstagramのようなUXをビジネスソフトウェアに適用したかったのです。"

— Karim Atiyeh, Ramp co-founder and CTO

従来のB2Bソフトウェアは「決裁者向け」に設計されていました。実際に使う従業員のことは二の次です。その結果、使いにくいソフトウェアが蔓延しました。

Rampは違います。すべてのユーザーの体験を最適化し、「使いたくなる」ビジネスソフトウェアを目指しています。

この姿勢が、従業員からの支持を集め、ボトムアップでの導入を促進しています。

エンジニアがマーケティングを変革

インタビューでは、Karim はマーケティング実験まで engineering 的に捉える姿勢を語っています。その結果、マーケティングにも「システム思考」が導入されます。

Before（変革前）

• ブリーフ作成 → レビュー → 実行まで2週間
• 静的なビルボード広告

After（変革後）

• アイデア → 実行まで10分
• 1週間に7回変わるビルボード

“

"1週間に7回変わる1枚のビルボードは、2枚の静的なビルボードよりメッセージを伝える強力な方法です。"

— Karim Atiyeh, Ramp co-founder and CTO

ニューヨークにビルボードを出すと10万ドル（約1,500万円）。しかし既に買ったビルボードを変更するのは1,000ドル（約15万円）だけです。この「システムの特性」を理解し、最適化するのがエンジニア的思考です。

スパイキーな人材採用戦略

“

"10個のチェックボックスを埋める人よりも、明確なスーパーパワーを持つアベンジャーズを集めることに興味があります。"

— Karim Atiyeh, Ramp co-founder and CTO

Rampの採用哲学は「スパイキーな人材」を求めることです。

従来型採用

• 10個のスキルチェックリストを満たす人
• 平均的に全て「まあまあ」

Ramp型採用

• 1つの分野で極端に優れた人
• 他は平均以下でもOK
• 「アベンジャーズを集める」発想

新卒1年目でも、極めて優秀なら採用します。年齢や経験年数よりも「スパイキー（尖った）なスキル」を重視します。

実践ステップ：日本企業への適用方法

Step 1. 現状の開発速度を測定する

まず、現状を把握することから始めます。DORA Metrics（ドラ・メトリクス：開発効率の4つの指標）を活用しましょう。

DORA Metricsの4つの指標:

• Lead Time for Changes: コードコミットから本番デプロイまでの時間
• Deployment Frequency: デプロイの頻度
• Mean Time to Recovery (MTTR): 障害からの復旧時間
• Change Failure Rate: 変更による障害発生率

Step 2. ボトルネックを特定する

バリューストリームマッピング（開発プロセスの可視化手法）で、どこに時間がかかっているかを可視化します。

確認すべき3つのポイント:

• コードレビュー: 待ち時間はどれくらいか？
• テスト: 実行時間はどれくらいか？
• デプロイ: 承認プロセスはどれくらいか？

チーム内アンケートも有効です。現場の声を聞きましょう。

Step 3. Quick Winを積み重ねる

大きな変革を一度に行うのではなく、小さな改善から始めます。

Quick Win（小さな成功）の例:

• CI/CD高速化: パイプラインの実行時間を短縮
• SLA設定: コードレビューは24時間以内と明確化
• 自動テスト拡充: カバレッジを段階的に向上

成功体験を共有し、チームのモチベーションを高めます。

Step 4. 組織全体に展開する

小規模チームで実証できたら、横展開します。

組織展開の3つのステップ:

• 経営層: 理解とサポートを得る
• 連携体制: 他部署との協力体制を構築
• KPI追跡: 指標を設定し、継続的に測定

数字ではなく operating system を持ち帰る

Ramp の valuation、顧客数、競合の買収や product roadmap は変化が早く、記事の鮮度を落としやすい要素です。この記事で持ち帰るべきなのは、次の 4 点です。

• アイデアから顧客フィードバックまでの待ち時間を減らす
• ownership を近いチームに置き、調整待ちを減らす
• 低リスクの定型作業を自動化し、例外だけ人間に戻す
• 大きな計画書より、小さな loop を回して学ぶ

この 4 つは、会社規模や市場環境が変わっても比較的残りやすい原則です。

「ログイン不要の財務システム」をどう読むか

“

"私の希望は、人々が基本的にRampにログインする必要がなくなることです。財務の多くが本質的に自動運転になります。"

— Karim Atiyeh, Ramp co-founder and CTO

Karimが描く未来は、ユーザーが「毎回ツールを開いて手で処理しなくても良い」財務システムです。

これは dated な product roadmap として読むより、workflow の方向性として読むほうが有益です。つまり、画面を1枚ずつ操作する back-office から、policy-driven に自動処理される back-office への移行です。

• ルーティン承認は agent が処理する
• 異常や曖昧さがあるときだけ人間を呼ぶ
• 人間は最終責任と例外判断に集中する

この balance は Ramp の AI Principles にも通じています。AI に任せる範囲を広げつつ、透明性、監査可能性、不可逆な判断に対する human final say は残す、という考え方です。

よくある質問（FAQ）

Q1. Speed Firstで品質は下がりませんか？

短期的な速さと長期的な速さの違いを理解することが重要です。

自動テスト、コードレビュー、ペアプログラミングなど品質を担保する仕組みを並行構築することで、持続可能な速さを実現できます。

Q2. Rampの手法は大企業にも適用できますか？

可能ですが段階的アプローチが必要です。まず小規模チームで実証し、成功体験を作ってから横展開する方法が効果的です。

Q3. どんな技術スタックを選ぶべきですか？

「チームが最も生産性を発揮できるもの」が正解です。Rampは既存の成熟技術を組み合わせる戦略を取っています。最新技術を追う必要はありません。

Q4. 技術的負債はどのタイミングで返済すべき？

「事業成長を阻害し始めたとき」が目安です。負債の可視化と定量化が重要です。

PMF（Product-Market Fit：製品と市場の適合）を探索中は意図的に負債を作ることも戦略となります。

Q5. リモートチームでも高速開発は可能？

可能です。むしろ非同期コミュニケーションが強制されることで、ドキュメント化が進み、長期的には生産性向上につながることもあります。

Q6. エンジニア採用で重視すべきスキルは？

技術スキルよりも「学習速度」「自律性」「コミュニケーション力」を重視します。

具体的な技術スタックは入社後でもキャッチアップ可能です。スパイキー（尖った）な強みがあるかを見極めましょう。

Q7. 見積もりをやめると、スケジュール管理はどうする？

大まかなマイルストーンは設定しますが、詳細なタスク見積もりは行いません。

代わりに、継続的なデリバリーと進捗の可視化で管理します。見積もり精度を上げるコストより、実行速度を上げる方が価値があります。

Q8. スタートアップフェーズごとに戦略は変わる？

変わります。PMF前は極端なSpeed First、PMF後は品質とのバランス、スケール期は標準化と再現性を重視します。フェーズに応じた最適解があります。

まとめ

Speed First Engineeringは、単なる「速さ」ではなく「持続可能な速さ」を追求する開発哲学です。

主要ポイント

1. Speed First = 品質無視ではない：修正速度を上げることで、バグを恐れず出荷できる
2. 5つの原則：行動優先、シンプル志向、高速フィードバック、明確な責任、徹底自動化
3. AIは workflow に埋め込むと効く：policy、approval、coding、exception handling をまたいで設計する
4. 数字より仕組みを真似る：valuation や顧客数ではなく、loop、ownership、guardrails を持ち帰る

次のステップ

• 自社の開発速度を測定する（Lead Time、Deployment Frequency）
• チーム内でSpeed First Engineeringの勉強会を開催する
• 小さな改善から始めて、Quick Winを積み重ねる

参考動画

この記事は以下の一次情報を参考に作成しました：

• Building Ramp - Colossus / Invest Like the Best episode page
• About Us - Different By Design - Ramp
• Ramp Intelligence - Ramp
• Ramp AI Principles - Ramp
• Ramp Bill Pay / Accounts Payable - Ramp