コンセプチュアル・マネジメント

pmstyleでは、研修に必要な条件として

【条件１】経験を意味づけ、経験に弾みをつける

【条件２】研修をスタンドアロンで完結させず、プロジェクトマネージャーとしてのアサインに連動させる

【条件３】研修をトップマター（事業部）だと認識する

の３つを掲げ、これに基づいて研修をデザインしている。

条件２は制度上実現困難な企業が多いが、残りの２つの条件はやろうと思えばできる。特に、条件１は重要だ。

経験が重要だというのは多くの人が言うが、経験はしっぱなしでは意味がない。難しい言葉でいえば概念化ができて初めて経験の意味があるし、学習につながる。例えば、失敗したときになぜ失敗したのか、うまく行ったときになぜうまく行ったのかをきちんと分析し、概念化をする。これはレッスンズラーンドの一つであるが、ここで、単にノウハウとして蓄積するだけではなく、理論との結び付けをすることが重要である。プロジェクトマネジャーに対する研修ではこれが最も重要な事項であろう。

それができて初めて、応用力のあるノウハウになるし、また、次の新たな経験につながる。例えば、自分なりに行っている進捗管理が実はＥＶと同じ原理で行っているというのはよく見かける現象である。

その際に、自分のやり方がＥＶと結びつけばＥＶの世界で発見されていること（手法）やノウハウを纏めて使うことができるようになる。そして、それらの手法を自分のやり方に加えることによってさらに、自分のやり方が幅を持つようになる。これが経験を意味づけ、さらに、経験に弾みをつけることだ。

ちなみに上のような条件を考えた弊社のトレーニングはキャリア段階にあわせ、以下の４段階としている。

【ステップ１】
プロジェクトマネジメントの基礎知識を身に付ける

【ステップ２】
プロジェクトマネージャーとしての行動規範を身につける（PMコンピテンシーの獲得）

【ステップ３】
業務の中で遭遇した問題に立ち返り、経験を分析し、必要な知識を補給する

【ステップ４】
業務経験を振り返り、自分のプロジェクトマネージャーとしての特性を知り、自分のスタイルを作っていく

ステップ３、ステップ４の段階においては上に述べたような経験の意味づけと、弾み付けができて初めて研修としての意味が持つことを忘れてはならない。しかし、この指摘をすると、多くの人は、そんな理論を持ち出さなくても分かっているし、できているという態度を取る。もう少し、謙虚にありたいものだ。

ＷＥＤＧＥの９月号に製造業の品質問題の記事が掲載されている。

「電子化偏重・人間軽視」開発現場から崩れる製造業

という記事だ。なかなか、興味深い記事なので、機会があれば目を通して見られるとよいだろう。

この中に、プロジェクトマネジメントの立場からは気になる指摘が書かれている。

トヨタでは、この１年くらい、過去に市場に送り出した商品の品質問題に頭を痛めている。マスコミでも何度も取り上げられているように信じられないようなリコールが多発しているのだ。それを受けて、品質担当の副社長を１名増やして２名にし、さらには担当専務まで設置したが、それでも思ったような効果がでない。なぜか？

これがこの記事の問題提起である。その上で効率とコストを追求するために起こっている「開発プロジェクトでのコミュニケーション不足」があると指摘している。これはトヨタに限らない。僕のコンサルティングをしたプロジェクトでもこの問題はよく直面する。

この種の問題は極めてやっかいである。プロジェクトスコープの中に現れてきにくいからだ。自動化された設計上の問題はない。品質基準も満たしている。そのような中でも、設計者同士が議論をしていると気づく問題も多い。しかし、効率追求・コスト優先の中ではその時間がままならない。

この問題は今に始まったことではない。僕が三菱重工で仕事をしていた頃に、ＣＡＥのシステムの自動設計の開発に携わっていたことがある。このときに多くの設計エンジニアにインタビューしたことがあるが、多くの人はこの問題を指摘していた。僕流に言えば次のようなことを言っていたように思う。「設計というのは形式化できない。ナレッジベースを作っても無理。コラボレーションの中で生まれてくる部分が多い」

さて、この問題、トヨタも気づいていなかったわけでも、手をこまねいていたわけではない。記事によると、早くから問題の所在に気がつき、手を打ってきた。２００３年くらいから、開発段階における設計、生産、調達の横断的なすりあわせを強化してきたという。タラレバになるか、だから、この程度で済んでいるともいえよう。

