プロジェクトの「補助線」

【補助線】マクドナルドに学ぶ「価値」の標準化

本ブログは移転しました。こちらをご覧ください。

マクドナルドが地域別の販売価格の導入をする。

改めて説明をするまでもないと思うが、マクドナルドは標準化をコアコンピテンシーにする企業である。ぼくは仕事柄、あちこちに行くが、マクドナルドほど均質なサービスを提供している外食チェーンやファーストフードはないと思う。特に、カウンターでの対応と、デリバリーの時間の均質さは凄いと思う。

そのマクドナルドが自ら標準を破った。表向きの理由は、コストの違いだという。店舗の維持費、労働コストなどが都会と地方では違うので、変えるとのこと。まあ、こういう言い方がもっとも当たり障りがないのだろう。

標準もある程度成熟してくると、高度化させていく必要がある。最初は、材料であり、プロセスであり、デリバリ時間であり、価格であり、コストであった。しかし、これらはいずれも内部要因に起因するものであるので、自分たちは標準的だと思っていても、外からはそうは見えないケースが多い。

プロセスの標準化をみているとすぐに分かるが、プロセスの標準化を阻害するものは外部要因である。ビジネスプロセスであれば、顧客、地域、調達などが問題になることが多い。しかし、これを公式に扱うことは非常に難しい。それゆえに、各部門で実情に併せて、カスタマイズして使ってくれという話になる。標準化という名をとって、実を捨てた格好になる。

なぜ、難しいのだろうか？標準から外してよいものと、残すものが分からないのだ。

標準化が一定の浸透をしてきた際には標準化されるべきものが変わる。最初は外面的、具体的なものであるが、それがだんだん、内面的、抽象的なものに変わって行く。これがプロセスが成熟するという意味だが、新たに標準化すべき対象を見つけるのが難しいのだ。

このマクドナルドの動きを見ていると、さすがに標準化のチャンピオンといった感じを受けた。

マクドナルドが標準として残しているものは、顧客とっての価値の標準化ではないかと思う。今回の地域別価格でそれがすべて実現できるかどうかは微妙だ。むしろ、テスト的な意味合いがあるのだと思うが、価格といった外形的なものではなく、顧客にとっての価値という抽象的なものを標準化するという発想は素晴らしいと思う。

もっとも、今までもマクドナルドは、「スマイル０円」という価値の標準に先鞭をつけていた。これは、ウィットだと捉えられていたと思うが、今度はいよいよ、価値の問題の本丸に手をつけた。成功するかどうか、見ものである。

さて、我々のビジネスに戻るが、カスタマイズというのは本来、部門に任せるものではない。マクドナルドでも、地域別にするというのだけを決めて、価格は地域で決めてくれというと大混乱が起るだろう。

標準に対するオーナーシップは、標準を策定する部門が持ち続ける必要がある。その中で、ユーザにとっての価値のメトリクスを導入し、そのメトリクスが、フェアになるようにカスタマイズを仕切っていくことが重要である。

【補助線】人だけが成長し、組織が成長しないと、人はジレンマに陥る

本ブログは移転しました。こちらをご覧ください。

ビジネスでは、「最後はひと」とか、「結局はひと」とかとよくいう。

いくら仕組みやルール、環境を作ってみてもそれを活用するのは人なので、人がそれらをうまくできるようにならないと何の意味もないという意味の言葉である。特に、人材育成の重要性を指摘する言葉として言われることが多い。

ところが、プロジェクトマネジメントの世界を見ていると、しばしば、十分な仕組み、ルール、環境を整えない中で、「最後はひと」だと言っているケースがある。

とりあえず、戦う武器（仕組み、環境など）がない。ひとこそ、それを補う存在である。そんなニュアンスで使われている。まるっきり、特攻隊である。

ビジネスにおいてひとが重要であることは間違いないが、ひとに対する過剰な依存は禁物である。マネジメントの放棄に繋がる。組織としての活動はよい仕組みや環境があって、はじめて、人が能力を発揮し、また成長する。そして、その成長がより仕組みや環境をよいものにする。この循環をつくることこそ、マネジメントの責任である。

ここで大切なポイントは

　・人だけが成長し、組織が成長しないと、人はジレンマに陥る

ことである。このような状況はいたるところにある。つい最近も、知り合いがやっている中堅のＳＩ企業で、この５年くらい一生懸命にプロジェクトマネジメントに取り組んできた部長が、会社をやめるという出来事が起り、社長から相談されたことがあった。

その社長の話はざっと以下のようなものだ。やめた部長（Ａ部長）は、自社の成長のためにはプロジェクトマネジメントの定着が必要だと考え、取り組んできた。自身はいろいろと勉強し、ＰＭ手法を導入し、メンバーにもいろいろと教えて、ツールも自分なりに作ってきた。

その会社では、役員と部長がほとんどのプロジェクトのマネジャーを担当している。最近では、Ａ部長に感化されて、一部の部長もプロジェクトマネジメントを行うようになってきたし、役員の一部も興味を持ち出した。ところが、一部の役員はまったく必要性を感じておらず、無関心。

