そもそもPMBOKもプロジェクトマネジメントのナレッジを共有するために体系化されたモノです。

そのナレッジは大きく分けて二つに分類されます。

・暗黙知

個人が持っているナレッジで、このナレッジは共有されていない為に、そのナレッジを所有する個人によって利用されるナレッジである。

・形式知

少なくとも組織レベルで共有されるナレッジ。文書化されていたりするため、個人だけでなく組織レベルでの利用が可能なナレッジである。

この二つのナレッジで重要なのが、暗黙知を体系化して表現されたのが形式知であり、この形式知が個人で利用されることにより身につき新たなるナレッジが加わり、また暗黙知となります。このような関連で結びついているということ。

このように、暗黙知が体系化され形式知になることによりこのナレッジはさらに良いナレッジに変わっていくのです。

ではプロジェクトマネジメントではどうなのであろうか。

もちろん、プロジェクト内でナレッジを共有することは重要なことで、これが共有できているか否かでそのプロジェクトの質も変わってきます。

しかし、このナレッジの共有というのは難しい。データベースを利用したりするという方法はすぐに思いつくが、なかなかそこにナレッジが落とし込まれないからです。

それは、なぜか・・・

ただでさえ忙しいのに、そんなことやってられるか!!

(￣へ ￣ 凸

とか、

これはわしが苦労して身につけた方法なんぢゃ。

人に簡単に教えることなんてできるわけねぇよ。

(´0ﾉ｀*)

というメンバーの思いがある場合もあれば、

あれ??何でみんなこのやり方知らないんだろう??

こうすれば楽なのに・・・

(　 ﾟ ▽ ﾟ ;)

という場合もあります。

プロマネとしては頭が痛い問題です。

だからといって、

おまいら、隠すんぢゃねぇ!!

総て吐き出せゴラァ!!

＼(*｀∧´)／

と言っても、すんなり出すとは思えません。

なので、自分のナレッジも含めて、率先して体系化する必要があります。

そして、プロジェクト開始時点からツールを用意しておくことにより、すんなりとナレッジを共有できる体制を整えておくことが重要です。

プロジェクトの中でナレッジが共有されていると、ムダも無くなり品質も向上します。

プロジェクトを実施する際にプロジェクトにおけるナレッジ戦略を立ててみたらいかがでしょうか?

◎ナレッジマネジメント関係の本

ナレッジマネジメント

￥2,200

株式会社　ビーケーワン

ナレッジマネジメントのすすめ

￥1,500

株式会社　ビーケーワン

「経験知」を伝える技術 ディープスマートの本質/ドロシー・レナード

￥2,310

Amazon.co.jp

ナレッジマネジメントとリスク戦略

￥1,000

株式会社　ビーケーワン

知識の構造化/小宮山 宏

￥2,835

Amazon.co.jp

ナレッジマネジメント事例集

￥3,000

株式会社　ビーケーワン

情報を共有し、活用する技術―コンサルタントがその秘訣を明かす/日本能率協会コンサルティング

￥1,890

Amazon.co.jp

設計のナレッジマネジメント

￥2,400

株式会社　ビーケーワン

ナレッジ・マネジメント5つの方法―課題解決のための「知」の共有/ナンシー・M. ディクソン

￥2,520

Amazon.co.jp

ナレッジマネジメントがわかる本

￥1,800

株式会社　ビーケーワン

〈図解〉わかる！ナレッジマネジメント

￥1,600

株式会社　ビーケーワン

人間系ナレッジ・マネジメント―営業力をとことん高める/山本 藤光

￥2,310

Amazon.co.jp

バリューベース・ナレッジマネジメント

￥2,400

株式会社　ビーケーワン

今日からできるナレッジマネジメント

￥1,800

株式会社　ビーケーワン

ビジュアルナレッジマネジメント入門

￥1,000

株式会社　ビーケーワン

図解 ナレッジマネジメント/アーサーアンダーセンビジネスコンサルティング

￥1,680

Amazon.co.jp

知的グループウェアによるナレッジマネジメント

￥2,500

株式会社　ビーケーワン

ナレッジマネジメント入門/紺野 登

￥1,050

Amazon.co.jp

リクルートのナレッジマネジメント

￥1,500

株式会社　ビーケーワン

実践！ナレッジマネジメント

￥1,400

株式会社　ビーケーワン

図解１００語でわかるナレッジマネジメント

￥2,200

株式会社　ビーケーワン

今日からできるナレッジマネジメント/デロイトトーマツコンサルティング

￥1,890

Amazon.co.jp

Excelで始めるナレッジ・マネジメント/加藤 良平

￥1,995

Amazon.co.jp

これからはもう少し頑張ろうと思いますm(_ _)m

プロジェクトマネジメントで大事な事はたくさんあります。その中で今回はモチベーションについて書いてみようと思います。

プロジェクトを遂行するにあたり、プロジェクトメンバーのモチベーションが高いか否かでそのプロジェクトの成功率は格段に変わります。

こんなプロジェクトやってられるかｺﾞﾗｧ

(-_-ﾒ)

とか、

どーせ上手くいかネェだろ

( ´△｀)ｱｧ-

というメンバーばかりだったら、進捗も間違いなく遅れるし、ゴールに向かって進むことが難しいのは容易に想像できるでしょう。

プロジェクトという業務は一過性の業務。そして、失敗することもあり得る業務です。さらに、成功させるのが難しいプロジェクト・・・特に、すでに火を噴いて失敗しているプロジェクトの火消しプロジェクトであればなおさらアサインされたプロジェクトメンバーのモチベーションが低い場合が多いです(火消し屋と自負するメンバーの集まりであれば別ですが・・・)。

このモチベーションを上げるか、下げるか、さらにそれを維持できるかはプロジェクトマネージャーの双肩にかかっています。

だからといって、

てめぇら、グチグチ言ってんぢゃねぇ!!
俺様がやってんだから、シャキっとせい!!
凸(ﾟ皿ﾟﾒ) ｳﾗｧｧｱｱ!!

と言って突っ走るのはだめです。熱血型のプロマネに良くありがちな光景ですが。このようなことをやると、たいてい空回りをして、なおさらモチベーションが下がりかねないです。
一見みんながやるようになるかもしれませんが、あくまでもそのプロマネが怖いから仕方なく従っている状況になります。コレではモチベーションの上がりようがありません。

そして、

わしも、そう思うよ・・・。
でも、やれと言われてるからね・・・。
とりあえずやってみようか・・・。
(´Д｀) =3 ﾊｩｰ

といった、マイナス思考型のプロマネでももちろんだめです。

なぁんだ、プロマネもそう思ってるのね。
やっぱだめなんじゃん・・・
┐(￣ヘ￣）┌ ﾌｩｩ～

って思われてしまい、いっそう状況が悪化してしまいます。

ならどうすればよいのでしょうか??

1)いつでも目的とゴールを再確認し、共有する。
2)プロジェクトメンバーの声を客観的に聞く
3)プロジェクトメンバーの意見が間違っていても否定しないように修正する。
4)常に一歩引いて全体を見る。
5)競争相手を作る

