新製品開発や職場改善などのプロジェクトベースの仕事に携わる中で、発足時に立てた計画通りにことが進まない、または、期待していた通りの成果を上げることができなかった、という苦い経験を持つ人は少なくないでしょう。中には予算などのリソースの都合から、プロジェクトを途中であきらめざるを得なかったという方もいらっしゃるかも知れません。

プロジェクトを成功に導くためには、内容に応じて適切に「プロジェクトマネジメント」を行うことが重要です。幸いにも効率的なプロジェクトマネジメントの手法についてはさまざまな研究がなされており、いくつか手法も確立されています。また、プロジェクトマネジメントに役立つツールも、有償・無償含めて多くの種類が世の中に出回っています。これらを活用することで、プロジェクトの成功確率を各段に上げることができるでしょう。

では、プロジェクトマネジメントのための手法、並びにツールとは、いったいどのようなものなのでしょうか。

1.プロジェクト・プロジェクトマネジメントの定義

そもそも、プロジェクトやプロジェクトマネジメントとは何を指す言葉なのでしょうか。これらの言葉の定義はさまざまですが、ここでは最も普及していると思われる、プロジェクトマネジメントの標準策定などを行う非営利組織「プロジェクトマネジメント協会(PMI=Project Management Institute)」による定義を見ていきましょう。

PMIによると、まずプロジェクトとは、「独自の成果物を作り出す有期限の活動」であると定義されています。例えば継続的に行っている営業活動や、経費精算等の日常的に行っている業務などは、期限がありませんのでプロジェクトとは言えません。もし「来年5月までに営業チームで新規顧客を20社開拓する」といった活動や、「年末までに経費精算を自動化するシステムを導入する」といった活動が始まった場合、初めてプロジェクトと呼ぶことができます。そしてこれら多様なプロジェクトにおいて、期限内に想定通りの成果物を作り出すための活動のことを、プロジェクトマネジメントと呼びます。

2.プロジェクトマネジメントにおいて実施するプロセス群と知識エリア

では具体的に、プロジェクトマネジメントにおいては、どのようなプロセスがあるのでしょうか。プロジェクトマネジメント協会が、プロジェクトマネジメントに関するノウハウや手法をまとめている「PMBOK=Project Management Body of Knowledge」の第5版では、プロジェクトの発足から成果物を刈り取る所までを、5つのプロセス群に分割しています。またこれらのプロセス群の中に、プロジェクトをマネジメントしていくうえで必要なプロセスが定義されています。このプロセスは、マネジメントの対象により10のプロジェクトマネジメント知識エリアとして分類されています。

5つのプロセス群と10個の知識エリアは、しばしば下図のようにマトリクスで表記され、プロジェクトマネジメント上の実際のプロセスを示すことができます。プロジェクトマネジメントのプロセスの全体像を俯瞰できるため、進捗を確認する際にはこの表に立ち戻ると良いでしょう。

2-1.プロセス群

1. 立ち上げプロセス群
   プロジェクトがどのようなものになるか定義し、各種ステークホルダー（プロジェクトをとりまく関係者）から認可を得る
2. 計画プロセス群
   プロジェクトのゴールを達成するための計画を作成する
3. 実行プロセス群
   計画に基づき、定められた期限までに作業を完了する
4. 監視・コントロール・プロセス群
   もともとの計画と実際の状況との間で、かい離が生じていないかどうか、生じた場合にどのように解消するかマネジメントする
5. 終結プロセス群
   プロジェクト内で作成された成果物を納入し、プロジェクトを完了させる

2-2.知識エリア

1. プロジェクト統合マネジメント
   それぞれのプロセスを統合するために必要なプロセスを定義
2. プロジェクト・スコープ・マネジメント
   プロジェクトを成功させるために欠かせない作業を洗い出すプロセスを定義
3. プロジェクト・タイム・マネジメント
   プロジェクトを期限内に完了させるためのプロセスを定義
4. プロジェクト・コスト・マネジメント
   プロジェクトを予算内に完了させるためのプロセスを定義
5. プロジェクト品質マネジメント
   達成すべき品質を担保するためのプロセスを定義
6. プロジェクト人的資源マネジメント
   プロジェクトチームを組織し、効率的に運営していくプロセスを定義
7. プロジェクト・コミュニケーション・マネジメント
   プロジェクトのステークホルダーとのコミュニケーションを円滑に進めるためのプロセスを定義