Ａ部長のプロジェクトのメンバーになったら、スケジュール以外にもいくつかの計画書を作り、それを使いながら、やっていく。メンバーも徐々にではあるが、計画してプロジェクトを進めることの重要性がわかってきだした。ところが、何人かの役員がプロマネを務めるプロジェクトに入ると、そんなものに時間を割いている時間があれば、開発作業をしろといわれる。かといって、そのようなプロマネのプロジェクトが必ず失敗するわけでもない。成功しているものも多い。

これでメンバーがジレンマに陥り、やめたり、部長に相談するという状態が続いたが、ついに、部長自身もイヤになったようで、やめていった。どうすればいいだろうか？

という相談だった。典型的な「人だけが成長し、組織が変わらないとジレンマに陥る」というケースだ。

なぜ、変わらないかという部分で、この社長自身のリーダーシップの問題は大きいと思われる。しかし、それ以上に大きいのは、役員や部長といったあたりが、組織が変わらなくても、個人が変われると思っている点だろう。これを変えなくてはならない。社長には変えていくためのリーダーシップが必要だ。

そんなことを思わせる話だった。では、社長はどういうリーダーシップを持てばよいのか？これについては別の記事に書くことにする。

【補助線】メンバーのスキルの低いチームをどう運営していくか

本ブログは移転しました。こちらをご覧ください。

チームをマネジメントするとはどういうこと？

の中で、僕自身、このテーマは後で書くといったことをすっかり忘れていた。コメントを貰って思い出した。ありがとうございました。

この話は本質的な解決というのはないと思っている。それは多くの人が感じていることだろう。ぼくが言いたいのは、パラダイム（ものの見方）を変えようということだ。

たまたま、昨日、「問題はなかったことにしよう」という記事を書いたが、実は、メンバーのスキルの問題もここから始まる。多くの人がプロジェクトには問題がないと思いたい。だから、スキルの低いメンバーなどいるはずはないし、いたとしてもそれは一時的なことであって、変わっていくと考えたい。こういう話になる。

このような問題を直面しないままにこの問題を考えてみても、解決策はおろか、問題への応急処置をして前に進んでいくことすら難しくなる。

まず、最初にすべきことは、それを問題としてみるのではなく、現実として認識することである。その人はそれだけのスキルかないと認め、スキルそのものを想定に近づけようとは思わないことだ。

つまり、想定している生産性で仕事が進むことなどありえないと考える。ここが受け入れられるかどうかが最大のポイント。そして、育成は別の問題だと考える。

これがパラダイム転換。

念のために言っておくが、想定納期ではできないとステークホルダに対して開き直れといっているわけではない。この現実を認めた瞬間に、想定納期は「ストレッチされた目標」になる。これをスキルの低い人に責任をおっかぶせるではなく、チームとして計画的に対処する方法を考える。これがマネジメント。

すると、仕事の進め方が変わってくる。ＰＭＢＯＫで、ＷＢＳとＯＢＳでフォーメーションを設計し、ＲＡＭで統制するという考え方はリソースの能力が均質で、スキルセットが揃っていることが前提になっている。ゆえに、スキルセットが揃っていなかったり、能力にでこぼこがあるとすれば、このようなスキームは使えない。

工数見積もり（生産性の調整）でカバーできると思う人がいると思うが、もし、できるならそれでＯＫ。パフォーマンスの違いは生産性で調整できても、スキルセットのギャップは調整できないケースが多いので、みんなが頭を悩ましている。

スキルの低い人がいることを前提として考えると、仕事の分解の際に仕事そのものにグレードをつける必要がある。例えば、スキルレベルをＡ、Ｂ、Ｃとすれば、生産性ではなく、仕事の内容で、Ａランクの仕事、Ｂランクの仕事、Ｃランクの仕事とする。

ＩＴであれば、テスト、コーディング、プログラム設計、システム設計といった業務セグメントの難易度ランクはすでにあり、この範囲ではスキルレベルを調整している（現実には人手不足でできていないとしても、そういう考え方になっている）。

ここでさらに、それぞれの仕事の中を分解して、グレードをつける。例えば、テストであれば、テストのロジック設計をする人、テストのドキュメントを書く人、実際のテストをする人、環境設定をする人といったグレーディングをする。そして、グレードにあった人を割り振っていく。スキルレベルが揃っていれば縦割りの分担をするが、それを横割りにして分担をする。

こういう風に仕事を分解すると、実は、技術的な意味での専門性が必要になるのは、各セグメントでトップ、あるいは、２番目くらいまでのグレードである。それ以下のグレードは、技術的な専門性よりも、ドキュメントを書けるとか、正確に仕事をできるとかいったコンピテンシーの方が重要である。

ということは、セグメントに横断的に人材を活用できる。これにより、Ｂランクや、Ｃランクの仕事の一部を経験しながら、いろいろな仕事を見ることができる。これがひとつ、育成的視点からは重要なところだ。単に技術を覚えさせるだけではなく、仕事をするというのがどういうことかについて多様な経験をする機会になる。