ざっと考えてこのような方法があります。

1)いつでも目的とゴールを再確認し、共有する。
目的とゴールを共有していないと、メンバーもどの方向に進んで良いかわからなくなります。次第に、何をやっているかもわからずに、モチベーションが下がってきてしまいます。それを避けるために、くどいくらいに目的とゴールを共有しても良いでしょう。この目的とゴールをプロマネが理解してないということがあったら、論外です。

2)プロジェクトメンバーの声を客観的に聞く
「客観的に」というのが重要です。プロジェクトメンバーはあくまでもプロジェクトの一部を任された担当者。その人の意見を客観的に聞かないと全体を見失います。でも、これらの声をたくさん聞くことができるかどうか、それが重要です。その声の多さが、プロマネのバロメータと言っても良いでしょう。

3)プロジェクトメンバーの意見が間違っていても否定しないように修正する。
仮に、そのメンバーの意見が間違っていても、思いっきり否定してしまってはその人のやっていること総てを否定する事になりかねません。それをやってしまうと、その人のモチベーションは最低なラインまで堕ちてしまう可能性があります。否定せず修正する・・・難しいけど必要なスキルです。

4)常に一歩引いて全体を見る
全体を見れないプロマネはプロマネとして失格です。プロマネはメンバーと違って全体を見渡して全体をしっかりとした方向に進めていく必要があります。細かい目先の事ばかり見ていると、本来の方向性を見失い、しょっちゅうその方向性が変わることになり、メンバーのモチベーションを下げてしまいます。

5)競争相手を作る
コレが究極のモチベーションアップの方法かもしれません。人間は元々競争意識が高い生き物です。その本能を刺激したモチベーションアップの方法です。目的とゴールがわかりにくいプロジェクトの場合はこの方法をとると良いでしょう。

とまぁ、こんな感じでモチベーションを下げず上げる方向に持って行くことが必要となります。

