【ＰＭスタイル考】第25話：ドラッカースタイル～計画編
◆ドラッカーの思考体系
今回は、ドラッカー思考の体系をプロジェクトマネジメントに適用する際の７つの視点
１．成果を上げる（成果を大きくするドラッカー思考）
２．価値をもたらす計画をたてる（戦略と計画に関するドラッカー思考）
３．顧客を中心に考える（顧客に関するドラッカー思考）
４．チームを動かす（チームのパフォーマンスを高めるドラッカー思考）
５．マネジメントを極める（プロジェクト品質を向上させるドラッカー思考）
６．イノベーションを実現する（技術を有効に活用するためのドラッカー思考）
７．プロフェッショナルになる（自己成長のためのドラッカー思考）
の２番目、「価値をもたらす計画をたてる」について考える。
◆計画とは
計画とは目標とその目標の達成手段である。
プロジェクトの計画の策定が難しいのは、「適切」な目標を設定することが難しいためである。たとえば、スコープとスケジュールとコストの目標をバランスよく設定するのは至難の業であると同時に、プロジェクトマネジャーの力量が力量を発揮できる局面でもある。しかし、残念ながら多くの組織では「制約条件」という形で「目標」を与えており、プロジェクトマネジャーが目標設定において力量を発揮することは少ない。
このような風潮は一考の余地がある。制約条件は最低の制約条件であって、より上位（経営上）の制約や顧客からの制約に対してぎりぎりの条件である必要はない。むしろ、そのような制約条件がプロジェクトに与えられているとすれば、プロジェクトスポンサー失格の烙印を押されてもおかしくない。
◆くすぶる丸投げ論
プロジェクトマネジメントのブーム以来、ずっと、「丸投げ」論がくすぶっている。プロジェクトマネジャーが丸投げしていると思っているのはいうまでもなく、プロジェクトスポンサーである。ところが、プロジェクトマネジャーの丸投げ論も焦点がずれている。多くの人が不満に思っているのは要員の調達とか、顧客や社内ステークホルダとの調整といったオペレーションにかかわることである。この部分は、プロジェクトスポンサーが権限を持っている場合にプロジェクトスポンサーと交渉することも含めて、プロジェクトマネジャーがほぼ全面的に責任を負うべき部分である。百歩譲って、これらのオペレーションに対してプロジェクトマネジャーに権限を委譲されていないことは認めるとしても、権限なしになんとかすることがプロジェクトマネジャーに課せられている責務である。
一方で、丸投げになっていると思う部分が上で指摘したように目標である。プロジェクトの目標は制約条件を考慮して、プロジェクトマネジャーが設定することを逆手にとって、制約条件で目標を与えている。これこそが丸投げである。
◆品質が価値だという。だが、この答えはほとんど間違いである。
では、なぜ、プロジェクトスポンサーは目標の丸投げをするのか。価値に対する理解がないためである。ドラッカーは価値についてこう述べている。
品質が価値だという。だが、この答えはほとんど間違いである。顧客は製品を買っているのではない。買っているのは、欲求の充足である。彼らにとっての価値である。何を価値とするかは、顧客だけが答えられる複雑な問題である。（ドラッカー 365の金言）
前回の顧客編でも価値に関するドラッカーの指摘を紹介したが、プロジェクトスポンサーが丸投げをするのは、まさにドラッカーの指摘する間違いを犯しているからである。
なぜ、このような間違いを犯すのか。実は、目標設定以外にもプロジェクトスポンサーが丸投げしているものがある。ドラッカーの言葉を借りていえば
（顧客の価値は）推察してはならない。顧客のところへ出かけて行き、聞かなければ
ならない。（ドラッカー 365の金言）
ということに尽きる。内向きで、市場データや情報システムの導入部門の顧客の声に関心を持つことはあっても、商品や情報システムを使うユーザには関心がない。市場や情報システム部門からの情報に基づき推察する。そのため、顧客が求める価値を正確に把握することができない。この誤りを「動かないコンピューター」と言った人がいる。日経コンピュータの記者だった谷島宣之氏である。谷島氏はその後、日経BizTechでも製造業を中心にこの問題を掘り下げている。
◆答えより問い
話が脱線気味になってきたが、顧客の価値をうまく読み取れない背景、つまり、プロジェクトスポンサーが顧客のところに出て行かない理由はなんだろうか？この点について、ドラッカーは非常におもしろいことを言っている。
戦略的な意志決定では、範囲、複雑さ、重要さがどうであっても、はじめから答えを得ようとしてはならない。重要なことは正しい答えを見つけることではない。正しい問いを見つけることである。（現代の経営）
どうも、正しい答え探しに夢中になり、正しい問いを見つけようとはしないところにあるように思える。問いを見つけられない限り、おそらく、顧客のところにいく理由
はない。あっても、せいぜい、自分たちの答えの確認である。ところが、自分たちがプロジェクトをやるために必要な問いが見つかれば顧客のところに行かざるを得ない。
その典型的な問いが
顧客にとっての価値は何だろう
という問いである。ドラッカーの言うとおり、顧客しか答えを知らない問いなので、顧客のところに行かない限り分からない。ただし、顧客のところに言って「御社のこのプロジェクトに対する価値はなんですか」といっても答えが返ってくることは少ない。
そこで大切になるのが、「対話」である。賢明な読者はすでにお分かりだと思うが、問いを立てるとは相手から情報収集をすることが目的ではない。そもそも、問いに対して顧客が答えを持っているという保証はない。Ｂ２Ｂであれば顧客が答えを持っている可能性が高いが、それでも今は見えないという顧客が多い。Ｂ２Ｃだと答えを持たない可能性が高い。その問いについて顧客やユーザと一緒に答えを作っていくことが目的なのだ。
言いかえると、顧客にとっての価値を一緒に作り、その価値に応えるソリューションを提供してくれることへの期待を高めていることが対話の目的である。
そして、その延長線上に価値を実現する目標がある。そのようにして作られた目標に対する計画ことがプロジェクトを成功させる計画である。作り手側の理論による目標に基づき作った計画は一見もっともらしく見えるが、虚構に過ぎない。
そしてプロジェクトスポンサーにとって重要なことは、このようにして作られた目標と計画によって、プロジェクトマネジャーも含めたメンバーのプロジェクトへの貢献が組織に対する貢献に結びつくということだ。この点についてドラッカーはマネジメントの中で
目標は、自らが属する部門への貢献によって規定される。プロジェクトエンジニアの目標は、彼と彼の部下たちが技術部門全体に対して果たすべき貢献によって規定される。（マネジメント）
と指摘している。プロジェクトの統制は、制約を持って行うのではなく、貢献を持って行うべきである。
| | 
|
コメント