この問題、プロジェクトマネジメント的にはどうすればよいのだろうか？

難しいのはコストと時間の制約が極めて大きいために起こっている問題で、コミュニケーションマネジメントをきちんとすればよいといった単純な問題ではない。かといって、いまさら、リードタイムや製品原価を緩くする方向に向かうというのはできない相談だろう。

このような状況で唯一の解になりうるのは、今まで真剣に考えてこなかったチームマネジメントではないかと思う。ただし、自動車メーカは製品アーキテクチャーから組織を作りこんでいるので、チームマネジメントを何とかしようといってもそう簡単にはいかないだろう。そこは悩ましい点だ。

一方で、他の業界ではこの矛盾に満ちた問題を解消できるようなチームマネジメントは比較的容易に実現できるように思うのだが、如何だろうか。

実は、この問題、マスプロダクションだけに限った話ではなく、受注生産製品でも起こっている。その典型がＳＩプロジェクトである。ＳＩプロジェクトでは、顧客コミュニケーションの悪さは目に見える形で品質の問題として出てくる。しかし、システム内部の不適合はそう簡単には出てこない。そこで、要件定義や設計時のプロセスマネジメントで品質の作りこみを行うのだが、短納期化やエンジニアのスキルの問題などでコミュニケーションの品質が落ちてきて、それが製品の品質問題になっているケースが増えている。

ＳＩの場合であれば、チームマネジメントを丁寧に行うことで、納期と品質のコンフリクトという問題は解消できる。

日本の現場の強さは、コミュニケーションの強さであるし、上流工程のさまざまな問題のバッファになってきた。実際に「現場あわせ」という言葉が象徴するように、上流工程のコミュニケーション不足を現場のコミュニケーションで解消してきた。

それができなくなってきたのだとすれば、ある意味で転機だといえる。製品開発プロセスにプロジェクトマネジメントを導入し、コミュニケーションマネジメント、リスクマネジメントなどをチームマネジメントで統合していくようなマネジメントが求められるようになってきたといえる。

自民党の総裁選挙が近づいてきて、マスコミがこぞって特集番組を放映し始めた。小泉という首相は非常に面白いことを見せてくれた。それは、議員内閣制でもここまでできるという限界である（本当に限界か、まだできるか、常識的限界を超えて属人的に許される限界かは分からない。おそらく次の首相が方向を決定付けることになるのだろう）。

なぜ、こんな話題を持ち出したかというと、これまでずっと述べてきた組織によるプロジェクトマネジメントのイメージは、ある意味で議員内閣制に似ているからだ。プロジェクトマネジャーは首相である。プロジェクトチームは内閣。スポンサーは与党。ステークホルダは野党や国民。

小泉以前の内閣は少なくともこのフォーメーションであった。ところが、小泉はこのフォーメーションをひっくり返した（と表面的には見える）。世論の支持を背景に、カリスマリーダーのごとく行動した。彼の行動がよいか悪いかはまだしばらく答えがでないと思うが、少なくとも、今までの首相ではフォーメーションをひっくり返すことにより今まではできなかったことをやってのけた。

プロジェクトマネジャーにはあまり権限がないと思っている人が多い。内閣総理大臣もそうだった。しかし、やればこれだけできた。問題はやり方と意志である。

大志あるプロジェクトマネジャーは小泉的を目指せ！

岡野工業の社長（正確には代表社員）である岡野雅行さんが新しい本を書かれた。

岡野 雅行「世界一の職人が教える仕事がおもしろくなる発想法―結果が出ない人はいない」、青春出版社（2006）

岡野さんは今までに４～５冊出版されているが、どの本を読んでも元気付けられる。特に今回の本は、岡野さんの仕事の仕方、考え方のエッセンスを抽出されているので、非常に啓蒙的内容が濃い本だ。

岡野さんの仕事のモットーはこの本にあるとおり、誰も無理だ、できないという仕事をやるのが最高に楽しい、アドリブで仕事をするからこそ楽しいなど、「技術屋」が聞くと涙を流しそうなものばかりだ。

岡野さんは僕の尊敬する経営者の一人だ。大企業に勤める「サラリーマン」と岡野さんの話をすると、決まって返ってくる答えが、社長だからできるとか、中小企業だからできるである。

こんな話は自分が岡野さんの立場になった想像をしてみて１０秒考えれば間違いだと分かる。要するに、違う点を言い訳にしたいだけに過ぎない。岡野さんと彼らの違いは、岡野さんややる方法を考えるが、そのような言い方をする人はやらない言い訳を考える。言い尽くされた話だが、まさにそのもの。

