人気ブログランキング |

<   2019年 04月 ( 3 )   > この月の画像一覧

感情のマネジメントとは、どういう事を指すのか

夜中に目が覚めて、しばらく眠れなくなった。仕事の多忙で、身体は疲れているはずだ。なのに、うまく眠れないまま、いつの間にか、ある問題状況について考え始めていた。最近起きた、ひどくイライラするトラブルだ。おかげで頭がさえて、さらに眠りから遠ざかってしまう。「夜中にそんな事を考えても、仕方がない」−−そう自分に言い聞かせてみたが、心はまたその悩みに戻って行く。そして堂々巡りの思考の中で、休息すべき時間が失われてしまう・・

こういう経験をしたことがない人は、うらやましい。働いていて悩みが全くない人は、滅多にいないだろうが、悩みに煩わされる程度は、人によって違うようにも思える。夜中に目がさえるような時は、起きている間も、いつの間にかその問題を考え続けている。ただ、考えるといっても、たいていは同じ場所を巡っているだけで、出口の見つからないことが多い。つまり、脳の中のある部分がずっとループしたまま回り続けていて、メモリやリソースを占有してしまっている感じだ。

とはいえ、わたし達の脳がコンピュータと違うのは、そこに『感情』というモードが伴うことだ。怒りだとか、不安だとか、恐れだとか。もちろん幸福という感情だってたまにはあるが、夜中に幸せすぎて目が冴えたという体験は、まだない。大抵は不快な、ネガティブな感情が伴っている。いや、逆かもしれない。感情的な問題がまずあって、それを解決したくて、知的な回路がぐるぐる回っている、という事なのだろう。

感情とは、なんだろうか。それは、マネージすることができるのだろうか?

自分は感情というものに対して、決定的に鈍感なのではないか。そう、疑い始めたのは、中年になってからだった。ずっと技術職だったから、理屈を通すことで仕事を回してきた。若いうちは、それで仕事を回せると思ってきた。

だが、プロジェクトというのは、複数の人間が協力し合って、共通の目的を達成する仕事である。人と協力するには、人の役割分担や能力も大切だが、人のモチベーション、その気分や感情も大切だ。信頼関係のないところに、良い仕事は生まれない。

自分はちゃんとチームを動かしているつもりなのに、「〇〇さん、あとで怒ってましたよ」「××君、ひどく疲れてがっかりしていたね」といった指摘を、人から受けることもたびたびあった。そして家族からも、他人の感情について鈍感だ、と思い知らされるに至って、これは何とかしなければ、という問題意識が生まれてきた。

先日、わたしが主催する「プロジェクト&プログラム・アナリシス研究部会」で、『感情のマネジメント』という珍しいテーマを選んで講演してもらうことにしたのも、その問題意識からだった。アイシンク(株)の丸山奈緒子様に講師をお願いした。ところで驚いたことに、この回は過去最高の参加希望者があり、しかも初参加の方が多かった。このテーマに関心を持つ人が自分だけでないことに、あらためて印象付けられた。

以下、わたしが学んだことを、研究部会における丸山さんの講演資料「プロジェクトマネジャーが高めたい『感情マネジメント』スキル」をベースに、多少引用させていただくが、もちろん文責は筆者にある。

まず、感情とは何か、である。

当たり前だが、わたし達が抱える感情には、多種多様な種類がある。では、何種類に分けられるのか? じつは感情というものは、基本的な分類基準さえ、世間的には確立していないのだ。自家用車にはどんな種類があるか、金融投資にはどんな種類があるのか、わたし達は大まかな分類の軸をあげることができる。だが、感情はそれができない。それくらい、近代的なわたし達の生活において暗黒大陸、ないし未開の沃野なのだ。

それでも、とりあえず感情にはポジティブとネガティブがありそうだ、というくらいは分かる。ネガティブ感情にしばしば悩まされると、上にも書いた。では、ネガティブな感情は、さらにどう区分できるのか?

