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

エンパワーメント

プロジェクトをプロジェクトマネジャーに任せることは組織的にはどういうことかをしっかりと考えてみたい。「ひとつ上のプロマネ。」ブログにも書いたが、議論のポイントは、エンパワーメントか権限委譲かである。

※「孤立するプロジェクトマネジャー」
　　　https://mat.lekumo.biz/ppf/2007/09/post_9184.html

ブログ「ひとつ上のプロマネ。」にも書いたが、プロジェクトをプロジェクトマネジャーに任せることは組織的にはどういうことかをしっかりと考えてみたい。

『ウィキペディア（Wikipedia）』の説明の冒頭に以下のような説明がある。

◆エンパワーメントとは何か

さて、最初に、エンパワーメントとは何かについて説明しておく。

『ウィキペディア（Wikipedia）』の説明の冒頭に以下のような説明がある。

エンパワーメント (エンパワメントとも、Empowerment) とは一般的には、個人や集団が自らの生活への統御感を獲得し、組織的、社会的、構造に外郭的な影響を与えるようになることであると定義される。

このように、もともと、エンパワーメントという概念は、社会学者ジョン・フリードマンが提唱した個に着目したソーシャルスキルであり、コミュニティの根底をなすものであった。

このようなエンパワーメントを最初にビジネスに持ち込んだのは、米国経営学会の論文誌に発表されたConger, J.A.,& R.N.Kanungoの論文

Conger, J.A.,& R.N.Kanungo, "The Empowerment Process : Integrating Theory and
Practice", Academy of Management Review, Vol.13, 1988, 471-482

だといわれている。この論文をきっかけに定説といえるような流れができた。

◆エンパワーメント＝自律性を促す＋支援する

ビジネスにおけるエンパワーメントの特徴は、「自律性を促し」、「支援する」ことにある。

ここで、「自律性を促す」というキーワードは、業務の遂行に当たってマネージャーが業務目標を明確に示す一方、その遂行方法については構成員の自主的な判断に委ねることをさしている。これはいわゆる「権限委譲」である。

ところがエンパワーメントという概念には、「支援する」という活動がついている。「支援する」とは、部下に具体的な指示や解決策を与えるのではなく、部下自身が問題点を発見したり、不足する能力を開発したりする「環境」を整えることをいう。

さて、冒頭の問題に戻る。プロジェクトをプロジェクトマネジャーに任せるというのは権限委譲なのか、エンパワーメントなのか？

こういうロジックが多い。

当社にはプロフェッショナル認定制度があり、プロジェクトを任せるプロジェクトマネジャーはすべてプロフェッショナルとして認定されている。したがって、精神的な面はともかく、業務的な側面では支援を必要としていない

つまり、権限委譲さえすれば、十分であるという認識だという。この認識が適切であるかどうかは、事業や業務の特性によって変わってくると思われるが、ひとつだけ述べておきたことがある。

◆何が起こるかわからないプロジェクトではエンパワーメントが必要

プロジェクトとは何が起こるかわからない。したがって、どんな問題が起こるかわからない。まず、最初に引っかかることは、その問題の発見できるだけのプロジェクトマネジャーの能力があるかどうか。ここは疑問だ。

次に、発見できたとして、その問題を解決するだけの能力を持つかどうかだ。

だから、プロジェクトを立ち上げるときに、組織全体でリスク分析を行い、起こりそうなリスクはすべてつぶしているというマネジャーもいるだろう。そのとおりである。すでにここで、権限委譲という枠を超えて、支援に入っている。それ以外にもすべき支援がある組織も多いのではなかろうか？

その意味では、やはり、プロジェクトマネジャーにプロジェクトを任せるというのはエンパワーメントなのである。

【今回の課題】

プロジェクトマネジャーにプロジェクトを任せるにあたって、どんな支援をすればよいのだろうか？

９月２７日で第３期のＰＭＯリーダー養成講座が終わり、懇親会の席でＰＭＯのコストの議論になった。この問題について考えてみたい。

◆そもそもプロジェクトマネジメントコストは誰が持つべきか？

ＰＭＯのコスト以前に議論されているようで、本気で議論されていないのがプロジェクトマネジメントのコストをどう考えるかだ。この話はたいへん難しい話であるが、ＰＭＯとしてきちんと整理しておかなくてはならない話である。

