プロジェクトマネジメント 重点教科書

みなさんの会社で「新しい在庫管理システムを半年で作ってほしい」という話が持ち上がったとします。これは、毎日繰り返される経理処理や日々の受発注のような、決まったやり方を淡々と繰り返す仕事とは、性質がまったく違います。こうした「終わりの期限が決まっていて、世の中にまだない独自の成果物を作り出す、一度きりの活動」のことをプロジェクトと呼びます。「期限がある」ことと「独自の成果物を生み出す」ことの2点が、プロジェクトを見分けるキーワードです。

そしてこのプロジェクトを、決められた期限・予算・品質の範囲内で、狙った成果物まできちんとたどり着かせるための一連の考え方や進め方をまとめてプロジェクトマネジメントと呼びます。行き当たりばったりで作業を進めると、途中で「何を作るんだったか目的がぼやけてしまう」「気づいたら予算を使い切っていた」といった事態に陥りがちです。プロジェクトマネジメントは、そうした事態を防ぐための地図であり、羅針盤のような役割を果たします。

プロジェクトとは何か(定常業務との違い)

毎月の給与計算や、決まった手順で行う受発注処理のように、いつ始まっていつ終わるとも決まっていない繰り返しの業務を定常業務と呼びます。これに対してプロジェクトは、「今回だけ、この期限までに、これまでにない何かを作る」という点で明確に異なります。たとえば「毎月の売上を集計する」のは定常業務ですが、「その集計を自動化する新しいシステムを今年度中に導入する」のはプロジェクトです。この区別は、ITパスポートの試験でもプロジェクトの定義を問う形でよく出題されるため、「独自性」と「期限(一時性)」という2つのキーワードで判断できるようにしておきましょう。

プロジェクトマネジメントの基本的な流れ

プロジェクトは、思いつきでいきなり作業を始めるわけではありません。まず「このプロジェクトを正式に始めます」と組織として認めるところから始まり(立ち上げ)、次に「何を」「いつまでに」「いくらで」作るかを具体的に決めます(計画)。そのうえで、その計画に沿って実際に手を動かし、成果物を作り上げていきます(実行)。

ただし実行しっぱなしでは、途中で計画からズレていても気づくことができません。そこで、節目ごとに進み具合を確かめるレビューを挟みながら、作業がどれだけ進んでいるかを示す進捗、実際にかかっているお金であるコスト、成果物の出来栄えを示す品質、そして人や設備といった資源を絶えずチェックし、ズレがあれば軌道修正していきます。この「計画を立てて、実行して、確認して、直す」というサイクルを繰り返しながらゴールへ向かっていくところに、プロジェクトマネジメントの本質があります。

プロジェクトに関わる人たち

プロジェクトは1人で完結するものではなく、必ず複数の人が関わります。プロジェクト全体の責任者として、計画づくりから予算管理、メンバーへの指示、トラブル対応までを一手に担う人をプロジェクトマネージャと呼びます。船に例えるなら船長にあたる存在で、目的地である成果物まで、船であるプロジェクトを導く役割を持ちます。プロジェクトマネージャの指示のもとで、実際に設計や開発といった作業を担当する人たちはプロジェクトメンバーと呼ばれます。

さらに、プロジェクトに直接作業として関わっていなくても、その結果によって利害が生じる人たちがいます。発注元の経営者、実際にできあがったシステムを使う現場の従業員、システムの一部を作る協力会社など、プロジェクトの成否によって得をしたり損をしたりする関係者をまとめてステークホルダ(利害関係者)と呼びます。プロジェクトマネージャは、自分のチームの管理だけでなく、こうした社内外の多様なステークホルダとの調整も担う必要があります。

プロジェクトの立ち上げを支える文書「プロジェクト憲章」