わたし達は赤ん坊の時から、感情をもっている。知性や自我の前から、あるのだ。ただ最初は、未分化な状態にある。自分が成長していく過程で、少しずつ、「あんたは怒ってるの?」「うれしそうね」「ぼくはそれ悲しい」「さびしいな」などと、言葉で表現するようになる。名付けることによって、感情は対象化され、また自分でも気付きやすくなるものらしい。感情の分類と、感情の発達・分化は関係しているのだ。
e0058447_19332857.jpg

そこで講演では、参加者に、自分が感じている感情を、言葉と数字を使って、表の形で書いて見るワークが出題された。直近の一週間を振り返って、自分はどんな時、どの感情を感じていたか。その強さは0-100%であらわすと、何%か?

単純なワークだが、これをやっていると、自分が毎日、いろんな気持ちを抱きながら過ごしている事に、あらためて気づく。それもプライベートだけではない。職場などの公的な時間でも、いろんな感情とともにいるのだ。

丸山さんによると、感情には、二つの重要な機能がある。一つ目は、自分自身への「信号」として、である。感情は、自分にとって重要な何かが起きていることを、知らせる。それによって、直接的具体的な行動を促す働きがある、という。たとえば、怒りは「戦え!」「相手を排斥しろ」という信号だし、恐れは「走れ、危険が迫っている!」 と自分に知らせてくれる。

もう一つは、他者との「コミュニケーション」を活性化する機能だ。感情は、他者に自分に関する副次的情報を伝えることで、他者とのコミュニケーション活性化のきっかけとなる。たとえば、悲しみは「助けて!」「わたしは傷ついています」と他人に訴えかける力がある。喜びは、「協力しよう」「再現しよう」 という気持ちを伝えてくれる。

ポジティブ感情には、「心身を回復する」ないし「注意と行動の範囲を広げる」働きがある。そして、ポジティブな感情は、その大きさ・深さよりも「頻度」が大切だという主張にも感心した。小さくても、頻繁に、自分に対してポジティブな感情のストロークを蓄積する。それがストレスを軽減するのだろう。

講演はさらに、ネガティブ感情を受け入れる、というテーマに進む。ネガティブな感情も、適度であれば、自分にメリットをもたらす。不安は、慎重さや準備、予防策のきっかけになるのだ。しかし、不安感情が過剰だと、デメリットが目立つようになる。パニックになる、他のことが手につかない、などの状態に陥るからだ。

そして、自分のネガティブ感情に「応対戦略」を考えるワークを、皆で行った。二人一組になって、それぞれ、自分がしょっちゅう悩まされるネガティブ感情をとりあげ、それに「あだ名」をつけるのだ。このとき、ちょっとコミカルなキャラづけになるような名前を考えるのがいい、という。

自分の場合は『怒り』だな、とわたしは思った。じつは気が短いので、つまらぬことでもすぐ怒ってしまう。とくに馬鹿げた、筋道の通らない話をされると、ついカッとなり、それが攻撃的な口調となって出てしまう。これで何度、損をして痛い目にあったことか。では、なんてあだ名をつけようか。

よし、「イカール大帝」にしよう、と決めた。ご存知の通り西洋史には、カール大帝という、英雄だが戦争好きな君主が出てくる。それのもじりだ。イカール大帝が登場すると、しょっちゅう、あちこちでケンカをやらかして、まずい事態を引き起こす。自分の中にいるのだから、そんなに偉大な存在ではないけれど、暴君なのだ。では、どんな時に現れてくるのか。この人と、どう付き合ったらいいか。それを考えて、相方に説明し、一緒に相談する。

これはなかなか興味深い体験だった。何より、自分が前からとらわれている感情を対象化し、しかもコミカルに擬人化するところがいい。そうすると自分にとって、何とか応対可能な相手だという感じがする。あだ名をつけるというアイデアが、卓抜だ。さすが専門家はだてに専門家ではないな、と思った。

