◆人ベースと仕事ベース

慶応ビジネススクールの高木晴夫先生が「「人ベース／仕事ベースのアークテクチャーにおける組織学習装置」という研究をされている。最近、この研究成果が書籍になって出版された。この本だ。

高木 晴夫「組織能力のハイブリッド戦略」、ダイヤモンド社（2012）

この本はグローバルな経営環境の中で生き延びていくために、人ベースと仕事ベースをどのように組み合わせていけばよいかを、１６３社の調査に基づいて考察したものである。

高木先生によると、経営組織の仕組みは、仕事ベースと人ベースに分けることができる。仕事ベースは、まず仕事があり、その仕事をするために人を採用する。人ベースは、まず人があり、その人が仕事をとってきて実施していく。分業が進むと仕事ベースになっていくわけだが、日本の組織は人ベースのままで仕事をしている企業が多い。

今回の戦略ノートは、この問題をプロジェクトマネジメントの問題として考えてみたい。ちなみに、今回、初めての試みとして、このネタをメルマガの

オンラインコミュニティ「プロジェクトの補助線」

に投げ、意見を戴いた。その上で、記事を書いた。




◆人ベースから仕事ベースへ

さて、もう少し、現状認識として人ベースであることについて、触れておこう。人ベースは、人を中心にして仕事を考え、その人がキャリアを積み、スキルが向上し、人脈ができてくるに従って大きな仕事をするようになる。人ベース、仕事ベースに限らず、新しい事業を立ち上げる局面では、必ずこういう局面はあるように思う。しかし、欧米型はある時点から仕事ベースに変わっていくが、日本はそのまま人ベースで突き進む。何らかの事情で、仕事を起こした人がいなくなる場合には、人ベースで引き継がれていくことも珍しくない。

仕事ベースの典型的な方法は、プロジェクトである。プロジェクトでは仕事はあり、その仕事のために社内外から人を確保（採用）してきて、仕事を進めていく。そのような仕事の進め方を推進するのがプロジェクトマネジメントである。


◆人ベースでプロジェクトを行う日本企業

ところが、日本ではプロジェクトも人ベースであることが多い。プロジェクトマネジメントが注目され始めた２０００年前後に、多くの企業が注目したのがプロジェクトマネジメントではなく、プロジェクトマネジャーだった。つまり、プロジェクトを仕事ベースでやるのではなく、人ベースでやろうとした。最初は小さなプロジェクトしかできないかもしれないが、経験を積んでいくうちに、大きなプロジェクトを立ち上げたり、あるいは、受注してきて、事業として大きくしていくという期待をした。そして、一生懸命、プロジェクトマネジャーを育てた。

しかし、このような展開が結果的におかしなプロジェクトマネジメントスタイルを作ってしまった。上にも述べたように一般的にはプロジェクトマネジメントは仕事ベースであり、プロジェクトを立ち上げる中でプロジェクトマネジャーを決める。

実が人ベースのやり方には、もう一つ、大きな意味がある。権限の問題である。平たくいえば、人ベースでは人が実績を上げ、仕事を大きくしていくとともに、「出世」する。つまり、権限が大きくなり、できる仕事も広がっていく。ここが人ベースのミソだ。キャリアを積んで人脈ができても、権限がなければ大きな仕事はできない。

仕事ベースの場合は、権限はあまり関係ない。トップダウンで仕事が行われるので、仕事を立ち上げるときに、必要な権限もつける。プロジェクトも本来そういうものである。


◆人ベースのプロジェクトの問題

ところが、人ベースでプロジェクトをやろうとすると、権限がついてこない。プロジェクトマネジメントの導入を行った企業が次にやるのが、プロフェッショナル認定制度だ。つまり、プロジェクトマネジャーとしてのランクを認定する制度である。プロフェッショナル認定制度を実施する場合、プロジェクトマネジャーの権限はランクによって決められるべきである。ところが、大抵の制度では実施できるプロジェクトのランク（大抵は規模）を決めているだけである。たとえば、１億のプロジェクトと１０億のプロジェクトでは、当然のことながら必要な権限が変わってくる。しかし、権限は明記しない。ここは、レトリックともいえるし、日本企業の伝統的なガバナンスだともいえる。

ある企業で、ラインの持っている権限を棚卸し、プロフェッショナル認定制度に紐付け、プロジェクトマネジャーのランクごとに委譲する権限を明示した制度を設計したことがある。結局、役員会の承認が下りなかった。この制度そのものはかなり良くできていると思うので、仕事ベースでできないわけではない。おそらく認識の問題で、プロジェクトマネジャーとして自立することを認めていないものと思われる。あくまでも、まずは自分の部下であり、部下にプロジェクトマネジャーをやらせているという認識だ。

