コンテンツにスキップ

プロジェクト・マネジャーが知るべき97のこと/プロジェクトマネジメントはプロブレムマネジメント

提供:Wikisource


たとえ最高の環境であっても、ソフトウェアプロジェクトのマネジメントという仕事はチャレンジングで複雑なものです。その上、プロジェクト・マネジャーが自分の役割に間違った期待を抱いたせいで、プロジェクトマネジメントをより一層難しくしているのをよく見かけます。

単純明快に言ってしまうと、プロジェクトマネジメントはプロブレムマネジメントです。そうでなければ、そもそもプロジェクト・マネジャーなど必要ないはずです。ただ実行するよう要請するだけで、すべて(リソース、技術、要件、スケジュールなど)が調整され、何の面倒もなく仕事は順調に完了するはずです。

ところが現実はそうではありません。だからプロジェクト・マネジャーという役割が存在するのです。リソースは割り当てすぎで、技術とスキルセットはマッチしていません。要求は不明確ですし、スケジュールは現実的ではありません。こうした問題のことを、仕事を邪魔する外部からの力によって引き起こされる迷惑、頭痛のたね、「問題(プロブレム)」だと考えているプロジェクト・マネジャーがよくいます。彼らはこう考えるのです。「あいつらがこれをやってくれていれば、あいつらがもっとよく考えてくれていれば、あいつらがもっと時間を与えてくれていれば、こんな不要な混乱は起こらずに、プロジェクトマネジメントの仕事をどんどん進められたのに。」

言うまでもなく、こう考えている人はいつもイライラ、ピリピリしていて、怒りっぽくなっています。

結局のところ、こうした理想と現実の違いや混乱をなくしていくことこそが、プロジェクトマネジメントの仕事なのです。私たちプロジェクト・マネジャーの役割とは、プロジェクトに資金提供する人たちやプロジェクトを遂行するメンバーたちよりも、うまく計画し、明確に考え、すぐれた戦略的ビジョンをもつことです。私たちがここにいるのは、プロジェクトの実行というものは本質的にやっかいな仕事であり、避けられない問題をつぶしたり、回避したり、取るに足らない問題へと解きほぐすために、独特のスキルと気質をもった人が必要とされているためです。

やっかいなことに、これはプロジェクトを管理することだけに留まりません。「取るに足らない問題へと解きほぐす」必要がある場合もあります。プロジェクトで一番困難なところが「技術」や「スケジュール」にあるのではなく、プロジェクトにかかわる「人」の場合もあります。その「人」というのは、プロジェクトにアサインされたメンバーかもしれませんし、上位の監督委員会に所属している人かもしれません。

簡単な典型例をいくつか挙げておきましょう。ひねくれた態度をとってプロジェクト・マネジャーの権威を弱体化させる「怒りっぽいメンバー」。たえず心配して落ち着きのない「神経質なステークホルダー」。ステークホルダーやプロジェクト参加者らが、事あるごとにプロジェクトをどう運営すべきか口を出さざるを得ないと感じる「目立たないプロジェクト・マネジャー」などです。

こうした人間関係にまつわる問題について、どのように管理するのが望ましいかを説明するのは、このエッセイの範囲を超えています。あえて言うと、こうした問題を管理しなければならないのはよくあることで、WBS(Work BreakdownStructure)を理解したり、正確なプロジェクト計画をメンテナンスするのと同様、プロジェクトマネジメント責任のスコープに含まれます。

こうした状況を業務遂行に対する障害だと考えるのではなく、それこそが自分の仕事の核心なのだと考えることで、仕事はもっと順調かつ穏やかになるでしょう。もちろん、相対的にはですが。

この作品はクリエイティブ・コモンズ 表示 3.0 アメリカ合衆国ライセンスのもとに利用を許諾されています。

あなたは以下の条件に従う場合に限り、自由に

  • 共有 – 本作品を複製、頒布、展示、実演できます。
  • 再構成 – 二次的著作物を作成できます。

あなたの従うべき条件は以下の通りです。

  • 表示 – あなたは適切なクレジットを表示し、ライセンスへのリンクを提供し、変更があったらその旨を示さなければなりません。これらは合理的であればどのような方法で行っても構いませんが、許諾者があなたやあなたの利用行為を支持していると示唆するような方法は除きます。