NUPPNUP1NUP2NUP3NUP4NUP5NUP6

鎖の強さは一番弱いつなぎ目で決まることを忘れないこと

プロジェクトにはさまざまな領域があり、すべてに注意を払う必要があります。私たちはプロジェクトの全体的視点を持たなければなりません。一見重要そうに見えるドメイン(例えば時間)にだけ注意を払うのでは十分ではありません。なぜなら、すべての領域が相互に影響し合い、すべてに十分な注意が払われない限り、適切に機能しないからです。

例: 締め切りがすべて!

オリンピックに向けて何かを作っているとしましょう。非常に重大な締め切りがあるため、時間管理が非常に重要になります。しかし、それだけでいいのでしょうか? 品質が低すぎて、しばらくしたらまた作業を繰り返さなければならなくなったらどうなるでしょう。きっと時間にも影響が出ます。そうなると、時間と品質の問題になります。当初のプロジェクト定義には派手な庭が含まれていたとしても、もし時間が足りなくなった場合、それを省略して芝生で覆うこともできるでしょう。もし事前にその選択肢の可能性を予見し準備をしておいたならば。こうなると、スコープ管理も重要になります。結果、私たちはスコープ、時間、品質の3つの領域に注意を向けて考えることになります。

ケネディ大統領がNASAの清掃員に会い、何をしているのかと尋ねると、彼は「月に人を乗せるのを手伝っているんだ」と答えたという有名な逸話を耳にしたことがあるでしょうか。プロジェクトにそのような人材がいれば、期限を守ることに大いに寄与するのではないでしょうか。

突き詰めると、プロジェクトのあらゆる領域が時間管理に寄与していることに気づくでしょう。ただし、すべての領域に注意を払わない限り、許容可能なレベルで確実に期限を守ることはできません。

例: チェリーピッキング

私たちは、さまざまな手法に目の前にしたとき、時にチェリーピッキングを始め、様々なシステムから良さそうなものを取り出しすべてをミックスしてしまうことがあります。これは、大抵うまくいきません。なぜなら、要素は単独では機能せず、互いに相性が合わなければなければならないからです。ですので、システムにおける追加や変更を行う場合は、全体的な視点から行われるべきなのです。

私たちは時々異なる手法において相反する要素を目撃します。あるシステムではうまく機能するのに、別のシステムではその正反対のものがうまく機能する。そういった要素は、それ自体が正しいとか間違っているとかいうものではありません。

最も安全なアプローチは、プロジェクトのために方法論を選択し、それを調整し、そしてシステム全体の一貫性を考慮しながら、慎重に新しい要素をそれに加えることです。

例: アンチプロセスアプローチ

アジャイルメソッドが行ってきた最も優れたことの1つは、人間的側面に注意を引いたことです。これは公平な比較ではないかもしれないかもしれませんが、アジャイルマニフェストは、プロセスやツールなどに比べると、個人と意思疎通に重きをおいています。ほとんどすべての手法も、人間的側面が重要であるとは言ってはいますが、アジャイルメソッドが他と本当に違う点は、人間的側面をそれ単体の話としてではなく、プロセスに一部に組み込まれているところです。つまり、人間的側面なのか、それともプロセスなのかと対峙するものではなく、システムの中における人間的側面をどう捉えるかという問題なのです。

より洗練されたプロセスを持つことで人間的側面を置き換えようとする人は間違いなくいるでしょうが、それは間違った使い方です。その逆を主張する人さえいます。プロセスを人間的側面に置き換えようとする人。こちらも上手くはいきません。

例: 必要な全ての領域

領域について考えるとき、どの領域も見逃さないように注意する必要がある。とはいえ、ではそれらは何なのか?いろいろと調べてみると、さまざまな異なる答えが返ってきます。そしてどれも真実ではありません。

PRINCE2®ではテーマが領域ですが、それはあくまでこの方法論において重要な役割を果たす領域に過ぎません。他の領域は、暗に示されているくらいです。

PMBOK®ガイドは方法論ではないですが、10の知識エリアを使ってもっとうまく系統化することができます。しかし、これらは中立的な視点ではなく、プロジェクトに対するPMBOK®ガイドの視点に基づいた全領域の解釈です(必ずしも中立的な視点が必要というわけではありませんが)。例えば、人的側面はPMBOK®ガイドではあまり注目されていません。

領域に関する良い情報源の1つはICB (Individual Competence Baseline)です。(※ ICBは、IPMA:International Project Management Associationの提唱している基準です)しかし、それは領域というよりは、プロジェクトで必要とされるコンピテンシーに関するものです。そのコンピテンシーは領域と1対1の関係ではありませんが、ドメインを特定する上では大いに役立ちます。

NUPPに領域のリストがないのは、それがシステムというよりメタシステムであることが主な理由であり、また領域の分類がプロジェクトのタイプや環境によって異なるからです。(たとえば、ありふれた建設プロジェクトは、創造的なリサーチプロジェクトとは、異なる視点が必要となるでしょう)


翻訳者: Takashi Izumoto


▼ PDF