ミニマム・プロジェクトマネジメント

日本のIT業界では、プロジェクト管理はPMBOKがデファクトスタンダードとなっており、その知見を適用していないプロジェクトは無いと言って間違いありません。

一方でPMBOKの知見は幅広く複雑です。全てを正しく適用しているプロジェクトは無いと言っても過言ではないでしょう。

プロジェクトの規模、プロダクトの複雑性、使う技術の新規性によらず、全てのプロジェクトでやらなければならない事があります。

ここでは、全てのプロジェクト管理で行うべき事柄と、その注意点を説明していきます。

1． PMBOKが定義するプロジェクト管理の知識体系

PMBOK（第6版）では、プロジェクトマネージャ（以下、PM）が理解すべき知識体系を5個のプロセス群と10個の知識エリアのマトリクスで定義しています。

プロジェクトマネジメントのプロセス群

  • ・ 立ち上げプロセス群
  • ・ 計画プロセス群
  • ・ 実行プロセス群
  • ・ 監視・コントロール・プロセス群
  • ・ 終結プロセス群

プロジェクトマネジメントの知識エリア（語頭の「プロジェクト」は全て割愛）

  • ・ 統合マネジメント
  • ・ スコープ・マネジメント
  • ・ スケジュール・マネジメント
  • ・ コスト・マネジメント
  • ・ 品質マネジメント
  • ・ 資源マネジメント
  • ・ コミュニケーション・マネジメント
  • ・ リスク・マネジメント
  • ・ 調達マネジメント
  • ・ ステークホルダー・マネジメント

2． 最低限行うべき管理行為は何か

さてPMBOKはあくまでも知識体系であり、実運用にそのまま適用することが難しいため、ここでは一旦PMBOKの知識エリアから離れましょう。

ここでは、日本のIT業界で一般的に使われる用語で説明します。

最低限行うべきプロジェクト管理行為は

  • ・ プロジェクトの計画とその進捗の管理
  • ・ 発生した課題とその対応状況の管理

の2点です。

一見当たり前に思われる事項ですが、適切に運用することは管理者のみならずプロジェクト参画者全員が、その必要性や目的、役割を理解した上で運用する必要があります。

3． プロジェクトの計画とその進捗の管理

  • ・ プロジェクトの計画

PMが計画粒度を定めた上でプロジェクト内の各チームリーダーに作業計画の作成を依頼しましょう。

計画の様式は様々ですが、ここでは様式に依らないポイントを説明します。

  • ・ 作業計画のポイント
  • ・ 計画は完全ではなく、誤りが必ず含まれるということを参画者全員で認識し、許容する
  • ・ PMは計画を俯瞰的に確認する必要があるため、プロジェクト内全てのチームに同じ書式、項目の粒度で記述を依頼するために予めルールを定める
  • ・ 「担当者」「開始予定日」「完了予定日」「開始実績日」「完了実績日」を最低限の管理項目とし、余分な情報を入力しない
  • ・ 長期の計画は最初から詳細化することが極めて困難なため、数か月先の計画は、一旦粗い粒度（数週間～程度）で記述しておく
  • ・ 荒い粒度の時点では、担当者はチーム単位で良い
  • ・ 計画を詳細化するルールを定めて運用する
  • 例）開始1か月前に迫った項目は、～1週間までのサイズに詳細化する
  • ・ 計画を詳細化した際は、担当者を必ず1名に設定する

計画精度を可能な限り向上させるために綿密な計画を立てることは望ましいですが、ソフトウェア開発において確実に正しいといえる計画を行うことは非常に困難です。

そのため、プロジェクトの進行に沿って計画を修正したり、詳細化したりを繰り返して、徐々にプロジェクト全体で精度を向上する必要があります。

最初から十分な精度を狙った複雑な計画を立てようとすることは、その難しさもさることながら、管理工数の増大にも繋がります。よほど熟練したPMや経験豊富な技術リーダーが多数参画している場合を除き、変更・変化を許容した計画を立てることを推奨します。

  • 進捗の管理

    進捗の管理は、最低限「誰が担当する」「その仕事を開始した日」「その仕事を完了した日」だけを記録します。

    PMは開始が遅延している項目、完了が遅延している項目を日々追うことになります。

    これにより大まかに「システムのどの機能の塊が遅れがちであるか」「誰が担当している箇所が遅れがちであるか」といったプロジェクトの概況を掴み、対応に移ることが可能になります。

よく見る運用方法で、○○したら20%、△△したら50%、□□したら70%などステータス管理する場合もありますが、ステータスが手戻る可能性が高くあまり有用とは言えません。（指標として管理することに意義はありますが、有用な効果を生むためにはプロジェクト参画者の習熟と統制が必須です）

また更に高度なプロジェクト管理として、EVM（Earned Value Management）を行うために、項目の担当時間を計画・記録する場合もあります。

前述の通り計画は完全ではありません。所要時間を計画し、実績時間を管理することで実コストを算出することは望ましいですが、実績の虚偽が容易で計画に合わせた記録を付けることが防げないため、ここでは取り上げないこととします。

4． 発生した課題とその対応状況の管理

進捗の管理と合わせて、必ずプロジェクト内の課題を管理しましょう。

進捗の遅延はここで管理する課題が原因となることが殆どであるため、進捗管理と合わせて運用することで、より効果が発揮されます。

  • 課題管理のポイント
  • ・ 「課題内容」「解決の担当者」「解決期限」「対応状況」を最低限の管理項目とし、余分な情報を入力しない
  • ・ 課題の内容は、課題管理を行うツール内の記述を読むだけで一意に読み解けるよう、“文章”で正しく記述させる
  • ・ “いつ“、“誰が“、“なぜ“、“何に困っているか“を可能な限り課題内容に記述させる
  • ・ 「～について」といった一文の課題内容は認識の相違を生むため排除する
  • ・ 課題の対応状況には、課題内容と同じく、“いつ“、“誰が“、“何をしたか“を可能な限り正しい“文章“で記述させる
  • ・ 課題起票の意識を高くもつために“起票者”を安易に”解決の担当者”としない。PMやチームリーダーが責任をもって適切な担当者に振り分ける

課題管理では、日本語が適切に記述されないことで、課題の認識がプロジェクト内で一致しないまま対応が進められるケースがあります。1つの認識の差異が数週間の遅延を生む要因になるケースを、これまで多数見てきました。

PMは管理項目をシンプルに、管理内容は丁寧に行うことが、トラブルを未然に防いで健全にプロジェクトを運営する手段の一つであると心掛けて下さい。

5． まとめ

プロジェクト管理では、最低限「プロジェクトの計画とその進捗の管理」「発生した課題とその対応状況の管理」を行いましょう。