Jeremie Lebrunは、コンサルティングで10年を過ごした後、BlaBlaCar に6年間在籍しています。現在はHead of Engineering、Corporate Servicesとして、35名のチームを率いています。ノートパソコン、ネットワーク、HRツール、財務、CRM、自動化、バス事業関連のアプリケーションなど、すべての社内ツールを担当しています。つまり、エンドユーザーに直接向けられたものではなく、6カ国に分散した800名の従業員が効率的に働くためのすべてを担当しています。

ソリューションを内製するか、サードパーティツールを使用するかを選択する際の、技術的・ビジネス的な基準は何ですか？

Jeremie Lebrun： おそらく特別な点はないと思います。一方では、開発者は希少なリソースです。他方では、私たちよりも多くのテーマで成熟した人々が設計した市場のソリューションがあり、すでに多くを考え抜かれています。

私たちの原則はシンプルです。競合他社との差別化につながり、プロダクトビジョンの推進に役立つものはすべて内製します。逆に、差別化につながらないものは「既製品」を探します。例えば、財務・会計ソフトウェアを開発することに私たちの意義はありません。一方、カープーラー間のやり取りを調整するアルゴリズムについては、私たちだけがその経験とビジネスコンテキストを持っており、それは社内開発のままです。

しかし、その2つの間にはグレーゾーンがあります。そこでの判断は、保守性、市場カバレッジ、コスト、組織的な影響という基準で行われます。

一例を挙げると：BlaBlaCar Busサービスでは、遅延発生時に乗客へ通知するコミュニケーションシステムを構築する必要がありました。当初は既存ソリューションを購入しました。対応できるチームがなく、何が必要かもまだ正確にわかっていなかったためです。2年後、要件が具体化してきたところで、開発を内製化しました。

「ビルド」のコストと「バイ」のコストをどのように評価しますか？

Jeremie Lebrun： ビルド側では、どのチームが関わるか、どのくらいの期間か、インフラとプロダクトの複雑さはどうかを計算する必要があります。私たちの経験から、必要なチームの規模とデリバリーのタイムラインを見積もることができます。不必要な技術的負債を増やさないために、すでに習熟した技術に留まるようにしています。

バイ側では、ライセンス料だけではありません。常に、設定、社内システムへの接続、管理、セキュリティ、プロダクトのコストがあります。その後、時間経過とともに保守コストも考慮する必要があります。SaaSは問題をなくすわけではありません。それ独自の進化と制約をもたらします。

ベンダーへの依存は最初の選択に含まれています。SaaSソリューションを選択した場合、ある程度の依存を受け入れ、それを前提として適切に管理する必要があります。良いとこ取りはできません。

BlaBlaCar のような、強い成長やトラフィックのピークに対応しなければならないプラットフォームにおいて、どのビルドとバイの決定が最も構造的に重要ですか？

Jeremie Lebrun： 私たちは実用的なアプローチをとっています。技術的負債は汚い言葉ではありません。市場投入期間の短縮を可能にするなら価値があります。重要なのは、最初から財務的な負債のように集団的に受け入れることです。後で返済しなければならないことはわかっていますが、即時のメリットが将来のコストを上回る場合があります。

例：乗客へのSMS送信システムでは、最初は外部ソリューションを購入しました。2年間で400万件以上のSMSを送信し、NPS（顧客推奨度）を10ポイント以上改善できました。内製化したとき、何をすべきかを正確に把握していました。コーディング作業は残っていましたが、プロダクトマネジメント作業の80%はすでに完了しており、開発をより速く、より的確なものにしました。

判断を後悔したことはありますか？

Jeremie Lebrun： 適切なパートナーを選べずに変更しなければならなかったケースはあります。しかし全体的には、これらはエンジニアリングプロジェクトの通常の調整であり、メイクかバイかの選択を後悔したことは幸いありません。

ビルドとバイの選択はBlaBlaCar の技術文化やチーム組織にどのような影響を与えていますか？

Jeremie Lebrun： 歴史的に、BlaBlaCar は強い技術文化を持ち、すべてを内製してきました。そのため、SaaSやローコードソリューションの導入には、本当の教育的な取り組みが必要でした。議論を脱政治化する必要がありました。もちろん、開発者はすべてコーディングできますが、彼らの時間は貴重です。チケット管理ツールを開発することは意味がありません。

これには変更管理も含まれます。2週間ごとにデリバリーするアジャイルスクワッドは、2ヶ月ごとに新バージョンをデプロイするSaaSベンダーと同じペースでは動きません。作業方法を調和させ、コミュニケーションを合理化し、期待を揃える必要がありました。

開発者のプライドという問題もありますか？

Jeremie Lebrun： はい、2つのアプローチを比較するときはどこでもそうです。しかし、Salesforceのようなエコシステムに向かうことを実際に好む開発者プロファイルもあります。常に同じことをコーディングすることに疲れ、管理や統合に新しい活力を見つける人もいます。重要なのは問いを脱政治化することです。そう、私たちの開発者はすべてできますが、時には80%完成したソリューションを使う方が賢明です。

スタートアップやスケールアップでこれらの選択に直面している人へのアドバイスは？

Jeremie Lebrun： 非常にオープンで客観的であること。多くのスケールアップはすべて自前で構築したいと考えますが、すぐに「オペレーション」部分（CRM、自動化）をアウトソースします。重要なのは、完全なコストを考慮することです。構築、保守、組織、依存性。本質的に良い選択も悪い選択もなく、良い分析か悪い分析かだけです。

そして何より：特定の技術のスケーラブルまたは非スケーラブルな性質を当たり前に思わないでください。BlaBlaCar では、ローコードソリューションで数百万件のSMSを送信することに成功しました。しかしこれが機能するためには、プロジェクトがビジネスチームだけでなく技術チーム（アーキテクチャ、テスト）によって支えられなければなりません。そうでなければ、ソリューションがスケールしないリスクがあります。

主なポイント

• BlaBlaCar は重要で差別化された機能を内製し、標準的なプロセスにはサードパーティソリューションを使用しています。
• コスト評価には、開発やライセンスだけでなく、保守と組織的な影響も含まれます。
• 技術的負債は明確なROIが伴えば戦略的なレバーになります。
• SaaSとローコードの統合には、チーム間の真の変更管理とコミュニケーション作業が必要です。