NUPPNUP1NUP2NUP3NUP4NUP5NUP6

明確な目的のない限り、何もしないこと

明確な目的がない限り、何もすべきではありません。2つのパラレルワールド（平行世界）をイメージしてみてください。そこでは、これからあなたがやろうと考えていること以外はすべて同じです。あなたがそれを行うことで、その2つの世界の間には、どのくらいの違いが生まれるだろうか？生まれるその違いは、その努力に見合うだけの価値があるだろうか？

もしあなたが明確な目的を持っておらず、ただみんながやっているから、あるいはみんなが重要だと言うからという理由だけでやっているとしたら、それは、

例: ポートフォリオとプログラム

プロジェクトの選定や始動に携わるのであれば、プロダクトではなく、そのプロダクトが生み出すベネフィット（利益・恩恵）や解決すべき問題に注力すべきです。よく言われる例として、エレベーターの製造会社で、エレベーターのスピードに関する苦情を受けていたため、スピードを上げるためのプロジェクトを何度も実施したが、成功には至らなかった。その試みは、“すぐに思いつく “解決策（エレベーターの高速化）ではなく、問題（人々の退屈や不快感）に焦点を当てるべきだと気づくまで続いた。結果として、エレベーターに鏡を追加し、シンプルかつ安価に問題を解決したのでした。

プロジェクトマネジメントとは主に物事を「正しく行うこと」であり、ポートフォリオマネジメントとは「正しいことを行うこと」というのを忘れないでください。プロジェクトをいくらうまく運営しても、間違ったプロジェクトをやっていてはうまくいきません。すべては目的を持っているかどうかなのです。

例: プロジェクト全体

プロダクトの柔軟性はプロジェクトによって異なります。あるIT開発プロジェクトでは、プロダクトにとても柔軟性をもたせ、その最終形はプロジェクトを進めながら段階的に作っていくプロダクトに対するフィードバックに依存するため、適応型（アジャイル）のアプローチが必要となるでしょう。これは実務的な言い方をすればポートフォリオ、プログラム、プロジェクトのレイヤーの組み合わせであり、最終ゴールに最大限の注意を払う必要があります。目的を文書化し、みながアクセスできるようにしておくのは良いアイデアです。これは、スクラムプロジェクトで使用されている「プロダクトビジョン」の目的の1つです。アジャイルプロジェクトでビジネス価値に注目するというのは、目的との整合性を確保するための方法なのです。

他のタイプのプロジェクトでは、プロダクトが比較的固定化されていて、そのプロダクトが目的を満たすことを確かなものにするメカニズムがあります。そこでは、プロジェクトチームのメンバーのフォーカスの多くを目的からプロダクトに移すことができます（これが、PRINCE2®の「プロダクトにフォーカスする」原則）。しかし、最小限の注意は目的にも向けられ、作っているプロダクトが目的を満たすことを確かめることは求められます。これは、期待されるベネフィットと予想されるベネフィットとを比較することで行うことができます（これが、PRINCE2®の「ビジネス正当性の継続」原則と、「ビジネスケース」テーマ）

プロジェクトが社外のクライアントのために実行される場合、クライアントにはクライアントのプロジェクトの目的があり、あなたの会社にはあなたの会社の目的があります。本当の意味で成功するためには、この2つを理解し、使い分ける必要があります。

例: プロジェクトのモニタリング

最終的な目的に焦点を当てることは必要ですが、日々の活動レベルで使うには抽象的すぎるかもしれない。そのため、より実用的にするためには階層が必要となります。まず、最終的な目的に基づいてプロジェクトの正当性とベネフィットを定義し、正当性を満たすためのプロジェクト変数（時間、コスト、品質など）のターゲットを明示的、暗黙的に設定します。これらは抽象度が低く、日々のタスクレベルで有用なものとなります。

モニタリングに関しては、最終的な目的に対してのトラッキングは難しいため、プロジェクトの最も抽象度の低い変数を用いて行います。この場合でも、その目的を念頭に置くべきです：モニタリングすることの目的は何だろうか？

通常の受け入れられる答えとしては、計画通り進んでいるかどうかを確認し、もしそうでなければ、計画に戻すためのあるアクションをとるか、あるいは目標を調整しつつ、それでも最終的な目的を満たすことができるかどうかを確認するといったことでしょう。したがって、私たちの測定することは、この低いレベルの目的において役に立つべきであり、適切な測定というものは、完了した時点での変数の予測値を示すものです。例えば、いつプロジェクトを終えることができるだろうか？プロジェクトを完了させるために必要な資金は？

これまでの計画と実績の今日までの値 など、その他の測定値はすべて、予測を計算するために必要な中間値に過ぎず、経営的な目的で使用する最終値ではありません。

例: ドキュメント

