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

プロジェティスタという考え方が注目を浴びている。きっかけになったのは、この本だ。

野田 稔+ミドルマネジメント研究会「中堅崩壊―ミドルマネジメント再生への提言」、ダイヤモンド社（2008）

プロジェティスタはイタリアで存在している職業で、一言でいえば、中小企業がプロジェクトを実施するときに、そのプロジェクトマネジメントを引き受ける。これにはイタリア独特の背景がある。イタリアでは、95％以上の企業が従業員9人以下という中小企業で、中小企業の輸出比率は60％に達する。イタリア企業の全体としての強みは、各企業間で縦横に張り巡らされた水平ネットワークであり、ネットワーク環境で活躍し、ある意味でこのネットワークを支えているのがプロジェティスタという職業だというわけだ。

日本もイタリアと同じように中小企業産業を支えている国であるが、大企業がビジネス中核を担い、中小企業はそこに対して技術を中心に部分的なコミットをするという産業構造を持つ日本ではプロジェティスタは成り立ちにくい職業である。しかし、その発想は大いに参考になる。実際に、野田先生が提案されているのも、企業内において、ミドルマネジメントのロールとしてプロジェティスタを位置づけることである。

このプロジェティスタという形は、プロジェクトマネジャーのロールモデルとして非常に卓越したものではないかと思う。

ＰＭＩがＰＭＢＯＫやＰＭＣＤＦ（Project Managemet Competency Development Framework）だけを提示していた時代は、プロジェクトマネジャーは独立性の強い仕事だという風に感じていた人も多いと思う。現に日本企業でＰＭＢＯＫに関心を持った企業のほとんどはそのようなプロジェクトマネジャー観を持っていたと思われる。

しかし、それは米国においてもあまり現実的な姿ではなく、また、ＰＭＩの標準を見ていてもその後、プログラムマネジメントやポートフォリオマネジメントにおける標準、さらには、これらすべてを束ねるＯＰＭ３という組織成熟度の標準が登場するに当たってはだんだん、見え方もプロジェクトマネジメントは組織ぐるみで行うものだという方向に変わってきている。

つまり、ガバナンスのマネジメントをきちんとして、プロジェクトマネジャー、プログラムマネジャー、ポートフォリオマネジャーといった「ロール」に、「プロジェクトマネジメント」、「プログラムマネジメント」、「ポートフォリオマネジメント」という「ツール」を使ってプロジェクトを組織としてマネジメントしていくという合理的なマネジメントシステムを構築し、戦略実行をしていこうという考え方が明確になってきた。

このような価値観は、従来からある日本の価値観に合わない点が出てきている。大きな問題は２つあるように思える。ひとつは、プログラムマネジメントやポートフォリオマネジメントといった組織マネジメントが含まれてくる部分は日本型経営の強みであった。ここを標準化してしまい、競争の対象から外してしまうのは、あまりにももったいない。米国は違うが、日本企業はこの部分のマネジメントに付加価値の源泉があるからだ。

そもそも、なぜ、こういう話になっているかと考えてみると、戦略経営が必要だということに尽きる。では、なぜ、戦略経営かと考えてみると、これはいくつかの理由はあるが、最大の理由はグローバルな競争である。グローバルな競争のためには戦略が必要である。これは事実だと思う。

ただし、では、日本型の組織では戦略経営が成り立たないかというとそんなことはない。トヨタがなによりもそれを証明しているし、たとえば、京都には日本市場に関心を持たず、いきなりグローバル市場に出ていき、マネジメントシステムを構築している会社がいくつもあるが、そのような企業の経営を見ていても、日本型経営のスタイルで戦略展開している。要するにこの議論は、戦略を持つべきであるということだけが問題であるにもかかわらず、抱き合わせ販売のように戦略達成のマネジメントをそこに押し付けられているところにあるのは明らかである。

つまり、戦略を作り、戦略実行ができるのであれば、どのような形でも構わないことになる。

