JiraでRACIマトリクスを作る：責任の所在を明確にする

Jiraの課題に担当者がいても、重要な責任が未解決のまま残ることがあります。最終的な結果に責任を持つのは誰でしょうか。完了前に誰がレビューすべきでしょうか。すべての議論に参加せず、報告だけ受けるべき人は誰でしょうか。

一つの作業がプロダクト、開発、テスト、カスタマーサポートにまたがると、これらの問いはさらに難しくなります。担当者が変更を実装しても、関連するすべてのやり取りに自動的に責任を持つわけではありません。

RACIマトリクスは、そうした期待を見える形にします。少数の成果物と関係者を対応させ、それぞれの関わり方を記録します。

このガイドでは、架空の顧客ポータルのリリースを例に実用的なマトリクスを作り、Power Pack for Jiraに整理する方法を紹介します。目標は、人々が迷わず行動できる、短く役立つ合意を作ることです。

RACIとは？

RACIは、作業への4つの関わり方を表します。

各行の結果責任者は1人にします。実行責任者は少なくとも1人を割り当て、複数人で実行する場合は責任を明示します。相談には対話が必要ですが、報告は短い更新だけで済む場合もあります。

これらの定義はAtlassianによるRACIチャートの説明に沿っています。このガイドの残りでは、Jiraの例示的な作業フローに当てはめます。

実行責任と結果責任の区別は特に重要です。エンジニアが通知設定を実装する一方、合意した顧客向けの結果を提供できたかどうかはプロダクトオーナーが責任を持つことがあります。どちらの役割も、技術的な判断や協力を不要にするものではありません。

実際の調整上の問題から始める

架空のチームが顧客ポータルの更新を準備しています。顧客は受け取るアカウント関連メールを選べるようになります。この変更にはテストと短いサポート用ガイドも必要です。

メンバーは、プロダクトオーナーのMaya、エンジニアのLeo、テスターのPriya、サポート責任者のSamです。名前と担当は例であり、推奨される固定的な人員配置ではありません。

マトリクスを作る前に、混乱の原因を確認します。設定画面を作ることには全員が同意していますが、サポート手順の責任を明確に引き受けた人がいません。テストも、顧客が受信し続ける必要のあるメールについてのプロダクト判断に依存しています。

これはRACIマトリクスを作る意味のある理由です。単純な作業が一つだけで責任者も明白なチームには、必要ないかもしれません。責任についての話し合いが働き方を変える場面で使いましょう。

議論の置き場所に適したJira課題を選びます。共通の成果を説明し、関連する実作業にリンクしている課題が適しています。マトリクスの場所をチームに伝え、日々の計画に組み込みます。

認識しやすい成果物を書く

大きな部署名や曖昧な工程ではなく、具体的な出力から始めます。「開発」は人の集まりです。「メール設定の操作部品を実装する」は、誰かが完了できる作業です。

この例では、チームは4つの行を選びます。

• 顧客が変更できる通知設定を合意する。
• メール設定の操作部品を実装する。
• 設定変更とメール配信の動作を照合する。
• 新しい操作部品のサポート手順を公開する。

各行は責任者を明確にできる程度に小さく、それでも話し合う価値がある程度に意味のある単位にします。細かな実装手順をすべて列挙すると、調整の問題が管理作業に埋もれてしまいます。

ある行に結果責任者が2人必要になることが続くなら、範囲を見直します。「体験全体を構築して公開する」には、異なる責任者が持つ複数の成果が含まれているかもしれません。責任が実際に変わるところで分割し、分割後も全体の成果を表していることを確認します。

最初のマトリクスを作る

以下はチームの最初の合意です。横線は、その成果物に対して具体的な役割が割り当てられていないことを示します。

最後の行には説明が必要です。サポート手順の正確さと有用性にはSamが責任を持ち、技術的な手順の草稿はLeoが書きます。このチームはそう合意しました。別のチームなら、執筆をサポート担当者に任せるかもしれません。

マトリクスは実際の作業上の合意を表すべきです。役職名だけで埋めないようにします。専門知識があっても作業時間を確保できない人はいますし、上位の役職だから適切な結果責任者とは限りません。

各行を声に出して読みます。テストの行なら「Priyaが検証し、Leoが技術的な助言をし、Mayaが結果に責任を持ち、Samが結果を受け取る」です。この説明に驚く参加者がいたら、確定扱いにする前に不一致を解消します。

合意をPower Packに登録する

