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

ミーティングマネジメント本などにもあまり書いていないが、ミーティングによる意思決定をする際にアジェンダマネジメントというのは極めて大切である。

分かりやすいのが、今、国会でやっている道路特定財源の協議だ。新聞の世論調査結果などを見ると、入口でもたもたしていることに対する批判が多いようだが、たぶん、ここが大切なのだ。「暫定税率をなくすかどうか」という協議をするのと、「暫定税率を何％にするか」という協議をするのでは、論点が全く異なる。自民党のいうように、確かに数字上でいえば、％の協議をする中で０％という選択もあるということになるが、存続を「前提」にしているのだから極論として扱われ、まず、この意見が影響を与えることはないだろう。だから、民主党は拘る。

柔道でいえば、組み手のようなものだ。組み手によってそのあと、出せる技が異なってくる。

プロジェクトの中でもミーティングアジェンダの設定が、その後のプロジェクトの流れを決めることは少なくない。にも関わらず、ほとんど無意識のままで進んでいるのが怖いところだ。

以前はミーティングの達人の話を聞くと、例外なく、ミーティングは会議の設定がされた時点でほとんど終わっているといっていた。今は、違う。ファシリテーションをうまくして、多くの意見を引き出し、よい結論を生み出すことこそが重要だという。

もうお分かりだろう？ファシリテーションをいくら上手にやってみたところで、アジェンダの中での話だ。もし、アジェンダを無視した議論をしたとすれば、仮にそれでいくらよい議論が得られたとしてもそれはビジネスとしてルール違反である。

たとえば、スケジュールが遅れてきたときのミーティング。「このあとどうするか」というアジェンダを設定するのと、「遅れてきたスケジュールを如何に回復するか」というアジェンダの設定をするのでは内容も意味あいもまったく異なる会議になることは容易におわかりいただけるだろう。

さすがに、「とりあえず集まろう」という会議は少なくなってきた。これだけでも進歩だと思うが、もう一歩、踏み込んでアジェンダマネジメントをきちんとやるようにすれば、もう少し、プロジェクトの統制ができるようになる。

プロジェクトをコントロールする手段はミーティングしかない。これはミーティングの中でのコミュニケーションでメンバーに指示をしたり、依頼したり、影響を与えたりすることが一つの方法だ。しかし、これ以上に重要なのはアジェンダとマネジメントして、プロジェクトの進め方をしっかりとコントロールしていくことだ。

知り合いのプロジェクトマネジャーに、シナリオを作るときにターニングポイントになるとことではミーティングを想定し、ミーティングアジェンダをだいたい設定してしまうという人がいる。その人のコミュニケーションログを見せてもらったことがあるが、確かに、ミーティングアジェンダを並べてみると、大体、プロジェクトの流れが分かるので大したものだ。

もっとアジェンダの設定にこだわろう！

◆顧客が満足するには対話が必要

「顧客が満足する」にはどうすればよいか？プロジェクト要求定義をしっかりとして、顧客の要求を適切に把握するといったところにすぐに行きつくかもしれない。しかし、これは「顧客を満足させる」ための方法にすぎない。

顧客が満足するには、「対話」が必要だ。

対話とは何か？「コミュニケーション」だと答える人もいると思うが、一般的な意味でのコミュニケーションではない。古代ギリシア時代に多くの哲学者により、弁証法という方法が考えられた。弁証法は、テーゼ（正）、アンチテーゼ（反）、および、それらを本質的に統合したジンテーゼ（合）の３つで思考を深めていく思考方法である。

手軽に弁証法のことを知りたい人は、僕が大ファンである仲正昌樹先生の

仲正昌樹「知識だけあるバカになるな!」、大和書房（2008）

をお勧めしておく。

◆弁証法とディライト

弁証法と顧客が満足するディライトはどう関係があるのか？特に、ディライトという場合、ベンダーが画期的なことを考えて顧客が感動を生めばよいのではないかと思いがちである。

