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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

の４つである。

◆レビューはドキュメントに基づき行う

ポストプロジェクトレビューのベースになるのは、プロジェクトドキュメント（ログ）である。したがって、ポストプロジェクトレビューの前に、すべてのプロジェクトドキュメントが更新され、プロジェクト報告がそろっている必要がある。特に

・スケジュールの計画と実績
・リソースの計画と実績
・統合変更管理の履歴
・課題管理の履歴と、問題のエスカレーションの履歴
・プロジェクトメトリクスの実績
・パフォーマンスレポート

などについては最終情報が使えないとポストプロジェクトレビューを開催する意味がないので、うまく段取りをする必要がある。

◆教訓を得る方法

上のような情報・データに基づく振り返りを行い、教訓を得る際の視点は３つある。一番目は

（１）是正措置や問題解決方法の有効性

である。ベースラインとの差異が発生した際に実施した是正策が有効だったかどうかを検討する。有効な場合にはその是正策は継続されるべきこととして教訓化される。有効でなかった場合にはどのような策を講じるべきだったか、つまり、改善すべきこととして取り扱われ、改善された教訓が残る。

二つ目は、

（２）リスクの充足度

である。つまり、発生した問題がリスクとして想定されていたかどうかである。想定されていない場合には、リスクチェックリストに反映される必要がある。想定されていた場合には、なぜ、問題となる以前に対処できなかったかを分析し、教訓として残しておく必要がある。

三つ目は、

（３）コミュニケーション

の視点である。問題が発生したときには、必ずといってよいくらい、コミュニケーションの問題が潜んでいる。このことは常に意識すべきであり、振り返りでは常にコミュニケーションに関する教訓の発見に努めるべきだろう。

◆レビューミーティングの運営

よい教訓を得るために重要なのはミーティングの運営である。

まず、アジェンダのレビューをすること。そして、ミーティングのルールを設定することから始める。

次に、会議の中ではできるだけ多くの人から意見を引き出すように心がけること。そのためには、問題解決や個人的な攻撃に走らないことだ。よいプラクティスの発見に努め、問題に対しては、改善の機会を議論すること。

ホワイトボードなどに書き留めるアイデアは選ぶこと。ブレンストーミングを行っているわけではないことを理解する。

ある程度、意見が出尽くしたら、モードを切り替える。個別の問題を対象にして、コンフリクトの解消をしていく。その方法は、原因結果分析や、プロセス改善、ブレンストーミングなど、いろいろな方法を使うとよい。システム思考を使うのも効果的である。

この場面でも可能な限り、多くの人が発言できるようにする。結局のところ、レッスンラーンドはコミットメントの質と量だということを心得ることだ。

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

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

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

◆ベースラインの設定

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

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

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

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

ベースラインが設定されたら、コミュニケーションの計画にしたがって、１週間に一度程度、プロジェクトの状況データを収集する。

そして、ベースラインと実績データを比較し、「差異（バリアンス）」の分析を行う。分析をして、コストやスケジュールのベースラインの差異が許容範囲内の場合には、現状のパフォーマンスについての報告を作成し、コミュニケーション計画に従って情報配布を行う。同時に、差異を縮小するために、スコープ、コスト、スケジュールの調整していく。

差異分析で、許容範囲以上の差異が発生した場合には、いくつかすべきことがある。許容範囲を超えると多くの問題はプロジェクトだけでは解決できなくなる。そこで、まず、その問題を分析・整理し、解決できる権限を持つ人にエスカレーションをすることが必要である。また、外注が絡む場合には、あらかじめ決められたマネジメントプロセスがあればそのプロセスに従った処理をする。なければ、問題解決の方法について外注先と協議する必要がある。

情報配布は定期的にプロジェクトスポンサーが参加するプロジェクトレビュー会議に対しても行われる。差異が許容範囲を超える場合、レビュー会議では、ベースラインの再設定が行われる。また、差異が許容範囲を超える場合だけでなく、問題が解決できず、是正の可能性がないと判断される場合にもベースラインの再設定が行われる場合がある。

◆ベースラインを使った振り返り

以上のサイクルが、プロジェクトマネジメント計画実行の基本的なサイクルであるが、プロジェクトが終了したら、終結プロセスに入り、振り返りが行われ、プロジェクトは終結する。

終結においても、ベースラインは重要な役割を果たす。ベースラインとの差異が出てきた局面にフォーカスし、是正の妥当性が振り返りの対象になる。

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

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

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

◆プロジェクト憲章とは

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

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

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

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

・Reference Specification
・Plan of record

と呼ばれることもある。

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

プロジェクト憲章を書くためには、必要なインプット情報を収集し、整理する必要がある。情報にはさまざまな性格のものがあるので、いくつかに分けて考えるとよい。PMstyleでは、

（１）スポンサーシップ情報のレビュー
・プロジェクトのビジネスニーズ
・ビジネスニーズからみた問題
・そのほか、プロジェクトに関連するすべての情報

（２）プロジェクトゴールの設定
・プロジェクトに望まれる結果
・プロジェクトのゴール

（３）条件の決定
・制約条件
・前提条件
・初期のプロジェクトスタッフに関する情報

（４）プロジェクト環境
・プロジェクトに関連するビジネス標準
・プロジェクトに関連する組織的な要請

という手順を推奨している。