それと同時に、こうした研修講演にはワークが必須なのだ、と気づいた。聴いて、知った気になるだけでは、自分の行動に結びつかない。身に着けるには、練習が必要なのだ。ただ、実りあるワークのためには、ある程度、自分の感情を人に晒せるような、相互に信頼感のある場づくりが必須である。

今回は、本来1日かかる研修コースの内容を、丸山さんを拝み倒して、わずか1時間半に凝集してもらった。ただ、明らかにこれだけで十分ではない。だから、自分自身で感情に気づくエクササイズを、日常で繰り返す方がいい。そのためにも、日誌による「ふりかえり」の習慣は有益だろうと思う。

ところで、以下は個人的な感想ないし疑問だが、はたして感情とは「マネージ」「コントロール」するべき対象なのだろうか?

感情のマネジメントという考え方が広まった背景には、EQという概念の普及も関係しているらしい。EQは、80年代後半に米国のメイヤーとサドベイが提唱したもので、IQ(知能指数)にヒントを得た用語であある。彼らは、「感情をうまく管理し、利用することは、知能である」と主張する。

優秀なリーダーは、自分の感情を把握・コントロールする能力と、他者の感情を知覚する能力が優れている、という研究があり、彼らの主張はこれに基づいている。つまり、ビジネスの成功には、知的なIQと、感情のEQが必要だ、という主張である。まあ、ある意味、いかにも「ビジネスの成功=社会的理想」とする米国的な考え方ではある。

ところで、日本語には「知情意」という言葉がある。知性、意思、感情という、心の働きの主要な3つを表した言葉だ。この三つについて、上記のEQのような考え方では、意思に基づいて知性を働かせ、その知性によって感情をマネージする、という風にとらえられる。つまり、

 意思>知性>感情

という優越関係にあるようだ。ただ、本当に感情とは、自分(自我の持つ意思・目的)が利用すべき資源にすぎないのか。暴れん坊だからコントロールすべき、家畜のような存在なのだろうか?

感情は、じつは自分の一部ではないのか。知性や意思と対等な、自分自身を作り上げる構成要素ではないか。そういう風にも、わたしには思える。感情の働きは、じつは自分の生に意味や価値を与えるのではないか。

人間は、なぜかしらないが、感情を共有したがる生き物である。丸山さんはこのことを、感情には「伝染性」がある、と表現された。そしてまた、感情には「流れ」があり、それはお金の流れと同様に重要だ、という経営者もいる。興味深い考えだ。

そして、感情は身体とかなり直接、結びついている。負の感情が肉体的な不調を呼び起こすことも、よくある。身体だって、自分の一部であって、単に「自分の所有物」ではあるまい。所有物みたいに思って暮らしていると、そのうち、身体の反乱によって痛い目にあう日が来る。同じように、感情をただ「マネジメント」の対象として、上から目線で考えるのは、いささか一方的だと感じるのだ。

「プロマネの仕事は技術をリードすることだ、だから優秀な技術者がやればいい、と信じている組織が世間ではほとんどです。だが本当は、感情とリスクのマネジメントがその8割以上なのではないかと、参加した皆さんもきっと思われるようになるはずです。」--研究部会の案内文に、わたしはそう書いた。

夜、目覚めて眠れず困る時間をすごす代わりに、自分の中の感情に気づき、自分を支える一部として認め共存することが必要なのではないか。そして、他者の感情をも、同じように尊重することが大切なのではないか。これが、理詰めで世の中を渡ろうとしてきたわたし自身の、最近の本心である。


by Tomoichi_Sato | 2019-04-26 21:36 | 考えるヒント | Comments(0)

BOM/部品表に関するセミナー講演のお知らせ(6月18日・東京)

お知らせです。
来る6月18日(火)に、BOM/部品表に関する有償セミナーを行います。場所は東京・新宿です。

