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

昨日は、第１回のPMstyleプライベートセミナーを開催した。好川と峯本さんがスピーカーを務め、

　「世界の標準に見るプロジェクトのマネジメントの方向性」

というテーマで行った。このセミナーは今までにPMstyleのセミナーにきていただいた方への感謝の意味を含めて、限定的に行うセミナー。当然、メルマガなどでは告知していないので、このブログの読者でもセミナーページを見られていない方もおおいだろう。

【第１回　PMstyle Private Seminar】世界の標準に見るプロジェクトマネジメントの方向性

久しぶりにメルマガの開始当時にやっていたみんなが参加するフロアディスカッションをやった。面白かったが、その話題になったのが、Integrity（インテグリティ）。

峯本さんの話に誘発されて、フロアから、プロフェッショナルにインテグリティが必要なのは分かるが、現実にそれはどう実現するのかという質問が口火になったのだ。

僕は、持論である、日本語のボキャブラリがないものを標準として導入するのは、文化を創るに等しい仕事だという立場で意見を述べたが、実はこれを一番感じているのが、チャーターである。

名詞　charter　はコウビルド英英では以下のように説明されている

A charter is a formal document describing the rights, aims, or principles of an organization or group of people.

一方で、charter に当てられる日本語「憲章」を広辞苑で引くと

重要なおきて。原則的なおきて。

と説明されている。おきてとは何かも書いていないし、重要とは何かも書いていない。

ＰＭＢＯＫでプロジェクト憲章というツールにはじめて出会うと、「プロジェクト憲章には何を書いたらいいのだろう」という疑問を持ち、説明を読んで、「ああ、そういうものか」と納得する。

ＰＭＢＯＫに書かれていることはあたかも、ＰＭＢＯＫで決められているように思えるが、実はこれはプロジェクトチャーターというツールというレベルで決まっているというよりも、文化、「しきたり」が charter という言霊になっているような話である。

charter　という動詞は、例えば、飛行機をチャーターするとかいう使われ方をする。これは、「やとう」、「特権を許す」という意味である。権限委譲よりももっと強いイメージだ。

ついでにいえば、charter　という動詞には、「許可する」という意味があり、許可書を発行するという意味でもある。つまり、 charter というのは許可書なのである。英語では、project chartering　という言葉がある。プロジェクトをチャーターするのである。チャーターするためには、rights, aims, or principles of an organization をはっきりしておく必要がある。明快である。

言葉からこんなことを考えてみると、なんとなく、プロジェクトというのが組織にとってどんな位置づけのものか、感じることができるのではないだろうか？

ところが、プロジェクトチャーターをプロジェクト憲章とした瞬間に、このような言葉を構成する世界はすべて消えてしまう。だいたい、この憲章って誰が作るのかといった議論すら怪しくなっている。日本にスポンサーシップが根付かないのはこのためではないかと思っている。

マネジメントには、こういう例がたくさんある。例えば、昨日のセミナーで峯本さんが紹介したレスポンシビリティ（resopnsibility）。責任概念にはレスポンシビリティとアカウンタビリティがあるが、これは、いずれも「責任」である。言葉がないのだから、この区別をしろというのは無理な話だ。レスポンシビリティという概念がないので、コミットメントという概念もできない。

アカウンタビリティもレスポンシビリティもコミットメントもないところで、マネジメントを実行しようと思えば、プロセスにするしかない。これが、日本人にＰＭコンピテンシーがなかなか理解されない理由であろう。

しかし、このような壁を乗り越えて、コンピテンシーを身に付けていかない限り、本当の意味で日本人がプロジェクトマネジメントを実行する日はやってこないだろう。

壁を乗り越えずに、日本は日本のやり方で、米国のやり方とインタフェースをとっていくという方法もある。欧州ＰＭ協会のＩＣＢなどがやっている方法だ。

トヨタが米国文化の象徴のひとつともいえる自動車で世界一の企業になった。単に世界一になっただけでも凄いが、もっと凄いのは自分たちのマネジメントのやり方を世界中に普及して現地生産拠点を増やし、世界一になった。これは素晴らしいことだ。

なんどかＴＶでその方法をみたが、非常に地道なトレーニングをしている。インストラクタ（トヨタウェイのエバンジェリスト）が公私につき、模擬のラインを作ってスキルアップを図ると同時に、その考え方を丁寧に教えていく。「私」の部分でも、「トヨタマン」としての振舞い方を教える。まさに、人材育成の部分でもコツコツとやって、今の状況を作った。

こういうやり方もある。

◆はじめに

ゴールデンウィークで少し間があいたが、前回のコラムでは、ＰＭＯのマネジメントについて、最低限でも

（１）ＰＭＯ活動の成果の定義と測定
（２）ＰＭＯの戦略と役割の見直し
（３）ＰＭＯの機能の評価と見直し
（４）ＰＭＯスタッフのローテーションと育成