二つ目の違和感は、個人にとってのやりがいの問題だ。米国のマネジメントシステムはキャリアアップをし、たくさんの報酬を得ることを望んでいるという価値観を基本にしている。ゆえに成果主義がうまく機能する。余談だが、そこに飽き足らなくなってくると、社会起業のような活動を始める。

日本人はこれではおそらくやりがいを感じない。米国のような価値観を持っている人もいるが、その人たちも５０歳くらいまでに価値観が変わることが多いようだ。では日本人は何にやりがいを感じるかというと、自分にとってのおもしろさであり、また、他人から感謝される（認められる）仕事である。従来から、生涯現役でいたいという人は多くいた。野田先生の著書の表現を変えると、生涯、一プレイヤーでいようという人だ。

ところが、成果主義の中ではこれは通用しない。野田先生の指摘するようにミドルまできて、プレイヤーである人はあきらめ感があるというくらい深刻な状況になっている。

ここでドロップアウトしたくない人は、マネジメントの仕事に入っていく必要がある。ところがマネジメントの仕事にやりがいを感じる人は多くないし、不安感のようなものがあるのだと思う。そこで、マネジャーではなく、プレイングマネジャーを目指す。

つまり、マネジャーの役割もするが、同時にプレイヤーという役割も果たすという人だ。部下を持ち、部下を使ったプロジェクトをいくつか同時にマネジメントするというスタイルで仕事をしているミドルマネジャーがこれだ。日本の企業が上に述べたように、日本型経営スタイルでなんとか戦略実行をできているのは、プレイングマネジャーの役割が大きいことも間違いない。

このようなスタイルで仕事をしている人は、野田先生が指摘するように「プロジェティスタ」に極めて近いし、逆に、プロジェティスタをロールモデル（手本）とすると自分たちの価値観を活かし、成果を上げることが可能になるのではないかと思われる。

以上のように考えてみると、プロジェティスタが日本の企業の中で普及していくことは、ミドルマネジメントが復活し、競争力をとり戻るために不可欠だと思えてくる。また、その意味で、プロジェクトマネジャーは次のステージとしてプロジェティスタを目指すというのがよいだろう。さらに、著者が「ひとつ上のプロマネ。」といっているものの、ひとつの実現イメージは間違いなく、プロジェティスタである。

ということで、しばらく、プロジェティスタというのを追いかけてみたい。

残業が問題解決を遅らせる（吉越浩一郎、トリンプ元社長）

【効用】

・ＰＭ体質改善
　　リーダーシップ発揮、問題解決能力向上、計画力アップ、実行力アップ
・ＰＭ力向上
　　ピープルマネジメント力向上、チームをまとめる力の向上、リスク対応力向上
・トラブル緩和
　　モチベーション向上、チームの士気向上

【成分】

◆粗い計画と残業
◆プロジェクトマネジメントにとって残業は諸悪の根源
◆残業ゼロがプロジェクトの成功をもたらす
◆もう一つの問題

このサプリを服用したい方はこちら。

◆プロジェクトの３大ステークホルダはそれぞれ、対立する目的を持つ

プロジェクトには多くのステークホルダがいる。プロジェクトマネジャーからみた場合の三大ステークホルダは、チーム、上位組織、顧客である。ここで言う顧客は、プロジェクトの成果物を活用して何らかの活用する人たちである。

プロジェクトの始まりには、プロジェクト憲章を作って、目的や成果目標、前提、制約を明確にしなさいという。たとえば、ＳＩベンダーのＳＩプロジェクトを例にとって考えてみよう。顧客はプロジェクトを起こした目的があるはずだ。それは、最終顧客に対するサービスの向上かもしれないし、あるいは、原価の低減かもしれない。いずれにしても、単純に考えれば、ＳＩベンダーに支払う費用が少なければ少ないほど、顧客の目的達成の度合いは大きくなることだけは間違いないだろう。

しかし、ベンダーにはベンダーの目的がある。利益を上げること、あるいは顧客との取引額を大きくするといったことだ。ここで早くも思惑が食い違う。顧客はお金を払いたくない。ベンダーは１円でもたくさんのお金をもらいたい。