まあ、それは人生観も折込の話になるので、どうでもよい。生涯サラリーマンの人はその人なりの価値観があるだろう。

ただ、考えてほしいことは、顧客や上司から「無理難題」を吹っかけられることは中小企業であろうと、大企業であろうとある。何にしても顧客はエライのだ。

例えば、痛くない注射針を作ってほしいというのに匹敵するような、あるいはそれ以上の無理難題な要件を言われたことのあるＳＩプロジェクトのプロジェクトマネジャーは少なくないと思う。

このときに、「あ～、だから何もわかっていない顧客とはやってられない。営業を巻き込んでから断るか」と考える人と、「お～！、面白い、なんとかしてやろうじゃないか」と考えれられる人では、しんどい目をするのは、間違いなく前者である。

サラリーマンをやっている人に、トム・ピーターズや岡野さんのように、あえて積極的にリスクをとって面白いプロジェクトを作ろうと呼びかけるつもりはない。しかし、おかれた境遇から逃げれないのもまたサラリーマンだ。まさか、公務員のように不作為というわけには行かないだろう。

であれば、そんな人こそ、岡野さんのような考え方をできるようになってほしいなと思う。プロアクティブなプロジェクトマネジメントはそこから始まる。

プロジェクトマネジャーの人にこの本は読んでほしいな。

「失敗学会」の副会長を勤められている飯野謙治さんが最近ソフトバンク新書から

「失敗をゼロにする」のウソ

という本を出 された。大変、よい本だと思うので、ぜひ、読んでほしいのだが、この本のまえがきに、「失敗学」を活用するためのポイントを３つ書いている。

三つ目は

　「失敗を繰り返さないための仕組みづくり」

という失敗学のメインストリームの主張なのだが、その前の２つが非常に興味深い。

一つ目は

「人は失敗をやらかすもの」だと意識すること

だという。そして、二つ目は

「失敗を隠そうとするのは自然の心理」だと素直に認めること

だという。この２つが組織の風土となって、最初に書いた三番目の仕組みづくりが可能になるという指摘をしている。

リスクマネジメントというのは、この

「失敗を繰り返さないための仕組みづくり」

に他ならない。リスクマネジメントの効果が出ないのは、飯野謙治さんが指摘する２つの風土に問題がある。

多くの企業、特に、大手企業でプロジェクトリスクマネジメントのコンサルティングをしているときにこれをひしひしと感じる。つまり、

　自分たちは失敗はしない

という思い。この背景には当然、組織として失敗は許されないという風土がある。この意識がある限り、リスクマネジメントはできない。問題はあってもよいのだが、その問題によって失敗をすることは１００％ないと考える。リスクというのはその問題における失敗行動を取る可能性であるので、当然、失敗しないという前提であれば、リスクはないことになる。

このように考えると、基本的にはプロジェクトを開始する前にすべてのリスクを回避できていなくてはならないということになる。これは、プロジェクトマネジャーと上司の間、また、プロジェクトメンバーとプロジェクトマネジャーの間の両方に言えることである。

ただ、プロジェクトであるのでデッドラインがある。そのため、事前にすべてのリスクを回避できないことがある。このような場合には、その問題は確実に解決できるという仮定の上にプロジェクトを進めることになる。「よきに計らえ」である。当然、失敗するとは思っていないので、その対応で問題が生じると責任問題になる。

この問題と関係するのが二番目である。失敗はないという前提であるが、当然、人間であるので失敗することもある。そこで、失敗した場合には隠すことになる。

リスクマネジメントの枠組みでいえば、リスクモニタリングを公正に行わないことになる。仮に、リスク識別をしていても、そのリスクは発生していないという報告をすることになるのだ。

リスクマネジメントを効果的に行うためには、失敗を隠すことが自然だという認識が重要だ。これはプロジェクトメンバーを信じるとか信じないという視点で捉えてはならない。隠すことは自然なことであり、特定のメンバーの固有の問題ではないと考える。そのような前提でリスクモニタリングをしていく必要がある。

プロジェクトマネジャーがプロジェクトリスクマネジメントを行う際には、一番目のポイントの

「人は失敗をやらかすもの」だと意識すること