ご承知のとおりBOM/部品表の構築と保守は、製造業にとって古くて新しい問題です。わたしは2004年に「BOM/部品表入門」を上梓しましたが、この本は発刊後15年経っても、いまだに現役です。昨年も増刷され累計1万部を超えたばかりか、中国語版もかなり売れています。

それはしかし、BOMのマネジメントに関わる根本の問題が、多くの企業で、未解決のまま長く残っている事を意味します。とくに近年は、
 ・新製品開発・投入のサイクルが早くなったことと、
 ・製造のサプライチェーンが国境をまたいで海外に伸びたこと、
 ・企業買収や提携が進んでいること
などの要因が相まって、BOMの維持運用を難しくしています。

ともあれ、近年製造業でも多少は情報化投資の余裕が出てきたことと、データ・サイエンスや統合データ・マネジメントに関心が集まったことで、ふたたび注目されているのでしょう。また過去15年間に、この分野でたしかに進展もありました。たとえばBOP(Bill of Process=工程表)概念の普及や、海外を中心としたPLM(Product Lifecycle Management)ソフトウェアの発達などが挙げられます。

わたしは最近、有償セミナー講師をいささか控えてているため、このテーマで講演するのは2年ぶりとなります。今回はとくに、著書に詳しく書いた量産型の製造業だけでなく、BOMを扱いにくい個別受注生産における知恵にも光を当てて、「自分で考え身につく」セミナーを目指します。

この問題に関心のある方のご来聴をお待ちしております。

<記>

日時: 2019年6月18日(火) 10:30~17:30

テーマ: 「BOM/部品表の基礎と効果的な構築・活用ポイント ~演習付~

主催: 日本テクノセンター

会場: 〒163-0722 東京都新宿区西新宿二丁目7番1号
     小田急第一生命ビル22F

セミナー詳細: 下記をご参照ください
     →詳しい開催案内


 よろしくお願いします。
               (佐藤知一)


by Tomoichi_Sato | 2019-04-16 22:45 | サプライチェーン | Comments(0)

PMBOK Guideに欠けている、3つの重要事項

春である。4月の花咲く頃になると、今年は何人くらい受講生がいるかな、とそわそわした気持ちを抱えながら、つくばエクスプレスに乗る日が来る。東大の柏の葉キャンパスで「プロジェクト・マネジメント特論」の開講日を迎えるからだ。まだ働いた経験のない学生たちに、PM論を教えるのは、あまり簡単でない。それでも柏の葉キャンパスは大学院なので、皆、とりあえず自分の卒論で多少は苦労した経験を抱えて、入って来る。つまり小さくて個人的ながら、プロジェクト的な取り組みをした訳だ。だから学部生よりは、少しだけ教えやすい。

PM論を教えるにあたって、どんな構成・体系で説明を進めるべきかも、悩ましい。大学で講義を持っている、というと、「じゃあPMBOKを教えるんですね」とたずねてくる人が時々おられる。こういう人は、PMBOK Guide®︎が『教科書』だと信じているのだろう。だがあれは、いくつかあるガイドブックの一つにすぎない。よくまとまっているが、あまり書かれていない部分、足りない部分もある。

たとえば、プロジェクトの類型論である。これがないのは、けっこう痛い。古今東西、すべてのプロジェクトが同じ一つの道具立てでマネージできる訳ではない。数ある技法やプロセスの、どれを使うべきか、どれが自分のプロジェクトにあっているのかを、判断する具体的な基準が、PMBOKには書いていない。

最初に読んだときから感じているのだが、PMBOK Guideには、無意識に前提されていることが一つある。それは、プロジェクトが比較的「固い」スコープをもって出発する、との前提である。そこで、SOW(Statement of Work=作業範囲記述書)を初期インプットとして、プロマネがProject Charter(=PMBOK日本語版では「プロジェクト憲章」と訳されている)をまず作る、といった作業プロセスが規定される。Charterはさらに、プロジェクト・マネジメント計画書のインプットとなり、その中でWBSが展開される・・と続く。SOWは、まさにプロジェクトの出発点である。