プロジェクトマネジメントは本来、そのプロジェクトの目的を達成するために行うべきものである。その意味で、何をやって、何をやらないかということはプロジェクトマネジャーが判断すればよい。

しかし、実際にはそうはならない。標準を作る組織が多い。なぜだろうか？

◆アンケートに見る標準化の効果

以前、翔泳社のＰＭマガジンという雑誌の連載でこのアンケートをやったことがある。この結果で出てきた効果ベスト３は以下のとおりである。

（１）初心者にとって有効　４５％
（２）ナレッジの蓄積に有効　３５％
（３）プロジェクトマネジメントがうまくできる　１０％
http://pmstyle.jp/honpo/survey1/survey4.htm

これからわかるようにプロジェクトマネジメント標準がそのプロジェクトに対して、「直接的なメリット」をもたらしていると感じている人は全体の１割程度に過ぎない。これに対して、組織にメリットがあると思っている人は８０％いることになる。

◆標準化の本来の目的は

このアンケートの選択肢には明確な形で書いていないが、標準化というのは本来

　組織として成功を計画をできるようにするため

に策定するものである。言い換えると、このやり方をしていればうまくいくだろうという指標として標準がある。

であるとすれば、その組織の標準のプロジェクトマネジメントは、そのプロジェクトを成功を成功させるために欠かせないものであり、そう考えると、マネジメントコストはプロジェクトが持つというのが筋が通っている。

こういう建前がある。しかし、現実にはそのような筋書きにはなっていない。ＰＭＯから、自分たちの策定した標準どおりに行えば、プロジェクトはうまくいくという自信に満ちた言葉を聞いたことはない。標準を策定している側からの言い分は、だいたい、上のアンケートのものに近い。

まず、誰でも同じプロジェクトマネジメントをできるようになる。これは組織としては意味のあることだ。という言い分。確かにプロジェクトの成功率は上がるだろうが、シニアなプロジェクトマネジャーにとっては標準的なプロジェクトマネジメントを行う理由にならない。

そこで出てくるのが、ノウハウの蓄積という話。これはシニアなプロジェクトマネジャーにとっては自分のノウハウを組織に還元させていくという意味で標準を遵守する動機にはなる話だ。ただし、マネジメントコストをプロジェクトが持ってやるべきことではないという但し書きが着くだろう。

◆アカウンタビリティのための標準化という発想は正しいのか？

そこで、ＰＭＯ側の奥の手が出てくる。アカウンタビリティの確保である。つまり、上司や組織にプロジェクトの状況を説明し、必要とあれば指示を仰ぐのは組織人の義務であるという理屈だ。これを言われればプロジェクトマネジャーはやらざるを得ない。ただし、この場合もプロジェクトがコストを持つという話は成立しにくい。確かに、問題があれば組織として支援するので報告は必須であるというともっともらしいのだが、そもそも、そのような事項は組織がすべきプロジェクトマネジメントであり、それをプロジェクトマネジャーにマルナゲしているのがおかしいのだ。

このように考えると、プロジェクトマネジメントのコストはプロジェクトが持つべきだという論理は分が悪いのだが、あなたは、どう整理すればよいと思われるだろうか？

皆様の意見をお待ちしています。上の記事はブログ記事にしてありますので、こちらにコメントをください！

右手にロジック、左手に仮説、胸に信念、心は浪花節、そして執念の粘り腰（ヤハマ発動機社長・梶川隆）

【効用】
・ＰＭ体質改善
　　リスク管理力アップ、現象観察力アップ、バランス感覚の洗練、徹底確認力アップ
・ＰＭ力向上
　　ステークホルダをコントロールする力の向上、チームをまとめる力の向上
・トラブル緩和
　　モチベーション向上、弱気克服

【成分】

◆マネジメントにはＡＮＤの発想が必要
◆ロジカルと浪花節
◆仮説を持つには信念と粘り腰が必要

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

前の記事では、組織の問題を書いたが、プロジェクトマネジャーの孤立という問題に対して、プロジェクトマネジャーの問題はないのかという点についても意見を述べておく。

つい最近、アービンジャー・インスティチュートの箱本の第２弾の邦訳がでた。

アービンジャー・インスティチュート（門田美鈴訳）

「２日で人生が変わる「箱」の法則」
　　

