システムの運用保守では、複数のチームで連携する場面が多くあります。その際に「誰が何を担当するのか」を明確にするツールが『RACIマトリクス』です。
この記事では、筆者が学んだRACIマトリクスの基本と、具体的な運用例について簡潔に解説します。
RACIマトリクスの基本
RACI（レイシー）とは、タスクにおける役割を以下の4つのタイプで定義する考え方です。
-
R (Responsible): 実行責任者
- タスクを実際に担当し、実行します
-
A (Accountable): 説明責任者
- タスクの完了に対して最終的な責任を負います。各タスクに1名のみ割り当てられます
-
C (Consulted): 協議先
- タスクの実行前に相談を受ける、専門的な知見を持つ人やチームです
-
I (Informed): 報告先
- タスクの進捗や結果について報告を受ける人やチームです
これらを表形式で整理したものが「RACIマトリクス」であり、役割と責任の所在が一目でわかるようになります。
【具体例】3社連携の運用保守RACIマトリクス
ここでは、具体例として3社体制のケースを紹介します。
- A社: サービス全体を統括し、最終責任を負う会社
- B社: インフラの運用を専門とする会社
- 開発ベンダー: アプリケーションの保守を専門とする会社
運用保守RACIマトリクス
| カテゴリ | タスク | A社（依頼元／保守責任） | B社（運用担当） | 開発ベンダー（保守実務） | 主な理由・目的 |
|---|---|---|---|---|---|
| 監視・インシデント管理 | 監視アラート確認 | A | R | - | B社が24/365の一次受付を実行し、A社がプロセス全体に説明責任を負う。 |
| 障害一次切り分け | A | R | C | B社がインシデントの初期調査を行う。必要に応じ開発ベンダーに技術的な相談を行う。 | |
| エスカレーション判断・実行 | A | R | I | B社が自社で対応不可と判断した場合、開発ベンダーへエスカレーションを実行する。 | |
| 問題・ナレッジ管理 | 障害原因調査 | A | C | R | 問題管理プロセスの開始。根本原因の特定まで開発ベンダーが責任を持つ。 |
| └ インフラ/ミドルウェア層の調査 | A | R | C | B社が管轄するインフラレイヤーの問題でないことを証明する（責任分解点）。 | |
| └ アプリケーション層の調査 | A | I | R | 開発ベンダーがソースコードやアプリログを解析し、根本原因を特定する。 | |
| 恒久対応 | A | C | R | 特定した根本原因を取り除くための恒久的な対応を開発ベンダーが主導する。 | |
| └ インフラ/ミドルウェア設定変更による対応 | A | R | C | OSやミドルウェアの設定変更が恒久対応となる場合、B社が実施する。 | |
| └ ソースコード修正による対応 | A | I | R | アプリケーションのバグ修正が恒久対応となる場合、開発ベンダーが実施する。 | |
| 技術的ナレッジベース更新 | A | C | R | 調査過程や対応内容について、実行者である開発ベンダーがナレッジを蓄積する。 | |
| 障害報告書の作成・提出 | A | C | R | 開発ベンダーが原因と恒久対応をまとめ、A社に報告する。B社は時系列情報を提供。 | |
| 変更・リリース管理 | 変更要求(RFC)の起票・管理 | A | R/C | R/C | 変更プロセス全体をA社が統括。起票は関係各社から可能とする。 |
| 変更諮問委員会(CAB)の開催・承認 | A | C | C | 重要な変更について、A社がビジネスインパクトを評価し、最終承認を行う。 | |
| 変更作業の実施 | A | - | - | （以下のサブタスクで役割を定義） | |
| └ インフラ/ネットワーク構成の変更実施 | A | R | C | B社がインフラ専門家として計画・実施する。開発ベンダーはアプリへの影響を助言。 | |
| └ アプリケーションリリースの計画・実施 | A | C | R | 開発ベンダーがリリース計画を策定し、安全なデプロイまで責任を持つ。 | |
| 定常運用・セキュリティ | 定期メンテナンス | A | - | - | （以下のサブタスクで役割を定義） |
| └ OS/ミドルウェアのパッチ適用 | A | R | C | B社が計画的にインフラのセキュリティ・安定性を維持する。 | |
| └ アプリケーションの定期作業 (データ更新等) | A | C | R | 開発ベンダーがアプリケーション固有のメンテナンス作業を実施する。 | |
| 運用手順書／構成図の更新・管理 | A | - | - | （以下のサブタスクで役割を定義） | |
| └ 運用手順書 (監視・障害対応手順等) の更新 | A | R | C | 日々の運用を行うB社が、手順の陳腐化を防ぎ、実態に合わせて更新する。 | |
| └ システム構成図/設計書 (アプリ関連) の更新 | A | I | R | アプリケーションの変更を行った開発ベンダーが、関連ドキュメントを更新する。 | |
| ユーザーアカウント管理（権限申請・発行） | A | R | I | A社が申請を承認し、B社が払い出し作業を行うことで、職務分掌と統制を担保する。 | |
| 会議体・レポーティング | 定例運用報告会の開催・報告 | A | R | C | B社が日々の運用実績を報告し、A社がサービスの健全性を評価する。 |
| 月次運用レポート作成 | A | R | - | B社が月間のインシデント件数やSLA達成状況をまとめて報告する。 | |
| キャパシティ・パフォーマンス報告 | A | R | C | B社がリソース状況を報告。開発ベンダーは性能劣化時の分析に協力する。 | |
| 契約・サービスレベル管理 | SLA（サービスレベル合意）の評価・見直し | A | C | C | A社がビジネス要件と実績を基に、SLAの妥当性を定期的に評価・見直しする。 |
| 保守契約の管理・更新 | A | - | C | A社がオーナーとして、開発ベンダーとの保守契約を管理する。 |
各カテゴリのポイント
マトリクスから読み取れる各カテゴリでの役割のポイントを簡潔にまとめます。
-
監視・インシデント管理
障害発生時は、B社が一次対応を実行(R)し、A社が全体の説明責任(A)を負います。これにより、迅速な初動と責任の明確化を両立させています -
問題・ナレッジ管理
根本原因の調査は、アプリケーション層：開発ベンダー(R)、インフラ層：B社(R)と、専門領域に応じて実行責任を分担します。これにより、正確な原因特定を促進します -
変更・リリース管理
インフラ変更はB社(R)、アプリのリリースは開発ベンダー(R)が実行しますが、最終的な承認はA社(A)が行います。これにより、安全な変更管理プロセスを実現します -
定常運用・セキュリティ
各種メンテナンスは専門チームが実行(R)します。特にドキュメント類は、変更作業の実行者(R)自身が更新することで、情報の鮮度を保つルールとなっています
まとめ
RACIマトリクスは、単なる役割分担表ではなく、円滑なコミュニケーションを促すための指針です。
タスクを実行する際は、自分の役割(R)だけでなく、誰が説明責任者(A)で、誰に相談(C)・報告(I)すべきかを常に意識することが、チーム全体の生産性向上に繋がります。