さて、ここで視点を変えてプロジェクトチームのメンバーにはどのような目的があるのだろうか？プロジェクトをうまくやることによって、目標を達成し、評価を上げることが目標かもしれない。そのプロジェクトに新技術を適用し、習得することによって、その後のキャリアにプラスにすることが目的かもしれない。

いずれにしても、そんなに簡単に両立するようなものではない。

◆プロジェクトデザインとは結局のところ、目的の整合である

しかし、プロジェクトの目的は、このようにすべてのステークホルダの目的を満たすものでなくてはならない。プロジェクトのデザインをする中で、最も難しいのが、プロジェクトの目的の設定である。

多くの場合にはこれができないので、力関係で、まず、組織が顧客に対してなき、メンバーや下請けのベンダーが組織に対してなくという構図が描かれることが多い。これではだめだということで、なんとかしてみんなが満足する目的を見つけようという話になる。いわゆるＷｉｎ－Ｗｉｎの関係というやつだ。

ここでよく考えなくてはならないのは、目的の整合のさせ方には２つがあることだ。ひとつは文字通り、Ｗｉｎ－Ｗｉｎである。もう一つは共通点だけ取るという目的の設定の仕方だ。実は日本人は後者がとても得意である。

典型的な例を示そう。ＳＩプロジェクトで、「ユーザが満足する品質の○○システムを作ろう」という目的の設定である。このような目的が１００％プロジェクトの目的であるということはあり得ない。顧客もベンダーも戦略上の目的というのが必ずある。これだけで戦略上の目的が達成できればほとんど戦略などないと言ってもよい。

◆共通部分だけすり合わせするのはナンセンス

もうお分かりだと思う。このような部分的な目的設定をしておいて、あとは、属人的、あるいは場当たり的に適当にやっていこうというのが日本流なのだ。この場合、まず、戦略など顧みられることはない。ひたすら、当事者の満足やメンツといったものが重視される。要はそれで現場は丸く治まるのだ。何も目的の合わないところを公式にやりあって、勝ち負けをつける必要もないし、Ｗｉｎ－Ｗｉｎなどどうでもよいという感覚である。

ただし、これをやると、間違いなく、最もつらい思いをするのはプロジェクトである。一生懸命にやっても評価されない、責任は全部押し付けられるなど、悲惨なことになる。非公式な意思決定をするのだから弱いものが泣くのは当然である。

これではどんなにチームビルディングをやってみても、チームの一体感は生まれてこない。プロジェクト初期の緩い間はまだよいが、後半を迎え、本来チームワークがもっとも重要な修羅場になってくると、間違いなく、チームは崩壊する。チームの一体感を引き出すためには、まず、目的設定のところにとことんこだわり、目的が合意できない限り、プロジェクトは開始しないくらいの覚悟を持つことが必要である。

プロジェクトの運用においてチームのマネジメントに対する関心が高まってきている。チームのパフォーマンスには２つの側面がある。ひとつは創造性であり、もう一つが生産性である。

創造性は「３人集まれば文殊の知恵」を実現することだ。知的生産性だと言ってもよい。

いろいろなアイディアが出てきて、１人では思いつかないような問題解決ができたり、素晴らしい商品アイディアが出てきたりする。これはファシリテーションをうまく行えば、確実に実現できる。

ところがチームはよい話だけではない。プロジェクトの中でも、設計作業や開発作業のような実務的な仕事をチームで行うと必ず、生産性が下がる。つまり、２人でやって２人分の仕事ができることは珍しい。せいぜい、１．５人分だろう。人数が増えれば増えるほど、パフォーマンスの低下は大きくなる。

チームマネジメントの前提

よく、チームは２人で３人以上の仕事をするというが、これはこの２つがうまくいったときの状態を指している。つまり、創造性を高め、かつ、生産性を落とさない状態がチームなのだ。

チームが難しいのは、この２つには本質的なトレードオフがあることだ。