を徹底的に意識付けする必要がある。このためには、原理を重視する。正しいことと正しくないことを明確にするのだ。それをしないと失敗を失敗だと認めない（リスクの発生を無視した）ままで前に進んでしまう危険がある。

これがクリアできれば、隠す必要性が小さくなる。つまり、リスクへの早期の対応が可能になる。そのとき初めてリスク対策が意味を持ってくる。

そんなプロジェクト組織の作り方を議論するセミナーを開発した。

リスクに強いプロジェクトと組織を作る（リンクあり）

ＰＭコンピテンシーの仕事をしているうちに、だんだん、プロジェクトマネジャーに足らないと思われるものがはっきりしてきた。

　コアマネジメントスキル

である。

プロジェクトマネジメントというのはどちらかといえば、テクニカルな色彩の濃いマネジメントである。ＰＭＢＯＫはその象徴でもあるが、「ツール」や「技法」に依存する割合が多い。

確かに、建設の仕事だとかを考えてみると、このようなマネジメントは必要なのだと思う。延べ人数で数万～数十万人の人を動かして一つの目標を達成する。このような仕事では今のようなプロジェクトマネジメントの枠組みは不可欠だろう。

一方で、今、盛んにコミュニケーションやネゴシエーションといったヒューマンスキルが注目されるようになってきている。これらに注目が集まる理由をよくよく聞いていると、マネジメントスキルの欠如をヒューマンスキルでカバーしようとしているようだ。正しいかどうかは別にして、この感覚はちょっと違う。

家を建てることに例えてみると、以下のような比喩ができる。

　基礎：コアマネジメントスキル

　デザイン（機能性）：プロジェクトマネジメントスキル

　デザイン（快適性）：ヒューマンマネジメントスキル

今、行われていることは、基礎工事が悪くて、ドアの立て付けが悪くなったときに、ドア枠をフレックスな構造にしておくことにより隙間風が入らないようにする仕掛けを作っているようなものだ。要するに、「ギミック」なのだ。

もっといえば、コアなマネジメントスキルを持たない人材がもつプロジェクトマネジメントスキルというのもギミックだという気もしなくもない。これは少し言いすぎかな、、、

「ギミック」が悪いどうかは別問題だ。

組織としての評価のポイントは２つある。一つは、その家にどれだけ住み続けるかだ。仮住まいで１０年ほど住んだら取り壊してしまうのであれば、それも一つの選択だ。

その際のもう一つのポイントは、コスト。基礎をしっかりするのと、このような「ギミック」を施すためのコストを比較し、「ギミック」の方が安いとすればそれでもいいのかもしれない。

個人のとして評価は言うまでもない。その会社が潰れても生きていかなくてはならない。基礎が大切だ。基礎がしっかりとしていれば、「ギミック」など必要ない。

「ギミック」を身につける前に、本物のマネジメントスキルを身に付けたいものですね。

新・ＰＭコンピテンシー強化術（スキル編）～プロジェクトマネジメント実践を強化するマネジメントの原理原則（リンクあり）

プロジェクト（マネジメント）の議論をするときに、スコープを仕様というニュアンスで使っている人が多いが、ご存知の通り、これは正しくない。スコープというのは成果物と役務の相対を指す言葉だ。ＰＭＢＯＫではこれをさらに明確にし、

●プロジェクトスコープ：規定された特性や機能を持つプロダクト、サービス、所産等を生み出すために実行しなくてはならない作業

●プロダクトスコープ：プロダクト、サービス、所産に特有の機能や特性

と区別して使えと書いている。

ここまではいいと思うが、では、スコープマネジメントというのは何をすることなのか？問題はこちらだ。仕様管理、構成管理、変更管理だと思っている人が多い。これが冒頭の話。

実は、ＷＢＳがうまくかけない悩みを持つＰＭは極めて多いが、ＷＢＳは両方のスコープを統合するツールであるので、このスコープマネジメントの認識がないとまず、上手に作れない。

実際には、ここに工法（仕事の進め方）が絡む。建築プロジェクトを考えてみると分かりやすいが、ある仕様の建築物を作ろうとすれば、必ず、工法を決める必要がある。これがプロダクトスコープとプロジェクトスコープである。プロジェクトスコープとプロダクトスコープは１対１の場合も少なくない。

逆にソフトウエアなどでは自由度が高く、プロダクトスコープは厳密に管理する必要があるが、プロジェクトスコープはあまり真剣に考えない。プロジェクト見積の中でも、プロダクトスコープをベースにして見積もり、それにプロジェクトスコープの配慮を入れるというのが普通である。

