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

◆プロジェクトマネジメントで変わったもの、変わらないもの

プロジェクトマネジメントが日本で注目されるようになってきたのは、２１世紀になってからですが、それでもかれこれ、１０年近くになります。この間に変わってきたものと、相変わらず変わっていないものを一つずつあげるとすれば、みなさんは何を取り上げられますか？

変わってきたものは仕事のスタイルです。

・計画をたてて仕事をする
・進捗を管理しながら仕事をする

というワークスタイルは定着してきましたし、定着したと言えるかどうかは微妙ですが、

・ドキュメントによるコミュニケーションを行う

というスタイルもかなり浸透してきたようです。

これに対して、あまり変化がないと思うのは、「責任」を明確にして、責任を果たしながら仕事をするという点です。

この議論はプロジェクトマネジメントの前提とする組織観と、日本流の組織観の根本的な違いがあり、相当に難しい問題です。

◆プロジェクトＫＳＦ

ちょっと機会があって、プロジェクトの成功要因（ＫＳＦ）の研究について調べている。プロジェクトの成功はプロジェクトマネジメントの成功と異なり、ある意味での歴史的検証が必要である。たとえば、商品開発のプロジェクトで、スケジュール内、予算内で商品を開発したとしても即座にプロジェクトは成功だったとはいえない。ＩＴのプロジェクトで、スケジュール内、予算内で顧客の要望するシステムを作っても成功だとはいえない。商品であれば売れるかどうかが問題であり、システムであればそのシステムがライフサイクルを終えるときに満足しているかどうかが問題だからだ。

もっといえば、プロジェクト終了から１０年くらいたった後で、そのプロジェクトの実施にどのような意味があったが問題である。

調べた範囲でいえば、だいたい出てくるのは

（１）ステークホルダとの良好なコミュニケーション関係の構築
（２）プロジェクトチームやプロジェクトマネジャーの問題解決能力

の２つに加えて、もう一つある。最近、機会あるごとにこの質問をしているのだが、なかなか、正解に行き着かない。なんだかおわかりだろうか？

（３）プロジェクトの明確な定義がされていること

である。

◆注目されるプロジェクトガバナンス

プロジェクトガバナンスという言葉が目につくようになってきました。

日本では一部のプロジェクトマネジメントのプロフェッショナルの方は早くから関心をもってきた分野です。ＰＭ学会では２００６年に特集をやったりしていますが、そんなに議論が広まってきませんでした。やっとここにきてという感じです。

◆与えられた仕事を行う理由を徹底的に考えて下さい

もう２０年以上前の話になりますが、大学を卒業して三菱重工業という機械メーカに入社したときに入所式でこんなことを言われた方がいらっしゃいました。

上司から仕事を命じられたら、なぜその仕事をやらなくてはならないのかを徹底的に考えて下さい。分からなければ命じた上司に聞いてください。理解してから取りかかってください。理解するのに時間がかかっても構いません。結局それが近道になります。そして、理解できたら、その仕事を通じて自分として達成したい課題を一つ必ず見つけて取り組んでください。その課題が本来やらなくてはならない仕事の中にあるようなら、我が社の将来はありません。

実は三菱重工にいたときにはなんとも思わなかったのですが、その後、コンサルタントとして独立し、いろいろな会社をみているうちに、如何にすごいことを言っているかが理解できるようになってきました。多くの企業では、「そんな余計なことを考えなくてよい、言われたことを如何に高い品質で実現するかだけを考えろ」と指導されていたのです。

◆プロジェクトマネジャーの力量に問題がある？！

ある企業の事業部長が著者にこういいました。

プロジェクトがうまくいかないのはプロジェクトマネジャーの力量に問題があるからだ。

どう思いますか。「ＰＭＯは何をしているんだ」、「そんなプロジェクトマネジャーを選んだ組織にも問題がある」といった異論も出てきそうです。

◆リスクマネジメントの目的はリスクに強くなること

リスクマネジメントは、多くのプロジェクトマネジメント導入企業がもっとも重視しているマネジメント活動です。しかし、最近、よく何のためにリスクマネジメントをやっているのだろうと感じることがあります。

リスクマネジメントは、初期においてはプロジェクトマネジャーだけではなく、体系的な分析のできるＰＭＯや、経験の豊富なステークホルダが一緒にリスクの分析を行うことにより、プロジェクトのリスク対応能力を上げることに目的があります。

そして、このような「経験」を通じて、プロジェクトマネジャーやプロジェクト、ひいては、組織がリスクに強くなることを目指すものです。

◆基本知識

まず、言葉の定義から。各期の事業の計画を作るには、まず、経営ビジョンを作る。これは企業としてのあるべき姿、つまり、経営理念、事業領域、経営目標、事業構成、組織風土などから創り出される企業の将来の姿を示すことが目的である。

