人気ブログランキング | 話題のタグを見る

プロジェクトのオーナーシップとは何か

オーナー(Ower)とは、所有者であり、オーナーシップ(Ownership)とは所有権を意味する。ただ英語の語尾 -shipは、名詞について、それを持つ人の志や、性質や「らしさ」をも示す(例えばリーダーとリーダーシップのように)。だから、オーナーシップとは、所有者らしいふるまい、ということにもなる。

有形のもの、車とか家などのオーナーシップの意味は、誰にも明らかだ。そのものを所有して、自分の意のままにすることができる。無形のもの、例えばライセンスといったものにも、オーナーシップを考えることができる。自分がお金を払い、そこから得られる便益を自分の自由にすることができる。何であれ、それを維持する労力や費用負担し、そこから主たる価値を得るものは、それに対するオーナーシップを持つと言えるだろう。

それでは、プロジェクトのオーナーシップとは、何なのか?

X社のプロマネP氏は、困惑していた。大型プロジェクトを受注して数ヶ月。このままでは、かなりの赤字になることが明白だ。現時点での詳細設計から、全体コストを見積もり直してみると、当初想定していた金額を大幅に上回ってしまう。

顧客のA社に窮状を訴えて、追加費用を出してもらうことも考え、実際内々に打診してみた。だが顧客の反応は冷たかった。そもそも基本設計も、X社が有償で行なったのではないか。その基本設計書の内容をもとに、両者が合意して一括請負契約を結んだのだから、その通り実行してもらいたい。それが向こう側の言い分だった。

確かにその通りだ。要件定義は前任者のプロマネが行い、P氏はそれを引き継いだまでだ。ただ、顧客の業務要件は思ったよりはるかに複雑で、例外が多く、新しく入ったメンバーが理解するまでの時間も、かなり必要だった。

おまけにもっとまずい事に、プロジェクトで中心的に使うつもりでいた自社製の新型装置を、隣のチームが並行して開発中だったのだが、予定された期日からかなり遅れていた。基本設計レベルに問題があったらしく、期待したパフォーマンスがさっぱり出ないのだ。そのおかげで、上司の命令により、自分のチームから優秀なメンバーを数名、隣に回さなければいけなくなった。

仕様は思ったより膨らんでいる。優秀なメンバーもとられてしまった。あてにしていた中核装置も出来上がってこない。顧客は頑固な態度である。このままでは赤字は必至だ。一体どうしたらいいのか?

世の中ではしばしば、大赤字を生みデスマーチが見えているプロジェクトが、延々と続けられている。なぜだろうか。受注したからには完成させるのが受注者の義務? だが、たとえ違約金を払ってでも、プロジェクトから降りてしまう方が、ビジネス的には傷が小さく済む場合だってあるではないか。

だが、一般にプロジェクト・マネージャーには、プロジェクトを中止・撤退する権限はないのである。プロマネとは、プロジェクトを遂行するように命じられた存在である。遂行の義務と責任を負っている。仕事のパフォーマンスがまずくて、プロマネの職を解かれることはある。だが、プロジェクトの価値が下がったからといって、自分からプロジェクトの遂行をやめる権利は無い(会社自体を辞めてしまうなら別だが)。

そこで改めて考えてみよう。プロマネを任命するのは、一体誰か。プロマネの成果を認定し、評価するのは誰なのか?

それが、「プロジェクト・オーナー」なのである(オーナーは、業界によっては「スポンサー」と呼ばれる場合もある)。プロジェクトの価値を考え、プロジェクトを発進させ、プロマネを任命し、予算を与えるのがオーナーの仕事である。なお、プロジェクトが上位の「プログラム」の一部である場合は、プログラム・マネージャーがオーナーシップをとる。だが、日本ではプログラム・マネジメントをまともに実施している企業がほとんど無いため、そのケースは無視していい。

さて、苦境に陥ったP氏は、上司である事業部長K氏に、状況を正直に報告し、対策を相談した。事業部長が、このプロジェクトのオーナーだったからだ。そこでK事業部長も、自ら顧客に追加交渉にいってみた。だが、相変わらず相手の態度は硬い。このまま続ければ、この開発プロジェクトと、自社の新型装置開発の、二つのプロジェクトがともに道連れで沈没しかねない。

K氏はさらに上の役員と相談の上、苦渋の決断を下した。顧客A社に対し、違約金を払って、このプロジェクトから降りると宣言したのだ。

発注者A社側のプロジェクト責任者は、X社の撤退に驚き、大いに怒った。たとえ違約金をもらったからといって、費やした時間も労力もかなり無駄になったからだ。しかしA社の担当役員は、X社の決断に舌を巻き、内心、敬意を評したという。X社が受注者としてのスポンサーシップを発揮し、痛みは伴うが適切な決断を下したからだ。「確かにウチは迷惑した。だが、あの決断は大したものだ。なかなかできる決断ではない。」