ちょっと脱線するが、リッツカールトンはなぜ、あんなにすばらしいサービスを提供できるのだろうか？全従業員がクレド（credo：リッツカールトンのサービスの基本精神をかいたカード）を持ち歩いているからか？従業員の誰もに、スイーツの宿泊費に相当するような裁量を与えているからか？もちろん、これらの仕組みは大切だが、何よりも大切なのは、顧客が中心にいて、顧客とのやり取り（対話）によってサービスが向上していくからだ。

初回に、期待と実績の話をし、期待と実績をバランスよく向上させていくのが顧客が満足する方法であり、ディライトを提供する方法だと述べた。そのためには、対話が必要なのだ。違う言い方をすれば、サービスを顧客と一緒に作り上げていくことによって、ディライトの提供が可能になる。

◆ウォーターフォール（一方通行）プロセスでは対話はできない

さて、プロジェクトの話に戻ろう。プロジェクトにおいて顧客が満足するにはどうすればよいか？言い換えると対話をするにはどうすればよいか？

ここで必要なのは、ウォーターフォール型のプロセスの精緻化ではない。いくら頑張っても一方通行のウォーターフォールプロセスでは顧客との対話を深めていくことはできない。顧客との対話によってスコープが決まっていくスパイラルプロセスが必要である。

顧客との対話を重視する場合に、何が必要か？対話は顧客から聞き出すことではない。顧客がこうしたい（テーゼ）といえば、それにはこういう問題がある（アンチテーゼ）と反論をする。ここから始まり、プロダクトの利用者は何が欲しいのか？、そもそも、この機能を持つことはどういう意味があるのか？などといった問答を繰り返し、最初は持っていなかった結論を生み出していく。このプロセスが弁証法による対話である。

◆対話には顧客中心型チームが必要

顧客がプロジェクトチームの外部にいる限り、対話は成り立たないのではないかと思う。顧客をプロジェクトチームの中、それも中心に座らせる必要がある。そして、対話を行いながら、顧客がプロジェクトを動かしていけるようにサポートを提供する。

そんなフォーメーションが必要である。このようなフォーメーションはＣＤＴ（Customer Driven Term；顧客中心型チーム））と呼ばれ、今後、プロジェクトマネジメントのやり方の一つになっていくと思われる。

◆プロジェクトマネジメントはディライトを目指す

プロジェクトマネジメントを競争力強化のために導入したのだとすれば、目指すものは極めて明確だ。顧客満足ではなく、カスタマーディライトである。追って説明していくが、プロジェクトマネジメントの目的から展開していくマネジメントの考え方はディライトを実現するために最適であるといってもよい。

この議論をする前に、前回定義した顧客満足について、もう少し、深堀しておきたい。

◆「顧客が満足する」のか、「顧客を満足させる」のか

品質マネジメントにおける顧客満足活動というのは「顧客を満足させる」ことである。顧客を満足させるというのはどこまでいってもサービスや商品の「提供者の視点」での活動である。品質マネジメントにおける顧客満足は基本的に提供者の視点からの品質の一要素であるので、これはある意味、当然のことだ。

極論すれば、どれだけ満足するかについては顧客の「勝手」であり、提供者側はできるだけよいものを提供するように努力する。「結果」として顧客が満足するということだ。ここで「よいもの」の指標の一つに顧客がどれだけ満足しているかがあるが、それは、約束した機能が提供されているとか、約束した性能が実現されているといった品質指標の一つでしかない。

つまり、「顧客が満足する」ものを提供することを目的とする活動ではない。

一方で、顧客満足というのは、顧客を満足させることではない。「顧客が満足する」ことである。まず、ここの意識を変える必要がある。そのためには、「顧客の立場」で考えることが重要だ。たとえ品質であっても、顧客の立場に立った品質を作りこんでいかなくてはならない。

◆品質絶対は思考停止

以前、

品質絶対は思考停止

という記事を書いたが、この話はまさにそうだ。

ベンダー側からみた最高の品質は欠陥ゼロ（ゼロディフェクト）である。しかし、顧客が本当にそれを求めているかどうかは別である。これは納期とのトレードオフとか、製品原価とのトレードオフといったプロジェクト品質の問題を言っているわけではない。顧客はベンダーの考える品質に関心のないと言った方が正確だろう。顧客の立場からの品質は調達している製品により顧客自身の提供するサービスや商品の品質が高くなることである。調達する製品の品質がよかろうと悪かろうと関心がない。

