プロマネとナレッジマネジメント

プロジェクトにおいてナレッジの共有というのは非常に大事なこと。

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

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

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

PMとしてWin-Winな関係を築く

Project Managementをするにあたり、各関係部門との関係で、Win-Winな関係を築くことが重要です。

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

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

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

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

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

http://09darts.com/pmbok/

PMBOK紐解き 目次 (9/21更新)

01.プロジェクトマネジメント
02.はじめに　-PMBOKとは？？-
03.PMBOK 第一章　序論(1) -PMBOKの目的-
04.PMBOK 第一章　序論(2) -プロジェクトとは何か-
05.PMBOK 第一章　序論(3) -有期性・独自性・段階的詳細化-
06.PMBOK 第一章　序論(4) -プロジェクトマネジメントとは-
07.PMBOK 第一章　序論(5) -他のマネジメント分野との関係、関連業務-
08.PMBOK 第二章 2.1 -プロジェクトフェーズとプロジェクトライフサイクル-

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

最終更新日:2005/09/201

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

ということで、プロジェクトはいくつかのプロジェクトに分けてマネジメントする必要があるのですが、

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

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

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

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

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

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

(PMBOK P11)

言いかえると、

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

と言うことができます。

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

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

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

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

(PMBOK P11)

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

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

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

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

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

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

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

もしくは、

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

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

と判断します。

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

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

PMBOK 第二章 2.1 -プロジェクトフェーズとプロジェクトライフサイクル-

さて、久しぶりに紐解き再開です。今日より二章をを開始します(お待たせしました)。

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

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

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

というモノなのです。

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

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

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

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

ｵﾚ死んじゃうよ・・・

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

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

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

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

複数のプロジェクト

プロジェクトマネジメントを行う上で、プロマネが実施するプロジェクトは1名につき1プロジェクトというのが理想的です。
しかし、現実的にはプロマネが1つのプロジェクトだけに参画している例は少ないと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

お詫び

4月末から約1ヶ月ちょっとこのブログを更新しておりませんでした。

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

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

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

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

4月は異動の季節

4月は異動の季節ですね。私の回りでも異動する人が多いです。

・あるプロジェクトの旗振り役の部長級の方が異動
・あるプロジェクトのマネージャーが異動
・あるプロジェクトの現場を引っ張っていた方が異動

おいおい、この「あるプロジェクト」はどうなるんぢゃい??

といった状況になりました。
本来であれば、プロジェクトのコアメンバーはプロジェクトが完了した時点で外れるのが理想。
しかし、企業の辛いところはプロジェクト人事と社内人事がリンクしていないこと。
昔からの企業はプロジェクトに対する考え方がまだ浸透していません。どうしても企業内組織を優先してしまい、プロジェクト組織がおろそかになってしまいます。
これは、プロジェクトを破綻させる大きな要因となっているのも確かで、マトリクス型組織の危険な部分だと思います。
今後変わっていくのかどうか・・・非常に難しいとは思いますが、会社事情によるプロジェクト破綻を避けるべく努力するしかないんでしょうね。

話は元に戻って、今回の異動劇は私にとって非常に辛いところ。
旗を振って現場を動かしていた方がいなくなり、相談すべきユーザー側のマネージャーもいない。我々の思いを理解して一緒に悩む人までいなくなる・・・
おまけに、その人たちの後任者はいない・・・(人事上の後任者のみ)

今後は、目先の事しか考えていない現場主導型の担当者が残る・・・。
昨年一年かけてプロジェクトの進むべき方向を修正してきたのだが、それがわかっている人が全くいなくなる。
来年度はまた一から出直し・・・ちょっと辛いものがある。

とはいえ、悪い話ばかりではない。
一昨日、部門全体の大きな集会がありました(部門人数200人弱)。
集会終了後、自分のグループの人たちはあっさり帰ったのですが、他のグループ(仕事上はほとんど関係ない)の部長とマネージャーに拉致られて飲みに行くことに。
その部長は、一緒に仕事をしたことが無いのですが、先日「昇進試験」の代わりとなるプレゼンを行った際のレビューアーだった方。
その方曰く、

「君のプレゼンが一番良かったよ。一番良い評価つけておいたからね」

とのこと。まだ昇進の辞令が出ていないので不安でしたが、一歩昇進に近づいたのかなと思わせるコメントでした。
さらに、マネージャーが部長に

「こいつかわいいやつなんですよ、おっさん顔だけど。いろいろ考えてるし。うちのグループに引っこ抜こうとしたんだけどやっぱりだめでした(笑)」

と言ってくれました。おっさん顔はよけいだけど(笑)
転職により、人脈を無くしてしまったことが気になっていましたが、一年で少しずつ人脈が広がりつつあるのを実感しました。
ある方が言っていることを思い出しました。

・本気でやれば何でもできる。
・本気でやれば楽しくなる。
・本気でやれば誰かが助けてくれる。

良い言葉です。今年一年、本気でやってきたので、無理だと思ったこともできましたし、はじめて受け持った分野の仕事でしたが、楽しくなりました。そして、助けてくれる人も出てきました。確かにその通りだと思います。

今後の私としては、今回の部長やマネージャーの評価、そしてこの言葉。これらを忘れないようにして頑張っていきたいと思ったのでここに書くことにしました。

来年度は波瀾万丈なプロジェクトになりそうですが、破綻させることなく一歩一歩前進させていこうと思います。

ゼロベース思考

昨日から、「問題解決プロフェッショナル」という本を再読しています。
これは、4年くらい前に購入した本。それ以来、一度も開けていません。
これくらい期間が空いていると、読んで理解する部分も異なるかもしれないと思い、また読むことにしました。

さて、ここの一章に書いてある内容なのですが、「ゼロベース思考」というものがあります。結構大事なことなので、ここにメモりたいと思います。
ゼロベース思考とは、

「既成の枠を取り外して考えるということ」

です。なーんだ、そんなことか、と思う人も多いと思います。
ただ、

外から見ると「さほど重要ではない」「そんなことは、はなから当たり前だ」と思われるポイントが、中にいると全く気がつかない、あるいは気がついても変えられない、変える方法が見つからないということが非常に多いのだ。

というものでもあるのです。
これは、大企業でよくあることで、私はよく「しがらみ」と言っています。
この「しがらみ」を排除しないと、何もできないことが多いのです。
それと同時に、「しがらみ」を排除しようとすると猛烈な反発を食らったりします。
とはいえ、やらないとどうしようもないし、プロジェクトなんてそれを排除するのが目的だったりする。
では、どうすればいいのか。

日々の考えの中で、

小さな枠の範囲内で限定的に考えてしまうため枠の外にある解決策を見落としてしまう可能性があるため、常に枠の外に解決策があると考える。

ことが重要なのです。
そして、社内でどうあるべきかと考える前に、

自部門や自社の既成の枠から離れ「顧客にとっての価値」を考え抜く

ということも重要になります。

つまり、お客様あってのビジネスな訳ですから、

社内の「しがらみ」や「こだわり」を捨て、顧客中心に考える

ことをする必要があるのです。
一見簡単なようですが、これは日々努力していく必要があるでしょう。
私は、中途入社の社員ですので、これは比較的やりやすい立場にあります。
しかし、元々いた社員にこの考えが無い人が多く見られるので、日々戦いになります(笑)
でも、中に染まることなく、自分の考えを貫く重要性も最近身にしみて感じることが多いのも事実。

皆さんも初心に返って頑張ってみてはいかがでしょうか?
ゼロベース思考、重要です。