PMstyleプロデュース

◆いくつ、当てはまるだろうか？(2007/07/06)

・プロジェクトマネジメントを導入すれば、プロジェクトマネジャーの行動が変わると思っている

・プロジェクトマネジメントを導入した後に、適応するようにプロジェクトマネジャーを教育している

・プロジェクトへのインセンティブ制度により、プロジェクトマネジャーやメンバーのモチベーションが高まると思っている

・事業部長がプロジェクトマネジメントにコミットしている姿勢をみせれば、プロジェクトマネジャーやメンバーはついてくると思ってる

・プロジェクトマネジメント制度の運用に対して、プロジェクトメンバーの抵抗に合う

・プロジェクトマネジメントルールの推進は問題が見つかったときにモグラ叩き的にやっている

こう書くと何かあるんと思うだろうが、ひとつひとつを見ていくと、そんなにおかしなことではない。

これらは、著者がこれまでプロジェクトマネジメントの導入の中で見てきた典型的な落とし穴である。このような考え方、やり方をしていると、いずれもうまく行かない。

◆当事がいない！？

プロジェクトマネジメントの導入においてもっとも問題なのは、「当事者意識を持った人」いないケースが多い人だ。

一応、ＰＭＯがプロジェクトマネジメント推進の掛け声をかけている。しかし、ＰＭＯがプロジェクトマネジメントの当事者意識を持っていることはあまり多くない。
他人事というと語弊があるかもしれないが、やっぱり、やるのは自分たちではないという意識はあることが多い。プロジェクトマネジャーの負荷だとか、心情的な点は考える。しかし、逆にいえば、これこそ、当事者意識以外の何者でもない。負荷がかかってもうまく行くと思っていればその通りにやらせるだろう。

プロジェクトマネジャーに当事者意識があるかというと、そうでもないことが多い。
プロジェクトマネジャーにしてみれば、ルールに従ってやればうまく行くという確信を持っていないことが多い。

◆「上がやれといっている、、、」

では、なぜ、やるのか？ＰＭＯとプロジェクトマネジャーの結節点にあるのが、プロジェクトスポンサーであったり、シニアマネジャー、組織によってはエグゼクティブマネジャーである。ＰＭＯは彼らがやれといっているからやってくださいという。テクニカルな部分、つまり、どのような手法を導入するか、あるいはどのようなメトリクスを設定するかという部分では、一定の責任を取らざるを得ないとは思っている。
しかし、それを推進していることについては、自分たちが結果に対して責任をとろうなどとは微塵も思わない。

つまり、商品の品質の責任は自分たちにある。しかし、商品を使うのを決めたのは自分たちではないので、使った結果に対しての責任は取れない。こんなＰＬ法も真っ青な恐ろしい話がまかり通っている。

プロジェクトマネジャーも自分たちがよいと思ってやっているわけではない。上がやれというからやっている。やり限り最善は尽くすが、責任は取れないとくる。

では、そこで結節点になっている人たちは責任を持つのか？ここで多くの人はコミットすらしようとしない。が、コミットをしていても、細かいことはわからない。現場に任せるとなる。つまり、責任は取らない。

◆定着化が先決

ただし、事業責任はあるので、プロジェクトが行き詰まってくると、介入する。ところが、その介入はプロジェクトマネジメントのような合理性がある方法ではなく、過去の経験に基づいた腕力にモノを言わせる方法であることが多い。これを何回かやっていると、プロジェクトマネジメントって本当に役に立つのかという疑念が湧いてくる。

それが、プロジェクトマネジャーにも伝播し、ＰＭＯが導入したものに対するサポタージュが正当化される。すると、ＰＭＯは何か手を打つ必要性に迫られ、定着もしていない手法の問題点をあげつらい、新しい取り組みを始める。

この悪循環があちこちの組織に渦巻いている。この悪循環を作り出しているのが冒頭に述べたような落とし穴である。

このような落とし穴に陥ることなく、定着化を図るのが、チェンジマネジメントである。定着化のためには、冒頭に述べたような落とし穴に陥ることなく、着実に、全員がコミットする普及活動を行っていかなくてはならない。

◆もう一つの課題

もう一つの課題がある。それは上に述べたような悪循環が起っている最大の理由であるプロジェクトスポンサーや組織マネジャーの関与の方法を変えることである。実は上のようなケースは、そもそも、彼らがプロジェクトマネジメントの効果を信用していない。