では、そのSOWなるものは、どこから来るのか? プロマネが受け取るのだから、プロジェクト・チームの外部から、ポンと来るわけだ。解説書などを読むと、プロジェクトの成果を利用する組織が作る、と書いてある。社内利用なら、内部のsponsoring organizationが、また外部顧客の利用なら、顧客から来る、と。だとすると、自動車の新車開発プロジェクトでは、まだ見ぬ顧客からSOWが届くのだろうか?

種明かしをしよう。SOWは、プロジェクトの発注者から来るのである。米国PMIで初期のPMBOK Guideをつくった人たちの多くは、防衛産業・航空宇宙産業やエンジニアリング産業の出身だった。彼らにとって、プロジェクトとは受注型のビジネスであり、「何を作るべきか」は発注者(国防総省とか石油メジャーとか)が決めるものであった。そして(少なくとも米国においては)国の機関や大企業は、自分達の要求事項は事細かに、紙に書いて入札を行うのだ。それは業界によってITBとかRFQとかいろいろな名前で呼ばれるが、抽象化してStatement of Workと呼ぶことにしたのだろう。

初期のPMBOK Guideにおいては、プロジェクトとは受注型であり、かつ明確なスコープから出発するものだ、という無意識の前提があった。だから、エンジニアリング業界に身を置くわたしのような者が読むと、なんだか似たような業種の匂いがぷんぷん感じられた。ただし、プロジェクトには自社が決めて行う、自発型のものもあるし、PMBOK Guideが標準である以上、それにも適用可能な記述でなければならない。だから、「社内利用の場合はsponsoring organizationがSOWをつくる」といった、なんだか無理の多い話になるのである。新車は誰が利用するものだろうか?

PMBOK Guideがもう一つ、無意識に前提したことがあった。それは、プロジェクトは複雑で大型の営為である、という感覚である。これも、防衛宇宙産業やエンジニアリング産業からみれば当然のことであった。大規模プロジェクトの場合、必然的に、「計画」「契約」そして「計数管理」が大切になる。わたしはこれを、プロジェクト・マネージャーの3Kと呼んでいる。この三つが、プロマネの仕事をひどく大変にするのだ。また、受注型プロジェクトではたいてい、コスト制約・スケジュール制約が厳しい。したがってプロマネに、より強い権限を与えるような組織体勢が望まれる。

ところで、世の中には自発型のプロジェクトもある。新製品開発がその典型だ。あるいは、イノベーティブな技術開発とか、自社向けの業務システム開発などもそうだろう。こちらは、ふつうスコープが柔かい。コスト制約よりも、プロジェクト価値の最大化がねらいになる。そこで、品質(とくに設計の品質)が重要になる。このような種類のプロジェクトに、計画・契約・計数管理を持ち込んでプロマネに権限を集中し、ギリギリやっても、あまり楽しい結果が出てきそうにない。別の種類のマネジメント技法が望まれるのだ。

これに関連して思うのは、PMBOK Guideに設計論がない、ということである。なぜ、10個の知識エリアには、『設計のマネジメント』が入っていないのか? プロジェクトが独自の製品・サービスを生み出すための有期性の業務であるなら、必ずその中には設計業務があるはずではないか。その設計のあり方、良し悪しが、その後のプロジェクトを大きく左右する。ヘマな設計をすると、作りにくく、時間がかかり、コストもかさむ。

設計によって、その後の段取りや作業が全く変わることも多い。3階建ての建物を作るとき、鉄骨造で設計するのと、木造2X4(ツーバイフォー)で考えるのでは、工法や要員や作業手順が全く変わる。それどころか、力学的構造が全く異なるので、建築デザインの見た目も、大きく異なる。それくらい、設計段階の意思決定は重要なのだ。

なのに、PMの知識エリアには品質やコストはあれど、「設計」がない。設計抜きで、構築(製造・実装・建設)だけがプロマネの仕事、という観念は奇妙である。え? 設計は分野ごとに個別性が高いから、Guideに書くのは適当ではない? だが、そもそも、分野ごとに個別性が高いのがプロジェクトの特性であろう。それでも、共通なプロセスを考えることは十分可能なはずだ。