プロジェクトを正式にスタートさせる際、口約束だけで始めてしまうと、後になって「そんな話は聞いていない」というトラブルが起きがちです。そこで、プロジェクトの目的、大まかな範囲、責任者であるプロジェクトマネージャが誰かといった基本事項を文書としてまとめ、組織として正式に承認するものをプロジェクト憲章と呼びます。プロジェクト憲章は、いわばプロジェクトの戸籍や設立趣意書のようなもので、この文書が発行されて初めて、プロジェクトマネージャは正式に予算や人を動かす権限を得ることができます。プロジェクトの途中で「そもそも何のためにこのプロジェクトをやっているのか」を思い出したくなったとき、立ち返る原点にもなる重要な文書です。

プロジェクトマネジメントの意義

なぜここまで手間をかけて計画やルールを整えるのでしょうか。それは、プロジェクトが「初めて挑む一度きりの活動」だからこそ、経験や勘だけに頼ると失敗しやすいためです。過去に何度も繰り返してきた定常業務であれば、担当者の経験則だけでも大きな失敗は起こりにくいものですが、プロジェクトは毎回条件が異なる一発勝負です。だからこそ、憲章で目的を明確にし、計画で道筋を描き、進捗・コスト・品質・資源を継続的に確認するという型を持っておくことで、経験の浅いメンバーが加わっても、組織として一定の水準でプロジェクトを完遂できるようになります。これが、プロジェクトマネジメントという考え方が広く使われている理由です。

プロジェクトを計画するとき、最初に決めなければならないのが「何を作るのか、そしてどこまでを作る範囲に含めるのか」です。この作業や成果物の範囲のことをスコープと呼び、スコープを明確に定義し、それが勝手に膨らんでしまわないように管理していく活動をプロジェクトスコープマネジメントと呼びます。

スコープを決める意味

たとえば「在庫管理システムを作る」というプロジェクトで、進めていくうちに「ついでに売上管理機能も」「ついでにスマホアプリも」と要望が増えていくと、当初の予算や期限では到底終わりません。このように、いったん決めたはずの範囲が、関係者の要望に押されて少しずつ膨らんでしまう現象は、プロジェクトが炎上する典型的な原因の一つです。プロジェクトスコープマネジメントは、こうした際限のない拡大を防ぎ、「今回のプロジェクトでやること・やらないこと」の線引きをはっきりさせ、その線引きを関係者全員で共有しておく役割を担います。

WBSで作業を分解する

スコープが決まったら、次はそれを実際の作業へと落とし込んでいきます。「システムを作る」という大きすぎる仕事は、そのままでは誰も手を付けられません。そこで、成果物や作業を「システム開発」から「設計」「画面設計」「データベース設計」というように、だんだん細かい単位に分解していく手法がWBS(Work Breakdown Structure)です。WBSによって作業が細かい単位に分けられると、「誰が」「何を」「いつまでに」やるのかを具体的に割り当てやすくなり、規模の見積もりの精度も上がりますし、大きな作業のまま扱っていたら見落としていたかもしれない作業の抜け漏れも防ぎやすくなります。木の幹から枝、さらに小枝へと分かれていくイメージを持つと理解しやすいでしょう。

ガントチャートでスケジュールを見える化する

WBSで洗い出した一つひとつの作業には、それぞれ「いつからいつまでかかるか」という期間があります。この作業ごとの期間を、横軸を時間、縦軸を作業項目にした横棒グラフで表したものがガントチャートです。「設計は4月1日から4月10日まで」「開発は4月8日から5月20日まで」というように、複数の作業がどの時期に並行して進むのかが一目で分かるため、プロジェクトのスケジュール管理において最もよく使われる図の一つです。会議で「今どの作業が遅れているか」を説明するときにも、ガントチャートがあれば視覚的にすぐ共有できるという利点があります。

アローダイアグラムとクリティカルパス

作業の中には、「設計が終わらないと開発に着手できない」というように、前の作業が終わってからでないと始められないものがあります。こうした作業同士のつながり(依存関係)を、矢印(アロー)を使って表現した図がアローダイアグラムです。それぞれの矢印には作業にかかる日数が書き込まれ、開始から終了までのすべての経路のうち、最も日数がかかる経路のことをクリティカルパスと呼びます。