創造性を高めるにはできるだけ、自由に活動させる方がよい。しかし、あまり自由にさせると生産性が極端に低くなる。かつ、ＩＴのような顧客ビジネスのプロジェクトではこれに加えて、顧客への対応というもう一つのトレードオフが出てくることが多い。

このトレードオフを最適化するのがチームマネジメントだと言える。現実を見ていると、これらに優先順位を付けてチームを動かしていることが多い。たとえば、ソフトウエア開発のプロジェクトでは創造性を高めることを重視し、生産性を犠牲にしているケースが多い。また、同じＩＴでもＳＩプロジェクトでは生産性を重視し、創造性を犠牲にしているケースが多い。このようなトレードオフがトータルのパフォーマンスを高めるからだ。

しかし、これではマネジメントしているとはいえない。

どうすればよいか？創造性の向上によって実行力をカバーしていくこと、あるいは、逆に生産性の向上の中から創造的なコラボレーションを生み出していくことができて初めてチームのマネジメントだと言える。

プロジェクトマネジメントでは、ＷＢＳやＯＢＳによって分担をして仕事を進めていく。これはチームの生産性を落とさないためだ。チームへの第一歩は、ＯＢＳで決まった分担を前提にして、それを超えた行動をすることだ。ＷＢＳをいくら完璧に作ってもモレはあるものだし、突発的なできごともある。その中で、メンバーが自律的に判断をして、そのような事態に対処していけるようにすることである。

個の多様性がオピニオンの多様性になって組織の中で解放され、企業のパフォーマンスにつながっていくことが重要だ（シー・スウィート・クラブ）

【効用】
・ＰＭ体質改善
　　アカウンタビリティ向上、リスク管理能力アップ、アナロジー思考力アップ、
　　バランス感覚の洗練、問題解決能力向上
・ＰＭ力向上
　　プロ意識の向上、実行力向上、リスク対応力向上
・トラブル緩和
　弱気克服、プロジェクトにおける辛さの克服

【成分】

◆広まるダイバーシティマネジメント
◆プロアクティブとリアクティブ
◆プロジェクトマネジメントとダイバーシティ
◆慣れない状況はチャンス
◆プロアクティブプロジェクトマネジメントの一要素としてのダイバーシティ

このサプリを服用したい方はこちら。

チームマネジメントが注目されるようになってきた。チームマネジメントとはどんなことをするマネジメントだろうか？

チームの話でよくつかわれるエクスサイズに以下のようなものがある。

一郎君と次郎君と三郎君の３人兄弟がいる。お母さんに言われて、家の掃除をすることになった。一人でやれば６時間かかる。３人で一緒にやれば何時間かかるだろうか？

単純計算をすれば２時間である。しかし、このエクスサイズを行うといろいろな答えが出てくる。ポイントは２時間を超えるかどうか。代表的な意見は以下のようなものだ。

１人でやったの無駄は段取り変えにある。掃除機をかける、掃除機をかけれない場所をふく、窓ガラスをふくというところで、何度か段取り変えが出てくる。したがって、２人でやることによればこの段取り変えを減らすような分担ができるし、また、疲労が少なくなるのでパフォーマンスの低下が小さく、ゆえに２時間以下に減る。

というのが一つの意見。もう一つの代表的意見は、

二人でいくら効率的にやっても２時間かかるのだから、２人でやる作業の段取りを決めたり、作業の行き違いもあると思われるのでそもそも、ベースラインを２時間に設定するのがおかしい。したがって、いくら頑張っても２時間ではできないだろう。

というもの。

他にもお兄さんの太郎君のリーダーシップによるだろうとか、兄弟の仲がよいかどうかによって違うとか、掃除の道具ややり方によって違うとか、まあ、いろいろと出てくる。チームビルディングにもなると思うので、ぜひ、一度、あなたのチームでも議論してみてほしい。

掃除のようなベースラインのある作業を行う場合には、１人の場合と同じやり方をしたのでは２人でやって生産性が倍になることはまずない。コミュニケーションの問題とか、協働の問題で、必ず、生産性は落ちる。

