コンセプチュアル・マネジメント

◆はじめに

この戦略ノートは、

【戦略ノート269】「センス」について考える

の続編です。

 

◆正しい努力

日本人は、努力することをよいことだと考える。このこと自体は、間違っていないと思う。しかし、前提がある。それは、正しい努力であればという前提である。

では、正しいかどうかをどのようにして判断すればよいのだろうか？それは、相手、あるいは周囲の期待に応えるために意味のある努力であるかどうかだと思う。同時に、自分自身が期待に応える価値があると考えていることが必要である。この両方が揃って、初めて正しい努力であるといえる。

◆チームとグループは違う

マッキンゼーのコンサルタントで、チームマネジメントの世界的な権威であるジョン・カッツェンバックは、２０年前にチームとグループは違うと指摘した。

概念的な言い方だが、１＋１が２以下であるのがグループで、１＋１が２以上になるのがチームだという。たとえば、５人の人が集まったときに３～４人分の仕事しかできないのがチームで、７～８人分以上の仕事ができるのがチームだという意味だ。

◆変わるプロジェクトの成功の定義

この１０年間くらいの間に、プロジェクトの成功の定義が変わってきた。改めていうまでもないが、プロジェクトは上位組織から与えられたＱＣＤの制約の中で、求められる成果物を実現する活動であり、これがきればプロジェクトは成功したと言える。このため、プロジェクトマネジメントはＱＣＤの制約をクリアしながら、定めたスコープを実現すべく、プロジェクトを進めていく活動として位置付けられる。

ところが、最近ではＱＣＤの制約をクリアできればプロジェクトは成功したとは考えられなくなってきた。成果物が生み出す価値が問題にされるようになってきた。

この背景にはプロジェクトを取り巻く環境はプロジェクト期間中は変わらないという前提がある。たとえば、ある商品を開発するのに、競合の動向や、技術動向、ビジネスの動向などは基本的にその期間は変わらない。つまり、プロジェクトを開始する時点と、製品の開発が終了した時点で変わらない。したがって、計画を立ててしまえば、その計画通りにプロジェクトを進めれば価値は保証されるという前提が成り立たなくなっていることがある（実際にその商品が売れるかどうかは別の問題である。価値とはその商品が持つポテンシャルである）。

ところが、現実にはそうはいかなくなってきた。開発リードタイムの間に市場に状況がガラッと変わってしまうようなケースは珍しくなくなった。

◆常盤文克氏の指摘

花王を成長させた経営者として有名な常盤文克氏が「新・日本的経営を考える」（日本能率協会マネジメントセンター、2012）で以下のような指摘をしている。

売り手と買い手はそもそも分離できない。お客がいて初めて企業が成り立ち、企業があって初めてお客の生活（活動）が成り立つ。にも関わらず、お客と企業は別々の存在であって、対極に置いていることが多い。顧客満足というのは特別な活動ではなく、企業活動そのものなので、こんなやり方では実現できない。

アジャイル、デザイン思考のように顧客との協働を価値感とした手法が増えてきている。しかし、なかなか、うまく行かない。そこに、常盤氏が指摘している問題が横たわっていることが多い。

◆顧客価値を実現するのが難しい理由

顧客価値を実現するのは、難しい。理由は２つある。一つは顧客自身が自分の求めている価値を必ずしも明確にできていないこと。もう一つは、顧客においては価値は明確になっていたとしても、それをプロジェクトの価値にうまく変換できないこと。

もう少し、詳しく説明しておこう。

顧客価値のベースになるのは、顧客のニーズ、あるいは要求である。そこで、価値を実現するために、顧客の要求を明確にし、その要求を実現していくのが一般的なアプローチである。プロジェクトの成果物が顧客価値になるのは、要求が正しく把握できたという前提での話しであり、現実にはで難しい。そのため、プロジェクトの生産物は、顧客にとって期待通りの価値を持たないことが少なくない。

もう一つの問題は、メトリクスの問題である。プロジェクトマネジメントにはアーンドバリューという考え方があるように、基本的にはプロジェクトの進捗は生産量からマッピングされるメトリクスを使って測ることが多い。アジャイル開発などで、機能の実現を進捗としてとっても同じことである。

つまり、これらのメトリクスは、顧客価値とプロジェクトで生産された価値がうまくマッピングされていることを前提としているわけだが、現実はそんなに単純ではない。顧客価値にはプライオリティがあるので、生産の価値はプライオリティを反映したものである必要がある。

顧客価値を実現するには、この２つの問題を乗り越えていかなくてはならない。

◆プロジェクトガバナンス

