PMBOKとは？プログラマー・SEが知っておくべき理由
PMBOK（ピンボック）とは、「Project Management Body of Knowledge」の略で、日本語では「プロジェクトマネジメント知識体系ガイド」と呼ばれています。
一言で言えば、プロジェクトを成功に導くための知識・考え方・手法を体系的にまとめたガイドラインです。
PMBOKは、アメリカのPMI（Project Management Institute）が策定しており、世界中のプロジェクトマネジメントの共通言語として使われています。
「PM向けの難しい理論書」というイメージを持たれがちですが、実はプログラマーやSEこそ知っておくと現場が楽になる知識が詰まっています。
私自身、開発メンバーとして複数のプロジェクトに関わる中で、「なぜこのプロジェクトは混乱するのか」「なぜ毎回スケジュールが崩れるのか」という疑問を持っていました。その答えを体系的に示してくれたのがPMBOKでした。
PMBOKの全体像をわかりやすく解説
PMBOKは、大きく分けて以下の2つの軸で構成されています。
-
プロジェクトマネジメント・プロセス群
-
知識エリア（ナレッジエリア）
プロセス群とは何か？
PMBOKでは、プロジェクトの流れを以下の5つに分類しています。
-
立ち上げ
-
計画
-
実行
-
監視・コントロール
-
終結
これは「ウォーターフォール前提」というより、どんな開発手法でも共通する思考の流れだと理解するとわかりやすいです。
私が新人SEだった頃、「設計が終わったと思ったら仕様変更が入る」「いつの間にかスケジュールがずれている」という状況に振り回されていました。
後からPMBOKを学んで気づいたのは、計画と監視がほぼ機能していなかったという点です。
知識エリアとは？現場に直結する10の視点
PMBOKでは、プロジェクト管理に必要な知識を以下の知識エリアに整理しています。
-
統合マネジメント
-
スコープマネジメント
-
スケジュールマネジメント
-
コストマネジメント
-
品質マネジメント
-
資源マネジメント
-
コミュニケーションマネジメント
-
リスクマネジメント
-
調達マネジメント
-
ステークホルダーマネジメント
プログラマーやSEにとって特に重要なのは、スコープ・スケジュール・リスク・コミュニケーションの4つです。
【体験談】PMBOKを知らずに炎上したプロジェクトの話
私がSEとして参加したある業務システム開発では、要件定義が曖昧なまま開発がスタートしました。
-
「ついでにこの機能も追加してほしい」
-
「やっぱり仕様を変えたい」
という要望が次々に入り、最終的には残業続きの炎上案件になりました。
当時は「顧客の要望だから仕方ない」と思っていましたが、PMBOKを学んだ後に振り返ると、これはスコープマネジメントの欠如でした。
スコープを定義し、変更管理のルールを決めていれば、
-
影響範囲の説明
-
スケジュールやコストへの影響提示
ができ、無秩序な仕様追加を防げたはずです。
PMBOKを知っていると何が変わるのか？
1. 「なぜこうなるのか」を説明できるようになります
PMBOKを知ると、プロジェクトの問題を感覚ではなく言語で説明できるようになります。
-
「これはリスク管理ができていません」
-
「スコープが明確でないまま進んでいます」
このように説明できるだけで、上司やPMとの会話がスムーズになります。
2. 無理な要求に理論でブレーキをかけられます
PMBOKは「断るための理論」でもあります。
私自身、「その変更は可能ですが、スケジュールとコストに影響があります」と冷静に説明できるようになったことで、精神的な負担が大きく減りました。
3. プログラマーでも視座が一段上がります
PMBOKを理解すると、自分のタスクだけでなく、
-
プロジェクト全体
-
他メンバーの状況
-
ビジネス上の制約
を意識して行動できるようになります。
これは評価やキャリアアップにも直結します。
プログラマー・SE向けPMBOKの実践的な使い方
タスク管理にスケジュールマネジメントを使う
スケジュールマネジメントというとガントチャートを思い浮かべがちですが、個人レベルでも使えます。
-
作業を細かく分解する
-
依存関係を意識する
-
バッファを持つ
これだけで、タスクの見積もり精度が上がります。
リスクマネジメントをコードレビュー前に使う
私は最近、「リリース前に起こりそうな問題」をあらかじめ洗い出すようにしています。
-
仕様の理解違い
-
テスト不足
-
環境差異
これも立派なリスクマネジメントです。
【応用編】PMBOK × アジャイルでさらに便利にする
PMBOKはウォーターフォール向けと思われがちですが、アジャイル開発とも十分に組み合わせられます。
例えば、
-
スプリント計画 → 計画プロセス群
-
レトロスペクティブ → 監視・コントロール
-
バックログ管理 → スコープマネジメント
というように、PMBOKを「考え方の土台」として使うと、アジャイルの実践が安定します。
私はこの考え方を取り入れてから、
「アジャイルなのに行き当たりばったり」な開発から抜け出せました。
PMBOKは資格のためではなく、現場を楽にするための知識
PMBOKというとPMP試験を思い浮かべる人も多いですが、資格取得が目的でなくても十分価値があります。
-
炎上しやすい人ほど効果がある
-
若手SEほど早く知るべき
-
プログラマーのキャリアを広げてくれる
これは、私自身が実感していることです。
まとめ：PMBOKを知ることは「守備力」を高めること
PMBOKは、派手なスキルではありません。
しかし、トラブルを未然に防ぎ、無駄な消耗を減らす守備力を確実に高めてくれます。
プログラマーやSEとして、
-
「なぜいつも忙しいのか」
-
「なぜプロジェクトがうまくいかないのか」
と感じている方ほど、PMBOKの考え方は強い味方になります。
まずは「スコープ」「スケジュール」「リスク」という言葉を意識するところから、ぜひ取り入れてみてください。
コメント