箱本は、自分の殻に閉じこもり人間的な発想を失ったマネジャーが、箱から出て人間力を取り戻していくことを書いた本である。

第１弾はＰＭ養成マガジンの書籍プレゼントの対象になったこともあり、読者の方から話題にされることが多かった本である。

アービンジャー・インスティチュート（金森 重樹監訳、富永星訳）

「自分の小さな「箱」から脱出する方法 」

プロジェクトマネジャーが孤立する理由として、「箱に入りたがる」という理由も指摘しておきたい。スコープに関するトラブルを起こしたプロジェクトを見ていると、必ず、見られる理由のひとつがステークホルダコミュニケーション不足なのだが、その背景に「プロジェクトという箱」に入って出てこないプロジェクトマネジャーという問題があることが多い。

箱から出たがらない理由はさまざまだが、箱の中で見えていることですべてを決めてしまう。せいぜい、決まった様式や、形式的な会議での「コミュニケーションごっこ」をやるだけでプロジェクトを進めていこうとする。

こんなことをやっていれば、スコープの問題が起こらないほうが不思議だ。箱から出て顧客やほかの主要ステークホルダと人間としてしっかりと対峙して、一緒にやっていくことが何より重要である。

にもかかわらず、箱から出ないままで、自分の理屈をいい、相手を非難する。さらに、悪質だなと思うのは、プロジェクト全体を箱にしているのだ。つまり、プロジェクトメンバーは仲間であるので、真摯に向き合う。しかし、外部ステークホルダには向き合わない。メンバーまで、箱の中で自分の理屈をいう。こうなると、箱の中ではお互いに慰めあうのでどうしようもない仲良しグループになってしまう。

プロジェクトマネジャーがアホでも、メンバーにはカシコイのがいて、プロジェクトの窮地を救う。これもプロジェクトの醍醐味のひとつであるが、チームに対する誤ったマネジメントで、そんなダイバーシティを取り除いた仲良しチームを作っているプロジェクトは本当に目に余る。

コミュニケーションというのは諸刃の剣である。コミュニケーションによってチームのパフォーマンスがあがる。これは間違いない。しかし、それは箱の中のコミュニケーションになってしまうと、成果に結びつかない。ここをしっかりと把握しておきたい。

◆プロジェクトマネジメントブームを紐解く

PMstyleの展開を本格的に始めて１年半になる。今年度から過去にPMstyleのセミナーに参加していただいたお客様を対象にプライベートセミナーを開催している。第１回はプロジェクトマネジメントにかかわる諸問題の整理と議論を行った。第２回のPMstyleプライベートセミナーは、プロジェクトマネジメントを成功させる組織のあり方の問題を扱うことになった。今回はこの背景認識を紹介したい。

もう５年くらい前になると思うが、日本でもプロジェクトマネジメントブームが起こった。

誤解のないようにしておきたいが、それ以前は何もしていなかったということではない。もう１０年くらい前、つまり、ＰＭＢＯＫでいえば第１版（９６年版）が出てきたあたりから、先進的な企業はＰＭＢＯＫなどを参考にしながら、体系的なプロジェクトマネジメントの導入に取り組んでいたし、また、９０年代にＰＭＯ（プロジェクトマネジメントオフィス）を作っていた企業も少なくない。日本プロジェクトマネジメント協会（当時の、日本プロジェクトマネジメントフォーラム＝ＪＰＭＦ）もこの時期にはすでに活発に活動をしている。

ライフサイクルでいえば（近代）プロジェクトマネジメントの世界的な動きは

　揺籃期　～１９９０
　成長期　～２０００
　成熟期　２０００～
　衰退期

という感じだと思うが、日本の普及を見ていると、ユーザが

　～1995　Innovator
　～2000　Early Adopters
　～2005　Early Majority
　2005～　Late Majority

といった感じで出てきているのではないかと思う。具体的なユーザとしては

　～1995　Innovator　外資系のＩＴ企業、エンジニアリング業界の一部企業
　～2000　Early Adopters　国内資本ＩＴ系企業、製薬業界の一部企業

といったところではないだろうか。

このような動きの中で、ＰＭブームは、何人かのエバンジェリストが登場し、多くのEarly Majorityを生み出したことによって起こった。彼らは、メディアやコミュニティなどを通じて、プロジェクトマネジメントの必要性を説き、多くの企業にプロジェクトマネジメントの導入の契機を作った。

