役割分担と期待値調整（DRSI）：誰が何をするかを明確にする

「これ、誰がやるって決めてましたっけ？」

「てっきりBさんが対応してくれると思っていました……」

「また大事なタスクが落ちている……」

管理職として現場を預かっていると、こうした「ポテンヒット」は日常茶飯事です。プロジェクトが炎上するたびに原因を探ると、たいていそこにあるのは「役割の曖昧さ」です。チームワークを重視するあまり「みんなでやる」と言い続けた結果、誰も責任を持たない状態が生まれてしまう——そんな経験、あなたにも心当たりはありませんか？

この記事では、役割分担と期待値のズレを構造的に解消するフレームワーク「DRSIモデル（RASCIモデル）」を徹底解説します。明日のミーティングから即使える実践手順も紹介しますので、ぜひ最後までお読みください。

---

「みんなでやる」は「誰もやらない」——役割曖昧化の正体

リンゲルマン効果：人数が増えると責任感は薄れる

社会心理学に「リンゲルマン効果（社会的手抜き）」という現象があります。綱引きの実験で有名なこの効果は、人数が増えるほど一人あたりの努力量・責任感が低下するというものです。3人で綱を引くと、一人あたりの力は単独時の約85%に、8人になると約50%にまで落ちると報告されています。

チームで「みんなでやろう」と掛け声をかけるとき、実はこのリンゲルマン効果が静かに作動しています。「誰かがやるだろう」という心理的な依存が、タスクの空白地帯を生み出すのです。管理職が意識的に役割を「指名」しなければ、いくら優秀なメンバーが揃っていても組織は動きません。

「仲良しチーム」ほど危ない——阿吽の呼吸の罠

関係性の良いチームほど、「言わなくても伝わる」という幻想を持ちやすいです。しかし信頼と役割明確化は別物です。心理的安全性の高いチームが本当に機能するのは、「何でも言える」環境と「誰が何をするか」という構造的な明確さが両立しているときだけです。

「仲良しクラブ」と批判されるぬるま湯組織の本質は、役割の不明瞭さによる責任の拡散にあります。心理的安全性と役割明確化は対立概念ではなく、組織パフォーマンスの両輪です。この点については 心理的安全性の誤解：「ぬるま湯組織」との決定的違い でも詳しく解説しています。

「決定者」が不明確な会議は永遠に終わらない

会議が長くなる最大の原因のひとつは、「誰が決めるのか」が明示されていないことです。意思決定権者が曖昧なまま議論が続くと、全員が意見を出し続けるが誰も決断しない「合議の迷宮」に陥ります。「R（Responsible）＝決定者は必ず1人」というDRSIの原則は、この問題を構造的に解決します。

---

DRSIモデルとは何か——RASCIをシンプルに使いこなす

責任分担表（RAM）の基本概念

DRSI（RASCI）モデルは、プロジェクトマネジメントで広く使われる責任分担マトリクス（RAM: Responsibility Assignment Matrix）の一種です。各タスクに対して「誰が何の役割を担うか」を明示的に割り当てることで、ポテンヒットと権限重複を同時に防ぎます。

PMBOKをはじめとするプロジェクトマネジメントの国際標準でも採用されており、IT・製造・コンサルなど業種を問わず活用されています。チームの規模が大きくなるほど、また業務の複雑性が増すほど、その効果は顕著になります。

D・R・S・I——4つのロールの定義

※フルバージョンのRASCIでは、A（Accountable＝最終説明責任）やC（Consulted＝相談先）が加わります。ただし実務では「誰がやるか（D）」「誰が決めるか（R）」の2点を押さえるだけで、タスクの8割の曖昧さは解消できます。

DとRの違いを理解する——「動く人」と「決める人」は別

DRSIで最も混乱しやすいのが「D（実行責任者）」と「R（決定者）」の区別です。たとえばプレゼン資料の作成であれば、D＝担当者（資料を作る人）、R＝上司（最終的にGOを出す人）と分離できます。

現場でよく起きる失敗は、「Dが自分でRも担おうとして承認待ちが発生する」または「Rが複数いて誰のOKが正式なのか不明になる」パターンです。RとDを明示的に分離し、Rを1名に確定することが、意思決定の速度を劇的に改善するカギです。

---

期待値のすり合わせ——「誰が」だけでは足りない

QCDSで期待値を言語化する

役割（Who）を決めただけでは不十分です。「どのクオリティで（Quality）、いつまでに（Delivery）、どのコストで（Cost）、どの優先度で（Speed）」という期待値（QCDS）までセットで伝えることが、真のアサインです。

「資料作成をお願い（D）」→ 部下：完璧に仕上げようと3日かける→ 上司：たたき台でいいのに……

このすれ違いは、役割ではなく期待値のズレから起きています。正しいアサインの伝え方はこうです。

「田中さん、来週月曜の定例用の資料作成をDでお願いします。クオリティは60点のたたき台でOK、締め切りは金曜17時、スピード優先です」