たとえば、開始から終了までのルートがA→B→C(合計10日)とA→D→C(合計15日)の2通りあるとすると、より日数の長いA→D→Cの経路がクリティカルパスとなり、プロジェクト全体の所要日数は15日になります。クリティカルパス上にある作業が1日でも遅れると、プロジェクト全体の完了日もそのまま1日遅れてしまいます。逆に、クリティカルパス以外の経路上の作業には、多少遅れてもプロジェクト全体には影響しない余裕時間があります。試験でアローダイアグラムの問題が出たときは、まずすべての経路の所要日数を書き出し、そのうち最も長い経路を探す、という手順で解くのが基本です。

節目を意味するマイルストーン

ガントチャートやアローダイアグラムの中には、「基本設計完了」「結合テスト開始」といった、プロジェクトの重要な節目を示す点が書き込まれることがあります。これをマイルストーンと呼び、道路脇に立てられた一里塚(マイルストーン)が旅の進み具合を示すのと同じように、プロジェクトが計画通りに進んでいるかを判断する目印として使われます。日々の細かい作業の進み具合だけを見ていると全体像を見失いがちですが、マイルストーンを基準に進捗を確認することで、プロジェクト全体としての遅れに早く気づくことができます。

プロジェクトを進める際、スケジュールと並んで欠かせないのが、お金・出来栄え・人やモノという3つの管理です。この章では、進捗管理と密接に関わるこの3つの領域を見ていきます。

コストの管理

どんなに優れたシステムでも、想定していた予算を大幅に超えてしまっては、プロジェクトとして成功したとは言えません。プロジェクトに必要な費用をあらかじめ見積もり、実際の支出がその予算内に収まっているかを継続的に確認していく活動をコストの管理と呼びます。プロジェクトの初期段階では、過去の似たプロジェクトの実績などをもとにおおまかな金額を見積もり、計画が具体化するにつれて、人件費や機材費といった項目ごとに、より精度の高い見積もりへと更新していきます。進めていく中で「思ったより作業に時間がかかっている」状態が続くと、その分の人件費がかさんで予算を超過してしまうため、進捗の管理とコストの管理は切り離せない関係にあります。

品質の管理

期限内、予算内で完成しても、不具合だらけで使い物にならないシステムでは意味がありません。あらかじめ「これくらいの水準を満たす」という品質の基準を決め、実際にできあがった成果物がその基準を満たしているかを確認していく活動を品質の管理と呼びます。設計書の内容をみんなでチェックするレビューを行ったり、完成した機能に対して実際に操作してテストを実施したりすることは、いずれもこの品質管理の一環です。「早く終わらせたいから」といってテストを省略してしまうと、後になって重大な不具合が見つかり、かえって手戻りで多くの時間とコストを失う結果になりかねません。品質・コスト・スケジュールはお互いにトレードオフの関係にあることが多く、どれか一つだけを優先すると他の二つにしわ寄せがいく、という感覚を持っておくことが大切です。

資源の管理

プロジェクトを進めるには、人、パソコンやサーバといった機材、開発に使うツールなど、さまざまな資源が必要です。この資源を、どの作業にどれだけ割り当てるかを計画し、無駄なく活用できるように管理していく活動を資源の管理と呼びます。たとえば、設計が得意なメンバーには設計工程を、テストの経験が豊富なメンバーにはテスト工程を担当してもらうというように、業務における最適な人的資源の配置を行うことも、この資源管理の重要な活用例の一つです。特定のメンバーだけに作業が集中してしまうと、そのメンバーの遅れがプロジェクト全体の遅れに直結してしまうため、メンバーごとの作業量のバランスを見ながら割り当てを調整していくことが求められます。機材についても同様で、限られた台数の検証用サーバを複数の作業がとり合うような事態が起きないよう、あらかじめ使用スケジュールを調整しておくことが実務では重要になります。

コスト・品質・資源をあわせて考える

