中嶋悟
名前：中嶋 悟（なかじま さとる） ニックネーム：サトルン 年齢：28歳 性別：男性 職業：会社員（IT系メーカー・マーケティング部門） 通勤場所：東京都千代田区・本社オフィス 通勤時間：片道約45分（電車＋徒歩） 居住地：東京都杉並区・阿佐ヶ谷の1LDKマンション 出身地：神奈川県横浜市 身長：175cm 血液型：A型 誕生日：1997年5月12日 趣味：比較記事を書くこと、カメラ散歩、ガジェット収集、カフェ巡り、映画鑑賞（特に洋画）、料理（最近はスパイスカレー作りにハマり中） 性格：分析好き・好奇心旺盛・マイペース・几帳面だけど時々おおざっぱ・物事をとことん調べたくなるタイプ 1日（平日）のタイムスケジュール 6:30 起床。まずはコーヒーを淹れながらニュースとSNSチェック 7:00 朝食（自作のオートミールorトースト）、ブログの下書きや記事ネタ整理 8:00 出勤準備 8:30 電車で通勤（この間にポッドキャストやオーディオブックでインプット） 9:15 出社。午前は資料作成やメール返信 12:00 ランチはオフィス近くの定食屋かカフェ 13:00 午後は会議やマーケティング企画立案、データ分析 18:00 退社 19:00 帰宅途中にスーパー寄って買い物 19:30 夕食＆YouTubeやNetflixでリラックスタイム 21:00 ブログ執筆や写真編集、次の記事の構成作成 23:00 読書（比較記事のネタ探しも兼ねる） 23:45 就寝準備 24:00 就寝
QAとSREの違いを理解するための基礎ガイド
このガイドは、QAとSREという言葉を仕事の現場でよく耳にする人のために、両者の役割や違いをわかりやすく整理するものです。QAはQuality Assuranceの略で品質保証の役割を担います。製品が仕様どおり機能するかを検証する作業を中心に、テスト計画を作成し、ケースを設計し、実際に動作を確認してバグを見つけ出し、開発チームへ適切な報告を行います。このプロセスは“正しく機能することを証明する”ことにフォーカスしています。
一方、SREはSite Reliability Engineeringの略でサイトの信頼性を守る運用側の考え方です。SREの目的は、システムを常に安定して動かすこと、可用性を高めること、遅延を小さく保つこと、障害が起きても迅速に復旧できる状態を整えることです。具体的には監視の仕組みの設計、自動化の推進、エラーバジェットの概念を使った運用の意思決定、障害時の手順書の整備などを行います。これらは共通して「品質を守る」という大きな目的を持っていますが、日常の活動の焦点が異なるのが大きな違いです。
QAは機能の正しさを検証する専門家であり、SREは運用の信頼性を守る専門家です。QAが新機能の検証や品質の低下を早期に発見する役割を担うのに対し、SREはシステムが長時間高い信頼性を維持できるよう、インフラや自動化の仕組みを支える役割を果たします。結果的に、両者はリリースの前と後で協力することで、商品やサービスが「使いやすく」、しかも「安定して動く」状態を実現します。
この章を読んで得られる要点は、まず両者の目的を分けて理解し、次にワークフローのどこで協力するかを具体的に考えることです。QAはテスト計画の設計とバグ検出、SREは監視設計と障害対応の自動化を担当すると覚えておくと、混乱を減らせます。
QAとは何か？
QAはQuality Assuranceの略で、日本語では品質保証と呼ばれます。主な仕事は、製品が仕様どおり動作するかを検証することです。具体的には、開発者が作った機能が期待通りの動きをするかをテスト計画に基づく検証、手動テストと自動化テストを組み合わせた実行、見つかった不具合の再現手順と再現性の記録、報告書の作成と優先度の設定、修正後の再検証と回帰テスト、品質リスクの分析と品質基準の策定、リリース後のフォローアップなど、多岐にわたります。QAは「正しい機能が作られているか」を確かめるため、仕様理解とテストケースの粒度がとても重要です。
また、リリースの前だけでなく、開発サイクルの早い段階から関与することが求められます。仕様変更があればすぐにテストケースを更新し、開発の初期段階で潜在的な品質問題を浮き彫りにします。これは顧客体験の向上にも直結します。
現場では、QAと開発者の対話が非常に大切です。問題を単に「なおせ」と伝えるのではなく、どのような条件下で再現するのか、どのような影響範囲かを分かりやすく共有します。これにより、修正が遅れず、リリーススケジュールを守ることができます。
SREとは何か？
SREはSite Reliability Engineeringの略で、日本語にすると「信頼性のエンジニアリング」です。運用と開発の境界線を越えて、システムを常に安定して動かすための設計と自動化を担当します。具体的には監視指標の設計、アラートの適切な閾値設定、インシデント対応の手順作成、障害時の復旧自動化、デプロイの安全性を高める Canaryデプロイやブルーグリーンデプロイの運用、SLOとエラーバジェットの概念を用いた意思決定、キャパシティプランニング、外部依存の影響分析、災害対策とバックアップの整備などを含みます。SREは「システムの信頼性を数値で語る」ことを重視します。
この考え方の核心は、失敗を避けることよりも「失敗してもすばやく回復できる状態を作る」ことです。そのためには、観測可能性を高める監視基盤と自動化された運用プロセスが不可欠です。SREはまた、エラーバジェットという考え方を用いて、安定性と新機能のリリース速度のバランスをチームで決めます。
現場のSREは、単に「障害を直す人」ではなく、サービス全体を見渡し、将来の障害を減らすための設計を行います。開発者と協力し、コードの信頼性を高めるストラテジーを立て、運用を自動化して運用コストを抑える役割も果たします。
実務での違いと協力の仕方
現場での違いは、日常業務の焦点と指標の違いに表れます。QAはテストケースの網羅性、バグの再現性と優先度、リグレッションの可用性を重視します。一方、SREは可用性の指標、SLO、エラーバジェット、障害時の早期復旧、監視の精度、運用の自動化を重視します。両者は、リリース前の品質検証とリリース後のシステム信頼性維持という2つの軸で補完し合います。協力の現場では、開発の初期段階からQAとSREが協力してテスト設計と監視設計を同時に進めることが有効です。例えば、機能追加の段階でSREがSLOに関する要件を共有し、QAがその要件を検証計画に組み込むことで、品質と信頼性を同時に高めます。また、障害の波及範囲を理解するための事例ベースの演習を定期的に行い、復旧手順の実効性を検証します。現場では、共通の用語と共通の指標を使うことが大切です。SREの監視指標とQAの品質指標を統合することで、改善の優先順位が見えやすくなります。最後に重要なのは、責任の分担を明確にすることです。誰がどのフェーズで何を決定するのかを事前に決めておくと、混乱を避けられます。
今日は友達とカフェでSREの話をしていた。友人が『SREって難しそう』と言うと、私はこう返した。SREは“信頼性を守るための仕組みづくり”のことだと説明した。監視や自動化、障害時の手順、そしてデプロイの安全性を高める工夫を積み重ねる作業は、日常の学校生活の計画と似ている。予定外のトラブルが起きても、誰がどう動くか、どう復旧するかを決めておけば混乱を減らせる。QAとSREは別の道を歩むけれど、最終的には同じゴールを目指している――それは「使う人を失敗させない」世界を作ることだ。
ITの人気記事
