“

この記事は Ramp's CTO on Shipping Fast and Leveraging AI (Invest Like the Best) の内容を基に作成しています。

この記事でわかること

• 評価額1.2兆円のスタートアップRampが実践する「Speed First」開発哲学
• 「バグを恐れない」開発文化の作り方と、その具体的な実践方法
• AI（Policy Agent）を活用した経費精算の自動化事例
• 日本企業でも明日から始められる高速開発の4つのステップ

3行でわかる要点

1. Speed First = 品質無視ではない: 「正しい速さ」を追求し、長期的な生産性を最大化
2. 意思決定の高速化: 技術選定・設計判断に明確な基準を設け、迷いを排除
3. 組織全体の最適化: エンジニアだけでなく、プロダクト・デザイン・ビジネスチームが一体化

評価額81億ドル（約1.2兆円）を超えるフィンテックユニコーン、Ramp。わずか数年で爆発的な成長を遂げた裏には、「Speed First Engineering」という独自の開発哲学があります。

本記事では、Ramp CTOのKareem Zaki氏が語る「速度を武器にする開発手法」を徹底解説します。

Speed First Engineeringの5原則

本記事で使われる用語

Rampとは？フィンテックユニコーンの軌跡

会社概要と成長の軌跡

Rampは2019年に創業した法人向け経費管理プラットフォームです。法人カード、経費精算、請求書管理、財務レポートを統合したサービスを提供しています。

創業から約5年で年間処理額は数兆円規模に成長。評価額は81億ドル（約1.2兆円）を超え、フィンテック業界で最も急成長している企業の1つです。

話者プロフィール：Kareem Zaki

本記事は、Ramp CTOのKareem Zaki氏のインタビューを基にしています。

Kareem Zaki（カリーム・ザキ）

• Ramp CTO（最高技術責任者）・共同創業者
• レバノン出身、MIT（マサチューセッツ工科大学）卒業
• 前職でParabusを創業し、Capital One（米国大手金融機関）に売却した連続起業家
• 技術部門だけでなく、マーケティング部門も統括する稀有なリーダー

「技術とビジネスの両方を深く理解している」からこそ語れる、実践的な開発哲学が本記事の内容です。

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

フィンテック市場では、Brex、Bill.com、Expensifyなど強力な競合がひしめいています。この環境で後発のRampが勝てた理由の1つが「圧倒的な開発速度」です。

“

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

— Kareem Zaki, Ramp CTO

市場の変化が早いほど、素早く対応できる企業が勝ちます。Rampは「速度」を意図的に競争優位性として設計しています。

Speed First Engineeringとは何か

定義と基本コンセプト

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

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

“

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

— Kareem Zaki, Ramp CTO

Kareemが強調するのは、「バグを恐れすぎて何も出荷しないこと」が最大のリスクだということです。重要でない部分は1日10回壊れても良い。重要なのは「修正速度」です。

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

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

“

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

— Kareem Zaki, Ramp CTO

Rampでは「タスクの見積もり」をほとんど行いません。見積もりに時間をかけるより、実行に集中する方が効率的だからです。

従来型開発 vs Speed First Engineering

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の「Policy Agent」も、この高速フィードバックの結果生まれました。24/7稼働で経費ポリシーを自動判定し、継続的に精度を向上させています。

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

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

身近な例: 「この件、誰に聞けばいいの？」「A部署とB部署の両方の承認が必要」という状況をなくすことです。「この機能はこのチームが責任を持つ。判断もそのチームがする」と明確にすれば、調整待ちの時間がなくなります。

「合意形成」ではなく「権限委譲」。担当者が判断し、事後報告でOKという文化です。

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

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

AI活用の2つの段階

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

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

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

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

• AIが製品の中核機能を担う
• 自律的に判断・実行する
• 人間より多くのコンテキストを持つ

Rampは第2段階に到達しています。その代表例が「Policy Agent」です。

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

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

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

この「人間が1件ずつ目視で確認する」プロセスが、RampのPolicy Agentでは24時間自動化されています。

Policy Agent：経費精算AIの実力

“

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

— Kareem Zaki, Ramp CTO

従来の経費精算では、社員が経費を使った後、マネージャーが規定に沿っているか確認していました。非常に手作業で、時間がかかります。

RampのPolicy Agentは以下の機能を持っています。

• カレンダー、メール、経費ポリシーを統合して判断
• 24時間365日稼働で自動判定
• 人間の審査者より多くのコンテキストを参照
• ポリシー改善の提案も自動で行う

これはAIが「業務を補助する」のではなく「業務を代替する」レベルです。

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

“

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

— Kareem Zaki, Ramp CTO

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

Rampは違います。すべてのユーザーの体験を最適化し、「使いたくなる」ビジネスソフトウェアを目指しています。この姿勢が、従業員からの支持を集め、ボトムアップでの導入を促進しています。

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

Kareemは技術者でありながら、マーケティング部門も統括しています。その結果、マーケティングにも「システム思考」が導入されました。

Before（変革前）

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

After（変革後）

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

“

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

— Kareem Zaki, Ramp CTO

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

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

“

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

— Kareem Zaki, Ramp CTO

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

従来型採用

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

Ramp型採用

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

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

Speed First Engineering 実践ステップ

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

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

まず、現状を把握することから始めます。DORA Metricsを活用しましょう。

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

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

バリューストリームマッピングで、どこに時間がかかっているかを可視化します。

• コードレビューの待ち時間は？
• テストの実行時間は？
• デプロイの承認プロセスは？

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

Step 3. Quick Winを積み重ねる

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

• CI/CDパイプラインの高速化
• コードレビューのSLA設定
• 自動テストの拡充

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

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

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

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

5年後のビジョン：ログイン不要の財務システム

“

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

— Kareem Zaki, Ramp CTO

Kareemが描く未来は、ユーザーが「ログインしなくても良い」財務システムです。AIが自動的に経費を処理し、異常があれば通知する。人間は例外処理だけを行う。

これは「自動運転する財務システム」です。

よくある質問（FAQ）

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

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

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

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

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

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

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

「事業成長を阻害し始めたとき」が目安です。負債の可視化と定量化が重要です。PMF（Product-Market Fit）を探索中は意図的に負債を作ることも戦略となります。

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

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

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

技術スキルよりも「学習速度」「自律性」「コミュニケーション力」を重視します。具体的な技術スタックは入社後でもキャッチアップ可能です。スパイキーな強みがあるかを見極めましょう。

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

大まかなマイルストーンは設定しますが、詳細なタスク見積もりは行いません。代わりに、継続的なデリバリーと進捗の可視化で管理します。見積もり精度を上げるコストより、実行速度を上げる方が価値があります。

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

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

Speed First Engineering まとめ

まとめ

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

主要ポイント

1. Speed First = 品質無視ではない: 修正速度を上げることで、バグを恐れず出荷できる
2. 5つの原則: 行動優先、シンプル志向、高速フィードバック、明確な責任、徹底自動化
3. AI活用の第2段階へ: LLMを製品に組み込み、人間を超えるコンテキストで自動判定
4. 組織全体の変革: エンジニアリングだけでなく、文化・プロセス・ツールの三位一体
5. スパイキーな人材: 平均的なジェネラリストより、1つの強みを持つスペシャリスト

Next Action

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

速度は意図的に設計できます。Rampの成功から学び、自社に適した「Speed First」を見つけてください。

参考動画

この記事は以下の動画を参考に作成しました：

• Ramp's CTO on Shipping Fast and Leveraging AI - Invest Like the Best with Patrick O'Shaughnessy