◆権限委譲は何をもたらしたか

このような普及の中で、ややもすると「プロジェクトマネジメントはプロジェクトマネジャーに権限委譲して、全面的に任せるものだ」というイメージが植えつけられた。むしろ、口出しをすべきではないという風潮ができたのも事実である。これが後に禍根を残している。

これは多分に受け止め側の問題でもあるので、エバンジェリストだけの責任とはいえないが、結果としてそのようなあまり適切とはいえないイメージができたことは事実だ。ただし、このイメージが急速に広まっていったのは、実はエバンジェリストの影響ではないと思う。受け止め側の問題と書いたが、むしろ、これが組織のミドルマネジャーやシニアマネジャーにとって好都合だったということが大きいと思われる。この図式の中では、自分たちはプロジェクトの実施責任をすべて放棄して、成果を求めるという構図ができるのだ。

これにより、プロジェクトマネジャーは「責任が大きくて報いがないあまりやりたくない仕事」という印象がついてしまった。当たり前である。これまでは、失敗も成功も上司の問題という立場から、「失敗すれば自分の責任、成功すれば上司の手柄」という仕事にかわってしまったからだ。もちろん、インセンティブ制度などを取り入れ、報いようとする動きはあるのもの、キャリアに結びつく評価というのはあまりされることがない。

◆孤立するプロジェクトマネジャー

また、もっと深刻な問題はプロジェクトマネジャーが孤立し始めていることだろう。プロジェクトマネジャー自身ではどうしようもないようなリソース関連の問題や、ビジネスの収益確保の問題まで一人で抱え込んでいるプロジェクトマネジャーが増えている。

これらは組織側からは失敗プロジェクトがなくならないという現象に見えた。そこで、やむなく「口出し」をするという施策をとり、うまくいっている企業もある。

◆権限委譲からエンパワーメントに

この議論は根本的な誤りがある。プロジェクトマネジャーにプロジェクトを任せることは「権限委譲」ではなく、「エンパワーメント」である。これが理解されていない。エンパワーメントとは業務の遂行に必要な権限を渡すと同時に、

　・目的・目標の合意
　・自由度の供与
　・補完的な支援

を行うものである。権限は委譲しても、この３つのいずれか、あるいはすべてができていない組織が多いのだ。

判断と決断は違う（丹羽宇一郎・伊藤忠商事社長）

【効用】
・ＰＭ体質改善
　　リーダーシップ発揮、実行力向上、自己統制力アップ、アカウンタビリティ向上、
    問題解決能力向上
・ＰＭ力向上
　　チームをまとめる力の向上、ステークホルダをコントロールする力の向上、
　　リスク対応力向上、プロ意識の向上
・トラブル緩和
　　モチベーション向上、プロジェクトにおける辛さの克服

【成分】

◆判断と決断
◆判断は誰にでもできる、しかし、決断はできない
◆プロジェクトマネジャーの重要な仕事は決断である
◆ヒトゴトだと考えるとプロジェクトはうまく行かない
◆キャリアをかけて決断をする

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

情報サービス産業協会（JISA）の浜口友一会長が興味深い発言をされている記事が日経ＢＰ社のサイトに掲載されていた。

http://itpro.nikkeibp.co.jp/article/NEWS/20070831/280932/

一部を抜粋すると

「止めてはいけない重要なシステムは、世の中にどれだけあるのだろうか。ベンダーや顧客、マスコミも交え、もっと議論すべきだ」

という発言。浜口会長の意見を好川流に解釈すれば、情報システムの品質マネジメントは「思考停止に陥っている」という問題提起である。浜口会長のような立場の方がよくぞ、言ってくれたと思う。拍手喝采！

プロジェクトマネジメントの方針を決める場合に、「品質は絶対」だとよく言う。これは正すべきである。コンサルティングや研修などの機会に口をすっぱくしていっているのが、「品質絶対だというな！言った瞬間に思考停止に陥る」ということだ。

実際に、コンサルにしろ、研修にしろ、書かれたプロジェクトマネジメント計画書を見ると例外なくプロジェクトマネジメント方針として品質絶対と書いている。気持ちはわからないでもないが、これは明らかにおかしい。

「プロジェクト品質絶対」