ここを掛け違えて、顧客に提供する製品の品質レベルを決めてもらっているようなベンダーが少なくないが、そのようなベンダーは永遠に顧客の要求を正しく把握して、提供することなどできないだろう。それを行う唯一の方法は顧客の立場で考えることだけだからだ。

プロジェクト品質の議論では、ここにさらに、サービス要求が絡んでくる。つまり、納期だとか、原価、あるいは、コミュニケーション、ライフサイクルマネジメントなどである。そうすると、ますます、顧客が満足するのは何が満たされたときかを考えることが重要さを持ってくる。

◆何のためのプロジェクトマネジメントか？

多くの組織は「顧客を満足させる」ためにプロジェクトマネジメントを行っているが、これではディライトを目指すプロジェクトマネジメントとしては不十分である。ディライトを目指すためには「顧客が満足する」ことを目的としたプロジェクトマネジメントを行う必要がある。

◆顧客満足の定義

ＩＳＯ９０００の２０００年版から品質マネジメント活動の一環として顧客満足の把握が要求されるようになり、製造業やＩＴにも顧客満足という考え方は一挙に浸透してきた。ＩＳＯ９０００がうたっている顧客満足とは、

　　顧客の要求事項が満たされている程度に関する顧客の受けとめ方

と定義されており、かなり、狭い意味でつかわれている。もう一つ、多くの企業に顧客満足という方向づけをしている活動にボルドリッジ賞を手本にして作られたといわれる日本経営品質賞があるが、この活動では「顧客満足の明確化」が求められ、顧客満足を

　　顧客に期待以上の価値が提供されたときの、顧客の心理状況

と広い意味で捉えている。経営管理と品質管理という違いがあるので、このような違いが出てきているものと思われる。

◆顧客満足の評価

顧客満足の評価としては、リチャード・オリバー（Richard L.Oliver）が提唱している「期待不確認モデル（expectation - disconfirmation model）」がもっともよくつかわれている。このモデルでは、期待（Ｅ）と実績（Ｐ）に注目し、その大きさで顧客満足を評価している。

すなわち、

　Ｅ＜Ｐ　満足
　Ｅ＞Ｐ　不満足

と定義し、顧客満足度の把握（顧客満足度調査）においては、この関係を調査することに主眼を置いている。

このモデルを使うと、定義のところで述べた品質における顧客満足と、経営（製品やサービス）に対する顧客満足が異なることがよく分かる。ＩＳＯ２０００における顧客満足（ＩＳＯ９０００の顧客満足）というのは、Ｅ＜Ｐの状態ではなく、Ｅ＝Ｐである。Ｅ＜Ｐだといわゆる過剰品質ということになる。これに対して、日本経営品質賞では

　Ｅ≦Ｐ

の状態を顧客満足だと言っていることになる。

◆顧客満足の背景

さて、品質マネジメントにおける顧客満足にしろ、経営活動における顧客満足にしろ、その背景にあるのは、顧客が不満を持っているという前提である。ある意味で、これらの活動は顧客を満足させるための活動というよりは、顧客の不満を解消するための活動だといった方が適切である。

ところが、最近の傾向として、顧客満足を不満足の解消ではなく、満足を高めるととらえる考え方が普及してきつつある。これは従来の顧客満足と区別するために、カスタマーディライトと呼ばれる。カスタマディライトはオリバーのモデルでいえばＥ＜Ｐを言っているわけだが、単なるＥ＜Ｐではない。顧客が期待する以上の品質やレベルの製品やサービスを提供することで、顧客に「歓びや感動」を与えることだと定義される。

つまり、顧客満足におけるＥ＜Ｐとディライトは似て非なるものだと考えた方がよい。そのポイントはＥのレベルにある。

◆顧客の期待

オリバーモデルでＥ＜Ｐを作る方法の一つは顧客に高い期待を抱かせないことである。特に日本においては競争が規制されていたため、実際にいまでもそのようなマーケティング戦略を取る企業は多い。また、品質の面から顧客満足をとらえていく場合には期待を大きくすること自体が好ましくないと考える。これでは、仮にＥ＜Ｐが実現できても顧客の不満足心理は残る。

