障害対応リードタイムを2ヶ月で 【6.0日 から 0.8日】へ matsuri technologies 株式会社に学ぶ、強い開発組織のつくり方 

取材協力：matsuri technologies 株式会社 開発部 開発課 課長 花田 覚 氏 / SICチーム 大島 朋也 氏

この記事のポイント

• 対応リードタイムを2ヶ月で1/7（6.0日 → 0.8日）に短縮

• 鍵は「自動化より、まず記録を」という意思決定

• 成功を支えた3つの要因：プロダクトオーナー後押し・ワンチーム文化・キーマン異動による危機感

• 改善施策：Notion中心のナレッジ運用 × Datadog MCPを核としたAIスタック

• 示唆：地味な一歩こそが、大きな組織変革を生む

本シリーズ『レジリエンスな企業に学ぶ、強い開発組織のつくり方』では、インシデント対応における属人化や検知の人力依存といった共通課題に対し、先進的に取り組んでいる企業の事例をご紹介していきます。意思決定の論理と組織変革のリアルを通じて、改革に挑む読者の皆様に再現可能な実践知をお届けすることが目的です。

第1回目に取り上げるのは、省人運営の宿泊・短期賃貸プラットフォームを開発・運用する matsuri technologies 株式会社。m2mシリーズを中核に、自社の宿泊事業と外部向け集客プラットフォーム（Sumyca・一時帰国.com 等）の双方を支え、9 年にわたって事業を伸ばし続けてきたテクノロジー企業です。

その開発組織が、わずか2ヶ月という短期間で、問い合わせ対応のリードタイムを6.0日から0.8日と約1/7に短縮。

鍵を握ったのは最新のAIツールでも専任SREチームの新設でもなく、「自動化より、まず記録を」という本質的な意思決定でした。本稿ではmatsuri technologiesの開発を率いる花田氏と、SICチームを率いる大島氏のお2人への取材をもとに、意思決定の論理と組織が変わっていった軌跡をご紹介します。

個の練度から組織の仕組みへ──変革前夜のmatsuri technologies

成果の物語に入る前に、まずはmatsuri technologiesの事業特性と課題を整理していきましょう。

9年にわたって稼働してきたプロダクト群は、AirbnbなどOTAと非同期で連携しています。省人運営という事業特性は、システム不具合が単なるバグでは終わらず「ゲストが今夜、部屋に入れない」という、1つのシステム不具合がサービス提供や顧客満足度にダイレクトに影響する重みと緊張感を与えてきました。さらにmatsuri technologiesのプロダクトは、社外のお客様のみならず、社内の事業部も日常的に使っています。エンジニアにとってのユーザーが、社外と社内の双方にまたがる独特の構造です。

この事業特性のもと、開発組織には大きく2つの課題がありました。

課題①：属人化

matsuri technologiesの開発体制は、もとをたどれば「1人1プロダクト」の担当制から始まりました。事業が拡大するにつれ「さすがにこのままでは、みんな休めないし無理があるよね。そのような背景から徐々にチーム化していきました」と語るのは、TSチームを率いる花田氏です。

チーム化後、ナレッジやドキュメントの整備は着々と進んでいったものの、十分とは言いきれない状況でした。それでも大きなトラブルなく対応できていたのは、個々のエンジニアのスキルが高かったからです。

「実際に、現場では『古くからあるシステムほど、特定のメンバーに確認しないと分からない』というケースも少なくありませんでした」とコメントするのは、SICチームを率いる大島氏。

属人化は、組織の安定性に影響を与える要因です。ましてやmatsuri technologiesのようなサービスとテクノロジーが結びつく会社では、その影響は計り知れません。

課題②：検知の人力依存

もうひとつの構造的課題が、検知の人力依存でした。先述の通り、プロダクト開発者とユーザーである事業部が同じ社内におり、障害の第一報が事業部からSlackで届くことも多くありました。距離の近さは初動の速さを生みますが、裏を返せば「事業部が気づかなければ、検知できない」という危うさを意味していました。

「開発チームの我々が気づけていない障害が、どこかで起きているのではないか」　（花田氏）

そのような不安が常にチームに付きまとっていたと、花田氏はコメントされています。

感じていた課題に対し転機となったのが、キーマンである花田氏の他チームへの異動でした。「このままでは事業が回らなくなる」その認識が、組織全体に強い当事者意識を生むことになります。

変革を生んだ3つの要因

matsuri technologiesのような課題に対し「AIによる自動化」から動こうとする組織は少なくありません。ですがmatsuri technologiesが選んだのは、その逆の基本に立ち返る「記録の仕組みを整える」ことからでした。

2026年に入社した大島氏が抱いていたのは、素朴な動機でした。

「問い合わせが発生したとき『これは何だ？』から始まることが多くありました。どのように対応すべきか、前任者やキーパーソンに確認しなければ自分（達）は分からない。これは問題だと感じていて、『少なくとも、まずはやったことはちゃんと残していこう！』というのが出発点ですね」　（大島氏）

その思いから出発し、指定のフォーマットで情報を取り溜める動きから始まったといいます。

