PMBOK原理・原則：システム思考：プロジェクト全体を俯瞰する力

システム思考に関する記事を投稿しました📝
PMBOKの「システム思考」について、実践的な観点からまとめてみました。
ポイントは3つ：

プロジェクト全体を俯瞰する視点
チーム間の関係性を把握
早期のリスク発見

特にソフトウェア開発では、マイクロサービスの連携など複雑な依存関係の理解に役立ちます。
興味のある方はぜひご覧ください🤓
![マインドマップ (6).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/7fe0a1b4-6938-4f58-0e74-f2ec03bd5efc.png)


### はじめに
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/3ff289c7-6a78-abf4-e5c9-dacc7e8aa91e.png)

PMBOK（Project Management Body of Knowledge）の原理・原則のひとつに「システム思考」というものがあります。

「うーん、PMBOKか…なんか難しそう」って思うかもしれませんが、これはプロジェクト全体を“俯瞰”するためのとっても大事な考え方。
ソフトウェア開発やインフラ構築などで、あちこちに散りばめられたタスクや依存関係を一元的に捉える視点を得られます。

---

### 1. そもそもシステム思考って何？

![systems-thinking-comparison.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/6363cc33-1a2f-ab10-b48a-c4e7c216662d.png)

- **全体を“システム”として捉える力**  
  - 「要素をバラバラではなく、相互に関連するしくみとして捉える」という考え方。  
  - いわゆるモジュール・サービス・インフラ・チームなど、プロジェクトに関わるものを俯瞰して見る。

- **みんなやりがちないくつかの失敗例**  
  - 「API仕様変更に気づかず、フロント側でエラー祭り」  
  - 「サブシステムのバージョンアップがメインシステムに影響することを見落として、リリース直前で大慌て」  
  - 「Aチームは最高の成果物を作ったのに、Bチームとは連携ミスで動かない」  
  こうした問題は“要素を全体として把握できていない”ことが原因のひとつです。

---

### 2. システム思考がプロジェクトに効くポイント

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/0649e742-db0b-2ff3-6442-8170657973eb.png)

#### (1) リスクの早期発見と対応
- たとえばマイクロサービス構成でのプロジェクト。
- それぞれが独立したサービスでも、あるサービスがダウンすると関連サービスも巻き込むことがあります。
- システム思考を意識して全体図を把握しておけば、どこを手当すれば影響を最小にできるか早く気づける。

#### (2) コミュニケーションをスムーズにする
- どのチームがどのサービス・モジュール・要件を担当しているのか一目で分かるようにしておく。
- 「この仕様はUXチームにも影響があるから共有しておこう」「あっちのコンポーネントに手を入れる前にSREチームに連絡が必要」など、**ステークホルダー間のつながり**が明確になる。

#### (3) 全体最適がしやすい
- “局所最適”になりがちなタスクも、全体で見たらコスト・リソースを食いすぎる場合もある。
- システム思考があれば、品質・コスト・納期などのバランスをとりやすい。
- 例：高機能APIを作ったけど、社内向けにそこまで要らなかった…→工数とコストが無駄に、なんてことを減らせる。

---

### 3. 具体例：マイクロサービスのシステム思考

```mermaid
graph TB
    subgraph Frontend
        UI[User Interface]
    end

    subgraph Backend Services
        Auth[認証サービス]
        Profile[User Profileサービス]
        Payment[決済サービス]
        Analytics[分析サービス]
    end

    subgraph Data Stores
        AuthDB[(認証DB)]
        ProfileDB[(プロファイルDB)]
        PaymentDB[(決済DB)]
        AnalyticsDB[(分析DB)]
    end

    UI --> Auth
    UI --> Profile
    UI --> Payment
    
    Auth --> AuthDB
    Profile --> ProfileDB
    Profile --> Auth
    Payment --> PaymentDB
    Payment --> Auth
    Analytics --> Auth
    Analytics --> PaymentDB
    Analytics --> ProfileDB

    classDef service fill:#f9f,stroke:#333,stroke-width:2px
    classDef database fill:#beb,stroke:#333,stroke-width:2px
    classDef frontend fill:#bbf,stroke:#333,stroke-width:2px
    
    class Auth,Profile,Payment,Analytics service
    class AuthDB,ProfileDB,PaymentDB,AnalyticsDB database
    class UI frontend
```

#### 例：マイクロサービス構成

- **Auth サービス**：ユーザー認証を司る  
- **User Profile サービス**：ユーザー情報を管理  
- **Payment サービス**：決済処理  
- **Analytics サービス**：ログやイベントを集計・分析  
- **Frontend**：実際にユーザーが触るUI  

#### ありがちな問題とシステム思考の対策

1. **Auth サービスの仕様変更**  
   - JWTトークンの形式を変更。  
   - **User Profile サービス**が認証情報を取り扱えなくなる → APIで401エラー連発。  
   - Frontendがユーザー情報を取得できず真っ白画面に。

2. **Payment サービスのDBスキーマ変更**  
   - テーブルを分割し、カード情報を別管理に。  
   - **Analytics サービス**が直接参照していたDBがなくなる → イベント集計が止まる。

3. **新しいFrameworkでFrontendを刷新**  
   - ビルドやリリースフローが大幅に変更。  
   - CI/CDのパイプラインが壊れる → そもそも本番リリース不可。

#### 解決策

- **マイクロサービス間の依存関係マップを作る**  
- **仕様変更やリリース時のレビューを“システム思考”で実施**  
- **全体が連携する“監視・アラート”を設定**  

---

### 4. システム思考を養う5つのステップ

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/17382e75-a01b-de36-f605-41c597fb5cc2.png)

1. **ステークホルダー・システム要素を可視化する**
2. **依存関係を洗い出す**
3. **変化に備える“バージョン管理”や“リリース管理”を徹底**
4. **問題が起きたら、影響範囲を広い視点で検証**
5. **定期的に全体レビューを行う**

---

### 5. PMBOKっぽい落としどころ

- **計画策定時**：プロジェクトマネジメント計画書に「システム全体の構造や利害関係人（ステークホルダー）を整理した章」を設ける。
- **コミュニケーション計画**：システム思考を踏まえて「どこがどこに情報共有するか」を可視化しておく。
- **リスクマネジメント**：関連サービスやチームの横のつながりを見落とさず、リスクを早めに洗い出す。

---

### まとめ

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/ff0609af-a875-8192-1cd1-c864f3995712.png)

- **システム思考** = 全体としてプロジェクトを捉え、要素の相互関係を把握する力。
- ソフトウェア開発では、マイクロサービスやクラウド環境など複雑な構成が増え、依存関係を無視すると大混乱に陥りがち。
- PMBOKの一要素としても、アジャイルやDevOpsとの組み合わせでも、システム思考を持っておくとリスクが減り、コミュニケーションもしやすくなる。

「パーツを単体で完璧にする」だけでなく、「全体の流れがスムーズにいくか」を考える——
これがプロジェクト成功への一歩となります。