撤退の判断は、つねに難しい。特に受注型プロジェクトの場合は、なおさらだ。お金も労力も失われるが、自分のメンツや顧客からの評判は丸潰れになる。業績評定にだって、大いに影響が出るだろう。

プロジェクトが完遂できないのは、明らかにプロジェクト・マネジメントの失敗である。だが、失敗したプロジェクトから、適切なタイミングで撤退する事は、正しいオーナーシップの発揮なのだ。この点を世間の人は誤解しがちなので、あえて繰り返し強調しておく。失敗したプロジェクトから思い切りよく撤退する事は、オーナーシップの失敗ではない。

オーナーシップの失敗とは、価値のなくなったプロジェクトを、延々と続ける事なのだ。プロジェクトにおいて最も恐ろしい事とは、プロジェクト自体が自己目的化してしまう事だ。ゴールに到達したが、結果は無価値で、労力と金と時間の無駄だった、という事ほど、人心を荒廃させる事はない。それはオーナーシップの不在を意味する。

わたしは授業でよく、公共事業のケースを例にあげる。有名な公共事業の中には、すでに半世紀以上にわたって遂行中で、予算規模も千億円クラスのものがある。だが、終戦直後に計画されたその事業の完成を、もはや誰も待ち望んでいない。それでも続いているのはなぜか。役人という人種が、いったん始めた事は絶対に失敗を認めないし、撤回もしないからだ。だが、繰り返す。失敗を認めず、意味のなくなった事業を続けることこそ、より大いなる失敗なのだ。

もちろん、オーナーの仕事はプロジェクトを中止し撤退することだけではない。むしろそれは最後の選択肢だ。オーナーは、プロマネを助けて、プロジェクトが意味ある仕事として完遂することを支援するのが、本来の仕事である。