もっとも、この「自然な選択」を支えていた会社のカルチャーがあります。物理オフィスでもバーチャルオフィスでも、困ったらすぐに集まる「ワンテーブル」の文化が以前から存在していました。これを今回、インシデント対応にも適用したのです。

組織的な後押しも、前例のない取り組みを定着させる重要な要素でした。特に大きかったのがプロダクトオーナーの姿勢です。

通常、プロダクトオーナーはビジネスのプレッシャーから「メンバーはそれぞれ自身の業務も並行で進めて」と動かしたくなる立場です。ですがmatsuri technologiesの場合、そうは動きませんでした。

「うちのプロダクトオーナーは、障害調査・対応について1人は本当に見ているだけになってもいいと言ってくれていました。難しいものはチーム全体でぜひ取り組んでほしい、と。プロダクトオーナーによっては、各自担当のタスクは動かしてくれと言う場合もある中で、これはかなり大きな後押しだったと思います」　（大島氏）

いわゆるスウォーミングとよばれる、最優先のタスクにチーム全員で取り組む方式です。

プロダクトオーナーの組織的な後押しや、ワンチームという企業文化、そしてキーマン異動という危機感。この3つの要因が重なって「記録から始める」という地道な取り組みが、チームや組織を変える大きな動きに変わっていきました。

課題解決する運用基盤の組み上げ方──ナレッジ運用とAIスタック

抱えていた課題に対し、大きく二軸の施策に取り組みました。ひとつはナレッジ・ドキュメントの管理、そしてもうひとつはAIツールと自動化です。

Notionを中心としたナレッジ管理・運用

従来、Slack、Googleドキュメント、Notionなど各所に散らばっていた調査結果をひとつのデータベースに集約しました。「この事象に対する調査結果は、このページを見ればわかるという状態を最初に作り出した」と大島氏は説明します。すべての問い合わせをNotionに起票し、概要・対応内容・調査履歴を一元管理しました。

定着のための工夫も具体的です。Notionのテンプレート機能を活用し、雛形を準備。必須項目の入力を促し、フォーマットがぶれないように工夫することで、蓄積されるデータの情報を型化していきました。問い合わせ情報の収集はClaude Coworkのような自立型AIエージェントを一部のチームで先行導入し、「Slack上の問い合わせを収集し、Notionに貯めるところまで自動化。人は介入していない」状態まで進んでいます。

設計の根底にあるのは「同じ問い合わせが来たときに、過去事例を参照してすぐ対応できるようにしたい」という思想です。「将来的には、この情報を使ってAIが勝手に対応してくれたら嬉しい」と大島氏は付け加えています。

AIと自動化のスタック

事業部からの問い合わせに頼っていた障害検知を変えたのは、障害検知・対応のAIパイプラインです。

matsuri technologiesではもともと、システム監視ツールの「Datadog」、自律型AIエージェントの「Devin」、AI開発アシスタントの「Claude Code」「Codex」を個別に活用していましたが、これらを統合し障害検知のパイプラインとして活用できるようになったのが、Datadog MCPの登場です。

Datadog MCPは、Datadog内のログやエラー情報をAIや他のツールに渡す橋渡し機能ですが、この機能を活用したAIパイプラインは次の通りです。

まず、自律型AIエージェントであるDevinが、Datadogのエラーログを定期的に自動でチェック。異常を検知するとGitHubのIssue（開発タスクとして記録される場所）に自動で起票できるように整えました。さらに、AIによる修正提案まで返してくれる仕組みを構築することで、人手を介さず検知から対応案までを一気通貫で進めるパイプラインを組み上げました。

もっとも自動検知はまだ全プロダクトには展開しておらず、本格導入に向けて試行錯誤を続けられるようです。

インシデント発生時の調査には、Claude CodeやCodexが活用されており、Datadog MCPを介してログやAPM情報を直接AIに渡し原因の絞り込みを高速化していく方向とのことです。

こうした実践のアイデアは、毎日午後3時に行われる「相談会」から自然に湧いてくるそうです。最近試したツールや学んだ知見を共有しあう仕組みがあり、新しいツールが業務に組み込まれるサイクルが日常的に回っています。

リードタイムが6.0日から0.8日に。消えたのは着手までの「待ち時間」

問い合わせ対応のリードタイム（起票から完了まで）の中央値は、タスク化・スウォーミング導入直後の2026年2月時点で6.0日。それが3月には1.0日、4月には0.8日にまで短縮されました。わずか2ヶ月で約1/7の水準と劇的な改善です。

数字の裏にあるメカニズムを、花田氏は次のように分析しています。

「今までは『とりあえず起票するだけして、あとでやろう』みたいな伸びがありました。それが今では『起票されたんだから、さっさとやろう』という考えになり、この点が大きな変化だと思います」　（花田氏）

花田氏が、過去の対応時間（着手から完了まで）データを調べ直したところ次のような発見があったそうです。

「実は着手から完了までの対応時間について、以前も今も平均値・中央値とも大して変わりませんでした。以前は『対応時間のばらつき幅が広い』というのが特徴でしたが、今回の改善でこの対応時間のばらつきが消えました。誰が対応するのか曖昧でタスクが滞留しがちな状態がなくなり、安定したリズムで対応が進むようになりましたね」　（花田氏）