ＦＦＳ理論という独自のチーム理論を展開しているヒューマンロジック研究所によると、１０人のチームではだいたい、ベースラインの生産性が６～７人分の生産性だという。このデータは実験に基づくちゃんとしたものだが、僕も感覚的にいえば、こんな感じだと思う。

チームとは３人が集まったときに３人分以上の仕事をする状態だというが、まずは如何に３人分の仕事をするかというのが問題になる。この問題は、リーダーシップの問題であったり、チームワークの問題であったり、モチベーションの問題であったりする。

同時に、３人で、１人ではできない方法で作業ができる方法がある。分業して慣れればパフォーマンスが上がるというような単純な課題はプロジェクトではあまりないと思われるが、それでも工夫すれば見つかることが多い。そして、作業者としての熟練と、プロセスの改善を継続的に行う。

この２つの要素を組み合わせてチームのパフォーマンスを上げていくのが、チームマネジメントである。

◆チームマネジメントを学びたい方はこちら！

〓【開催概要】〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
　◆　「ひとつ上のプロマネ。養成講座」
　　　　第４回　チームを育てるスキルを身につける◆７ＰＤＵ取得可能
　　日時：2008年8月20日（水）　10:00-18:00
　　場所：ヴィラフォンテーヌ汐留コンファレンスセンター（東京都港区）
　　講師：好川哲人（株式会社プロジェクトマネジメントオフィス）
　　詳細・お申込　www.pmstyle.biz/smn/team.htm

〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
【講義】
・チームを作るとはどういうことか
・プロジェクトマネージャーのリーダーシップ行動
・チームビルディングエクスサイズ
【グループ討議】
・管理と統率を両立するにはどうすればよいか
・メンバーのコミットメントをどのように引き出すか
【ロールプレイ】
・スケジュール遅延の際のリーダーシップ
【エクスサイズ】
・チームコミュニケーションエクスサイズ
〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓

「計画している」というけど、それは決して「計画」ではない（保田健治、グローバルマネジメントコンサルティング代表）

【効用】
・ＰＭ体質改善
　　ＰＭ体質の全般に対して効果があります
・ＰＭ力向上
　　ＰＭ力向上の全般に対して効果があります
・トラブル緩和
　　モチベーション向上、チームの士気向上

【成分】

◆計画を作るマネジャーは２８％
◆計画と呼べない計画
◆プロジェクトにおける目標でしかない計画
◆プロジェクト計画は目標だという考え方もある
◆計画はシミュレーションである

このサプリを服用したい方はこちら。

◆メンタルモデル

メンタルモデルという言葉を聞かれたことがあるだろうか？我々の心に固定化されたイメージや概念のことだ。刷り込み、思いこみだと言ってもよい。

ハーバードビジネスレビュー２００８年８月号にプロジェクトマネジャーのメンタルモデルをめぐるたいへん興味深い論文が載っていた。これだ。

キショア・セングプ、タレク・アブデル、ルーク・ファン・ワッセンホフ「プロジェクト・マネジャーが陥る「経験の罠」 」

この論文では、プロジェクトマネジメントのシミュレータを使って、数百人にのぼるベテランのプロジェクトマネジャーの調査をやっている。そして、その結果、必ずしも、これらの経験の豊富なプロジェクトマネジャーのパフォーマンスが高いわけではないことが分かった。むしろ、同じ失敗を繰り返し、パフォーマンスが低いケースが多いという結果が出た。

そしてその原因はなんと、従来、プロジェクトマネジャーの重要な資質だと考えられてきた「経験」にあるという結果を得たというのだ。

◆失敗を繰り返す３つの原因

実際に実験に協力したプロジェクトマネジャーの多くは、過去の判断ミスが反省せず、その後の意思決定に活かすこともなく、結局のところ、失敗を繰り返していることが多いが、その原因は３つあったそうだ。

ひとつ目は原因と結果の間にタイムラグがあることだった。タイムラグがあるので、因果関係がはっきりしない。たとえば、新たに加えたメンバーがチームに慣れ、思惑通りの能力を発揮するには常識的に考えて２～３か月かかるが、彼らはメンバーに加えるとすぐに能力を発揮するという判断をするのだ。そして、それは繰り返される。

