本ブログは移転しました。こちらをご覧ください
◆リスクと不確実性の違い
リスクと不確実性はしばしば同じ意味で使われているが、大きな違いがある。その違いとは、リスクはあくまでに確率事象であり、母集団における分布が過去の経験で分かっている。これに対して、不確実性の場合には母集団すらわからないことだ。
たとえば、こういうことだ。ある作業が遅れるかもしれないとする。その作業の方法がはっきりわかっている。遅れる理由は担当者のスキル不足で、十分なスキルを持つメンバーを担当させられない可能性がある。この場合の母集団はその作業に必要なスキルを持つメンバーであり、その中でスキル不足な人の割合がリスクになる。たとえば、過去の実績で判断すると、１０人の内の３人だと今の計画では予定通り作業が終わらないとすれば、遅れが発生するリスクは３０％ということになる。
ところが、別の作業はどのようにしてよいか分からないとしよう。この場合、どの範囲で遅れる確率を考えればよいか分からない。つまり、母集団が分からないのだ。これはリスクではなく、不確実性である。
本ブログは移転しました。こちらをご覧ください
◆開発管理とプロジェクトマネジメント
ＩＴ分野を中心にアジャイル開発への関心が高まってきている。一方で、アジャイル開発は大企業には適さないとか、日本では適さないといった意見も出始めている。適さないという意見には、ガバナンスを問題視する意見が多い。今回はこの問題を考えてみたい。
そのまえに、開発管理とプロジェクトマネジメントという言葉について整理しておきたい。プロジェクトマネジメントが普及してくる以前から、開発管理という言葉がある。プロジェクトマネジメントが普及するにつれて、言葉のニュアンスが変わってきているので、いまやどうでもいいのだが、このあとの話の展開上必要があるので、もともとの定義に触れておきたい。
開発においては、プロダクト（システムや製品）自体の実現が目的であり、開発管理は、開発手法（プロセス）、ツール、体制などに注目する。プロダクト開発は予算、納期の制約のもとに行われるが、プロダクトの実現が重視される。つまり、プロダクトの仕様（機能、品質）を実現するためには、予算をオーバーしたり、納期に遅れることもある。その意味で、予算オーバーや納期遅れを如何に小さく食い止めるかが管理としての役割だといえる。
ただし、ビジネスのスピードが速くなった中で、特に、スケジュールが努力目標になっていたのでは、開発の意味がなくなるケースが多くなっている。そこで、管理方法がプロジェクトマネジメントに移ってきている。
プロジェクトマネジメントも枠組みは同じであるが、プロダクト機能（プロダクトスコープ）や品質、予算、納期はすべて対等に目標として扱い、ベースラインとして計画化する。プロダクトはプロジェクトの成果物の一つに過ぎず、プロジェクトにはその成果物を構築することによって実現したい目的（成果）がある。そして、その目的を達成するという視点から、プロダクト機能、品質、予算、納期のトレードオフを行う。これがプロジェクトマネジメントである。
この背景にあるのは、プロダクトの機能や品質の一部を落としてもいいので、早く出荷したい、あるいは原価を下げたいといったモノ作りではあまりない多様なニーズである。
本ブログは移転しました。こちらをご覧ください
◆コストマネジメントのポイントは予備費
ＩＴ系のプロジェクトでは、プロジェクトマネジャーにスケジュールと品質のマネジメントを任せ、スコープとコストマネジメントは組織職が行っているケースがある。今回は、プロジェクトマネジャーとプロジェクトリーダーという視点からこの問題について考えてみたい。
マネジメントとは、なんとかすることである。プロジェクトでは納期と予算という形でスケジュールとコストの制約条件が与えられ、目標としては、成果物やその品質、その他プロジェクトの目的に所以する目標（顧客を感動させるとか、チームメンバーの育成をするなど）が設定されることが多い。プロジェクトマネジメントは、プロジェクトに与えられた制約条件の中で、なんとかして目標を達成することである。分担でいえば、目的・目標や制約を決めるのがプロジェクトリーダー（プロジェクトスポンサー）であり、何とかするのがプロジェクトマネジャーである。
ソフトウエア開発を中心とするＩＴプロジェクトにおいては、直接経費のほとんどは人件費であり、間接経費も直接経費に従量配賦するような会計システムをとっている企業が多く、コストマネジメントのある部分は工数管理で代替的に行っている。コストマネジメントをプロジェクトマネジャーに任さないという問題になるのは、予備費である。
本ブログは移転しました。こちらをご覧ください
◆任務を全うすることによって責任を取る
プロジェクトリーダーとプロジェクトマネジャーの関係を明確にするために、まず、「責任」という観点から考えてみたい。日本の組織ではこんな会話がよくある。プロジェクトリーダー＝部長、プロジェクトマネジャー＝ＰＭだとしよう。
（ＰＭ）責任は私が取りますので、この方法でやらせてください。
（部長）どうやって責任を取るの。責任はとれるの？
（ＰＭ）・・・
責任を取るという言葉も難しい。
企業のトップとか、政治家が責任を取るという場合の相場は、辞任することだ。大臣が何かしでかしたら、大臣を辞めて責任を取ることだった。一般的に考えても責任を取るというのは、「懲罰」を受けるという意味合いがある。
ところが、小泉政権の時だったと思うが、大臣が問題発言をした際に誰もが思わなかった対応をした。
「大臣を続け、大臣としての任務を全うすることによって責任をとります」
と言い出した。
こういう言い方をされると、反論するのが難しい。任務をまっとうすることが責任を取る方法だと言われると、受け入れざるを得ない。せいぜい、潔くないといったあまり役に立たない非難をするくらいしかできない。また、非難にさらされながらも、任務を行うことは懲罰といえなくもない。
本ブログは移転しました。こちらをご覧ください
◆はじめに
ついに戦略ノートも３００回になった。
戦略ノートは、ＰＭ養成マガジンの配信を始めてしばらく、唯一のコンテンツとして配信していた。ＰＭ養成マガジンとしては本号が１１０４号なのだが、僕自身は、戦略ノートの３００回の方が感慨深い。この機会にバックナンバーを読んで戴けると嬉しい。途中からメルマガからブログ記事に飛ばす形態にしたため、「プロジェクトの補助線」ブログにも収録されているものもあるが、プロジェクトマネジメントＯＳ本舗のサイトに２９９話、すべて収録されている。
「戦略ノート」
ということで、３００話目のテーマを何にしようかと１ヶ月くらいいろいろと考えていたのだが、これをテーマにすることにした。
「リーダーとマネジャーのコラボレーション」
このテーマは実は今までも何回か書いたことがあるのだが、プロジェクトマネジメントのもっとも基本的なテーマである。
本ブログは移転しました。こちらをご覧ください
◆ある遅延プロジェクト
現場で力を発揮しているリーダーは、現場に不協和音を生じさせるような意思決定ができないという指摘がある。今回はこの問題について考えてみたい。
あるコンサルの現場で、こんなことがあった。その会社では、エースと言われるプロジェクトマネジャーがプロジェクトが納期遅れを起こした。実はかなり早い段階でスケジュールを遅れがあったようで、プロジェクトマネジャーはそれを隠していた。しかし、プロジェクトマネジャーの上司に当たる担当部長に、顧客からプロジェクトの対応がおかしいという指摘があり、調査したところ、遅れが判明した。まあ、ここまではまれにある話だ。
本ブログは移転しました。こちらをご覧ください
◆プロジェクトにおけるチームとは何か
戦略ノート２９６で、
【戦略ノート296】日本人は真のチームを作れない
という話をした。この記事に、個人的にコメントをもらったので、今回はこの話をもう少し、深く考えてみたい。貰ったコメントは、そもそも、プロジェクトマネジメントにはチームマネジメントはあるが、チームにであることを前提にしてしないのではないかというコメントだ。
最初に考えなくてはならないのは、そもそも、プロジェクトにおけるチームというのは何だという話である。もちろん、いろいろな側面があるが、基本的には広い意味での問題解決を行うものだ。
プロジェクトはメンバーを集めてグループを作る。そして、プロジェクトマネジメント計画として、ＷＢＳとＯＢＳを作り、ワークパッケージ（要素成果物）ごとに担当（一般には複数）を決める。さらに、ＲＡＭを作って、担当の中での責任分担を明確にする。
従って、プロジェクトがうまくいっていれば、実はチームというのは、あまり、役に立たない。もちろん、問題解決以外に、チームワークがよくなれば生産性が向上するとか、モチベーションがあがるとか、諸々のメリットがあるので、まったくの無駄というわけではないことは言うまでもない。
本ブログは移転しました。こちらをご覧ください
◆はじめに
この戦略ノートは、
の続編です。
◆正しい努力
日本人は、努力することをよいことだと考える。このこと自体は、間違っていないと思う。しかし、前提がある。それは、正しい努力であればという前提である。
では、正しいかどうかをどのようにして判断すればよいのだろうか？それは、相手、あるいは周囲の期待に応えるために意味のある努力であるかどうかだと思う。同時に、自分自身が期待に応える価値があると考えていることが必要である。この両方が揃って、初めて正しい努力であるといえる。
本ブログは移転しました。こちらをご覧ください
◆チームとグループは違う
マッキンゼーのコンサルタントで、チームマネジメントの世界的な権威であるジョン・カッツェンバックは、２０年前にチームとグループは違うと指摘した。
概念的な言い方だが、１＋１が２以下であるのがグループで、１＋１が２以上になるのがチームだという。たとえば、５人の人が集まったときに３～４人分の仕事しかできないのがチームで、７～８人分以上の仕事ができるのがチームだという意味だ。
本ブログは移転しました。こちらをご覧ください
◆変わるプロジェクトの成功の定義
この１０年間くらいの間に、プロジェクトの成功の定義が変わってきた。改めていうまでもないが、プロジェクトは上位組織から与えられたＱＣＤの制約の中で、求められる成果物を実現する活動であり、これがきればプロジェクトは成功したと言える。このため、プロジェクトマネジメントはＱＣＤの制約をクリアしながら、定めたスコープを実現すべく、プロジェクトを進めていく活動として位置付けられる。
ところが、最近ではＱＣＤの制約をクリアできればプロジェクトは成功したとは考えられなくなってきた。成果物が生み出す価値が問題にされるようになってきた。
この背景にはプロジェクトを取り巻く環境はプロジェクト期間中は変わらないという前提がある。たとえば、ある商品を開発するのに、競合の動向や、技術動向、ビジネスの動向などは基本的にその期間は変わらない。つまり、プロジェクトを開始する時点と、製品の開発が終了した時点で変わらない。したがって、計画を立ててしまえば、その計画通りにプロジェクトを進めれば価値は保証されるという前提が成り立たなくなっていることがある（実際にその商品が売れるかどうかは別の問題である。価値とはその商品が持つポテンシャルである）。
ところが、現実にはそうはいかなくなってきた。開発リードタイムの間に市場に状況がガラッと変わってしまうようなケースは珍しくなくなった。
最近のコメント