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

◆プロジェクトマネジメントライフサイクル

前回までプロジェクトマネジャーやプロジェクトスポンサーの意志決定の重要性を説明してきたが、では、具体的にどのような意志決定をする必要があるのだろうか。今回が概要を説明する。

プロジェクトにおける意志決定はプロジェクトマネジメントのライフサイクルと密接な関連がある。ここではＰＭＢＯＫのような複雑なフェーズモデルは考えずに、もう少し、単純にプロジェクト全体に対するモデルで考えていきたい。PMstyleでは、プロジェクトマネジメントライフサイクルを

（１）構想
（２）実現性分析
（３）計画
（４）実行
（５）統制
（６）終結

の６つのフェーズで考えている。（３）～（６）は基本的にはＰＭＢＯＫのプロセス群と同じものなので説明は省略する。（１）と（２）は併せて、ＰＭＢＯＫのプロセス群でいうところの立ち上げプロセス群に相当する。

◆プロジェクトマネジメントは未来志向

最近、「フューチャーセンター」のマイブームで、未来志向という言葉が頭から離れない。未来志向とは、未来に目標を定め向かうことである。プロジェクトマネジメントは、この２０年くらいの間に、すごい発展をし、一つの完成形に近づきつつあるように思う。

そんなことを少しずつ、考えてみたいと思う。

まず、最初に明確にしておきたいのは、本来、プロジェクトマネジメントは未来志向である。数か月から数年の未来に目標を定めて、実現していくのがプロジェクトであり、その活動をスムーズに進めていくためにプロジェクトマネジメントがある。その意味で、未来志向の活動に他ならない。

ただ、考えてみたいといっているのはこのことではない。プロジェクトマネジメント自体が未来においてどのようになっていたいかだ。たとえば、５年先、１０年先にどうなっていたいのか？

◆賢者は歴史に学び、愚者は経験に学ぶ

ドイツ帝国初代宰相のオットー・フォン・ビスマルクの有名な言葉に、

賢者は歴史に学び、愚者は経験に学ぶ

という言葉がある。プロジェクトマネジメント関係者の中には、歴史を「自分以外の経験」と読み替える人が多い。たとえば、自分が担当した以外のプロジェクトの経験に学ぶ。この読み替えは正しいのだろうか？

話は変わるが、かつて、高度成長期の日本は経験至上主義だった。特に、定型的な業務を行うときには経験は極めて重要である。求人のときに経験者が優遇されるのは、経験が重要だからである。

定型的な業務では、学びより、覚える（倣う）ことが重要である。仕事を覚える。覚えるためには、理屈よりは経験だ。ゆえに、経験は重視される。これは別に日本に限ったことではない。どこの国に行っても同じだ。

ところが、マネジメントのような非定型な業務になると話はそう簡単ではない。経験がいらないかというと、経験は必要である。しかし、覚えるだけではうまく行かない。そこで、「学び」が必要になってくる。

◆「Right Risk」

プロジェクトリスクマネジメントの考え方は、当たり前だがプロジェクトを前提にしている。プロジェクトの制約が厳しくなり、また、創造性が求められるようになってきた今、好む、好まざるにかかわらず、リスクを取らざるを得なくなってきている。

「Right Risk」という言葉がある。（正しい）ゴールを達成するために、取ることが妥当なリスクのことだ。少なくとも、「Right Risk」は取らざるを得ない。

そこで、リスクマネジメントを組織で行うべきだという話が出てくる。これは何を意味するのだろうか？

よく行われているのは、プロジェクトの立ち上げや、計画の時に、プロジェクトだけではなく、上位組織も知恵をだし、リスクを評価し、対策を考えることである。これは、視点の多様性ができるという意味で、確かに有効な方法であり、実際に効果も出ている。

あるいは、リスクマネジメントを知識化し、リスクチェックリストや、リスク兆候の知識化、リスク対応策のナレッジベースの構築などを作る取り組みをしている組織もある。知識化は、リスクマネジメントへの効用だけではなく、教育という面でも効果があるよい取組である。

これらは、プロジェクトリスクマネジメントに対する組織としての取り組みとして位置付けられる。

ＰＭ養成マガジン１０周年記念イベント第２弾として

ＰＭ養成マガジン版　プロジェクトマネジャーが知るべき４８のこと

という「持論集」を作りたいと思います。

持論は、学生も、働く人も、だれもが持っている「自分なりにどうするか」の実践的理論です。ばくぜんと頭の中にある「暗黙知」を言語化して、みんなに理解してもらえる「形式知」に磨き上げたものを持論と言います。自論ということもあります。

米国に「97 Things Every ○○ Should Know」という大変有名なシリーズ本があります。○○には職業が入ります。それぞれの職業のプロフェッショナル９７人の持論を集めて作った本です。もちろん、プロジェクトマネジャー版もあり、昨年、日本語に翻訳されました。

「プロジェクト・マネジャーが知るべき97のこと」

具体的なイメージを知りたい人は、まずはこの本を読んでみてください。

これのＰＭ養成マガジン版を創ってみようと思います。手順と想定スケジュールは以下の通りです。

◆過去の活動の振り返り

２００８年８月～９月に補助線の記事として

【補助線】プロジェクトマネジャーから、プロジェティスタへ

【補助線】出でよ！プロジェティスタ！

という記事を書いた。また、その後も

【補助線】洞察とプロデュース

といった記事を書いてきた。