顧客はＰに対する理想（あるべき姿）を持っているからだ。

これに対してディライトというときの期待Ｅは、文字通り、顧客自身の体験を通じて想像しうる目一杯の期待である。そのような期待に対して、Ｅ＜Ｐのパフォーマンスを実現するのがディライトである。

違う言い方をすれば、よい意味で顧客の予想外のサービスや製品を提供することである。予想外であるゆえに感動するのだ。このように期待を位置づけるときの最大のポイントは、人間は「二度目は感動が薄くなる」ということである。つまり、一度、体験をすることにより、目一杯の期待値は高まる。

この関係をよく理解した上で、プロジェクトマネジメントやプロジェクト品質における顧客満足とは何かという問題を考えてみる。

道路特定財源の問題もいよいよ、大詰めになってきた。なにもなければこのまま、暫定税率は一旦廃止になる。

この１か月くらいを見ていてつくづく思うのは、「変えない」ことを前提にした議論をしていることだ。自民党や自治体の言っていることは、他のことは変えないで、この部分だけを変えるという前提で議論をしている。

他のことは何も変わらず（変えず）、暫定税率分がなくなると、財政的な穴が空いて（予定している来年度予算が足らず）混乱が起こる。これは当たり前のことだ。新規の道路工事を一切やらないとしても、混乱は収まらない（まだ、足らない）。

だから、暫定税率を無くす（仕組みを変える）などあってはならないという論法である。

もちろん、政治的な配慮もあってそのような論法を取っているのだと思うが、これと同じ論法をみなさんの組織の中で聞いたことはないだろうか？あるいは、みなさんは使っていないだろうか？

たとえば、こういう論理がある。

計画書を丹念につくると、プロジェクト作業の着手までに時間がかかり、顧客に迷惑がかかり、かつ、プロジェクトリソースの活用もスムーズにいかなくなる。だから、計画書をあまり時間をかけてつくることは、混乱のもとだ。いままで程度に作っておけばよいのではないだろうか？

これは正しいのだろうか？

朝日新聞を見ていたら、また、道路工事予算の問題がでていた。

●国土交通省が所管する道路・街路関連の国直轄事業や補助事業のうち、０２年度以降に完了・実施中の１１７６事業の過半数で、当初計画時より事業費が膨らんでいる。

●最終事業費が１００億円以上にのぼる道路・街路関連事業は１１７６、判明した当初事業費の総額は約４０兆６千億円。このうち当初事業費を上回ったのは５９７事業で、総額は約４８兆４千億円（差額　７兆８千億）。

●当初の３倍以上に膨らんだのは２１事業。理由は、「工場や病院、ガソリンスタンドなどの移転費用が増えた」「想定していなかったもろい岩質による崩落が発生した」など。用地補償費や工事費の見積もりが結果的に不十分だった。

●ひどい事例。青森県「白銀市川環状線」事業は完了が１５年も遅れたうえ、当初の約２４億５０００万円が、５．８倍の約１４２億２０００万円に。兵庫県主体の「阪神本線連続立体交差事業」は約１５２億８０００万円が約８３９億８０００万円に。

少し前に

計画されないプロジェクト
https://mat.lekumo.biz/ppf/2008/03/post-651a.html

という記事を書いたが、ここまでとは思わなかった。一応、工事積算基準、用地補償基準などはあるわけだから、ここまで来ると、費用対効果の数字を作るために、追加発注を前提にして当初見積もりを取っているのではないか？と疑ってしまう。

もっとも、仮にそうだとすれば倫理的な問題は感じるが、プロジェクトをコントロールできているという意味ではまだましかもしれない。これが無作為の数字であれば、事業者当事者としての能力に疑いを持たざるをえない。

前の記事でも述べたように、このような実態を作っている最大の原因は

　「スケジュールありき」

だろう。背景にあるのは、道路特定財源の設置当初からそうであったように道路が欲しいのではなく、工事がほしいという景気対策である。ゆえに、何が何でも計画通りに着手する。だとすれば、これでもまだ、よくやっている方だと言えなくもないか。

