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

◆普及してきたレジリエンス

レジリエンスという概念がある。東日本大震災のあと、メルマガの配信をしばらく休んでいたが、復活第１号（通算９４２号）から「難局を乗り切るマネジメントとリーダーシップ」というシリーズを書き、真っ先に取り上げたのがこの話だ。

【戦略ノート247】難局を乗り切るマネジメントとリーダーシップ（１）～レジリエンスを高める


それから３年になるが、当時は一般にはあまり知られていない概念だったレジリエンスがかなり知られるようになってきている。レジリエンスを高めるトレーニングの本も見かけるようになった。

◆はじめに

昨年１０周年のイベントが終わって以来、戦略ノートを１本書いた以外は、過去記事の再掲のみで、ずいぶんご無沙汰しています。

ご無沙汰の最大の理由は１０周年記念で作って戴いた持論を２７本、配信したことです。これだけで年間の配信記事の四分の一になりました。もう一つの理由は１０年に１年くらいは充電したいと思ったことです。

ということで、両方とも終わったので復帰したいと思います。改めて、よろしくお願いいたします（実は、もう一つ、理由があるんですが、それはまた、何かの機会に）。

◆「抽象的」な考えは机上の空論？！

７月２４日に「リスクをとるリスクマネジメント」という公開講座を行った。創造的リスクマネジメントをしようというセミナーなのだが、受講者の方からアンケートで、「リスクが抽象的」、「具体的」とはどういうことかという指摘を受けたので、メルマガを使って補講してみる。公開講座に参加されていない方を念頭において書くので、受講者の方には被る内容があるのはご容赦戴きたい。

今年になって、コンセプチュアルスキルの強化を打ち出している。その活動の中での感触としては８割くらいの人（特に理系の人）はものごとを「抽象的」に考えても机上の空論にすぎない、「具体的」に考えるべきだと考えているようだ。ここについてはまだ、かみ合っていない感じなのでこれから時間をかけて抽象的なことも考えた方がいいよと伝えていこうと思っている。

この話を頭の中にどこかに残しておいてほしい。

◆リスクと不確実性の違い

リスクと不確実性はしばしば同じ意味で使われているが、大きな違いがある。その違いとは、リスクはあくまでに確率事象であり、母集団における分布が過去の経験で分かっている。これに対して、不確実性の場合には母集団すらわからないことだ。

たとえば、こういうことだ。ある作業が遅れるかもしれないとする。その作業の方法がはっきりわかっている。遅れる理由は担当者のスキル不足で、十分なスキルを持つメンバーを担当させられない可能性がある。この場合の母集団はその作業に必要なスキルを持つメンバーであり、その中でスキル不足な人の割合がリスクになる。たとえば、過去の実績で判断すると、１０人の内の３人だと今の計画では予定通り作業が終わらないとすれば、遅れが発生するリスクは３０％ということになる。

ところが、別の作業はどのようにしてよいか分からないとしよう。この場合、どの範囲で遅れる確率を考えればよいか分からない。つまり、母集団が分からないのだ。これはリスクではなく、不確実性である。

 

◆開発管理とプロジェクトマネジメント

ＩＴ分野を中心にアジャイル開発への関心が高まってきている。一方で、アジャイル開発は大企業には適さないとか、日本では適さないといった意見も出始めている。適さないという意見には、ガバナンスを問題視する意見が多い。今回はこの問題を考えてみたい。

そのまえに、開発管理とプロジェクトマネジメントという言葉について整理しておきたい。プロジェクトマネジメントが普及してくる以前から、開発管理という言葉がある。プロジェクトマネジメントが普及するにつれて、言葉のニュアンスが変わってきているので、いまやどうでもいいのだが、このあとの話の展開上必要があるので、もともとの定義に触れておきたい。

開発においては、プロダクト（システムや製品）自体の実現が目的であり、開発管理は、開発手法（プロセス）、ツール、体制などに注目する。プロダクト開発は予算、納期の制約のもとに行われるが、プロダクトの実現が重視される。つまり、プロダクトの仕様（機能、品質）を実現するためには、予算をオーバーしたり、納期に遅れることもある。その意味で、予算オーバーや納期遅れを如何に小さく食い止めるかが管理としての役割だといえる。

ただし、ビジネスのスピードが速くなった中で、特に、スケジュールが努力目標になっていたのでは、開発の意味がなくなるケースが多くなっている。そこで、管理方法がプロジェクトマネジメントに移ってきている。

プロジェクトマネジメントも枠組みは同じであるが、プロダクト機能（プロダクトスコープ）や品質、予算、納期はすべて対等に目標として扱い、ベースラインとして計画化する。プロダクトはプロジェクトの成果物の一つに過ぎず、プロジェクトにはその成果物を構築することによって実現したい目的（成果）がある。そして、その目的を達成するという視点から、プロダクト機能、品質、予算、納期のトレードオフを行う。これがプロジェクトマネジメントである。

この背景にあるのは、プロダクトの機能や品質の一部を落としてもいいので、早く出荷したい、あるいは原価を下げたいといったモノ作りではあまりない多様なニーズである。

◆コストマネジメントのポイントは予備費