プロジェクトでどのような開発手法を使うにせよ、計画は常に必要です。重要なのは、それぞれの計画の詳細レベルです。計画に十分な詳細さがなければ、その計画は十分な役割を果たすことができず、プロジェクトの実行は、統合された全体的なものではなく、場当たり的な決定に基づいて行われることになります。その一方で、多くの人は慎重になろうとするあまり、計画に細部すぎるものを加えしまいます。そうなると、計画の作成とその維持が難しくなり、プロジェクトの不確実性に対して硬直化しすぎてしまいます。その結果、計画は非現実的で役に立たないものになってしまいます。

詳細レベルを決める最善の方法は、計画の1つ1つの要素についての目的を念頭に置くことである。例えば、計画にリソースの追加を検討しているのであれば、その目的があるはずです。そのリソースをどのように使うのか？プロジェクトにどう役立つのか？どれだけの労力がかかるのか、そして、その価値はあるのか、など。

ある要素を計画に盛り込むかどうかを決めることもあれば、何かを計画したり準備したりする方法について決めることもあります。ビジネスケースであれ、プロジェクト憲章であれ、報告書であれ、なぜその文書を作成するのか、そしてそれがプロジェクトにどのように役立つのかを自問すべきなのです。

「テンプレート」を探すという行為は、目的に基づいて何かをする行為とは正反対のものです。

例: ステータス報告

多くのプロジェクトで、本当に長いステータスレポートを作成するのをよく見かけます。このNUPに基づき、他の多くの人が何をしているかに関係なく、私たちは、「その報告の目的は何か」、「その目的を達成するにはどうすればよいか」を自問すべきでしょう。

その結果、多くの場合、長い報告書ではなく、ステークホルダーが本当に読んで理解できるような、非常にシンプルな1ページの報告書を作成することにつながるでしょう。これこそが、目的に注意を払うということです。

とはいえ、1ページの報告書を作成すると、それに反対し「適切な」モニタリング・システムを導入できていないと考える人も出てくるでしょう。現実的には、こうなると（ステーホルダーにプロジェクトの状況を理解してもらうという第一の目的以外に）あなたにとって第二の目的が生まれることになり、その目的を満たすためには、長い第二のタイプの報告書を作成すればよいのです。しかし、この2つの目的は同じではないので、最初のレポートとミックスさせることはありません。

例: ビジネスケースとプロジェクト憲章

ビジネスケースやプロジェクト憲章のような文書を作成することは、ほとんどの人にとって退屈で、実りのない、官僚的な作業でしょう。ただし、これらの文書には、ほとんどのプロジェクトに通じる正当な目的があります。もし「テンプレート」を見つけてそれを埋めようというなら、その作業は時間の無駄です。その一方で、それらの文章の真の目的を知り、あなたのプロジェクトに、どのように役立つかどうかを確認し、その目的を満たすというだけのために、好きなやり方で文書を準備するならば、それこそが正しい文書となります。

目的を満たすために、どのような文書を作成すればよいかを考えているうちに、すべてのシナリオを思い浮かべることができず、何かを見逃してしまうかもしれません。それを避けるためには、PRINCE2®、PMBOK®ガイド、P3.express、DSDM®などのリソースが示しているものを、目的を念頭におきながら参考にしてもよいでしょう。

例: ポストプロジェクト

プロジェクトには具体的な目的があり、プロジェクトを通じてその目的を考慮しますが、目的の実現は主にプロジェクト中の予測に基づいて評価されます。しかし、プロジェクトが終了したときも、目的を忘れてはならなりません。プロジェクト終了後にゴールを達成したかを確認することは重要である。なぜならば、

ポストプロジェクトのモニタリングは、目的志向型であるためには必要なステップです。これは主にプログラムやポートフォリオマネジメントシステムの責任であり、ほとんどの企業にはそのようなマネジメント階層がないため、このステップはたいてい無視されます。そのため、P3.expressやDSDM®のような手法では、このステップをプロジェクトマネジメントの方法論の中に追加しているのです。

例: シンプルさ

世界は複雑で混沌としていますが、私たちのモデルは世界の一部を反映した抽象的な近似であるため、単純であることができます。一方、シンプルなシステムの方が、中心的な考えに集中できるため、たいていはうまくいきます

私たちの多くは、システムに複雑さを加えることでより良い結果を得ようとし、それが世界の複雑さと一致することを望んでいます。実際には、これはシステムがうまく機能することを妨げ、たいてい目的を達成することを遠ざけてしまうことが多いです。

例: テーラリング

音楽をストリーミングするためのソフトウェアと、人の命がかかっているような病院や飛行機の設備に使われるソフトウェア、何年もクラッシュすることなく動くことが前提とされる人工衛星に使われるソフトウェアとでは、その状況はまったく異なります。また、別荘や消防署、製造工場を建設するのとも異なります。

目的を常に念頭に置いていれば、さまざまな異なるプロジェクトにシステムや作成物を合わせる方法をよく理解できるようになるでしょう。


翻訳者: Takashi Izumoto


▼ PDF