そして、最後に・・・
モチベーションが上がっている時に下げるような行為は決してやってはいけません。
飴と鞭・・・良くある方法ですが、鞭を打ってその後飴を上げるのなら良いですが、飴を上げてモチベーションを上げたあと鞭を打った場合、モチベーションの低下は著しいです。
よくある勘違いですが、コレが致命的になったりもするので覚えておきましょう。

そのWin-Winの関係を築くにはどうしたらよいか??と言うことを考えなくてはなりません。

その考え方としては、「一つのリンゴを2人に均等に分けるにはどうすればよいか?」という問題を解くことで解決することができます。

PMとしては、どのような心構えでWin-Winな関係を築く必要があるのか・・・

それについて考えてみました。

詳細についてはこちらを参照下さい

http://09darts.com/pmbok/

09.PMBOK 第二章 2.1.1 -プロジェクト・フェーズの特性-

最終更新日:2005/09/201

いったい、どうやって分けるといいの??

という疑問が出てきます。ただ闇雲にフェーズ分けをするのでは当然だめです。

ではどうしたらいいのでしょう?

プロジェクトを進めていけば、なんかしらのものを作ることになるでしょう。例えば、システム開発においては要件定義書や内部設計書。製造においては、設計図面や試作品などのことを言います。

これら、作られたもののことを要素成果物と言い、これら要素成果物の完了を持って、フェーズの区切りとするのが一般的です。

プロジェクトフェーズは、プロジェクト成果物の適切な定義を確実にするために設けられ、プロジェクト全体を大きく見た場合には順序関係のあるロジックの一部である。

(PMBOK P11)

言いかえると、

成果物をしっかり作るのがプロジェクトフェーズである。

と言うことができます。

そして、プロジェクトフェーズの終了時には、その成果物とプロジェクトの実績をレビューします。

そのレビューにおいては、

a) プロジェクトを引き続き次のフェーズに進めるかどうかを決定

b) コスト効率良く間違いを発見し、訂正する

(PMBOK P11)

という観点でレビューを行います。このレビューのことをフェーズの出口、ステージの出口、中止点と呼びます。

プロジェクトにおいては、このレビューが非常に大切なものとなります。

プロジェクトマネージャーは、

このフェーズでこんな成果物作ったぞ!!

次のフェーズに行かせろ、コラァ!!

とアピールする場であり、一方レビューアーは、

すばらしい!!次のフェーズに行ってヨシッ!!

もしくは、

こんな成果物でプロジェクトがうまくいくと思っているのかコラァ!!

考え直してこい!!できなきゃ、中止だッ!!

と判断します。

このように、フェーズを区切ってプロジェクトを進めることにより、適切なマネジメントを適切なタイミングで行うことができるようになるのです。

次は、プロジェクトライフサイクルの特性について見ていきます。

2.1節　プロジェクトフェーズとプロジェクトライフサイクル

プロジェクトという業務は独自性があり、ある程度不確実性を伴うことは今まで説明してきた通りです。つまり、

プロジェクトでやっている業務は初めての内容で、成功するかどうかなんてわかりゃぁしない!!

というモノなのです。

もちろん、プロジェクトに関わっている人は失敗するつもりで取り組んでいるわけではなく、少なくとも成功するために努力しているわけです。

だからこそ、プロジェクトをマネジメントする立場のプロジェクトマネージャー(PM)は、通常業務とは異なり、失敗と隣り合わせで、プレッシャーと戦い続けているのです。

そして、そのプロマネから

いつこのプロジェクトが終わるかわかんね～よ!!

ｵﾚ死んじゃうよ・・・

という愚痴を聞くことが多々ありますが、プロジェクトの性質上、どのような結果であれ、プロジェクトには終わりがあるので、そのような心配は本来は不要です。上手くコントロールして、しっかりと終わらせる努力が必要なのです。

では、どのように上手くコントロールするかというと、ただ単に終わりがあるからと言ってダラダラとやればいいわけではなく(卒論とは違いますから)、プロジェクトをいくつかのフェーズに区切り、それぞれのフェーズをしっかりと終わらせるように運営していけば良いのです。

このフェーズのことをプロジェクトフェーズといいます。そして、このプロジェクトフェーズ全部を含めて、つまり、プロジェクトの始めから終わりまでのプロジェクトフェーズをまとめて、プロジェクトライフサイクルと言うのです。

では次のフェーズから、それぞれについて詳しく見ていくことにします。