以前、米国のPMコンサルタントであるNeal Whittenの主張を紹介した(「プロジェクト・スポンサーシップが足りない」 https://brevis.exblog.jp/23393425/)。彼によると、米国におけるプロジェクトの問題の1/3は、オーナーシップの不全にある、という(彼は「スポンサー」という用語を使っている)。

それでは、プロジェクト・オーナーの仕事とは何か。それは、

  • プロジェクトを起動し
  • プロマネを任命し
  • Project Charterを承認し
  • 予算枠と期限を与え
  • プロジェクトの状態と価値を定期的にウォッチし、
  • プロマネの相談に乗り、助ける
  • プロジェクトの終結を承認し
  • あるいは、無価値となったプロジェクトを中止する

こうした、プロマネに対する「上からの支援」が、プロジェクトの成功のためには、非常に重要なのである。だからあえて、以前も掲げた図をここに再掲しておこう。
プロジェクトのオーナーシップとは何か_e0058447_23034860.jpg
プロジェクト・オーナー(スポンサー)は、プロマネの相談相手として機能しなければならない。そして、プロマネの悩みはたいてい決まっている。それは、お金が足りません、か、人が足りません、なのだ。オーナーというのは上級職の仕事で、普通はプロジェクトにフルタイムで関わることはない。だが、プロマネに対しては、いつでも悩みを聞いてあげる存在でなければならない。

ところが、わたし達の社会では、これが弱いのだ。あるいは、オーナーという役割が存在しない場合も多い。その必要性さえ、認識されていない。だが、プロマネを助けないプロマネの上司とは、一体何のためにいるのか?

とはいえ、多くの読者諸賢の職場では、実際問題、オーナーというポジションは存在しないかもしれない。だったら、どうすべきか。居ないものは居ないとして、それでもプロジェクトが倒れないようにするための、現実解を考えなければならない。

わたしがお勧めする方法は、三つである。

第一に、きちんとProject Charterを作ることだ。Charterというのは、日本では「憲章」と誤訳されているが、「趣意書・許可書」のことだ。もともと英国で、国王が特に出す勅許状のことを、Charterと呼んだ。特別仕立ての飛行機のことをチャーター便と呼ぶのは、その名残だ。また英国では、公式に認定された技術者をChartered Engineerと呼ぶ。

Project Charterという文書は、組織が、そのプロジェクトを公式に認めて、その発進を許す書状である。そこにはプロジェクトの目的や目標などを書く。そして本来は、このCharterはプロジェクト・オーナー(スポンサー)が作って、プロマネに与える、という建前になっている。少なくとも、PMPの試験では、そう書かないと正解にならない、と教わったはずだ。

だが現実には、プロマネがCharterを作っている企業が大半である(だってオーナーはいないのだから)。そこでCharterを作ったら、それをしかるべき上司に、承認してもらおう。表紙にハンコの承認欄を作るのもいい。判子をもらってしまえば、それは上司が公式に認めたことになる。そして上司にも責任(命令責任)が生じる。

あるいは、もう少しモダンなやり方としては、皆で集まってチームビルディングを行う。そして、最後に皆で「コミットメント・シート」を作る。そこにサインを寄せ書きする。無論、上司には中央にサインをしてもらおう。そのシートは、プロジェクト・ルームの壁に掲げて、いつでも見えるようにしておく。こうして、オーナーたるべき人物を、責任と面子のループに取り込んでおくことが重要である。わたし達の社会は、面子とコンセンサスの社会なのだから。

第二に、プロジェクトのJournalを頻繁に発信することである。Journalというのがまた、適切な訳語がない言葉なのだが、元々は日誌のことで、転じて定期刊行物や雑誌を意味するようになった。プロマネにとって、日誌をつけるのは非常に良い習慣である。それはいざという時の法的根拠にさえなる。だが、もっとソフトな意味で、定期的な情報発信のことを、ここでは言っている。

つまり「プロジェクト週報」だとか「プロジェクト新聞」といった簡単なニュースメールを発信し、関係者皆に送りつけるのである。関係者の中には、もちろん「オーナーたるべき人」も、さらにその上司をも、送付先に含めておく。

こうして、プロジェクトの状況を、定期的に、かつできる限り頻繁に、皆に知らせておき、上層部にも関心を持ってもらう。「そんなの多分、メルーボックスの肥やしになるだけだ」などと、最初から悲観してはいけない。捨てる神あれば拾う神ありで、世の中にはたまに、ちゃんと見ている人もいるのだ。プロマネはなるべく、いろんな人に味方になってもらう必要がある。

三番目の方法は、ちょっと大技だが、プロジェクトのために「ステアリング・コミッティー」を設置してしまう(設置してもらう)やり方だ。これは、拙著『世界を動かすプロジェクトマネジメントの教科書』 (最近増刷が決まった)に書いた方法でもある。

この本では、製造業の若手エンジニア・小川君が突然、海外企業とのジョイント・プロジェクトに巻き込まれるのだが、このプロジェクトたるや、誰がプロマネなのかも判然としない。そんな中、大学の先輩だった広田氏のアドバイスをもらいながら奮闘していく物語だ。その際、プロマネもオーナーも不明ながら、なんとか仕事を前に進めるために、あえて複数部門の管理職の層でステアリング・コミッティーを設置してもらうよう、小川君が上に提案する(広田氏がそう勧めたのだ)。

その顛末は本を読んでいただくとして、いったんコミッティーを作ると、なにせ面子とコンセンサスの国だから、なんとかサポートは得られる。そして、プロジェクト・ガバナンスの点からいうと、これはこれで立派な方策なのである。

もちろん、上記の三つの方法が、いつも功を奏するとは限らない。忙しい中、権限もないのに、実行するのはかなり大変だろう。でも、本当にプロジェクトが傾いてきたら、一番こまるのはプロマネの自分なのだ。だとしたら、少しでも会社にオーナーシップを自覚してもらうべきである。

それにしても、研究会などで多くのプロジェクト事例を聞くにつけ、感じることがある。日本の多くの組織で見られる、現場リーダークラスの共通の悩み、共通の問題があるのだ。

それは、ビジョンの不在や戦略の失敗を、戦術レベルでなんとかカバーしようと努力して苦労している、という事実だ。これが、中堅若手のプロマネや、サブリーダー・クラスの疲弊感を生んでいる。たとえば、営業部門が売上目標のために無理な価格、納期で受注してきた案件を、技術部門が苦心惨憺、遂行する。そして、プロジェクトをなんとか黒字にできないか、悩んでいる。あるいは、ヘンテコな製品戦略のために、新製品開発プロジェクトが迷走し、BOMや基準情報までが混乱する。こうした例は、枚挙にいとまがない。

なぜ、そんなことに努力を費やすのか。それは、現場リーダーに与えられた権限範囲と、リーダーの責任(評価・賞罰)とが、あっていないからだ。プロマネ自身ではどうしようもない環境条件において、結果だけを評価される。ここでプロジェクトの「環境」とは、プロマネが短期的な努力では左右し得ない条件をいう。

プロジェクトのオーナーシップは、プロマネを任命する権限を持つ者にある。したがって、プロジェクトの最終的な損益やアウトカムに対する最終的責任・評価もオーナー側にあるのだ。プロマネは与えられた条件下で、どこまで良くやったか(計画し遂行したか)を評価されるべきである。プロマネは、自分では途中でやめられないのだ。プロマネには実行責任がある。だが、命令責任は、オーナーは負うべきなのである。


<関連エントリ>
 →「プロジェクト・スポンサーシップが足りない」 https://brevis.exblog.jp/23393425/ (2015-07-08)
 →「アカウンタビリティとは『命令責任』である」 https://brevis.exblog.jp/24837740/ (2016-11-05)


by Tomoichi_Sato | 2019-01-17 23:12 | プロジェクト・マネジメント | Comments(0)
<< ITシステムのオーナーシップとは何か 望みと抱負とふりかえり >>