の４つは実施する必要があることを述べ、（１）のＰＭＯ活動の成果の定義と測定について説明した。今回から（２）について説明する。その前に、前回の記事について「ＰＭＯはひとつしかおかないのか？弊社では、プロジェクトの中にもあるし、事業部にもある。会社としてのＰＭＯもある」という質問を戴いたので、これに回答しておきたい。

◆ＰＭＯの種類

ＰＭＯといっているものにはいろいろなものがある。例えば、米国では以下のような分類が一般的である。

（１）CPMO（Corporate Project/Program Management Office）
　あとで説明する
（２）PMO（Project Management Office）
CPMOによって確立されたプロジェクトのマネジメントの標準の適用による効果を見ながら、事業部、BU、リージョンなどの範囲で、戦術的なマスタープランに対する責任を持つ
（３）PSO（Project Support Office）
CPMOによって確立されたプロジェクトマネジメントの標準の監視をし、オペレーショナルなマスタープランに対する責任を持つ
（４）PO（Project Office）
ミッションクリティカルなプロジェクト、大規模＆複雑なプロジェクトの直接的な支援を行う責任を持つ

これらは、ひとつの組織の中に共存する。

◆ＣＰＭＯの役割

この中で、注目すべきなのは、ＣＰＭＯである。日本でもエンタープライズＰＭＯとか、コーポレートＰＭＯといった位置づけのＰＭＯがある企業は少なくないが、ＣＰＭＯというのは

全社のビジネス機能の一つに位置づけられる。財務、マーケティング、営業、エンジニアリング、製造などと同様に、プロジェクトマネジメントに対するオーナーシップを持ち、プロジェクトのマネジメントのベストプラクティスを全社に展開することを目的とする組織

をいう。つまり、プロジェクトマネジメントというのは組織機能の一つである。メルマガの記事に何回か書いたように、最近、「正しいプロジェクトを正しく行う」ということに関心が高まってきている。しかし、実は、これだけでは不十分である。

「正しいプロジェクトを行う」ことと、「正しく行う」ことは組織の中では自動的には結びつかないことが多い。例えば、正しいプロジェクトを正しく行うためには、組織がプロジェクトをやる意味が十分にプロジェクトに伝わり、反映される必要がある。プロジェクトマネジメントにはプロジェクト憲章というツールがあるが、これだけでそのプロジェクトを実施する組織としての意味が十分に伝わるものではない。この部分は人間系（組織）の課題になる。

◆「正しいプロジェクトを正しく行う」ためにはＣＰＭＯが必要

つまり、「正しいプロジェクトを正しく行う」ためには、「正しいプロジェクトを行う」ことと、「正しく行う」ことをコンバインする必要があるのだ。これはシニアマネジャーの役割であるが、シニアマネジャーが個別にやるには横通しの問題からおのずと限界がある。

そこで、プロジェクトマネジメントのオーナーシップという話が出てくる。プロジェクトマネジメントのポリシーを明確に定め、そのポリシーに従って、シニアマネジャーがうまくプロジェクト選定とプロジェクトマネジメント実行を結びつけてやるのだ。このようなオーナーシップを持つためには、ＰＭＯを戦略組織とし、「ＣＰＯ（Cheif Project Management Officer）」とでもいう役職を設置する必要がある。

最後にひとつ、日本の企業のＣＰＭＯの特徴に触れておく。日本の企業では、ＣＰＭＯがプロジェクトマネジメントに対するオーナーシップをもてないケースが多い。ぜひ、考えてみて欲しい。仮に、あなたのＰＭＯが全社標準を作っているとすれば、以下の３点をチェックしてみて欲しい。

【簡易診断】

（１）全社のプロジェクトマネジメントポリシーを作っている
（２）標準の運用で、プロジェクトスケジュールを無視して、計画書の書き直しを命じることができる
（３）プロジェクトマネジャー以外の部門のプロジェクトマネジメントに対する責任を明確にしている

適材適所という言葉をネガティブに受け取る人はほとんどいないだろう。しかし、この考え方は結構、「曲者」である。

適材適所というと、ほどんとの場合、「新しいやり方はしない」、「新しいやり方は認めない」という前提がある。ほとんどの場合と書いたのは、例外的に「何か新しいことをする」場合の適材適所というのは、新しいものを生み出せる人の配置を指すからだ。

パフォーマンスマネジメントの中にストレッチゴールと呼ばれる手法がある。これは個人に目標を与える際に、すでにその人が達成している目標よりやや高い目標を与え、その達成を「期待」することだ。

では、チームパフォーマンスをあげるにはどうするか？ひとつのやり方は、一人ひとりに対してストレッチゴールを与えることである。その積み重ねがチームのパフォーマンス向上に繋がる。確かにそうだ。これだけで十分か？

多くの人は、ここでチームワークといった「オバケ」を思い浮かべるのではないだろうか？

コンサルをしたプロジェクトでこんな経験をしたことがある。化学製品の開発プロジェクトだったのだが、プロジェクトの途中で中途採用の技術者がプロジェクトに入ってきた。とりあえず、そこの会社に慣れるためということで、まあ、勉強がてらといったところだ。