人ベースでやろうとすると、チャレンジの含まれるプロジェクトはできなくなる。プロジェクトの承認をする権限を持つ上位者によって、リスクがとれなくなるからだ。その意味で、人ベースのプロジェクトの進め方を変えていく必要がある。どうすればよいか。


◆ステークホルダの問題〜ＩＴプロジェクトの場合

コミュニティで、ＩＴプロジェクト関係の方から、顧客が人ベースを求めるのだから仕方ないだろうと言う意見があった。確かにそのとおり、人ベースから仕事ベースに変えようとしたときに、ステークホルダとの絡みが出てくる可能性があるのが現実だ。特に顧客の問題は、入札との兼ね合いがあるが、技術入札のような形で随契になる可能性が高い情報システムでは人ベースであることは重要かもしれない。

そう考えると、人ベースを残したままで、その問題点を解消するような仕事ベースを入れていくのが現実的だ。プロジェクトの場合、プロジェクトマネジメントは仕事ベースであるので、仕組みは一通りそろっていると考えてよい。今、使われていないだけだ。

その中で、もっとも問題なのが、ガバナンスの問題であり、これはプロジェクト定義のプロセス、ＰＭＢＯＫ（Ｒ）でいえばプロジェクト憲章の作成をきちんと実行すればほぼ、片付くと思われる。


◆人ベースでグローバル化はできないのか

日本に仕事ベースのプロジェクトマネジメントの仕方が根付くかどうかは、現段階でははっきりしないように思う。特に、ＩＴのように顧客がいる場合には、顧客の認識が変わるのは難しい。また、メーカの商品開発などのプロジェクトでも、はやり、技術が人についている側面が強い。

人ベースか、仕事ベースかの違いを、経営的な視点からみれば、雇用の前提が終身雇用なのかどうかで大きく変わってくる。極端なことを言えば、終身雇用であれば、仕事ベースよりは、人ベースの方が有利である。４〜５年前から、終身雇用制が崩れたといっても、やっぱり、意識としてそのような意識が浸透する気配はないし、現実に崩れているようには見えない。

これは、グローバル化でも同じではないかと思う。たとえば、日本企業と対比的に、グローバル化をうまくやっているように見える企業にサムスンがある。サムスンは、人ベースの中に、合理性を追求する仕事ベースをうまく組み合わせているように見える。ところが、サムスンのグローバル戦略の中心にあるのは、人材育成で、その方法は「地域専門家制度」という制度だ。この制度は、入社３年目以上の勤務成績が優秀で、国際化マインドを持つものが選ばれ、海外に派遣される。一旦、派遣されると１年間戻れない。そして、現地の大学の短期プログラムに参加したり、勉強したり、全く自由に活動してその国の文化や地域の特性を身をもって体験し、肌で感じながら、人脈を作っていく。これが任務である。


◆人ベースのプロマネと、仕事ベースの組織的マネジメントを組み合わせる

僕の体験では、グローバルプロジェクトの中で仕事をすることくらい、グローバルな感覚と実務能力が身につくことはないようにも思う。その意味でもプロジェクトの基本は人ベースでよい。

ただ、その際に弊害を取り除くことはもちろん重要だ。弊害は上に述べたような必要な権限と与えられる権限のミスマッチである。この問題の本質は、プロジェクトマネジャーに権限が与えられていないことではなく、プロジェクトの遂行に対して、組織としての体制がとれていないことによる。

仕事ベースとして、プロジェクトスポンサーをしっかりと決め、プロジェクトマネジャーとの間のコラボレーションプロセスを明確にする。ここには、極力、人ベースが入らないようにする。これだけで、人ベースでうまくいくのではないかと思う。

◆関連セミナーを開催します
━【開催概要】━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆戦略を実行するプログラムマネジメント　　　　　　　◆3.5PDU's
　 　　日時・場所：【Zoom】2024年 11月 26日（火）13:30-17:00（13:20入室可）
　　　　　　　※Zoomによるオンライン開催です。
　　　　　　　※少人数、双方向にて、演習、ディスカッションを行います
　　講師：鈴木道代（プロジェクトマネジメントオフィス，ＰＭＰ，ＰＭＳ）
　　詳細・お申込　https://pmstyle.biz/smn/program30.htm
　　主催　プロジェクトマネジメントオフィス、ＰＭＡＪ共催
　※Youtube参考動画「プロジェクトマネジメントの基礎」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　【カリキュラム】
　　　１．プログラムマネジメントとは
　　　２．戦略サイクルとプログラムデザイン
　　　３．ベネフィットのマネジメント
　　　４．ステークホルダーマネジメント
　　　５．プログラムにおけるプロジェクト間の調整
　　　　・プロジェクト間のコンフリクトの調整
　　　　・スケジュール管理とリソース管理
　　　　・リスク管理
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━