Who + Quality + Deadline + Priority——この4点をセットで伝えることで、「思っていたのと違った」というミスマッチを構造的に排除できます。

期待値のズレが生む「見えないコスト」

期待値のすり合わせ不足は、単に「やり直し」が発生するだけではありません。部下のモチベーション低下、上司への不信感の蓄積、チームの心理的安全性の毀損という連鎖反応を引き起こします。「頑張ったのに否定された」と感じる体験が繰り返されると、部下は自発的に動くことを避けるようになります。

1on1でのフィードバックや目標設定においても、期待値の言語化は不可欠なスキルです。詳しくは 効果的な1on1の7ステップ：2026年最新フレームワーク を参照してください。

---

実践：DRSIマトリクスの作り方と運用ステップ

ステップ1：タスクを書き出す

まずプロジェクトや業務のタスクを洗い出します。付箋やホワイトボード、スプレッドシートのどれでも構いません。この段階では「誰がやるか」ではなく「何をやる必要があるか」にフォーカスすることが重要です。役割の前にタスクを定義することで、人ありきの歪んだ分配を防げます。

ステップ2：各タスクにD・R・S・Iを割り当てる

タスク一覧ができたら、横軸にD/R/S/I、縦軸にタスクを並べたマトリクスを作成します。チーム全員でこの作業を行うことが重要です。「Dが空白のタスク」「Rが2名になっているタスク」はその場で即解決します。

実例：来期予算案の作成

• D：田中（数字をまとめて資料を作る）
• R：山田課長（最終承認・決裁）
• S：経理部・鈴木（データ提供・数値チェック）
• I：部長（完成後の報告先）

ステップ3：「バグ」を潰す

マトリクスを見渡して以下のバグをチェックします。

• Dが空白のタスク → 即座に指名する
• Rが複数いるタスク → 最終決定者を1名に絞る
• 全員がSかIだけのタスク → Dが実質存在しないため再確認
• 特定のメンバーにDが集中しすぎている → 負荷の偏りを調整

この「バグ発見と修正」のプロセスこそ、DRSIマトリクスを作る最大の価値です。可視化することで初めて「穴」が見えるようになります。

ステップ4：定期的に見直す

プロジェクトは進行とともにタスクが変化します。週次・隔週のチームミーティングでマトリクスを更新する習慣をつけましょう。タックマンモデル：チーム成長の4段階とリーダーの役割 にあるように、チームの成熟度によって最適な役割分担の粒度も変わります。形成期は細かく定義し、統一期以降は自律的な調整を促す設計が効果的です。

---

よくある失敗パターンと対処法

失敗①：Rが「なんとなく上司」になる

「Rは役職が上の人」という思い込みで、部長・課長・主任の全員がRになるケースがあります。これでは承認プロセスが三重になり、意思決定が遅延します。Rはそのタスクのコンテキストをもっともよくわかっている人が担うべきであり、必ずしも職位の高さとは連動しません。

失敗②：Dを「チーム全体」にする

「このタスクはチーム全員でD」という設定は、リンゲルマン効果を構造的に再現する最悪のパターンです。Dは必ずフルネームで個人を指名してください。チームで協力するタスクであっても、「とりまとめ役のD」を1名立てます。

失敗③：SとIの違いを無視する

SとIを同一視すると、「報告を受けるだけでいい人」が実作業に巻き込まれ、逆に「実際にサポートすべき人」が情報だけ受け取って動かないという逆転が起きます。Sは能動的に行動する役割、Iはパッシブに情報を受け取る役割という区別を明確に持ちましょう。

失敗④：マトリクスを作って「満足」してしまう

DRSIマトリクスを作成することは手段であって、目的ではありません。作った後に各DとRに対して期待値（QCDS）を個別に伝えることがセットです。マトリクスはあくまでも「誰が何をするかの地図」。動かすのは対話です。

---

DRSIと心理的安全性——「責任の明確化」は信頼を壊さない

役割明確化は管理強化ではない

「役割をはっきり決めると、ガチガチの管理組織になる」という誤解があります。しかし実際は逆です。役割が曖昧なチームでは、失敗したときの「犯人探し」が発生しやすく、むしろ心理的安全性が低下します。誰が何を担うかが明確であれば、失敗は「このタスクの問題」として切り分けられ、個人攻撃に発展しにくくなります。

Googleのプロジェクト・アリストテレスが示したように、最強のチームの条件の最上位は心理的安全性ですが、構造の明確さもその基盤となっています。詳しくは 心理的安全性の科学：Googleが証明した最強チームの条件 をご参照ください。

「Blameless」なチームはDRSIから生まれる

障害や失敗が起きたとき、「誰が悪いか」ではなく「どのプロセスに問題があったか」を問うBlameless（ブレームレス）な文化は、役割が明確であってこそ機能します。Dが誰で、Rが誰で、Sがどこまでサポートしたかという記録があれば、ポストモーテム（振り返り）が建設的に行えます。犯人探しをしない：Blameless Postmortemの技術 もあわせて読むと、より深く理解できます。