最初はメンバーの話を聞く中で、雑用係みたいなことをやっていたが、半月ほど経って、３名の実験チームの一人になり、実験の一部を担当した。ところが、他の２人と較べると常に早く終わる。最初はチームリーダーは、なれないので、やり方を間違っていると思ったらしいのだが、そうではなく、検証ロジックを組んで、並行して実験を進めていた。それで早かったのだ（といっても単なる実験計画法だが、、、）。これは前の会社で身につけた方法だった。ただし、技術スキルはもうひとつで、実験はいくつか手戻りがあった。

プロジェクトマネジャーは、仮にこの技術者がプロパーの社員であれば、その（重要プロジェクトと位置づけられた）製品開発プロジェクトには選ばれなかっただろうし、そもそも、うちの会社でエンジニアとして生き残れるかどうか怪しいとまで言っていた。にも関わらず、このプロジェクトマネジャーは、彼のやり方を自分のプロジェクトにどんどん取り込んでいった。

この例は偶発的だが、本当の意味での適材適所というのは、こういうものである。つまり、多様な視点で考え、どの視点が今一番必要かということを見極め、その視点から優れた人を割り振ることである。こうすれば、適材適所というのは失敗しないための方策ではなく、チームとしてストレッチゴールを達成するための方策になる。

冒頭に述べた曲者と書いた理由は、この視点設定ができない限り、いくら適材適所といっても非現実的だということだ。楽天の野村監督がヤクルト時代に雑誌のインタビューでこんなことを言っていた。「巨人みたいに１番が出塁し、２番がチャンスを広げ、３～５番で点を取るというような単純な野球なら、１番に足が速い人、２番にバントのうまい人、３番は足が速くて、中距離ヒッター、４番はホームランを打てる人、５番は勝負強い人と並べればいい。でも、そんな選手がいなければ、どんな野球をやるかというところから考え、その野球をできるチームを作らなくてはならない。これが王や長島には分からない監督の醍醐味」。

野村監督のどんな野球をやるかというのが視点設定である。人がいないといいながら、ステレオタイプのやり方でやって、人がいないから失敗したというのはナンセンスもいいところだ。確かに、個人の目標をストレッチしながらやっていけば、少しずつは、選手も育っていくかもしれないが、その前に監督を首になるだろう。

この議論はもうひとつ面白い含意がある。個が先か、組織が先かという議論でもある。ある視点設定でスペシャリストになると、別の視点設定をする組織では活躍できない。トルシエが中村俊介を選ばなかったのはこれだ。ここで個が先なら、自分の身につけたスキルに合う組織を捜すということになる。組織が先なら、個性を組織に併せるしか生き延びる道はない。つまり、自分のスタイルにこだわらず、組織の求めるスタイルになっていくことだ。

日本の会社は、個を活かすとかいいながら、やっぱり、組織が先で個を活かす方向を求めているだけのように見えるのはなぜだろうか？最後に、ひと言。モダンプロジェクトマネジメントというのはどう考えても個がありきの手法だな。

米国人は分ける文化を持っている。これは、コンサルタントのキャメル・ヤマモトさんの指摘だ。

鷲・龍・桜
https://mat.lekumo.biz/books/2007/04/post_46a2.html

この本を読んだときに、ピンときた。

ゴールデンウィークで多少気持ちの余裕があったので、それぞれの文化というのがどういうものかというのを、ショートストーリー仕立てにしてみた。

合わせる文化【ストーリー編】
https://mat.lekumo.biz/ppf/2007/04/post_8f2d.html

分ける文化【ストーリー編】
https://mat.lekumo.biz/ppf/2007/04/post_5872.html

プロジェクトマネジメントといった話は抜きにして、どちらの進め方がよいと思われるだろうか？意見をお持ちの方は、ぜひ、ブログにコメントを頂きたい。

どちらがよいかは別にして、確実にいえることがいくつかある。

一つ目は、分ける文化の方が実行が易しい。もっと正確にいえば、組織としての実行が易しい。今回のストーリーの場合でも、父親がしっかりとしていればこういうやり方はできる。つまり、リーダーがしっかりしていれば、分ける方が組織としての生産性は高くなる可能性が高い。

誰でもできるようするには分ける方がよいと即答する人もいるだろう。注意しなくてはならないのは、確かに実行者の能力が低い場合に有効な方法だという一面はあるし、これが一義的であるが、そのほかに、非定型なことをする際には分けることによってスムーズにできるという側面もある。合わせる方法だとある程度の適応期間が必要になる。

農耕民族が毎年同じ場所に土壌の改良をして少しでも多くの収穫を上げようとする場合には合わせる文化のほうがよい。ところが、狩猟民族が毎日少しでも多くの獲物を得るためには分ける文化が必要である。大学（システム工学科）の卒業式のときに、先生が「みなさんは狩猟のできる農耕民族を目指せ」と言われたのにひどく感動したことがある。結局、バランスの問題なのかもしれない。

二番目。
合わせる文化の方が、その成功が人間に依存する割合が高い。これは一番目の合わせることは実行が難しいという事実と関係が深い。人間に依存する割合が高いので、一朝一夕にはできない。積み重ねが必要だ。

