IT業界で働き始めると、避けては通れないのが「プロジェクト」という言葉です。新システムの開発やアプリのアップデートなど、私たちの仕事のほとんどはプロジェクト単位で進みます。
しかし、勢いだけで進めると、納期に間に合わなかったり、予算が足りなくなったりといったトラブルが必ず起きます。そこで必要になるのが、先人の知恵を体系化した「プロジェクトマネジメント」という技術です。
本稿では、プロジェクトの正体から、管理の5つのステップ、そして現場で必須の「WBS」や「ガントチャート」といった武器の使い方まで徹底解説します。
第1章：そもそも「プロジェクト」とは何か？
普段のルーチンワーク（定型業務）とプロジェクトは何が違うのでしょうか。PMI（米国プロジェクトマネジメント協会）などの定義を噛み砕くと、2つの大きな特徴があります。
1-1. プロジェクトの2大特徴
- 有期性（終わりがある）: 「いつか終わる」ものです。開始日と終了日が決まっており、永遠に続く活動ではありません。
- 独自性（初めての試み）: 「今回だけの特別な成果」を作ることです。全く同じものを全く同じ条件で作ることは二度とありません。
1-2. なぜ管理が難しいのか？
プロジェクトには「不確実性」がつきまといます。
- やってみないとわからない: 独自の試みなので、途中で予想外のトラブルが起きやすい。
- 制約がある: 「お金（予算）」「人（リソース）」「時間（納期）」という限られた枠の中で結果を出さなければなりません。
第2章：プロジェクト成功の「ものさし」と5つのステップ
プロジェクトが「成功した」と言えるためには、単に完成させるだけでは不十分です。
2-1. 成功を測る4つの視点
- 納期（Time）: 期限内に終わったか？
- コスト（Cost）: 予算内に収まったか？
- 品質（Quality）: 求められた性能を満たしているか？
- 顧客満足: お客さんが「これ欲しかったやつだ！」と喜んでいるか？
2-2. 5つの標準プロセス（流れ）
プロジェクトは以下の5つのフェーズを順番に（時には重なりながら）進みます。
- 立ち上げ: 「何のためにやるか」を決め、プロジェクトの憲章（公式な許可証）を作ります。
- 計画: 「誰が、いつまでに、何を、どう作るか」という詳細な地図を書きます。
- 実行: 計画に基づいて、実際に手を動かして作ります。
- 監視・管理: 計画からズレていないかチェックし、ズレていたら軌道修正します。
- 終結: お客さんに納品し、チームを解散します。
第3章：マネジメントを支える10の知識エリア
プロジェクトをコントロールするために、管理すべき領域は10個に細分化されています。これを「知識エリア」と呼びます。
3-1. 基本の3軸：スコープ・スケジュール・コスト
- スコープ管理: 「どこまでやるか（範囲）」を決めます。これがあやふやだと、作業が無限に増えてパンクします。
- スケジュール管理: カレンダー通りに進むよう時間を管理します。
- コスト管理: お金（予算）の使い道と残高を管理します。
3-2. 質と人を支える：品質・資源・コミュニケーション
- 品質管理: バグがないか、使いやすいかを確認します。
- 資源管理: メンバーのスキルや、必要な機材・会議室などを手配します。
- コミュニケーション管理: 「言った・言わない」を防ぎ、必要な情報を適切な人に届けます。
3-3. 外の世界と向き合う：リスク・調達・ステークホルダ・統合
- リスク管理: 「もしPCが壊れたら？」「メンバーが病欠したら？」といった不測の事態に備えます。
- 調達管理: 外部の会社に手伝ってもらう際の契約などを管理します。
- ステークホルダ管理: お客さんや上司など、プロジェクトに影響を与える人たちと良い関係を築きます。
- 統合管理: 上記の全てをバラバラにせず、一つのプロジェクトとしてまとめ上げます。
第4章：現場で使う「最強の武器（技法）」
プロジェクトマネージャが実際に使っている、状況を可視化するための道具を紹介します。
4-1. 作業の分解図「WBS」
WBS（Work Breakdown Structure）は、大きな目標を小さく、小さく分解して、担当者が「今日何をやればいいか」わかるレベルまで落とし込んだ図です。
- 木の枝のように広がる構造で、漏れやダブりがないかチェックします。
4-2. 進捗の見える化「ガントチャート」
縦軸にタスク、横軸に時間をとった棒グラフです。
- 「今、どの作業が遅れているか」が誰の目にも明らかになります。
4-3. 順序のパズル「アローダイアグラム（PERT図）」
タスクを矢印で繋ぎ、作業の順番（Aが終わらないとBが始められない等）を整理した図です。
- クリティカルパス: 一番時間がかかる経路のことです。ここが「1日」遅れると、プロジェクト全体の終了日も「1日」遅れます。絶対に遅れられない「急所」を見つけるために使います。
第5章：リスクへの「構え」と見積もりの技術
5-1. リスクに対する4つの戦略
悪いことが起きそうなとき、プロはこう動きます。
- 回避: 危険な道を通らない（例：難しすぎる機能の実装を諦める）。
- 軽減: ダメージを小さくする（例：テストを増やしてバグを早めに見つける）。
- 転嫁: 誰かに肩代わりしてもらう（例：保険に入る、専門業者に任せる）。
- 受容: 覚悟を決めて受け入れる（例：予備のお金や時間を確保しておく）。
5-2. システム開発の「お見積り」
「どれくらい大変か」を予測する手法です。
- ステップ数法: プログラムの行数で予測します（昔ながらの手法）。
- ファンクションポイント（FP）法: 画面の数やボタンの複雑さなど、システムの「機能」に着目して点数をつけ、規模を測ります。言語に左右されないため、現代では主流です。
結論：プロジェクトマネジメントは「チームの安心感」を作る
プロジェクトマネジメントは、決して「メンバーを管理・監視する」ためのものではありません。
それは、「不確実な未来に対して、少しでも見通しを良くし、チーム全員が安心してゴールに向かえるようにする」ための技術です。
WBSで作業を整理し、ガントチャートで進捗を共有し、リスクに備える。こうした基本を一つずつ積み重ねることで、プロジェクトは「奇跡」ではなく「計画」として成功に導くことができます。
ITパスポート試験などで学ぶ知識は、実務という戦場に出るための「地図」になります。まずは自分の身の回りの小さなタスクをWBSで分解することから、プロジェクトマネジメントの第一歩を踏み出してみましょう。