この3つの管理は、それぞれ単独で考えるのではなく、常にセットで捉える必要があります。たとえば、品質を高めるためにテストの工程を増やそうとすれば、その分だけ資源(人や時間)を追加投入する必要があり、結果としてコストも増えます。逆に、コストを抑えようと資源を減らせば、一人あたりの作業負担が増えて品質が下がったり、進捗が遅れたりするおそれがあります。「品質を上げたいなら、コストか資源のどちらかに影響が出る」という関係を意識しておくと、試験の状況設定問題でも、何と何がトレードオフの関係にあるのかを整理しやすくなります。

プロジェクトは、未来に向けて初めての取り組みを行う活動である以上、計画通りに進まない可能性を常にはらんでいます。この章では、そうした不確実性への備えと、関係者どうしの意思疎通を支える仕組みを見ていきます。

プロジェクトリスクマネジメントとリスクの対応策

「重要なメンバーが急に体調を崩して離脱してしまうかもしれない」「発注していた機材が納期通りに届かないかもしれない」というように、プロジェクトには、実際に起きるかどうか分からないものの、起きればスケジュールやコストに悪い影響を与えかねない出来事、つまりリスクが数多く存在します。こうしたリスクをあらかじめ洗い出し、影響の大きさや起こりやすさを踏まえて対応方針を決めていく活動をプロジェクトリスクマネジメントと呼びます。

リスクへの向き合い方は、大きく4つの対応策に整理されます。リスクの原因となる作業そのものを取りやめてしまう回避、対策を講じてリスクが起きる確率や起きたときの影響の大きさを小さくする軽減、特に対策をとらずそのまま受け入れる受容、そして保険をかけたり外部の会社に作業を委託したりすることでリスクの影響を他者に移す転嫁の4つです。

たとえば、特定の技術者しか扱えない特殊な機材を使う計画があり、その技術者が体調を崩すリスクが心配だとします。代わりに扱える人を事前に育てておくのは軽減にあたり、その作業自体を専門業者に外注してしまうのは転嫁にあたります。逆にその機材を使う工程自体を計画から外し、別の方法に切り替えるなら回避、影響が小さいと判断してあえて何もしないなら受容にあたります。どの対応策を選ぶかは、リスクが実際に起きたときの影響の大きさと、対策にかかる手間やコストを見比べながら判断していきます。この4分類はセキュリティ分野のリスク対応(回避・低減・共有・保有)と発想は共通していますが、呼び方が「軽減」「転嫁」「受容」と少し異なる点に注意しておきましょう。

プロジェクトコミュニケーションマネジメント

プロジェクトマネージャがどれだけ優れた計画を立てても、その内容がメンバーやステークホルダに正しく伝わっていなければ意味がありません。誰が、誰に、どんな情報を、どのくらいの頻度で、どういう手段(会議、メール、報告書など)で伝えるかをあらかじめ決めておき、プロジェクトに関わる情報が過不足なく行き渡るようにする活動をプロジェクトコミュニケーションマネジメントと呼びます。発注元の経営層には月に一度の進捗報告会でまとめて報告し、日々一緒に作業するメンバー同士は毎朝の短いミーティングでこまめに情報共有する、というように、相手や情報の重要度に応じて伝え方を使い分けることがポイントです。

進捗報告とレビュー

日々の実務の中でとりわけ重要になるのが、業務の進捗報告の仕方です。「順調です」だけの報告では、本当に順調なのか、あるいは問題を隠しているだけなのか、聞いている側には判断できません。今どの作業がどこまで終わっていて、当初の計画に対してどれくらいの差があるのか、遅れているならその原因は何かを、具体的な事実に基づいて伝えることが求められます。プロジェクトマネージャは、こうした報告や定期的なレビューを通じて、ステークホルダからの信頼を保ちながら、必要があれば早い段階で計画を軌道修正していきます。

ここまで見てきたスコープ・スケジュール・コスト・品質・資源・リスク・コミュニケーションという各領域の管理は、それぞればらばらに動くのではなく、互いに影響し合いながらプロジェクト全体を一つのゴールへと導いていきます。たとえばスコープが膨らめばコストとスケジュールに影響し、リスクが顕在化すれば品質や資源の配分を見直す必要が出てくる、というように、常にセットで捉える視点を持っておくと、試験問題の状況設定にも対応しやすくなります。