8. プロジェクト・リスク・マネジメント
   プロジェクトに関するリスクを洗い出し、対策を練るためのプロセスを定義
9. プロジェクト調達マネジメント
   プロジェクトを進めるにあたり必要なプロダクトやサービスを調達するためのプロセスを定義
10. プロジェクト・ステークホルダー・マネジメント
    プロジェクトに関わるステークホルダーを適切に管理するためのプロセスを定義

3.プロジェクトを進めるうえで必要なプロセス

PMBOKは基本的に、どのような業種のどのようなプロジェクトでも活用できるように作られていますが、これらプロセスのすべてを実施する必要はありません。プロジェクトの内容や規模によっては、それぞれのプロセスを厳密に実施する必要がない場合もありますし、逆にプロセスを追加しなければならない場合もあります。

例えば、プロジェクトメンバーが100人を超えるような大規模プロジェクトなら、それぞれのプロセス群の中で定められているプロセスひとつひとつについて、時間をかけて議論しなければなりません。そのうえで文書に残し、大人数が集まるミーティングで各ステークホルダーに周知することが求められます。逆に、プロジェクトメンバーが10名程度、期間も3カ月～半年で済むような小規模なプロジェクトの場合、各プロセスの中には、合意事項をメモ書きした上でメール周知する、といった簡素な形で済む場合もあるでしょう。PMBOKに定められた標準的なプロセスをもとに、それぞれのプロジェクトに合った進め方を編み出すことが重要です。

ここでは、それぞれのプロセス群の中で、主要なプロセスについてまとめました。具体的にどのようなプロセスを実施するのか見ていきましょう。

1. 立ち上げプロセス群
• プロジェクト憲章作成
  プロジェクト憲章とは、企業内でそのプロジェクトを公式に認可するための文書です。プロジェクトの基礎として、背景や概要、目的などを明示します。具体的には、下記のような内容を含みます。
  • プロジェクトの概要、目的、目標
  • 顧客、ステークホルダーの大まかな要求事項
  • 制約条件、前提条件、リスク
  • プロジェクトマネージャーと、その権限
  • 主要なステークホルダーの情報
  • スケジュールの要約並びに概算の予算
• ステークホルダー特定
  プロジェクトにどのようなステークホルダーが関わるのか、その影響力などを特定・分析します。ステークホルダーは、必ずしもプロジェクトに協力的な人ばかりではありません。プロジェクトに対して好意的・否定的なステークホルダーは誰なのか、なぜそのような態度を取っているのかも含めて分析する必要があります。
2. 計画プロセス群
• プロジェクトマネジメント計画書
  プロジェクトの実行や監視コントロール、終結プロセスについてまとめたものがプロジェクトマネジメント計画書です。プロジェクト憲章をもとに、プロジェクトマネジメントの作業、手順、手段をまとめて記載します。
• 要求事項収集
  顧客やステークホルダーが何を求めているのか、その要求事項を明確にするための作業です。顧客へのヒアリングやステークホルダーへのインタビューなどを通じて、要求事項をまとめます。
• スコープ定義
  このプロセスでは、前述の要求事項収集プロセスで明確にした要求事項などをもとに、プロジェクトで作成すべき成果物やその受け入れ基準を定義します。言い換えると、何ができればプロジェクトが成功したと言えるのかを決める作業です。
  プロジェクトを取り巻く前提条件や制約条件によっては、収集された要求事項のすべてを満たすことができないこともあります。そのため、プロジェクトとして必ず満たすべき要求事項と、そうでない事項を明確にするためにも、この作業は非常に重要です。
• WBS作成
  プロジェクトで作成すべき成果物を細かく分類し、構造化したものです。作り方の詳細は後述します。
• スケジュール・マネジメント作成
  このプロセスでは、プロジェクトのスケジュールを計画・作成・実行・管理します。単にスケジュールを作成するだけでなく、どの段階まで終わったらどの報告書を使って報告するといった決まりごともここで定義します。
• アクティビティ定義・資源見積もり・所要時間見積もり
  プロジェクトの成果物を作成するために必要な作業を、「アクティビティ」として定義します。定義されたアクティビティを行うために必要な人員、機器、資材などを見積もるのが「資源見積もり」、それぞれに必要な作業時間を見積もるのが「所要時間見積もり」です。所要時間を見積もる際には、スケジュール遅延などのリスクも踏まえ、バッファ時間を盛り込むことが重要です。
