プロジェクトマネジメント

プロジェクトマネジメントの出発点は、成果物と範囲をはっきりさせることです。ここが曖昧なまま走り出すと、後工程で「これは含む／含まない」の争いが起き、納期も予算も崩れていきます。PMはまず、依頼元（発注者やスポンサー）と目的をすり合わせ、達成状態を言葉にして残します。

この段階で使われる代表的な成果物が、プロジェクト憲章とスコープ記述書です。憲章は「なぜやるか・誰が責任を持つか」を一枚で示す出発点の文書で、スコープ記述書は「何を作り、何は作らないか」を線引きします。判断の軸は品質・コスト・納期の三つ（安全を加えて四つと置く現場もあります）で、この三つは互いに引っ張り合う関係にあります。

• 目的の言語化：売上を上げたい、業務を効率化したいといった漠然とした要望を、検収できる成果物の形に翻訳します。
• 範囲の線引き：やることリストだけでなく、やらないことも明記して、後からの上乗せ依頼に備えます。

つまずきやすいのは、依頼元の「当然これも入っているよね」という暗黙の期待です。書面に残らない期待は後で食い違いの火種になりやすいので、口頭合意も議事録に落としておくと安全です。

多くのプロジェクトは、立ち上げ・計画・実行・監視コントロール・終結という流れで進みます。厳密な段階分けはPMBOKなどの体系に譲りますが、現場の感覚としてはこの順で山を越えていくイメージです。

計画では、成果物を作業の単位まで分解し、順番と所要期間を見積もります。作業の依存関係をつなぐとクリティカルパス（最も余裕のない経路）が見え、ここが遅れると全体が遅れます。担当と責任はRACIのような表で整理し、「誰が実行し、誰が承認するか」の抜けを潰します。進捗はマイルストーンとガントチャートで見える化し、週次などの定例で差分を確認していきます。

• 作業分解：大きな塊のままでは見積もれないため、担当者が着手できる粒度まで割ります。
• 進捗管理：計画線と実績線を並べ、ずれの原因を早めに掘ります。報告の数字だけを鵜呑みにしないのがコツです。

実行中は、変更依頼が必ずと言っていいほど発生します。ここで効くのが変更管理で、影響範囲と工数を見積もってから受けるか断るかを決めます。言われるまま取り込むと、いつの間にか当初の範囲を超え、デスマーチに近づいていきます。

プロジェクトは、立派な計画を作った時点ではなく、運用の途中で崩れることが多いものです。理由はいくつかあり、代表的なものを軸で挙げます。

• 進捗の実態が見えない：「だいたい終わりました」という自己申告は、残り作業が読めていないことが少なくありません。完了の定義を事前に決めておくと、報告のブレが減ります。
• リスクを先送りする：起きてから動くと選択肢が狭まります。起こりそうな事象を早めに洗い出し、予兆と対応策を用意しておくと、慌てずに済みます。
• 関係者の合意が薄い：決めたつもりが決まっていない状態です。誰の承認が必要かをステークホルダー整理で押さえ、意思決定の場を先に確保しておきます。

もう一つ見落とされがちなのが、チーム内の負荷の偏りです。特定の担当に作業が集中すると、そこがボトルネックになり、工数管理上は余裕があるように見えても実際は詰まります。PMは数字の裏にある実態を、雑談や一対一の会話から拾っておくとよいでしょう。こうした運用の地味な積み重ねが、終盤の余裕を左右します。

プロジェクトマネジメントは広い言葉なので、隣接する概念と混ざりやすいところがあります。軸を「何を指すか」に置いて整理します。

• PMBOKとの関係：PMBOKはプロジェクトマネジメントの知識を体系化したガイドで、実務そのものではなく参照する地図にあたります。現場はその中から自分たちに合う部分を選んで使います。
• アジャイルとの関係：アジャイル開発やスクラムは、計画を固めてから進めるウォーターフォールに対し、短い反復で作りながら調整する進め方です。どちらもプロジェクトマネジメントの一形態で、対立ではなく使い分けと捉えるのが自然です。
• 進捗管理との関係：進捗管理はプロジェクトマネジメントの一部です。全体がマネジメントで、その中の進み具合を見る活動が進捗管理、と包含関係で理解しておくと混乱しません。

つまずきやすいのは、手法の名前にこだわりすぎて、目的を見失うことです。ウォーターフォールかアジャイルかは、扱う対象の不確実性や関係者の事情で選ぶものです。どの型でも、品質・コスト・納期をどう折り合わせるかという中心の問いは変わりません。

プロジェクトマネジメントの基本は、業界や開発手法が変わっても持ち運べる土台になります。範囲を線引きし、作業を分解し、進捗とリスクを見ながら関係者の合意をつなぐという一連の型は、SIerでもDX推進でも共通して問われる部分です。転職を検討する場面では、この型を自分の言葉で語れるかどうかが、経験の説明力に効いてきます。

具体的には、担当したプロジェクトで何を線引きし、どのつまずきをどう収束させたかを、成果物と役割の粒度で説明できると伝わりやすくなります。手法の名前を並べるより、判断の軸と対応の中身を語るほうが、実務の厚みが見えやすいと考えられます。自分の強みがどの職域にあるかを整理する足がかりとして使ってみてください。

プロジェクトマネジメントとプロジェクトマネージャーはどう違いますか。

プロジェクトマネジメントは、期限のある取り組みを計画・統制する活動そのものを指します。プロジェクトマネージャー（PM）は、その活動の中心となって責任を持つ人の役割です。活動と担い手の関係だと考えると整理しやすいでしょう。

資格は必要ですか。

PMBOKなどの体系を学ぶ資格は、共通言語や基本の流れを身につける助けになります。ただし実務は現場ごとに事情が異なるため、資格だけで進められるわけではありません。知識の土台として活かし、経験と合わせて磨いていく位置づけが現実的です。

小さなプロジェクトでも必要ですか。

規模が小さくても、目的・範囲・期限があるなら基本の考え方は役立ちます。憲章や詳細な計画書まで作らなくても、何を・いつまでに・誰がやるかを短く決めておくだけで、途中の食い違いを減らせます。規模に応じて重さを調整するとよいでしょう。