プロジェクトの「補助線」

【補助線】上司に任せる

本ブログは移転しました。こちらをご覧ください。

　自身が権限を持たないので、できることしかできない

というプロマネがたくさんいる。これはある意味で真実だ。これから内部統制も厳しくなっていく中で、ここをはずすことはできない。

ただ、ひとつ考えてほしいことがある。

みなさんは、部下に任せるということは普通にやっていると思う。では

　なぜ、上司やステークホルダに任せないのか？

部下に任せることと、上司に任せることの間には２つの決定的な違いがある。ひとつは、部下に任せる多くのことはプロマネ自身が実行することもできる。しかし、上司に任せることの多くは上司にしかできないことだ。

上司にしかできない理由は、まれに業務遂行能力、スキルなどに依存するが、ほとんどのケースは権限の問題である。つまり、業務そのものはできるのに、権限がないからできない。これがプロマネが権限にこだわるひとつの理由にもなっている。

もう一つの違いは、部下には程度の差こそあれば、命令、あるいは指示、あるいは指導ができる。しかし、上に任せる場合にはこれはできない。どのようにやるかは上司の判断に任せる必要があるし、結果の是非についてもある程度上司に任せざるを得ない。

整理すると、上司に任せる場合には

（１）自身はできないことを任せる
（２）判断そのものを任せる

の２つが求められる。

こうなってくると、「お山の大将」的なリーダーは到底、任せようなどとは思わない。結果、何をするかといえば

（１）できる範囲でやる
（２）あなたの責任でやってくれと投げ出す

である。いずれも箱からでないでできることだ。これでは話にならない。

では、どうすればよいか？答えは簡単だ。

プロマネ（自身）が考えているとおりに、上司が「自発的に」動くようにする

ことだ。これには２つの問題がある。ひとつは、上司にそのように動こうと思わせるにはどうしたらよいかだ。もう一つは、上司が考えたことが本当にできるかどうかだ。

後者についてはある意味で、メンバーに任せるよりは簡単だ。プロマネの上司といえばおおよそ課長級で、課長級となるとそれなりに能力がないとなれないからだ。

ここで、プロマネの中には、上司の「無能さ」を批判する人も少なくないが、フェアな立場できいていると、だいたい、前者がきちんとできていない。したがって、思った通りには動いてくれず、その不満を言っている人が多い（もちろん、中にはピーターの法則を絵に描いたようなマネジャーもいるけど）。

ということで、上司に任せるための問題は、

上司をどのように動かすか

にかかっている。このときに、正論を言えば動く（べきだ）と思っているようでは、永久に動かすことはできないだろう。つまり、説得などの何の役にも立たない。上司には上司のキャリアがある。上司だってあなたと心中したいとは思っていないのだ。

そこで出てくるキーワードが「影響力」である。影響力が発揮できれば、上司は動く。もちろん、上司以外のステークホルダにもこれまで述べてきたことはすべて当てはまる。

上司に任せるために影響力を身につけよう！これも一種にリーダーシップである。

【補助線】ミーティングアジェンダでプロジェクトをコントロールする

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

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

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

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

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

【補助線】顧客が満足するには対話が必要

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

をお勧めしておく。

◆弁証法とディライト

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

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

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

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

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

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

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

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

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

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

【補助線】「顧客が満足する」のか、「顧客を満足させる」のか

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

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

◆品質絶対は思考停止

以前、

品質絶対は思考停止

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

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

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

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

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

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

【補助線】顧客満足とは何か？

本ブログは移転しました。こちらをご覧ください。

◆顧客満足の定義

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

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

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

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

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

◆顧客満足の評価

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

すなわち、

　Ｅ＜Ｐ　満足
　Ｅ＞Ｐ　不満足

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

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

　Ｅ≦Ｐ

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

◆顧客満足の背景

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

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

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

◆顧客の期待

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

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

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

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

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

【補助線】変わると混乱が起こる？

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

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

【補助線】スケジュールありきのプロジェクト

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

少し前に

計画されないプロジェクト
http://people.weblogs.jp/ppf/2008/03/post-651a.html

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

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

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

　「スケジュールありき」

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

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

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

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

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

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

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

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

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

【補助線】プロセス、行動規範、仕組み

※本ブログは移転しています。こちらをご覧ください。

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

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

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

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

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

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

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

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

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

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

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

【補助線】プロジェクトリーダーをやる気にさせるもの

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

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

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

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

である。

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

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

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

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

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

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

どこに問題があるのか？

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

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

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

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

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

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

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

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

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

【補助線】計画されないプロジェクト

本ブログは移転しました。こちらをご覧ください。

◆計画の位置づけの違い

テレビの道路特定財源の議論を見ていたら、なるほどなと思ったことがある。

日本の道路のコストがなぜ高いのかという議論なのだが、欧州では道路は計画に時間をかけて実現性を持つように徹底的にやる。その代わり、計画が終われば、「計画通り」速やかに工事計画を作り、工事をするので、結果として、企画から供用までの時間は欧米の方がはるかに短いという。

