パブリックに構築する：自社プロダクトを使うことがなぜ私たちを強くするか
3 min read
Last edited:
Akanksha（Head of Engineering India、DEVU-1）とAhmed（CTO）の対話 — 250人のエンジニアが自分たちが出荷するプロダクト上で生活するとどうなるか。
学んだこと
250人のエンジニアが自分たちが構築したプロダクトを使うと、予想外のことが起こります。問題は四半期レビューではなく、月曜の朝に表面化します。数百のチケットでは問題なく動いていたクラスタリングアルゴリズムが、サポートが数千を扱うと壊れる。営業が気に入っていた検索が、エンジニアリングのニーズには答えられない。
DevRevは自らをCustomer Zeroと呼んでいます。CTOからサポートチームまで全員が、出荷するのと同じプラットフォーム上で動いています。サンドボックスではありません。本番環境です。それが、構築方法から修正方法まですべてを変えます。
Customer Zero、User One
DevRevは初日から自社のアルファ環境でした。エンジニアリング、営業、サポート — すべてのチームが日常的にDevRev上で業務を行っています。サンドボックスではありません。本番環境です。
Akankshaは内部識別子DEVU-1を持っています。User One。プラットフォームに最初にオンボードした人物です。そしてDevRevという組織がCustomer Zero — 800人、5年の歴史、すべての部門が同じシステムでワークフローを実行しています。
会社を構築する時、自分のプロダクトを実際に使える — プロダクト上で生活できる — なら、すべてがより速く明らかになります”
CTOとしてのAhmedの視点から見ると、これは単なる利便性ではありません。自社のインフラストラクチャ上で大規模に運用することで、ステージング環境では決して明らかにならない障害モードが表面化します。自社の認証システムが様々なロールを持つ800人の従業員を処理しなければならない時、クラスタリングアルゴリズムが実際のチケット量で詰まる時、顧客がそれを目にする前に修正できます。
ドッグフーディングが仕様では見えないものを明らかにする時
DevRevのカスタマイゼーションエンジンが存在するのは、社内チームがストックオブジェクトとして存在しないオブジェクトタイプを必要としたからです。それを構築し、使用し、検索がカスタムオブジェクトをファーストクラスの市民として扱うことを要求し、アナリティクスがそれらをまたいで機能することを主張しました。顧客に届いた時には、構築した人々によるプレッシャーテスト済みでした。
同じことがDevRevの認証プラットフォームであるMFZでも起きました。カスタムオブジェクトを含め、見たことのないオブジェクトに対してフィールドレベルのアクセス制御でポリシーを適用する必要がありました。組織が数人から800人に成長するにつれ、外部ツールがプラットフォームに接続され、それらのシステムからのアクセスプロビジョンを尊重する必要がありました。認証システムは、エンタープライズ顧客が到着する前にエンタープライズ対応が完了していました。
境界でのイノベーション
クラスタリング：4年前、DB-scanは数百の課題をクラスタリングするエンジニアリングチームには完璧に機能していました。次にサポートが数千のチケットで試しました — そして壊れました。その後：階層型DB-scan、次にLLMベースの分類、そしてマルチティアのk-meansへの再設計。1つの部門だけがプロダクトを使っていたなら、これは一切起こらなかったでしょう。
検索 → Text-to-SQL：検索は営業には最適でした — ポイントオブジェクト、グラフナビゲーション。しかしEPDチームにはコレクションの回答が必要でした。「スプリントのサマリーは？」これは集計の質問であり、検索の質問ではありません。この洞察がComputer — DevRevのTeam Intelligenceプラットフォーム — の自然言語SQL変換レイヤーの開発につながり、現在プラットフォーム全体のダッシュボードとアナリティクスを支えています。
検索だけでは十分ではありません — text-to-SQLと、コレクションのオブジェクトを横断してその質問に答える能力が必要です”
リアルタイムのフィードバックループとしてのOps
DevRevのマイクロサービスはArgo CD、CircleCI、その他のCI/CDツールに接続されています — すべてプラットフォームに流れ込みます。エンジニアリングリーダーは自然言語でComputerに問い合わせ、リアルタイムの可視性を得ます。
ライブデモでは、AkankshaがJanus（IDおよびアクセス管理）のテスト状況についてComputerに質問しました。目標を下回るパス率を報告し、低下したQAパーセンテージを特定し、最も不安定なテストスイートを表面化させました。その場で課題を作成し、適切なエンジニアにアサインし、正しいプロダクトをタグ付けしました — すべて数分で。
通常は大規模なrev-opsチームがダッシュボードを構築し、ダッシュボードができた頃には情報はすでに古くなっています。これはリアルタイムです”
Ahmedは、これがエンジニアリングリーダーの運営方法を変えると指摘しました。エスカレーションや四半期レビューを待つ代わりに、コンテキストがまだ新鮮なうちに問題を見て修正できます。
私の考えでは、それはアクショナブルなメモリです。情報を実際にエンリッチして、行われている作業、プロダクト、それが提供している顧客を理解し、さらに誰が取り組んでいるかも理解できる能力です”
スプリント計画の中の顧客
なぜ営業、サポート、エンジニアリングが同じプロダクトを使うべきなのか？顧客シグナルがスプリント計画に表示された時、答えは明白になりました — 作業アイテムを顧客チケット、商談、アップセルに接続することで。
顧客を中心に据え続けることが、DevRevでは常に答えでした。なぜそれをやりたいのか？特定の顧客がそれを必要としていることを知っているからです”
すべてのデータがComputerのメモリに存在するため、「自分の作業のどれくらいが顧客の需要で正当化されているか？」と質問して実際の答えを得られます — そしてそれを組織全体が追跡するダッシュボードに変換できます。
個人のためのツール、チームのためのツール
Team Intelligenceツールの中には個人を助けるものもあります。ミーティングの要約、プロジェクトステータスの更新、1時間かけて調べるはずだった質問への回答。これは便利です。
しかし、より大きな変化は、同じツールが共有されるようになった時に起こります。1人のエンジニアが構築したパイプラインヘルスのスキルがリーダーシップチーム全体に広がる時。顧客コールからのインサイトがプロダクトとサポートに同時に見える時。
DevRevはかつて各ロール向けの「Day in the Life」ガイドを維持していました。パターンは予測可能でした。一部の人がすぐに採用し、大多数が遅れ、数人は追いつけない。Team Intelligenceはその分布を変えます。トップの人は依然として優れていますが、今や全員が同じベースラインのツーリングを持っています。四半期レビューではなく、毎日リマインダーが届きます。
私たちはそれをTeam Intelligenceと呼んでいます。それは会社に存在するノウハウですが、必ずしも公平に分配されていません。私たちが目指しているのは、知識が偉大な平等化装置であり続けることで、全員を引き上げることです”
この記事はDevRevのAhmed（CTO）とAkanksha（Head of Engineering, India）によるLinkedIn Liveの対話に基づいています。私たちが裏側で何を構築しているかを見るには、[Discord](https://discord.gg/devrev)に参加してください。
