⑮ 孫子の兵法をPMOのRACI表に翻訳する—古典×現代フレームワークの実践読書ガイド【Salesforce×PMO×孫子】

なぜ孫子とRACI表なのか

孫子の兵法の核心の一つは、「誰が何の役割を担うかを明確にすること」で組織の力を最大化するという発想にあります。将軍・参謀・兵士それぞれの役割が曖昧な軍は、どれだけ兵力があっても機能しません。

これは、現代のプロジェクトマネジメントにおけるRACI表の思想と本質的に同じです。RACI表が明確でないプロジェクトは、Salesforce実装のような複数部門・複数ベンダーが関わる案件において、特に混乱を招きやすくなります。

孫子の原則をRACI表設計に翻訳する

「将とは、智・信・仁・勇・厳なり」→ Accountable（説明責任者）の要件

孫子は将軍に求められる資質として、知恵・信頼・仁徳・勇気・厳格さを挙げています。これをPMOに置き換えると、RACI表の「A（説明責任者）」に据える人物は、単に役職が高いだけでなく、この5要素をバランス良く備えている必要があるという示唆になります。特に「信」（メンバーからの信頼）が欠けたAは、形式上の承認者に過ぎなくなり、意思決定の質が落ちます。

「衆を治むること寡を治むるが如くなるは、分数是なり」→ Responsible（実行責任者）の分割設計

大人数の組織を少人数のように統制できるのは、組織を適切に分割しているからだ、という孫子の原則は、RACI表における「R（実行責任者）」の粒度設計に直結します。Salesforceプロジェクトで実行責任者を大きな単位（例：「開発チーム全体」）でしか設定していないと、誰が実際に手を動かすのかが曖昧になります。機能単位・コンポーネント単位までRを分割することが、孫子の言う「分数」の実践です。

「上下の欲を同じくする者は勝つ」→ Consulted（協議先）の設計

上下が同じ目標を共有している組織が勝つ、という原則は、RACI表の「C（協議先）」を誰にするかという設計に応用できます。単に役職上の上位者を協議先に置くのではなく、そのプロジェクトのゴールに対して本当に当事者意識を持っている人物を協議先に据えることで、形骸化した合議を避けられます。

「兵を知る者は、動きて迷わず、挙げて窮せず」→ Informed（報告先）の情報設計

状況を正確に把握している者は迷わず行動できる、という原則は、RACI表の「I（報告先）」の設計思想そのものです。情報が届くべき人に、適切なタイミングで届いていない組織は、いざという時に迷いが生じます。Informedの範囲を「念のため全員に共有」で済ませるのではなく、本当に必要な相手に絞り込むことも、孫子的な情報設計の一部です。

実践：Salesforce導入プロジェクトでのRACI表サンプル

Amazon Connect / Agentforce Voice導入プロジェクトを例にすると、次のような設計が考えられます。

| タスク | R | A | C | I |
|---|---|---|---|---|
| 通話ルーティング要件定義 | コールセンター運用リード | PMOリード | Amazon Connect技術リード | 経営スポンサー |
| Agentforce Voice AI応答チューニング | AIチューニング担当 | PMOリード | オペレーター代表 | プロジェクト全メンバー |
| 本番カットオーバー判断 | PMOリード | 経営スポンサー | 全技術リード | 全プロジェクトメンバー |

このように役割ごとに粒度を変えることで、孫子の言う「分数」の思想を反映した、機能する組織設計に近づきます。

まとめ：古典は"翻訳"することで初めて実務の武器になる

孫子の言葉をそのまま暗唱しても、現代のプロジェクトマネジメントには直接使えません。しかし、RACI表のような具体的なフレームワークに"翻訳"することで、2500年前の原則は今も色褪せない実務ツールになります。

<関連書籍>
「拙速」の一節を実際に確認したい方向け
▶『新訂 孫子』 著：孫武／訳：金谷治／岩波文庫
最も定番の訳書。文庫で安価

[Amazonで見る]

<関連記事>

この記事が参考になったら、スキ・フォローをお願いします。