本ブログは移転しました。こちらをご覧ください
◆常盤文克氏の指摘
花王を成長させた経営者として有名な常盤文克氏が「新・日本的経営を考える」（日本能率協会マネジメントセンター、2012）で以下のような指摘をしている。
売り手と買い手はそもそも分離できない。お客がいて初めて企業が成り立ち、企業があって初めてお客の生活（活動）が成り立つ。にも関わらず、お客と企業は別々の存在であって、対極に置いていることが多い。顧客満足というのは特別な活動ではなく、企業活動そのものなので、こんなやり方では実現できない。
アジャイル、デザイン思考のように顧客との協働を価値感とした手法が増えてきている。しかし、なかなか、うまく行かない。そこに、常盤氏が指摘している問題が横たわっていることが多い。
本ブログは移転しました。こちらをご覧ください
◆顧客価値を実現するのが難しい理由
顧客価値を実現するのは、難しい。理由は２つある。一つは顧客自身が自分の求めている価値を必ずしも明確にできていないこと。もう一つは、顧客においては価値は明確になっていたとしても、それをプロジェクトの価値にうまく変換できないこと。
もう少し、詳しく説明しておこう。
顧客価値のベースになるのは、顧客のニーズ、あるいは要求である。そこで、価値を実現するために、顧客の要求を明確にし、その要求を実現していくのが一般的なアプローチである。プロジェクトの成果物が顧客価値になるのは、要求が正しく把握できたという前提での話しであり、現実にはで難しい。そのため、プロジェクトの生産物は、顧客にとって期待通りの価値を持たないことが少なくない。
もう一つの問題は、メトリクスの問題である。プロジェクトマネジメントにはアーンドバリューという考え方があるように、基本的にはプロジェクトの進捗は生産量からマッピングされるメトリクスを使って測ることが多い。アジャイル開発などで、機能の実現を進捗としてとっても同じことである。
つまり、これらのメトリクスは、顧客価値とプロジェクトで生産された価値がうまくマッピングされていることを前提としているわけだが、現実はそんなに単純ではない。顧客価値にはプライオリティがあるので、生産の価値はプライオリティを反映したものである必要がある。
顧客価値を実現するには、この２つの問題を乗り越えていかなくてはならない。
本ブログは移転しました。こちらをご覧ください
◆プロジェクトガバナンス
プロジェクトマネジメントは、ドキュメントが多くて、手間だと思っている人は多い。確かに、ＰＭＢＯＫ（Ｒ）を見ると、プロセスの中に出てくるドキュメントは実に多種多様である。全部を作成しなくてはならないわけではないと言われても、じゃあ、何が必要で、何が不要なのかをどう判断するのかという話になる。
そのように考える前に、どもども、プロジェクトというのは、組織的にどういう業務プロセスかを考えてみるといい。
プロジェクトの成り立ちは、例外はあっても、
（１）経営層がプロジェクトを行うことを決める
（２）経営層が組織にプロジェクトの実施を指示する（以下、上位組織）
（３）上位組織がプロジェクトを構想し、経営層の了解を取る
（４）了解が取れたら、プロジェクトマネジャーにプロジェクト遂行の指示をする
（５）プロジェクトマネジャーは、プロジェクト遂行の計画を作り、上位組織の了解を取る
（６）了解が取れたら、その計画を展開し、プロジェクトを実施する
というガバナンスになっている（業務プロセスとしては、権限委譲が入っているので、もう少し、単純である）。
本ブログは移転しました。こちらをご覧ください
◆牙を抜かれたプロジェクトマネジメント
プロジェクトマネジメントが本格的に認知されるようになって１０年余りになる。日本では、この間、ＩＴベンダーを中心に、受注プロジェクトという定常業務への適用を中心に発展してきたため、ある意味で牙を抜かれたような状態になっている。
プロジェクトマネジメントは本来、プロジェクトを実施する目的を実現するために行うものである。目的の実現には度合いがある。たとえば、ブランドの認知を目的だとすると、商品に関心を持つ市場でのブランドの認知なのか、商品に関心を持たない人もいる市場での認知なのかによって、話がずいぶん変わってくる。このコントロールは、目的に対する目標の設定で行う。この例であれば、認知率のようなものでコントロールできる。
そして、この度合の設定はプロジェクトに任されている（上位組織は承認をする）。このためか、プロジェクトマネジメントが「進化」するにしたがって、リスクマネジメントの威を借りて、目標設定が低くなっている。
プロジェクトマネジメントは本来、目標を少しでも高く設定するために行うものだ。できることをできるようにやればよいのであれば、プロジェクトマネジメントは要らない。よく引き合いに出されるのは、ピラミッドの建立のプロジェクトである。巨大な構造物であるが、民というリソースがふんだんにあり、できるときにできればよいのであれば、技術さえあればできる。逆にいえば、これが、技術が重視される理由でもある。
本ブログは移転しました。こちらをご覧ください
◆優先順位はつけれない！？
一つのプロジェクトの中で、スコープや機能、品質、コスト、スケジュールの優先順位をつけることはできるが、２つのプロジェクトの間でどちらのプロジェクトを優先するかは、順位をつけることができない。
このような主張をする人が多いが、マネジメントの本質ともいえる優先順位問題について、優先順位問題について考えてみたい。
まず、上の主張をもう少し、考えてみる。
本ブログは移転しました。こちらをご覧ください
◆プロジェクト成果の質を上げる
プロジェクトの成果について、よく言われる法則がある。それは、
プロジェクトの成果の質は最終的な意思決定者が関わる程度に比例する
という法則である。多くの人が共感している法則だ。
ここでいう最終的な意思決定者とは誰だろう。真っ先に思いつくのは、経営トップであるが、経営トップだけだとは限らない。意思決定の権限を持つ管理者、いわゆるプロジェクトスポンサーはすべて該当する。むしろ、現実的にはプロジェクトスポンサーであることが現実的である。
サントリーで、情報システム部長、事業企画部長、工場長、商品開発研究所長、事業
本部長を歴任され、役員にまでなられた、橋本忠夫さんは、
プロジェクトスポンサーが誰かわからないプロジェクトは失敗の確率が高い
と言われているが、この指摘も同じ指摘だと考えることができる。プロジェクトスポンサーが明確でないということは、最終的な意思決定者が経営トップであることになる。このようなプロジェクトは失敗する。
本ブログは移転しました。こちらをご覧ください
◆２つの要求
スコープにプロダクトスコープとプロジェクトスコープがあるように、要求にもプロダクト要求とプロジェクト要求がある。要求＝顧客（ユーザ）要求だと考えていると、ちょっと違和感があるかもしれないので、少し、ＩＴの受注プロジェクトを例にとって商流の整理をしておこう。
ＩＴのプロジェクトではＲＦＰによって、顧客が調達をする際の要求が提示される。ＲＦＰではもっぱらプロダクト要求（技術要件）が注目されるが、技術要件以外にも、マネジメント要件が示されるのが一般的である。これらの顧客要求に対して、ベンダーは企業として提案をする。
本ブログは移転しました。こちらをご覧ください
◆システムの一部だけを変えることはできない
かつて、プロジェクトマネジャーの育成をするときに、上位管理者をどうするかということがしばしば、話題になった。プロジェクトマネジャーが一生懸命、新しいやり方を学び、業務の中で実践しようとしても、上位管理者が足を引っ張ることが多い。たとえば、プロジェクト計画書を時間をかけて作成していると、「そんな時間があれば早く着手しろ」と平気で言い切る上位管理者はいまでも少なくない。
この問題は厄介である。次世代のリーダーの育成方法に関して、「ハイ・フライヤー」という本を書いた、南カリフォルニア大学マーシャルビジネススクールのフレーズはモーガン・マッコール博士は
組織というものはひとつのシステムであり、他の部分への影響を及ぼすことなく、システムの一部だけを変えることはできない。ある人が変化を試みているにもかかわらず、属しているシステムが同じ状態であった場合には、その人はジレンマに陥ってしまう。
と指摘しているが、まさに、プロジェクトマネジメントのトレーニングを受け、行動を変えようとした人は、ジレンマに陥っていた。PMstyleでは、半年～１年かけて行うアクションラーニングによる行動変革を求めるトレーニングをやっているため、この問題にいやというほど直面した。
本ブログは移転しました。こちらをご覧ください
◆人ベースと仕事ベース
慶応ビジネススクールの高木晴夫先生が「「人ベース／仕事ベースのアークテクチャーにおける組織学習装置」という研究をされている。最近、この研究成果が書籍になって出版された。この本だ。
高木 晴夫「組織能力のハイブリッド戦略」、ダイヤモンド社（2012）
この本はグローバルな経営環境の中で生き延びていくために、人ベースと仕事ベースをどのように組み合わせていけばよいかを、１６３社の調査に基づいて考察したものである。
高木先生によると、経営組織の仕組みは、仕事ベースと人ベースに分けることができる。仕事ベースは、まず仕事があり、その仕事をするために人を採用する。人ベースは、まず人があり、その人が仕事をとってきて実施していく。分業が進むと仕事ベースになっていくわけだが、日本の組織は人ベースのままで仕事をしている企業が多い。
今回の戦略ノートは、この問題をプロジェクトマネジメントの問題として考えてみたい。ちなみに、今回、初めての試みとして、このネタをメルマガのオンラインコミュニティ「プロジェクトの補助線」に投げ、意見を戴いた。その上で、記事を書いた。
本ブログは移転しました。こちらをご覧ください
◆プロジェクトの主体者は誰か
ＰＭＢＯＫ（Ｒ）はステークホルダーという考え方に特徴がある。一言でいえば、プロジェクト活動に対して、利害関係者はすべてステークホルダーという考え方である。プロジェクトスポンサーや、プロジェクトマネジャーやチームメンバーもすべてステークホルダーである。
ここで、利害関係とはそのプロジェクトを実施すること、あるいは、そのプロジェクトを実施した結果として生じる状態が特定の人にどのような影響を与えるかである。影響は業績に関わるものもあれば、個人のキャリアに関わるものもある。そのほかにもいろいろとあるだろう。
企業のステークホルダーという場合、経営活動の主体者たる経営陣はステークホルダーだとは考えない。あくまでも経営活動に対する利害関係者として、株主、消費者(顧客)、従業員、得意先、地域社会などが挙げられる。
両者を比較すると、一つ、疑問が浮かんでくる。それは、
プロジェクト活動の主体者は誰か
という疑問である。プロジェクトスポンサーなのか、プロジェクトマネジャーなのか、プロジェクトチームなのか。活動を中心に考えると、活動の主体者（活動の意思決定者）がステークホルダになることは本来の意味と反するので、少なくともステークホルダに名を連ねる人たちではないはずだ。
最近のコメント