

導入事例インタビュー
2025.07.18
株式会社ビットキー
ビットキーは、2018年に設立されたスタートアップ企業で、「つなげよう。人は、もっと自由になれる。」というミッション・ビジョンを掲げています。アプリ/SaaS/プラットフォームからデバイスの開発まで、横断的にデジタル技術を用いて事業を進めています。
自社の認証認可技術、ハードウェアデバイス、ソフトウェアプロダクトを用いて、世の中の様々なサービスや事業者、およびデジタル世界と物理世界をつなぎながら、「暮らす」「働く」といった日常生活において、例えば、「顔をかざすだけでドアの鍵が開いたり、会議室を予約できる」、といった体験を生み出しています。

Product Insight 高石 圭佑様
情報のサイロ化が重要課題になっていた
Waroom導入前のインシデント対応状況と課題を教えてください。
ビットキーはハードウェアデバイスとそれを操作するソフトウェアを提供しています。ソフトウェアだけでなくハードウェアの軽微な不具合まで含めると、プロダクト全体のインシデント内容は多岐にわたります。
当時、社内には一定の対応フローはあったものの、インシデント対応を自動化・省力化したり、情報の共有を効率的に行う仕組みはありませんでした。
また、情報のサイロ化に起因して経営層やマネジメント層と現場の間で課題認識のギャップが生じており、必要な対応が後手に回ることがありました。これらは致命的ではないものの、将来的に顧客との信頼関係を損なう可能性がある問題の一端でした。
Waroom導入の決め手は何だったのでしょうか。
SRE NEXT 2023で、VPoEの佐藤がTopotalさんのブースでWaroomのデモをみたことがきっかけでした。当時は、インシデント対応用の内製ツールのメンテナンスの問題も抱えていたので、SaaSとして提供されるWaroomは魅力的でした。
デモで見せていただいた「Slackの情報を自動的に要約する」機能と(ユーザー数ベースではなく)会社一律の料金体系に魅力を感じ、Waroomのトライアルを決めました。
Waroomの正式リリース直後からトライアルを始めましたが、すでに整備されている自社のインシデントの対応フローに合わせるには、当初のWaroomの機能が足りない状況でした。例えば、プライベートチャンネルの対応やインシデント対応チャンネルの命名規則の設定などです。
これらの機能がなければ導入は難しいことをお伝えしたところ、私たちの要望に真摯に向き合い、迅速に機能開発を進めてくださいました。ユーザーとWaroomの開発者の距離が近く、現場の声をプロダクトに反映してくださるその姿勢が、導入を決断する際の後押しとなりました。
情報共有がスムーズに!エンジニア以外も巻き込んだインシデント対応を実現できた
実際に導入して変わったことはありますか
「専用Slackチャンネルの作成とサービスごとの自動招待機能」が情報のサイロ化の解消に役立ちました。
Waroom導入前は、特定のSlackチャンネルのスレッドを利用してインシデント対応を行っており、情報共有先のメンバー・チームに対して毎回メンションをする必要がありました。このフローだと、メンションの心理的なハードルや単純なメンション漏れが起こることがあり共有に失敗しやすい状況でした。また、一つのスレッドの中で複数の情報のやり取りがなされ、コミュニケーションが複雑化することも課題となっていました。
Waroomを導入をすると、インシデントごとにチャンネルが自動で立ち上がり必要なメンバーを自動招待できます。ビットキーでは、緊急度の高いサービスのインシデントの場合は経営層も含めてチャンネルへ招待するようにしました。その結果、重大なインシデント情報を確実に共有するフローを確立することができました。
対応フローの仕組み化は、属人化の解消に役立ちましたか?
はい、直近で弊社のworkhub事業内で力を入れているビルのモニタリングにおいて、Waroomの「Runbook機能」を有効活用することによって従来特定のエンジニアが行っていた一次対応(初手の調査対応)をカスタマーサポートチームへ移譲することができました。この件は、弊社の三河内がSRE NEXT 2025で発表した内容の一部でもあります。
この運用を導入する前は、SLOアラートが発生した場合SREまたは開発エンジニアが一次対応を行っていました。ビルモニタリング運用における一次対応では、はじめに物理的な故障や誤動作が起きていないかを現地確認したりお客様に確認いただく場合が多いのですが、この対応は必ずしもエンジニアが行う必要はありません。
Waroomは、Slackチャンネル上に対応手順(Runbook)を表示する機能があります。一次対応の手順をドキュメント化した上で本機能を利用することで、インシデント対応に慣れていないカスタマーサポートのメンバーでも一次対応を行う仕組みをつくることができ、一次対応に手を取られていたエンジニアの業務を移譲することができました。
ビルモニタリングで成功事例ができたので、今後はこの仕組みを他のサービスにも横展開していく予定です。
一連の改善によって現場に変化は起きましたか?
改善に取り組む前までは、SLOアラートが発生しても一部の限られた開発メンバーのみで対策に取り組んでいたのですが、今回の仕組み化をきっかけに、「カスタマーサクセス組織」と「複数人のエンジニア」が連動して対策に取り組める様になりました。結果として「障害発生時の切り分け方法」などについての知見を蓄積する現場のモチベーションも向上しています。
オブザーバビリティの改善のインセンティブが高まったせいか、以前よりもモニタリングを細かく設定したり、ログの整備(余分なエラーを減らす、手がかりになるログを出力するなど)が活発に行われるようになったと思います。ハードウェア観点においても「センサから取得できる値をデバイス内部のログに記録しておくことで、できる限り現地の環境情報を入手できるようにする」という動きも少しずつ活発になってきています。
Waroom導入をきっかけに、組織全体でインシデント対応に備えるための活動が増え、フィードバックループが回るようになってきた実感があります。
最後にWaroomにメッセージをお願いします。
先日、AIが自動的に切り分けや巡回を行うデモをみせていただきました。MCPを活用した次世代のインシデント対応体験には期待しています!
Waroomの好きなところは、プロダクトミッション「つらいインシデント対応をなくす」を掲げ、インシデント対応にポジティブに向き合う仕組みを作ろうとしているところです。この点は私自身の考え方やモチベーションに通ずるところがあり、非常に共感しています。
今後とも、引き続きよろしくお願いいたします!
本日はありがとうございました。