三番目。
合わせる文化の人が分けるやり方をするのはしんどい。あるいは、分ける文化の人が合わせるやり方をするのはしんどい。
そもそも、「仕事を分担する原理」を発明したのはテーラーであるが、テーラーの原理には、「経済的刺激」によってワークモチベーションを生み出していることへの批判が常について回っている。形は違うが、この発想は目標管理として引き継がれている。ビジネス組織でいえば、分ける仕事の方法と目標管理はだいたいワンセットになっており、これが合わさってストレスになっている感がある。
昨今、ストレスマネジメントが注目されているが、合わせる文化を持つ組織が、ストレスの発生する仕事のやり方を受け入れて、ストレスマネジメントに注力するか、あるいはストレスを発生しない仕事のやり方にいくかは微妙なところだ。
特に、この議論をする場合には、これまた、最近、注目の「クリエイティブクラス」といった新しいガバナンスの概念も気になるところである。

マッケイ一家は、カリフォルニア州ビバリーヒルに住んでいる。父親のナット（Nat)、母親の淳子（旧姓　近藤）、長男・ディラン（Dylan）、次男・スティーブ（Steve）、長女・ケリー（Kelly）の５人家族。

昨年、日本旅行をし母親の淳子の友達の田中さんのところにステイした。今年は、田中さん一家がステイすることになった。淳子はクルマでロサンゼルス空港まで出迎える。

家では、ナットが仕切って、歓迎パーティーの準備をする。

ナット「田中さん、つくのはお昼過ぎだし、バーベキューとビールで歓迎しようと思っているのだが、何か、他にいいアイディアはあるかい」

ディラン「天気もいいし、いいんじゃない」

スティーブ「日本人は魚介類が好きだっていうし、肉だけじゃなく、魚も焼けば」

ナット「それはいいかもしれない。ケリーはどう思う？」

ケリー「時差で体調悪いかもね。日本人ってあまり油濃いものを好まないというので、肉も脂肪が少ないところがいいかもね。」

ナット「グッド。じゃあ、今日のメニューはバーベキュー、材料は牛肉、魚、野菜だ。牛肉はできるだけ脂身が少ないところ。魚は白身がいいな。スズキなんかいいな。野菜は、コーン、ピーマン、オニオン、ポテト、マシュマロくらいでいいか。あと、ウィンナーだな。じゃあ、役割分担だ、まず、ディラン」

ディラン「はい」

ナット「ディランはまず、ミートショップ○○にいって、牛肉２Ｋｇ、次にスーパー○○でコーン１Ｋｇ，ピーマン５００ｇ、オニオン３Ｋｇ、ポテト３Ｋｇ、マシュマロ１Ｋｇ買ってきて。そのあと、隣のリカーによって、ビール５０本買ってきて。わかった？」

ディラン「わかった。予算は？」

ナット「肉が１００ドル、野菜が５０ドル、ビールが１００ドルだ」

ディラン「了解」

ナット「スティーブは、スーパー△△で、ウィンナー２Ｋｇととスズキの大きいの一匹を買ってきてくれる。予算は全部で１００ドルだ、いいかい？」

スティーブ「ＯＫ」

ナット「今、９時で、たぶん、道が込んでいないと１３：００には到着する。そこで、ディランはルート○○から××のルートで行こう。この時間ならすいている。帰りはルート●●がいいだろう。今から出ると９時４０分にはミートショップ○○につくので、買い物を２０分で終わろう。そのあと、スーパー○○につくのが１０時１０分だな。こちらは買い物に３０分かかるとして、１０時半か。隣が、リカーなので、１０分でビールを買い終えて、１０時４０分か。リカーからは２０分だな。１１時はつくか」

ディラン「ちょっと厳しいんじゃないか。道込んだり、店でお客が多いと無理だよ」

ナット「そうだな。じゃあ、２０分余裕を持って、１１時２０分までに家に戻ってくることにしよう。１１時２０分から、バーベキューの準備にかかれるようにしておくから、何とか、１１時２０分までに帰ってきて。」

ディラン「了解」

ナット「スティーブはルート○△の往復でいいな。片道２０分ってところだから、買い物に３０分かかるとして、１１時には帰ってこれるか。」

スティーブ「ＯＫ」

ナット「ケリー、やっと君の出番だ。君は、バーベキューの道具と食器の準備だ。まず、最初にガスボンベの点検をして。なければ、２丁目の雑貨でかってきて。コールマンだ。１１時にスティーブ、１１時２０にディランが帰ってくるので、もし、早く終わった休んでいていいよ。１１時から、１２時３０分までの間に準備しよう。１１時から３０分で魚をさばこう。１１時３０分から１２：２０分までで、肉と野菜を準備すれば、１２時３０分には準備オーライだ。」

ケリー「わかったわ」

ナット「じゃあ、始めようか。何かあるとまずいので、１時間に１回、パパに状況を連絡してくれ。もし、誰からの状況で予定を変更しなくてはならない場合には、パパから連絡するから」