この構図は、企業のプロジェクトにもたくさん見られる。っていうか、これを裏返ししたのが、企業プロジェクトの実態だと考えてもよいだろう。道路工事を請けるゼネコンは、まったく準備ができていない状況で受注し、プロジェクトを走らせることになる。他の官庁でも同じだ。ＳＩ案件で予算だけつけて、仕様を決めないままで着手している例は少なくない。

あるＳＩ企業では、内部調査で失敗プロジェクトの８０％はスケジュールありきで実施していることがわかったそうだ。その大半は、「準備不十分なままで時計をスタートさせ、実質的に計画よりはるかに短い時間で完成させようとして品質の問題を起こしたか、納期遅れを起こした」だそうだ。

プロジェクトのスケジュールの要望は顧客が出すことが多いので、これを顧客側の問題に転嫁する人が多いが、実際に顧客の意見を聴くと、１０年使うシステムで、１０年間不適合で悩むよりは、１年カットオーバーが遅れる方がはるかにましだという意見が圧倒的に多い。

っていうか、要件定義ができないままでトラブって３年かかるよりは、プロジェクト開始を１年遅らせてでも要件を確定して、１年でやった方が、よほど早く、よいものができるだろうという短期的な話のような気もするが、、、

なんにしても、顧客側の問題だとかいって、ベンダーが言われたままで流されて、顧客ときちんと向き合った話をしていないだけだ。

つまり、スケジュールありきはほとんどは自分たちの事業成果（売上）の都合である。道路の比喩でいえば、サービスを提供することが目的ではなく、売り上げを上げることが目的なのだ。ゆえに、何よりもスケジュールが重要になる。国が景気対策で工事を作るのと、本質的に違いはない。

だからそんなプロジェクトのやり方は間違っているというほど、単純な話ではない。道路であれば政策の問題であり、企業であれば戦略の問題でもある。むしろ、問題なのは政策や戦略の中で成果に関する部分だけがひとり歩きしてしまって、その実現に必要な組織能力を持っていないことではないだろうか？実際に、道路についていえば、欧米の企業とはずいぶん生産性が異なるという話をよく耳にする。これは道路をつくる能力の違いだけではなく、労働政策とか、国土政策とか、総合的な政策の質の違いだと思われる。企業においても同じで、単にシステムを作る生産性の違いではなく、ＨＲＭ、組織マネジメントなど、さまざまな要因がシステム構築の生産性に表れているように思う。

ここをなんとかしなくてはならない。

エンジニアはプロセスが好きである。ある意味で当り前だ。工業製品であっても、ソフトウエアであっても、工芸品であっても、作り上げるまでのプロセスは必ずあるからだ。逆にいえば、プロセスがないとすれば再現性がなく、エンジニアリングとはいえない。

エンジニアからプロジェクトマネジャーになっていくとき、一皮むけるというのは、この信仰ともいってよいプロセスへのこだわりを捨てることだろう。

たとえば、ＰＭＢＯＫの４３のすべてのプロセスはインプットとアウトプットでつながっている。つまり、プロジェクトマネジメントを一つのプロセスで表現することが可能だと言っているようにも思える。たしかに、プロセスの「インプット→処理→アウトプット」の定義には当てはまっている。しかし、処理の内容をみればそうではないことは一目瞭然だ。処理の内容は思いっきり属人的なものがふんだんにある。というか、属人的ではない処理（ツールと手法）はほとんどない。したがって、形式的にはプロセスにしているが、再現性はほとんどない。

ＰＭＢＯＫはまだしも、プログラムマネジメント標準となると、技法とツールはすべてのプロセスに対してひとつである。つまり、インプットとアウトプットを明確にしているだけで、他は何も定義していない（これは、次のバージョンでは変わるらしいが、ＰＭＢＯＫレベルのツールと技法を指定するのは不可能だろう）。

したがって、ＯＰＭ３やＰＭＣＤＦといったメトリクス系の標準を使って、プロセスの品質を均質化させることを目指しているのだ。

これがマネジメントであり、正解がないということだ。ここで、よく認識しておくべきはこのような背景であるにも関わらず、ＰＭＩがプロセスに拘る理由はアカウンタビリティの確保だと思われる。仮に処理がなくても、インプットとアウトプットを明確にしておけば、アカウンタビリティを高めるには大変有用である。