技術的なスキルについては、そのような仕事をしながら、アシスタント的な仕事をする中で覚えさせればよい。これを下手に、専門性などで担当を決めて、設計者の仕事は設計をすることであって、ドキュメントを作ったりすることではないなどとやっていると、ロクな人材が育たない。下積みとして、自分の仕事に関連することを全て経験するというのは、日本型経営の優れた点だと思うし、今後も維持し続けるべき点だと思う。

こういう工夫をしているプロジェクトは結構ある。うまく行っているところも多い。繰り替えになるが、日本の組織というのはかつてはこういうやり方をしていたのだ。それをもう一度、プロジェクトマネジメントの枠組みを使って、体系的に実行してみようという話だ。

【補助線】問題はなかったことにしよう

本ブログは移転しました。こちらをご覧ください。

毎日、ニュースや報道バラエティで年金問題をやっている。

自民党の議員や民主党の議員がいろいろと説明している。自民党は節操のない方針変更はともかくとして、一貫して、細かいことよりは「とにかく大丈夫だ、任せてくれ。民主党さん、不安をあおるのはやめてくれ」と一貫していっている。これに対して民主党はあくまでも論理的に整合しないと国民は納得しないだろうというスタンスを貫いている。

両政党の政治的に立脚するところの違いか、単なる選挙のためのスタンスかは分からないが、結果としてどちらの言い分が通るかは非常に興味深い。

確かに、民主党のいうように、倫理的に整理しないと納得しない層が一定の割合でいる。この問題の、もう一人のプレイヤーであるマスコミは、今のところ、ここにフォーカスして報道しているように見える。

しかし、問題をなかったことにしたいと思っている人たちがいることも間違いない。当事者であることが分かっていないわけではない。当然、年金制度が破綻すれば自分たちが困ることはよく理解している。しかし、どういう問題が起っているかを知りたくない。できれば知らないままで、丸く収まってくれれば、ありがたい。万一、税金の投入でもしないと収まらないとしても、仕方ないと思うことにしよう。こんなマインドの人は、きっと論理的に納得したい人に匹敵するくらいいると思う。

これを単に当事者意識がないと批判するのは短絡過ぎる。

「日本沈没」という小説があったが、その中で、日本列島が沈み始めたときに、何もしないで日本列島と一緒に沈んでいくことを選ぶ意見を持つ有識者たちがいるという話が出てきた。これも本質的に同じ話しだ。このようなことを書ききった小松左京の人間観は興味深い。

ちょっと前に、宮崎県の裏金発覚で、「知らなかったことにしてくれ」といった定年を控えた出先機関のトップがいた。どんなタイプの人か分からないので、なんともいえないが、ひょっとすると、このトップも自分からは間違っても言わないが、誰かがリークし、それが自分の身に降りかかってくるのは運命だと思うある種の潔さは持っているかもしれない。このマインドはおそらく日本人に染み付いているマインドだと思う。

別に、役所に限ったことではない。組織の中でもこんな話はいくらでもある。感覚であるが、民間企業の管理職の半分以上はこのタイプではないかと思う。

また、必ずしも、上の人間に限ったことではない。実は下の人間も「これは知らせるべきことではない、知りたくもないだろう」といった調子でこのマインドを持ち合わせている。日本組織のアカウンタビリティが低い背後には、この不思議な利害関係の一致があるのだ。

これは、ある企業でシニアマネジャー（部長）から聞いた話。プロジェクトマネジメントの導入ステップが進み、リスクマネジメントの導入をする段になって、リスク分析などいらないと本気で言い出した。いわく

「リスク分析などすると、自分が知らなかったではすまなくなる。リスクがあるのは分かっている。でも、それも含めて、プロマネに飲み込んで欲しい。プロマネの骨は拾うし、まあ、そうなると自分の骨もまた、上の人に拾ってもらうことになるだろう」

半分くらいはプロジェクトを失敗したところで個人的に責任追及されるはずがないと高をくくっていっているのは間違いないが、半分くらいは本音ではないかと思う。注目したいのは、この部長、社内でも結構切れ者で通っているらしいが、この発言からも分かるようにリスクマネジメントの本質を実に的確に理解していることだ。その上で、言っているのだ。

実際に、このマネジャーが主催するプロジェクトレビューのミーティングに参加したことがあるが、見事なものでこの本音を地でいっている。

通常のレビューミーティングはプロジェクトには少なからず問題があるという前提でやるが、このマネジャーは問題がないという前提でレビューミーティングをしている。

例えば、こんな感じだ。

スケジュールが遅れているとしよう。これ自体は誰がみても問題である。このマネジャーもこれを否定するわけではない。予実を目の前にして、これは遅れていないことにしようと言い出すわけではない。

ところが、彼の頭の中では、「プロジェクトには問題はない」と思っている（思いたい）ので、目の前の問題を潰すことに意識を集中する。

ここで、プロマネがひと言、本質を突いた原因を言えばいいのだが、上の利害関係一致の構図で、「どうも、見積もりが甘かったみたいです」と何の根拠のない原因を語った上で、「すみません。もう１人メンバーを追加してもらえないですか」と来る。

