プロジェクト管理の全体解説 – 立上げ／計画／実行／コントロール／終結

プロジェクトの実行

作成した計画に則り、プロジェクト作業を進めます。
ここではプロジェクト推進の管理やチーム育成、審査や監査など多様の作業があります。

プロジェクトの管理業務

進捗管理

プロジェクトの作業計画と実績値を比較することで進み具合を把握します。
マスタスケジュールが遅延しないように日々の作業状況を適切に把握し、問題発生したら対処していきます。
ここでポイントとなるのが、管理対象の規模でチェックする観点が異なります。

現場の作業メンバを直接管理する場合、メンバごとにWBSが予定通り進んでいるか確認することができます。
これは小規模プロジェクトであったり、プロジェクト内のチームを管理する場合が該当します。
この規模であれば、メンバから直接状況をヒアリングすることができます。

複数チームを取りまとめる立場の場合、進捗確認はチームリーダからの進捗報告を受けて把握します。
こちらはメンバから直接状況をヒアリングするのは困難であるため、報告書にある定量、定性の情報をもとに判断します。
報告内容にある進捗状況を見るだけではなく、報告しているチームリーダが状況を正しく理解しているか、間違っていないかといった観点でチェックします。
無邪気に報告内容を信じて問題が発生したとき、責任を取るのは報告を受けた側であると心得ましょう。

課題管理

プロジェクトで発生した問題やTODOなどの作業を管理します。
WBSに記載されていないタスクを管理すると考えるとイメージしやすいです。
一般的には課題を一覧で管理し、課題ごとの期限や対応状況を記載して管理します。

課題一覧の記載内容についてはExcelのサンプルフォーマットを無料公開しています。
参考にしてください。

また課題管理の運用については、別記事「課題管理」でも解説しています。

課題管理は意識して運用しないと形骸化するので、しっかり運用するために次のことを意識します。

• 課題一覧に書くか迷ったら「書く」ルールにする
• 期限、担当者は必須入力
• 複数人で対応する課題も担当者欄は１名だけ（責任者）
• 期限超過した課題がないか定期的に確認する
• 記入者≠担当者であり、適正な担当をアサインする
• 課題対応で時間を要するならWBSのスケジュールを調整する

先にも述べましたがWBSに記載されていないタスクであることを認識して担当をアサインすることが大切です。
それらを無視してメンバにタスク割り当てすると課題が報告されなくなり、問題やリスクが潜在し続けることになります。

課題管理における期限超過は、WBSでいうスケジュール遅延と同様です。
課題を担当者任せにするのではなく、対応が進んでいない課題についてはリーダが担当者に状況確認したり、対応の督促やアドバイスの提示をします。
もしリーダが他で手一杯というなら、課題対応の責任者を別に用意することもあります。
少なくとも、課題を担当者任せにするのは避けましょう。

別記事「進捗管理と進捗報告のポイント」を参照

不具合管理

設計書レビューの指摘事項や、テストで発生した不具合を管理します。
管理する目的は不具合を漏れなく対応することですが、その意外に修正方法を有識者が確認するためにも使用されます。

また、レビュー記録表や不具合管理表は品質を分析するための諸元データとしても利用します。
発生した不具合情報から傾向分析を行い、成果物の弱点を発見することで、対策や未発見の不具合を発見することができます。

不具合管理一覧の記載内容についてはExcelのサンプルフォーマットを無料公開しています。
参考にしてください。

別記事「品質を定量分析する方法」を参照

仕様変更管理

プロジェクトで発生した仕様変更に関連する要求事項や対応状況について管理します。
管理するのは仕様変更の対処が決定した要求事項だけでなく、調整前の要求事項や、既に取り下げられたものも全て管理します。
仕様変更はコストの変動だけでなく、利用者の満足度にもつながるため、厳密に経緯や結果を管理する必要があります。

間違っても現場の担当間のやり取りだけで仕様変更を取り込むのはNGです。
そのような事態が発生するのであれば、それはプロジェクト統制に問題があります。
仕様変更ルールについてはプロジェクト計画で定義したうえで、キックオフミーティングでプロジェクトメンバやクライアントと合意を取ることが重要です。

リスク対策

「プロジェクトの監視・コントロール」で行うリスクの予兆を監視した結果、リスクが顕在化したらリスク管理で取り決めていたアクションプランを実行します。