次に、経営戦略を創る。経営戦略とは、経営ビジョンに示すあるべき姿に企業を近づけるための方策（シナリオ）である。経営ビジョンを示し、経営戦略を策定するまでに一連の流れを経営計画と呼ぶことがある。

戦略が策定されると、戦略実行の段取りをする。ここで、戦略策定までは、ある程度長期、あるいは中期の話であることに注意をしておいてほしい。戦略実行の段取りも、まずは中期で行う。例えば、

・中期の経営目標
・事業展開の方向、重点、課題
・機能別革新方向、課題

を明確にし、経営の方向性を明確にする。これらを中期計画ガイドラインと呼ぶことがある。計画ガイドラインに基づき、

・販売計画
・研究開発計画
・設備計画
・人員計画
・利益計画
・資金計画
・全社中長期計画書

などの中期計画を作る。

その上で、やっと、単年度の事業計画（予算）を行うことになる。単年度の事業計画は中長期事業計画を単年度に置き直し、具体的な目標化をする。さらに部門別、製品別、期間別に落とし込んで、具体的な目標を定めたものである。

事業計画の方法はさまざまである。現場に影響のある損益予算でみれば、例えば、

○損益予算
　＋販売予算
　　　－売上高予算
　　　－売上原価予算
　　　－販売費予算
　＋製造予算
　　　－製造高予算
　　　－製造費予算
　　　－購買予算
　＋本部管理予算
　＋研究開発予算

といったメトリクスを使うことが多い。

このようにして、経営ビジョンからブレークダウンされた目標を達成するために業務（オペレーション）を行う。

目標達成の方法は、目標達成のための業務の性格に依存する。代表的には、反復性が高い業務である場合には定常業務として機能組織（ライン組織）で行い、反復性が低い場合にはプロジェクト業務としてプロジェクトチームを組織して行うことが多い。

◆プロジェクトデザインとは

第１話のテーマは「プロジェクトのデザイン」です。

プロジェクトのデザインというのは耳慣れない言葉かもしれませんが、大切な概念です。プロジェクトのデザインとは

プロジェクトで何を（広い意味での）顧客に提供したいかを明確にし、その方法の概略を決めること

です。簡単にいえば、プロジェクトの土台作りです。

◆プロジェクトデザインの留意点

プロジェクトのデザインにあたって、留意すべきことが３点あります。

（１）プロジェクトの成果物（プロダクト）とプロジェクト成果の関係（目的）
（２）不確実さへの対処（シナリオ）
（３）プロジェクト環境の設定（条件）

の３つです。

（１）は成果物と成果は違うということです。成果物は、システムであったり、商品であったりします。プロダクトと呼ばれるものです。一般には、これがプロジェクトの成果のすべてにはなりません。プロジェクトの成果は、プロダクトを通じて顧客や自組織に提供するもの、あるいは、プロダクトの開発を通じて自組織に提供するものといったケースがほとんどです。例えば、開発した商品でユーザに対して利便性（ベネフィット）を提供できた、開発した商品で自社シェアの拡大をもたらしたといったことです。

（２）はプロジェクトのデザインは、複数の選択肢を考えておく必要があるということです。プロジェクトのプロジェクトたる所以は、不確実性です。成果物の達成手段は計画で検討され、不確実性はリスクマネジメント計画として扱われます。しかし、成果達成の手段の不確実性は計画レベルでは扱うことができませんので、あらかじめデザインの段階で複数案を検討しておく必要があります。例えば、現有の自社技術では対応できない商品ラインナップを増やすという「成果」が期待される中で、商品を一から開発するのか、既存部品の組み立てで対応するのか、ＯＥＭ提供先を探すのかといった選択肢は、デザインの中でそれぞれ、どのような展開が考えられるかを検討しておき、その上で、もっとも優先するアプローチを決める必要があります。

（３）はプロジェクトを実施する条件です。特に、選択したアプローチを実施する際には、どのようなことが「前提」になっているのかを明確にする必要があります。これは、（２）でどのアプローチをするかを決める際にたいへん重要なファクターになってきます。

◆プロジェクトデザインをしないプロジェクトは基礎工事をしない建物

このようなプロジェクトのデザインは構想計画と呼ばれることもありますが、プロジェクトの計画の土台になるものです。いくら完璧な計画を作っても、土台がしっかりとしていなければどこかで崩れてしまいます。また、計画変更を要するトラブルが生じたら、あっという間に崩壊してしまいます。

プロジェクト計画の充実に力を入れることは重要ですが、計画の基礎工事であるプロジェクトデザインに力を入れていくことが、特に大規模で不確実性の大きいプロジェクトでは求められます。