プロジェクトマネジメント

2007年11月28日 (水)

プロジェクトマネージャーの育成 
不祥事多発! 仕事ができるプロマネの「プロフェッショナル責任」とは (2)

Tsuchiya みなさん、こんにちは
(株)富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア(http://ascii.jp/cate/21/)に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回も、プロフェッショナル責任についてです。

前回の記事はこちら

*******************

マネジメントで全体最適を目指す
 プロフェッショナル責任が大切だということは、誰もが頭では理解できていると思います。現に、世の中で起きている問題の多くは“技術的な問題”というより、“行動”に関する問題です。問題を事前に食い止めようとすれば、食い止められる単純なことなのです。では、これらを守っていくにはどうすればいいのでしょうか。

 対策の1つとしては、物事の判断基準を明確にすることです。「このときはいいけど、あのときはダメ」「今回は時間がなかったので、本当はダメなんだけど、いいことにしよう」など妥協やいい加減な判断があると、徐々にプロフェッショナル責任に対する意識が弱くなってしまいます。しかも、個々の品質の低下やプロジェクトの遅れ、トラブルにもつながっていきます。

 判断基準としては「全体最適」を目指すのがよいでしょう。プロジェクトを進めるとき、それぞれのメンバーは自分の担当箇所にとって最適を目指して仕事をするでしょう。それはプロとして重要なことではありますが、時に自分の担当の最適(部分最適)が、全体としての最適(全体最適)にならないことがあります。

 たとえば、あるパートが進行の遅れを取り戻すため、決められた方法を簡素化して作業を進めた場合。スケジュールどおりには進むでしょうが、そこではルールが無視されています。するとその結果、全体として不良個所が発生し、成果物は最適とは言えなくなります。確かに、個別で部分的な作業をすることの多いメンバーが、常に全体最適をとるのは困難です。そこで、プロジェクトマネージャーが全体の最適を目指してプロジェクトをコントロールし、小さなズレや間違いを早く修正して全体の最適に向かわせなければならないのです。

仕事をするすべての人が、PMBOKを学習する必要がある
 プロジェクトマネージャーやプロジェクトに関わるメンバーに限らず、プロとして仕事をしていくにはプロフェッショナル責任を強く意識することが大切です。それには時に教育をすること、教育を受けることも必要でしょう。そして、トラブルや失敗を起こしてしまったとき、正直に話すという責任が果たせるようにならなくてはなりません。結果的にそのことで一時的に個人や組織が非難されるかも知れませんが、逆に以前に増して信頼を得られることもあります。

 たとえば、不祥事をいち早く公表して、対策をとった家電メーカーが過去にありました。多大なコストをかけて新聞やテレビ、インターネット、ハガキなどで製品の欠陥を大々的に公表し、すべての消費者を対象に使用の停止と製品の回収を呼びかけました。するとその会社は「公正で誠実な会社である」という評価を得ることができたのです。

 最後に、プロジェクトマネジメントで教科書的に使われるPMBOKは、プロジェクトを進めていく際に、非常に有益で実践的な内容で構成されています。PMBOKはプロジェクトマネージャー向けの書籍ですが、プロジェクトマネージャーだけでなく、プロジェクトに関わるメンバーすべてが理解しておくことで、プロジェクトが成功に向かってスムーズに進むことでしょう。なので、プロジェクトに関わるすべての人に学習することをお薦めします。PMBOKで身につけた知識は、プロジェクトマネジメントに限らず、あらゆる仕事をしていくうえでもとても役立つことでしょう。

プロジェクト成功のポイント
・常に勉強を怠らずさらなる専門性を高めなければならない
・どんなときも、正直に、誠実に対応しなければならない
・プロジェクトメンバー、お客さんなどのステークホルダーと信頼関係を築く
・プロマネだけでなく、プロジェクトの関係者は「PMBOK」を勉強する

*******************

このブログでご紹介したスキル診断が対応しているITスキル標準の職種プロジェクトマネジメントも、このPMBOKに対応しています。
以下の記事もご参照ください。

→ 「スキル診断の結果より~職種・専門分野ごとのスキル状況(1)~」の記事

▼20回にわたって、「プロジェクトマネージャーの育成」を連載してまいりましたが、本日で最後となります。
ご意見やご感想をお待ちしております!
また「このようなテーマを取り上げてほしい」など、お気軽にコメントにてお寄せください!

※コメント・トラックバックは、当社確認後表示となります。
 コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
 コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
(株)富士通ラーニングメディアへのリンク

| | コメント (0) | トラックバック (0)

2007年11月27日 (火)

プロジェクトマネージャーの育成 
不祥事多発! 仕事ができるプロマネの「プロフェッショナル責任」とは (1)

Tsuchiya みなさん、こんにちは
(株)富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア(http://ascii.jp/cate/21/)に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回は、プロフェッショナル責任についてです。

前回の記事はこちら

*******************

より“責任が問われる”時代
 最近、企業の不祥事が明るみに出ることが多くなっています。しかも不祥事を隠そうとして、さらに事態を悪化させてしまうケースが目立ちます。このような社会状況では、会社の姿勢としてコンプライアンス(法令遵守)やアカウンタビリティー(説明責任)が厳しく問われるようになりました。

 かつては、意識しなくてもこのようなプロフェッショナル責任がわざわざ問われることはそれほどありませんでした。しかしあえて問われなくてはならないほど“できていない”ことがあるのです。コンプライアンスというのは、法律などが守られないがためにわざわざ宣言しなければならなくなるということでしょう。

 そこで、プロジェクトマネージャーにもプロとして、自らだけでなくステークホルダーに対して公正かつ誠実な仕事をするようにマネジメントすることが一層求められようになっているのです。

プロフェッショナルとしての責任意識
 では、具体的にプロジェクトマネージャーがプロフェッショナル責任を持つというのは、どういうことなのでしょうか。ここでいうプロとは、ただ専門性が高いことを指しているのではありません。高度な専門性を身につけているのはもちろん、高い技術者倫理を持っていることが含まれます。簡単に言えば正直かつ誠実な仕事ができることです。これらは当たり前のことですが、近年ではないがしろにされている傾向にあります。

 たとえば技術者倫理の低さの現われとして、「技術に疎い人にもわかりやすく説明する」という基本的な責任を忘れられている点があるでしょう。この傾向が顕在化したのは、技術の高度化・専門化が進んだことで、それ以外の理解していない人が増えたことが原因です。相手がわからないからといって、説明をしないで勝手に進めるのはよくありません。わかるように説明したり、素人が気づかない部分は気づかせてあげたりする。そして納得を得てから進めることが非常に重要であり、プロとしての責任です。「説明してもわからないので説明しない」というのは、素人をだましていることと同じです。このことを深く心に留めておてい下さい。

 また、加えてここに必要なプロフェッショナルの意識としては、高い専門性を持っていても、それを活用できないと単なる知識に過ぎないということへの認識です。技術や知識を生かしてこそビジネスになり、プロフェッショナルとしての存在意義がが生まれます。高い技術があり、それが適切な形で生かされることで、社会に役に立つ技術として成り立ちます。

*******************

このブログでご紹介したスキル診断が対応しているITスキル標準の職種プロジェクトマネジメントも、このPMBOKに対応しています。
以下の記事もご参照ください。

→ 「スキル診断の結果より~職種・専門分野ごとのスキル状況(1)~」の記事

次回も引き続き、「プロフェッショナル責任」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
 お気軽にコメントにてお寄せください!

※コメント・トラックバックは、当社確認後表示となります。
 コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
 コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
(株)富士通ラーニングメディアへのリンク

| | コメント (0) | トラックバック (0)

2007年11月21日 (水)

プロジェクトマネージャーの育成 
発注者として必須の意識とは 「調達・マネジメント」 (2)

Tsuchiya みなさん、こんにちは
(株)富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア(http://ascii.jp/cate/21/)に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回も、調達・マネジメントについてです。

前回の記事はこちら

*******************

根底には「任せておけばいいや」の意識の甘さがある
 たとえば最初に調達・マネジメントのルールがしっかり決められていたとしても、プロジェクトの進行フェーズでルールがなし崩し的に乱れ、最終的に納入側が自分たちがやりやすい方法で作業を進めてしまうことも現場ではよくあります。これは、できあがった成果物の外見は繕っているけれども中身は混沌としているため、メンテナンスのときにトラブルが起きるという事態につながりかねません。トラブルは開発段階より、運用時やメンテナンス時に起きることが多いのです。それは、システムは開発期間よりもはるかに長い期間で運用されるからです。そのことをしっかりと念頭に置いて、納入側に中身も整えられた成果物を納品してもらえるようにマネジメントしなければならないと考えて下さい。

 さらに、受注した会社がより下請けに発注するときにはルールがもっと曖昧になりやすくなります。それを防ぐ方法は、まずスタート時に調達側がしっかりとルールを説明し、そしてプロジェクト進行の途中にルールどおりに行なわれているかをチェックすることです。これを行なうだけで、トラブルはかなり防げると思います。

 かつては系列の会社が下請けを育てるという意識がありました。知識や経験は調達側の方がはるかに豊富に持っていたのです。しかし、今では納入側の方が力をつけ、調達側にスキルが足りないという状況でしょう。調達側は、このスキルの差を埋める努力が必要なのかもしれません。

 しかし、調達側がマネジメントできないのは、知識や経験の不足によるところだけではないと思われます。「任せておけばいいや」という甘えや、意識の低さが根底にあるのです。つまり、調達者としての意識がプロフェッショナルではないということでしょう。一方、受注者は「先方はどうせわからないだろう」と高を括っている部分もあるのかもしれません。双方ともに、そのような考えを捨て、ルールに則ってプロジェクトは進めていくべきです。

プロジェクト成功のポイント
・調達先から納入された成果物はきちんと検収する
・調達契約を結んだらプロジェクトの特に設計や運用ルールを納入者に説明する
・プロジェクトの進行過程の途中段階でも調達先の状況をチェックする

*******************

このブログでご紹介したスキル診断が対応しているITスキル標準の職種プロジェクトマネジメントも、このPMBOKに対応しています。
以下の記事もご参照ください。

→ 「スキル診断の結果より~職種・専門分野ごとのスキル状況(1)~」の記事

次回は、「プロフェッショナル責任」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
 お気軽にコメントにてお寄せください!

※コメント・トラックバックは、当社確認後表示となります。
 コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
 コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
(株)富士通ラーニングメディアへのリンク

| | コメント (0) | トラックバック (0)

2007年11月20日 (火)

プロジェクトマネージャーの育成 
発注者として必須の意識とは 「調達・マネジメント」 (1)

Tsuchiya みなさん、こんにちは
(株)富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア(http://ascii.jp/cate/21/)に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回は、調達・マネジメントについてです。

前回の記事はこちら

*******************

一括作成請負で、いわば「丸投げ状態」
 プロジェクトというものは必要な作業のすべてを内部でまかなうことはほとんどなく、外部の手を借りることになります。特に日本のIT業界の場合は、一括作成請負という契約方法で外部に作業を丸ごと任せることがよくあります。それは、発注する案件の専門性が高く、自社に十分な知識や技術を有している人材がいないので、専門家に任せてしまおうという考えによるものです。しかし、そうするといわゆる「丸投げ状態」になってしまい、意図していたものと違う成果物が納品され、「こんなものを頼んだのではない」とトラブルになる場合があります。これでは、調達側は成果物の納品日が遅れてしまうおそれが出てしまうし、納入側には手戻り作業が発生してしまうでしょう。両者ともに不利益が生じるのです。

 また、トラブルの原因となるのが、納品時の検収不十分があります。検収を怠ることで、システム稼働後のメンテナンス時に問題が発生するケースとなるのです。この場合、システムがブラックボックスのままなので、トラブルの原因を解明するのが非常に困難となります。

イニシアティブを持ってルールの決定と説明ができていない
 プロジェクトというものは、多くの会社が関わります。そして、そこには製品を調達する側と納入する側があり、調達する側にはそれを管理する「調達・マネジメント」が必要となります。PMBOKガイドには「外部の組織(購入者)が実行組織(納入者)からプロジェクトを取得する際に発行する契約書の管理、およびプロジェクト・チームに課される契約上の責務の管理を行なう」と書かれています。つまりプロジェクトの本体が外部からサービスや成果物などを調達する場合、発注、契約などスタート時点から納入まですべての過程で、決められたルールどおりにできているかを管理する必要があるということです。

 調達・マネジメントでトラブルが起こるのは、契約管理のときにルール決めがしっかりなされていないからです。何をどのように、いつまでに、そしていくらでということだけでなく、細かい設計ルールや運用の方法なども決める必要があります。そして、これらのことは調達側がイニシアティブを持って行なわなければなりません。しかしながら、冒頭で述べたように、はじめに決めておく必要がある事柄に関して調達側がよくわかっていないケースがあり、その結果「丸投げ」となることが多いようです。

*******************

このブログでご紹介したスキル診断が対応しているITスキル標準の職種プロジェクトマネジメントも、このPMBOKに対応しています。
以下の記事もご参照ください。

→ 「スキル診断の結果より~職種・専門分野ごとのスキル状況(1)~」の記事

次回も引き続き、「調達・マネジメント」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
 お気軽にコメントにてお寄せください!

※コメント・トラックバックは、当社確認後表示となります。
 コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
 コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
(株)富士通ラーニングメディアへのリンク

| | コメント (0) | トラックバック (0)

2007年11月13日 (火)

プロジェクトマネージャーの育成 
危機管理はまだまだ甘い? 「リスク・マネジメント」の第一歩 (2)

Tsuchiya みなさん、こんにちは
(株)富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア(http://ascii.jp/cate/21/)に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回も、リスク・マネジメントについてです。

前回の記事はこちら

*******************

プロジェクトの途中にこそ、リスク・マネジメントは必要
 このリスク分析は、プロジェクトのスタート時にはしっかり行なわれているようですが、プロジェクトの途中ではあまり行なわれていないようです。そのため、途中で発生するリスクについては対策が練られておらず、トラブルが起きたときに対応する問題解決型のマネジメントになってしまいます。プロジェクトは進行していくに従って状況が変わっていくもので、それに合わせてリスクも変化します。したがって、プロジェクトの途中にもリスク分析をし、対策を立てる必要があります。定例の会議の中で、進捗について報告するだけでなく、リスクについても話し合う機会を作るとリスクを共通認識できることでしょう。プロジェクトの全体を通して、リスクについて分析予測し、対策を立て、リスクを追跡することで、はじめてリスク・マネジメントができていると言えるのです。

リスクを「ゼロ」にするという間違った発想
 リスク・マネジメントの目的は、リスクをゼロにするのが目的ではありません。その影響を最小限に抑えることにあります。リスクの判断基準は0%か100%ではなく、五分五分でその五分のリスクについて小さくする対策を取るという考え方が必要です。

 プロジェクトのリスク・マネジメントでよく起こる問題としては、人材の確保があります。たとえば、あるプロジェクトの成功にはAというエンジニアの技術が必要だとします。そのエンジニアAは、現在別のプロジェクトに関わっていて、終了後にプロジェクトに参加してくれる段取りになっています。このケースでは、リスクの1つとして「先のプロジェクト作業が延びてエンジニアAがプロジェクトに参加できなくなる」ことが考えられます。この場合は、今関わっているプロジェクトのマネージャーに、エンジニアAが次のプロジェクトに必ず必要であることをしっかり伝えプレッシャーを与えたり、もしものことを考え、エンジニアAの次に適任だと思われるエンジニアBの手当をするのがリスク・マネジメントです。こうしてプロジェクトのリスクを小さくしていくのです。

 リスクはゼロにはならないし、ゼロを目指すというものでないことは先に解説しましが、「新技術適用を検討する」プロジェクトでは、新技術適用のリスクをゼロにするために、はじめから新技術を諦めるなどの安全な方法ばかりを選択していては、よりよい成果物はできないし、新しいことにチャレンジできません。最善のものを目指しつつ、その中でリスクを小さくしていくのがリスク・マネジメントのあるべき姿と言えるでしょう。

 最後に、リスク分析をし、ある事柄がリスクが大きいと判断しても、それを承知の上でプロジェクトを進めていく場合があります。これはプロジェクトマネージャーの判断ではなく、組織としての判断が下された場合です。組織としては上を目指したり、政治的な判断により、リスクを受け入れることが多々あります。このようにリスクについての考え方は、プロジェクトマネージャーの判断を超えるケースがあることを承知しておいてください。

*******************

このブログでご紹介したスキル診断が対応しているITスキル標準の職種プロジェクトマネジメントも、このPMBOKに対応しています。
以下の記事もご参照ください。

→ 「スキル診断の結果より~職種・専門分野ごとのスキル状況(1)~」の記事

次回は、「調達・マネジメント」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
 お気軽にコメントにてお寄せください!

※コメント・トラックバックは、当社確認後表示となります。
 コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
 コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
(株)富士通ラーニングメディアへのリンク

| | コメント (0) | トラックバック (0)

2007年11月12日 (月)

プロジェクトマネージャーの育成 
危機管理はまだまだ甘い? 「リスク・マネジメント」の第一歩 (1)

Tsuchiya みなさん、こんにちは
(株)富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア(http://ascii.jp/cate/21/)に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回は、リスク・マネジメントについてです。

前回の記事はこちら

*******************

リスクに対する認識が甘さが及ぼす影響
 新しい事業を立ち上げたり、プロジェクトを進めたりするのにリスクは付き物です。しかし、ある事柄がリスクであるとわかっているにも関わらず、先送りにしてしまう事があります。それは「直接被害が及ばない」「まだ大丈夫だ」と考えてしまうからでしょう。でもそうすると、リスクの拡大、対策の選択肢の減少、手戻り作業の発生、新たなリスクの表面化などさまざまな悪い事態を招くことになります。プロジェクトの成功は、このリスクにどう対応していくかにかかっています。これができないと、プロジェクトを進めるどころか、問題解決だけに終始してしまう可能性が高いでしょう。

ほかのプロマネ、メンバー、ステークホルダーから多角的な視点を得る
 リスク・マネジメントという考えを強調するようになったのは、ここ数年のことです。それまではトラブルが起こるたびに解決していくという問題解決の考え方が一般的でした。つまり、「モグラたたき」のような解決方法だったのです。しかし、これではプロジェクトを進めることよりも問題解決に時間とコスト、労力を取られることになりプロジェクトは疲弊してしまいます。そこで起こりうる問題を予測し、事前に対策しておいた方が賢明であるという考えに基づいたのが「リスク・マネジメント」であったのです。

 このリスク・マネジメントで、まず大切なことはプロジェクトにどんなリスクがあるのかを洗い出す作業をすることです。コストは予算内に収まるのか、スケジュールどおり進むのか、人手は足りているのか、どんなリソースが必要なのか、さまざまな方面からの洗い出しをするのです。その際、他のプロジェクトに関わったプロジェクトマネージャーに「どのようなリスクが考えられるか」過去の経験を聞くことをお勧めします。つまり、ここでもこれまで何度も解説してきた「過去のプロセス資産を生かす」ことが大切となるのです。また、プロジェクトのメンバーだけでなく、ステークホルダーも含めてこのリスクの洗い出しをするとよいでしょう。見る眼が違ってくると問題の視点が変わり、新たなリスクが発見できるはずです。

定性的リスク分析と定量的リスク分析
 さらにリスク・マネジメントにおいて大切なことがもう1つあります。前述のリスクの洗い出しだけでなく、リスクをしっかり認識するための「リスク分析」ができることです。

 具体的なリスク分析の方法には、定性的リスク分析と、定量的リスク分析があります。まず定性的リスク分析については、PMBOKガイドによると「リスクの発生確率と影響度を評価し、組み合わせ、この後の分析や対処のためにリスクの優先順位付けを行なう」と書かれています。つまり、リスクには大小があるので、相対的にランキングをつけて優先すべきリスクとそうでないリスクを分けるのです。また、定量的リスク分析は「識別したリスクがプロジェクト目標の全体に対して与える影響を数値的に分析する」とあり、定性的分析で優先度が識別されたリスクに対して、それぞれがどれくらい重要なのかを今度は認識しやすいように数値で表し分析します。つまり各リスクの対応にどの程度のリソース(金額・時間・人材など)が必要となるのかを判断し、この分析をもとに優先順位をつけて対策を立てていくのです。
*******************

このブログでご紹介したスキル診断が対応しているITスキル標準の職種プロジェクトマネジメントも、このPMBOKに対応しています。
以下の記事もご参照ください。

→ 「スキル診断の結果より~職種・専門分野ごとのスキル状況(1)~」の記事

次回も引き続き、「リスク・マネジメント」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
 お気軽にコメントにてお寄せください!

※コメント・トラックバックは、当社確認後表示となります。
 コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
 コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
(株)富士通ラーニングメディアへのリンク

| | コメント (0) | トラックバック (0)

2007年11月 7日 (水)

プロジェクトマネージャーの育成 
クライアントとの言った、言わない問題…… 情報伝達の「コミュニケーション・マネジメント」 (2)

Tsuchiya みなさん、こんにちは
(株)富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア(http://ascii.jp/cate/21/)に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回は、前回に引き続き、コミュニケーション・マネジメントについてです。

前回の記事はこちら

*******************

悪い情報をクライアントへ開示する重要性
 コミュニケーション・マネジメントの失敗でよくあることは、チーム・マネジメントの回(注1)でも解説した「悪い情報が行き渡らない」ケースの存在です。社内で対策を考えて対処し、それからクライアントに伝えるという段取りを踏むことも状況によっては仕方ないですが、基本的に悪い情報はできるだけ早く伝えるべきです。特に昨今のプロジェクトは専門性の高いものが増えているため、専門的なところは専門家に任せようという社会的な流れがあります。そのため、プロジェクトをほぼ丸投げで任されることもあります。この場合でも、高い信頼関係の下でプロジェクトを推進できるように、悪い情報ほどきちんとクライアントに開示していくことが重要です。

100%正確に伝わる情報はないという認識
 これまでの内容を踏まえコミュニケーション・マネジメントのポイントをまとめると、必要とされる人に的確な情報を適切な方法で送ることが大切だということですが、しかしこれらは「情報が受け手に100%正確に伝わることはない」ことを常に前提とされるべきです。チームメンバー以外のクライアントに情報を伝える場面は、このような意識を一層持つ必要があります。

 たとえば、受け手は届いた情報を自分のフィルターに通して理解しようとします。その際に、情報はそぎ落とされたり、受け手側の都合のよいように解釈されたりするため、伝達側の意図通りに伝わることは、まずないでしょう(図1参照)。そこで伝達した後には、受け手が「どう受け取ったか」「間違いなく意図が伝わっているか」を確認し、合意するフォローが重要になります。これを怠るとよくある“言った、言わない問題”が起こり、プロジェクトの成功どころか、信頼関係の崩壊につながりかねません。念入りに行ないましょう。

200711071_4 






図1:伝達側のメッセージは、受け手側のフィルターを通って認識される。また、受け手側のフィードバックの際には、伝達側のフィルターを通ることになる。

クライアントとの“言った、言わない問題”を防ぐために
 情報共有のよい方法として、会議では議事録をつけ、それを双方が確認し、合意することは特に大切です。議事録をつけるだけでなく、会議自体を録音するのもいいでしょう。そうすれば、それを元に議事録を作ることもできるし、万一に“言った、言わない”の水掛け論に発展しても、録音した内容で確認できます。会議で誰もが責任ある発言をするような効果もあるでしょう。

 このように、多くの人が関わるプロジェクトだからこそ、メールなのか、会議なのか、どれくらいの頻度で情報交換を行なうかなどのコミュニケーションルールを決めることは大切です。相手の合意と確認はプロジェクトの命運を左右する重要なポイントとります。

プロジェクト成功のポイント

・悪い情報は次の手を打ちやすくするために、早め、早めに報告する
・コミュニケーションは100%相手に伝わらないことを前提に、確認・合意をする
・メールなのか、会議なのか、どれくらいの頻度で情報交換を行なうかなどのコミュニケーションルールを決める

注1:チーム・マネジメントの回は、こちらからご参照ください。
プロジェクトマネージャーの育成 メンバーのモチベーションを高めてチームを活性化させる「チーム・マネジメント」のあり方(1)

プロジェクトマネージャーの育成 メンバーのモチベーションを高めてチームを活性化させる「チーム・マネジメント」のあり方(2)

*******************

このブログでご紹介したスキル診断が対応しているITスキル標準の職種プロジェクトマネジメントも、このPMBOKに対応しています。
以下の記事もご参照ください。

→ 「スキル診断の結果より~職種・専門分野ごとのスキル状況(1)~」の記事

次回は、「リスク・マネジメント」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
 お気軽にコメントにてお寄せください!

※コメント・トラックバックは、当社確認後表示となります。
 コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
 コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
(株)富士通ラーニングメディアへのリンク

| | コメント (0) | トラックバック (0)

2007年11月 6日 (火)

プロジェクトマネージャーの育成 
クライアントとの言った、言わない問題…… 情報伝達の「コミュニケーション・マネジメント」 (1)

Tsuchiya みなさん、こんにちは
(株)富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア(http://ascii.jp/cate/21/)に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回は、コミュニケーション・マネジメントについてです。

前回の記事はこちら

*******************

ステークホルダーを含むコミュニケーション
 前々回、前回の「チーム・マネジメント」(注1)では、情報の重要性と、正しく情報が伝えられる環境づくりの大切さを解説しました。 しかし、このチーム・マネジメントとは主にメンバー同士やメンバーとプロジェクトマネージャーの間のマネジメントなのですが、今回解説するコミュニケーション・マネジメントは、それ以外のステークホルダーも含むマネジメントです。つまり、プロジェクトに関わるすべての人とのコミュニケーションをマネジメントするものです。チーム・マネジメントができている場合でも、コミュニケーション・マネジメントの欠如によってプロジェクトがうまくいかない場合があります。

 PMBOKガイドにも、コミュニケーション・マネジメントについて「プロジェクトを成功させるために必要とされる人と情報を結びつける重要な役割を果たす」と書いてあります。

コミュニケーション・マネジメントのよくある失敗、メールにおける情報伝達の落とし穴
 ステークホルダー含むすべての人間をマネジメントするコミュニケーション・マネジメントでは、関係者と直接会えないため、その情報伝達方法をメールに依存せざるえない場面も多いでしょう。その際「カーボンコピー(CC)」の機能を使って、関係のある人すべてに同じメールを送ることがよく行なわれるはずです。これは関係者全員に情報を行き渡らせるという意味合いにおいては、効果がある方法と言えます。しかし、行き交うメールがあまりに膨大だと、すべてのメールに詳細に目を通せないということが起こります。それでは、ただ情報を送っただけで、情報を伝えていることにはなりません。

 これはコミュニケーション・マネジメントの欠如と言えます。特にプロジェクトの終盤は、確認する事柄が多くなり情報の量も増え、目を通さなければならない資料やデータが次々にメールに添付されてきます。それに加え、1つ1つの情報の重要度が増すため、重大なトラブルが発生しかねないので注意が必要です。

 また、この伝えるべき情報についでですが、「必要な情報」というのは、受け手のポジションやプロジェクトの進行段階によって異なるという意識を強く持つべきです。たとえば、新しいシステムを導入する場合を考えると、情報の受け手がクライアントの進捗管理担当者なら期日どおりに稼働するか進捗状況が気になるし、予算管理担当者ならコストに関する情報が必要になります。このように情報は受け手によって異なり、さらにプロジェクトの初期段階や終盤など時期によっても異なるので、単一に情報を伝達しても意味がないと考えて下さい。

注1:チーム・マネジメントの回は、こちらからご参照ください。
プロジェクトマネージャーの育成 メンバーのモチベーションを高めてチームを活性化させる「チーム・マネジメント」のあり方(1)

プロジェクトマネージャーの育成 メンバーのモチベーションを高めてチームを活性化させる「チーム・マネジメント」のあり方(2)

*******************

このブログでご紹介したスキル診断が対応しているITスキル標準の職種プロジェクトマネジメントも、このPMBOKに対応しています。
以下の記事もご参照ください。

→ 「スキル診断の結果より~職種・専門分野ごとのスキル状況(1)~」の記事

次回も引き続き、「コミュニケーション・マネジメント」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
 お気軽にコメントにてお寄せください!

※コメント・トラックバックは、当社確認後表示となります。
 コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
 コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
(株)富士通ラーニングメディアへのリンク

| | コメント (0) | トラックバック (0)

2007年10月31日 (水)

プロジェクトマネージャーの育成 
メンバーのモチベーションを高めてチームを活性化させる「チーム・マネジメント」のあり方(2)

Tsuchiya みなさん、こんにちは
(株)富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア(http://ascii.jp/cate/21/)に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回は、前回に引き続きチーム・マネジメントについてです。

前回の記事はこちら

*******************

チーム・マネジメント、プロジェクトマネージャーがするべきこと
 コミュニケーションの核となるのは、よく言われている「ホウレンソウ(報告・連絡・相談)」です。新入社員研修にもよく組み込まれ、入社当初はマメにできている人が多いでしょう。しかし、社会人経験を重ねていくと徐々にホウレンソウができなくなる傾向があります。その原因には、報告する側のタイミングの悪さと、受ける側の聞く体制や反応に問題があると考えられます。

 プロジェクトマネージャーとしては、ホウレンソウができない原因を「報告する側のタイミングの悪さ」とは捕らえず、チームの環境に問題がある─本当のことが言えないチームの雰囲気─だと捉えるべきでしょう。「タイム・マネジメント」の回(注1)でも解説したように、問題を報告しやすい、相談しやすい雰囲気が作りができていないのです。よいことでも悪いことでも、本当のことが言える環境を作るのが大切であり、問題が発生する前、また問題が起きそうなときにプロジェクトマネージャーに報告・相談できる環境を作ることが重要です。

今から簡単にできるチーム・マネジメント向上方法
 プロジェクトマネージャーはチームをとりまとめるために、よくも悪くもメンバーからの正しい情報を聞く必要があり、メンバーが報告しやすい環境を作るべきであることは先にも触れました。そこで、すぐにでもできて効果のある簡単な方法を紹介します。

 まず、机の上をきれいにすること。机が書類で溢れていたりすると、メンバーは「プロジェクトマネージャーは忙しい」と思ってしまい、ホウレンソウをしにくくなります。

 また、プロジェクトマネージャーからメンバーへ呼びかける、つまりホウレンソウすることは効果的です。普通ホウレンソウというと、メンバーからプロジェクトマネージャーへの下から上への一方通行と考えるかもしれませんが、積極的に上から下へ、つまり自らが見本を示すことで、ホウレンソウはメンバーに浸透していくことでしょう。

 メンバーにホウレンソウさせるテクニックを使うことも時には必要です。簡単な聞き出しのテクニックとしては、メンバーの話した事を繰り返す「オウム返し」の方法があります。単純な方法のようですが、ただメンバーの言った言葉を繰り返しているだけなのに、話す側は認められたように感じ、もっと話しをするようになります。

 さらに、仕事を離れたところでのスポーツ大会や飲み会もチーム・マネジメントに効果があるでしょう。社外でメンバー同士が顔を合わせることで、仕事以外の横顔を見ることができ、「あ、この人はこんな側面があるのか」と発見し、親近感が生まれます。

 このようにプロジェクトマネージャーは、ホウレンソウがしやすい環境作りに努めなければなりません。それと同時に、メンバーのやる気が低下するような状況を回避していく必要もあります。例としては、プロジェクトの進行が遅れる原因で多い、メンバーが作業について悩んでいる状況です。悩みに悩んで出した結果が間違っていることもよくあり、その時はプロジェクトマネージャーはやり直しを言い渡さなければなりません。これはメンバーのモチベーションを大きく低下させます。そうならないためにも、プロジェクトマネージャーはメンバーが迷っているときに、また普段からも声をかけるなどして方向性を示したり、ジャッジしてあげることが大切です。

プロジェクト成功のポイント
・メンバーがコミュニケーションしやすい環境をつくる
・プロジェクトマネージャー自らがホウレンソウをする
・プロジェクトマネージャーはチームの行動を観察し早いジャッジメントを心がける

注1:タイム・マネジメントの回は、こちらからご参照ください。
プロジェクトマネージャーの育成 目先の進捗に捕らわれず、大きな視点で見るのが「タイム・マネジメント」(1)

プロジェクトマネージャーの育成 目先の進捗に捕らわれず、大きな視点で見るのが「タイム・マネジメント」(2)

*******************

このブログでご紹介したスキル診断が対応しているITスキル標準の職種プロジェクトマネジメントも、このPMBOKに対応しています。
以下の記事もご参照ください。

→ 「スキル診断の結果より~職種・専門分野ごとのスキル状況(1)~」の記事

次回は、「コミュニケーション・マネジメント」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
 お気軽にコメントにてお寄せください!

※コメント・トラックバックは、当社確認後表示となります。
 コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
 コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
(株)富士通ラーニングメディアへのリンク

| | コメント (0) | トラックバック (0)

2007年10月30日 (火)

プロジェクトマネージャーの育成 
メンバーのモチベーションを高めてチームを活性化させる「チーム・マネジメント」のあり方(1)

Tsuchiya みなさん、こんにちは
(株)富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア(http://ascii.jp/cate/21/)に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回は、チーム・マネジメントについてです。 

*******************

チームが機能しないという事態
 プロジェクトのメンバーが増えるほど、困難になるのがチーム・マネジメントです。プロジェクトはメンバーが連携して進めていくため、メンバー同士やメンバーとプロジェクトマネージャーとの意思の疎通の欠如は、そのままプロジェクト進行の妨げになります。特にチームにとって不都合な情報は滞りやすく、問題が膨れ上がり表面化してからプロジェクトマネージャーの元へ到達、その時はすでに収拾が困難な状況に陥っているという失敗が起こりがちです。

 また、一度プロジェクトにとってよい情報だけが流れ、悪い情報が隠される傾向が生まれてしまうと、さらに悪い情報がプロジェクトマネージャーの元に届けられないチーム状態になってしまうこともあります。こうなるとプロジェクトに内包された問題がより大きくなってしまい、チームは混沌とし、プロジェクトは破綻を来す恐れも出てきます。

 そのため、プロジェクトマネジメントで重要とされるのが、チーム・マネジメントなのです。

チーム・マネジメント、プロジェクトマネージャーがするべきこと
 メンバーのやる気を起こさせ、チーム力を高めるのもプロジェクトマネージャーの仕事であり、チーム・マネジメントです。それにはメンバーがお互いに信頼できる人間関係を築けていることが大前提になります。信頼関係があればメンバーは活力を持って同じ目的に向かってプロジェクトを進めることができます。そうするとメンバーは自分の担当している仕事の意義が認識できるようになり、それがやる気につながるでしょう。

 たとえば、チームにとって必ず必要となる情報を、人の体内における「酸素」だと考えてみてください。この酸素はチームに活力を与えてくれる存在であり、各メンバーに酸素が行き届かないとチームは死んでしまいます。そこで、酸素という情報を行き渡らせるのに「血液」が必要になるわけです。この血液の役割を担うのが、コミュニケーションです。つまり、チーム内のコミュニケーションがうまくいくことで、ひいては情報がチーム全体に行き渡ります。それが、メンバー1人1人にチームがどこに向かっているのか、そして自分は何をすべきかを明確にさせ、チームとしての統一感が生まれてくるのです。

*******************

このブログでご紹介したスキル診断が対応しているITスキル標準の職種プロジェクトマネジメントも、このPMBOKに対応しています。
以下の記事もご参照ください。

→ 「スキル診断の結果より~職種・専門分野ごとのスキル状況(1)~」の記事

次回も、ひき続き「チーム・マネジメント」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
 お気軽にコメントにてお寄せください!

※コメント・トラックバックは、当社確認後表示となります。
 コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
 コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
(株)富士通ラーニングメディアへのリンク

| | コメント (0) | トラックバック (0)

2007年10月25日 (木)

プロジェクトマネージャーの育成 
「品質・マネジメント」でプロセスを管理して品質を保つ (2)

Tsuchiya みなさん、こんにちは
(株)富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア(http://ascii.jp/cate/21/)に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回は、前回に引き続き品質・マネジメントについてです。

前回の記事はこちら

*******************

品質監査は嫌ってはいけない
 品質保証の方法の1つに「品質監査」あります。品質監査とはプロセスがルールどおりに進められているかをチェックする作業で、通常プロジェクト外の第3者が行ないます。工程の途中で定期的に行なうことで、ルール違反を発見し、プロジェクトが違う方向に進むことや品質の維持が困難になる状況を回避できます。特に、上流工程は、ルールに反して簡単に済ませようと思えばできてしまうので、しっかりした管理が必要となります。

 しかし、このように重要な作業にも関わらず、品質監査はしばしばプロジェクトマネージャーにはイヤがられます。それは、内部で品質保証が徹底できていないということがあるかもしれません。しかし、品質監査をする監査人からの意見は、仮に厳しく指摘されたとしても真摯に受け止めるべきです。その指摘は、プロジェクトをよりよい方向に導くでしょう。

監査人に意見を求めるくらいの姿勢が大切
 現場でも品質監査で何も指摘されなければそれを“よかった”と考える傾向が強いようです。しかし、指摘が何もないということは、それ以上、品質が向上することはないことを意味すると捉えてください。そして実際は、指摘することがないというのはありえないはずです。無駄なプロセスはないか、改善するところはないかなどを監査人が指摘し、プロセスをよりよくするのが品質監査の本来の役割だと考えるといいでしょう。

 プロジェクトマネージャーは、進んで品質監査を受ける姿勢が大切です。常にルールどおりにプロジェクトを進行させていれば、本当は何の問題もなく、監査人にも「何も指摘することがない」と言われることでしょう。でもそこで、きっと何かあるはずだと考えて、「他のプロジェクトではどんなことをしていましたか」とか「これまでにうまく行った方法はありますか」と聞き出すくらいの意識があってもよいと思います。品質監査はダメな点を指摘するためではなく、改善のための意見を聞く機会だということを今一度考えてみてください。監査人の指摘がよりよいプロセスを生み、そのプロセスによって品質が高まるのです。

プロジェクト成功のポイント
・品質保証はプロセスを管理することで、成果物の品質を保つという考えである
・品質監査はよりよい品質のために喜んで受けるべきである
・あまり厳しいルールを決めてしまうと、品質保証が機能しない

*******************

このブログでご紹介したスキル診断が対応しているITスキル標準の職種プロジェクトマネジメントも、このPMBOKに対応しています。
以下の記事もご参照ください。

→ 「スキル診断の結果より~職種・専門分野ごとのスキル状況(1)~」の記事

次回は、「チーム・マネジメント」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
 お気軽にコメントにてお寄せください!

※コメント・トラックバックは、当社確認後表示となります。
 コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
 コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
(株)富士通ラーニングメディアへのリンク

| | コメント (0) | トラックバック (0)

2007年10月23日 (火)

プロジェクトマネージャーの育成 
「品質・マネジメント」でプロセスを管理して品質を保つ (1)

Tsuchiya みなさん、こんにちは
(株)富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア(http://ascii.jp/cate/21/)に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回は、品質・マネジメントについてです。 

*******************

品質確保のためのルールが現場で守られていない
 プロジェクトは多くのメンバーの手で進められるので、最終成果物の品質を確保するために、プロセスの手順や進め方などのルールを決めます。各メンバーがそのルールに従って仕事をすれば、そのプロジェクトが成功する可能性が高くなります。

 しかし現場では、プロセスが進むにつれてメンバーが徐々に自分なりのやり方で進めるようになってしまうことがよくあります。その結果、システムの保守管理作業の際、ルールどおりに修正を加えたにも関わらず、不具合が生じるなどのトラブルが起こります。これではプロジェクトが完了したとしても、プロジェクトの成功とは言えません。

ルールを守ることの重要性をメンバーが理解していない
 このような事態を防ぐため重要となるのが、PMBOKガイドにおける品質・マネジメント(注1)の「品質保証」です。品質保証は、プロセスを管理して最終的に製品の品質を保つという、つまりプロジェクトのスタート時や途中で決められたルールどおりに作業が行なわれているかを管理するというものです。これらがきちんと行なわれていれば、自ずと最終成果物の高い品質につながります。

注1:品質・マネジメント
国際資格「PMP(Project Management Professional)」のバイブルとも呼ばれるPMBOKガイドに書かれた9つの知識エリアの中の1つ。プロジェクトが意図するニーズを満足させるために必要なプロセス群のこと。プロセスには、品質計画、品質保証、品質管理の3つがある。
 そこで品質・マネジメントのポイントとなるのが、このプロセス―どういう手順や工程で仕事を進めていくか―のルールを決めることと、どうやってそのルールに則ってプロジェクトを進めていくかです。

 たとえば冒頭で述べたような、プロジェクトのメンバーがスタート時にきちんと守れていたルールを、時間が経過するに従って自分がやりやすい方法に変えてしまうというケースは、その原因の1つとして「なぜルールどおりに進めないといけないのか」ということをメンバーが真に理解していないことが考えられます。

 プロジェクトマネージャーは、プロジェクト開始時にメンバーの理解を得る努力が必要でしょう。また、ルールが守られない原因として、ルールが厳しすぎることも考えられます。しっかりルールを決めるのは重要ですが、あまりにも厳しすぎるとメンバーの首をしめることになります。厳しすぎるルールはあってないが如しになるのです。
*******************

このブログでご紹介したスキル診断が対応しているITスキル標準の職種プロジェクトマネジメントも、このPMBOKに対応しています。
以下の記事もご参照ください。

→ 「スキル診断の結果より~職種・専門分野ごとのスキル状況(1)~」の記事

次回も、ひき続き「品質・マネジメント」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
 お気軽にコメントにてお寄せください!

※コメント・トラックバックは、当社確認後表示となります。
 コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
 コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
(株)富士通ラーニングメディアへのリンク

| | コメント (0) | トラックバック (0)

2007年10月18日 (木)

プロジェクトマネージャーの育成 見通しの甘さを排除する正しい「コスト・マネジメント」のあり方(2)

Tsuchiya みなさん、こんにちは
(株)富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア(http://ascii.jp/cate/21/)に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回は、前回に引き続きコスト・マネジメントについてです。

前回の記事はこちら

*******************

リスクを考慮した予備費を計上していない
 コストマネジメントのポイントは、見積もりの予算に予備費を組み込むことです。その予備費はリスクを考慮して計上します。一般的には+10%~15%程度の確保は必要です。予備費を取れば、オーバー分を予備費が吸収し、問題も起こらないかもしれません。予備に使えるお金がないと、コストを抑える手段を選択しがちになり、プロジェクトマネージャーの打てる手数も少なくなってしまいます。

 予備費に関しては受注側が確保するのはもちろんですが、発注者側も確保します。受注側、発注側の双方が予備費を持っていれば、それぞれの問題やリスクへの対応が可能になります。

 また、ITのプロジェクトでよくあるのが“とりあえず進めましょう”と曖昧なままプロジェクトを進行してしまうことです。ビルや橋を造る建設業と違って、ITの場合、後でなんとかなる(プログラムの修正はすぐできる)という意識が発注者側にあります。発注者はあまりお金もかからず、すぐに直せるだろうと考えがちなのです。しかし、もちろん簡単には修正できませんし、修正するには相応のコストがかかります。さらには、システムの構造も劣化してしまいます。一度やった仕事をまたやり直す修正の手戻り作業をするのが1番よくない事態でしょう。本来その時間でほかの仕事ができるので、機会を損失していることにもなります。手戻り作業で作り直すことは2倍のコストがかかると考えてください。それに、手戻り作業はメンバーにとって精神的にもつらいものです。

スコープがコストに最も影響する
 コストに最も影響するのは、以前解説したスコープ(注1)です。スコープが曖昧だとコストの見積もり精度が低く、前述のような手戻り作業も発生する可能性が高くなります。できるだけ早い段階でスコープの曖昧さを排除し、確実なものにしていくことに努めるべきです。スコープの早期確定、そしてリスクの想定、問題の早期発見。これらの意識が、結果的にコストの超過を防止していくことにつながります。

プロジェクト成功のポイント
・受注側、発注側双方が予備費を必ず確保する。
・見積もりの算出の場合は組織のプロセス資産を生かしコストの項目を漏らさないようにする
・コスト見積もりは精度を上げるために繰り返し見積もる。

注1:スコープの回は、こちらからご参照ください。
プロジェクトマネージャーの育成 WBS作成で、成果物と作業内容を明確にするのが「スコープマネジメント」(1)

プロジェクトマネージャーの育成 WBS作成で、成果物と作業内容を明確にするのが「スコープマネジメント」(2)

*******************

このブログでご紹介したスキル診断が対応しているITスキル標準の職種プロジェクトマネジメントも、このPMBOKに対応しています。
以下の記事もご参照ください。

→ 「スキル診断の結果より~職種・専門分野ごとのスキル状況(1)~」の記事

次回は、「品質・マネジメント」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
 お気軽にコメントにてお寄せください!

※コメント・トラックバックは、当社確認後表示となります。
 コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
 コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
(株)富士通ラーニングメディアへのリンク

| | コメント (0) | トラックバック (0)

2007年10月16日 (火)

プロジェクトマネージャーの育成 
見通しの甘さを排除する正しい「コスト・マネジメント」のあり方(1)

Tsuchiya みなさん、こんにちは
(株)富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア(http://ascii.jp/cate/21/)に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回は、コスト・マネジメントについてです。 

*******************

コストに対する見通しが甘い
 大きな規模のプロジェクトほどコストは大きくなります。そして規模が大きくなればなるほど、予算の全体像を把握するのが難しくなり、プロジェクトが進むにつれてコストが拡大、気がついたら予算オーバーという失敗が起きやすくなるのです。しかし、プロジェクトの途中での仕様変更の発生やスケジュール変更は致し方ない部分はありますが、予算オーバーだけは避けなければなりません。

 予算オーバーの原因として多いのは、予算を組むときにコストを算出する項目の洗い出しが不十分で、計上すべき項目が漏れていたり、リスクを想定した予備費を確保していなかったりすることです。

 ユーザー(発注側)にとって、一度稟議を通して決定した後の予算の追加は、再度1つずつ稟議を通していかなくてはならないので非常に手間がかかりますし、また認められないこともあります。そういった際に、受注側がオーバーしたコストを負担せざるを得ない状況も発生し、WIN-WINの関係が成り立たなくなってしまいます。それではプロジェクトは完了しても「失敗」と言わざるを得ないでしょう。

スタート時のコスト見積もりは1回のみ
 コストについては、コストを管理するためのコスト・マネジメントが必要です。コスト・マネジメントとはコストの見積もり、予算化、コントロールからなる管理プロセスです。特に見積もりについては、最初から正確な見積もりはできないことを認識する必要があります。プロジェクトスタート時の見積もりはPMBOKガイドでも「-50%から+100%の超概算」とあり、それが「概算見積もり」→「予算見積もり」→「確定見積もり」(図1参照)と経過を経て金額がフィックスされていくことが書かれています。見積もるタイミングで手法が異なり、作業項目が明らかになっていくことによって見積もりの精度が徐々に上がっていきます。

Pmbok03_zu01_300x_2

図1:PMBOKガイドで解説される見積もり精度による分類。
プロジェクトが進展するにつれて、見積もり精度は高くなっていく

 プロジェクトというものはその進行に従って、何をすべきか、そしてどれくらいの時間がかかり、必要なリソースは何かなども判明していきます。そこからそれぞれのコストが明らかになるのです。注意すべきことは、見積もり算出のための項目を漏らさずリストアップするということ。項目が漏れると、“予算オーバー”の失敗となる可能性があります。では、項目を漏らさないためにはどうすべきなのか。そこで、WBSの回でも解説した(注1)「組織のプロセス資産」を生かすことが必要となります。つまり、コストに関しても重要なことは、曖昧さをなくすこと、過去の教訓を生かすことが重要なのです。このようにコスト・マネジメントは特にプロジェクトの利益が上がるのか、また赤字になるのかにダイレクトに影響しますので確実にやりましょう。

注1:WBSの回は、こちらからご参照ください。
プロジェクトマネージャーの育成 WBS作成で、成果物と作業内容を明確にするのが「スコープマネジメント」(1)

プロジェクトマネージャーの育成 WBS作成で、成果物と作業内容を明確にするのが「スコープマネジメント」(2)

*******************

このブログでご紹介したスキル診断が対応しているITスキル標準の職種プロジェクトマネジメントも、このPMBOKに対応しています。
以下の記事もご参照ください。

→ 「スキル診断の結果より~職種・専門分野ごとのスキル状況(1)~」の記事

次回は、ひき続き「コスト・マネジメント」についてです。

▼ご感想やご意見、
  また「このようなテーマを取り上げてほしい」など、
 お気軽にコメントにてお寄せください!

※コメント・トラックバックは、当社確認後表示となります。
 コメント・トラックバックが表示されるまでお時間いただくことをご了承ください。
 コメント・トラックバックにつきまして、営利目的の場合はご遠慮ください。

※無断転載・無断転用はご遠慮いただきたくお願いいたします。

当社のホームページはこちら
(株)富士通ラーニングメディアへのリンク

| | コメント (0) | トラックバック (0)

2007年10月12日 (金)

プロジェクトマネージャーの育成 
目先の進捗に捕らわれず、大きな視点で見るのが「タイム・マネジメント」(2)

Tsuchiya みなさん、こんにちは
(株)富士通ラーニングメディアの土谷です。

前回に引き続き、ASCII.jp キャリア(http://ascii.jp/cate/21/)に連載中の記事、プロジェクトマネジメントを成功に導く「本当の実力を養う最強プロマネ講座」をご紹介します。

今回は、前回に引き続きタイム・マネジメントについてです。

前回の記事はこちら

*******************

報告の“0-100ルール”
 進捗報告の仕方について注意事項がもう1つあります。進捗会議では「今80%終わっています」という報告がよく聞かれますが、この「80%」というのが問題です。80%と聞いて「もう80%」と思う人と「まだ20%残っている」と考える人では、進行状況の把握に大きな差があるでしょうし、さらには残りの20%が実は困難な作業ということがよくあります。これらの問題を解決するには「報告のルール」を決めることが必要です。例としては、プロジェクトの個々の