だと書くのであれば、まだわかる。プロダクト品質絶対などありえない。これはプロジェクトのスコープを決めていないに等しい。まさに、思考停止である。

プロジェクトマネジメントを少し離れるが、顧客満足について考えてもらうときに使うエピソードに、「ある会社で壁に「顧客絶対主義」だと書いてあった。顧客絶対主義では顧客は満足しないだろう」というのがあるが、品質の話もこの話に通じる。

品質絶対で顧客が本当に満足するのか？もっと大きく言えば、浜口会長の発言にあるように社会的コンセンサスとして社会が求めているものなのか？

結論を出す前に、まず、なぜ、こんな状況に至ったかを述べておく。一般的にいえば、品質コストは

　予防コスト＜評価コスト＜不良品対応コスト

という順序になる。従って、できるだけ不良品を出さないようにすることが品質コストを下げることに通じる。従って、まずは不良品を出さないプロセスや設計に力を注ぐ。それが難しい場合にはテストや検査を徹底する。それでも、どうしようもない場合にはアフターフォローに力を注ぐ。当然、順に利益が小さくなる。

ただし、この構図は商品ライフサイクルが短い場合の話であって、一定のサイクルより短くなると成立しなくなる。もちろん、「知覚品質」やブランドイメージの問題があるので一定の品質の保証は必要だが、それ以上は、不良品が出たときに対応する方が品質コストが安くなる。この典型が携帯電話のソフトウエアである。最近の携帯電話は、発売時にパッチが出ていることは珍しくない。商品の特殊性もあるが、それを顧客もそんなに大きな問題だとは思わない。むしろ、早く対応してくれる、誠実に対応してくれる方が重要だと考えているユーザが多い。

つまり、顧客が求めていない（基本）品質を提供していれば顧客満足には結びつかない。提供者はこのことをよく知るべきである。

ここで注意すべきことは、商品価格が変わらなければ、「必要のないものでも求める特性がある」ことだ。顧客満足にとって、何よりも大切なのは、余計なものを捨てることによって価格は下がるという事実を顧客に伝えることである。

プロジェクトの品質の問題に戻るが、ＳＩプロジェクトの品質にはこの視点が抜けていることが多い。テストは重要であるが、ユーザにとって重要なのはテスト結果ではなく、稼動の保証を如何にしてくれるかだ。そんなに難しいことではない。品質絶対のために、形骸化してしまった、MTBF、MTTRなどの概念を昔どおりにスコープに明確に入れることだ。

もちろん、そこでは、品質絶対などといった思考停止をせずに、仕様、コスト、納期、ライフサイクルマネジメントとの関係をきちんと検討し、バランスをとり、ステークホルダを納得できる答えを導くことが肝要である。

◆セミナー

こんなことを背景に、要求の問題なども取り入れたセミナーを開催します。

〓【開催概要】〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
　◆顧客中心プロジェクトマネジメント　　◆１４ＰＤＵ取得可能
　　日時：2007/11/12（月）10:00-18:00，2007/11/13（火）9:30-17:30
　　場所：ヴィラフォンテーヌ汐留（東京都港区）
　　講師：好川哲人、鈴木道代（プロジェクトマネジメントオフィス）
　　詳細・お申込　http://www.pmstyle.biz/smn/cdpm.htm
〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓

自分から「やらせてください」といっているのができる社員です（サントリー社長・佐治忠信）

【効用】
・ＰＭ体質改善
　　リーダーシップ発揮、計画力アップ、アカウンタビリティ向上、顧客感度アップ、
　　リスク管理力アップ
・ＰＭ力向上
　　リスク対応力向上、プロ意識の向上
・トラブル緩和
　　モチベーション向上

【成分】

◆問題解決プロフェッショナルでは通用しない時代
◆プロアクティブというキーワード
◆シナリオが書けるかが鍵
◆できるプロジェクトマネジャーはマネジメントの目的を考える

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

こういう言葉が、あちこちで見られるようになってきた。ＰＭ養成マガジンでも、「エグゼクティブ版」を作った。

非常に単純に定義すれば、プロジェクト（マネジメント）エグゼクティブは、経営的な立場、あるいは組織的な立場で、プロジェクトマネジメントやプロジェクトを統制する立場の人である。例えば、プロジェクト予算の決定権を持つ人、デッドラインに決定権を持つ人といった意味合いである。つまりは、上位組織のマネジャーだということになる。

