モラルとモラール
違うとわかっていたのですが、本日、テキストの中に誤用を発見。言葉は難しい哉。
最近忙しくて、メルマガもブログも手が回らず、申し訳ありません。そろそろ復活します。
違うとわかっていたのですが、本日、テキストの中に誤用を発見。言葉は難しい哉。
最近忙しくて、メルマガもブログも手が回らず、申し訳ありません。そろそろ復活します。
自分と相手の感情について理解するためには、EQとは何か、自分のEQはどのようなものかを知るのは有効です。EQは、仏教的な意味合いの怒り・悲しみ・喜び・楽しみだけではない、広い範囲の、人間の行動の原理みたいなところについてまで触れて、感情を考えているように思われます(まだ、ちゃんと理解はしていません)。
さて、EQトレーナーという「おもちゃ」があります。これは、EQの様々な要素の一部を、自己判定でき、かつ、トレーニングもできます。が、操作性はかなり疑問(笑)。TOMYが出してます。ヨドバシで\5000以下で買えました。まぁ、面白いんですが、、、、実用性には疑問があります。はい。
あ、EQって、数字の大小を競うようなものではありませんよ、念のため。
昨日までのセミナーご参加の皆様、お疲れ様でした。
以前からずっと気になっていたことを、ついに、口にしてみました。一般的な、PMPの人は、そもそも、プロジェクトマネジメントの課題とその他の課題を混同する傾向にあり、また、プロジェクトマネジメントの知識を使って思考する習慣が、無いのです。
もっと、使わないと、知識にならず、情報のまま、終わってしまいます。
とても勿体ない、です。ツールと技法に、なぜ、いつ、を、考える習慣を、まず、身につける。判断を素早く出す。覚悟を決める。そんな話を、今回も少ししました・・・・。
PMBOK(ガイドに非ず)は、使えば、知識として身につきます。はい。
なるほど、今日は、「エモーショナルインテリジェンス」なるものを知りました。
これは面白いですねぇ。私自身について、EQIのアセスメントを通じて、知ることができました。
自分の感情特性を認識し、人の感情特性に気づくようになる、それによりリーダーシップを高める或いは、コミュニケーションを改善する、そういう使い方が出来ます。
これは、リーダーシップやコミュニケーションなどのスキルを習得する以前の話です。そうしたものを習得する前に、自分を知っておかなければならないのです。
自分を知るのはちょっとドキドキしますが、悪くないです。
ただ、注意が必要で、「ある特性が低い」のは、「そうするように努めている」のか、「気づいていないから低い」のか、「何か別の特性とのバランスなのか」です。
EQというキーワードで興味を持っている人も多いようです。是非、これは、アセスメントを受け、かつ、じっくり考えるチャンスも持ってください。
自分を知り、自分を変える。知的生産者に絶対に必要な素養です♪
世界最大級の放水路が完成 10万トンの水がめ
埼玉県東部の洪水防止のため国土交通省が建設した世界最大規模の地下水路「首都圏外郭放水路」(全長6・3キロ)が完成、同県春日部市で10日、通水式が行われた。
会場は59本の巨大な柱が林立し“地下神殿”とも呼ばれる調圧水槽の中。国や地元関係者約400人が出席した。
特設スクリーンでのイメージ映像とレーザー光線で、嵐が発生し大量の雨が放水路を伝わって水槽に深さ約10メートル、約10万トンの水がめを造る様子をデモンストレーションした。
同省の吉田博美政務官が「素晴らしい放水路を活用し、災害に強い街づくりを進めたい」と北側一雄国交相の祝辞を代読した。 (共同通信) - 6月10日12時35分更新珍しく、他人の記事を引用してみた。
いつ、どこで、なにを、については、言えない立場なのだが、この仕事、若干係わっていました。あれから10年以上経つのですね・・・・。
あの頃、いろいろな事を学びました。新入社員同然だったわけですが、今では、、、、多少、人間がまるくなりました。
あの頃、何を学んだか、というと、やはり人間系のスキルでした。鬼のような上司に議事録の作り方を乱暴に教えられ、鬼のような作業員に金槌で頭を叩かれ、鬼のような上司に激しく叱責され。。。。
なんだか懐かしい気がします。
計画の作り方を覚えたのも、あの頃です。尤も、プロジェクトマネジメント計画書と呼ぶにはあまりにもお粗末な、限定的な計画書でした。・・・・施工計画書でしたね。
確かに、品質とコストとスケジュールは、深さ方向にはかなり詳細化された業界でした。あの粒度はたいしたものです。が、いわゆるマネジメントという着眼点だと、広さ方向には疑問がありました。
でも、同じ建設でも、トンネル系は、かなり理論派だったなぁ。。。。。トンネルの仕事、好きなんですよねぇ。
そういえば、鬼のような上司の一人は、しばらく前に亡くなったそうです。合掌。
最近、きちんとGUIDEを読まない人が増えてきました。正直、非常に不安です。
●全部読む必要性
知識体系というものは、全体にこそ意味があります。一度は隅から隅まで読むことで、初めて全体が見えてきます。その後で、部分の位置がわかり、部分を読む価値が出るのです。
知識体系慣れしていない方は、この前提をよく考えて欲しいのです。拾い読みではあまり役に立たないのです。
セミナー受講前にも、一度は読んでおいてくれ、というのは、そういう理由です。全体を説明した後で、「あっ」とわかってから、部分を・・・と、思っても、もう、部分の解説は終わってしまっています。
無論、部分がわからないから、全体もわからない、という話は一理あると思います。それはその通りだと思います。そういうときは、「世界一~」を読むようにしましょう。
●日本語は確かにおかしいのだが
現在のGUIDE第三版、日本語は若干問題があります。しかし、だから意味が無いか、というと、そういうものではありません。ある言葉をどう説明しているか、脳の中でマッピングができれば、多少言葉がおかしくても、どうということはありません。
確かに、要素成果物など、本来の意味から考えたら奇妙な翻訳です。だからといって読まない・読みたく無い理由にはなりません。
●知識の習得は実務に役立たない気がする
いつか言おうと思っていた事なのですが、そろそろ言ってもいいか、、、、と、思い、言いますが、GUIDE第三版に書いてある程度の事、ただ読んだだけでは、知識ではないです。単なる情報です。
知識にするには、最低限一回実践してみることです。それによって、初めて、思考が生まれてきます。その結果、知識になります。こうなって初めて、役立つ知識になります。一度も実践しないうちは、知識では無いと思います。
●実務に合っていない
GUIDEは実務に合っていないという話がありますが、私は、ほぼ、そんなことは無いと思います。その手の話の多くが、単なる誤解なような気がしています。
GUIDEは、本当に細かく読んでいれば、殆どの正しい実務に適用できると思います。例えば、プロジェクトマネジメント計画書。GUIDEに載っている通りに計画をつくれば、全てのプロセスをプロジェクトマネジメント計画書で定義する必要性が無いことに、簡単に気がつくと思うのです。あの全項目を記述しなければならない、それは、おかしい解釈だと思います。
合っていない、と、思うケースは、間違った実務経験があるか、あるいは、GUIDEの読み込みが甘いか、あるいは、全く経験が無い分野、、、、ということだと思います。
●GUIDEは十分ではない
確かに、粒度という点では、GUIDEはかなり粗いのです。でも、粗いままでも、あの厚さ。これ以上細かく記述されては、知識体系としては失格になってしまうと思います。変更や是正のIN/OUTには、正直私も疲れさせられます。
知識体系としては、あまり細かな「部分」はそれほど重要では無いと思います。そもそも、適用書でも無いですし、コンピテンシーガイドラインでもありません。
私は、全体の説明は、粗さを残して説明するようにしています。もし質問が出れば、適用なり実践について、それなりに細かく解説を行います。部分がわかれば全体が見える、ということも多いですからね。
●GUIDEは不親切だ
確かに、各プロセスに、WhenやWhyは記述されていません。この2点は、自分で補うことになります。解説では、多少この点についてもお話しています。例えば、アクティビティに着手した時点で、最低限どんな計画が作られていなければならないでしょうか?
●ということで・・・・
これは知識体系なのだ・・・・と、考えてみてください。PMBOK全体から見れば、GUIDEに記述されている量はほんの僅かです。しかし、その僅かな量、でも、あの厚さ。PMP受験までに必要な知識の、50%程度しか、GUIDE第三版には記述されていないと思います。
そういう意味で、GUIDEは、最低限、読んで欲しいのです。GUIDEが、脳内に、プロジェクトマネジメントという枠を定義します。あとはその枠に、自分で肉を付けていけば良いのです。
・・・まとめてみようと思いましたが、きれいにまとまりませんでした。失礼しました・・・。でも、GUIDEは、試験までに、ぼろぼろになるまで、とは言いませんが、手垢が付く程度まで、読んで欲しいと思います。2000に比べたら第三版は、かなり「読める」GUIDEですよ!
昔懐かしいNortonなものをインストール中。
この不安定さは、不安だ・・・。嫌な予感です。
プロジェクト活動とプロジェクトマネジメント活動。この2つは明確に区別されているだろうか?
それぞれ、計画プロセス群と実行プロセス群で取り扱われるのだが・・・・・。
実行プロセス群が、監視コントロールプロセス群や終結プロセス群を「実行」します。
というと、違和感を覚える人がいるかもしれません。こう考えてみましょう。もし実行プロセス群が無いと、、、どうなるでしょう?監視コントロールプロセス群や終結プロセス群の、開始の指揮や、活動の指揮が、出来なくなるのです。計画にのみ基づいて、行うことになります。
メンバーだって、コロコロ変わるかもしれません。
実行は、フィージビリティスタディの実行おも、指揮しているかもしれません。
どうしてもプロジェクト全体のイメージとGUIDEが結びつかないという方へ。
計画プロセス群は、プロジェクトの間、何度でも必要に応じて必要な程度で登場する、と、理解したほうが良いです。
極論すると、
という感じです。これが、ローリングウェーブ計画法のとらえ方の一つだと思います。
反復的、というのは、そういうこと、です。区切られた時間軸が有るたびに、また、その中でも何度でも、出てきます。
但し、業界別に感じ方はいろいろあると思いますよ!!!
今回の実践リスクから、内容を是正していきます。
前回はちょっと濃すぎた・・・・かえって、本質が見えにくくなってしまったところがあります。もっと、カリカリにしたほうが良いだろう、ということで、多少、内容を是正していこうと思っています。月曜午前までに完成させます(めずらしく期限付きの発言!)。
テキストを大量印刷しない世界だと、こういう調整ができるから便利です。
が、プリンターが大変なことに・・・・だから、プリンターが壊れる・・・。
前にも書いたかもしれないのですが、PMP試験というか、PMP試験対策には、弊害があると思っています。多くのPMPと話をする機会があるのですが、正直「???」と思うようなPMBOK GUIDEの理解だったり、、、ちょっと困ってしまうことがあります。
以前から、GUIDEにはWhyとWhenはGUIDEには載っていない、Whatがtoolベースで記述されているのだよ、と、お話してきました。
以前から、「PMBOKのイメージを頭の中に創れ」と言ってきました。
が、それでは不十分なようです。
今後、是正方法を考えていきたいと思っています。
私に向かって「WBSを書け」とか言う人・・・・プロジェクトのステークホルダーや、プロジェクトのタイプを考えて、その必要性を考えて、そう言っていますか???
ということで、第三版移行を復活させました。是正色が強いです。