本書は、プロジェクト遂行に不可欠なプロジェクト管理について、プロジェクト管理手法で行き詰まっているコンサルタントの一助を担うことを目的とし、プロジェクトに関わる関係者が必ず知っておかなければならない（と、私が考える）観点について広く知らしめるため、プロジェクト管理に関する知見をまとめておくものです。
このブログを読んでただちにPMPに受かることは無いですし、ただちに素晴らしいプロジェクト管理技法が身につくこともありません。プロジェクト管理は一長一短で身につくものではなく、なんちゃら管理表というエクセルをきちんと整備するという泥臭い仕事を継続していくことにより、身についていくものとなります。それでも、”○○管理”ということが示す目的や、その意味を理解していないと、身につくものも身につかないので、なぜこんな管理が必要なのか、管理を行う上での肝はどこにあるのか、というエッセンスを理解いただき、各自のプロジェクト運営に少しでも役に立てば幸いです。
プロジェクトとは、プロジェクトマネジメントとは
そもそも、プロジェクトとは、何でしょうか。このブログにおけるプロジェクト、プロジェクトマネジメントの対象は、システムインプリだけと思われがちですが、そうではありません。
プロジェクトとは
プロジェクトとは、PMBOKによると、「独自のプロダクト、サービス、所産を想像するために実施する有期性のある業務」のこととされています。有限の時間、有限のコストで、なにかを成し遂げるための活動のこと、となります。システムインプリ（SI）であっても、業務改善（BPR）であっても、なにか目的があって、期日を決めて（有限の時間）、関係者をあつめて（有限コスト）、集まった人たちで仕事をしていく（プロジェクト）ことになります。ビジネス変革（いわゆるDX）も、プロジェクトとして活動する代表的なものとなります。
プロジェクトマネジメントとは
プロジェクトマネジメントとは、PMBOKによると、「プロジェクトの要求事項を満足させるために、知識、スキル、ツール及び技法を、プロジェクト活動に適用すること」とされています。少し難しくなってしまいましたね。プロジェクトの目的を達するために、ありとあらゆる知見や手法を使ってコントロールすること、と理解しています。
昔、お客様から、こんな愚痴を聞きました。『せっかく高いお金を出してプロジェクトマネジメント支援（通称、PMO支援）としてコンサルを雇ったのに、いろんなチームのステータスレポートをあつめてきてマージすることしかしてくれないんだよ、高給な派遣社員を雇ってしまったようなものだよ、これなら、事務のスペシャリストの派遣社員を雇ったほうが遥かにパフォーマンスが良いよ』
さて、様々な関係チームからステータスを集めてくることはプロジェクトマネジメントではなかったのでしょうか・・・？
プロジェクトマネジメントのデータと情報
プロジェクトマネジメントにおいては、様々なステータス情報を把握することが不可欠です。
作業パフォーマンスデータ
PMBOKによると、プロジェクトの作業に取り組んでいる状況下で、作業の実行中に把握できた“生の観察された測定値”を“作業パフォーマンスデータ”といいます。例えば、作業タスクが全部で何本あり、実際に作業完了として報告されたタスクが何本であるか、その全体に対する割合や、タスクの開始日と終了日、変更の発生した数、投入したコスト（リソースの稼働時間）、実際に要した期間のデータなどが、挙げられます。
作業パフォーマンス情報
PMBOKによると、さまざまなコントロールから収集した情報を“作業パフォーマンス情報”といいます。タスクの完了数は作業パフォーマンスデータですが、そこから導出される成果物の進捗状況や、残作業の見積もり予測情報などが、これに該当します。
作業パフォーマンス報告書
PMBOKによると、“作業パフォーマンス情報”を物理的または電子的にまとめたプロジェクト文書を“作業パフォーマンス報告書”といいます。つまり、実際のプロジェクトメンバーの作業そのもの（稼働時間やタスクが完了したかどうかなど）という“作業パフォーマンスデータ”を元に、きちんとコントロールすることで成果物作成の状況を把握できるようにしたものが“作業パフォーマンス情報”で、それをきちんとステークホルダーに伝えることができるようにビジネス文書化したものが“作業パフォーマンス報告書”となります。
プロジェクトマネジメントにおいては、生のデータである“作業パフォーマンスデータ”をしっかり抑えることが重要で、これを「ファクト」を抑えるといいます。ファクトもないのに、プロジェクトメンバーや関係者の「終わりました−」という報告を鵜呑みにしてはなりません。（個人のドラフト作業が終わっただけで、上位者のレビューが終わってなくて成果物としては成り立ってない、ということがよくあります。これにPMOのコンサルタントが気づけないということがよくあるのですが、プロフェッショナルとして恥ずかしい限りです。）
それと同時に、関係者の生のデータ“作業パフォーマンスデータ”や“作業パフォーマンス情報”を集めてきて、ホッチキスで止めただけで“作業パフォーマンス報告書”と主張するPMOのコンサルタントがいますが、これも恥ずかしいことです。きちんとステークホルダーが把握できるように報告書としてしたためて、位置づけとして正しい”作業パフォーマンス報告書”を作ることが不可欠です。（さきの例のお客様から聞いた愚痴は、これが出来ていないという事例でした）
プロジェクトマネージャーとPMO
PMOという言葉は、“プロジェクトマネジメントオフィス”の略です。PMBOKによると、「管轄する複数のチームを一元的にマネジメントし調整を行うことに、種々の責任を有する組織の一部門あるいはそのグループ」とされています。
プロジェクトマネージャと比較することで、PMO（プロジェクトマネジメントオフィス）の位置づけを確認しておきましょう。
プロジェクトマネージャーは、特定のプロジェクト目標に集中し、配分された資源（ヒト、モノ、カネ）をプロジェクト目標を最大限満足させるためにコントールすることが目的です。プロジェクトの各種制約条件（スコープ、スケジュール、コスト、品質、リスク）をマネジメントすることが責務となります。
PMOは、目標を達するために、プロジェクト全体の資源の活用を最大化することがオフィスの目的となり、プロジェクトへの大きな変更をマネジメントすることが求められます。
プロジェクトマネジメント技法について
プロジェクトマネジメントをきちんと行うには、メソドロジーが定義されているので、それにしっかり従って進めていくことが肝要です。実際には会社ごとに詳細なメソドロジーは異なるので、ここでは、共通的な観点のみ記しておきます。
プロジェクト立ち上げ時の準備
プロジェクト立ち上げ時に、最低限定義しておくべきドキュメント類を上げておきます。
1.プロジェクト憲章
プロジェクト憲章とは、PMBOKによると、「プロジェクトの存在を正式に認可する文書」と定義されています。これを作ることで、きちんと関係者にプロジェクトの存在を認識させ、プロジェクトの資源（ヒト、モノ、カネ）を動かす権限を確保します。 記載するべき内容については、きちんと関係者の認識合わせができるように、プロジェクトの目標、ハイレベルな要求事項、プロジェクトのスコープ、主要な成果物について記載します。プロジェクトに関わる全員の役割と責任を明確化し、関係者の共通理解を確実にします。
2.ステークホルダーマップ
プロジェクトのステークホルダーを特定し、プロジェクト成功への関心事、関与、影響に関する情報を分析し、文書化します。 記載するべき内容については、名前、組織での立場、場所と連絡先、プロジェクトでの役割、主な要求事項や期待、プロジェクトの成果に影響を与える可能性、関与度や影響度を記載します。 また、ステークホルダーを分類し、内部−外部、関与度、影響度、権力、関心度について、上向きー下向き、外向き−内向きを識別します。
3.プロジェクトスコープ記述書
プロジェクトスコープ記述書は、プロジェクトのスコープ、主要な成果物、前提条件、制約条件を記述した文書です。 プロジェクトスコープ記述書に、実施予定の作業と除外する作業を、どれだけ詳細に定義できるかが肝となります。ポイントは、“やること（In-Scopeの作業）”だけでなく、“やらないこと（Out-of-Scopeの作業）”についてもきちんと明文化して書き下しておくことです。 よく、プロジェクトスコープというPPT１枚のスライドに、やることだけを箇条書きで記載しているのを見かけますが、これだけだと片落ちとなります。きちんとアウトオブスコープについて定義することで、スコープが定義されることになります。
4.WBS
WBSは、プロジェクト目標を達成し、必要な成果物を生成するために、プロジェクトチームが実施する作業の全範囲を、“階層的に要素分解”したものです。 WBSは、プロジェクトのスコープ全体を系統立ててまとめて定義したものであり、プロジェクトスコープ記述書に規定されている作業を表したものとなるように作成します。
5.プロジェクトマネジメント計画書
プロジェクトマネジメント計画書は、プロジェクトを実行、監視・コントロール、および終結する方法を記述した文書です。
PMBOKの10の知識エリアについて
PMBOKでは、プロジェクトマネジメントを実施する際に求められる知識を、10に分割して定義しており、「10の知識エリア」といいます。ここでは、PMBOKの10の知識エリアについて簡単に概説しておきます。
1.スケジュール・マネジメント
スケジュール・マネジメントは、プロジェクトのスケジュールを計画を策定し、管理し、実行し、これらをコントロールするプロセスです。具体的には、スケジュールのアクティビティの定義、アクティビティの順序設定、アクティビティの所要期間の見積もり、スケジュールの作成と、スケジュールのコントロールが含まれます。
2.スコープ・マネジメント
スコープ・マネジメントは、プロジェクトを成功裏に完了するために必要なすべて、かつ必要な作業のみをプロジェクトが含むことを確認するために必要なプロセスを行うものです。 スコープのマネジメントでは、プロジェクトに何が含まれ、何が含まれないかを定義し、コントロールすることが重要となります。
3.コスト・マネジメント
コスト・マネジメントは、プロジェクトを承認済みの予算内で完了するための、計画、見積り、予算化、資金調達、財源確保、マネジメント、およびコントロールのプロセスを行うものです。
4.品質マネジメント
品質マネジメントは、ステークホルダーの目標に合致するために、プロジェクトとプロダクトの品質要求事項の計画、マネジメント、およびコントロールに関する組織の品質方針を組み込むプロセスからなります。
５.リスク・マネジメント
リスク・マネジメントは、プロジェクトの運営中に予測される様々なリスクに対し、リスクを回避したりリスクが顕在化した際の対処をスムースに可能とするよう、リスクをコントロールする（予測されるリスクの洗い出しを前もって行っておき、リスクについて対応者や対応期限等のステータスを明確にし、その顕在化を監視する）ことです。プロジェクト成功の可能性を最大限に高めるために、ポジティブ・リスクの発生確率と影響度を増加させ、ネガティブ・リスクの発生確率と影響度を減少させることにあります。
6.リソース・マネジメント
リソース・マネジメントは 、プロジェクトを成功裏に完了させるために必要な資源を特定し、獲得し、マネジメントするプロセスからなります。適切な資源を、適切な時に、適切な場所でプロジェクト・マネジャーとプロジェクト・チームが利用できることを確実にさせます。
7.コミュケーション・マネジメント
コミュニケーション・マネジメントには、プロジェクトとステークホルダーのほしい情報が、資料作成の過程と、効果的な情報交換（コミュニケーション）を達成するために意図された活動を通して、満たされていることを確実にするために、必要なプロセスが含ます。コミュニケーション・マネジメントはふたつの部分から成ります。ひとつ目は、コミュニケーションがステークホルダーにとつて効果的であることを確実にするための戦略を定義すること、ふたつ目は、コミュニケーション戦略の実施のために必要な活動をすることです。
8.ステークホルダー・マネジメント
ステークホルダー・マネジメントには、プロジェクトの作業に影響を与える可能性のある人、グループ、または組織を特定する、あるいはプロジェクトから影響を受ける可能性のある人や、影響を受けるかもしれないと思つている人を特定するために必要なプロセスが含まれます。これは 、ステークホルダーの期待を分析し、ステークホルダーがプロジェクトに影響を及ぼす程度、またはプロジェクトから影響を受ける程度を評価し、プロジェクトの決定およびプロジェクトの計画と実行を支援するためにステークホルダーからの関与を効果的に引き出すための戦略を策定することがあげられます。
9.調達マネジメント
調達マネジメントは、プロダクト、サービス、所産をプロジェクトチームの外部から購入または取得するプロセスです。調達マネジメントには 、契約、発注書、契約覚書、または内部サービスレベルアグリーメント(SLA)な どの合意書を作成し、管理するのに必要なマネジメントおよびコントロール・プロセスが含まれます。プロジェクトに必要な物資やサービスを調達する許可を得た担当者は、プロジェクト・チーム 、上層部、または該当する場合は組織の購買部門の一部のメンバーとなります。
10.統合マネジメント
統合マネジメントは、プロジェクト全体の方針を決めて、目標やプロセスを調整したり管理したりする分野です。他の9つの知識エリアをその名の通り統合して、全体をマネジメントする位置づけとされています。
※課題管理
課題管理は、PMBOKの１０の知識のように独立したマネジメントプロセスとしては定義されていません。が、すべてのマネジメントプロセスの中で課題管理を行うことが含まれており、課題管理はさまざまな場所で横断的に求められるものになっています。すなわち、課題管理をしっかりすることが、あらゆる場面で重要となってくることを意味します。
最低限のプロジェクト管理
あるべきマネジメントプロセスに対してバランス良く目を配り推進することは不可欠であるものの、軽重つけて物事をハンドリングしていくことが現実的となります。いわゆるPMO支援コンサルタントが最低限マネジメントをしっかりやるための最低限のプロジェクト管理について、次から見ていきます。
プロジェクト管理を最低限実施するときに必要なものは４つの管理をしっかり行うことです。①進捗管理、②ToDo管理、③課題管理、④リスク管理、です。プロジェクトが失敗する際の大概の原因に、これらをきちんと区別してしっかりマネジメントすることができていないことが挙げられます。課題とToDoを区別できていない、課題とリスクを区別できていない、進捗管理で管理するタスクとToDoを区別できていない、課題の粒度が適切ではない、こういったケースは少なくない状況です。
まず、プロジェクト管理をしっかり行うために必要なことは、各管理プロセスの“目的”を押さえることです。各管理の目的を押さえて、そのために必要な管理表などのツールを継続的にメンテナンスし続けるという取組みが、何よりも重要となります。
①進捗管理
進捗管理の目的は、プロジェクトにおける最終的なゴールの実現に向け、各フェーズ、タスク、チーム、並びに個々人における進捗を管理し、円滑なプロジェクトの推進を行うことで、遅延等、進捗に関する問題を早期に発見し、問題の解決方法を策定することです。
進捗管理の実施方針としては、WBS及びEVMによる進捗管理を行うこと、EVMによる進捗管理に加え、成果物作成進捗状況、及び成果物に対する指摘事項の対応状況に基づく管理を併用し、多角的に進捗状況を把握すること、進捗に遅延が発生している場合は、速やかに状況と原因の分析、対応策の検討を行った上で要員の追加、管理者・担当者の変更等、体制の見直しを含む改善策を検討することがあげられます。
具体的なツールとしては、タスク管理のツールが様々ありますが、どんなツールを使うにしても、まずWBSや小日程をきちんと計画立てるというのが大前提となります。その作業計画に対して、遅延しているのかどうかというのを視覚的に把握できる状態を作ることが必要です。ガントチャートで作業スケジュールを作成し、イナヅマ線とよばれるジグザグの線を用いて、作業の進捗状況を把握できるようにします。スケジュール表の右方向が未来を示しており、ある作業予定に対してアヘッドしていたらイナヅマは右に折れ、ディレイしていたらイナヅマは左に折れるように表現します。
②ToDo管理
ToDo管理は、スケジュール管理で管理するタスクほどではないものの、雑用レベルの作業について、これを忘れないようにリストで一元管理することが目的です。ToDoが出てきたら、必ずToDo管理表を作成し、ToDoを完了したのか未完了なのか識別できるようにします。
たとえば、会議の中で、誰か特定の関係者に、ある技術的要素に問い合わせするといったことが挙がった場合、誰が、いつまでにそのToDoを実施するのかを確認し、きちんとToDo管理表に記載することが必要です。
進捗管理で出てくるタスクと、ToDo管理で出てくるToDoの識別基準は基本的にはありませんが、目安としては、1週間以上かかる作業はタスク化して進捗管理の対象とし、1週間未満の簡易な作業はToDo管理表で管理するということが望ましいです。ここで気をつけてほしいのは、ToDoにもタスクにも同じ内容が二重計上されたままということがよくあります。最初に、何かしなければならないことが発生した際、ToDo一覧表に記載し、その後で1週間以上かかる取組ということが判明したらタスクとしてスケジュールにその内容を反映します。その際、ToDo管理表としては、実際にはタスクが完了していなくても、“スケジュールにタスクとして反映した”事をもって、ToDo管理表をクローズすることを忘れないようにしてください。
③課題管理
課題とは、目的の阻害要因となるものです。少なくともプロジェクト進捗の阻害要因となるものは必ず課題表に記載します。逆に言うと、進捗管理で“遅延”が発生したら必ずそれに紐づく課題が起票されていることが必須となります。 課題管理プロセスは、プロジェクトの運営中に発生する様々なイシューに対し、検討が遅れたり放置されたりすることによりプロジェクト運営に支障をきたすことのないよう、発生の都度確実に起票・管理し、適切に対応していくことが求められます。
課題管理の実施方針としては、発生した課題について台帳での管理を基本とすること、課題と対応方針が明確となるような課題の記載方法を定めること、課題の内容、発生日、担当者、検討状況、検討結果、解決日等の必要情報を一元管理し課題の解決に努め、また、未然防止の対応策を実施することがあげられます。
重要なことは、何が課題なのかきちんと記述することです。記述のポイントは３つあり、以下に示します。
また、課題表への書き方としては、大きく3流派あります。
ここで注意すべきことは、課題管理の内容がネクストアクションの細かい作業レベルに落ちてきたときに、ToDo管理に移管して課題をクローズしてしまうことがありますが、これは絶対にしてはいけません。課題への対応として発生している作業は、ToDoではなく、課題管理表の中で対応状況として追跡できるようにしておきます。課題表は、課題そのものが完全に解決するまで、クローズしてはいけません。
④リスク管理
リスク管理は、プロジェクトに影響を及ぼしうる事項であるものの、まだ発生していない（発現していない）事項のことで、これらを前もってリストアップし、一元管理するものです。発生頻度の高中低と、リスクが発現した際の影響度合いの高中低、で掛け合わせて点数付けして管理していきます。
リスク・マネジメントの実施方針については、管理台帳での管理を基本とすること、新たなリスクがある場合、可及的速やかにステークホルダーへ共有し、対策を講じることがあげられます。 ほとんど発生しないからリスク管理表にて管理しない、というのはNGです。発生頻度が限りなく低くても、一度発生したら大損害につながるような内容は、きちんとリスクとして定義しておきましょう。
様々なアドバイザリー案件やコンサルティング案件では、PMO支援案件ではなくても、実質プロジェクトマネジメント作業は絶対に発生します。その際に、上記に示した①〜④についてはきちんと管理を回せる状態であることが不可欠であり、そのためのケイパビリティを日々日々磨いていくことが必要です。。
0 件のコメント :
コメントを投稿