ＡＩ駆動開発の普及によって開発スピードが劇的に向上した一方で、「リリースが怖い」「深夜のアラートに誰が対応するかわからない」「監視ツールは全部グリーンなのに顧客からの問い合わせが絶えない」——そんな運用上の矛盾に悩む現場が増えています。
そこでＳｕｎ＊は、株式会社はてな・株式会社ハートビーツとの共催で、システムのスピードと信頼性を両立するための設計・監視・運用の全体像を解説するウェビナーを開催しました。
目次
登壇者プロフィール
株式会社Ｓｕｎ Ａｓｔｅｒｉｓｋ Ｃｒｅａｔｉｖｅ ＆ Ｅｎｇｉｎｅｅｒｉｎｇ Ｓｏｌｕｔｉｏｎ Ａｒｃｈｉｔｅｃｔ ／ Ｕｎｉｔ Ｍａｎａｇｅｒ 橋本 武人
都内受託開発スタートアップにてエンジニアとしてキャリアをスタート。レガシー基幹システムのＷｅｂフルリプレイス、ＥＣサイトのスクラッチ開発、不動産エージェントマッチングサービスのリードエンジニアを経験。２０２２年９月にＳｕｎ＊に参画後は、生産管理システム・ＨＲ向けＢｔｏＢ ＳａａＳ・幼児向けアプリ・ナレッジ共有プラットフォームなど、ＰＭ／Ａｒｃｈｉｔｅｃｔ／ＳＥ／ＬｅａｄＥｎｇｉｎｅｅｒ／ＥＭ等の多様な役割でプロジェクト推進と開発組織のマネジメントを担当。ＡＷＳパートナーアライアンス活動やＷｅｌｌ－Ａｒｃｈｉｔｅｃｔｅｄ Ｆｒａｍｅｗｏｒｋの社内推進も担う。
株式会社はてな Ｍａｃｋｅｒｅｌ プロデューサー 渡辺 起
インフラエンジニアとして監視・運用を専門とし、現在はＩｓＩＴ監視ＳａａＳ「Ｍａｃｋｅｒｅｌ」のプロダクトマネージャーを務める。自社サービス「はてなブログ」「はてなブックマーク」等の運用ノウハウをＭａｃｋｅｒｅｌに凝縮し、チームで回せる監視文化の普及に取り組んでいる。
株式会社ハートビーツ クラウド・アクセラレーション事業部ビジネス推進グループ マーケティングチームマネージャー 谷川 隼人
２０２４年ハートビーツ入社。ＥＣや金融商品のマーケティング領域での経験を経て、現在は支援企業へのインタビューや各種ウェビナー登壇を担当。ＩＴインフラ運用２０年超のノウハウを持つハートビーツのサービスを、顧客のリアルな課題に紐付ける役割を担う。
なぜ「後付け運用」は機能しないのか
現場に潜む４つの症状
多くの開発現場で見られる「４つの症状」に心当たりがある方も多いのではないでしょうか。
- 症状①「数字で話せない」： 障害報告が「重かった」「遅かった」で終わり、事業側のＫＰＩと噛み合わず、具体的な打ち手が決まらない。
- 症状②「誰が見るか決まっていない」： 深夜のアラートでＳｌａｃｋが「＃誰か起きてる？」状態になる。一次対応・エスカレーション先が曖昧。
- 症状③「怖くて直せない」： 「触ったら壊れる」領域が増え、リリース判断が政治化。年に数回の大型リリースへと後退していく。
- 症状④「緑なのに売上が落ちる」： 監視画面は全部ＯＫ。でもＣＳには問い合わせが殺到している。技術メトリクスと顧客体験が断絶している。
この４つの症状には、共通の原因が１つあります。それは、運用が後付けになっていることです。
後付け運用と全体設計の違い
機能を作り切ってから監視を足す、障害が起きたらその都度チームで頑張る、ＳＬＯ（サービスレベル目標）とアラートのしきい値が混同されている——これらは「後付け運用」の典型です。この状態では、症状が出てから対処することになり、根本的な解決には至りません。
一方、ＤｅｖＯｐｓは本来、設計・監視・運用を最初から一体で作り込む考え方です。ＳＬＩとＳＬＯを事業ＫＰＩと接続し、運用の責任と観測点を設計段階で埋め込み、変更容易性と観測可能性を最初から仕込む——これにより、開発スピードと信頼を両立する設計を実現することができます。
止まらない運用設計の４つの土台（Ｓｕｎ Ａｓｔｅｒｉｓｋ セッション）
ＤｅｖＯｐｓ全体設計に必要な土台づくりのた目には４つのポイントがあります。どれか１つでも欠けると、スピードと信頼のバランスが崩れることになります。
土台１：共通言語——事業と開発が同じ数字で話す
「重かった」「遅かった」では動けない。事業と開発が同じ数字で語れるようにすることが、共通言語の本質です。
具体的なアプローチは、事業ＫＰＩ → プロダクトＫＰＩ → 技術メトリクスの３層構造で指標を設計することです。
- 事業ＫＰＩ（例：注文完了率 ≥ ９９．９％／月）
- プロダクトＫＰＩ（例：決済成功率、セッション完走率）
- 技術メトリクス（例：決済ＡＰＩ ｐ９９ ≤ ８００ｍｓ、ＤＢエラー率）
この３層を文書化し、事業側・ＣＳ含む全ステークホルダーで合意することが重要です。そして障害報告も「目標をどれだけ消費したか（Ｅｒｒｏｒ Ｂｕｄｇｅｔ）」で書く習慣をつけることで、打ち手の優先順位が自然と決まるようになります。
土台２：責任境界——誰がどの時間帯に何を見るかを宣言する
深夜のアラートが鳴ったとき、「これは基盤チーム？アプリチーム？」を毎回会議で決めている——そんな状態を防ぐために、サービス × 担当チーム × 時間帯の一覧表を設計書に明記し、運用を開始することが重要です。
具体例として、ＥＣプラットフォームの担当マトリクスを提示します。
- 平日日中（９〜１８時）： 各チームが対応
- 夜間（１８〜９時）： 当番制（１５〜３０分以内に反応）
- 休日： 重要度に応じて当番対応ｏｒ翌営業日に振り分け
- エスカレーション： １５分 → 二次対応 → ３０分 → 責任者 → ６０分 → 経営層
２４／３６５有人体制が前提でない場合は、夜間は翌営業日対応とルールを明文化することも重要です。
土台３：変更容易性——分ける・小さく変える・すぐ戻せる
「怖くて直せない」状態は、リリースに問題があるのではなく、設計の問題です。この症状を解消する３点セットが以下です。
- 分ける： 機能の境界を明確にし、独立に変えられる形にする（マイクロサービスでも、モノリス内のモジュール分割でも可）
- 小さく変える： Ｔｅｒｒａｆｏｒｍ／ＩａＣでインフラをコード管理、ＧｉｔＨｕｂ Ａｃｔｉｏｎｓ／ＣＩ－ＣＤで手作業をゼロにする
- すぐ戻せる： Ｆｅａｔｕｒｅ ＦｌａｇやＢｌｕｅ－Ｇｒｅｅｎデプロイメントで段階リリース。エラーが増えたら数十秒で自動ロールバック
具体的な設定例として、「１％ → １０％ → １００％」の段階的リリースを紹介。先行リリースでエラーが増えたら自動でロールバックする仕組みを最初から組み込むことで、リリースの心理的コストを大幅に下げることができます。
土台４：観測可能性——事業と技術を同じ画面で見る
「監視は全部グリーンなのに売上が落ちる」問題の原因は、技術の数字だけを見ているからです。
解決策は、事業の数字（注文数、ＣＶＲ、離脱率）と技術の数字（応答時間、エラー率、リソース）を同じダッシュボードの上下２段に並べて表示すること。これにより、「事業の数字が落ちた瞬間に、下段で原因を辿れる」二層連動の監視体制が実現します。
アラートは「目標をどれだけ消費したか（Ｅｒｒｏｒ Ｂｕｄｇｅｔの消費ペース）」で設定するのが原則です。急速な消費 → 即通知、緩やかな消費 → まとめ通知という設計にすることで、ノイズの多いアラートから脱却できます。
改善は段階的に——３０／９０／１８０日ロードマップ
これらは一度に実装しようとするのではなく、３フェーズでの段階的な改善が推奨されます。
- Ｐｈａｓｅ １（〜３０日）可視化： 事業の数字に直結する指標を３つ決めて測る。デプロイ頻度・復旧時間など開発側の数字も出す
- Ｐｈａｓｅ ２（３０〜９０日）仕組み化： 目標値を事業側と合意。担当マトリクスを設計書に追加。ＣＩ／ＣＤ・段階リリースを整備
- Ｐｈａｓｅ ３（９０〜１８０日）習慣化： 障害振り返りを開発に反映。運用指標を経営層と定期共有。信頼性改善をチーム目標に組み込む
「Ｐｈａｓｅ １を飛ばして仕組み化に進むと、効いているかわからず改善が止まる」という指摘は、現場に刺さるポイントでした。
障害対応を属人化させない監視設計（はてなセッション）
「完璧な監視」を最初から作ろうとしないこと
監視設計でよく見られるアンチパターンとして、詳細な監視項目としきい値を最初から全部詰めようとすることが挙げられます。完璧な監視を設計している間にも開発は進み、完成するころには設定が古くなっているというジレンマが生じます。
逆に見切り発車してしまうと、「監視項目は正常なのに壊れたところに気づけない」という別の問題が発生します。これはビジネス機会の損失に直結します。
小さく始めて育てる
そこで有用なのが、「走りながら育てる」前提の監視設計です。
最初に確保すべき最小限のことは２点です。
- 情報は取得しておく： 今使っているクラウドのモニタリングや監視ツールで、一通りの情報はまず取得しておく。計測できないものは改善できない。
- ユーザー視点の監視を優先する： ＣＰＵやメモリの詳細しきい値より、「実際にブラウザから画面にアクセスできているか」「ビジネス上重要な機能が落ちていないか」を先に監視する。
ＣＰＵが振り切れても、ユーザーが使う機能が損なわれているかはそれだけではわかりません。ビジネス上、ここが落ちたらまずいという場所から始めることで、緊急度の判断がずっとしやすくなります。
属人化を止める文化
監視が個人の中に閉じてしまう最大の原因は、「障害はミスをした人の責任」という文化です。これが生まれると、課題の発見と解決が個人に閉じ、同じ問題が繰り返し起こります。
これを防ぐための文化として、以下のようなポイントが考えられます。
- 人のせいにしない： 犯人探しをしてもシステムは改善しない。仕組みで解決する思考に切り替える
- 失敗から学ぶ： なぜ起きたか・どう改善するかを振り返る（ポストモーテム）
- データで語る： 定性的な「気をつけます」ではなく、数字（ＳＬＩ／ＳＬＯ）を見てどう仕組みを変えるかで議論する
ＳＬＯを１００％にすると、なぜ失敗したんだという詰め方になります。クラウドでも機械はいつか壊れます。９９．９％などの目標値を定めることで、仕組みの改善の話がしやすくなります。
オブザーバビリティの本質
オブザーバビリティ（観測可能性）とは、新しいツールを入れることではありません。その本質は、「システムを変えずに、中で何が起きているかを知ることができる状態」を作ることです。
トラブルやエラーの解決が長引いた時には、「このシステムはオブザーバビリティが低いのではないか」という視点で考えること。そして特定の人の職人的な勘ではなく、データの探索で誰でも原因を辿れる状態に変えていくことが目標です。
始め方も「今取れているデータをよく見て、不足しているものを振り返りながら作り込んでいく」という小さくから始めるアプローチが推奨されました。
止まった時に備える２４×３６５体制（ハートビーツ セッション）
運用コストの現実
ＩＩＪの調査データから、システム運用監視は、部長クラスの上位レイヤーにとっても業務時間の１０％前後を占めているという現状が読み取れます。本来はＩＴ戦略策定や既存システムのリプレイスにリソースを使うべき人が、日常の運用監視に追われている——これが多くの企業の実態です。
加えて、ＩＴ人材不足の深刻化と、２０２６年度に運用開始が予定されているサプライチェーン全体のセキュリティ水準を引き上げる制度（脆弱性管理体制・侵入リスク低減・迅速な異常検知が要件）により、少人数でも安定した運用体制を構築することの重要性はさらに高まっているのです。
止まる前に整えるべき「３つの見える化」
障害に備えるための事前準備として３つの見える化が効果的です。
①潜在リスクの見える化：属人化を解消する
「インフラ担当者が退職することになったが、中身がわかる人がいない」は典型的な相談内容です。まず取り組むべきは、ナレッジ共有の文化を作ることです。完璧なドキュメントを作ることより、「まずは何らかの形で残していく」習慣を根付かせることが先決です。
②障害対応の見える化：均一化で負荷を分散する
障害対応を均一化することで、属人化に依存せず少人数でも一定のクオリティを維持できます。対応ログを蓄積することで、ＡＩが原因の仮説立案やドキュメント化を支援できるようになってきています。ただし、自社環境のユニークな部分に対しては人の判断が不可欠です。
③時間外対応の見える化：アラートを整理する
夜間・休日対応の大きな問題の一つが「オオカミアラート状態」です。不要なアラートや不適切なしきい値が放置されると、どのアラートが本当に重要かの判断が困難になります。定期的な見直しと精査が必要です。また、どこまで復旧させるかを社内で合意形成しておくことで、夜間対応の範囲を事前に絞り込むことができます。
内製ｖｓ外注——２４×３６５体制の判断軸
２４×３６５体制を作る際の内製・外注の判断については、２つの観点があります。
コスト・クオリティの比較
週休２日制で２４×３６５監視体制を内製で組むには最低５名（理想は６〜８名）が必要です。インフラエンジニアの平均年収は７００万円とされており、２名確保するだけで固定費は年間１，４００万円以上になります。加えて、未経験者が１人で対応できるレベルになるまでに６〜１２ヶ月の育成期間が必要です。
エンジニアリソースの有効活用
外注の最大のメリットは、突発的な障害対応や日常運用にかかるエンジニアの稼働を減らし、ＩＴ戦略や機能開発など新しい価値を生み出す業務にリソースを集中できることです。
自社のエンジニアリソースをどこにかけるか、自社でやるにはどこがハードルになるかを可視化の中で発見し、その領域を補填するパートナーを選ぶという選択肢も検討する必要があります。
まとめ
開発スピードを高めながらシステムを止めないためには、設計・監視・運用の３つを後付けで縫い合わせるのではなく、最初から一体として設計することが不可欠です。Ｓｕｎ＊が提唱する「共通言語・責任境界・変更容易性・観測可能性」の４つの土台を設計段階で仕込み、はてなが語る「小さく始めて育てる」監視文化を根付かせ、ハートビーツが示す「３つの見える化」で２４×３６５体制の基盤を整える——この３社のアプローチが、スピードと信頼性の両立を実現します。
Ｓｕｎ＊では、２，０００名を超えるエンジニア・クリエイターが在籍し、０から１００のフェーズまで一気通貫で事業開発を支援しています。ＤｅｖＯｐｓ推進・運用設計・システム信頼性向上にお悩みの際は、ぜひＳｕｎ＊までお気軽にご相談ください。
システム設計・運用改善のご相談はＳｕｎ＊まで