＜１時間後＞
ディランから電話「行きの道が少し込んでいて、さっき、ついたところ。店の方はすいているので、５分くらいの遅れで、スーパーにつくと思うよ。１１時２０分は楽勝だと思う」

ナット「そうか、そのなることを祈っているよ」

スティーブから電話「パパ、こちらは予定どおりです、１１時前には帰れそう」

ナット「了解。お～い、ケリー、君はどんな具合だ」

ケリー「準備は終わった。やっぱり、ガスがないので、これから買ってこようと思っているところ」

ネット「そうか、じゃあ、気をつけて行ってらっしゃい」

＜２時間後＞
ケリーとスティーブは帰ってきたが、ディランから電話があって、

ディラン「まずい。必要なものは全部買ったけど、事故渋滞があって、１１時２０分には戻れないと思う。早くても１１時３０分、遅くなると１２時近くになるかもしれない」

ナット「わかった、君が事故をしないように、気をつけて、できるだけ急いで帰ってくれ」
電話をきり、ケリーに言った

ナット「ケリー、ディランは遅れるそうだ。もう、買い物は全部終わっているそうだから、どうしようもない。まず、ママに電話して、何時くらいにつくかを確認して」

ケリー「わかったわ」

ケリーは淳子に電話して確認したところ、予定通りだという。そこで、今度は、ナットが電話をした

ナット「ちょっと準備が遅れているんだ。すまないけど、事前に打ち交わせておいたように、ルート××にルートを変更して、形式を楽しんで貰って、１３：３０くらいに戻れるようにしてくれないか」

淳子「わかったわ」

１２時前にディランが戻ってきて、それから１時間半で、準備を追え、無事、田中さんを迎えることができた。

田中家は、父親の剛志、母親の淳子、長女・春子、次女・夏子、三女・秋子、四女・冬子の４人兄弟の６人の家族だ。京都に住んでいる。

ある日、母親の淳子の友人であり、米国人と結婚して米国に住んでいる近藤さんが家族５人で日本旅行をするということで、何日か田中家に泊まることになった。淳子とは２５年ぶりの再会になるらしい。淳子は関空まで迎えに行くので、姉妹でご馳走をつくり、迎えることになった。

剛志「かあさんの大切な友人やから、君ら４人で協力して近藤さんたちにご馳走を振舞ってあげて。とうさんは今日はどうしても抜けれない仕事があるから会社に行ってくるし。近藤さんたちがいらっしゃるまでには帰れると思うし、あとはよろしくな。困ったことがあれば、とうさんか、かあさんの携帯に電話して相談してや。とうさんも携帯くらいは出れると思うし」

といって淳子の空港に向かう車に便乗して出て行った。現在、１３時、近藤さんたちが田中家に到着するのは１８時くらいの予定だ。

残された４人は３０分ほど相談して本日のお品書きを決めた。メインをすき焼きとちらし寿司にすることになった。次は、材料の買出しだ。

秋子「クルマあんの、春子姉さんと夏子姉さんやから、二人で適当に買ってきて。その間、私と冬子は家に食材があるもんを使ってオードブルとかの準備をしておくし」

春子「わかったわ。私、いい店を知っているし、ワインと日本酒を買うてくる。途中に○○屋もあるから、肉も買ってくるわ。夏子は市場行って肉以外のすき焼きの材料とチラシの具を買ってきて、すき焼きとチラシに何入れるかは夏子に任せるし」

夏子「わかった」

春子と夏子を見送って、秋子と冬子は相談を始めた。

冬子「おつまみ、どないしよう？」

秋子「冷蔵庫を見て、材料をみてから考えよ、でももう少し、時間ある。お母さんにきけば、近藤さんところの息子さんイケメンいうし、私、美容院に行ってきたいんやけど。１時間半ほどで帰ってくるから」

冬子「わかった」

＜近藤一家到着３時間前＞

春子がワインと日本酒を買って帰ってきた。

春子「夏子はまだ帰ってへんな。あれ、秋子は」

冬子「美容院行った。もうすぐ、帰ってくると思うけど」

春子「しょうがないなあ、じゃあ、冬ちゃん、オードブルを作ろうか」

冬子「うん、生ハムはきればいいし、あと、根菜のサラダとか、酢の物が作れると思うけど」

春子「ご主人、アメリカ人でしょ。少し、変わったものも付け合せよう。お漬物のスティックとかどうかしら。秋子に電話して、美容院の帰りにしきでお漬物を適当に買ってきてって伝えといて」

冬子「それから、夏子姉さんから電話があって、思いっきり９号線が思いっきり渋滞しているそうや。思ったより時間かかるかもしれへん、言うてた」

春子「そうか、ほな、秋子も遅うなるかもしれへんな。できるだけのことしとこ」
といって、寿司飯の準備とか、すき焼きの割り下の準備とかを始めた。

＜近藤一家到着１時間前＞
夏子が戻ってきた。春子が早速、何を買ってきたかを訊ねる。