だんだん、わかってきたのではないかと思う。要するに、プロジェクトマネジメントが効果的かどうかというのは、自分たちの問題である。そして、いくらプロジェクトマネジャーが思っても、いくらＰＭＯが思ってもそれだけではダメだ。組織の一人ひとりがそのように思って初めて効果が出るのだ。

この中で、特に組織のリーダーである人たちの役割は大きい。この人たちが「コミットする姿勢を見せるだけではく、支援する」ことによって初めて全体が動き出す。ここをよく押さえておく必要がある。

◆セミナーのご案内

このような落とし穴を避けながら、プロジェクトマネジメントの定着化を推進する方法を解説するセミナーです。

    http://pmstyle.biz/smn/establish.htm

プロジェクトにおけるアカウンタビリティとレスポンシビリティ(2007/03/01)

◆アカウンタビリティとレスポンシビリティ

アカウンタビリティとレスポンシビリティという言葉がある。

日本語でいえば、両方とも「責任」である。しかし、微妙に違う。

このような責任概念はもともと企業経営の概念であるので、プロジェクトにおける議論をする前に、少し、一般的な説明をしておこう。

レスポンシビリティは、企業自身が負う内部的、「自己責任」のニュアンスで使われる言葉である。これに対して、アカウンタビリティは消費者、市民などから求められる「外部への責任」という意味で使われる言葉である。最近、アカウンタビリティが注目されるようになってきたのは、環境問題をはじめ、企業としての社会的な責任が問われるようになってきたためである。

◆プロジェクトマネジメントにおけるアカウンタビリティとレスポンシビリティ

プロジェクトマネジメントにおいても同様の概念がある。レスポンシビリティはプロジェクト内部のステークホルダに対する自己責任を持つことである。このために、例えば、プロジェクトマネジメントでは、ＲＡＭなどの手法を用いて、自己責任の分担を明確にするのだ。

ＰＭＢＯＫのツールと技法を極める　第１回　ＲＡＭ
　http://www.pmstyle.jp/honpo/pmbok_method/tool1.htm

アカウンタビリティそのものを扱う手法は存在しないが、コミュニケーションマネジメントなどではアカウンタビリティを確保する計画をすべきである。

◆アカウンタビリティは仕組みの問題、レスポンシビリティは人の問題

ここで注意しておきたいのは、レスポンシビリティは自己責任であり、個人の資質・モラルに関わる概念であるのに対して、アカウンタビリティは、システム・仕組み・組織などに関わる概念であることだ。その意味で、レスポンシビリティの確保はプロジェクトとして最低限のことはすべきだが、結局、その責任がきちんと果たされるかどうかは、個人の資質の問題であり、ある意味で、それ以上、どうしようもない。

しかし、アカウンタビリティについては、アカウンタビリティを確保するシステムを作る必要がある。従って、そのためのシステムとして、コミュニケーションマネジメントが極めて重要な役割を果たすのだ。

さて、では、プロジェクトの中でレスポンシビリティとアカウンタビリティがどのように機能するかについて考えてみよう。

◆それ以前の問題～コミットメント

この問題を考える場合には、実はもうひとつ、重要な概念がある。それはコミットメントである。

コミットメントは仕事（作業）遂行の約束である。計画を作ることの重要な一面は、コミットメントである。プロジェクトにおいては、作業や仕事を、達成すべき目標を加えてプロジェクトマネジャーが定義し、メンバーに渡す。メンバーはそれを引き受ける。これがコミットメントである。

プロジェクトマネジャーの最も重要な管理仕事は、メンバー個々に必要な作業を割り当てて、作業方法を教育し、進行プロセスの管理をすることである。

さらに、メンバーにスキル的な未熟がある時は、作業方法を示することによって、教育をすることもプロジェクトマネジャーの管理業務の範疇である。

◆コミットメントのプロセスがあるか？

このように書くと当たり前だと思うかもしれないが、実は、このコミットメントのプロセスはあいまいになっていることが多い。ある意味で「あたりまえ」だと思うせいか、コミットメントを明確なプロセスで行うことをしない。これが、達成できない目標の設定になり、無責任の原因になっていることも少なくない。

ここで、目標について理解しておくべきことは、目標は達成すべきものであって、単なる口約束ではないことだ。口約束にしないためには、達成できるための方法（対策）を決める必要があることは明らかである。それが決まって初めて、達成すべき数値を含んだ目標ができるのだ。