実際にはプロダクトスコープとプロジェクトスコープはもっと微妙な関連にある。プロジェクトの目的を達成するためにプロダクトスコープだけを調整するのではなく、プロジェクトスコープを調整することを考える必要もある。つまり、工法の工夫だ（要員数の調整もこの中に含まれる）。

このマネジメントを一口でいえば、プロジェクトスコープで調整するか、プロダクトスコープで調整するかを工夫することより、プロセスをシンプルにし、それによって生産性を上げること。

プロジェクトスコープとプロダクトスコープの両方をマネジメントする方法を説明することは非常に難しいが、よい本を見つけた。経営工学の大家で、良い仕事をされている慶応大学の中村善太郎先生のご本だ。

この本は、仕事を「もの」と「こと」に分けて、整理し、調整することにより、プロセスがシンプルになり、生産性が上がることを書かれた本。

先生の言われている「もの・こと」分析は、例えば

　「素材」を「製品」に変える「こと」

　はじめの「もの」をおわりの「もの」に変える「こと」

として捉え、この変換過程を、「もの・こと」図として書くことによって、スコープがきれいに整理でき、仕事の最適なプロセスを見つけるという発想。これは非常に分かりやすい。

この問題、結構、重要なのに考えられていない。

計画することをデスクワークだと考えているプロジェクトはだいたい失敗する。

　計画をするとは段取りをすること

である。つまり、計画の対象になる作業を実施する準備をすることである。

こんな例を考えてみて欲しい。

システムの受注開発をする。「計画書」に顧客から仕様が出てくると書く。その計画に基づいて、顧客にそのように対応してもらえるようにお願いをする。当然、顧客には顧客の都合があるので、素直にはウンを言わないが、そこを何とかしながら計画を実行していく。これをステークホルダマネジメントだという。ステークホルダマネジメントの甲斐なく、顧客からはお願いした通りのアウトプットは出てこない。結果として、スケジュールが遅れる。

このような状況はよくあるだろう。どこに、問題があるのだろうか？おそらく、多くの人はステークホルダマネジメントの問題をいうのだと思う。

しかし、このトラブルの本当の問題は、「計画ができていない」ところにある。計画を作るというのは、計画書に書くことのすべてについて、裏づけを取るという作業である。

どうもリスクマネジメントを導入するようになって、裏づけを取らずに、書いたことが実行できないのはリスクだと扱いたがる傾向がある。これはトンでもない間違いだ。

例えば、上の例で、顧客との間で、顧客側の具体的なスケジュールも含めて、合意をし、その通りにやってくれるという確約を取る。これは計画作業に他ならない。段取りだといってもよい。それでも、顧客の方に不測の事態が発生し、できないかもしれない。これがリスクだ。

確かに、ステークホルダマネジメントだとか、コミュニケーションマネジメントだとかが必要だというのはその通りなのだが、本当に必要なのは、計画の実行の中ではなく、計画を作るところである。

このような考え方で、pmstyle のプロジェクトマネジメント（ＰＭＢＯＫ準拠）はコミュニケーション計画を立ち上げプロセス群の中で、ステークホルダ分析を行うと同時に策定すべきだとしている。

これがプロアクティブなプロジェクトマネジメントである。

コミュニケーションに関心を持ち、コミュニケーションをトレーニングしようと考える人は多い。自分の失敗を振り返ってみると、そこにコミュニケーションの失敗があるというのがその理由だと思う。

左の図を見てほしい。ある組織で行ったトラブルの分析結果である（クリックすれば大きくなります）。過去のプロジェクトに対して、プロジェクトで発生したトラブルを大きいほうから３つ抽出し、その主要原因を２つまで上げていき、結果をＰＭＢＯＫの知識領域とプロセスのマトリクスを作り、分析したものだ（原因はほとんど２つ上がった）。

見て戴ければ分かるとおり、コミュニケーションが圧倒的に多い。

理由は、表面上は他のトラブルなのだが、分析するとコミュニケーションの問題もあるというケースが圧倒的に多かったためだ。

「犯罪の影に女あり」と同じくらい、「問題の影にコミュニケーションあり」は確率が高い。

ここでいうコミュニケーションって何かという問題。例えば、「口べたで相手にうまく自分の考えを伝えることができない。それゆえに問題になった」。こんなケースは、そうそうあるものではない。