また、２００９年から「プロジェティスタ研究会」なるものを立上げ、同研究会とPMstyleの共催で、２０１０年５月～２０１１年３月にかけて、東京で５回、関西で１回、イノベーションをテーマにしたワールドカフェを行った。２０１１年３月のワールドカフェは１１日に開催し、第２ラウンドをやっている最中に東日本大震災が発生し、古い施設だったので結構、怖い思いをした。

【PMstyleCafe】プロジェティスタ研究会主催ワールドカフェ（５月１９日）報告

さらに、２０１０年～２０１１年にかけて何度か、

「プロジェティスタの仕事術」

というセミナーを行った。

プロジェティスタについては、震災をきっかけに時間が止まってしまった。震災後のいま、本当に必要な人材はプロジェティスタだという思いはあるのだが、動けなかった。

２月１１日にＰＭ養成マガジン１０周年記念セミナー第１回「ゲームストーミングによるプロジェクト活性手法」のワークショップ、５４名の方が参加され、盛会のうちに終了しました。

ファシリテータは国際大学GLOCOM主幹研究員「イノベーション行動科学」プロジェクトリーダー、富士ゼロックス株式会社 KDI(ナレッジ・ダイナミクス・イニシアティブ) シニア マネジャー、K.I.T.虎ノ門大学院ビジネスアーキテクト専攻 客員教授といろいろな活動をされている野村恭彦さんでした。

（ゲームの進め方を説明する野村さん）

◆知識労働者はエグゼクティブ

管理者がプロジェクトを管理する際にもっとも考えるべきことは、ＲＲＡＡ（Role,Responsibility, Accountability,Authority）ではなく、自分たちの仕事はどういう仕事かということである。プロジェクトマネジャーも、プロジェクトメンバーも、プロジェクトスポンサー（管理者）もプロジェクトにかかわる仕事をする人たちは、例外なくピーター・ドラッカーのいうところの「知識労働者」である。すなわち

知識をもって何事かを成し遂げることを欲する労働者

である。そして、ドラッカーは、知識労働者はすべてエグゼクティブであると指摘している。

エグゼクティブとは、仕事の目標、基準、貢献を自ら決定し、仕事をしている人たちのことである。肉体労働が労働の主体であった時代には、エグゼクティブとして仕事をするのは組織のトップ階層の人たちだけであった。しかし、知識労働においては、知識による権威は、地位による権威と同じように「正当かつ必然」のものであるといえ、だれもがすべての知識労働者はエグゼクティブであるとみなすことができる。

◆チェックリストは網羅的に作るものではない

チェックリストは誰でも知っているツールである。しかし、実体は意外と理解されていないのではないかと思う。たとえば、プロジェクトマネジメントの中でもっともチェックリストが使われているのはリスクマネジメント（リスクチェックリスト）だろう。多くの企業がリスクチェックリストを使って、リスクマネジメント計画を作っている。

では、リスクチェックリストをどのように作っているかというと、結構、考え方の違いがある。多いのは、網羅的に作るという方法である。とにかく、チェックリストをみれば考えられるすべてのリスクの有無が判断できるという狙いだ。その対極にあるのが、少数派ではあるが、必要最小限押さえておいてほしいリスクだけをチェックリスト化する。

リスクマネジメントとしてどちらがよいかではなく、チェックリストとしてどちらが適切かというと後者である。前者のものはチェックリストとは言わない。

リスクに限らず、チェックリストと聞くと多くの人が面倒だとか、厄介だという印象を持つ。それは、チェックリストに記載されていることは実施しなくてはならないからだ。と同時に、チェックリストの作り方が網羅的だからだ。

◆成果か人か

ある本を読んで、マネジメントは深いとつくづく思った。マネジメントはジレンマの集まりだというのだ。

たとえば、プロジェクトという業務の性格上、プロジェクトマネジメントは成果に焦点をあて、人には焦点を当てない。権限委譲をしてメンバーの自律的管理に委ねる。確かに、ＷＢＳを作って、達成しなくてはならない中間成果物とそのスケジュールを明確にする（落とし込みは必ずしも個人ではなくチーム単位の場合もある）。そして、スケジュール通りに中間成果物が出てくるかどうかだけを問題にする。メンバーの勤怠や勤務態度、あるいは業務遂行方法についてはメンバーに任せるわけだ。

これには前提がある。プロジェクトのメンバーはスキルを持った自律した人材であり、管理をされなくても自律的に仕事ができるという前提である。しかし、これはＳＩ事業のようにプロジェクトが常態化している場合には必ずしも成り立たない。

その場合には、成果に焦点を当てようとすると、それを遂行する人に注意を払わなくてはならない。つまり、メンバーが自分の担当する成果物をきちんと達成できるかどうかだけではなく、ある程度、そのやり方も見ておく必要がある。

ところが、プロジェクトマネジャー（リーダー）がその分野について必ずしも、不十分なスキルしか持たないメンバーより、知見を持っているかというとこれはまた別の話だ。そもそも、プロジェクトマネジメントが成果だけに焦点を当てるのは、そのプロジェクトチームにおいては、特定の問題に対しては特定のメンバーが最もスキルフルであるという前提に立つものだ。プロジェクトが専門家の集まりという所以である。

そのような状況で、人に注意を向けるにはどうすればよいか。よく見かけるのは、そのメンバーに指導をしてくれるスキルを持つ人に支援を請う、メンバーがスキルアップの動機を持つように仕向ける、といった行動である。

このようにプロジェクトマネジメントが難しいのは、２つの相反する活動（ジレンマ）を整合性を持って行わなくてはならないことだ。ここまでに述べてきた例では

成果に焦点を当てるために、人に焦点を当てなくてはならない

というジレンマである。