これで件のマネジャーの顔は立つ。喜んで（というか、渋い顔をしながら、内心ほっとして）プロジェクトにもう一人、リソースを工面する。

かくして、プロジェクトマネジャーとマネジャー（スポンサー）の見事な一致協力で、問題はなかったことになる。

もっといえば、多くの場合、そのプロジェクトで問題が再発する（笑）。そんなプロジェクトは、「問題対応も適切にしたし、君はよくやったよ。いい経験したね」とシニアマネジャーからプロマネへのひと言の振返りとともに終結する。

これですべてが丸く収まる。このシニアマネジャーはプロマネの人事考課者なのだ。

最初はよそ事だと思っていた人もここまでくれば、相当な確率で思い当たる部分があるのではないだろうか？

「問題をなかったことにしていないか」を一度、点検してみてほしい。

【補助線】プロマネ屋

本ブログは移転しています。こちらをご覧ください。

昨日のメルマガの編集後記に技術屋と技術者（エンジニア）の違いを書いた。

技術屋と技術者（エンジニア）の違いは、技術に対するスタンスの違いではなく、経
営に対するスタンスの違いです。

　技術屋は技術に貢献します
　技術者は事業に貢献します
　これはいずれも、最終的には経営に貢献します

技術畑ではない人は、業務という言葉で置き換えてください。開発、企画、マーケテ
ィング、総務、人事など、なんでも結構です。

というフレーズだ。数通、個人的なご意見を戴いたので、ブログで再度、コメントしておく。

メルマガでははっきり書かなかったのだが、この後記で書きたかったのは、技術者のことではなく、プロジェクトマネジャーに対すること。

最近、気になっているのがプロマネ屋というのができつつあるのではないかということだ。上の言い方をすれば、

　プロジェクトマネジャーは事業に貢献します
　プロマネ屋はプロジェクトマネジメントに貢献します

という感じである。ただし、プロマネ屋は経営には貢献しない。ここが問題。

もちろん、全面的に否定しているわけではない。いまだに、プロジェクトマネジメントというのものに興味を示さない人も多く、その人たちと較べるとプロジェクトマネジメントという点からは進化している人たちだ。ただ、一皮、むけて欲しいなと思っており、そういうニュアンスのコメントです。

このブログでは、何度か、「隠すというスタイル」について書いてきた。その中でも書いたが、プロジェクトの情報をプロジェクトスポンサーやその代理人であるＰＭＯにすべて開示すると、プロジェクトの進行に影響が出てくる。干渉されることもある。従って、隠すことは必要だという考えは一定の合理性があるようにも思える。

こういうプロジェクトマネジャーが「プロマネ屋」である。

昨日の編集後記に対して、技術屋では経営に貢献できないのではないかという意見を戴いた方がいる。これは微妙なところがあるが、僕自身は貢献できると思う。企業が持つ技術ポテンシャルを大きくすることは、かりにそれが戦略との整合性がないとしても貢献だと思う。それは技術というものの性格によるものであり、技術というのはお金（事業）や人材と同じくらい普遍的な資産であると思うし、現に、経営戦略と無関係に、企業の資産価値を高めているからだ。

要するに経営というのは、出資者から集めた資金、あるいは、その組織が持っている資源を活用して如何に収益を上げるかという活動であるが、その資源のひとつが技術であり、それゆえに技術屋は資源を増やすという意味で経営に貢献している。

ただし、これは原則的な議論であって、現実の経営ではここに評価期間の議論が絡んでくる。従って、最近の経営のように、顧客価値より、株主価値を重視して考え、四半期ごとに収益を重視するような戦略の中では、技術のようにキャッシュサイクルが長いものは低い評価をされる傾向がある。ただ、これも企業価値という議論においては、さほど、本質的な話しではない。企業価値の評価の中では、株主（ステークホルダ）の評価もされるからである。

さて前置きが長くなったが、問題のプロマネ屋。プロマネ屋は技術屋のように経営に貢献できない。プロマネ屋は、自らのプロジェクトの目標を達成するために全力を尽くす。それはいいのだが、アカウンタビリティを考えないのがプロマネ屋の特徴だ。

こうなってくると、プロマネ屋は百害あって一利なしだ。プロマネ屋というのはスタンスの問題である。だから、技術屋がプロジェクトマネジメントに「はまる」とプロマネ屋になる傾向があるようだ。

プロマネ屋のプロジェクトマネジメントスキルは高いことが多い。そのスキルをプロジェクトマネジャーとして活かすことで、どれだけ経営にとって貴重な存在になるか。プロマネ屋になっている人は、ぜひ、早くこのことに気がついてほしい。

もっと現実的に言えば、プロジェクトで業績を残した人が、ラインマネジャーとして出世できるかどうかはこの点にかかっているといっても過言ではない。まあ、これは別の議論だが。。。

最後に、ひとつ。僕は技術コンサルティングをやっていた時期に、マネジメントチームを作って、何度か、数億～数十億規模のＳＩプロジェクトの「雇われ」プロマネをやった経験がある。これは純然たるプロマネ屋仕事だ。要するに、自分の任されたプロジェクトが成功すればよいのだ。当然だが、組織の中に入り込み、人脈を使い、結構、えげつないリソースの取り込みとかをするし、ベンダーもその組織の付き合いとは関係なしに決める。当然だが、覚悟が要る。この覚悟ができるのであれば、プロマネ屋で生きていくというのもひとつの選択だとは思う。