夏子「すき焼きは、焼き豆腐、葱、春菊、椎茸、しらたき。チラシは海鮮チラシやな。鯛のいいのがあったんで、これがメイン、イカ、甘エビ、いくら、たこ、かにくらいやな。あとは、タマゴときゅうり、がり」

春子「わかった。ええな。じゃあ、夏子、チラシつくってくれるか。もう、ご飯は炊けるし。私はすき焼きの準備する。冬子は手が足らないところの加勢と、配膳準備な。」

＜近藤一家到着３０分間前＞
最後に、秋子が一番帰宅が遅くなったが、やっと全員が揃った。とりあえず、春子と冬子は酢の物を作って待っていた。春子が秋子に何を買ってきたか訊いた。

秋子「きゅうり、なす、すぐき、しば漬、千枚漬、ゆず大根、たくあん、それから旬のもんで若筍といったところや。それから、おふのいいのがあったんで、買うてきた。すき焼きいれよ」

春子「わかった。それを一口にきって、串に刺して、桶に氷をひいてそこにたてよ。これが一番急ぐ出し」

夏子「まだ、あかん。おけ、寿司飯を作るのに使うし」

春子「ああ、そうか。じゃあ、秋子、別のもん探して」

夏子「秋子、若筍は醤油漬けやろ。少し、多めにあったら、チラシの具にするし、こっちにまわして」

秋子「わかったわ」

こうして、何とか１８時には、淳子と一緒にきた近藤一家を無事、迎えることができたのだった。

◆ＰＭＯのマネジメント機能とは

前回のコラムでは、プロジェクトマネジメントの組織成熟度を上げていくにはＰＭＯというのは単にプロジェクトマネジメントの支援をするだけではだめだという指摘をした。今回はもう少し、この問題に踏み込んでみたい。

ＰＭＯというのも組織である。従って、マネジメントされなくては、望まれるパフォーマンスを出すことは難しい。ＰＭＯに組織のマネジメントとして求められることには、以下のようなものがある。最低限でも

（１）ＰＭＯ活動の成果の定義と測定
（２）ＰＭＯの戦略と役割の見直し
（３）ＰＭＯの機能の評価と見直し
（４）ＰＭＯスタッフのローテーションと育成

の４つについてはマネジメントとして実施される必要がある。少しずつ説明していこう。

◆ＰＭＯ活動の成果の定義と測定

ＰＭＯを設立する、あるいは、運営するに当たって最も頭を悩ますのがこの問題である。ＰＭＯ関係のセミナーを開催すると必ずといってよいくらい出てくる質問でもある。

このような問題が出てくる背景には、（２）と関係があるが、ＰＭＯを設立する際に、戦略がなく、それゆえに、役割が熟考されていないケースが多いことがあげられる。プロジェクトマネジメントを標準化するために作る、プロジェクトマネジメントがうまく行っていないので作る、メンタルケアがうまく行っていないので作るという風に、当面の問題解決でＰＭＯを作っているケースが少なくない。

成果の定義の基本的な考え方は２つある。ひとつはあくまでもＰＭＯは間接部門であり、直接部門、つまり、プロジェクトの成功の度合いによってＰＭＯの評価に変えるというものである。もうひとつは、ＰＭＯも完結した活動組織であり、ＰＭＯ活動そのものの成果を評価するという考え方である。

◆評価指標の例

前者の場合によく使われる指標は
　・プロジェクトの成功率（ＱＣＤＳの目標達成率）の改善
　・プロジェクトのトラブルによる損失額の減少
である。また、もう少し、大きく見ると
　・プロジェクトのＲＯＩの改善
といった指標で見ることもある。このような考え方はＰＭＯの活動はあくまでも支援活動であり、必要な支援を適切に、タイムリーに提供することにより、プロジェクトの成功確率、あるいはＰＯＩが上がるという考え方に基づいている。

これに対して後者のような捉え方をする際によく使われる指標は
　・標準ツールやテンプレートの利用プロジェクト数（率）
　・プロジェクトマネジメントノウハウやテンプレートの登録件数
　・成熟度アセスメント結果の向上
　・プロジェクトマネジャーの数や認定制度があればシニアＰＭの割合の増加
　・プロジェクトマネジメント教育の受講者数や、受講時間
　・プロジェクトマネジャーの平均コンピテンシー
　・計画レビューによる不適合計画率
　・メンタリング活用者数
などがある。また、これらの指標よりは少し、上のレベルの指標として、プロジェクト監査を行い、

　・監査結果における不適合指摘項目数

などを指標として評価することもある。

◆どちらが適切か

どちらがより適切な評価かという問題があるが、これについてはその組織のプロジェクトマネジメントの成熟度によると思われる。成熟度が低い組織では、プロジェクトの成功は偶発的なものであったり、プロジェクトマネジャーの属人的な能力に依存する場合が多い。言い換えると、プロジェクトを開始する時点でほとんど成功するという予測はつかない。このような組織においては、まずは、後者のような評価をすべきだろう。前者のようにプロジェクトの結果を評価してみても、それがＰＭＯの姿を的確に表現している評価だとは考えにくい。ＰＭＯの立上げの段階では、このような評価が望ましい。
逆にプロジェクトマネジメントが成熟してくれば、結果を問うべきである。ＰＭＯの仕事は、定義しにくいものがある。例えば、ステークホルダ間の調整を行い、プロジェクトマネジメントの円滑な運営を図るというような仕事は、機能としては定義しにくく、結局、ＰＭＯの総合的な活動だと考えることが自然である。すると、そのような活動によってステークホルダがどう変化したかということより、プロジェクトの成功に結びついたかという方が実態を適切に反映すると考えられるためである。

