読者です 読者をやめる 読者になる 読者になる

プロマネブログ

とあるSIerでプロマネやっているオッサンです。主にシステム開発ネタや仕事ネタ、気になった三面記事ネタの解説なんかしてたりします。

曖昧なプロマネ権限と責任がプロジェクトを炎上に導く

テクノロジー プロジェクトマネジメント論

炎上プロジェクトの責任はプロマネが9割 - プロマネブログ

 

 はてなブックマークのコメントを沢山いただきありがとうございます。ちょっと気になったコメントが有りましたので、考えてみたく。

 

カネと期限の権限のないプロマネ = プロジェクト推進の専門家プロジェクトリーダ

気になったコメントというのは

  • 与えられた時点で予算や期限が限界を超えていて炎上必至
  • 最初から赤字プロジェクトだった

みたいな感じです。

 

で、ちょっと考えたのですが、オッサンの話の中で呼んでるプロマネとは微妙に役割が違うんですよね。。。

これって炎上プロジェクトの責任はプロマネが9割 - プロマネブログにある通り、PMBOK管理観点のスコープ管理、タイム管理、コスト管理に該当する話で、PMBOK的にはプロマネの管理の範疇の内容です。

 にも関わらず、プロマネがそれを制御できない、そういう声が多く現れているわけです。

 

実は、これら予算や期間といった管理業務から離れ、案件遂行に特化した役職としてプロジェクトリーダってのがあります。

プロジェクトマネジメント - Wikipediaを参照

 この場合、コスト責任など経営に関する責任はプロジェクトマネージャー、それに対し品質責任などの遂行責任をプロジェクトリーダが負う体制を取るのが一般です。

 

で、営業と開発チームが分離した製販分離の開発体制の場合、時折「プロジェクトリーダ」に該当する役割を「プロジェクトマネージャー」って呼んでる事例を見たことがあるんですよね。ちょっと紛らわしいんですけど。

 

上記の事例で言えば、営業がスコープ、予算、期限の権限をもっているため、「プロマネ」=プロジェクトリーダです。

 

話が紛らわしくて申し訳ないですけど、オッサンの話はここで言う「プロマネ」「プロジェクトリーダ」の両方の権限を持つ古典的な役割としてのプロマネをイメージしてました。

開発手法の検討でも記載しましたけど、スコープ管理や期間管理はなどの案件マネジメントはプロマネの役割の範疇として話してます。(でなければ、スコープ管理を行う開発手法を考える*1なんて話はできないですし)

 

さて、いろいろなコメントを貰うに、戦略的受注のため、営業の無理な案件受託のため、意図せずデスマにならざるを得なかったプロジェクトリーダは、炎上プロジェクトの責任を負うべきか、という話になるのですが、これはNoだと思います。

 

これは、営業やその他プロマネとしてのスコープ管理やコスト管理ができる立場の人間の問題です。炎上プロジェクトの責任はプロマネが9割 - プロマネブログ で話していた炎上プロジェクトの責任はそっちの人々にとってもらいましょう。

 

責任負うならカネ(=権限)をくれ!ってことで。

 

 

ただ。。。これは組織上の重要な問題を示唆していると思います。

 

炎上プロジェクトの問題を引き起こしかねない「権限と責任の分離」

この問題は、例えば、プロマネが気を利かせてリーン開発とウォーターフォール開発を組み合わせて、顧客側の仕様検討のブレに対するリスク回避しようとしても、そもそもリーン開発を選択できる権限が「プロマネ」に与えられてないわけです。

これじゃあ、開発手法で工夫してプロジェクト炎上を防ぐなんて夢のまた夢です。

 

これは、プロマネ機能を製造側と販売側に分割してしまったことが原因かなと思います。

オッサンの経験上、製販分離+受託開発でしばし見かける問題であり、販売側が過剰に製造側のプロマネ機能を侵食し、かつ責任は開発側にだけ寄っていることが問題と感じてます。(反面、製販一体な開発体制や、製販分離でもサービス開発の場合はあまり見かけた記憶が無いです)

 

では、どうするべきか。

 

基本は権限と責任を一致させればよいのですが、いくつか案が考えられます

  1. プロマネ分業案 ・・・ スコープ管理やコスト管理ができる営業を正式に「プロマネ」に、タスク管理や品質管理などの従来のプロマネの役割を「プロジェクトリーダ」とした体制を作る
  2. プロマネ専業案 ・・・ 営業はあくまでも顧客対応に限定し、スコープ管理やコスト管理を従来のプロマネに戻す。

 

対応する案件の規模や特性、顧客によりどちらの案が良いかというのは変わると思いますので、特性に合わせて上手く見極めることが必要ですね。

 

オッサン的には権限が集中する案2のほうがプロジェクト運営に対しての自由度が高くて好みですけど、反面責任もタスクも増えるので、プロマネが忙殺されるなんてこともありますし。

 

ただ、単純なプロジェクトに閉じた問題から会社組織の問題になるので、会社の文化にってはそうカンタンに変えられないでしょうけど。。。

 

まとめ

まあ、しょうもない話をだらだらと書きましたが、まとめれば曖昧な責任、曖昧な権限は百害あって一利なしになると思います。

 

よくプロマネは、プロジェクト開始時に体制図作ったりするかと思います。

メンバーが円滑に活動できるようにするためのもんですけど、オッサンだけかもしれないですが、自分の役割って見落としてきちんと定義しないことがありました。

で、体制図に書いたのはいいけど、ぼんやりとした立ち位置のせいでプロマネは何でも屋、便利屋になってしまう反面、責任ばかり負わされる損な役回りになったりして。

 

そんなこんなで、必ず役割分担表も作るのが習慣となりました。

 

※で、スコープ管理などの権限がない案件を割り振られたときは、案件推進しかやらないよって役割分担表に書いて楔をうっておくのが最初の仕事です。

 

何を今更!って感じの話ですが、オッサン自身の悪事例なので気をつけたほうがいいと思います。

 

 

 

以上

 

 

 

 

広告を非表示にする