「プロジェクトマネジメント」という言葉はよく耳にするけれど、実際に現場では何をしているのか？この疑問はITプロジェクトに携わる多くの人が抱くものです。人間が作業している以上、計画通りに進まないケースは本当に多いですし、ずるずるとプロジェクトが迷走してしまうケースも少なくありません。
そのため、PM / プロジェクトマネージャー（以下プロマネ）は重要な役割を担っています。プロマネには、プロジェクトのQCD（Quality：品質、Cost：コスト、Delivery：納期）を確実に守るために、計画を構造的に立て、状況を正しく把握し、チームの作業を円滑に進めるサポートを行い、課題解決やリスク対策に取り組むことが求められます。
JQでは、このプロマネの業務を「計画を構造的に立てること」「状況を正しく把握し、皆の作業が円滑になるようにサポートすること」「課題解決やリスク対策を行うこと」の大きく3つ柱に分類しています。この記事では、プロマネが日々実践している具体的な業務内容について、JQ流の視点から詳しく解説します。
PM業務の３つの柱
プロマネの基本業務は、以下の3つの柱によって構成されています。
計画を構造的に立てること：プロジェクトの目的やスコープ、体制、スケジュールを明確にし、計画書を作成する業務です。人間が作業している以上、完璧な計画は不可能ですが、JQでは構造的で網羅的な計画を策定することを重視しています。
状況を正しく把握し、皆の作業が円滑になるようにサポートすること：進捗管理や課題管理、リスク管理、品質管理、変更管理などの管理業務と、会議運営やコミュニケーションなどの運営業務です。チームが迷うことなく業務を遂行できる環境を整えることが重要です。
課題解決やリスク対策を行うこと：プロジェクトのQCDに影響を与える課題やリスクを積極的に解決する推進業務です。システム間やベンダー間のスコープが不明確な課題については、プロマネが積極的に解決に取り組みます。
これらの業務を通じて、プロマネはプロジェクトの成功に導く役割を果たします。JQでは、この3つの柱をバランスよく遂行することが、プロマネに求められる必須スキルと位置付けています。
プロジェクト計画実務
プロマネの最初の業務は、計画を立案することです。計画実務では、プロジェクト全体の計画から各工程の詳細な作業計画までを作成します。
プロジェクト全体の計画
プロジェクトがスタートする時、プロマネはまず全体像を明確にする計画を作成します。この計画では、「なぜこのプロジェクトを行うのか」「何を開発するのか」「どのように進めるのか」といった根本的な問いに対する答えを整理します。
具体的には、プロジェクトの最終目標（why）を定め、何を開発するのか（what to build）、どのような作業が必要になるのか（what to do）を明確にします。そして、誰がどのような役割を担うのか（by whom）、いつ完了するのか（when）、どこで作業を行うのか（where）といった実行面での計画も立てます。
また、プロジェクトには必ずリスクが伴います。どのようなリスクが想定されるのか、どう対処するのか（how）を事前に考えておくことも重要です。さらに、プロジェクト全体の管理・運営の方針（how）も計画に盛り込みます。
各工程の計画
プロジェクトの進行にあわせて、各工程の詳細な計画に取り掛かります。要件定義や基本設計などの各工程では、工程ごとの目的やゴールを設定し、具体的な進め方を計画します。
プロジェクト開始時に策定した計画も、実際の開発が進むにつれて変更が必要になることがあります。特に開発スコープについては、ビジネス要件の変化や解像度が高まった結果、また、技術的な課題の発生によって変更が必要になるケースが少なくありません。
各工程では、その工程に特化した具体的な作業内容や成果物、担当者の役割、週次のスケジュールなどを詳細に計画します。また、その工程で使用する作業環境や、発生が予想されるリスクとその対策、工程ごとの管理プロセス・ルールなども明確にします。例えば、基本設計工程と詳細設計工程では成果物が異なるため、品質管理として定めるレビュープロセスも変わってきます。変更管理も基本設計開始時と詳細設計開始時では、管理対象の成果物が変わってきます。
テスト計画
システム開発において、テストは非常に重要なフェーズです。テストの成功はプロジェクト全体の品質を左右するため、綿密な計画が不可欠です。
テストの全体計画
プロジェクトの特性に合わせたテスト全体の計画を作成します。システムの構成や連携する他のシステムの状況など、そのプロジェクト特有の事情を踏まえて、各テスト工程で、どのようなテストを行うのかを計画します。
テストの種類と内容
単体テスト、内部結合テスト、外部結合テスト、システムテスト、ユーザー受入テストなど、テストの種類ごとにスコープと内容を明確に定義します。単体テストではどこまでやるのか、例えば画面単体の確認は何をするのか。内部結合テスト、外部結合テストはどこまでつなげてテストするのかなど、各テストではどこまで何をするのか、その全体像を明らかにします。
テスト体制とスケジュール
各テスト工程の体制や発注側、ベンダー側の役割・責任範囲を定義します。また、各テスト工程の準備はいつから行うのか、いつから実施するのか、などのスケジュール、テスト開始・終了条件を策定します。
テスト環境の計画
テストに使用する環境も重要です。特に複数のテストを並行して行う場合は、テスト環境を複数用意する必要があるかもしれません。またテスト実施環境だけではなく、テスト実施環境に資源を反映する前の検証環境も必要です。システムテストのうち、性能テスト等では本番環境相当の環境が必要になります。このように、どのテストで、どのような環境を利用する予定なのかを予め定義しておきます。
移行計画
データ移行やインフラの移行が必要なプロジェクトの場合、移行作業全体の計画が必要になります。
移行の方針決定
移行の対象範囲を明確にし、一括移行か段階移行か、並行稼働が必要か、など、移行の方針を決定します。ビジネス的な制約、移行の規模やリスクを考慮して、最適な移行方針を策定します。
移行作業の定義
業務移行、アプリケーション移行、データ移行、インフラ移行など、移行作業の種類ごとにどのような移行作業が必要になるかを整理します。各移行作業の順序や依存関係も明確にします。
移行リハーサルや本移行、コンティンジェンシーの定義
リハーサルは何回行うのか、それぞれどのような目的で実施するのか、どのテスト工程に向けて行うのか、本移行は何回に分けるのか、問題発生時の切り戻し計画はどうするのかなど、移行全体のプロセスを計画します。
移行プロセスごとの体制とスケジュール
各移行プロセスの体制や発注側、ベンダー側の役割・責任範囲を定義します。また、各移行プロセスの準備はいつから行うのか、いつから実施するのか、などのスケジュール、テスト開始・終了条件を策定します。
移行環境の計画
テストの環境と同様に移行の環境の計画も必要になります。特にデータ移行では、移行データ量が多い場合、移行処理用の環境を別途立てる必要があったりします。また、並行稼働を行う場合は、旧システム環境の保全も必要になるため、新システム環境とどのようにデータの同期をとるのかなども予め整理しておく必要があります。
計画作成では、計画書から週次スケジュール、WBS（Work Breakdown Structure：作業分解構成図）へと構造的に整理することが重要です。計画を立てる際に「構造的な整理」を重視することで、メンバーが迷うことなく業務を遂行できるようになります。
管理・運営業務
計画が完成したら、次は管理業務と運営業務を通じて、計画通りにプロジェクトを進めます。
管理業務
計画ができた後は、プロジェクトが計画通りに進んでいるかどうかを常に監視し、問題が発生した場合は迅速に対応することが求められます。なお、各管理のプロセス・ルールは、工程ごとの計画内で策定されています。
進捗管理
作業が計画通りに進んでいるかを確認します。もし遅れている場合は、その原因を分析し、具体的な対策を講じます。単に遅れている事実を把握するだけでなく、なぜ遅れているのかを理解し、その真因を見つけ、解決策を見出すことが重要です。
課題・リスク管理
顕在化した課題を拾い上げるだけでなく、まだ表面化していない潜在的なリスクも検知し、見える化します。対応すべき課題やリスクの優先度や期日を決め、その検討状況・経緯を追跡します。
品質管理
要件定義からテストに至るまで、品質を維持するためのレビュー体制や不具合対応プロセスを着実に進行させます。例えば、ドキュメント成果物の指摘事項の管理、システム機能やインフラの不具合の発生状況の管理を行います。
変更管理
一度決まった要件や仕様について、どうしても変更が必要な場合、変更管理プロセスに基づいて対応を行います。変更を一覧化し、優先度を決め、対応是非を決め、変更の対応状況を管理します。
運営業務
プロジェクトチームがスムーズに活動できるように、様々なサポートを行う業務です。
会議運営
プロジェクトの体制に応じて、顧客とベンダー間の会議やチーム内の会議などを効果的に運営します。会議の開催調整、アジェンダの作成、資料の準備、会議のファシリテーション、議事録の作成などを行います。
ToDo/QA管理
会議で発生したタスク（ToDo）や質問事項（QA）を漏らさず管理します。これらを一覧化し、優先度を付けて対応することで、重要な作業が放置されることを防ぎます。
ドキュメント管理
プロジェクトで作成される各種資料を適切に管理します。各計画書、報告書、要件定義書、基本設計書、詳細設計書、テストケースなどの資料について、フォルダ構成や命名規則、最新版の管理ルールを定め、適切に配置します。これにより、プロジェクトメンバーが必要な時に最新の資料にアクセスできるようにしておきます。
コミュニケーション
プロジェクトチーム全体の円滑なコミュニケーションを確保します。会議に出席していないメンバーへの状況説明、ToDoや質問のリマインド、タスクに関する質問への回答、メンバーの相談対応など、様々な形でチームをサポートします。
要員管理
プロジェクトの要員に関わる事務を行います。プロジェクト参加時の各種手続き、立ち上がり支援、退任時の引継ぎ準備など、要員に関する業務を行います。
調達管理
プロジェクトに必要なリソースの調達手続きを管理します。インフラや備品などの調達については、発注から納品までのプロセスを適切に管理します。ベンダー調達については、開発プロセスの一環として要件定義前に完了しているため、プロジェクト進行中に追加で必要なリソースの調達・契約手続きを主に扱います。
コスト管理
EVM（Earned Value Management：出来高管理）などを用いて、要員コストを管理し、また、インフラコストなどのコスト管理を行います。変更対応の是非判断においても、残工数や予算との関係を確認しながら決定します。
これらの管理業務と運営業務を通じて、プロマネはチームが最大限のパフォーマンスを発揮できる環境を整えます。
推進業務
最後に、推進業務としてプロジェクトのQCDに影響を与える課題やリスクに積極的に取り組みます。
課題解決
ベンダー間やシステム間でのスコープの不明確さ、全体のマイルストーンが変わるなどの大幅な変更による影響分析など、個別のチームでは解決が難しい課題については、プロマネが中心となって解決に取り組みます。
課題解決のアプローチ
具体的には、議論のたたきを作成し、顧客やベンダー間の意見を調整しながら結論を導き出します。また、進捗遅延や品質悪化などのプロジェクト全体に影響する問題についても、根本原因を特定して解決策を講じます。
リスク対策
プロジェクト開始時、工程進行中、工程終了時に、検出されたリスクに対して対策を講じます。
プロジェクト開始時のリスク
例えば、対向システム側の体制が弱いことによる進捗・品質リスクなど、プロジェクト立ち上がり時に潜むリスクを特定し、対策を講じます。例えば、定期的な状況共有の会議を設定し、進捗や品質のリスク顕在化の予兆を早めにキャッチするなどの対策が考えられます。
進行中のリスク
例えば、業務側のスキル不足や作業時間の制約による進捗・品質リスクなど、プロジェクト進行中に見えてきたリスクに先手を特定し、対策を講じます。例えば、ベンダー側の業務有識者をサポートとしてつけるなどの対策が考えられます。
工程終了時のリスク
設計書の指摘内容やテストの不具合の傾向から推測される品質リスクを分析し、対策を講じます。例えば、再度、設計書類のウォークスルーを実施する、品質強化テストを企画するなどの対策が考えられます。
これらのリスクを根拠を持って特定し、具体的で実行可能な対策を講じることで、プロジェクトの安定した進行を確保します。
推進業務を通じて、プロマネは単なる管理者の役割を超えて、プロジェクトの成功を積極的に推進するリーダーとしての役割を果たします。
まとめ
プロジェクトマネジメント業務は、計画実務、管理・運営業務、推進業務の3つの柱によって構成されています。
プロマネは、これらの業務について、自身も含めて、誰が責任を持つのかを明らかにすること（体制・役割定義）、該当する要員が、業務を遂行する上で適正なスキルを持っているかどうかを判断することにも責任を持ちます。必要に応じて、体制強化・役割の変更などを行います。
プロマネの本領は、単なる管理ではなく、プロジェクト全体を成功に導くために、このように積極的なリーダーシップを発揮することにあるのです。