Jira課題でPower Packを開き、RACI / DACI Matrixを使います。責任分担モデルはRA(S)CIと表示され、4つのRACI役割に加えて任意のSupport役割があります。この例はSを割り当てず、R、A、C、Iだけで作れます。

参加者一覧、成果物、マトリクスの順に進みます。まず関係者を追加します。参加者一覧ではJiraユーザーの検索に加え、Jiraを使わない人や外部参加者も登録できます。外部の登録は一覧に人を記録するもので、Jiraアカウントの作成や課題へのアクセス許可ではありません。

次に合意した成果物を追加します。Power PackのImport Subtasksでは、既存の子サブタスクを利用可能な成果物に取り込めます。マトリクスに進む前に選択した成果物を見直し、行が話したい内容に合っていることを確認します。

マトリクスの該当する交点に役割を割り当てます。セルをクリックすると利用可能な役割が順に切り替わり、フォーカスのあるセルは役割の文字キーでも操作できます。その行に実質的な責任がない人のセルは未割り当てにします。

責任者がいない、複数いる、実行者がいない行は強調されます。表示は割り当てを見直すきっかけとして扱います。有効な行とは基本的な役割構成がそろっているという意味で、本人の同意、十分な時間、作業の完了を証明するものではありません。

変更はJira課題に保存されます。離れる前や他の人にレビューを依頼する前に保存表示を確認します。ローカルまたはオフラインの状態を、同僚がすでに最新版を見られる証拠と取り違えないでください。

行だけでなく人も確認する

行ごとには妥当に見えるマトリクスでも、一人に仕事が集中していることがあります。成果物を確認した後、各人の列を縦に読みます。

この例ではLeoが、動作の合意、操作部品の実装、サポート手順の執筆を担当しています。小さな変更なら問題ないかもしれません。大きなリリースなら、日程を約束する前に対処すべきボトルネックを示している可能性があります。

各人が役割を理解し、果たせるかを確認します。相談が必要な時期、期待する返答速度、報告先に渡すものを明らかにします。時期や連絡方法の詳細は、通常のJira運用で作業と一緒に記録します。

セルのCはレビューを予約しません。Iは更新を送信しません。マトリクスは期待を示し、実行するのはチームです。

責任分担とJiraワークフローを区別する

RACIの割り当ては成果物への関わり方を表します。Jiraの担当者フィールド、課題の権限、ワークフロー状態と混同しないようにします。

責任セルの変更は、実作業のチケットの割り当て、アクセス付与、課題の状態変更の代わりにはなりません。通常のワークフローで、こうしたJiraの操作を合意に合わせます。

Power PackではマトリクスをMarkdown表やCSVに出力し、別の場所で話し合えます。コピーを共有する場合は、現在の割り当てを確認する場所としてJira課題を示します。そうしないと、計画が変わった後も古い表が流通し続けることがあります。

範囲が変わった、参加者が不在になった、新しいレビュー要件が出たときにマトリクスを見直します。最初の版を永久に固定するより、意味のある変更時に短く確認するほうが役立ちます。

よくある3つのRACIの失敗を避ける

全員を相談先にする

相談は具体的な問いに答えるものであるべきです。すべての行に全員を関与させると、減らしたかった会議負担が戻ってきます。必要な専門知識を明示し、結果だけが必要な人には報告先の役割を使います。

結果責任を自動的な追加作業と考える

結果責任者には、結果に関する問題を解決するための十分な背景知識と権限が必要です。最も上位の人だから、あるいはすでに会議に多く参加しているからという理由だけで選ばないようにします。

意思決定の問題をRACIで解決しようとする

未解決の問いが「誰が作るか」ではなく「誰が選ぶか」の場合もあります。その場合はDACIで、推進者、1人の承認者、貢献者、報告先を決めるほうが適しています。まず決定を固め、その後必要に応じてRACIで実行責任を整理します。

チームで小さなマトリクスを試す

責任がチームの境界をまたいでいるJira課題を選びます。意味のある成果物を3〜5個挙げ、関係者を追加し、一緒に役割を合意します。

Power PackのRACI / DACI Matrixを使い、合意を課題のそばに置きます。責任の表示を確認し、保存状態を確かめ、名前の載った人たちと内容を読み合わせます。

実際の不明点を解決するマトリクスから始めましょう。この顧客ポータルのチームにとって役立つ結果は単純です。誰が操作部品を作り、誰が検証し、誰が結果に責任を持ち、誰がサポートの準備を整えるかを全員が理解できます。

• AtlassianによるRACIチャートの説明