コミュニケーションというのは車の運転と同じ。下手な人が、下手な人とであったときに初めて問題が生じる。それが顧客とベンダーという立場であったにしろ、丸く収まるのがコミュニケーションである。

昔に較べてコミュニケーションが問題になるというのは確かにスキルが低い人間が増えているということは間違いない。したがって、交通事故の可能性も高くなる。

じゃあ、みんなで車の運転を上手になりましょうという方向にいくかというと、そうは行かない。車の運転なんか個人の資質の問題があって、どんなに練習しても下手な人は下手だ。

では、どうするか？交通ルールを作るのだ。車線、信号、標識などなど。作っても、無視する輩がいるという問題はあるものの、ない状態に較べると、ずいぶん、まし。

でも、交通ルールだけでは解消できないような微妙な状況もある。例えば、山道を下っている。対向車が上ってきた。さて、問題。どちらが道を譲るか。道路交通法では規則はないが、上り優先という規範を作り、警察とか安全協会がそれをドライバーコミュニティで常識化している。

ここでさらに問題。そのときに谷側が崩れ落ちそうとか、あるいは、山側から落石がありそうだったらどうするか？これにしても、実際に警察が配っている教則には

「片側が転落のおそれがある崖になっている道路で、安全な行き違いができないときは、崖の側の車は一時停止して道をゆずりましょう。」

「山道では、路肩がくずれやすくなっていることがあります。このような場合の行き違いでは、路肩に寄り過ぎないよう注意しましょう」

と書いてあるらしい。これも規範なのだが、「上り優先」という規範とはずいぶん質が違うことが分かる。ドライバーの判断力が試される。つまり、ここでスキルが必要になるのだが、逆にいえば、ここまでは規範を決めることによってカバーできるという言い方もできる。

今のプロジェクトコミュニケーションを見ていると、スキルにばかり目が言っているが、規範はせいぜい、会議体だけである。これは交通ルールでいえば、道路交通法だけを決めているレベルだ。山道では上り優先というレベルの規範は決めていないし、さらに、その上のレベルの規範はまったく決めていないケースがほとんどだ。

なぜそんな状態となっているかいうと、規範も含めてコミュニケーションスキルだと考えていて、マネジメントとスキルの区別がついていないからだ。これは、みんなＦ１ドライバーになって行動を走ろうといっているに等しい。ありえない。

ルール・規範として決めるべきことは決める。そして、その規範を守る風土を作る。その上で、まだ、コミュニケーションの問題が発生するようなら、スキルベースを上げる。

そんなシステマティックな取り組みが必要なのではないかと思う。これがコミュニケーションマネジメントだし、そこまでできて、初めてコミュニケーションがマネジメントの基盤になる。

コミュニケーションが問題だ、重要だといっている人にこの議論を吹っかけると、１０人中９人まではそこまでしなくてもという。複雑性、新規性の高いプロジェクトで成功するのは、１人である。

プロジェクトマネジメントはあらゆるダイバーシティが前提となったマネジメント手法だということになっている。

しかし、現実を見ていると、女性のプロジェクトマネジャーは少ない。仕事がら、エンジニアリングだけでなく、マネジメント系のプロジェクトを含めて、１０００人近くのプロジェクトマネジャーにお会いしているが、女性は５０人もいないだろう。

不思議だ。

中国の会社で２社、コンサルとしてのお付き合いのある新興会社がある。１社はソフトウエアを開発する会社、１社はシステムを構築する会社だ。両方あわせると、１００名くらいのプロジェクトマネジャーがいるが、女性が４０名くらいいる。

欧米の会社と仕事をしていても、女性のプロジェクトマネジャーと出会うことは珍しくない。というより、女性であることを意識することはあまりない。

一方で、特にＩＴの企業では、プロジェクトマネジャー足らないというのは挨拶代わりになっている。仮に、日米のＩＴ業界の生産性が同じだと仮定すると、今のジェンダーダイバーシティの状況で日本企業ではプロジェクトマネジャーが足りるはずはない。

本来であればダイバーシティを増加する方向に向くはずのプロジェクトマネジメントが、日本では逆の方向に向いている。これは興味深い傾向である。

いろいろと考えてみたい。

ＰＭ職が特殊性があるかないかは分からないが、一般的な職業については、結構なボリュームの調査がある。

多様性をいかす組織

https://mat.lekumo.biz/books/2005/10/post_0d0f.html

この辺りにヒントがあるようにも思える。