プロジェクトマネジメントは、ドキュメントが多くて、手間だと思っている人は多い。確かに、ＰＭＢＯＫ（Ｒ）を見ると、プロセスの中に出てくるドキュメントは実に多種多様である。全部を作成しなくてはならないわけではないと言われても、じゃあ、何が必要で、何が不要なのかをどう判断するのかという話になる。

そのように考える前に、どもども、プロジェクトというのは、組織的にどういう業務プロセスかを考えてみるといい。

プロジェクトの成り立ちは、例外はあっても、

（１）経営層がプロジェクトを行うことを決める
（２）経営層が組織にプロジェクトの実施を指示する（以下、上位組織）
（３）上位組織がプロジェクトを構想し、経営層の了解を取る
（４）了解が取れたら、プロジェクトマネジャーにプロジェクト遂行の指示をする
（５）プロジェクトマネジャーは、プロジェクト遂行の計画を作り、上位組織の了解を取る
（６）了解が取れたら、その計画を展開し、プロジェクトを実施する

というガバナンスになっている（業務プロセスとしては、権限委譲が入っているので、もう少し、単純である）。

◆牙を抜かれたプロジェクトマネジメント

プロジェクトマネジメントが本格的に認知されるようになって１０年余りになる。日本では、この間、ＩＴベンダーを中心に、受注プロジェクトという定常業務への適用を中心に発展してきたため、ある意味で牙を抜かれたような状態になっている。

プロジェクトマネジメントは本来、プロジェクトを実施する目的を実現するために行うものである。目的の実現には度合いがある。たとえば、ブランドの認知を目的だとすると、商品に関心を持つ市場でのブランドの認知なのか、商品に関心を持たない人もいる市場での認知なのかによって、話がずいぶん変わってくる。このコントロールは、目的に対する目標の設定で行う。この例であれば、認知率のようなものでコントロールできる。

そして、この度合の設定はプロジェクトに任されている（上位組織は承認をする）。このためか、プロジェクトマネジメントが「進化」するにしたがって、リスクマネジメントの威を借りて、目標設定が低くなっている。

プロジェクトマネジメントは本来、目標を少しでも高く設定するために行うものだ。できることをできるようにやればよいのであれば、プロジェクトマネジメントは要らない。よく引き合いに出されるのは、ピラミッドの建立のプロジェクトである。巨大な構造物であるが、民というリソースがふんだんにあり、できるときにできればよいのであれば、技術さえあればできる。逆にいえば、これが、技術が重視される理由でもある。

◆優先順位はつけれない！？

一つのプロジェクトの中で、スコープや機能、品質、コスト、スケジュールの優先順位をつけることはできるが、２つのプロジェクトの間でどちらのプロジェクトを優先するかは、順位をつけることができない。

このような主張をする人が多いが、マネジメントの本質ともいえる優先順位問題について、優先順位問題について考えてみたい。

まず、上の主張をもう少し、考えてみる。

◆プロジェクト成果の質を上げる

プロジェクトの成果について、よく言われる法則がある。それは、

プロジェクトの成果の質は最終的な意思決定者が関わる程度に比例する

という法則である。多くの人が共感している法則だ。

ここでいう最終的な意思決定者とは誰だろう。真っ先に思いつくのは、経営トップであるが、経営トップだけだとは限らない。意思決定の権限を持つ管理者、いわゆるプロジェクトスポンサーはすべて該当する。むしろ、現実的にはプロジェクトスポンサーであることが現実的である。

サントリーで、情報システム部長、事業企画部長、工場長、商品開発研究所長、事業
本部長を歴任され、役員にまでなられた、橋本忠夫さんは、

プロジェクトスポンサーが誰かわからないプロジェクトは失敗の確率が高い

と言われているが、この指摘も同じ指摘だと考えることができる。プロジェクトスポンサーが明確でないということは、最終的な意思決定者が経営トップであることになる。このようなプロジェクトは失敗する。

◆２つの要求

スコープにプロダクトスコープとプロジェクトスコープがあるように、要求にもプロダクト要求とプロジェクト要求がある。要求＝顧客（ユーザ）要求だと考えていると、ちょっと違和感があるかもしれないので、少し、ＩＴの受注プロジェクトを例にとって商流の整理をしておこう。

ＩＴのプロジェクトではＲＦＰによって、顧客が調達をする際の要求が提示される。ＲＦＰではもっぱらプロダクト要求（技術要件）が注目されるが、技術要件以外にも、マネジメント要件が示されるのが一般的である。これらの顧客要求に対して、ベンダーは企業として提案をする。