• コスト見積もり・予算設定
  プロジェクト計画書やWBSをもとに、各アクティビティにかかるコストを見積もります。そのうえで、プロジェクトにどれほど予算が必要なのかを設定します。
• 品質マネジメント計画
  このプロセスでは、プロジェクトおよび成果物の品質要求事項や基準、品質を満たす作業手順、品質尺度などをまとめます。また、品質担保のために、一連の作業が行われたことを確認するチェックリストを作ることもあります。
• 人的資源マネジメント計画
  プロジェクトの遂行に必要な、プロジェクトメンバーの調達方法、それぞれの役割と責任などを決め、文書化することが目的です。会社外部から人材を調達する場合には、プロジェクトメンバーは物理的に同じ空間で働くことが求められるのか、それともリモート対応が可能なのかといった点も調整されます。
• コミュニケーション・マネジメント計画
  ステークホルダーが必要とする情報を定義し、どのような形で伝達するかを計画します。プロジェクトメンバーが少なく、同じオフィスで働いている場合は大掛かりな計画書は必要ありません。しかし、プロジェクトが大規模な場合や、物理的に離れた場所にメンバーがいる場合は、進捗共有ミーティングや品質レビューミーティングなどの実施頻度、書類や成果物の保存場所などを定めておかないと、必要な情報が行きわたらなくなってしまいます。
• リスク・マネジメント計画、リスク対応計画
  プロジェクトには、さまざまなリスクが潜んでおり、そのリスクをどのように対処するか決めるのがリスク・マネジメント計画やリスク対応計画です。例えば新製品開発プロジェクトなら、新たな規制の発表や突発的な需要の変化といった外部要因によるリスクもあれば、主要なプロジェクトメンバーの体調不良などの内部の要因によって顕在化するリスクもあります。プロジェクト進行中にも継続的にリスクの評価を行い、あらかじめ対応策を練っておかなければなりません。
• 調達マネジメント計画
  プロジェクト推進のために外部からプロダクトやサービスを購入する必要があるかを検討し、選定基準などを決めるためのプロセスです。購入から納品までに時間がかかる場合、プロジェクトのスケジュールにも大きく影響するため、注意が必要です。
3. 実行プロセス群
• プロジェクト作業の指揮・マネジメント
  このプロセスでは、プロジェクトマネージャーがプロジェクトマネジメント計画書に記述された作業について、指揮・マネジメントします。プロジェクトメンバーの配置やトレーニング、資源の調達といった作業も行われます。
• 品質保証
  品質マネジメント計画通りに手順が実行されているかを監査するプロセスです。特にさまざま作業を大人数が分担する大規模プロジェクトにおいては、人によって品質に対する考え方が違うことがあり、大きな問題につながることがあります。それを防ぐために、品質マネジメント計画と、品質保証の両輪が重要となります。
• プロジェクトチーム編成、育成、マネジメント
  このプロセスでは、プロジェクトチームを構成するために必要な人材を選出、任命し、必要に応じてトレーニングなどの育成を行います。また、プロジェクトマネージャーはプロジェクトチームが最大限の力を発揮できるよう、チームメンバーをマネジメントすることが求められます。
• ステークホルダー・エンゲージメント・マネジメント
  エンゲージメントは婚約という意味で使われることがありますが、組織やプロジェクトの文脈では「プロジェクトへのコミットメント度合い」といった意味で使われます。ステークホルダーの期待に応えるよう適切なコミュニケーションをとり、プロジェクトへのステークホルダーの関わり方をより良い形に変えていくプロセスのことを、「ステークホルダー・エンゲージメント・マネジメント」と呼びます。
4. 監視・コントロール・プロセス群
• プロジェクト作業の監視・コントロール、統合変更管理
  プロジェクト内で必要な作業や作成すべき成果物が、スケジュール通りに実施されているか監視します。プロジェクトが大幅に遅れた場合に、どのような対策を立てるべきかといったことも含まれています。プロジェクトの計画を変更する必要が出た場合は、「統合変更管理プロセス」で計画の変更をレビュー、分析し、最終的に意思決定します。