当時、ある人に、プロジェクトマネジメントという刀一本で組織に切り込んでいくといわれたことがあるが、母体組織も含めて力で動かすしかないわけで、まあ、しんどい。ちなみに、５年くらいこういう仕事をしていた。プロジェクト予算の１０％程度で契約するので、それなりに儲かるが、それ以上続けようとはおもいませんでした。経験談。

【補助線】「正しいプロジェクト」とは何か

本ブログは移転しました。こちらをご覧ください。

重要なことは、正しいプロジェクトを正しく行うことだ。

このような認識が日々、強くなってきている。正しく行うというのはプロジェクトマネジメントをきちんとすることとイコールだと考えてよいだろう。では、正しいプロジェクトとは何か。

例えば、どう考えても無理なスケジュール目標（納期）を決めてしまえば、いくらプロジェクトマネジメントをきちんと実施してもプロジェクトは成功しないし、それはプロジェクトマネジメントの問題ではない。どう考えても赤字になるような金額で受注してくる場合も同じ話しだ。

つまり、プロジェクトの目的に対して、その目的を達成できる範囲で、実行可能な目標を設定したプロジェクトが正しいプロジェクトというわけである。

ちなみに、今までは、プロジェクトマネジメントがあまりきちんと行われておらず、プロジェクトの「正しくなさ」の責任もすべて現場（プロジェクトマネジメント）に転嫁されていたが、プロジェクトマネジメントの普及により、ここにきて、この転嫁ができなくなり、この問題を直視せざるを得なくなってきたという事情があることも忘れないでおきたい。

ところが、ちょっと考えてみると、この話は不可解な点があることがすぐに分かる。「なぜ、明らかに無理な納期を設定するのか」、「なぜ、最初からオーバーすると分かっているような予算を設定するのか」といった疑問が生じる。この理由はそんなに難しいものではない。

ＳＩプロジェクトだと例えばこうなる。

「戦略計画達成のためにはこのお客さんからの受注を取ることは必須だ。他にも２社、引き合いをしている。うちとしては、多少、納期もお客さんの準備している予算も厳しいが、提案せざるを得ない。外注を駆使して乗り切ろう」

商品開発プロジェクトだと例えばこうなる。

「戦略計画達成のためには、この商品はこの時期までに上市をせざるを得ない。これより遅れると競合商品が出てきて、売上げ目標が変わってしまう。まだ、未解決の技術問題があるが、それはなんとかお金で解決しよう」

これから分かるように、「正しいプロジェクトを行う」ためには、戦略計画を達成するためのアプローチが大問題になってくる。例えば、上のＳＩの例であれば、「このプロジェクトは諦めよう。その分のリソースを他に転用して利益を作ろう」と考えることが必要である。

言い換えると、戦略計画達成のためには、どのプロジェクトをやるかが大きな問題になってくる。ただし、ここに、単に戦略計画達成の視点以外の要素が入ってくる。つまり、正しくないものを正しくする方法がある。それは組織としての生産性をあげることである。あるいは、技術力をあげることである。

プロジェクトレベルの生産性の向上はチームマネジメントなどで取り組んでいくが、組織レベルの生産性の向上は戦略課題である。戦略計画の実行に併せて、この戦略課題の解決によって、「正しいプロジェクトを行うこと」と、「正しく行うこと」のバランスが取れてくる。

これをわれわれは、「正しいプロジェクトを正しく行う」に加えて、「正しい組み合わせをする」といっている。

正しい「組み合わせ」ができてはじめて、「正しいプロジェクト」を立ち上げていくことが可能なのだ。このためのマネジメントが必要である。これがポートフォリオで取り組んで行きたい部分である。これを積み上げだけでやっていると、プロジェクトの優先順位が考慮することができない。

結果として戦略計画が達成できればいいじゃないかと考える人もいるかもしれない。これは間違い。リスクに対する配慮が足らない。

また、ここで、戦略そのものが上げ底である可能性もあるので、注意を要する。例えば、引き合いのある仕事をすべてとっても達成できないような戦略計画を作るケースだ。まあ、これはそもそも戦略計画とはいえないが、売上げ絶対時代の名残で今でもこのような経営計画を作っている組織は少なくない。これは論外。収益率を高めて、人を育てることという視点からもう一度、戦略の見直しをすべきである。

【補助線】プロジェクトマネジャーとＭＢＡ

本ブログは移転しました。こちらをご覧ください。

プロジェクトマネジメントにどのような知識が必要かと聞くと多くの人は、

・プロジェクトマネジメントの知識
・業務（技術）の知識

の２つをあげる。最近では、さらに、ここに

・ヒューマンスキル（人間系）
・チームマネジメント

というをあげる人も増えてきた。

本当に、これだけでいいのだろうか？

これが問題提起だ。

