本ブログは移転しました。こちらをご覧ください
◆アカウンタビリティとレスポンシビリティ
われわれが（プロジェクト）マネジメントの仕組みづくりコンサルティングを行う際に、徹底的にこだわっていることがある。それは、マネジャーや経営スタッフのプロジェクトチームやプロジェクトリーダー、プロジェクトメンバーに対するアカウンタビリティである。
アカウンタビリティ。説明責任という訳が一般的だが、業績責任の方がしっくりくるので、日本語で表記するときには業績責任という言葉を使っている。これだけの説明では漠然としているので、ちょっとだけ説明しておくと、プロジェクトに必要な責任には、レスポンシビリティとアカウンタビリティがある。レスポンシビリティは、チームメンバーの実行責任の意味で、ＲＡＭ（Responsibility Assignment Matrix）で定義される。これに対して、アカウンタビリティはプロジェクトに設定した目標、あるいは、プロジェクトに課せられた目的を達成する責任である。詳しくは、戦略ノート１３１を読んで欲しい。
戦略ノート１３１
◆バリューゾーンが変動している
上司が部下に対してアカウンタビリティを負うというと「あなたはアカウンタビリティの意味を理解しているのか」と言われることもある。そのぐらい違和感があるのだろう。
リーダーシップの議論としては、ロバート・グリーンリーフの提唱するサーバントリーダーシップという概念があり、それなりに理解される。ただ、プロジェクトにおいてはリーダーシップの議論だけでは十分ではない。責任が伴う必要がある。
なぜか？
従来は、プロジェクトのバリューゾーン（価値を生み出す場所）はプロジェクトの内部、あるいは、母体組織の内部にあった。技術や（狭い意味での）品質である。そして、これらをコントロールしているのが母体組織のマネジャーやスタッフだった。その意味で、プロジェクトで生み出す価値は組織が決めていた。
ところが、今は多くのプロジェクトでは、バリューゾーンは現場と顧客（市場）の間にある。これはイノベーションが組み合わせであるとことさら主張されるようになったことからも分かるし、アジャイル開発が注目されているのもその点にある。価値は、技術そのものから、どのように技術を組み合わせ、顧客の要求を実現していくかに移っている。すなわち、プロジェクト活動そのものが価値創造の場になっているといっても過言ではない。
にも関わらず、従来と同じように、プロジェクトスポンサーがプロジェクトリーダーをコントロールしている。言い換えると、プロジェクトリーダーはプロジェクトスポンサーにアカウンタビリティを追っている。すると、何が起こるのか？プロジェクトリーダーは自由に動けない。たとえば、顧客との対話によって、コストが変われば、マネジャーの承認を得なくてはならないなど、バリューゾーンでの活動が思ったようにできない。顧客からのみれば、不満足感が残る。
◆プロジェクトスポンサーのアカウンタビリティ
では、どうすればよいのか？答えが、プロジェクトスポンサーがプロジェクトリーダー（あるいは、メンバー）に対してアカウンタビリティを追うことだ。ただし、これはプロジェクトスポンサーが活動実績をリーダーやメンバーに報告することを意味しない。
プロジェクトスポンサーはプロジェクトの価値に対するアカウンタビリティを負う。ただし、現場で顧客と価値創造をしているのは、プロジェクトチームである。つまり、プロジェクトスポンサーは、間接的にアカウンタビリティを果たさなくてはならない。
一方で、多くの組織では、プロジェクトスポンサーは、プロジェクトリーダーに権限委譲をする、権限委譲できない部分は支援を約束する、また、個々のプロジェクトをモニタリングし、プロジェクトに対して評価を伝えるといったレスポンシビリティを負っているいる。
これらの活動を通じて、バリューゾーン（価値創造）に対するアカウンタビリティを果たすには、これらの活動のそれぞれに対してアカウンタビリティがあると考えた方がよい。それぞれの活動が明確にプロジェクトのバリューゾーンでの活動に貢献していること、つまり、プロジェクトスポンサーとしてのそれぞれの活動をプロジェクトの価値を生み出すことを目指す。
ちょっとややこしいのだが、一言でいえば、プロジェクトスポンサーとして、プロジェクトによるバリューゾーンでの価値創造にコミットし、それをリーダーやメンバーと共有することにより、プロジェクトの創造する価値を一段と高いものにするということだ。たとえば、権限移譲の話でいえば、現場は多少コストが膨らむが顧客の要求にこたえることにした。プロジェクトスポンサーとしてはその決定を支持し、プロジェクトリーダーも巻き込みながら、コスト増加への対処をしていく。こんなイメージになる。
◆プロジェクトリーダーはスポンサーへのアカウンタビリティを追わない
さて、このような仕組みをつくる場合、下から上へのアカウンタビリティをどう考えるかという問題がある。特に、プロジェクトリーダーがプロジェクトスポンサーに対して、アカウンタビリティを負うべきかどうか？
これは負う必要なないというのが、われわれの考えだ。理由は明確で、この場合、プロジェクトもプロジェクトスポンサーもバリューゾーンにコミットしている。つまり、状況を共有しながらプロジェクトを進めている。もし、プロジェクトスポンサーの活動にプロジェクトの情報が必要であれば、自分から取りに行くべきであって、報告を求める筋合いのものではない。
つまり、アカウンタビリティは従来と逆転する。これが、マネジャーではなく、プロジェクトでプロジェクトスポンサーというロールを作る本質的な意味ではなかろうか？
最近のコメント