• スケジュール・コントロール、コスト・コントロール、品質コントロール
  プロジェクトマネジメントを行うプロジェクトマネージャーは、プロジェクトのスケジュールやコスト、品質が、計画・基準通りに実行されているかどうかをコントロールしなければなりません。これらのプロセスでは、成果物の作成状況、遅延率などの情報をもとに、問題に対して適切な行動を取ります。
5. 終結プロセス群
• すべてのプロセス群で所定のプロセスがすべて完了しているか確認し、プロジェクトやフェーズを正式に完了させるプロセスです。ステークホルダーが複数社集まるようなプロジェクトであれば、後日揉めることのないよう契約関係をしっかりまとめておく必要もあります。

いかがでしょうか。プロジェクトマネジメントにおいて実施すべきプロセスの多さに、圧倒されてしまう方もいらっしゃるかも知れません。繰り返しになりますが、これらのプロセスはプロジェクトを実施するために必要な汎用的なプロセスをすべて洗い出したものであり、すべてのプロセスを忠実に実行する必要はありません。プロジェクトの規模や種類に応じて、必要なプロセスのみに注力し、重要度の低いプロセスは簡単に済ませてしまって問題ありません。これらのプロセスをそのままプロジェクト標準にするのではなく、チェックリスト的に自社のプロジェクトに必要なプロセスを洗い出すために使うのが良いでしょう。

4.プロジェクトマネジメントに役立つ手法やツール

プロジェクトマネジメントを効率的に行うためには、適切な手法やツールの使用が欠かせません。以下で代表的な手法やツールについて解説していきます。

• WBS(=Work Breakdown Structure)
  計画プロセス群の中でも紹介されたWBSとは、プロジェクトを実行するために必要なタスクを洗い出し、それを階層構造にして管理する手法のことを指します。プロジェクトマネジメントにおいてはもちろんのこと、普段の仕事の中でも必要なタスクを洗い出すときなど、あらゆる場面で活用することができます。
  
  
  
  WBSの作成は、基本的にはタスクをすべて洗い出して、いくつかのカテゴリにまとめたのちに階層構造として記載するだけですが、タスクの洗い出しは思いのほか大変なもの。タスクの漏れが発生しないよう、下記のポイントに注意して作成すると良いでしょう。
  • 最初に成果物を分割して考える
    タスクという抽象的なものよりも、目に見える成果物から考えた方が抜け漏れはなくなりやすいです。例えばカツ丼を作るためには、まずカツとご飯が必要、といった具合に考えると良いでしょう。
  • 作業の順番を考える
    時間軸に沿って考えると、より具体的な場面を想定しやすくなり、タスクが浮かぶことがあります。例えば、カツ丼を食べるというプロジェクトを考える場合、カツ丼の完成だけで満足するのではなく、作ったカツ丼を食べるためには配膳まで必要、と考えなければなりません。
  • 一度作成した後に、メンバーとミーティングする
    ひとりでWBSを作っていると、どうしても抜け漏れに気づきにくいもの。そんなときこそ「三人寄れば文殊の知恵」。チームメンバーの知恵も借りながら作成しましょう。
• ガントチャート
  ガントチャートとは、WBSで作成したそれぞれのタスクにかかる工数を、一目で把握するためのものです。WBSでのタスク洗い出しを行ったら、タスクごとにどれくらいの時間がかかるかを見積もり、グラフに表していきます。タスクがそれほど多くない、比較的小さめのWBSであればExcelで十分な場合もありますが、タスクが多くなればなるほど管理が大変。専用のツールを使用することをおすすめします。
  
  

• PDM(Precedence Diagramming Method)
  PDMは、作業の開始から終了までの間で、それぞれの作業の順序や関係を表すことができます。これを明確にすることで、スケジュールを立てる際にどの作業を優先して実施しなければならないか、どの作業が遅延するとどの作業に影響するかが分かります。
  
  
  
  