ところが日本は、最初の計画は作るが、実現性は工事での調整任せ。着工すると、できるところから予算をつけてやることになる。ゆえに、とびとびに作り掛け道路が点在しているのだそうだ。

なるほどなあと思った。この問題で、以前、テレビで国道８号線の高架化工事のいきさつの特集をやっていた。一応、計画を作って、タウンミーティングをやる。何回かやっているのだが、住民のコンセンサスは得られていないどころか、報道を信じれば圧倒的に反対住民が多い。にも関わらず、今後もタウンミーティングを続けながらも、計画通りに着工手続きに入り、進めていくというのだ。

基本計画の調整ができていないままで、工事にバトンを渡している。

これでは、いくら、工事計画を精緻に作ろうとその通りに実行できるはずはない。実際に工事を始めると、現場では想定していなかった障害が飛び出してくる。

◆なぜ、コストが高くなるのか？

プロジェクトマネジャーのみなさんなら、まあ、これは最後まで計画通りにいかないと思うのではないだろうか？

では、プロジェクトオーナーは何をやろうとしているのか？とりあえず、キックオフする。そして、比較的、反対住民の少ない箇所から着工し、既成事実を作って、反対住民が多いところを切り崩していく。

ただし、この切り崩しが、当初予算どおりにできるはずがないのは、自明の理だ。既成事実化すれば、土地が上がるし、何らかの補償をするにしても、補償金を上げることが「合理性」を持ってくる。当然、当初計画よりはるかに大きなコストがかかる。役人がリスク管理をしていないはずはないので、おそらく、確信犯でやっているのだろう（リスクをとっているわけではない。リスクを識別して無視しているのだ）。

当然、工事コスト自体もよけいにかかるのも明らか。ところが、ここでも既成事実が意味を持つ。「今、止めてしまうと、今までの投資はすべて無駄になる」というロジックで押し切れるからだ。

◆ＳＩプロジェクトのロジック

実は、このロジック、ＳＩプロジェクトで行われていることに瓜二つ。ポイントは以下の３つだ。

・徹底的に基本計画をせず、大雑把な基本計画でとりあえずプロジェクトを始める
・問題がでてきたら、予算の積み増しを要求し、継続する
・今、やめたら、これまでの投資が無駄になると継続の合理性を主張する

この構図は、ＳＩベンダーを非難しているように聞こえるかもしれないが、違う。３つとも、ユーザ側のプロジェクトマネジャーにとってもそうするメリットがあり、利害が一致するのだ。

計画を詳細化すればするほど、意志決定しにくくなるし、時間がかかる。また、変更がしにくくなる。変更をするのは、担当者にとってみれば一生懸命仕事をしていることのエビデンスだと言えなくもない。そして、中断しないのは一蓮托生である。

このような利害の一致があるがゆえに、止められない。そして、大けがをする。

◆ユーザ側の理性と計画

ただ、ユーザ側に「理性」があると、こんなことにはならない。先日の新聞にこんな記事が載っていた。

=====（抜粋開始）
静岡県を地盤とする地方銀行のスルガ銀行（本店・沼津市）は６日、銀行業務に関する基幹コンピューターシステムの開発を契約通りに行わなかったとして、開発委託先の日本ＩＢＭ（本社・東京都港区）に約１１１億円の損害賠償を求める訴訟を東京地裁に起こした
　関係者によると、スルガ銀行は２００４年９月、銀行業務全般にかかわる基幹システムを刷新するため日本ＩＢＭとシステムの開発契約を結び、開発費用の一部はすでに日本ＩＢＭに支払っている。ところが、新システムの稼働を予定していた０８年１月を過ぎても稼働のめどは立っておらず、開発費用も当初の予定額より膨らんだため、支払った費用の返還などを裁判で争うことにしたという。
　スルガ銀行は日本ＩＢＭとの開発契約は破棄したと主張しているが、システム開発自体は引き続き進めるとしている。
　日本ＩＢＭの広報担当者は、「このような訴えを起こされるのは異例だ。訴状が届いていないので詳細は分からないが、スルガ銀行との契約上の義務は果たしたと認識している」と話している。
=====（抜粋終了）

たぶん、記事の内容からすれば、契約の方法などにも問題があるように感じるが、ここで区切りをつけようとしたのは、まさに「理」だとも感じる。

ちなみに、スルガ銀行は横並びしないことで有名な地銀だ。何よりも、スルガ銀行を有名にしたのは、バブルの時に踊らなかった数少ない銀行であったこと。同族経営の強みだと言われているが、まあ、経営や、戦略を感じる企業である。

この記事は、ＳＩプロジェクトのプロジェクトマネジメントは日本で活動しているベンダーとしては頭一つ抜けているという評判のＩＢＭであることがもう一つのポイントだろう。これ以上は憶測になるので控えるが、このような事態が発生するのも、道路の問題と同じく、「計画」という作業の「位置づけ」に問題があるのではないかと推測される。