PMstyleプロデュース

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
【目的】アカウンタビリティを果たす

【用途】メンバーに作業を分担し、責任と意欲を持って取り組ませる

【効用】メンバーが意欲で作業に責任を持つことにより、高い品質の成果物を期待できる

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

◆プロジェクトにおけるメンバーの責任

リーダーシップの役割の中で、重要なことはメンバーに責任を委ねることである。責任には、アカウンタビリティとレスポンシビリティの２種類がある。アカウンタビリティは成果責任（あるいは、成果の説明責任）であり、レスポンシビリティは実行責任を意味する言葉である。

米国と日本の感覚の差があるが、米国的なプロジェクトマネジメントの考えとしては、アカウンタビリティはプロジェクトリーダーが持つ。プロジェクトリーダーはアカウンタビリティを果たすための計画を策定し、その計画のレスポンシビリティをメンバーに委任される。そのために、ＲＡＭ（責任分担表、Responsibity Assignment Marix）を作成する。

従って、メンバーがレスポンシビリティを果たし、計画通りに作業を進めていき、成果が十分でなかった場合には、その責任はプロジェクトリーダーが負うことになる。それ以上でもそれ以下でもない。

日本的な感覚としては、レスポンシビリティはメンバーにあるが、アカウンタビリティはプロジェクトマネジャーにあると考えるのは少し違うかもしれない。日本の組織の文化は誰も責任を取らない、言い換えると、メンバーに責任を押し付けた上で不問にする文化である。アカウンタビリティはプロジェクトの連帯責任になると考えるの自然だろう。

そのような感覚の違いがあることを先にお断りした上で、どうあるべきかを議論したい。

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
【目的】権限を持たずに影響力を行使する

【用途】プロジェクトマネジャーとしての活動範囲を広げる

【効用】プロジェクトメンバーや、上位組織などを自発的に動かし、プロジェクトへの協力を引き出す。

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

◆管理／マネジメント／リーダーシップ

PMstyleではプロジェクトマネジャーの活動を

（１）管理
（２）マネジメント
（３）リーダーシップ

の３種類に分けて考えている。管理は、権限に基づいて行う活動である。プロジェクトの基本的な考え方はプロジェクトへの権限移譲により、母体組織は実現できない成果を実現することにある。その意味で、プロジェクトは管理により運営できることが好ましい。

しかし、現実には多くのプロジェクトは母体組織をベースにして行われるため、プロジェクトマネジャーが思うように活動するために必要が権限が委譲されず、母体組織に残ることがほとんどである。この制約をクリアするためには、プロジェクトリーダーに役員を据えるなど、組織上の権限とプロジェクトリーダーの権限を整合させることが現実的であるが、なかなか、そのような体制は作れないからだ。

そこで（２）のマネジメント、および（３）のリーダーシップという話になる。しかし、マネジメントとリーダーシップは補完的な役割を担う。マネジメントは本来は権限がなくては解決できない問題（あるいは権限があってもできない問題）をなんとか、いまある権限だけで解決する方法を考え、メンバーを指揮することによって実際に問題解決を行うことである。

これに対して、リーダーシップはメンバーに影響を与え、メンバーに自発的な行動を求め、メンバーの自発的行動によって問題を解決することである。

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
【目的】プロジェクトリーダーとしてのマインドセットを身につける

【用途】プロジェクトリーダーとしての行動規範を考える

【効用】多くのプロジェクトリーダーがメンバーから昇進した初期のプロジェクトで陥っている落とし穴を防ぐ
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

前半では、メンバーとリーダーはどう違うのかを５つの視点から述べた。後半は、この違いをどのように具現化していくかについて述べる。

◆コミュニケーションに意識を集中する

プロジェクトリーダーにとってもっとも重要な仕事は何か？多くの人はコミュニケーションだと答えると思う。メンバーからリーダーになったときに、まず心がけるべきことは、コミュニケーションに意識を集中することである。

プロジェクトリーダーのコミュニケーションの重要性を示すデータに以下のようなデータがある。

あるＩＴ企業でプロジェクトマネジャーの仕事時間の調査をしたところ、調査対象の８０％以上のプロジェクトマネジャーが７０％以上の時間をコミュニケーションに費やしていた。

ただし、７０％の時間の配分はプロジェクトの特性や本人の考え方によってまちまちだった。ある人は、８０％のうちの８０％を顧客とのコミュニケーションに費やし、あるプロジェクトマネジャーは８０％のうちの６０％を上司や他部門の部門長とのコミュニケーションに費やしていた。全体的に、５０％以上の時間をメンバーとのコミュニケーションに費やしているプロジェクトマネジャーはほとんどいなかった。多くのプロジェクトでは、プロジェクトマネジャーとメンバーの間に中間層になるチームリーダーがいるというのがその理由だった。

