Rootly、障害対応をSlackの通知からreliabilityの共有基盤へ変えた転換

自社の障害対応から始まった

Rootlyは2020年、JJ TangとQuentin Rousseauによって始まった。

創業の出発点は、創業者自身が経験したincident responseのfrustrationだった。

JJ Tangは「I started Rootly in 2020 born from our own frustration」と説明している。出典

この出発点が、Rootlyを単なるalert通知ではなく、障害発生後の共同作業を扱うproductへ向かわせた。出典

資金調達で仮説を広げる

2021年、RootlyはXYZ Venture Capital、8VC、Y Combinatorなどから$3.2Mのseed fundingを調達した。出典

資金は、incidentの司令塔をSlackの外へ広げるための製品開発と市場開拓に使える余地を作った。

機能ではなく運用面へ

Rootlyはworkflow、on-call、status page、integrationsを束ね、障害対応の前後を一つの流れとして扱うようになった。出典

顧客ページやG2関連の発信は、単発の機能よりもチーム全体のreliability運用を前面に出している。出典

連携と買収で範囲を拡張する

その後はThinkHiveの買収やCortexとの連携を発表し、incident managementをengineering platformの運用面へ広げている。出典 出典

今のRootly

Rootlyの軌跡は、社内の痛みから始めた小さなworkflowを、既存ツールとの接続と運用データの蓄積によって、reliabilityの共有基盤へ変える道のりだ。

公開されていないARRや顧客数を推測しないことが、現在地を読むうえで重要になる。

障害対応では、通知を受けた人、runbookを実行する人、顧客へ説明する人が別々のツールを使う。

この分断が復旧時間とポストモーテムの質を下げる。

RootlyはSlack連携、workflow、on-call、status pageを一つの運用面にまとめることで、既存の開発・通信環境を捨てずに導入できる。出典

seed fundingの発表で、創業の出発点は自社のincident responseへのfrustrationだったと説明されている。

個人の通知アプリではなく、複数チームの共同作業を対象にしたことがPMFの核になった。出典

最大の障壁は、障害対応の実データとworkflowが組織の運用に埋め込まれること。

integrationsの数だけでなく、誰がいつ何を判断したかの履歴がretrospectiveと改善に接続される点がswitching costになる。出典

ネットワーク効果は弱〜中程度。

利用企業内では開発、SRE、サポート、経営が同じincident記録を参照するため部門内の参加者が増えるほど価値は上がるが、企業間の直接ネットワークではない。出典

主対象は、複数の開発・SREチームを抱え、障害対応の標準化が必要な中堅〜大企業。

Slack、PagerDuty系のon-call、status page、runbookを既に運用している組織に合う。出典

逆に、障害件数が少なく単純な通知だけで足りる小規模チームには過剰になりやすい。

第一に、Slackや既存の開発ツールを入口にして導入摩擦を下げたこと。出典

第二に、incidentの開始からretrospectiveまでをworkflowとして定義し、個別機能ではなく運用習慣を売ったこと。出典

第三に、顧客事例、G2評価、パートナー連携を重ね、reliabilityの専門領域で信頼を積み上げたこと。出典

公開情報だけではARR、顧客数、従業員数を確認できず、成長規模を断定できない。

pricingも個別相談型で、導入前の比較に必要な価格透明性は弱い。出典

またincident managementは既存のPagerDuty、Opsgenie、Jira Service Managementなどと競合する。

通知だけを求める小規模チームには機能過多になり得る。

買収・連携による範囲拡張が、製品の焦点を薄めるリスクも残る。出典

Slackを中心に既存ツールと接続し、チームが障害対応を実際に行う場所へ入るproduct-ledな導線を作る。

一方、securityやenterprise運用ではsales-ledな検討が必要になるため、content、customer stories、partnersを併用する複線型が自然だ。出典

seed funding後はplatformの機能拡張と買収・連携で対象範囲を広げている。

単機能のalertingではなく、reliabilityのoperating systemとして予算を取りに行く戦略だ。出典

主要チャネル: content, community, partners, productLed, salesLed

新しい運用SaaSは、既存ツールを全面置換するより、チームがすでに集まる場所にworkflowを重ねる方が導入しやすい。

Rootlyのintegrationsは機能一覧ではなく、既存のincident responseを捨てずに改善するための入口として働く。出典

一方で、カテゴリが成熟するほど、価格、導入効果、既存製品との差分を透明に説明する必要がある。

個別相談型の価格でも、比較可能な成果指標を用意することが重要だ。

日本企業では、障害対応が開発部門だけで閉じず、CS、広報、経営への連絡を含む。

Rootly型の価値を移植するなら、SlackだけでなくTeams、メール、社内ポータル、顧客向けstatus pageを含む連絡経路を日本の組織階層に合わせて設計する必要がある。

導入時は「英語のincident管理ツール」ではなく、ポストモーテムを責任追及から学習に変える仕組みとして説明すると、SRE以外にも広げやすい。