■この記事はこんな「疑問・悩み」を持つ方に向けた記事です
・RACIとRASICのどちらを使えばいいのか分からず、現場に合った使い分けを知りたい
・役割分担表（RACI）を作ったのに、現場で「聞いていない」「自分の仕事ではない」と押し付け合われる
・責任者（Accountable）と作業者（Responsible）の切り分けで失敗したくない
プロジェクトマネジメントの基本書やITILの参考書を開くと、必ずと言っていいほど登場するのが「RACI（レイシー）」や「RASIC（ラシック）」といった役割分担マトリクスですよね。
「Rは実行責任者で、Aは説明責任者……なるほど、これでチームの役割分担はバッチリだ！」
……なんて、綺麗に書かれた教科書を読んで納得していませんか？
正直に言いましょう。30年近くインフラエンジニアとして現場の修羅場を潜り抜けてきた私の視点から言わせてもらえば、教科書通りの知識だけで作ったRACIやRASICほど、現場で役に立たない「Excelのゴミ」になるものはありません。
申し遅れました。私はITインフラの現場で30年、ネットワークの刷新から大規模クラウドアカウント移行、さらにはISMS（情報セキュリティマネジメントシステム）の構築や審査員補としての活動まで、あらゆる「プロジェクトの泥沼」を這いずり回ってきたベテランエンジニアです。PMP（Project Management Professional）や高度情報処理技術者の資格も持っていますが、一番の誇りは資格ではなく「深夜のデータセンターで冷や汗を流しながら修羅場を収めてきた数々の苦い経験」だったりします。
この記事では、単なる用語の定義や一般的な比較にとどまりません。現場で本当に使える「RACIとRASICの決定的な違い」と、炎上を防ぐための泥臭い運用ノウハウを、私の失敗談や実感を交えて徹底的に語り尽くします。
「理論は分かったから、現場でどう動かせばいいんだよ！」とお悩みの方、ぜひ最後まで付き合ってみてくださいね。
30年の修羅場で痛感した「RACIとRASICの違い」の本質
まず基本中の基本として、RACIとRASICの文字が意味する定義をおさらいしておきましょう。ここを曖昧にしたまま進むと、後で必ず事故を起こしますからね。
RACIとRASICの基本定義
- R（Responsible：実行責任者）: 実際の作業を行う人。手を動かす担当者ですね。
- A（Accountable：最終責任者）: タスクの成果に対して最終的な責任を持つ人。承認権限を持つ「たった1人」です。
- S（Support：支援者）: ※RASICのみに登場。R（実行者）を助けて、実際に作業やリソースを提供する人。
- C（Consulted：参照・相談先）: 作業を進める上で、意見や専門知識を求める相手。双方向のコミュニケーションが発生します。
- I（Informed：報告先）: 進捗や結果を通知する相手。こちらは一方向の情報共有で十分な対象ですね。
一見すると、「ふんふん、S（Support）が入っているか入っていないかの違いだけでしょ？」と思いますよね。
ええ、文字通りの違いはそうです。しかし、現場の力学において「Sが存在するかどうか」は、天と地ほどの差を生み出すわけです。
文字の定義だけでは見えてこない「S（Support）」の決定的役割
ここが最初の重要ポイントなんですが、「S（支援者）」と「C（相談先）」を混同している人が非常に多いんですよ。
C（Consulted）は、あくまで「アドバイスをくれる人」です。「この仕様で問題ないですか？」と聞いて、「あー、そこは法的にこうだから気をつけてね」と答えてくれるアドバイザーなんですね。彼らは助言はくれますが、あなたの代わりにExcelを打ったり、ルータの設定コマンドを叩いてくれたりはしません。
一方で、RASICに登場するS（Support）は「一緒に汗をかいて手を動かしてくれる人」なんです。
例えば、基幹システムのネットワーク切替作業をイメージしてください。
R（実行者）がネットワークエンジニアだとします。しかし、配線の物理撤去や大量のラック固定作業は、1人では時間内に終わらない。そこで「インフラ保守運用チーム」から助っ人を呼び、一緒に作業してもらう。この「助っ人」こそが「S（Support）」なんです。
「C（相談先）」は口を出すだけですが、「S（支援者）」は労力（リソース）を差し出します。この違いをあらかじめ明確にしておかないと、現場では恐ろしい摩擦が起きるわけですね。
一目でわかる！RACI vs RASIC 比較・使い分け判定表
では、プロジェクトでRACIを使うべきか、それともRASICを使うべきか。
30年の経験から、判断基準を表にまとめてみました。迷ったらこの基準で選んでみてください。
| 比較項目 | RACIモデル | RASICモデル |
|---|---|---|
| 構成要素 | R / A / C / I | R / A / S / C / I |
| S（支援者）の定義 | なし（Rに含まれるとみなす） | 明確に独立して定義する |
| 適したプロジェクト規模 | 小〜中規模（自チーム内で完結する作業） | 中〜大規模（他部門や外部ベンダーが絡む作業） |
| 適したチーム構造 | 少数精鋭、各自の守備範囲が明確 | 役割が細分化された組織、混成チーム |
| 意思決定のスピード | 速い（関係者が少ないため） | やや遅い（調整対象が増えるため） |
| 現場の炎上リスク | 「手伝ってくれると思った」という認識のズレで炎上しやすい | 「Sの稼働・工数」を定義しないと曖昧化して炎上する |
| 結論としての推奨 | 単一部署の定常業務や小規模案件 | 外部ベンダーが絡むインフラ移行やシステム刷新 |
シンプルに決めたいなら「RACI」、組織を超えた協力やリソース提供が不可欠なら「RASIC」。これがベテランとしての結論です。
なぜ教科書通りのRACI/RASICを導入すると現場は炎上するのか？
プロジェクトの初期段階で、綺麗なExcelで作成されたRACIやRASICのマトリクスが配られる。「これで役割分担は完璧だ」とPMが満足げに頷く。
……ですが、ちょっと待ってください。
30年の経験上、教科書通りに綺麗に作ったマトリクスほど、プロジェクトが佳境に入った時に大炎上を引き起こすんですよ。
「なぜルールを決めたのに揉めるのか？」
そう疑問に思う若いエンジニアも多いでしょう。ここでは、現場で実際に起きる「RACI/RASIC崩壊の3大パターン」について、泥臭い力学と共に解説していきますね。
最高の禁忌！「A（Accountable：最終責任者）」が2人以上存在する地獄
RACI/RASICの運用において、絶対に破ってはいけない黄金律があります。
それは、「1つのタスクに対して『A』は絶対に1人しか置いてはならない」というルールです。
しかし、実際の現場（特に日本の大企業や、発注元と受託ベンダーが入り乱れるシステム開発）では、これが平気で破られます。「お客様と弊社で共同で責任を持ちましょう」とか、「システム部と営業部の両方をAにして角を立てないようにしよう」といった社内政治が働くわけですね。
結論を言いましょう。責任者が2人いるということは、責任者がゼロなのと同じなんです。
「船頭多くして船山に登る」という諺がありますが、Aが複数いると以下のような地獄が待っています。
- 障害発生時に「相手が最終判断をすると思っていた」と責任のなすりつけ合いが始まる
- 承認を求めに行くと、双方のAで意見が食い違い、現場の「R（実行者）」が板挟みになって潰れる
- 最終決裁者が曖昧なため、緊急事態での意思決定スピードが致命的に遅れる
「みんなで責任を持つ」という優しさは、厳しいプロジェクトの現場では「誰も責任を取らない」という無慈悲な裏切りに変わるわけですね。
「C（Consulted：参照・相談）」を増やしすぎて会議が終わらない罠
次に多いのが、「配慮」のつもりでC（相談先）を増やしすぎるパターンです。
「念のため、関連しそうな他部署の課長もCに入れておこう」「後で『聞いていない』と怒られたくないから、インフラチームのメンバー全員をCにしておこう」
……気持ちは痛いほど分かりますよ。角を立てたくないですもんね。
ですが、これがプロジェクトの意思決定を麻痺させる最大の原因になるんです。
Cに指定された人間は、自分の責任（A）でも作業（R）でもないため、気楽な立ち位置になります。結果どうなるかというと、「批評家（評論家）」に変身するわけですね。
- 「この方式、本当に大丈夫なの？」（代替案は出さない）
- 「うちの部署の運用基準と合わない気がするなぁ」（具体的にどこが合わないかは調べない）
- 「念のため、もっと検証データを集めてから再検討しよう」（判断の先延ばし）
C（相談先）が増えれば増えるほど、無駄な調整会議が増え、仕様決定が数週間単位で遅れていきます。「Cは必要最小限の専門家だけに絞る」。これがプロジェクトを遅延させないための鉄則なんですね。
「R（Responsible：実行責任者）」と「S（Support：支援者）」のなすりつけ合い
RASICモデルを採用した現場で最も頻発するのが、「R」と「S」の境界線崩壊です。
R（実行者）は「自分は全体のアウトラインを作ったから、詳細なドキュメント化やデータ移行作業はS（支援者）がやってくれるはず」と思い込む。
一方のS（支援者）は「自分はあくまで手が足りない時の補助。主体的に動くのはRでしょ」と考えている。
この意識のズレ放置したまま作業期日を迎えると、「えっ？ その作業、相手がやってると思ってました」という悪夢の会話が交わされることになります。
タスクがポッカリと宙に浮き、誰も手を付けていない「真空地帯」が生まれてしまうわけです。
これを防ぐためには、単にマトリクスに「R」「S」と書くだけでは不十分で、「具体的にSは何時間の工数を提供し、どの成果物を作成するのか」までブレイクダウンして握る必要があります。
【30年選手の泥臭い実体験：発注元と受託ベンダーで『A』を折半した金融システムの惨劇】
あれは10年ほど前、ある金融機関の基幹ネットワーク更新プロジェクトでのことです。
顧客側プロジェクトマネージャーと、受託側である我が社のPMが、仕様決定タスクの「A（最終責任者）」に連名で名を連ねていました。「対当なパートナーシップ」という綺麗事のもとに設定された体制でした。移行直前の負荷テストで、特定のルーティングにおいて想定以上のレイテンシ（遅延）が発生。システムを延期するか、そのまま強行するかの判断を迫られました。
顧客側のAは「技術的な担保を出せない受託側が延期を決断すべきだ」と主張。
我が社のAは「ビジネス上のリスク判断は発注元である顧客側がすべきだ」と譲らない。互いに「A」を盾にして決定を押し付け合い、会議は深夜まで糾弾合戦。結局、判断が3日遅れたことで移行手順の再検証が間に合わず、本番切り替え当日に通信障害が発生。私は現場のリーダーとして、3日間データセンターのパイプ椅子で仮眠を取りながらトラブル対応に追われました。
あの時、冷や汗を流しながら確信しましたね。「Aが2人いるプロジェクトは、必ず現場の人間が血を流すことになる」と。
ISMS審査員補・PMP視点で読み解く「責任と権限」のガバナンス
私はPMPとしてプロジェクト管理の体系的な知識を学び、ISMS（情報セキュリティマネジメントシステム）の審査員補として企業のガバナンス体制をチェックする立場でもあります。
単なる「作業の分担表」としてRACI/RASICを捉えている人が多いのですが、それは非常にもったいない。
実務とガバナンスを高度に融合させる視点についてお話ししましょう。
PMP（PMBOK）が教える責任割り当てマトリックス（RAM）の真価
PMPの標準ガイドであるPMBOK（Project Management Body of Knowledge）では、RACIなどの表を「RAM（Responsibility Assignment Matrix：責任割り当てマトリックス）」の一種として定義しています。
PMPの視点で重要なのは、「WBS（作業分解構成図）と組織構造（OBS）の交差点にRACIが存在する」という点なんですね。
つまり、プロジェクトのスケジュールやタスク（WBS）と、人間の配置（OBS）を物理的に連結する「接着剤」こそがRACI/RASICなんです。
プロジェクトマネジメントにおいて、RACIは単なる連絡網ではありません。「リソースの最適配分」「リスクマネジメント」「変更管理の承認フロー」の根幹をなす設計書なんですよ。
ISMS（ISO27001）審査の場でチェックされる「役割・責任・権限」の整合性
ISMSの認証審査や内部監査の場において、審査員が必ず確認する要求事項があります。ISO/IEC 27001の箇条5.3「組織の役割、責任及び権限」ですね。
審査員補としての視点を明かすと、私たちが現場で手順書やRACIマトリクスを見る際、単に「表が存在するかどうか」を見ているわけではありません。
「事故（インシデント）が起きた時、誰が・どんな権限を持って・どう判断するのかの実態」を見ています。
審査の場でよく見かける「NGなRACI」の典型例を紹介しましょう。
- 全員が「R（実行者）」になっていて、「A（最終責任者）」が不在の運用手順書
- 現場の若手が「A」に設定されているが、実際には予算や決定権限を持っておらず形骸化している状態
- セキュリティインシデント発生時の報告ライン（I）が多すぎて、情報漏洩の初動対応が遅れる構造
組織のガバナンスを高めるためには、「名目上のA」ではなく、「実際に事業リスクを負い、判断を下せる権限を持った人」をAに据える必要があります。これがセキュリティ監査をクリアし、本当の意味で会社を守るためのポイントなんですね。
Web解析・業務フロー視点：プロセスごとのBottle Neck（ボトルネック）可視化
少し視点を変えて、Web解析士やプロセス改善の観点からRACI/RASICを見てみましょう。
Webマーケティングや業務自動化（RPA導入など）の現場では、コンバージョンや業務処理の「離脱率」「停滞時間」を数値で分析しますよね。
業務フローの中にRASICをマッピングすると、どこが処理のボトルネックになっているかが一目で可視化できるんです。
例えば、システム申請のプロセスでデータが1週間止まっているとします。
その工程のRASICを見てみると……
- A（承認者）が多重化している（部長・本部長・役員のスタンプラリー）
- C（相談先）が広すぎて、全員のコメントを待たないと進まない
このように、プロセスの停滞は「人間の怠慢」ではなく「RASICの設計ミス（権限と相談の集中）」によって起きています。ボトルネックとなっている「A」を1人に絞り、「C」を単なる「I（事後報告）」に変更するだけで、業務スピードが5倍に跳ね上がるケースなんてザラにあるわけですよ。
現場で「生きる」RASIC/RACIマトリクスを作る5つの実践手順
ここまで読んで、「じゃあ、どうやって現場で本当に使えるマトリクスを作ればいいんだ？」と思われたことでしょう。
ここからは、私が30年の現場経験で編み出した、血の通ったRASICマトリクスを作成・運用するための5ステップを伝授します。
教科書には書いていない「泥臭いノウハウ」が詰まっていますから、ぜひ実践してみてください。
【生きたRASICを作る5つの実践ステップ】
ステップ1: WBSからタスクを漏れなく抽出（解像度を極限まで上げる）
ステップ2: 各タスクの「A」を“必ず1人”に絞り込む（社内政治を突破する）
ステップ3: 「R」と「S」のアサインと工数見積もりを完全連動させる
ステップ4: 膝詰めの「合意形成ワークショップ」を開催する（メール送信は厳禁）
ステップ5: 定例ミーティングで動的にアップデート（Excelの遺物にしない）
手順1：WBS（作業分解構成図）からタスクを漏れなく抽出する
マトリクスを作る前の下準備で、8割の成否が決まります。
よくある失敗が、「ネットワーク構築」「サーバー移行」といった大雑把な粒度でRASICを作ってしまうことです。粒度が粗いと、RACIの意味がなくなります。
まずはWBSを作成し、タスクの解像度を「誰が・何をやるかが明確に見えるレベル」まで叩き落としてください。
- ✕ 悪い例：「基幹ルータ設定」
- ◯ 良い例：「基幹ルータConfig作成」「Config事前検証」「現地パラメータ投入」「通信疎通テスト」
タスクの粒度が細かくなって初めて、「Config作成のRはベンダーだが、疎通テストのSは自社の運用チームだな」というリアルな配分が見えてくるわけです。
手順2：各タスクの「A（最終責任者）」を“必ず1人”に絞り込む
タスクが出揃ったら、いよいよマトリクスに文字を埋めていきます。
最大の難所が、この「Aを1人に絞る」作業です。
社内政治や発注元・受託側の壁が立ちはだかり、「ここはお互いにAということで……」と言いたくなる誘惑が襲ってきます。そこをグッと堪えてください。
もし調整が難航したら、以下の問いかけを自分や関係者に投げてみてください。
「このタスクが失敗して1,000万円の損害が出た時、最後に頭を下げて辞表を書くのは誰ですか？」
強烈な問いですが、これが「A」の本質です。
生殺与奪の権限と責任を持つ覚悟のある人間を、腹をくくって「たった1名」指定してください。ここを妥協すると、後で必ず炎上します。
手順3：「R（実行者）」と「S（支援者）」のアサインと工数見積もりの連動
RASICを採用する場合、「S（支援者）」を単なる「手伝い」として放置してはいけません。
マトリクスで「S」を割り当てたら、必ずプロジェクトの「工数見積もり（人日・人月）」および「スケジュール」にSの稼働を組み込んでください。
「Sなんだから、空いた時間にちょっと手伝ってよ」は通用しません。
- R（メイン実行者）：構築作業 10人日
- S（支援者）：環境構築の補助・レビュー 2人日
このように、Sの労力を「数値（工数）」として可視化して初めて、支援者は動けるようになるんですね。
手順4：ステークホルダーとの「泥臭い合意形成」ワークショップの開き方
ここ、めちゃくちゃ重要です。
完成したRASICマトリクスを、メールで「ご確認ください」と一斉送信して終わらせる人がいますが、絶対にやめてください。 100%誰も真剣に見ませんし、後で「聞いてない」と言われます。
必ず関係者を集めた「合意形成ワークショップ（対面またはオンライン会議）」を開催してください。
会議では、作成した表を画面に映し、各人に泥臭く確認していきます。
「〇〇さん、このタスクの『R』はあなたになっていますが、来月のスケジュールで本当に手を動かせますか？」
「〇〇部長、ここはあなたが『A』ですが、緊急時の判断権限を現場PMに委譲しますか？ それとも夜間でも電話に出て決断してくれますか？」
この膝詰めの会話を通して、メンバーに「自分の責任なんだ」という当事者意識（コミットメント）を植え付けるわけです。このプロセスを経ないマトリクスは、ただの紙くずですよ。
手順5：プロジェクト変更に伴うマトリクスの動的アップデート手法
プロジェクトは生き物です。仕様変更、要員の交代、スケジュールの遅延……当初の計画通りに進むことなんてあり得ません。
一度作ったRASICマトリクスを「Excelの遺物」にしないために、週次の進捗会議などで定期的に見直すルールを組み込みましょう。
「新しいサブシステムが追加されたから、タスクを追加してAとRを決めよう」
「〇〇さんが別案件で忙しくなったから、Sのメンバーを追加しよう」
このように、プロジェクトの状況変化に合わせて動的に書き換えていくことで、常に現場の「現在の役割分担」を正しく照らし出す地図として機能し続けるわけです。
【ケース別】インフラ・開発・運用現場におけるRASIC使い分け事例集
ここからは、より実践的なイメージを持ってもらうために、インフラ・システム構築の「実際の現場」を想定したケーススタディをご紹介します。
あなたのプロジェクトに似たパターンがあれば、ぜひそのまま参考にしてみてください。
【事例1】大手クラウドアカウント移行プロジェクト（RASICが威力を発揮）
既存のオンプレミス環境から、AWS/Azureなどのパブリッククラウドへシステムを移行する大規模プロジェクトです。
この手のプロジェクトは、社内インフラチーム、アプリ開発ベンダー、クラウド構築専門ベンダー、セキュリティ担当など、多くのステークホルダーが入り乱れる混成チームになります。ここで「RASIC」が絶大な効果を発揮します。
クラウド移行におけるRASIC設定例
| タスク項目 | 自社PM | クラウド構築ベンダー | アプリ開発ベンダー | 自社運用チーム |
|---|---|---|---|---|
| AWS環境・VPC基本設計 | A | R | C | S |
| アプリ移行テスト | A | S | R | I |
| 本番切り替え判断 | A | C | C | I |
| 移行後の運用引き継ぎ | A | S | I | R |
ポイントは、クラウド構築ベンダーと自社運用チームの間で「S（支援者）」を明確に相互割り当てしている点です。
構築ベンダーが設計する際、運用チームが「S」としてレビューやパラメータ提供で手伝う。逆に移行後の引き継ぎでは、運用チームが「R」となり、構築ベンダーが「S」としてバックアップする。
この「S」の相互関係をあらかじめ握っておくことで、移行後の「そんな運用聞いていない」という悲劇を防止できるわけです。
【事例2】セキュリティインシデント一次対応（シンプルなRACIが勝利する）
対照的に、ランサムウェア感染や不正アクセスといった「セキュリティインシデント発生時の緊急対応」では、「RASIC」ではなく「シンプルなRACI（むしろ一極集中）」を採用すべきです。
有事の修羅場において、「S（支援者）はどうする？」なんて生ぬるい協議をしている時間はありません。1分1秒を争う状況では、「指示を出す人（A）」と「手を動かす人（R）」の超絶シンプルなラインが必要です。
インシデント発生時のRACI設定例
| タスク項目 | CISO（最高情報セキュリティ責任者） | CSIRT（SOC）担当者 | 広報・法務部 | 外部Sier保守 |
|---|---|---|---|---|
| ネットワーク緊急遮断（LAN切断） | A | R | I | I |
| 被害範囲の一次調査 | A | R | I | C |
| 対外発表・プレスリリース | A | C | R | I |
有事の際は、「A（CISO）」に全権を集約し、「R（CSIRT）」が即座にLANケーブルを抜く。広報や外部ベンダーは「I（通知）」にとどめ、余計な口出し（C）をさせない。
このように、極限状態では「曖昧さを徹底的に排除したRACI」がチームを、そして会社を救うことになります。
【FAQ】現場から出される「よくある質問」に30年選手が本音で答える
プロジェクト現場でRACI/RASICを運用していると、メンバーや上司から様々な「困りごと」が持ち寄せられます。よくある質問に本音で回答しておきましょう。
Q1: メンバーがRASICの記号（R, A, S, C, I）を覚えてくれません。どうすればいいですか？
A: 記号を覚えさせる必要はありません。表のヘッダーに「具体的な行動」を日本語で併記してください。
「R（実行者）」と書くから分かりにくいんです。「R（実際に手を動かして作る人）」「A（最後にハンコを押す人）」「S（手伝う人）」と表の注釈に書いておけばいいんですよ。フレームワークの格好付けよりも、現場の人間が一目で理解できることの方か100倍大事です。
Q2: 上司（部長）が自分（PM）に全部『A』を押し付けてきます…
A: 「予算執行権限」と「納期遅延のリスク責任」を盾にして、巻き返しましょう。
「私がAで問題ありませんが、その場合、〇〇万円までの予算追加決定権と、納期が遅れた際の役員会への説明責任も私に委譲していただけますか？」と静かに伝えましょう。大抵の上司は「いや、それは自分がやるよ」とAを引き取ってくれます（笑）。権限のない人間にAを持たせてはいけません。
Q3: プロジェクト途中で「そのRACIは合意していない」と後からハシゴを外されました
A: 合意形成時の「議事録」と「ワークショップの参加実績」を証拠として突きつけましょう。
だからこそ「手順4」で言った対面ワークショップと議事録の残し込みが効いてくるわけです。「○月○日の会議で、〇〇さんご本人の承諾のもとRに設定し、議事録も送付しております」とクールに提示する。インフラ屋は証拠（ログ）を残してナンボですからね。
まとめ：ツールに使われるな。現場の「泥と血」を通わせたRASICを運用しよう
長々とお付き合いいただき、ありがとうございました。
最後に、30年インフラの現場で修羅場を潜り抜けてきたベテランとして、この記事で一番伝えたかったメッセージをまとめておきますね。
【この記事の要点プレイバック】
1. RACIとRASICの最大の違いは「S（支援者）」の有無。「C（助言）」と「S（作業支援）」を混同するな。
2. 「A（最終責任者）」は絶対に1名！ 複数設置は「全員無責任」と同じ地獄を生む。
3. 表を作るだけではゴミになる。対面ワークショップで「膝詰めの合意」を取り、工数（人日）と連動させよ。
4. 有事の障害対応は「シンプルなRACI」、混成チームのプロジェクトは「RASIC」を使い分けろ。
PMPや高度情報処理技術者、ISMS審査員といった資格のテキストを開けば、RACIやRASICはとても綺麗で、洗練された「素晴らしいツール」として紹介されています。
ですが、実際のプロジェクト現場は、綺麗事だけでは1ミリも動きません。
人間には感情があり、立場があり、都合があります。エクセル上に「R」や「A」と文字を打ち込むだけでは、人は動かないんですよ。
「このタスクは誰が責任を持つべきか？」
「どうすれば支援者が気持ちよく手を動かせるか？」
「泥をかぶる覚悟を持っているのは誰か？」
関係者と泥臭く対話し、泥をかぶり、血の通った合意形成を行うこと。
その「人間臭い泥臭さ」を綺麗に整理したツールこそが、本物のRASICマトリクスです。
知識や資格を振りかざして格好をつけるのは、もうやめましょう。
現場の汗を尊重し、本当の意味でプロジェクトを成功に導くために——
あなた自身の現場で、魂の通ったRASICを掲げ、反撃の狼煙（のろし）を上げてみませんか？
応援していますよ！
-
-
参考30年選手の告白！PMP知識だけでは現場が炎上する「マスタースケジュール・WBS・マイルストーン」の決定的な違いと実践使い分け術
✅この記事はこんな「疑問・悩み」を持つ方に向けた記事です・PMPの勉強中だが、「マスタースケジュール」「WBS」「マイルストーン」の実際の使い分けが曖昧でモヤモヤしている方・教科書通りにWBSを作った ...
続きを見る