プロジェクトの立ち上げはプロジェクトの成果にもっとも大きな影響を与えるフェーズであり、組織の創意や実力、マネジメントスタイルが顕在化するところであり、１００の組織があれば、１００通りのプロジェクトの立ち上げ方があるといってもよい。そのため、プロジェクト憲章の内容も、プロジェクト（マネジメント）計画ほど、標準化はできないし、また、すべきではない。

たとえばPMstyleでは、経験と推奨するマネジメントのスタイルに基づき、以下の項目を含めることを推奨している。ただし、プロジェクト憲章の見立てによっては、必ずしもフィットしないので注意しておいてほしい（たとえば、ＳＯＷをプロジェクト憲章に見立てると、書けない項目がある）。

・プロジェクトの目的
・定量的な成功基準
・プロジェクトの優先順位
・抽象的なレベルでのスコープ定義と、スコープ除外範囲
・ユーザや顧客の期待
・ステークホルダ特定の結果
・プロジェクトのビジネスケース
・コストの概算見積もり
・納期、および、特に重要なマイルストーン
・プロジェクトマネジャーと初期スタッフ
・他のプロジェクトとの依存関係
・プロジェクトライフサイクルと、プロジェクト管理への要求
・主要な制約と前提
・認識されているイシューと組織レベルのリスク

◆プロジェクト憲章の使い方

完成したプロジェクト憲章のもっとも重要な用途は、ステークホルダの要求マネジメントである。ＩＴのようにプロジェクトが外部の顧客のために行っているものであれば、プロジェクト憲章は契約交渉に使うと同時に、組織内部の契約条件の承認に使う。

また、プロジェクトの実施においては、要求収集、プロジェクト計画の作成、プロジェクトレビューに使う。

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

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

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

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

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

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

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

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

プロジェクト憲章を作るようにしたものの、あまり効果が出ないケースは、インフラストラクチャーがきちんと整備されていないケースが多い。グランドデザインを持たないままで、プロジェクト憲章でプロジェクトデザインをしているわけだ。

イメージがわきにくいかもしれないので、PMstyleで使っているインフラストラクチャー（グランドデザイン）の例を示す。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億ドル）

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

プロジェクトの目標（オブジェクティブ、あるいは、ミッション）は、シンプルな、短いプロジェクトについて記載したステートメントである。プロジェクトスポンサー、顧客、ステークホルダによって草案され、プロジェクトリーダーがまとめるのが一般的である。

よく知られているように、プロジェクトの目標は、

・デリバブルズ（スコープ）
・デッドライン（スケジュール）
・投資（コスト）

の３つの要素からなる。

プロジェクトの目標を記載するに当たってはよく言われる注意点は以下のようなものである。

・２５ワード程度に収めること（英語で、Twitterを例にとれば５０文字くらいか？）
・情報を言葉に置き換えること
・プロジェクトの本質を簡潔に記述していること
・専門用語、略語、慣用表現などの誤解のもとになる言葉を使わないこと
・成果物をすべてのステークホルダが理解できる普通の言葉で書くこと
・明確な時期を示すこと
・可能な限り、リソースの特定をすること

◆プロジェクトの本質とは何か

ジョン・ケネディーの宇宙開発への演説は、これらの要素をクリアしている。この中で、もっとも、難しいのはプロジェクトの本質である。

ジョン・ケネディーの演説の背景には、当時、冷戦状態だったソ連との宇宙開発競争がある。

ソ連は、1957年10月4日の初の人工衛星スプートニク1号を打ち上げ、さらに、1961年4月にはウ゛ォストーク1号で初の有人地球周回飛行を行います。いずれも米国に先駆けて行われたものだ。

冒頭のケネディーの演説は、ソ連の有人地球周回飛行の直後に行われたものだ。

このような状況で、プロジェクトの本質とは、ソ連に勝つという目的だ。

ソ連に勝つには、初の月面着陸しかない。そこで、簡潔、かつ、ストレートに、１０年以内に月に降りるという目標を掲げている。

実際に、1969年7月20日、このスピーチからわずか8年後には、月面着陸を達成している。残念ながら、ジョン・ケネディは暗殺され、それを見届けることはなかったが、このような結果を伴ったことが、ジョン・ケネディの目標の提示が素晴らしいと言われる一因になっている。

◆プロジェクト目標の記述により、目的に対する熟考が行われる

プロジェクト目標は、単に上位組織からの指示の確認ではないことに注意しておく必要がある。たとえば、プロジェクト憲章に

・顧客満足を達成し、顧客ロイヤリティを獲得する

という目的が定義されているとしよう。そこで、

「顧客満足を達成する」

といった抽象的な目標を設定しているプロジェクトが少なくない。また、顧客満足度測定のシステム（仕組み）を整えている組織では、

「顧客満足度レベル４以上を獲得する」

という目標を設定したりする。

これは、いずれも好ましくない。まず、前者は論外だ。目標になっていないことは説明する必要もないだろう。問題は後者だ。

一見、合理的に目標設定がされているように見えるが、結果を言っているだけであって、目標だとはいえない。プロジェクトの本質とは、目的を実現するにはどのような目標を達成すればよいかというごく当たり前の話だ。

たとえば、

・スケジュール（納期）は顧客要望通りでいいのか
・要求の分析と取扱いは
・品質レベルは

といったことを目標として設定しなくてはならないわけだ。上位組織の目的から、このような目標を決める過程で、当然、その納期、品質レベルで顧客は満足するのかという議論になるし、また、そこにコストの議論も出でくる。

つまり、上位組織とプロジェクトの目的について熟議する過程がプロジェクトの目標を決める過程にほかならない。