これに対して、ＩＰＭＡはコンピテンシーを中心に標準化をしようとしている。プロセスを決めるのではなく、マネジメント行動として何をすべきかということを標準化しようとしている。

結果として、ＰＭＩとＩＰＭＡの標準というのは同じところに落ち着くのではないかと思うが、このポリシーの違いは大きいし、重要だ。トップダウンの管理をするために最も重要なポイントはアカウンタビリティの確保である。アカウンタビリティを確保した上で、あとは状況を見ながら指示していく。これが米国流プロジェクトマネジメント。（マネジメントの）行動規範を作っておき、それを実行させることで成果を生み出す。これが欧州流プロジェクトマネジメント。

もちろん、どちらの地域でも多くの企業はグローバル化されており、こんなステレオタイプの議論ができるような状況ではないのだが、なんとなく、イメージに合うのではないだろうか？

さて、日本はどうか？僕は米国流でも、欧州流でもないように感じている。日本には日本流がある。それは、何か。仕組みを作って成果を出すことだ。仕組みとはシステムである。システムとはプロセスと行動規範を合わせたものである。これが日本人の智慧だと思う。

プロセスでも行動規範でもなく、仕組み作りのプロジェクトマネジメント。エンジニアからプロジェクトマネジャーに脱皮するとはこの脱皮ではないだろうか？

◆プロジェクトリーダーのやる気はメンバーのやる気

これ自体が僕の持論かもしれないが、プロジェクトメンバーをやる気にさせるには、プロジェクトリーダー（マネジャー）がまず、やる気になることが必要だ。

たとえば、ステークホルダからのやる気を削ぐコンタクトは自身が全部引き受けるというプロジェクトマネジャーは結構多い。一種のメンタリング行動だと思うが、これを喜々としてやっているプロジェクトマネジャーも結構いるが、多くの人はそれで自身は疲れ切って、やる気をなくしている人も少なくない。そんな様子をはたから見ていて、メンバーがやる気になって自分の仕事をやることはあまり考えられない。

これでは何をやっているかわからない。リーダーが腐れば、メンバーが腐り、チームが腐る。間違いなくこの伝染はある。

一方で、一人だけテンションが高いなどと揶揄されながらも元気一杯のリーダーがいる。こういうリーダーに出会うと最初は引くメンバーが多い。そこから先はリーダーの力量の問題もあると思うが、ずっとそんなふるまいを続けていると、馴染んでくることがある。慣れてくるのではない。なんとなくそんなものかなと思うのだ。これこそがやる気が伝染した瞬間である。

素晴らしいリーダーで、瞬時にチームの雰囲気を変えるような人もいるが、意外と、最初はメンバーに引かれてもかまわずそのふるまいを続けるリーダーのチームの方がトータルのパフォーマンスは高かったりするものだ。

しかし、リーダーが一定のやる気を持ち続けるのはそうたやすいことではない。

◆プロジェクトリーダーのやる気の源泉？

リーダーに「どのような環境になればやる気が出ますか」と質問したときに帰ってくる３大回答は

（１）やりがいのある（評価される）プロジェクト
（２）権限（好きなようにできる）
（３）優秀なメンバー

である。

ところが、本当にこれだけ準備すると、やる気を出して仕事をしてくれると思うと大きな間違いだ。

確かに最初は張り切って、絶対成功させますなどと宣言するのだ。

ところが、どれだけ優秀な人を集めようと、途中に挫折のないプロジェクトなど、めったにあるものではない。トラブルになったときに、多くの人は

（１）やってみたら全然面白くなかった。重要だと言っている割には何もしてくれない
（２）表向きは権限があることになっているが、実際には上の意見に逆らえない
（３）あいつ、みんなが評価しているけど、ぜんぜん、できない

と豹変する。条件が３拍子そろうことなどまずないので、これが３つ揃うこともないが、ひとつひとつの例をあげれば枚挙にいとまがない。

◆結局は本人のとらえ方次第

どこに問題があるのか？