リスクが顕在化して問題に変わったら、その後は課題管理に移管して対応します。

育成

プロジェクトチームや、チームに参画しているメンバを育成することは、プロジェクト成功や組織力向上のために大切です。

主にあげられる育成ポイントは次のとおり。

• プロジェクトで使用するスキル習得
• キャリアアップするための経験値
• メンバの技術や能力向上
• 有識者の保有する知識の継承
• チーム運営のプロセス改善

上記のうち、「有識者の保有する知識の継承」というのは、有識者の頭の中にある知識や作業手順を、ドキュメント化して他メンバに展開することを言います。
この作業は有識者にとって手間でしかないため、協力をえるためにも正式なタスクにして計画立てて進めないと成功しません。

次工程準備

次工程が始まる前に事前準備をすることは、プロジェクトをスムーズに遂行するために必要不可欠です。
工程が変わると作業内容も変わるため、準備不足だと進め方がわからず作業が止まることもあります。

例えば基本設計から詳細設計に移るとき、設計書フォーマットや規約などのルールが異なります。
これらの準備は現工程が完了するまでに完了している必要があります。
何を作成し、どのようなルールを定義するのか事前準備を進めます。

プロジェクト状況や社内ルールにもよるでしょうが、可能であれば一部作業を先行して着手するのをオススメします。
実際に作業をしてみると準備不足に気づくことがあるので、本対応が始まる前に準備を整えることができます。

工程審査

プロジェクトがウォーターフォール型の場合、工程完了したら前工程に戻ることはないため、工程を進めてよいか審査します。
工程審査の判定基準は組織により定義されている場合が多いので、まずはそちらを確認しましょう。

よくチェックされる判定基準のポイントです。

• 　スケジュールと進捗状況が妥当か
• 　コストは予定通りか
• 　品質状況
• 　リスク予実と次工程の計画
• 　残課題の有無（あれば今後の見通し）

審査の結果によっては次工程に進められないこともあります。
状況によってはプロジェクト中止という事態もあります。
そのような事態にならないよう、プロジェクト責任者など上位層には定期的にプロジェクト状況を伝えると良いです。
報告する相手によっては説明だけでも重労働になる場合もありますが、だからこそ審査で一発勝負をするのは避けた方が無難です。

もしプロジェクトが審査を通せない状態であるなら無理に工程を進めず、リカバリプランを検討すべきです。

プロジェクト監査

プロジェクト監査とは、プロジェクトのプロセスに問題ないかチェックすることです。
PMOや品質保証部、社外組織といった第三者機関がプロジェクトの進め方をチェックします。
プロジェクトの進め方に問題がないか当事者では気づかない問題点を指摘されることもあるため、プロジェクト向上のためと考え、前向きに対応しましょう。

ここではプロジェクトのマネジメント資料や成果物を確認したりプロジェクトマネージャなどにインタビューすることで、現状に問題がないのかチェックします。
プロジェクトのプロセスに対する品質分析です。

全てのプロジェクトで行うわけではなく、プロジェクト規模が大きかったり、社内で注目されている場合に監査対象となることが多いです。
監査者によって判断基準が異なるため注意すべきということは言えませんが、プロジェクト計画を策定し、それに準拠して進めているのか問われます。

どうしても指摘事項は「あるべき論」になるため、実態と合わない内容もあるかもしれません。
現状とあるべき論のギャップがリスクや問題点になるため、そのギャップを埋めるための対策を監査側に伝えます。
十分な回答ができないのであれば、それは潜在しているリスクや問題であるため、プロジェクトを振り返り対策を検討します。

要員計画

プロジェクトは工程ごとに作業内容やボリュームが増減します。
そのため求められるスキルや人数が変わることがあるため、適切な人材配置を行うための計画を立てます。
月単位で必要な工数と要員を当てはめていき、不足している要員がいれば社内や社外から調達するための調整を行います。
ただし人を追加したり削減するのは大変なので、要員数が均等になるように作業スケジュールを調整することもあります。

もし要員を追加する場合は１～２か月前から調達先と調整する必要があります。
これは削減する場合も同様で、解放したメンバが次の仕事を調整する時間も必要です。
「来週から外れてください」は通用しないので注意しましょう。

次はプロジェクトの監視・コントロールについて解説します。