私はいわゆるITスタッフと呼ばれる、企業の中のシステム開発部門に所属しています。
昔は情報システム部門と呼ばれ、自分達でプログラムを書きシステムを開発するという業務内容でしたが、近年はプログラミング等はパートナーさんに任せ、プロジェクトをマネジメントすることが業務となっております。いわゆる、社内コンサルタントという立場です(実際この立場であるということを認識している人は少ないですが・・・)。
そして、企業内でのIT化は相変わらず求められており、沢山のプロジェクトが立ち上がり一人一プロジェクトという体制では回らないのが現実です。その結果、一人あたりのプロジェクト数は増え、私自身数プロジェクトを複数兼任するという状況にあります。

もし一つのプロジェクトに参画するのみであれば、そのプロジェクトに専念することが可能で管理も楽とは言いませんが、しやすいのも事実です。
でも、複数のプロジェクトに関わっていると、問題が発生しそうなプロジェクトに工数がとられ、他のプロジェクトが疎かになってしまう可能性があります。

うぁぁっ!!何でそんなことが起きてたのぉぉ!!!

問題が発生しているプロジェクトの対応を行っているうちに他のプロジェクトで問題に火がついていた・・・ということは良くあります。
そのまま問題解決の工数をシフトし、解決できれば良いのですが、気づくのが遅くて問題が解決困難な状況に陥ってしまうこともたまにあります。
本来であれば、しっかりとコミュニケーションをとってこのような問題を小さいうちに発見することも可能なのですが、パートナーさんに任せっきりで気づかない・・・悩ましいことです。

このような問題が発生するのは、優秀な(と言われている??)パートナーさんと一緒に仕事をしているときに多いです。
優秀なパートナーさんは・・・

クライアントに迷惑をかけないために頑張るんだ!!!

という気持ちが強く頑張ってくれます。
その結果、小さな問題が発生してもパートナーさんの中で何とか解決してしまおうという努力をしてくれます。従って、問題がパートナーさんの中で解決できなくなった時に初めて顕在化するのです。
こうなったプロジェクトを見ていると大抵、

何でそうなるまでほっといたんぢゃ、ワレ!!!

と、クライアント側のプロマネがパートナーさんに怒っていることが多いのです。
でもこれはお門違いで、いくら複数のプロジェクトを持っているからという理由があっても、明らかにコミュニケーション不足であり、そのプロマネのマネジメント不足から発生していることだと私は思います。

これを解決するためには、

・一日一回各プロジェクトのタスクを確認する。
・定期的なコミュニケーションを行う。
・問題/リスクのエスカレーションパスを明確にし、些細なことでも報告する事を徹底する。

最低これだけは実施する必要があると思います。

そんなの、当たり前ぢゃぁ!!!言われなくともわかっとるわい!!

という声が聞こえそうですが、本当にしっかりやっていますか?
特に、最後のエスカレーションパスについてはやられていないことが多いと思います。
「些細なこと」でも報告するようにメンバーへ徹底することは非常に難しいことです。
これを徹底するためには、「解決した問題」も報告するようにするのが一番効果があります。
そうすれば、

このような小さな問題が発生していますが、こう解決するつもりです。

という連絡があるようになるでしょう。
こういう連絡が来るようになればしめたものです。
自分の知らないうちに問題が発生して勝手に解決しているということはなくなります。

これらは当然、一つのプロジェクトをマネジメントしているだけの時も必要なことですが、複数マネジメントしている場合は特に必要だと思います。

プロジェクトマネジメント手法に関わるノウハウ本は沢山出版されていますが、そのほとんどが一つのプロジェクトをマネジメントする場合について書かれています。複数マネジメントするその手法を書かれたものというのはほとんど見たことがありませんね。
それは、複数のプロジェクトマネジメントするのは「No」であり、一つのプロジェクトをマネジメントするようにすべきだというべき論で書かれているからだと思います(こう書かれている時点でで現実的ではなくなってしまうのでは??)。
ここらへんが、プロジェクトマネジメント本が理想論を書いてるのみといわれてしまう要因なんでしょうね。私にそのようなスキルがあれば、書いてみたいものですけどね・・・たぶん無理でしょう・・・。

転職先の会社で1年が経過したのと、昇進(たいした昇進ではないです)があったため業務内容が少し変わり、忙しくなっていたのでサボっていました。

激励のメールや、催促のメールをいただきありがとうございました。おかげで、やる気になり更新を開始します。

今後は、皆さんがもっと楽しんでいただけるよう、毎日とは言わず、1週間に一回は更新できるように努力するつもりです。

今後もよろしくお願いします!!!