Webサイトの更新作業を複数人で担当していると、誰が何を決めてよいのか分からなくなる場面が生じます。依頼を受けた担当者が勝手に公開してしまったり、確認の連鎖が続いて更新が滞ったりするのは、役割の境界があいまいなまま運用を始めたときに起きやすい問題です。こうした状況を整理するために広く使われているのが、RACI（ラシ）と呼ばれる役割分担の考え方です。
Web運用にRACIを使う目的と対象
RACIとは、業務における4種類の関与区分を表す頭字語です。R（Responsible）は実際に作業を行う担当者、A（Accountable）は最終的な承認と責任を持つ意思決定者を指します。C（Consulted）は判断前に意見を求める相談相手、I（Informed）は結果を通知される関係者です。
Web運用でRACIを使う主な目的は、コンテンツの依頼・編集・確認・公開という一連のステップで、誰が動いて誰が承認するかを明確にすることです。対象として適しているのは、担当者が複数いるサイト、制作会社と社内担当者が混在する体制、更新頻度が高くミスが起きやすい運用環境です。担当者が一人であれば区分の恩恵は小さいですが、2名以上が関与する時点でRACIを整理しておくと、認識のずれを事前に防ぎやすくなります。
分担表を設計するときの判断基準
RACIを作る前に、いくつかの観点を整理しておくと設計がスムーズです。まず、承認権限を誰が持つかを組織の意思決定構造から確認します。Aは一つのタスクに対して必ず一人にするのが原則です。Aが複数いると責任が分散し、判断が遅くなります。
次に、Cに入れる人数を絞るかどうかを検討します。相談相手が多ければ質は上がる反面、承認フローが長くなります。緊急度の高い更新が多い場合は、Cの範囲を限定して速度を優先する判断が合理的です。
また、社内と外部でどこまでAを持たせるかも重要な軸です。制作会社が編集を担当していても、公開の最終承認は社内に置く体制が多く見られます。技術的な変更についてはベンダーにAを持たせた方が判断が速い場合もあります。体制ごとにタスク単位でAの位置を変えてよい点を覚えておくと、現実に即した表を作りやすくなります。
RACI表を作る手順と進め方
RACI表は、タスクを縦軸、関係者を横軸に並べたマトリクスで表すのが一般的です。以下の順序で作成すると、抜け漏れを減らせます。
- 運用上のタスクを洗い出します。コンテンツ依頼・原稿作成・画像準備・HTMLコーディング・内容確認・最終承認・公開操作・公開後の確認・定期レポートなど、実際の作業単位で列挙します。
- 関与する人物または役割を横軸に並べます。個人名でも役職名でも構いませんが、役職・役割名を使う方が表の寿命が延びます。
- 各タスクと各人の交差するセルに、R・A・C・Iのいずれかを入れます。まずAを一人に決めてから、Rを割り当てると整理しやすくなります。
- AもRも入っていないタスクがないか、Aが複数のセルに入っていないかを確認します。
- 関係者全員で表を共有し、認識のずれがある箇所を議論して修正します。
表のフォーマットはスプレッドシートで十分です。重要なのは形式よりも、作成後に全員が参照できる場所に置くことです。変更があれば更新するサイクルを作ることも欠かせません。保守・運用の記事では、運用ドキュメント管理の考え方についても触れていますので、参考にしてみてください。
役割分担を運用に落とし込む際の注意点とリスク
RACIを作成しても、実際の運用で機能しないケースがあります。よくある原因の一つは、表を作って終わりにしてしまうことです。担当者が交代したり新しいタスクが生まれたりしたときに表を更新しなければ、すぐに実態と乖離します。
もう一つのリスクは、Aの負担が特定の一人に集中することです。承認者が多忙な場合、確認待ちが積み重なって更新が止まります。Aが不在のときの代行者をあらかじめ決めておくか、優先度の低い更新はAなしで進められるルールを設けることが有効です。
また、CとIの区別があいまいになると、通知すべき相手と相談すべき相手が混同され、不要な確認が増えます。Cは意見が反映される可能性がある段階で声をかける相手です。Iは決定後に結果を知らせるだけでよい相手と明確に使い分けると、無駄なやり取りを減らせます。
保守・運用サービスを外部に委託している場合は、どのタスクのRとAを委託先に持たせるかを合意しておくことが重要です。認識のずれは、問題が起きたときに初めて表面化しやすいからです。
よくある疑問への客観的な回答
RACIは小規模サイトにも必要ですか
担当者が実質一人であれば、RACIを文書化するメリットは限られます。ただし、将来的に担当者が増える予定がある場合や、制作会社と連携して運用する場合は、小規模のうちに整理しておくと引き継ぎのコストを下げられます。
RACIとフローチャートはどちらが先ですか
RACIが先です。誰が何を担うかが決まってからでないと、フローチャートの矢印が誰に向かうかを正確に描けません。RACIで役割を固定した後、フローチャートで時系列のプロセスを可視化する順序が一般的です。
承認ステップを省いて公開速度を上げることは可能ですか
条件次第では可能です。誤情報が掲載された場合の影響が小さいコンテンツや、テンプレートが固まっているページであれば、Rが一定の裁量で公開できるルールにする選択肢はあります。一方、法的・財務的な内容を含むページや、ブランドへの影響が大きいコンテンツは、承認ステップを省くリスクの方が大きくなります。
RACI表を導入する前の確認項目チェックリスト
RACI表を運用に取り入れる前に、以下の点を確認しておくと設計がスムーズです。
- 洗い出したタスクのリストは、実際の運用ステップを網羅していますか。
- 各タスクのAが一人に絞られていますか。
- AもRも割り当てられていないタスクはありませんか。
- Cに入れた人は、意見が反映される段階でのみ関与しますか。
- Aが不在のときの代行ルールが決まっていますか。
- 表を保存・共有する場所とアクセス権限は整理されていますか。
- 体制や担当者が変わったときに表を更新する担当者は決まっていますか。
- 外部委託先との役割分担について合意を取っていますか。
これらをすべて確認してから表を共有すると、関係者の認識が揃い、運用開始後の混乱を防ぎやすくなります。体制や委託範囲についてさらに検討が必要な場合は、お問い合わせから相談することも一つの選択肢です。Web運用における役割設計は一度作れば終わりではなく、体制の変化に合わせて定期的に見直す継続的なプロセスです。表を生きたドキュメントとして維持することが、安定した運用につながります。