二つ目は見込み違い。これは初期の見込みを修正できずに、チームに影響が出てくること。たとえば、生産性。ひとりひとりのメンバーの生産性に対して初期に設定した生産性が見込み違いであることが、進捗報告の評価によって判明しても無視する傾向がある。また、評価そのものを低めに行う傾向がある。これは、より多くのリソースを獲得したいという心理が働いているという。

三つ目はもっとも根深い問題だ。プロジェクト初期の目標が達成できそうにない場合に、彼らは目標の下方修正より、初期目標に拘り、ボロボロになりながらも何とか達成することにこだわるという。この背景には彼らのキャリアの中で「上司から与えられた目標は絶対である」というメンタルモデルが培われていくためだ。実際のところ、多くの企業では目標の下方修正は「失敗の自認」であるとみなされると指摘する。

このようにベテランのプロジェクトマネジャーは、長年、培われてきたメンタルモデルが支配し、それゆえに適切な判断ができなくなる傾向があるという論文である。これを防ぐためには、プロジェクト管理の仕組みの中に認知フィードバックの仕組みを入れて、プロジェクトマネジャーに思い込みに気付かせることが重要であると述べられている。まさに、アーンドバリューなどはそのためにあるといってもよいだろう。

以前、プロジェクトマネジャーの育成では失敗を糧にすべきという意見に対して、ＰＭ学会会長の富永氏に、「ＩＢＭでは失敗するプロジェクトマネジャーは何度でも失敗を繰り返す」と指摘されたが、結局、こういうことなのだろう（ちなみに、この論文で、企業名は明記されていないが、ＩＢＭと思われる企業がこの問題対処のベストプラクティスに取り上げられているので、ＩＢＭははやくからこの問題に気づき、対処していたのかもしれない）

◆経験を積めばつむほど失敗要因が強化される

少し、この論文から離れる。

この問題は、むしろ、メンタルモデルに起因するものなので、経験を積めばつむほど、強化されることになる。何とも考えさせられる論文である。全般的な印象でいえば、キャリアの浅いプロジェクトマネジャー（職位でいえば係長クラス）でこのような問題を感じさせる人は少ない（まれにエンジニアとしてのこのような感覚をそのまま引きずっている人がいるくらい）。ところが、シニアプロジェクトマネジャーになると、何を言っても自分の思い込みの世界から抜けきれないという人がよく見られる。明らかに強化されているわけだ。

ただ、これはそんなに単純な問題ではないことだけは言っておきたい。つまり、プロジェクトの状況で白黒がはっきりしていればアドバイスもできるが、本質的にはプロジェクトの状況も認知の問題であるので、そうは思わないと一言言われれば抗う余地はなくなる。したがって、対処のまずさも本人が気づくしかないのだ。

◆現場にみる３つの罠

また、この論文で指摘される３つのこの問題も、よく見かける。

最初のラグに対応できないという問題はかなり深刻な問題である。問題解決をする際にはアクションに必ずラグが出てくるが、このラグを考慮した問題解決を行うことのできるプロジェクトマネジャーにはほとんどお目にかからない。

二番目の見込み違いもよく見かける問題だ。多くのプロジェクトマネジャーは見積もりが間違っていたと認識した時点で計画を放棄する傾向がある。見積もりを見直して、新たな計画を作ってその計画に従って、プロジェクトを進めていこうとはまず考えない。ＰＭツールを使い、生産性を一括して変更できてもなかなかやろうとしない。初期の設定に拘り、なんとか、今の生産性をベースにして管理しようと工夫する。初期の設定が間違っていることはプロジェクトマネジャーとして決定的な落ち度になると考える傾向があるようだ。

これはプロジェクトの命取りになりかねない。