やりがいがあるかどうかは、本人が決めることだ。ここに「評価」といった「邪念」を持ち込むので、混乱するのだが、評価されるかどうかというのは結果であって、やりがいがあるかどうかというのは本人のプロセスなのだ。端もかけられなかった商品開発が伝説に残る成功になったなどよくある話だし、一見さんなので適当に押し付けられたシステム開発が顧客の大満足を得てリピートにつながることも珍しいことではない。評価を考えても仕方ないというつもりはないが、少なくともそのプロジェクトの開始前の評価など、どうでもいい話であることは間違いない。

（２）についてはもっとひどい勘違いである。権限を持つ経験がなかった人に権限が委譲されても、そう簡単に使えるものではない。ましてや、自分が権限を持ったからといって周りが動いてくれるわけではない。権限は「与えられ、持つもの」ではなく、「奪い、使うもの」だ。

たとえば、人事権があれば人をプロジェクトに引き込んだり、メンバーとして動かすことができると思っているプロジェクトマネジャーが多いが、そんなプロジェクトマネジャーに限って権限に従って動いていない。よいか悪いかは別にして、日本の組織というのはそんなガバナンスの効く組織ではないのだ。権限シンドロームにかかっているだけだ。

つまり、権限を持っても、その権限を自身がうまくつかわなければ何も変わらない。（２）はそれがうまくできないプロジェクトマネジャーの愚痴にすぎない。

（３）は勘違いの極みである。人の能力には絶対値がある。その意味で、できるできないもある。しかし、ある仕事で、一人ひとりの人の能力を引き出すのはリーダーの役割だ。日本の管理職はほっといて成果を出してくれる人とできると言っていた。こういうことをいうプロジェクトマネジャーは１００％この傾向がある。その意味で勘違いだ。

◆やる気を引き出すスタンス

ぼろくそに書いたが、３つの条件がやる気の源泉になっているというのは直観だろうし、その人にとって間違っていないのだと思う。だとすれば話は簡単だ。これらが現実のものになれば、プロジェクトマネジャーはトラブルになってもやる気を維持しながら切り抜けていける。つまり、

（１）やりがいがあると思う
（２）もっとうまく与えられた権限を使うことができるはずだと思う
（３）もっとうまくメンバーの能力を引き出すことができるはずだと思う

の３つでプロジェクトマネジャーのやる気は維持されることになる。こんな持論はどうだろうか？

◆メンバーのやる気の源泉はリーダーのやる気

こんな記事をＰＭ養成マガジンのマイナーなコーナー「ＰＭコンピテンシーを高める一冊の本」に書きました。

=====

プロジェクトマネジャーで、メンバーのやる気を気にする人が多いが、それよりも問題なのはプロジェクトマネジャー自身のやる気だ。

常にハイテンションのプロジェクトマネジャーだとメンバーがつかれてしまうといったことを言う人もいるが、プロジェクトマネジャーにやる気がないのに、メンバーがやる気まんまんなどといったプロジェクトなどまず、お目にかからない。

プロジェクトマネジャーは自身のやる気をうまくコントロールしなくてはならない。

=====

これは、神戸大学の金井壽宏先生の書かれた「やる気攻略法」という本の書評として書いたものです。この本では、モチベーションの高め方を実践家の事例を通じて考えています。

ワークモチベーションは誰にとっても身近なテーマで真剣に仕事に取り組んでいる人であれば、必ずといってよいくらい持論を持っているテーマです。

みなさんは、プロジェクトリーダーとして自身の持論を持ち続けるにあたって、どんな持論をお持ちですか？

◆好川のリーダーとしてのモチベーションを高めるための持論

ちなみに僕は、自分の活動に常に意味付けをしながら、プロジェクトを回していくようにしています。「やらされ」のプロジェクトでも考えてみれば、何か意味があるはずです。

それは、プロジェクトマネジャーとしてのキャリアを深める、スキルを向上させるといった個人的なことではありません。

僕はキャリアアンカーが僕のキャリアアンカーは「創造」ですので、よけいにそう感じるのかもしれませんが、自分がこのプロジェクトで何らかの社会貢献できるということで、モチベーションをコントロールしています。

僕のセミナーを聞かれた方は、僕が異様に「プロジェクトの目的」にこだわっていると感じられている方もいらっしゃると思いますが、これも根っこは同じ話です。