結論を述べておこう。これだけでは足らない。いわゆるＭＢＡの知識が必要である。それはどのようなものか？

（１）経営戦略
（２）マーケティング
（３）コスト
（４）ファイナンス

の４つがその代表である。これらの知識がないとプロジェクトマネジャーは務まらない。

もっとも、プロジェクトマネジャーをどう位置づけるかという問題もある。プロジェクトマネジャーを工場長、つまり、現場マネジメントの責任者だと位置づけるのであれば、これらはそんなに重要でないかもしれない。しかし、ビジネスのマネジャー、すなわち、経営側のマネジャーだと位置づけるのであれば、ＭＢＡの知識は不可欠である。

実は多くの企業はこの問題に明確な答えを出していない。というよりも、この問題は考えないでおこうとしているように見える。

一方で、プロジェクトマネジャーのキャリアパスというのが問題になってきている。日本でこの問題を白昼にさらけ出したのは日経コンピュータだったと思う。ＩＢＭ社のキャリアパスで、プロジェクトマネジャーで突き抜ける、すなわち、役員まで昇進するキャリアパスがあるという記事を発表した。この辺りから、急にプロジェクトマネジャーのキャリアパスに関心が高まったように思う。

プロジェクトマネジャーが現場マネジャーでキャリアを終えるのであれば、それはそれで構わない。しかし、役員になる、つまり、経営側に入っていくとなると、経営の視点は不可欠なのはいうまでもない。やはり、ＭＢＡ的な視点が必要になってくる。

では、ＭＢＡ的視点とはどういうものか？上の４つについて、ひと言ずつ、以下に述べておく

（１）経営戦略
経営戦略の適切さが最大のプロジェクトの成功要因であることを理解する

（２）マーケティング
プロジェクト期間中、プロジェクトの成功のためにどのようなマーケティング活動が行われているかを理解する

（３）コスト
プロジェクト期間中のコストは重要であることはいうまでもないが、成果物のライフサイクルコストも同様に重要であることを理解する

（４）ファイナンス
プロジェクトが企業価値に貢献するためには何が重要であるかを理解する

といった視点を持てることが必要である。視点として書くと簡単そうにみえるが、これらはいずれもそれぞれの分野で本質的な問題である。

さらに、ＭＢＡという場合に欠かすことのできないのが、組織・人材マネジメントである。これについては、プロジェクトマネジメントプロセスの問題として定義でき、スケジューリングプロセスだけが重要なのではなく、組織行動プロセス（リーダーシップ、チームなど）の重要性をきちんと理解することが必要である。

さて、あなたはどのくらいＭＢＡ的だろうか？

【補助線】ＰＭＯモデル

本ブログは移転しました。こちらをご覧ください。

◆プロジェクトマネジメントオフィスの３つのモデル

プロジェクトマネジメントオフィスの役割にはどういったものがあるのだろうか？この議論は２つの視点からする必要がある。ひとつは、プロジェクトマネジメントに対して、どのようなスタンスをとるかという議論である。もうひとつは、どのような機能を果たすかである。今回、したいのは前者に対する議論である。

プロジェクトマネジメントオフィスのプロジェクトに対する関わり方は一般に、ＰＭＯモデルと呼 ばれれ、２種類、あるいは３種類ある。

◆ストロングモデル

ひとつは、ストロングモデルと呼ばれる強い関わり方である。ストリングモデルでは、組織のプロジェクトマネジメントの実行そのものにＰＭＯがコミットする。場合によっては、プロジェクトが行うプロジェクトマネジメントにコミットする場合もある。

一般にはストロングモデルのＰＭＯは、標準化や機能の導入以外に、バーチャルチームの形成、計画書のレビューや、プロジェクト監査、リカバリーマネジメントなどの形で、プロジェクトの外部からプロジェクトマネジメントを支援していくことが多い。

また、いわゆるプロジェクトオフィス機能としてプロジェクトマネジャーの行うプロジェクトマネジメントの一部を引き受けるケースもある。例えば、プロジェクトマネジメント計画書の作成、上位組織への報告書の作成、会議体の運営、ファシリティの手配などを行う。また、プロジェクトマネジャーに代わって、メンバーの教育・指導などをすることもある。

◆コンサルティングモデル

これに対して、コンサルティングモデルと呼ばれるモデルはプロジェクトマネジメントに対してあくまでもコンサルティング的な立場で接していく。自発的に何かサービスを提供するということより、あくまでもプロジェクトや組織から相談があったときに出動し、相談された問題を解決していくというスタンスだ。支援内容的にはストロングモデルと重複する部分も多い。例えば、計画書のレビューをしたり、監査を行ったり、リカバリーを行う場合もあり、スタンスの違いだと考える方が分かりやすい。

ストロングモデルと異なるところは、自らが計画を作ったり、あるいはリカバリーに入ったり、あるいは、プロジェクトマネジメントをしたりということはない点である。

ＰＭＯの戦略の中でもっとも重要な部分はこのどちらのスタンスをとるかであり、これによって、ＰＭＯの性格も変わるし、必要なリソースも大きく変わってくる。

◆ブレンドモデル