ＩＴ系のプロジェクトでは、プロジェクトマネジャーにスケジュールと品質のマネジメントを任せ、スコープとコストマネジメントは組織職が行っているケースがある。今回は、プロジェクトマネジャーとプロジェクトリーダーという視点からこの問題について考えてみたい。

マネジメントとは、なんとかすることである。プロジェクトでは納期と予算という形でスケジュールとコストの制約条件が与えられ、目標としては、成果物やその品質、その他プロジェクトの目的に所以する目標（顧客を感動させるとか、チームメンバーの育成をするなど）が設定されることが多い。プロジェクトマネジメントは、プロジェクトに与えられた制約条件の中で、なんとかして目標を達成することである。分担でいえば、目的・目標や制約を決めるのがプロジェクトリーダー（プロジェクトスポンサー）であり、何とかするのがプロジェクトマネジャーである。

ソフトウエア開発を中心とするＩＴプロジェクトにおいては、直接経費のほとんどは人件費であり、間接経費も直接経費に従量配賦するような会計システムをとっている企業が多く、コストマネジメントのある部分は工数管理で代替的に行っている。コストマネジメントをプロジェクトマネジャーに任さないという問題になるのは、予備費である。

◆任務を全うすることによって責任を取る

プロジェクトリーダーとプロジェクトマネジャーの関係を明確にするために、まず、「責任」という観点から考えてみたい。日本の組織ではこんな会話がよくある。プロジェクトリーダー＝部長、プロジェクトマネジャー＝ＰＭだとしよう。

（ＰＭ）責任は私が取りますので、この方法でやらせてください。
（部長）どうやって責任を取るの。責任はとれるの？
（ＰＭ）・・・

責任を取るという言葉も難しい。

企業のトップとか、政治家が責任を取るという場合の相場は、辞任することだ。大臣が何かしでかしたら、大臣を辞めて責任を取ることだった。一般的に考えても責任を取るというのは、「懲罰」を受けるという意味合いがある。

ところが、小泉政権の時だったと思うが、大臣が問題発言をした際に誰もが思わなかった対応をした。

「大臣を続け、大臣としての任務を全うすることによって責任をとります」

と言い出した。

こういう言い方をされると、反論するのが難しい。任務をまっとうすることが責任を取る方法だと言われると、受け入れざるを得ない。せいぜい、潔くないといったあまり役に立たない非難をするくらいしかできない。また、非難にさらされながらも、任務を行うことは懲罰といえなくもない。

◆はじめに

ついに戦略ノートも３００回になった。

戦略ノートは、ＰＭ養成マガジンの配信を始めてしばらく、唯一のコンテンツとして配信していた。ＰＭ養成マガジンとしては本号が１１０４号なのだが、僕自身は、戦略ノートの３００回の方が感慨深い。この機会にバックナンバーを読んで戴けると嬉しい。途中からメルマガからブログ記事に飛ばす形態にしたため、「プロジェクトの補助線」ブログにも収録されているものもあるが、プロジェクトマネジメントＯＳ本舗のサイトに２９９話、すべて収録されている。

「戦略ノート」

ということで、３００話目のテーマを何にしようかと１ヶ月くらいいろいろと考えていたのだが、これをテーマにすることにした。

「リーダーとマネジャーのコラボレーション」

このテーマは実は今までも何回か書いたことがあるのだが、プロジェクトマネジメントのもっとも基本的なテーマである。

◆ある遅延プロジェクト

現場で力を発揮しているリーダーは、現場に不協和音を生じさせるような意思決定ができないという指摘がある。今回はこの問題について考えてみたい。

あるコンサルの現場で、こんなことがあった。その会社では、エースと言われるプロジェクトマネジャーがプロジェクトが納期遅れを起こした。実はかなり早い段階でスケジュールを遅れがあったようで、プロジェクトマネジャーはそれを隠していた。しかし、プロジェクトマネジャーの上司に当たる担当部長に、顧客からプロジェクトの対応がおかしいという指摘があり、調査したところ、遅れが判明した。まあ、ここまではまれにある話だ。

◆プロジェクトにおけるチームとは何か

戦略ノート２９６で、

【戦略ノート296】日本人は真のチームを作れない

という話をした。この記事に、個人的にコメントをもらったので、今回はこの話をもう少し、深く考えてみたい。貰ったコメントは、そもそも、プロジェクトマネジメントにはチームマネジメントはあるが、チームにであることを前提にしてしないのではないかというコメントだ。

最初に考えなくてはならないのは、そもそも、プロジェクトにおけるチームというのは何だという話である。もちろん、いろいろな側面があるが、基本的には広い意味での問題解決を行うものだ。

プロジェクトはメンバーを集めてグループを作る。そして、プロジェクトマネジメント計画として、ＷＢＳとＯＢＳを作り、ワークパッケージ（要素成果物）ごとに担当（一般には複数）を決める。さらに、ＲＡＭを作って、担当の中での責任分担を明確にする。

従って、プロジェクトがうまくいっていれば、実はチームというのは、あまり、役に立たない。もちろん、問題解決以外に、チームワークがよくなれば生産性が向上するとか、モチベーションがあがるとか、諸々のメリットがあるので、まったくの無駄というわけではないことは言うまでもない。