この組織では、生産性の観点からこの点を問題視しており、この後、コミュニケーションの比率を変えていった。生産性、顧客対応、社内調整のバランスがよいのは、「プロジェクトの特性にほとんど関係なく」

・チーム：５０％
・顧客対応：３０％
・組織対応：２０％

くらいだというところに落ち着いている。

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
【目的】プロジェクトリーダーとしてのマインドセットを身につける

【用途】プロジェクトリーダーとしての行動規範を考える

【効用】多くのプロジェクトリーダーがメンバーから昇進した初期のプロジェクトで陥っている落とし穴を防ぐ
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

前回までで、カテゴリ「一般」については、主だったものは紹介し終わった。PMstyle Kitは今でも毎月１個くらいのペースで増やしているので、一般、カテゴリーで重要なものが出てきたら改めて紹介することにして、連載記事は、次のカテゴリー「リーダーシップ」に移っていく。

リーダーシップに移っていく前に、番外編（カテゴリー：PMstyle）として、PMstyleが前提にしている「メンバーからリーダーへの変化」とはどういうことかを整理しておきたい。

Visaでプロジェクトマネジャーを務める Tom Kendrick がなかなか、味のある表現をしている。それは、プロジェクトリーダーは、「Staff」と一緒に働き、プロジェクトメンバーは「Stuff」と一緒に働くというものだ。この点も含めて、プロジェクトリーダーとプロジェクトメンバーには以下のような違いがある。

【目的】組織のプロジェクトマネジメント能力の底上げ

【用途】プロジェクトの振り返り時に抽出し、ナレッジ化し、プロジェクトの計画時に活用する

【効用】よいプロジェクトマネジメントプラクティスを組織に普及させ、不適切なプラクティスの再発を防ぐ
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

◆ポストプロジェクトレビューで取り上げるべきこと

プロジェクトマネジメントでは、プロジェクトの最後にポストプロジェクトレビューと呼ばれる振り返りのためのミーティングを行う。ポストプロジェクトレビューによって得られるものは「レッスンズ・ラーンド」、つまり教訓である。振り返りのミーティング自体をレッスンズラーンドと呼ぶこともある。

ポストプロジェクトレビューで必ず取り上げるべき議題は

・うまくいったこと（提言）：継続されるべきこと
・変えるべきこと（提言）：改善や変更が必要なこと
・提言の優先度
・すべてのプロジェクト参加者からの最後の意見

の４つである。

【目的】ベースライン計画によるプロジェクトの統制

【用途】組織が一体になったプロジェクト実行

【効用】正確でタイムリーな進捗報告、問題の早期発見、効率的なコミュニケーションを可能にする
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

◆ベースラインの設定

プロジェクトマネジメント計画が準備できたら、いよいよ、計画実行である。ここで重要なのは、プロジェクトベースライン設定である。ベースラインは、計画プロセスでプロジェクトマネジメント計画として決定され、プロジェクトスポンサー（やプロジェクトマネジャー）が承認をした実施計画である。

プロジェクトマネジメント計画の承認には、４つの意味がある。一つは、プロジェクト計画の内容が妥当であることだ。一つ目は、プロジェクトの目的や目標（制約）と合致した計画になっていることを認めることだ。これは主としてプロジェクトスポンサーがレビュー責任を持つ。二番目は計画の妥当性。見積もりの妥当性、業務手順の妥当性など、いくつかの視点からチェックされる。これについてはＰＭＯが責任を持ってレビューする。三つ目は、ステークホルダの期待を実現する計画であることだ。

そして、４つ目は少し趣旨が異なる意味づけで、プロジェクトスポンサーやステークホルダがコミットメントを与えるということだ。たとえば、何かと問題になるリソース確保の問題は、計画を承認した瞬間に、プロジェクトスポンサーの責任になる。

このようにして、ベースライン設定（計画承認）は、プロジェクトマネジメント計画の画竜点睛であり、かつ、プロジェクトモニタリングの始まりでもある。言い換えると、ベースライン設定は、計画プロセスから、コントロールプロセスへのブリッジである。

【目的】プロジェクトの制約をマネジメントし、計画を最適化する

【用途】プロジェクトの計画と、ステークホルダへのプロジェクトの周知

【効用】プロジェクトの当事者意識を高める
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

◆計画の２系統のプロセス

よくプロジェクトマネジメント計画策定が「形骸化している」という指摘をする人がいる。これはどういう意味だろうか？このKitでは、プロジェクトの計画策定プロセスのあり方と、形骸化の問題を考えてみたい。

プロジェクトマネジメントの計画作業は相当にシステマティックである。おそらく、ほかの分野では類を見ないくらいシステマティックで、その功績はＰＭＢＯＫにある。