ストロングモデルとコンサルティングモデルの折衷で、ブレンドモデルというスタンスの取り方もある。これは、例えば、プロジェクトトラッキングとリカバリーについてのみ、ストロングモデルを採用し、それ以外の部分ではコンサルティングモデルを採用するというようなものだ。

ＰＭＯとしては、もっとも力量が必要になるのが、ブレンドモデルであろう。

このようなスタンス（タイプ）分類でキーになっているのは、前回述べたプロジェクトマネジメントのオーナーシップである。ストロングモデルは基本的にはオーナーシップを持とうとするスタイルであり、コンサルティングモデルはオーナーシップを持たないスタイルである。どちらを選ぶかというのはプロジェクトマネジメントの成熟度によっても変わってくるし、また、企業の姿勢によっても変わってくるだろう。

プロジェクトマネジメントに人間的要素を強く求める企業はコンサルティングモデルを採用し、オーナーシップを重視しない傾向がある。プロセスや標準を重視する企業は、オーナーシップを重視し、ストロングモデルを採用する傾向がある。

特に、企業の姿勢の中で、押さえるポイントだけは押さえたというのがブレンドモデルということになる。日本企業では、ブレンドモデルが多いようである。

【補助線】プロジェクトをチャーターする

本ブログは移転しました。こちらをご覧ください。

昨日は、第１回のPMstyleプライベートセミナーを開催した。好川と峯本さんがスピーカーを務め、

　「世界の標準に見るプロジェクトのマネジメントの方向性」

というテーマで行った。このセミナーは今までにPMstyleのセミナーにきていただいた方への感謝の意味を含めて、限定的に行うセミナー。当然、メルマガなどでは告知していないので、このブログの読者でもセミナーページを見られていない方もおおいだろう。

【第１回　PMstyle Private Seminar】世界の標準に見るプロジェクトマネジメントの方向性

久しぶりにメルマガの開始当時にやっていたみんなが参加するフロアディスカッションをやった。面白かったが、その話題になったのが、Integrity（インテグリティ）。

峯本さんの話に誘発されて、フロアから、プロフェッショナルにインテグリティが必要なのは分かるが、現実にそれはどう実現するのかという質問が口火になったのだ。

僕は、持論である、日本語のボキャブラリがないものを標準として導入するのは、文化を創るに等しい仕事だという立場で意見を述べたが、実はこれを一番感じているのが、チャーターである。

名詞　charter　はコウビルド英英では以下のように説明されている

A charter is a formal document describing the rights, aims, or principles of an organization or group of people.

一方で、charter に当てられる日本語「憲章」を広辞苑で引くと

重要なおきて。原則的なおきて。

と説明されている。おきてとは何かも書いていないし、重要とは何かも書いていない。

ＰＭＢＯＫでプロジェクト憲章というツールにはじめて出会うと、「プロジェクト憲章には何を書いたらいいのだろう」という疑問を持ち、説明を読んで、「ああ、そういうものか」と納得する。

ＰＭＢＯＫに書かれていることはあたかも、ＰＭＢＯＫで決められているように思えるが、実はこれはプロジェクトチャーターというツールというレベルで決まっているというよりも、文化、「しきたり」が charter という言霊になっているような話である。

charter　という動詞は、例えば、飛行機をチャーターするとかいう使われ方をする。これは、「やとう」、「特権を許す」という意味である。権限委譲よりももっと強いイメージだ。

ついでにいえば、charter　という動詞には、「許可する」という意味があり、許可書を発行するという意味でもある。つまり、 charter というのは許可書なのである。英語では、project chartering　という言葉がある。プロジェクトをチャーターするのである。チャーターするためには、rights, aims, or principles of an organization をはっきりしておく必要がある。明快である。

言葉からこんなことを考えてみると、なんとなく、プロジェクトというのが組織にとってどんな位置づけのものか、感じることができるのではないだろうか？

ところが、プロジェクトチャーターをプロジェクト憲章とした瞬間に、このような言葉を構成する世界はすべて消えてしまう。だいたい、この憲章って誰が作るのかといった議論すら怪しくなっている。日本にスポンサーシップが根付かないのはこのためではないかと思っている。

マネジメントには、こういう例がたくさんある。例えば、昨日のセミナーで峯本さんが紹介したレスポンシビリティ（resopnsibility）。責任概念にはレスポンシビリティとアカウンタビリティがあるが、これは、いずれも「責任」である。言葉がないのだから、この区別をしろというのは無理な話だ。レスポンシビリティという概念がないので、コミットメントという概念もできない。

アカウンタビリティもレスポンシビリティもコミットメントもないところで、マネジメントを実行しようと思えば、プロセスにするしかない。これが、日本人にＰＭコンピテンシーがなかなか理解されない理由であろう。

しかし、このような壁を乗り越えて、コンピテンシーを身に付けていかない限り、本当の意味で日本人がプロジェクトマネジメントを実行する日はやってこないだろう。

壁を乗り越えずに、日本は日本のやり方で、米国のやり方とインタフェースをとっていくという方法もある。欧州ＰＭ協会のＩＣＢなどがやっている方法だ。