三番目も多い。なかなか、プロジェクトマネジャーが上位組織に対して、スコープ削減、納期変更などの目標の下方修正を申し入れることはない。これは不思議な現象だが、この論文のようにメンタルモデルを持ちだされるとよく分かる。そして、この論文の指摘通り、たとえば、１００％のスコープを９０％にして納期どおり、スケジュール通りに達成するよりは、大幅なスケジュール遅れ、大幅なコスト超過を起こしても、１００％のスコープを達成する方が評価される傾向がある。一度、コンサルティングに入った商品開発プロジェクトで、スコープ削減の提案をしたが通らず、２億円の予算が２億８千万円、開発期間１１か月が１５ヵ月になったが、プロジェクトマネジャーもメンバーも評価されて、びっくりしたことがある。

結局、上位のマネジャーは目的を達成するプレッシャーが一層強い。それゆえにこのようなことになるのだろう。

なんとはなくだが、コンサルティングの中で、抱いていた感じが、シミュレーションによってきちんと実証された感じだ。この論文はいろいろと使える！

人は、意味の共有ではなく、意識の共有で動く（小宮一慶、コンサルタント）

【効用】
・ＰＭ体質改善
　　アカウンタビリティ向上、計画力アップ、リスク管理力アップ、実行力向上
・ＰＭ力向上
　　チームをまとめる力の向上
・トラブル緩和
　　不要なトラブルの回避

【成分】

◆問題解決はチームで行うことが大切
◆チーム問題解決を可能にする風土
◆徹底的に議論し、結論がでたら従う
◆チーム問題解決では問題の定義が特に重要
◆答えを絞り込まず、優先順位をつける

このサプリを服用したい方はこちら。

ＰＭＢＯＫプロジェクトマネジメントの導入をすると、例外なく、ドキュメントワークの大変さを訴えるプロジェクトマネジャーが出てくる。実際にプロジェクトの立ち上げの際には時間の制約があり、かつ、マネジメント業務が集中する中でやらなくてはならないので、本当に大変だと思う。いくら、ドキュメントワークに慣れているといっても、欧米のプロジェクトマネジャーはこれだけのドキュメントを本当に書くのかと疑問を持っているプロジェクトマネジャーも少なくない。

そう思った経験のある人は、ＰＭＢＯＫのプロジェクト活動の図式をもう一度、みてほしい。実はプロジェクトマネジメントの仕事というのはプロジェクトマネジャーが一人でやるような図式になっていないのだ。少なくとも、プロジェクトマネジメントを担当すべき人は３名いる。

（Ａ）プロジェクトマネジャー
（Ｂ）プロジェクトスポンサー
（Ｃ）プロジェクトマネジメントチーム

である。プロジェクトマネジメントの指揮をするのがプロジェクトマネジャーであることは間違いないのだが、それはプロジェくマネジメントチームを結成し、プロジェクトマネジメントの体制を作り、さらには、プロジェクトスポンサーへのマネジメント活動の依頼をすることを意味している。

さて、プロジェクトマネジメント業務を分類すると、以下のように分けることができる。

（１）プロジェクト体制の整備
（２）プロジェクト運営方針の調整とステークホルダの調整
（３）プロジェクト運営に関する意思決定
（４）プロジェクトの統制
（５）プロジェクトマネジメント成果物作成作業
（６）プロジェクトの対外的アピール

ＰＭＢＯＫで問題にされているドキュメントワークの多さは、（４）の量の多さである。

さて、ここで問題は誰が何をするかだ。まず、確実にプロジェクトマネジャーの仕事だと言えるのは、（１）～（４）である。そして、（１）の中で、プロジェクトマネジメントチームの編成をする。その上で、（５）を依頼する。また（６）はプロジェクトスポンサーの仕事である。

ところが、現実には、（１）～（６）のほどんどがプロジェクトマネジャーの仕事になっている。これでは、いくら時間があっても足りない。

プロジェクトマネジャーがプロジェクトの立ち上げで真っ先にやるべきことは、プロジェクト憲章の作成でもなく、スコープの明確化でもない。プロジェクトの形を一緒に作ることのできるプロジェクトマネジメントチームの結成である。