しかし、そもそもエグゼクティブとは何かと考え出すと話はややこしくなる。ドラッカー博士の本に「経営者の条件」という本がある。多くの著作を残したドラッカー博士の代表作といえる論文集だ。この論文のオリジナルタイトルは「The effective executive」である。

日経ＢＰ社の谷島宣之さんにお聞きした話だが、多くのドラッカー作品を翻訳した上田 惇生先生によると、会社役員などをさす言葉ではなく、「人（上司）に言われたこと以上の仕事をする人は新人であろうとエグゼクティブという」というところにドラッカーの真意があるという。従って、日本語では、「できる人」という言葉が適切なのではないかというのが上田先生の解釈だそうだ。

コウビルドには、executiveは

An executive is someone is employed by a "business" at a senior level. Executives decide what the business should do, and ensure that is done.

と説明されている。この説明の中のキーワードはsenior levelである。同じく、

The senior people in an organization or profession have the highest and most important jobs.

とある。

この説明をみればドラッカー博士や上田先生の言っていることはよくわかる。

さて、では、プロジェクトエグゼクティブとはどういう人か？プロジェクトに関して、言われた以上のことをやる人ということになる。この意味は多様である。

　・言われた目標以上の成果を達成する人
　・言われたスコープの範囲を超えて活動する人

となる。プロジェクト作業はともかく、プロジェクトマネジメントの作業は自分が担当範囲だといわれている範囲を超えないとなかなかうまく行かない。一般的なプロジェクトにおいて、プロジェクトマネジメントを行っているのは、プロジェクトマネジャー、プロジェクトスポンサー、プロジェクトマネジメントオフィス、シニアマネジャー、プロジェクトメンバーである。プロジェクトマネジメントがスムーズにいくためには、これらのプレイヤーのそれぞれが、自分の担当範囲を超えて、言われた以上のことをやる必要がある。

そのような動きができるプロジェクトステークホルダ（ＰＭＢＯＫでいうところの意味）をプロジェクトエグゼクティブというのだろう。

よく「優等生」という言い方をされるタイプのビジネスマンがいる。問題解決能力が高いビジネスマンである。かつては、企業は優等生をほしがった。今の時代でも優等生が必要なことは間違いないのだが、優等生だけではどうしようもなくなってきた。

優等生では何が足らないのか？

課題を創る能力、課題設定力である。あるいは問題発見能力だといってもよい。先生（上司）が答えが見えないままに前に進まなくてはならなくなってきたのだ。一本被りする商品もあれば、まったく売れない商品もある。ヒット要因を分析してみてもよくわからない。わかった頃には市場のニーズが変わっていて、役に立たない。こんなビジネスの環境の中で、業績をあげる方法が見えなくなっており、走りながらいろいろなことを感じ、考え、先に進んでいくことが求められるようになってきた。

プロジェクトマネジメントでもこの現象は起こっている。プロジェクトというのは基本的には上位組織が課題を作って、プロジェクトマネジャーを中心としたプロジェクトチームに問題解決をさせるものである。

ところが、上に述べた商品開発プロジェクトのように、課題設定の後に、方針が揺らいだり、変わったりすることが多くなってきたし、方針すらも明確にできないようなプロジェクトも多くなってきた。このようなプロジェクトは「背景」と「要求」のみを与えて、プロジェクトマネジャーにバトンタッチする。

また、やたらと制約条件の厳しいプロジェクトが増えてきた。納期が現実的ではない、予算が現実的ではないといったプロジェクトだ。このようなプロジェクトは一見、課題設定ができて、その課題解決をプロジェクトマネジャーに任せているように見えるが、実際は違う。現実的な制約ではないということは、多少の工夫や改善で何とかなるといった話ではない。

つまり、課題設定そのものをしなおさないと課題の背後にある（組織としての）要求を満たすことができない。この手のプロジェクトが実に多くなっている。

いずれの場合も、「優等生」タイプの問題解決に優れたプロジェクトマネジャーではプロジェクトを成功させることはできない。課題設定ができなくては話にならない。

課題を設定するというのは、やれといわれた以上のことをやることに他ならない。いよいよい、プロジェクトマネジャーもやれといわれた以上のことが問われるようになってきたのだ。そのようなプロジェクトマネジャーを目指したいものだ。