（２）以降については次回説明する。

プロジェクトマネジメントではなぜ、たくさんのドキュメントを書かなくてはならないのか？

今日のテーマはこれ。

日本型経営という表現がある。「従業員は家族、同僚は親兄弟、取引先は親戚」という経営スタイルである。家族だから、従業員同士であれば、言わずとも、何を考えているか、だいたい、分かる。ちょっと分からなくてもひと言二言会話をすれば通じ合える。苦労しなくてもコミュニケーションができる。このような経営スタイルは非常に生産性が高い。日本人がドキュメントを書くのは、まとめである。相談して何かを決める。決まったことをドキュメントに書く。だから、ドキュメントも簡潔であるし、場合によってはなくても済む。

これに対して米国の経営スタイルのステレオタイプは「従業員は他人、同僚も他人」という経営スタイルである。これだとまず、自分の意志や考えを明確に表明しないと何も始まらない。つまり、ドキュメントを書かないことには話しは始まらない。ドキュメントを書き、プレゼン資料を作る。そこからコミュニケーションが始まる。ある意味で非常に生産性が低い。

ここまではどちらでもよい。問題はではなく、「家族の中に他人が入ってきたらどうするか」ということにある。つまり、「価値観が違う」、「ビジネスの習慣が違う」といった人が入ってきた場合だ。日本人の典型的な対処は２つある。ひとつはお客さんとして扱う。自分の家に来たからには面子にかけて不自由はさせない。しかし、絶対に自分たちの実態は見せないし、交わらない。もうひとつある。自分たちの習慣に従えという態度にでる。この場合は、従わない限り、組織の論理を持ち出して排除にかかる。

こうなってくると、極めて生産性が悪い。従って日本人のマネジャーは生産性を盾にとって、気心の知れない人を組織やプロジェクトに入れないということを平気でやる。もっとたちが悪いマネジャーは（このような態度による人事評価の×を恐れ）、笑顔で受け入れ、排除にかかる。

「一生懸命溶け込んでもらおうとしたのですが、なかなか、頑固な社員で」（表向き）

「君もわがチームの一員になったのだから、メンバー全員に何をしているかを聞いて回って仕事を覚えろ。さもなくはここに君のできる仕事はない」（実態）

となる。

ドキュメントを書くかどうかはどうでもいい。しかし、ドキュメントを書かなければ、間違いなくこのようになる。こうなると大問題だ。

成果主義全盛のご時勢である。事業部長がプロジェクトに乗り込んできて、「次の商品がダメなら事象部長の席はなくなる。あのデザイナーを使え」などといってもおかしくない。
あるいは、収益の確保に困った部長がプロジェクトに口を出し、「人件費の安いベトナム人のプログラマを使え」と言い出してもおかしくない。

一家の主のプロマネとしては、自分の意志に関係なく、他人を押し込まれるような状況なのだ。この状況で、上のような対応をしていたのではもたない。

何とか、他人と一緒に仕事をする術を覚える必要がある。これがプロジェクトマネジメントである。

◆ＰＭＯの機能はプロジェクト支援機能だけではない

ＰＭＯの機能というと

「社内標準やテンプレートを作ってプロジェクトマネジメントの支援をする」、「トラブルに陥ったプロジェクトをレスキューする」、「プロジェクトマネジメント計画書のレビューや計画策定の指導をする」

などさまざまなものがある。ただ、ＰＭＯがこれらの機能を実行しようとしてみても、なかなか、うまく行かないのが現実である。なぜだろうか？

今回のコラムは少し視点を変えてこの問題を考えてみたい。

◆使われるまでに必要なプロセス

ＰＭＯがどんな標準やツール、仕組みを作ろうと、それらは使われてはじめて意味がある。これは誰もが認めることだろう。そして、使われるためには、まず、

（１）知られること

が必要だ。そして、

（２）プロジェクトマネジャーが使おうという気になる

ことが必要である。

そして、使われるようになったときには

（３）使っているものがメンテナンスされ、活用がきちんとサポートされる

ことが不可欠である。

プロジェクトマネジメントの仕組みや道具をいろいろと作って入れてみたが、なぜか、プロジェクトマネジャーが使ってくれないという悩みを抱えるＰＭＯのほとんどは、（２）が抜けている。もちろん、存在すら知らないというケースは珍しいが、どのような場面で使えるか知らないとか、それを使うことによって何が期待できるか知らないとかいったケースは珍しくない。

◆使おうという気にならない

このようなことが起っている一因は皮肉なことにプロジェクトマネジメントブームである。ブームにのっかり、組織としてプロジェクトマネジメントの導入を決定した。このため、ＰＭＯの提供する支援に乗っかることが義務化されている会社が多い。

