PMBOK原理・原則：テーラリング入門 〜プロジェクトに合わせて "いいとこどり" する技術〜

![マインドマップ (11).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/73fa18ca-2923-10ec-5ae4-8d06949484e4.png)

PMBOKのテーラリングについて記事を書きました。
プロジェクトマネジメントの手法は、「全部入り」でも「完全省略」でもNG。大切なのは、**プロジェクトの特性**に合わせて「**使える手法は何でも使う**」という考え方です。
金融系基幹システムのシミュレーションとしての更改事例も紹介し、要件定義・開発・管理の各フェーズでどのようにテーラリングしたかを実践的に解説しています。

## はじめに：なぜテーラリングが必要なの？
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/04de41cd-17ca-0720-afec-a3a5ff0332d9.png)

「PMBOKの手法をすべて導入しないといけない」
「アジャイルだからウォーターフォールの手法は使えない」

...こんな思い込み、ありませんか？😅

実は、プロジェクトマネジメントで大切なのは、**状況に応じて適切な手法を選択すること**。これが「テーラリング」です。

## テーラリングとは？

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/95a41433-0a67-c37a-bab0-71029bdd612b.png)

テーラリング = プロジェクトの特性に合わせて、管理手法を調整すること

洋服の仕立て（テーラリング）のように、プロジェクトにぴったりとフィットするように調整していくイメージです。

## テーラリングの3つのポイント

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/985d9169-ac31-f566-7fc1-4ffe20a22e59.png)

### 1. プロジェクトの特性を見極める

以下の要素を確認しましょう：

* **規模**：小規模なら軽めの管理、大規模なら厳格な管理
* **重要度**：影響度が大きければ慎重に
* **チーム体制**：経験値や人数に応じて
* **制約条件**：納期、予算、品質要件など

### 2. 適切なアプローチを選択する

🔄 **アジャイル的アプローチ**
* 要件が流動的
* 頻繁な変更が予想される
* 顧客との密接な協業が可能

📋 **ウォーターフォール的アプローチ**
* 要件が明確
* 変更が少ない
* 契約での縛りが強い

💡 **ポイント：両方のいいとこどりもアリ！**

### 3. 調整のシミュレーション例

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/a88030a0-52d7-b661-8f8c-6d07421da30a.png)

## 実践的なテーラリング例：金融系基幹システムの更改

例えば、次のようなシミュレーションとしてのプロジェクトをもとに、テーラリングの実例を考えてみました。

**プロジェクト概要**
- 20年稼働した勘定系システムの刷新
- 開発規模：200人月
- 期間：2年
- 予算：10億円

**直面した課題**
- 古いシステムの仕様が不明確
- 運用部門が働き方改革で残業削減
- 新人が多く、ナレッジ不足
- パッケージ導入とスクラッチ開発の混在

**テーラリングのポイント**

1. **フェーズごとの使い分け**
```
【要件定義フェーズ】
Before：
- ウォーターフォールで一気に固める
- 複数部署の承認が必要
- 属人的な運用をそのまま踏襲

After：
- プロトタイプを使った要件の可視化
- 3週間単位で優先度の高い業務から定義
- 運用手順の標準化を同時に実施
```

2. **開発アプローチの最適化**
```
【パッケージ導入部分】
- 導入ベンダーの開発手法を採用
- データ移行は独立したサブプロジェクト化
- 受入テストを重点的に実施

【スクラッチ開発部分】
- 2週間スプリントのスクラム開発
- ユニットテストの自動化を徹底
- CIツールでの品質チェック
```

3. **プロジェクト管理の工夫**
```
【進捗管理】
- パッケージ：マイルストーン管理
- スクラッチ：バーンダウンチャート

【コミュニケーション】
- 朝会は週3回に削減（リモート併用）
- チャットで日次の進捗共有
- 月1回の全体報告会
```

**成果と学び**
- 要件定義の期間を当初の8ヶ月から6ヶ月に短縮
- 運用部門の残業時間30%削減
- 若手エンジニアの成長を促進

**成功の秘訣**
1. 開発手法を「目的」で選ぶ
   - 要件が不明確→プロトタイプ
   - 品質重視→自動テスト
   - 納期重視→アジャイル

2. チームの特性を考慮
   - 新人が多い→ペアプロ導入
   - リモートワーク→非同期コミュニケーション
   - ベンダー混在→インターフェース定義を厳格に

3. 定期的な振り返り
   - 月次でテーラリングの効果を検証
   - 半期で大きな見直し
   - 失敗も共有して改善

## テーラリングのコツ

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/0b09084b-bd56-81a0-d05e-7a85977d0945.png)

1. **段階的に調整する**
   * いきなり大きく変えずに、小さく始める
   * 効果を見ながら微調整

2. **チームの意見を聞く**
   * 現場の実態に合わせる
   * 押し付けは逆効果

3. **定期的に見直す**
   * 固定化しない
   * 状況変化に応じて柔軟に

## よくある失敗パターン

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/7c93633f-2b23-c853-26ec-3fe6e7619894.png)

❌ **過剰な形式主義**
「PMBOKに書いてあるから」と、不要な文書も作成

✅ **改善策**
本当に必要な成果物を見極める

❌ **極端な簡略化**
「アジャイルだから」と、必要な管理も省略

✅ **改善策**
最低限必要な管理は維持する

## まとめ

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2648069/69549105-2846-7b9e-dd8a-b5b3b8a33994.png)

テーラリングの本質は、**プロジェクトに合わせて、使える手法は何でも使う**という考え方。

堅苦しく考えず、チームと相談しながら、より良い進め方を探っていきましょう！

最後に、テーラリングを始める時のチェックリストをどうぞ 🎁

- [ ] プロジェクトの特性を整理した？
- [ ] チームの意見を聞いた？
- [ ] 段階的な導入を計画した？
- [ ] 定期的な見直しの機会を設定した？

では、みなさんのプロジェクトが、よりスムーズに進むことを願っています！✨