過去も現在も対応時間の中央値そのものは約1日。つまり、技術的な処理速度が劇的に変わったわけではなく起票から着手までの待ち時間が改善されたようです。

そして3月の劇的なジャンプを生んだのは、プロダクトオーナーのもうひとつの働きかけが重要でした。

「問い合わせが来たとき『30分とか短い時間でいいから、まず着手し考えてみよう』と、プロダクトオーナーが提案してくれました。解決できれば万々歳ですし、できなくても知識がある人に聞いてみる、と。無理に抱え込みすぎないようにしようというメッセージが、3月の大きな変化につながったと考えます」　（大島氏）

2月の愚直な起票で問い合わせの種類・傾向が可視化され、そして「30分提案」が重なりました。

花田氏の言う「起票されたんだから、さっさとやろう」という意識変化は、単独で生まれたわけではないようです。

• 全問い合わせが、Notion上でタスクとして可視化されたこと

• スウォーミング文化で、チームとして瞬時に取り組む態勢をとれたこと

• プロダクトオーナーの30分提案により、タスク着手のハードルが下がったこと

これらが結びついて初めて、起票→即着手の即時対応の文化が生まれ始めたようです。

　「一人で抱えなくていい」という心理的安全性が浸透し、新しいメンバーも早期に対応に加われるようになったと大島氏はコメントしています。Notionに蓄積された過去事例を参照できる環境が、新人の戦力化を加速させており、定性面での変化も大きいとのことです。

3つの次なる取り組み──横展開と外部連携の深化

2ヶ月で対応リードタイムを1/7に縮めたmatsuri technologiesですが、その視線はすでに次のステージへと向かっています。

1つ目は、改革の横展開です。

今回の取り組みはSICチーム（物件・集客領域）で先行していましたが、今後は非同期な働き方が中心のTSチーム（清掃・チェックイン領域）への展開を考えています。チーム特性の違いを踏まえた翻訳が、次の挑戦となります。

2つ目は、重大度判定の判断軸の確立です。

事業部との距離が近い分、画一的な基準を作るのではなく、プロダクトごとの特性・多様性を尊重した慎重なアプローチが必要です。花田氏は次のようにコメントされています。

深刻度とインパクト、両軸でどのように評価するか、一貫したものはありません。プロダクトのライフサイクルが違う中で、無理に共通化すべきなのか、それとも共通項があるのか。開発や事業展開の中で、徐々に見えてくるものもあるのではないかと考えています」　（花田氏）

言い換えれば判断軸の正解は、机上で設計するのではなく、日々の実践と事業の成長の中から自然と立ち上がってくると、花田氏は捉えています。

3つ目は、外部サービスとの連携の深化です。

OTAなど外部サービスとの連携は自社で完全にコントロールできない領域ですが、matsuri technologiesはそれを「課題」とは捉えていません。

「外部サービスでの障害を外部起因と切り捨てるのではなく、お互いに高め合っていく姿勢が大事だと考えています。弊社が気づいた事象を相手方に共有すれば、相手側にもナレッジが蓄積され自動検知の連携が進みますよね。障害の責任を相手に押し付けるのではなく、業界全体の成熟を促す姿勢が必要だと考えています」　（花田氏）

SIGQインサイト─事例から学ぶ、記録と自動化の仕組みづくり

matsuri technologiesの事例から見えるのは、「記録の仕組み」を先に整えることで自動化の効果が初めて測れるようになる、という普遍的な構造です。

SIGQがVPoE・EM・SREリーダー250名に実施した調査では、インシデント対応改革に取り組んだ組織のうち「改善しなかった」と答えた割合が32.4%にまでのぼりました。動き出しても結果に結びつかない組織が多いなかで、matsuri technologiesのように「記録 → 自動化」の順序で進められた事例は、業界全体への示唆に富みます。

花田氏が挙げた今後の取り組みポイントである

• インシデント重大度の認識がチーム間で統一されていない

• エラーログの自動分類・重大度判定を自動化したい

この2点は、多くの事業会社に共通する課題でもあります。

matsuri technologiesのように「記録」の土台を築いた組織が、次に向き合うのがまさにこの2点です。私たちSIGQも、同じ問題意識からIncident Lakeを設計してきました。

SIGQが提供するIncident Lakeは、過去の対応履歴を学習したAIが重大度を自動判定し、進行中のインシデントに類似事例の解決策をリアルタイムで提示します。Notionなどに蓄積された調査履歴と組み合わせることで、matsuri technologiesが築いてきた「記録」を「次の初動」に自動的に接続できる設計です。

同じ問題意識を持つ読者の皆様へ。matsuri technologies の歩みが教えてくれるのは、改革は最先端ツールではなく「まず記録を残す」という地味な一歩から始まる、ということ。Notionテンプレートひとつ、スウォーミング文化の取り入れ、プロダクトオーナーの「30分でいい」という後押し──どれも、今日から自組織で試せるアクションです。あなたの組織にも、必ず「最初の一歩」があります。

取材・執筆：株式会社BtoBの職人 鴨田 崇司