目次
近年、プロジェクトはますます複雑化しているように感じます。
記憶に新しいCOVID-19の蔓延によりリモートワークが一般的となり、プロジェクト形態の自由度が高まったことでよりプロジェクトは発足しやすくなりました。
しかし、その一方で先端テクノロジーの目覚ましい発展や顧客ニーズの多様化により、プロジェクトに対する要求はよりシビアなものとなり、頭を抱えている方も多いのではないでしょうか。
全国のプロジェクト管理ツールの利用者1,000人を対象に実施された『プロジェクト管理ツールに関する調査報告書(2023年4月)』によると、COVID-19の蔓延前後で比較した際のプロジェクトの複雑さに対して、「複雑になった」「やや複雑になった」という回答は全体の約半数(45.8%)を占める結果となりました。
複雑化するプロジェクトでは、より失敗のリスクが高まっており、プロジェクトの規模が大きければ大きいほど失敗による損害も大きなものとなります。
そのためプロジェクト失敗のリスクを最小限に押さえ成功に導く、正しいプロジェクトマネジメントはより重要になってきていると言えます
本稿では、プロジェクトマネジメントを正しくご理解いただくために、まずプロジェクトマネジメントの全体像からご説明し、その後に具体的なプロジェクトマネジメントの手法を解説してまいります。
PM/PMOとして初めてプロジェクトマネジメントに触れる方にもご理解いただけるよう、1つずつ順序立てて解説しますので、ご参考となれば幸いです。
プロジェクトマネジメントの詳しい内容に入る前に、そもそもプロジェクトとはどのようなものであるか改めて考えてみましょう。
プロジェクトと言うとほとんどの人が理解されているように思われますが、正しいプロジェクトマネジメントを実施するためには、まずプロジェクトの定義を正確に理解する必要があります。
一般的な定義によるとプロジェクトは「独自のプロダクト、サービス、所産を創造するために実施する、有機性のある業務」とされています。つまり言い換えると、限られた期間内で顧客の要望する製品やサービスを生み出す業務と言えるでしょう。
重要なのは「限られた期間内」という点です。
どんなプロジェクトであっても期間が限られており、決まった期間内で成果を出す必要があります。
前項で少し触れましたが、プロジェクトには必ず目標が設定されます。
期間であれば、3ヶ月後~3年後など、スパンに差はあれど原則どのようなプロジェクトにおいても特定の指標が設定されます。
プロジェクトにおける指標は、一般的にQCD(Quality/Cost/Delivery)に基づいて設定されるケースが多いです。
品質、予算、納期を指すQCDはプロジェクトの成否を測りやすく、かつ、定量的に設定しやすいためプロジェクト状況をモニタリングする上で重宝されます。
QCDはプロジェクトの開始時に設定され、以降プロジェクトの終結まで設定されたQCDを目標としてプロジェクトは動いていきます。そして、プロジェクトマネジメントはQCDを満たせるようにプロジェクトを導く重要な役割を担っています。
改めて、プロジェクトマネジメントとは、QCDを満たしプロジェクトを成功に導くための管理全般を指します。
プロジェクトマネジメントの知識体系には、プロジェクトマネジメント協会(PMI)が策定したPMBOK、英国商務局が策定したPRINCE2など複数の知識体系がありますが、今回は、より汎用的に活用されているPMBOK(第6版)で定義されている全体像からご説明します。
PMBOKはProject Management Body Of Knowledgeの略称で、プロジェクトマネジメントを体系的にとりまとめたガイドブックを指します。
1969年、プロジェクトマネジメントの普及を推進するために設立されたプロジェクトマネジメント協会(PMI)によって策定されました。
PMBOKは業種を問わずに適用することができ、IT業界に限らず、建設業界や広告業界など、様々な業界で活用されています。
初版が発行されたのは1996年で、現在の最新版は2021年に発行された第7版です。
第7版では、増加傾向にあるアジャイルプロジェクトに適用しやすいように、固定化された方法論というよりは概念的な内容が多く記述されています。
しかし、プロジェクトマネジメントの全体像を掴むという意味合いでは、前版の第6版が非常に理解しやすいので、今回は第6版をベースにご説明したいと思います。
※以降、「PMBOK」は全て第6版を指す
PMBOKでは、10の知識エリアと5つのプロセスによって、プロジェクトで実施すべきマネジメント作業が定義されています。
10の知識エリア
統合管理 | 他9つの知識エリアと5つのプロセスの進め方を定義する知識エリア |
スコープ管理 | プロジェクトやフェーズにおける作業範囲や、成果物を定義する知識エリア |
スケジュール管理 | プロジェクトのスケジュール管理について定義する知識エリア |
コスト管理 | プロジェクトで承認された予算管理について定義する知識エリア |
品質管理 | 生成される成果物やプロジェクトの品質について定義する知識エリア |
リソース管理 | メンバーなどの人的資源や、物的資源の管理について定義する知識エリア |
コミュニケーション管理 | プロジェクトにおけるコミュニケーションラインや内容および方法について定義する知識エリア |
リスク管理 | プロジェクトにおけるリスクの特定・分析・対応方法やモニタリングの仕組みについて定義する知識エリア |
プロキュアメント(調達)管理 | 契約締結やベンダーの管理について定義する知識エリア |
ステークホルダー管理 | ステークホルダーの関与度や管理について定義する知識エリア |
5つのプロセス
立ち上げ | プロジェクトまたはプロジェクトの新しいフェーズを明確に定め、それらを開始する認可を得るプロセス |
計画 | 作業全体のスコープを確定し、目標の定義とブラッシュアップを行い、目標を達成するのに必要な一連の行動の流れを規定するプロセス |
実行 | プロジェクト目標を達成する上で、プロジェクトマネジメント計画書において規定された作業を実行するプロセス |
監視・コントロール | プロジェクトの進捗やパフォーマンスの追跡、レビュー、統制、計画の変更が必要な分野の特定、およびそれらの変更を開始するプロセス |
終結 | プロジェクトやフェーズを公式に終了するための、全プロジェクトマネジメント・プロセス郡内の全アクティビティを終結するプロセス |
各知識エリアおよびプロセスにおける実施作業をマトリクスとしてまとめると下図のようになります。
全49の実施作業が定義されていますが、PMBOKはあくまで汎用的な知識体系に過ぎません。
プロジェクトによって対象となる知識エリアやプロセスは変動するため、プロジェクトに応じて最適な方法へアレンジする意識を持って活用することが重要です。
ここまでPMBOKをベースに、プロジェクトマネジメントの全体像についてご説明いたしました。
ここからは、主要なマネジメント対象に絞って具体的な手法を、私のプロジェクト経験も踏まえてお伝えしようと思います。
進捗管理ではプロジェクトが滞りなく、予定通りに進んでいるかをモニタリングし、遅延が発生しないようプロジェクトの関係者に働きかけます。
実施作業としては、プロジェクトの立ち上げフェーズで規定されたマスタスケジュールから遅滞なくプロジェクトを完遂させることを目的に、WBSを作成します。
WBSとはWork Breakdown Structureの略称で、プロジェクトで実施すべき作業を細分化した構成図を指します。
プロジェクトを遅滞なく進めるためには、作業が細かく分解されており、かつ、誰がいつまでに完了する必要があるかも含めて設計されている必要があります。
WBSは基本的にマスタスケジュールをベースにして、各工程で実施すべき作業に分解していきますが、分解する際は「実施作業の網羅性」に注意する必要があります。
仮に、実施作業に漏れが発生していた場合、成果物が作成できない、スケジュールが遅延するといった影響が生じかねないため、十分に注意を払いましょう。
実施作業に漏れが生じないように設計するためには、プロジェクトにおける作業を1つ1つ明確にイメージし想像力を働かせることが重要です。
WBSの作成後は、プロジェクトの進行に応じて進捗を管理します。
原則、進捗管理はWBSをベースに日次で実施しましょう。プロジェクトは1日であっても、様々な動きがありますし、1日放置してしまうだけでも致命的なスケジュール影響を及ぼすケースがあったりします。
ですので、進捗は日次で確認し、もし既定の完了予定日に間に合わないのであれば、対応策の検討・実行と間に合わない原因を追求し、以降の発生を防止するように働きかけましょう。
課題管理では、プロジェクトで発生した課題と対応状況を正確に把握し、解消に導くことが求められます。
では、そもそも課題とはなんでしょうか。日常的に使われる単語ではありますが、正しい課題管理をするために定義を明確にしておきましょう。
課題とは、一言でいうと問題を解消可能な粒度に分解したものを指します。
あるべき姿と現状のギャップを指す問題の原因を分析し、誰がどのように解消するかまで具体化できている状態と言えるでしょう。
あるべき姿 | タスクAが予定通りに完了する |
現状 | タスクAが予定完了日から2日経過しているが完了していない |
問題 | タスクAが2日遅延している |
課題 | 突発的な他タスクにより担当者のIさんのリソースが不足している |
プロジェクトの障壁となっている課題を解消に導くのが課題管理の役割です。
課題を管理するためには、課題管理表を作成します。
(課題管理表と呼んでいますが、目的が達成できればプロジェクト管理ツールであっても構いません)
先述の通り、課題管理では課題を正確に把握し、対応策を検討・実行・解消することが求められます。
そのため、どのような課題が発生しており、誰がいつまでに解消必要なのか、またどのように解消するかを可視化する必要があります。
課題管理表を作成する際に重要なことは、対応策を誰もが実行可能なレベルに細分化することです。
対応策が抽象的であると、実施する内容に認識齟齬が発生したり、そもそも実施することができないといったケースに発展したりする可能性が高まります。
そのため、対応策は具体的に設定し、解消に向けた対応状況が把握しやすくなるように心がけましょう。
リスク管理では、プロジェクトで発生しうるリスクを洗い出し、事前に対策を検討し、実行するまでのプロセスを管理します。
進捗管理、課題管理はどんなプロジェクトであっても原則実施すべきですが、リスク管理は必ずしも実施すべきとは限りません。
それは、リスクが将来的に発生する可能性がある事象であり、当該時点では発生していない事象であることに起因しています。
プロジェクトをより盤石に進めていくためには実施すべきですが、規模感によってはリスク管理の工数を考慮して、実施不要とするケースもあります。
リスクを管理するためには、リスク管理表を作成します。
構成自体は課題管理表と大きく変わりませんが、リスク管理特有の項目として「発生確率」(リスクがどの程度の確率で発生しうるか)や「影響度」(リスクが顕在化した場合のプロジェクトに対する影響度)は最低限含めたほうが良いでしょう。
リスク管理をする際に重要なことは、リスクを洗い出す機会を定期的に設定することです。
リスクは基本的に際限がないため、洗い出せた分だけプロジェクトがより安全に進められるようになります。
とはいえ、1人でプロジェクトの未来をイメージすることには限界がありますので、プロジェクトメンバーの考えを持ち寄ることで、多種多様なリスクを想定しておくことができます。
ですので、リスク管理を実施する際は、リスクを洗い出す機会を仕組みとして設定することを心がけると思います。
本稿では、まずプロジェクトマネジメントの全体像からご説明し、その後に具体的なプロジェクトマネジメントの手法についてご説明してまいりました。
プロジェクトがますます複雑化する現代において、プロジェクトマネジメント知識の有用性は今後さらに増していくことと思われます。
プロジェクトマネジメントの考え自体は50年ほど前から存在しており、これまでに様々な知識体系が構築されてきました。
今回はその中の1つであるPMBOKについてご説明しましたが、あくまで知識体系に過ぎません。
プロジェクトは多様な要素から成り立っており、目まぐるしく状況が変わっていきます。
そのような特性を持つプロジェクトを、特定の体系に沿って管理することは難しいでしょう。
もちろん知識として持っておくに越したことはないですが、最終的にはプロジェクトの特徴を鑑みて柔軟に工夫するプロジェクトマネジメントを心がければ自然と成功に向かっていくのではないかと思います。
本稿が皆様のご参考となれば幸いです。
【参考】
プロジェクトマネジメント協会(2018)『プロジェクトマネジメント知識体系ガイド PMBOKガイド 第6版』
プロジェクトマネジメント協会(2021)『プロジェクトマネジメント知識体系ガイド PMBOKガイド 第7版』
前田和哉(2019)『PMBOK第6版の知識と手法がこれ1冊でしっかりわかる教科書』
鈴木安而(2018)『よくわかる最新PMBOK第6版の基本』
日経XTECH「アンケート調査から紐解く企業課題」
アーツアンドクラフツ Consulting & Solution事業部/アナリスト
2020年早稲田大学文化構想学部卒業。ITコンサルティング分野において、CRM/SFAシステム導入支援の実績を保有。