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

PMstyleのfacebookページを始めました。

facebookページの参加者限定のコンテンツやサービスの提供、および、facebookページ限定のコンテンツ提供を予定しています。前者は、ただいま、準備中ですが、後者については、

「ストーリーで学ぶプロジェクトマネジメントの極意」

という連載をはじめ、すでに第１回をアップしました。facebookページにもぜひ、お越しください。

参加者が増えてきたら、参加者とのコ・クリエーションにも取り組んでいきたいと思っています。facebookのアカウントを取り、「いいね！」をして、参加されるのをお待ちしています！

PMstyle facebookページはこちらです。

via people.weblogs.jp

PMstyleプロデュースブログでお知らせしましたように、PMstyleのfacebookページができました。

プロジェクトスポンサーが誰かわからないプロジェクトは失敗の確率が高い  （橋本忠夫、多摩大学大学院教授）

【成分】

◆８０％の時間をコミュニケーションに費やすというが、、、
◆ステークホルダとの調整はプロジェクトマネジャーの本務ではない
◆生産性を上げることこそ、本務
◆プロジェクトスポンサーが明確であれば成功確率が上がる
◆プロジェクトスポンサーのスキル

◆顧客とのコミュニケーションが悪い！→研修をやろう！

まず、現実問題としてどのような対象をしているか。一つの事例を紹介する。

ＩＴ業界でプロジェクトマネジメントが定着し始めたころから、認識が高まってきた問題に、顧客からシステムの仕様やプロジェクトの運用に関する顧客の要望（プロジェクト要求）をうまく聞き出せず、プロジェクトの終盤になって認識が異なるという問題が発生し、プロジェクトが窮地に追い込まれるという問題がある。この問題への対処をパフォーマンスコンサルティングの観点から考えてみよう。

このような問題を抱えるある企業の事業部門は、この問題を顧客とのコミュニケーション、特に上流工程で、顧客とのコミュニケーションに問題があると考え、コミュニケーションの改善を目的とした研修を実施した。

残念ながら、この部門では問題が解決されたとは言い難い結果に終わった。研修プログラムに問題があると考え、数回改善をしたが、目立った効果もなかった。

◆分業型のチームと協働型のチーム

世間ではチームマネジメントがブームである。この半年で、チームマネジメントをテーマにした本は３０冊は出ていると思う。チームで仕事をすることの重要性への認識が高まってきているのだろう。

チームで仕事をすることの重要性は、プロジェクトでは改めていうまでもない。

チームで仕事をするといった場合、チームのスタイルは二つに分かれる。分業型のチームと協働型のチームである。分業型は生産を目的とするプロジェクトでよくみられるスタイルである。ＷＢＳで仕事を分け、責任者を決め、最終的にチームとして成果を統合していくスタイルである。

これに対して、協働型のチームは、チームで行うべき課題を全員でやっていく。細かくみれば作業分担をすることもあるが、基本的にはプロジェクトの一つ一つのイシューに対して、全員で知恵を絞り、動いていく。

権限は委譲できても責任は委譲できない（橋本忠夫、多摩大学大学院教授）

【成分】

◆責任を委譲できるという錯覚
◆アカウンタビリティとレスポンシビリティ
◆２つのケース
◆プロジェクトマネジメントに大した権限は要らない
◆権限と責任は非対称なもの

◆売り手市場と現場力

前回は、上位管理者の役割が混乱しているという話をしたが、今回はこの問題の背景を考えてみたい。

日本企業の強みの一つは間違いなく、「現場力」である。類まれともいえる現場力で成長してきた。ここで一つ、はっきりしておかなくてはならないのは、その間、売り手市場だったということだ。売り手市場ではよいものを作れば売れる。おまけに日本の高度成長期は規制による横並びの市場だった。言ってしまえば統制経済に近かったので、本当の意味での競争もなかった。このような環境であれば現場力が強いと全体が回っていく。

現場力が強みという話が怪しくなってきたのは、市場も成熟し、いわゆるバブルもはじけ、モノ余りが言われるようになってからである。

ここで多くの企業が考えたのは、モノが売れないのは、良いモノを作る力が落ちている、つまり現場力の低下だと考えた。品質、リードタイム、コスト、・・・

そこで、より一層の現場力向上をしようとした。その一つの施策がプロジェクトマネジメントである。この判断自体が間違いだとは思わないが、そのあとの方向性で致命的なミスをしている。それは、現場力を直接上げようとしたことだ。