それで、形はできているのだが、いまひとつ、実態が伴わず、実りが少ないと悩む企業が多いのだ。これらの企業に共通している問題は（２）である。「ベテランのＰＭには自分のやり方がある」、「仕組みが重いので、忙しいＰＭにすべてやってもらうのは難しい部分がある」といった悩みを持っている企業が多い。

ここで問題なのは、ＰＭＯサイドの「いいもの、便利なものを作れば使ってくれる」という錯覚である。ちょっと脱線するが、皆さんの会社のビジネスを考えてみて欲しい。（開発者の考える）いいものを作ることから使ってもらうまでには、最低でも

・その存在を知ってもらう
・その価値を認めてもらう
・導入してもらう
・使い方を理解してもらう

という４つの壁がある。

プロジェクトマネジメントの支援を見ていると、意外にも価値を知ってもらう前で止まっているケースが多い。ここをクリアしても、導入してもらうまでに時間がかかっているケースが多い。

この２つがクリアできてはじめて、使い方を支援するという段階にたどり着く。ここは結構できている（というか、やとうしている）企業が多い。

◆マーケティングしよう！

これらはひと言でいうと、マーケティング活動である。日本ではＰＭＯの書籍そのものが少ないが、米国のＰＭＯの本を見ると、必ず、ＰＭＯの活動の中にマーケティング活動が入っている。

日本企業のＰＭＯの人と議論をすると、サービス（標準の内容とか、ツールとか）の議論に終始することが多い。これではおそらく、いくらプロジェクトマネジメントに関する知恵を絞っても今の状況が改善される期待は薄い。

実は、日本企業のＰＭＯがきちんとやっていない活動はマーケティングだけではない。そもそも、マネジメント活動というのがろくにできていない。これについては次回。

弊社で１０日間の長丁場のプロジェクトマネジャー養成研修を持っているが、その中の１セッションに自分の知らない専門分野を統合しなくてはならないプロジェクトをどのようにマネジメントしていくかを議論するセッションがある。

例えば、こういう状況設定をする。

産業ロボット（特殊作業用）の開発プロジェクト。ＳＩ企業から転職をしてきたあなたは、前職でのプロジェクトマネジメント業務の実績が買われて、いきなり、プロジェクトマネジャーに任命される。このプロジェクトは、機械、電子、光学、制御、ソフトウエアなどの技術の統合しなくては成果物は生まれない。

技術者してはもちろん、プロジェクトマネジャーとしてもソフトウエア開発プロジェクトの経験しかなく、機械、電子、制御、光学などの知識はない。ソフトウエア部分については一通りに知識があるものの、組み込みソフトウエアの開発プロジェクトの経験はない。さて、このような状況でプロジェクトマネジャーとしてどのように振舞うか？

多くの人が、自分に知識がないのだから、メンバーに任せるという。あるいは、重要な判断の局面では、自分の人脈の中で信頼できる専門家に聞くという（実は、上の設定はこの人脈の可能性を潰した設定にしてあるのだが、、、）。

問題解決に対する答えをしては、これで正しいと思う。メンバーをマネジメントすることにより、プロジェクトの問題を解決し、プロジェクトのゴールに近づいていく。しかし、これがすべてではない。というよりも、ある意味、これは当たり前のことに過ぎない。もっと大切なことがある。

この状況の最大の問題は、自分がどう技術的問題に対処するかではない。メンバーも同じ状況にある。機械、電子、光学など自分の専門のことしか分からない。その状況で、専門家の間のコミュニケーションができない限り、技術の統合はできない。

ここに注意が行かないプロマネはある思考の落とし穴に陥っている。

　自分はメンバーを（業務的・技術的に）指導する立場にある
　　→　今回は自分の専門を越えた範囲なのでどうするか

という自分のことしか考えないという落とし穴だ。

専門性がないプロジェクトマネジャーが抱える本質的な問題は、それぞれの分野での問題解決にどのように寄与するかではなく、コミュニケーションできないメンバーが自分の専門性をプロジェクトに活かせる方法を作ってやることである。

また、ＩＴのように比較的同質性の高いプロジェクトでも、このコミュニケーションに寄与することは、各人、ひいてはチームのパフォーマンスを挙げる上で極めて重要である。

コミュニケーション能力が高いプロジェクトマネジャーでも、メンバーとのコミュニケーションにしか関心を示さない人がいる。プロジェクトマネジャーの行うべきコミュニケーションは、メンバーとメンバーを結びつけるコミュニケーションであり、チームのコミュニケーションである。そして、これがチームをマネジメントするということである。

このようなコミュニケーションを実行できるためには

　ヒューマンスキルとしてはファシリテーション
　マネジメントスキルとしてはコミュニケーションマネジメント

といったスキルが必要である。

冒頭の問題の答え。コミュニケーションの活性化である。こういうと、必ず出てくる反論。メンバーの専門スキルが低い場合にはどうするのか？これについては、また、別の機会に！