計画のゴールは、プロジェクトマネジメント計画を策定すること、あるいはベースラインを設定することである。ここに向かって、大きくは２系統のプロセスがあり、プロジェクト計画という形で統合されている。一つのプロセスはプロジェクトの制約のマネジメントを計画の最適化をするプロセスである。もう一つはリスクを識別し、対応策を準備するプロセスである。

両者のプロセスの始まりは「プロジェクト要求の収集」である。プロジェクト憲章での要求事項はもちろん、ステークホルダの要求事項を収集し、整理する。そして要求に基づき、「プロジェクトスコープ定義」を行う。そして、ＷＢＳを作って、スコープを具体化する。スコープが具体化されたところで、上記のようにプロセスが分岐する。

【目的】プロジェクトを開始するために、高次のプロジェクトの記述をする

【用途】プロジェクトの計画や実行、スタッフィングの指針とする

【効用】プロジェクトの全プロセスにおいて、一貫性のあるマネジメントを実現する
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

◆プロジェクト憲章とは

プロジェクト憲章は、プロジェクトの立ち上げの過程や立ち上げ直後において発生するプロジェクトに関する情報を収集し、整理し、ドキュメント化したものである。目的は、必要なことを決め、整理し、共有することである。さらに、プロジェクトマネジャーを指名する際に、「前提」とする目的もある。

ＰＭＢＯＫの普及とともに、プロジェクト憲章という名称が定着してきたが、従来

・プロジェクト定義書
・プロジェクトデータシート
・プロジェクト起案書
・ＳＯＷ

など、いろいろな呼び方をされてきた。これ以外にも、米国では

・Reference Specification
・Plan of record

と呼ばれることもある。

プロジェクト憲章を作成しているかどうかを尋ねると、作成していると答える組織は多くないが、実質的に上記のような目的のドキュメントを作っている組織は多い。すでに、相当するドキュメントがある場合には、そのドキュメントをプロジェクト憲章に位置づけても構わない。重要なのは、情報収集の方法、ドキュメント化すること、そして、書く内容である。

【目的】プロジェクトの計画やコントロールにおける意思決定の枠組みを明確にする

【用途】プロジェクトの立ち上げ、計画、コントロールに援用する

【効用】プロジェクトにおいて、迅速かつ、ぶれない意思決定を可能にする。
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

◆インフラストラクチャーはプロジェクトのグランドデザイン

聞きなれない言葉かもしれないが、「Project infrastructure」という概念がある。プロジェクトにおける意思決定のフレームワークのことで、プロジェクトの立ち上げ、計画、実行、コントロールの基礎になる。インフラストラクチャーを決定し、ドキュメント化することにより、どのようにプロジェクトがオペレーションされるかがおおよそ、明確になる。PMstyleでは、プロジェクトインフラストラクチャーを「プロジェクト・グランドデザイン」と呼んでいる。

インフラストラクチャーは、プロジェクトを立ち上げる前に決定すべきものである。インフラストラクチャーはプロジェクト憲章で定めればよいと考えがちだが、プロジェクト憲章では遅い。たとえば、当該プロジェクトにおけるプロジェクトスポンサーの役割は何か、プロジェクト憲章を誰がいつ、誰が作り、誰がどのような視点で評価するのかといった意思決定はプロジェクト憲章を作る前に行う必要がある。

商品開発のプロジェクトであれば、事業計画の中でプロジェクトの実施を決定する際に併せて決定することが望ましい。難しいようであれば担当が決まってプロジェクトに着手する前に決定する。

ＩＴプロジェクトであれば、可能であれば受注の意思決定の中で決定することが望ましい。それが難しいようであれば、契約までには決定する。

【目的】組織としてのプロジェクトのゴール（目的）を熟議する

【用途】目的から計画への落とし込みの適切さの保証

【効用】プロジェクトの目標が適切に設定され、プロジェクトのシナリオが明確になる。また、チームビルディングの一助になる。

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

◆プロジェクトの目標を述べた最高の例

第35代アメリカ合衆国大統領ジョン・Ｆ・ケネディの行った有名な演説の一つに、1961年5月25日にアメリカ連邦議会特別両院合同会議で行った、

"I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the Earth" （10年以内に人間を月に着陸させ、安全に地球に帰還させる）

という演説がある。アポロ１１号による人類初の月面着陸のスタートとして、非常に有名な演説である。そして、この演説には、

"$531 million in fiscal '62 and $7 billion to $9 billion during the next five years"（62年は531千万ドル、5年間で70～90億ドル）

というくだりがある。このステートメントは、プロジェクトの目標を述べた最高の例としてプロジェクトマネジメントの話によく登場し、一般にもよく知られる。