その一例が、システムズ・エンジニアリング分野から発した「V字モデル」である。これは対象がシステムであれば、人工衛星であろうがワープロソフトだろうが共通に当てはまる。また、「エンジニアリング・マネジメント」という言葉は、日本ではプラント業界くらいしかお目にかからないが、米国にはEngineering Managementを教える専門学科だって存在する。だったらなぜ、PM論の中に、設計マネジメントがないのか?

なお、ここで問題にしているのは「プロジェクトのデザイン」(=WBSをどう作るか)の話ではない。また、製品デザイン(=美大を出たデザイナー達が行う仕事)だけの話でもない。エンジニア達の普通の仕事としての「設計論」である。

現在のPMBOKに設計論が欠けている理由は、わたしの想像であるが、おそらく米国における分離発注の商慣習にあったのではないか、と思われる。つまり、

 「基本設計」の段階 →(見積と競争入札)→ 「構築プロジェクト」(実装・製造・建設)の段階

の二段階に、発注を分離する、という商慣習である。たとえば建築業界では、20世紀前半から、「建築設計」→「施工」が別々の主体で、別契約になることが一般的だった(少なくとも英米では)。プラント業界でも、80年代頃には、「基本設計」(FEED)→「詳細設計・調達・建設」(EPC)が別になるのが一般化した。防衛宇宙産業のことはよく知らないのだが、米国政府発注なので、似たような分離発注形式をとっていたのではないか。

前段の基本設計において、かなり詳細な(=コスト見積が可能なレベルの)仕様書を作成しておき、契約書の雛形も用意しておく。競争入札を経て、後段の構築プロジェクトに入る。そしてPMBOK Guideを作った初期の人たちは、構築プロジェクトにもっぱら携わる業界人だった。だから、プロジェクトの最初にSOWがあるのは、彼らにとって当たり前だったのだ。そして、設計の主要な部分はもう終わっているのだから、知識エリアに設計マネジメントは入らなかった、と。

ところで、これが本当だとすると、IT業界にとってはいささか気の毒なことだった。なぜなら、SIプロジェクトの分野で、「要件定義」→「設計・実装」が別フェーズとして分離するのは、もっと遅かったからだ。ソフトウェア開発プロジェクトでは、一般に要件定義が「柔らかい」(固めにくい)ため、設計・実装のスコープも柔らかくなってしまう。そして、IT系プロジェクトの難しさのかなりの部分は、このスコープの曖昧さから生まれるからだ。

おそらく、初期のPMBOKコミュニティには、IT業界の人が少なかったのではないか。そして、少し後になってから、PMが注目されるようになった(日本での普及期は2000年台に入ってからだ)。そして、PMBOK Guideを学ぶことが推奨された。だがPMBOKが無意識に前提するハード型の一括発注契約を、ソフト型であるIT開発プロジェクトに適用したことが、多少の無理を生んだのではないかと想像される。

そして、この不足を補うべく、BA(ビジネス・アナリスト)の実務標準を最近になって付け加えたのだろう。設計(とくに基本設計)が、プロジェクトにおいて重要だと、あらためて皆が痛感したからである。

ちなみに、IIBAの「ビジネスアナリシス知識体系ガイド (BABOKガイド)」https://amzn.to/2OQvnMF などを読んでいると、同じような設計マネジメントのアプローチが、IT以外の分野でも必要だし有効だ、と気づく。ただ、BABOK自体、Version 3.0になってずいぶん良くなったが、まだ発展途上だという印象が強い。デザイン思考がIT分野で注目を集めている今日、もっと設計論は必要だと思う。

さて、PMBOK Guideに書いておいてほしかった第3のポイントは、プロジェクトの評価論(価値論)である。