トヨタが米国文化の象徴のひとつともいえる自動車で世界一の企業になった。単に世界一になっただけでも凄いが、もっと凄いのは自分たちのマネジメントのやり方を世界中に普及して現地生産拠点を増やし、世界一になった。これは素晴らしいことだ。

なんどかＴＶでその方法をみたが、非常に地道なトレーニングをしている。インストラクタ（トヨタウェイのエバンジェリスト）が公私につき、模擬のラインを作ってスキルアップを図ると同時に、その考え方を丁寧に教えていく。「私」の部分でも、「トヨタマン」としての振舞い方を教える。まさに、人材育成の部分でもコツコツとやって、今の状況を作った。

こういうやり方もある。

【補助線】ＣＰＭＯとプロジェクトマネジメントのオーナーシップ

本ブログは移転しました。こちらをご覧ください。

◆はじめに

ゴールデンウィークで少し間があいたが、前回のコラムでは、ＰＭＯのマネジメントについて、最低限でも

（１）ＰＭＯ活動の成果の定義と測定
（２）ＰＭＯの戦略と役割の見直し
（３）ＰＭＯの機能の評価と見直し
（４）ＰＭＯスタッフのローテーションと育成

の４つは実施する必要があることを述べ、（１）のＰＭＯ活動の成果の定義と測定について説明した。今回から（２）について説明する。その前に、前回の記事について「ＰＭＯはひとつしかおかないのか？弊社では、プロジェクトの中にもあるし、事業部にもある。会社としてのＰＭＯもある」という質問を戴いたので、これに回答しておきたい。

◆ＰＭＯの種類

ＰＭＯといっているものにはいろいろなものがある。例えば、米国では以下のような分類が一般的である。

（１）CPMO（Corporate Project/Program Management Office）
　あとで説明する
（２）PMO（Project Management Office）
CPMOによって確立されたプロジェクトのマネジメントの標準の適用による効果を見ながら、事業部、BU、リージョンなどの範囲で、戦術的なマスタープランに対する責任を持つ
（３）PSO（Project Support Office）
CPMOによって確立されたプロジェクトマネジメントの標準の監視をし、オペレーショナルなマスタープランに対する責任を持つ
（４）PO（Project Office）
ミッションクリティカルなプロジェクト、大規模＆複雑なプロジェクトの直接的な支援を行う責任を持つ

これらは、ひとつの組織の中に共存する。

◆ＣＰＭＯの役割

この中で、注目すべきなのは、ＣＰＭＯである。日本でもエンタープライズＰＭＯとか、コーポレートＰＭＯといった位置づけのＰＭＯがある企業は少なくないが、ＣＰＭＯというのは

全社のビジネス機能の一つに位置づけられる。財務、マーケティング、営業、エンジニアリング、製造などと同様に、プロジェクトマネジメントに対するオーナーシップを持ち、プロジェクトのマネジメントのベストプラクティスを全社に展開することを目的とする組織

をいう。つまり、プロジェクトマネジメントというのは組織機能の一つである。メルマガの記事に何回か書いたように、最近、「正しいプロジェクトを正しく行う」ということに関心が高まってきている。しかし、実は、これだけでは不十分である。

「正しいプロジェクトを行う」ことと、「正しく行う」ことは組織の中では自動的には結びつかないことが多い。例えば、正しいプロジェクトを正しく行うためには、組織がプロジェクトをやる意味が十分にプロジェクトに伝わり、反映される必要がある。プロジェクトマネジメントにはプロジェクト憲章というツールがあるが、これだけでそのプロジェクトを実施する組織としての意味が十分に伝わるものではない。この部分は人間系（組織）の課題になる。

◆「正しいプロジェクトを正しく行う」ためにはＣＰＭＯが必要

つまり、「正しいプロジェクトを正しく行う」ためには、「正しいプロジェクトを行う」ことと、「正しく行う」ことをコンバインする必要があるのだ。これはシニアマネジャーの役割であるが、シニアマネジャーが個別にやるには横通しの問題からおのずと限界がある。

そこで、プロジェクトマネジメントのオーナーシップという話が出てくる。プロジェクトマネジメントのポリシーを明確に定め、そのポリシーに従って、シニアマネジャーがうまくプロジェクト選定とプロジェクトマネジメント実行を結びつけてやるのだ。このようなオーナーシップを持つためには、ＰＭＯを戦略組織とし、「ＣＰＯ（Cheif Project Management Officer）」とでもいう役職を設置する必要がある。

最後にひとつ、日本の企業のＣＰＭＯの特徴に触れておく。日本の企業では、ＣＰＭＯがプロジェクトマネジメントに対するオーナーシップをもてないケースが多い。ぜひ、考えてみて欲しい。仮に、あなたのＰＭＯが全社標準を作っているとすれば、以下の３点をチェックしてみて欲しい。

【簡易診断】

（１）全社のプロジェクトマネジメントポリシーを作っている
（２）標準の運用で、プロジェクトスケジュールを無視して、計画書の書き直しを命じることができる
（３）プロジェクトマネジャー以外の部門のプロジェクトマネジメントに対する責任を明確にしている