具体的な計画に裏付けられた明確な見通しがあれば、大いに自信が持てるし、力もわいてくる（ブライン・トレーシー、コンサルタント）

【成分】

◆プロジェクト計画を作る目的
◆多くの人が確信のない計画を作っている
◆デスマーチ
◆ビジョンは万能ではない
◆リーダーシップとしての計画

◆混沌を極めるプロジェクト上位管理者の役割

プロジェクトマネジメントはなんとか形になってきた組織が多いが、プロジェクトの上位管理者の役割や機能については、まだまだ、混沌としている企業が圧倒的に多い。大きな理由は２つあるように思う。

一つは、責任分担が不明確なことである。もう一つは、上位管理者がプロジェクトマネジメント（ロール）をあまり理解していないことである。このスレッドでは、プロジェクトの上位管理者の役割や機能を整理してみたい。戦略ノートでは、２００８年に１７６回から８回かけて、一度、この議論をした。しかし、消化不良の部分もあり、また、当時とは考え方も変わっているので、異なる枠組みで改めて、議論をしてみたいと思っている。

第１７４回（2008.01.29）
組織が行うべきプロジェクトマネジメント（１）～責任のフレームワーク

◆パフォーマンスコンサルティングの背景

前回は、パフォーマンスコンサルティングのさわりと、ＰＭＯがパフォーマンスコンサルティングを展開せよという主張をした。さっそく、いくつかのクライアント企業、特に研修をやらせていただいている企業でも話題になった。facebookでも何人からかコメントをもらった。大枠では共感するところが多かったようである。

ただ、この議論で研修との比較にどうしてこだわるかという意見もあった。確かに日本の現場の優秀さは研修による育成の成果とは言い難い部分がある。いわゆる「人創り」と呼ばれる現場密着型の活動で優秀な人材を育ててきたという過去がある。

これは的を得た指摘であるし、欧米でパフォーマンスコンサルティングという発想が出てきた背景の一つはそこにあると著者も考えている。しかし、そういう時代ではなくなったということだ。

一言でいえばそういう時代ではなくなった。最大の原因は成果主義だろう。二番目はリストラ。成果主義では仕事の中で人を育てるのは難しい。ただでさえ難しいのに、加えて人を減らしており、人を育てる余裕もない。

そのような経営環境では、人を育てるのはトレーニングに頼るしかない。しかし、前回も述べたように単純にトレーニングをしても人は育たない。ここが「パフォーマンスコンサルティング必要論」のスタート地点である。そして、パフォーマンスコンサルティングは人を育てることによりパフォーマンス上の問題を解決する方法である。

したがって、「いや、違う。まだ、うちの会社では、仕事の中で人を育てながら、かつ、競争力を持つ（＝成果を出す）ことができている」という組織であれば、パフォーマンスコンサルティングなど必要はないし、本音を言えばそれが望ましい姿であるとも思う。

◆１０年間使い続けることのできる情報システムは作れるか？

前回、商品開発にしろ、ＩＴにしろ、顧客がもう少し、積極的な参加を望むようになってきた。その中で、プロジェクトマネジメントはどうあるべきかを考える必要があるというところまで話しが進んだ。これから、少し、個別の領域でどうあるべきかを議論していきたいと思っている。まずは、著者がこの議論を考えるきっかけになったＩＴの分野から。

ＩＴの分野でこの問題意識を持ったのは実はもう２０年以上前である。きっかけは、あるコンピュータメーカのユーザシンポジウムで、偶然、聞いたＧＭＳのの情報部門の人の話。おそらく、コンピュータメーカのＳＩ部門に対する要望として、「システムの開発はせいぜい１年だが、我々はそのシステムを１０年間使い続けることになる。そのことを意識して対応をしてほしい」という趣旨のものだった。もっともな話なのだが、その話を聞いた瞬間に思ったのは無理だということだった。

たとえば、ＮＣマシンを調達し、１０年どころか、１５年、２０年使うということは珍しくない。ところが、１０年間使える情報システムの基盤というのは想像できない。自社のビジネスにおける位置づけが違うからだ。もし、１０年間使えるとしたら、情報システムの作りの問題ではなく、その企業のビジネスシステムやビジネスモデルがよほど卓越しているからだろう。実際に、その後、償却期間の設定も短くなり、情報システムのライフサイクルは短くなってきた。