• コスト見積もり手法
  スケジュールの見積もりと同じくらい重要なのが、コストの見積もりです。プロジェクトによって素晴らしい成果物ができあがったとしても、当初想定していたコストを大きく上れば、プロジェクトが成功したとは言いづらいでしょう。このような事態を避けるためにも、コストの見積もりには細心の注意を払う必要があります。代表的なコストの見積もり手法を3つご紹介します。
  • 類推見積もり
    類似している過去のプロジェクトを参考に、コストを見積もる手法です。過去に類似しているプロジェクトを実施した場合には、かなり精度の高い見積もりを作ることができます。またプロジェクトが初期段階にあるなど、不確実性の高い状況で利用されることもあります。
  • ボトムアップ見積もり
    WBSよりも作業をさらに詳細に定義したアクティビティのコストを見積もり、それらを足し合わせることによって全体のコストを計算する手法です。アクティビティの見積もり精度が高くなればなるほど、全体の精度も高まります。
  • パラメトリック見積もり
    コストに関する過去の統計データや経験と、プロジェクトに関わる変数を使ってコストを見積もる手法です。統計データや類似プロジェクトの経験が多くある場合には、見積もり精度が高くなります。
• 共有サーバー
  プロジェクト実施時には、数多くのファイルが作られます。プロジェクトメンバーが2～3人程度であればいざ知らず、10人以上のメンバーで成果物であるファイルをメールでやり取りしていると、あっという間にメールがさばけなくなるでしょう。どれが最新のファイルなのか分からなくなったり、メールを見落としたりしてしまうかもしれません。そのため、少人数のプロジェクトにおいても必ず共有サーバー上にプロジェクト専用のフォルダを作りましょう。また、プロジェクトメンバーが社内のメンバーのみであれば社内の共有サーバーを活用すれば済みますが、社外のステークホルダーやプロジェクトメンバーがいる場合には、クラウドストレージなどを検討する必要もあるでしょう。
• ポータルサイト
  プロジェクトに関わる人数が増えれば増えるほど、そして社外や国外などメンバーが多様になればなるほど、情報伝達が難しくなっていきます。プロジェクトマネージャーが必死に情報共有しているつもりでも、実は多くのメンバーがプロジェクトの状況が理解できないまま進行している、といった事態も起こり得ます。そのため、情報共有のプラットフォームは積極的に活用した方がよいでしょう。例えば、プロジェクト専用のポータルサイトを立ち上げ、誰でもプロジェクトに関する最新情報が得られるようにすると、情報の伝達がスムーズに行えるようになります。新たなプロジェクトメンバーが参加した場合にも、簡単にオリエンテーションを行うことができるでしょう。

5.プロジェクトマネジメントソフトウェア導入の重要性

プロジェクトマネジメントには、タスク管理からスケジュール管理まで、マネジメントにかかる工数が非常に大きくなってしまいます。それらの作業を軽減するために、最も手軽に使われるのがExcelでしょう。しかし、メンバーが5～6人程度の小規模なプロジェクトであれば、Excel上でのタスク管理やスケジュール管理でも問題なく業務が回りますが、人数が多くなればなるほどExcelファイルの共有が難しくなっていきます。また、多数のメンバーが編集するようになると、どれが最新のバージョンなのかが分からなくなってきて、結局プロジェクトマネージャーがイチからすべてチェックし直す、といったことも起こりかねません。そのため、ある程度プロジェクトメンバーが増えてきたときには、別のツールを導入することを検討しましょう。下記に代表的なツールを示します。

• Googleスプレッドシート
  Googleスプレッドシートの機能は基本的にExcelと大きく変わりませんが、シートの共有や複数ユーザーによる同時編集が簡単に行える点に強みがあります(ExcelもOffice 365の契約をしているか、または社内共有サーバー上であれば同時編集を実現できます)。とりあえずタスクの共有を手軽に行いたい場合は、有効な手段となるでしょう。
• Redmine
  Redmineは、オンライン上でタスク管理と進捗管理を行うためのツールです。ExcelやGoogleスプレッドシートとは異なり、進捗管理を行うための専用の機能が盛り込まれています。例えば、Redmine上でタスクを作成し、開始日と終了日を入力するだけで、ガントチャートが自動的に表示されます。また、それぞれのタスクに担当者を割り振ると、その担当者に自動的にメール通知がされるという機能もあります。無料で試用することもできますので、まずは試しに導入といったことも行えます。
• Microsoft Project
  大規模なプロジェクトを何本も抱えるような組織では、Microsoft Projectのような専用パッケージ製品の導入を検討することをおすすめします。ガントチャート作成機能はもちろんのこと、リソースの管理、複数案件の進捗管理、シミュレーション機能によるプロジェクト遅延の調整など、プロジェクトマネージャーを支援するさまざまな機能が搭載されています。

プロジェクトの規模や内容によって適切な手法やツールを使用し、プロジェクトをスムーズに進めていきましょう。