フレームワーク活用ガイドひとことで言うと#
すべてのタスク・プロジェクト・意思決定に**たった一人の「直接責任者（DRI）」**を置くAppleの組織原則。「誰の責任か」が常に明確なので、意思決定が速く、言い訳が生まれない。スティーブ・ジョブズが「会議では必ず各アクションのDRIを決めてから終わる」と徹底した。
押さえておきたい用語#
- DRI（Directly Responsible Individual）
- あるタスクやプロジェクトの最終的な成否に責任を持つたった一人の人物。複数人がDRIになることはない。
- シングルポイント・オブ・アカウンタビリティ
- 責任の一元化。問題が起きたとき「誰に聞けばいいか」が常に1人に決まっている状態を指す。
- RACI
- Responsible（実行者）、Accountable（説明責任者）、Consulted（相談先）、Informed（報告先）の役割分担マトリクス。DRIはRACIの「A」に相当する。
- オーナーシップ
- DRIに求められる当事者意識。「自分が最終責任者である」という自覚を持ち、他人任せにしない姿勢。
DRIモデルの全体像#
こんな悩みに効く#
- 会議で決まったことが実行されず、「誰がやるんだっけ」が多い
- 複数人が関わるプロジェクトで、責任の押し付け合いが起きる
- 意思決定が遅いのは、誰が決めるべきか不明確だから
基本の使い方#
DRIの指名ルールはシンプル。
- 1タスク = 1人のDRI（例外なし）
- DRIは「実行者」ではなく「責任者」。自分でやる必要はないが、結果には責任を持つ
- 会議の終了時に、全アクションアイテムのDRI名を読み上げて確認する
Appleでは会議の議事録に各項目のDRI名が記載され、全員がアクセスできる。
責任だけ与えて権限がないと、DRIは名ばかりになる。
- DRIは担当領域の意思決定権を持つ（他のメンバーの意見は聞くが、最終判断はDRI）
- 必要なリソース（予算、人、ツール）にアクセスできるようにする
- DRIが「決められない」と言う場合は、上位のDRI（マネージャー）にエスカレーションする
成功も失敗もDRIが報告する。
- プロジェクト完了時にDRIが結果を報告し、学びを共有する
- 失敗の場合は「何が起きて、次にどう防ぐか」をDRIが説明する
- 「チーム全員の責任」にしない。DRIが責任を持つからこそ、学びが具体的になる
具体例#
Appleの製品開発では、機能レベルまでDRIが決まっている。iPhoneの初代開発では、以下のようにDRIが細分化されていた。
| 機能 | DRI | 責任範囲 |
|---|---|---|
| タッチスクリーン操作 | エンジニアA | マルチタッチの精度とレスポンス |
| 通話品質 | エンジニアB | 音声の明瞭さとノイズキャンセル |
| カメラ | エンジニアC | 画質、起動速度、UI |
| バッテリー | エンジニアD | 8時間以上の通話時間を実現 |
スティーブ・ジョブズは週次のレビュー会議で各DRIに直接進捗を聞いた。「バッテリーの件はDさん、どうなった？」というように、肩書きに関係なく担当者と直接対話する。
この仕組みにより、100人以上 が関わるプロジェクトでも「誰に聞けばいいか」が常に明確だった。ジョブズは「責任が曖昧なAppleはAppleではない」と発言している。
従業員40名のWeb制作会社。クライアントプロジェクトの 35% が納期遅延していた。原因を分析すると「デザイナー、エンジニア、ディレクターの誰がボールを持っているか不明」が最多。
DRIモデルを導入し、プロジェクトの各フェーズにDRIを設定。
| フェーズ | DRI | 判断権限 |
|---|---|---|
| 要件定義 | ディレクター | クライアントとの仕様確定 |
| デザイン | デザイナー | UIの最終決定 |
| 実装 | エンジニア | 技術選定と品質基準 |
| 納品 | ディレクター | クライアントへの最終確認 |
フェーズの切り替え時にDRIが「引き継ぎメモ」を次のDRIに渡すルールも追加。
3ヶ月後の結果:
- 納期遅延率: 35% → 12%
- 「誰に聞けばいいかわからない」というSlack上の質問: 週平均 18件 → 3件
- クライアント満足度: 3.4 → 4.2（5段階）
最も効果的だったのは「フェーズ切り替え時の引き継ぎ」。それまでは「デザインが終わったのにエンジニアが知らない」という状態が頻発していた。
小学校のPTA（会員数180名）。年間行事の運営で「みんなで協力しましょう」という方針がかえって「誰もやらない」問題を生んでいた。運動会の準備が前日まで進んでいないというトラブルが2年連続で発生。
新会長がDRIモデルを導入。年間12行事それぞれにDRIを1名ずつ指名。
ルール:
- DRIは立候補 or 指名（1人1行事まで）
- DRIが全権を持つ（予算配分、スケジュール、担当割り振り）
- 他の保護者はDRIの依頼に応じてサポートする
- 結果報告はDRIがLINEグループに1回投稿するだけ
運動会のDRIとなった保護者は、3ヶ月前から段取りを組み、当日の運営を仕切った。「自分が責任者だとわかっているから、逆に動きやすい。“みんなで相談"より100倍速い」とのコメント。
導入年の結果:
- 行事の準備不足トラブル: 年4件 → ゼロ
- PTA活動への参加率: 42% → 61%（「何をすべきか明確だから参加しやすい」）
- 保護者1人あたりの月間活動時間: 平均6時間 → 3時間（効率化）
やりがちな失敗パターン#
- DRIに責任だけ与えて権限を与えない ── 「責任者だけど承認は上司」では意味がない。判断権限をセットで渡す
- 1つのタスクに複数のDRIを置く ── 「共同DRI」は存在しない。2人になった瞬間に責任は半分になる
- DRIを指名したことを周知しない ── 本人だけがDRIだと知っていて、チームが知らないと機能しない。全員に見える形で公開する
- DRIを固定化する ── 同じ人がずっとDRIだと負荷が偏る。プロジェクトごとにローテーションし、成長機会として活用する
まとめ#
DRIモデルは「すべてのタスクにたった一人の責任者」を置くAppleのシンプルな原則。責任が明確だから意思決定が速く、結果への当事者意識が生まれる。導入は簡単で、明日の会議から「各アクションのDRIを決めてから終了する」だけで始められる。責任の曖昧さがプロジェクトの遅延や品質低下の原因になっているなら、まずDRIを試してみるといい。