権限委譲との連携——自律型チームへの進化

DRSIを導入した後のステップとして、徐々にDとRをメンバーに委譲していく「エンパワーメント」があります。最初は管理職がRを握り、Dだけを委ねる。次第にRも本人に渡していくことで、自律型チームへと進化していきます。この段階的な権限委譲については エンパワーメント（権限委譲）の段階：自律型チームへの進化 が参考になります。

---

チームビルディングとしてのDRSI——対話の設計に組み込む

プロジェクトキックオフへの組み込み

DRSIマトリクスの作成は、プロジェクトキックオフミーティングの定番アジェンダとして設定することを推奨します。「最初に役割の地図を全員で書く」という体験が、チームの連帯感と共通認識を同時に醸成します。ファシリテーションの観点からは チーム対話の設計：安全な場を作るファシリテーション が実践的な手順を提供しています。

関係性の質と成功循環モデル

MIT・ダニエル・キム教授が提唱した「成功循環モデル」では、「関係の質」→「思考の質」→「行動の質」→「結果の質」という好循環を示しています。DRSIによる役割の明確化は「行動の質」を高めますが、それ以前の「関係の質」つまり対話の土台があってこそ機能します。関係性の質を高める「成功循環モデル」の応用 と組み合わせることで、DRSIの効果は最大化されます。

OKRとの連携で目標と役割をつなぐ

チームのOKR（目標と主要成果指標）が定まったら、各KRに対してDRSIを割り当てるとさらに効果的です。「誰が何の目標を追うか」が一覧で見えるようになり、目標管理と役割分担が一体化した強いチーム構造が生まれます。OKRの詳細は OKRの完全理解：2026年版目標管理の新常識 をご覧ください。

---

リモート・ハイブリッドチームでのDRSI活用

非同期コミュニケーションでは「見える化」が命

リモートワークや非同期コミュニケーションが常態化した現代において、DRSIマトリクスの重要性はさらに高まっています。対面であれば「なんとなく」伝わった役割も、テキストや非同期ツールでは意図が伝わりません。NotionやGoogle Sheetsなどのツールにマトリクスを常駐させ、全員が常時参照できる状態を保つことが実務上のポイントです。

ダッシュボードとの組み合わせ

DRSIマトリクスをデジタルダッシュボードと連携させると、各Dのタスク進捗をリアルタイムで管理職が把握できるようになります。ダッシュボードでチームの健康状態を可視化する で紹介されているツール活用と組み合わせることで、マネジメントの負荷を大幅に削減できます。

---

まとめ：「私がやります」「私が決めます」が飛び交うチームをつくる

DRSIモデルの本質は、テクニックではなく「チームの会話の質を変える」ことにあります。マトリクスを作る過程で起きる「あれ、Dが誰もいない」「Rが2人になってる」という気づきが、チームの機能不全を未然に防ぎます。

明日のミーティングから試せる最小ステップは次の3つです。

• 次のタスクを誰かに頼むとき、「D（実行）をお願いします」と明言する
• 「誰が最終的に決めるか（R）」を会議の最初に確認する
• 期待値（Quality・Deadline・Priority）を口頭またはテキストで明示する

「私がやります（D）」「私が決めます（R）」という言葉が自然に飛び交うチームは、驚くほど速く、そして心理的に安全に動きます。役割の明確化は管理の強化ではなく、チームメンバー全員を「主役」にする技術なのです。

---

【現役管理職の見解：役割分担は「信頼の設計図」である】

正直に言うと、私がDRSIのような役割分担フレームワークを意識的に使い始めたのは、プロジェクトが一度大きく炎上した後のことでした。チームの仲は良かった。コミュニケーションも取れていた。なのに、大事なタスクが「誰も触っていない」状態で締め切りを迎えてしまった。あのときの感覚は今でも覚えています。「なぜこうなったのか」を冷静に分析すると、答えはシンプルで、「誰もDだと思っていなかった」ということでした。

それ以来、私はアサインをするとき必ず「あなたがDです」と名前で指名するようにしています。最初は「なんか堅苦しい」と感じるメンバーもいましたが、慣れてくると逆に「自分が主役だ」という自覚が生まれ、主体性が上がりました。役割の明確化は、決して管理の強化ではなく、「あなたを信頼して任せる」というメッセージなんだと今は思っています。

INTJの私は俯瞰が好きなので、チーム全体のDRSIマトリクスを眺めながら「誰かに負荷が偏っていないか」「Rが曖昧になっていないか」を定期的に確認するのが習慣になっています。完璧な役割設計などありませんが、「地図を持ってチームを動かす」という姿勢自体が、管理職としての信頼につながると感じています。あなたのチームでは、誰がDで、誰がRかを全員が言えますか？

---