プロジェクト・マネジメントの最大の仕事は、決断することだ。決断とは、複数の選択肢から、最も良いと信ずるものを選ぶことである。だが、最も良いとは、どういう意味か?

プロジェクト・マネージャーの責務とは、プロジェクトの価値を最大化することだ、とも言える。それがプロマネの査定、成績表になるはずである。では、プロジェクトの価値とはいったい何か? スコープ・コスト・スケジュールの制約条件(「鉄の三角形」)を守ることだろうか? それとも、成果物のもたらす顧客満足なりベネフィットを最大化することか?

もし後者だとしたら、じゃあ、「ちゃんと作ったけれど、使われないシステム」の価値はどうなるのだろうか? わたし自身も過去にそういうものを作った苦い経験があるから書くのだけれど、その場合、プロマネの点数は落第点となるのか。たとえば、ユーザが旧来の仕事のやり方を変えることに抵抗したら? それはプロマネの責任範囲なのだろうか。

あるいは、逆に、あえて機能とスコープを増やしたおかげで、予算を超過し納期も遅れたが、顧客が喜んで使ってくれるようなシステムを作るのは、是か非か? つまり、プロジェクトの価値とは、成果物(アウトプット)で評価するのか、アウトカムで評価すべきなのか。これが決まらないと、プロマネは判断できないではないか。だが、こうした価値論が、現在のPMBOK Guideには欠けている。

多くのプロマネは、しばしば二律背反のトレードオフに直面するものだ。外注先は、価格の安さを取るか品質を取るか。計画では、コストを取るか、スケジュールを取るか。目標設定では、リスクを取ってでも、リターン(利益)の最大化を狙うべきか? こうしたトレードオフについて、ある程度までは、出発時のミッション・プロファイリングとCharterで、判断基準の優先度を事前定義できる。だが、プロジェクトの途上で起きる全ての判断パターンを、事前に定義できる訳もない。

ところで、PMBOK Guideには価値論がないが、モダンPM論の世界に、全く欠けている訳ではないことは、知っておくべきだ。英国の商務省が開発した標準の中には、「Management of Value」(略称MoV)という標準書がある。現在はAXELOSという会社が版権を所有している。内容をざっと知りたければ、たとえば下記のSlideShareをみるといいと思う。
AXELOS - MoV® - Management of Value - Foundation

このMoVでは、Valueという尺度を、次式で定義している。

e0058447_20303249.jpg

つまり、単にベネフィット(便益)を最大化しても、それに投入する資源(コスト等)がむやみに増えてしまったら、全体としてはプロジェクトの価値が下がるのだ。この定義式は概念的なもので、必ずしも定量化に向いている訳ではないが、一つのわかりやすい表現ではある。そして、こういう議論は、とても欧州のPM論に特徴的だな、とわたしは感じる。欧州のPM研究では、プロジェクトのスコープを所与のものとして扱わず、より大きな社会的文脈の中で評価しようという視点が強いからだ。

類型論、設計論、価値論--この三つを、今後のPMBOK Guideはもう少し盛り込んで欲しいと、わたしは思っている。念のためにいっておくが、わたしは別にPMBOK Guideを批判したり否定している訳ではない。ただ、それが完璧な教科書だと信じて、鵜呑みにしないようにしよう、と主張しているだけだ。

前にも書いたが、教科書を暗記しすぎる人は、プロジェクト・マネージャーには向かない。PMBOKというのは、署名にもある通り、Guideである。ガイドなのだから、皆、自分自身で考え、自分の足で山に登っていく必要があるのだ。


<関連エントリ>
 →「プロジェクトのスコープには硬軟がある」 https://brevis.exblog.jp/27558796/ (2018-09-20)
 →「オーケストラの指揮者かジャズ・バンドのリーダーか - プロジェクト・マネジメントの4つの類型を知る」 https://brevis.exblog.jp/21641066/ (2014-02-02


by Tomoichi_Sato | 2019-04-06 20:48 | プロジェクト・マネジメント | Comments(0)