言い換えると、この一連のプロセスがコミットメントであり、コミットメントがあるから、初めて、内部にしろ、外部にしろ、責任が生じる。

ところが現実にはこのプロセスがきちんと行われていない。目標を達成するための方法を明確にしないままで、目標の設定をしているケースが多い。これはプロジェクト内でもそうだし、プロジェクトそのものに対してもそうだ。「まるなげ」というのはこういう状況を言っている。

◆レスポンシビリティのためのコミットメントの方法

レスポンシビリティは前回触れたように、コミットメント（契約）を前提にした個人の責任であり、プロジェクトメンバーでいえば、作業遂行責任ということになる。まさに、ＲＡＭ(Responsibility Assignment Matrix）をイメージしていただければよいと思う。

前回述べたように、責任が発生するのは、コミットメントが成立した後である。

プロジェクトマネジメントの中では、一般的には、計画の中でＷＢＳによって成果物（目標）を明確にし、その目標達成に必要なアクティビティに対する責任の明確化のためにＲＡＭを作る。さらに、それぞれのアクティビティに対して、所要時間や共同作業者、作業順序に対する制約などをセットで決める。これらが、マネジャーから指示された作業方法ということになる。

作業者のレベルによって異なるレベルの指示が必要であるが、これについては、ＷＢＳの詳細度、アクティビティ定義の精度などでカバーしていくことになる。

つまり、プロジェクトマネジメントのプロセスをきっちりとやれば、前回述べたコミットメントのプロセスをきちんとカバーしていることになる。これが、前回の記事の答えだ。

◆レスポンシビリティを果たす

逆にいえば、ＷＢＳやアクティビティ定義、ＲＡＭといったドキュメントがない場合にはコミットメントのプロセスがきちんと実行されていないことになり、メンバーに責任（レスポンシビリティ）が発生しているとは考えられない。堅苦しく感じるかもしれないが、この部分はプロジェクトマネジメントの基本中の基本であるので、よく考える必要がある。
さて、コミットメントがある前提の中で、レスポンシビリティとは

コミットメントされた作業の中で、発生した障害の報告、経過の報告、目標の達成度の報告を行い、さらに、目標達成に有効な対策を立案したり、あるいは、目標の修正を行うこと

と定義できる。作業責任という場合、ここまでの範囲が含まれる。これから分かるように、リスクマネジメントでいう「是正」はレスポンシビリティの範囲で行われることになる。

ただし、レスポンシビリティを果たすことは単にメンバー（担当者）だけの責任ではない。プロジェクトとしてのレスポンシビリティを果たすため、プロジェクトマネジャーやプロジェクトマネジャーに指示されたリーダーは作業の指導を行う責任がある。
あるいは、必要な場合には、作業方法の変更を指示する必要もある。これらができて初めて、レスポンシビリティを果たしたことになる。お気づきだと思うが、ＲＡＭでは、これらの責任についても明示的に決定することになる（ただし、ＰＭＢＯＫの標準ＲＡＭでは少し弱いと思うが）。

◆アカウンタビリティを果たす

さて、ではアカウンタビリティとは何か？前回述べたようにこれは外部に対する責任を意味している。この内外の関係はさまざまなものがある。作業者個人が共同作業をしているチームに対するアカウンタビリティもあれば、チームがプロジェクトに対するアカウンタビリティもある。もちろん、プロジェクトとして外部のステークホルダに対するアカウンタビリティもある。

いずれの場合も、プロジェクト作業の結果を報告し、次の作業へのコミットメントを新たにするのがアカウンタビリティである。アカウンタビリティのためには、以下の２つのポイントがある。

・目標との差異を数値で報告すること
・結果を分析した振り返りが含まれること

ここで振り返りとは、目標に対して差異の発生した原因を定量的、かつ、論理的に説明し、その差異を克服するための対策を立案することを言っている。

◆プロジェクトマネジメント
　　　＝コミットメント＋レスポンシビリティ＋アカウンタビリティという構図

これで、お分かりいただけたと思うが、コミットメント、レスポンシビリティ、アカウンタビリティは普通にプロジェクトマネジメントを実施していれば実現できる。前回から述べてきたことをまとめると、プロジェクトに従事する人が責任を果たすとは

（１）作業遂行の約束
（２）責任を持って作業を遂行する
（３）振り返りを含む説明の責任を果たす

のサイクルをきちんとするということである。従って、結果が出ればプロジェクトマネジメントなどは不要であるということで済まされる議論ではない。

これらの責任は、今後、内部統制が厳しくなるとともに、だんだん、厳格な運用が行われるようになることが予想されるので、改めて認識を新たにしておきたい。

段階的詳細化をシステマティックに行う(2007/01/31)

◆プロジェクトマネジメント　３つの抵抗

今でもプロジェクトマネジメントは難しいものだとか、あるいは、非現実的なものだとかといった捉えられ方をするのは珍しくありません。

なぜなのでしょうか？

多くの企業で、ＰＭＯがプロジェクトマネジメントの導入に当たって必ずといってよいくらい抵抗にあうことが３つあります。

（１）マネジメントドキュメント量への抵抗
（２）あいまいな状況での意思決定への抵抗
（３）マネジメント事項の多さへの抵抗

です。

（１）は圧倒的に多い抵抗なので、よくお分かりだと思います。こんなにたくさんのマネジメントドキュメントを書く時間はとれないという抵抗です。（２）はまだ多くのことが未決定の計画の段階で完璧な計画を作ることなど不可能だという抵抗です。
（３）はスケジュールと要員計画だけでも手を焼いているのに、ＷＢＳ辞書だの、コミュニケーション計画だのとても作れないという悲鳴です。

いずれも一理ありますが、共通の誤解があります。

◆詳細的段階化はプロジェクトの基本中の基本

ちょっと脱線しますが、みなさんのほとんどの方がＰＭＢＯＫの５つのプロセスを見られたことがあるでしょう。この中で、計画と実行とコントロールがループになっています。これはＰＤＣＡのサイクルだと思っている人が多いようです。確かに、広い意味ではＰＤＣＡサイクルなのですが、単純なＰＤＣＡのサイクルではありません。
ＰＤＣＡサイクルは、計画をして実行をする。そして、レビューをし、是正をするというサイクルですが、これは改善をイメージしたものです。

ところが、プロジェクトマネジメントの計画、実行、コントロールがループになっているのは、部分的に計画してとりあえず、その計画を実行し、また、次のステップの計画を作り、実行するという繰り返しでプロジェクトの目標を達成することをイメージしています。これをプロジェクトでは、「詳細的段階化」といい、プロジェクトが最初から持っている性質のひとつだとされています。

ちなみに、このほかには

　・有期性（はじめとおわりがある）
　・独自性（そのプロジェクト固有のものがある。たとえば２つと同じものを作らない）

といった性質を並ぶものですが、なぜか、あまり段階的詳細化には注目されてきていませんでした。

もうお分かりですね。上に書いた３つの抵抗に共通の誤解とは、プロジェクト作業（開発作業など）に着手する前にすべて計画を作らなくてはならないという思い込みです。

それでなくてもプロジェクトの立上げは、プロマネはそのプロジェクトの内容の把握とか、ステークホルダとの話し合いとかで、仕事の集中する時期です。そこで、プロジェクトの完全な計画を作れといわれると、

「まだ、全部決まっているわけではないし、時間もないので、そんな計画は作れないし、使うかどうかも分からないコミュニケーション計画など論外」

と言いたくなる気持ちは分かります。

◆プロジェクトは登山、マイルストーンはハーケン、計画はザイル

そうではなく、段階的に詳細化をしていくという発想を持てば、話は全然変わってきます。登山をテレビで見たことのある方は、ハーケンを岩の割れ目や氷に打ち込み、一端の穴にザイルを通し、手がかりを確保しながら、登山する様子を連想してください。いままで、邪魔者に見えていた計画が、プロジェクトのゴールまで導いてくれるザイルのように見えてくるのではないでしょうか？

ハーケンはマイルストーン、ザイルはプロジェクト計画書です。

頂上まで登れるかどうかは、ハーケンを打つ場所にかかってきます。つまり、段階的詳細化をいかに行うかにかかってきます。しかし、段階的詳細化という概念は理解できでもなかなか実行できないのは登山と同じような難しさがあります。

◆セミナーのご案内

そこで、段階的詳細化をシステマティックに行う方法をご紹介するセミナーを開催します。このセミナーを受講していただくことによって、プロジェクト計画書を使った段階的詳細化ができるようになります。ぜひ、ご参加ください。

     http://pmstyle.biz/smn/keikakujissen.htm