（注）キャリアアンカーとは、キャリアを選択する際に最も大切な他に譲れない価値観や欲求のことで、有名なのは、エド・シャインの提唱した５つである。
自律：組織に属さず、何事も自分の力でやろうとするタイプ
創造：自分自身の何か（製品、会社、サービス）を生み出したいタイプ
技術・職能：スキルを中心に自分キャリアを作っていくタイプ
安定：キャリアの安定に何よりも関心を持つタイプ
管理：組織の中で、より管理・統制できる地位への出生に関心を持つタイプ

◆みなさんの持論を共有しましょう

このテーマについて、みなさんがお持ちになっている持論を共有しませんか？コメントに書き込んでもらえるか、あるいは、好川まで直接、メールをください。メールの場合は公開してよいかどうかも書いておいてください。

ここで、みなさんの背中をおすために、持論とは何かを整理しておきたいと思います。

金井先生は、ビジネスインサイト誌で、「持論とは」ということでこんな定義をされています。

=====

持論とは、学者が構築する公式の理論とは異なり、実践家が意識的にせよ無意識にせよ実際に用いているセオリー（theory-in-use）を指す。

金井壽宏「ワーク・モティベーション論における古くて新しい展開 －経営学における持（自）論アプローチのモティベーション論への適用－」、ビジネスインサイト、No.55　より抜粋

=====

多くの皆様は、モチベーションの問題に限らず、なにがしかの持論をお持ちではないかと思います。

持論のイメージがわかない人はぜひ、この本を読んでみてください。多くの実践家のモチベーションに関する事例が紹介されています。

「やる気要塞」を攻略しよう！

どうすれば持論を整理できるか、見当のつかない人は以下の記事を読んでみてください。持論を発見するステップになりうるエクスサイズを紹介してあります（金井先生の作られたものです）

メンバーのモチベーションの源泉を知る

編集というと、本や雑誌、新聞の編集のイメージがあるが、「編集工学」の提唱者で松岡正剛氏の編集のイメージは似て非なるものである。松岡正剛氏には膨大な著作があるが、その中で編集について言及した部分をいくつか抜き出してみよう。

もっとも有名な表現は編集とは「情報の新しい関係性の発見」というものだろう。「知の編集工学」での表現。また、「知の編集術」では「コミュニケーションの充実と拡張に関する方法」だと言っている。この本では

１）編集は「文化」と「文脈」をたいせつにする
２）編集はつねに「情報の様子」に目をつける
３）編集は日々の会話のように「相互共振」をする

と、かなり、具体的方法論に踏み込んでいる。

また、「日本数寄」には「眼の編集」という言葉が登場する。

縄文の縦櫛が弥生の横櫛に変わっていったのも、片輪車模様が流行したり小袖が流行したりするのも、よくよく見ればそこには文化的な編集のプロセスというものがあった。それはいわば「眼の編集」というものである。

この眼の編集という概念はえらく深いなあと思うが、いずれにしてもこれらの表現から雑誌や新聞の編集とは違った世界だということはおわかりいただけるだろう。

プロジェクトマネジメントの本質は編集にある。プロジェクトの周囲に渦巻く要素の間に、関係性を発見していく仕事である。

編集でいう情報はプロジェクトではなんだろうか？プロダクト（成果物）だととらえてしまうと、編集だというのは極めて狭義になってしまう。プロダクト以外に、人や組織、また、情報そのものも編集の対象である。これらを要素という。

たとえば、情報を与えることによって人を動かし、組織を動かす。そして、プロジェクトが動き、成果物も動く。これが「相互共振」である。

文化や文脈に相当するのもは、プロジェクトの背景であり、戦略であり、シナリオである。これらを重視しながら、計画を作っていく。計画とは要素間の関係を示すものであり、要素間の関係を明確にしながら、プロジェクトを進めていく。これは或る意味で情報の編集である。この際に重要なのは共振を引き起こすことである。共振を引き起こすことにより、各要素の本質が明確になり、その関係づけを適切に行うことが可能になる。

プロジェクトマネジャーには編集力を持ってもらいたい。