プロジェクトの中で目的を設定しようとしてませんか？目的はプロジェクトが始まる前に設定されていなければなりません。目的を達成するのがプロジェクトだからです
ウェブでプロジェクトの失敗の理由を検索して見てください。多くの理由が見つかりますね。
。。。スコープが曖昧、適切に計画されていない、チームがばらばら、変更が多い。。。
そして、プロジェクトの失敗の一番最初の理由として「プロジェクトで目的やゴールを設定していない」事が挙げられていませんか？
。。。しかし、これは間違いです。
「プロジェクトで目的やゴールを設定する事」は間違いです。
なぜか。
プロジェクトと目的設定の順序が逆だからです。プロジェクトは、何らかの目的を達成するための業務であり目的があって行うのです。プロジェクトを立ち上げてから目的を設定するのではありません。
プロジェクトが立ち上がってする事は目的の具現化と共有化です。
何度もしつこいですが、プロジェクトで目的を「作る」のではありません。プロジェクトを立ち上げてから、「さあ目的を明確に設定しよう！」なんてやってませんか？そんなプロジェクトが真に成功する事は難しいでしょう。
例えば、「新しい人事システムを導入する事になりました。手始めにシステム導入の目的を考えましょう！」。。
別の例として、「今やどの会社も新規事業をやろうとしているからな、わが社も新規事業プロジェクトを立ち上げよう！」と立ち上げました。「まずは新規事業計画を作ってくれ！目的と中長期の目標もしっかり立ててな！」
。。おかしくないですか？（笑）
何らかの目的があるから新しいシステムを入れる、あるいは新規事業を行うのではないのですか？
～ ～ ～ ～ ～
ところで、今や新規事業、企業内スタートアップ、オープンイノベーションはブームに近い状況になり多くの企業が手掛けるようになってきました。企業内起業を早くから導入し成功させているリクルートやサイバーエージェント、ソフトバンクのような素晴らしい会社があり、また経営トップの意識の高い数多くの会社が企業内起業を成功裏に進めています。
一方でうまく進められない会社もあります。
スタートアップは「アジャイル」や「リーンスタートアップ」等、ある程度の進め方の型（かた）が共有化されてきています。日本人は型に沿うのが得意ですから、型ができると多くの昔ながらの日本企業にとっても導入しやすくなります。
「他社がやり始めたからうちもやらないと。。」とスタートアップの思考も理解もないのに新規事業制度だけを導入する会社が増えてきます。猫も杓子も手を出すようになり、仏作って魂入れず、形だけ「イベントとして」取り入れる会社が出てきます。背景にあるべき本来の目的、改革の強い意思や覚悟のない「新規事業ごっこ」の開始です。これも明確な目的なくプロジェクトを始める事の一例です。
なお新規事業の場合は、既存事業の計画とは全く違うフォーマット・基準での目的が必要になるでしょう。
～ ～ ～ ～ ～
プロジェクトマネジメントに関する知識を体系的にまとめた「PMBOK®（Project Management Body of Knowledge）」では目的についてこう書かれています。
。。。プロジェクトのスポンサーは一般に、 プロジェクトのビジネス・ケース文書の作成と維持に責任を有する。。。
。。。プロジェクト・ビジネス・ケースは、十分に定義されていない選択された構成要素のベネフイットの妥当性を確立するために用いられる経済的な実現可能性検討文書であり、以降のプロジェクトマネジメント活動を認可するかどうかを判断する根拠となる。ビジネス・ケースは、プロジェクト立上げの目標および理由を記載したものである。これはプロジェクトの終了時にプロジェクト目標に対するプロジェクトの成功を測定するのに役立つ。ビジネスケースはプロジェクト・ライフサイクル全体にわたって使用されるプロジェクト・ビジネス文書である。ビジネス・ケースはプロジェクト立上げ前に使用され、プロジェクトの継続か中止かの決定をもたらす。
ニーズ評価は、ビジネス・ケースに先立って行われることが多い。ニーズ評価は、ビジネスの目的と目標、課題、好機を理解すること、およびそれに対処するための提案を推奨することを含む。ニーズ評価の結果は、ビジネス・ケース文書にまとめられることがある。。。。ビジネスケースおよびベネフィットマネジメント計画書は、プロジェクトの目標について、またプロジェクトがどのように事業目的に貢献するかについての情報源となる。ビジネス文書はプロジェクトに先立って作成されるが、 定期的に見直される。。。
。。。承認されたビジネスケースまたは同等物は、プロジェクト憲章の作成に最も一般に使用されるビジネス文書である。ビジネスケースは、プロジェクトに期待される成果が要求される投資を正当化するかどうかを決めるために、ビジネス上の観点から必要な情報を記述したものである。ビジネスケースは、通常、プロジェクトより上位レベルのマネジャーや執行役員が意思決定に使用する文書である。通常、ビジネスニーズと費用便益分析は、プロジェクトの境界を正当化し確立するために、ビジネスケースに組み込まれている。。。
。。。プロジェクト憲章が承認されると、プロジェクトが正式に開始する。プロジェクトマネジャーの決定と任命は、プロジェクトのできるだけ早期とし、常に計画策定に先立ち、しかもプロジェクト憲章の作成中に行うのが望ましい。プロジェクト憲章は、スポンサーまたはプロジェクトマネジャーが、立上げの関係者と連携して開発することができる。この連携により、プロジェクトマネジャーはプロジェクトの目的や目標、期待されるベネフィットをより深く理解することができる。。。
。。。プロジェクトのキックオフ会議は、通常、計画の終了および実行の開始に関連している。その目的は、プロジェクトの目標を伝達し、プロジェクトへのチームのコミットメントを得、各ステークホルダーの役割と責任を説明することにある。。。
～ 以上「プロジェクトマネジメントに関する知識体系ガイド(PMBOK®ガイド)第6版(2017年、日本語版)」より ～
少し引用が長かったですが（汗）、お分かりになったでしょうか？
- プロジェクトより上位レベルのマネジャーや執行役員が意思決定に使用する文書であるビジネスケースがプロジェクトの目的・目標を設定
- プロジェクト憲章作成時にプロジェクトマネジャーはプロジェクトの目的や目標、期待されるベネフィットをより深く理解
- プロジェクトのキックオフ会議で、チームにプロジェクトの目標を伝達し、コミットメントを得る
という順序です。
プロジェクトマネジャーが目的を作る事はないのです。ただし、目的を達成するためのプロジェクトチームとしての下位目標の設定はプロジェクトマネジャーの役割です。
上記1.ビジネスケースが不在のプロジェクトは多いのではないでしょうか？ビジネスケース不在の責任はプロジェクトマネジャーにはなく、その上位レベルの責任です。
日本ではこの上位レベルの欠如・欠陥の中、プロジェクトマネジャーが苦労して何とか頑張ってしまうケースもありますが、本来あるべき姿でない事は認識しておくべきです。
プロジェクトは組織の目的・目標を達成する手段です。この理解は組織の成長とプロジェクトを真に成功させる上で非常に重要です。
