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

◆今年はプロジェクトマネジメントの仕組みを撤廃します

年明け早々、ある中堅機械メーカのＨ社長からメールが届いた。人とおりの近況報告の後に、こう書かれていた。

=====
今年はプロジェクトマネジメントの仕組みを撤廃することを決心しました。好川さんも、責任があるんだから手伝ってくださいよ。
=====

この企業は弊社のというより、好川の個人事務所（技術士）のクライアントで、８年くらい前に産業用機械の開発プロセスにプロジェクトマネジメントの仕組みを導入するお手伝いをした企業である。

年賀メールにこんなことを書いてきたのは、おそらく、半年くらい前に１冊の本を紹介したところに始まるのではないかと思う。その本とは、米国のコロンビア大学ビジネススクールの教授が技術ジャーナリストと一緒に書いた

エリック・エイブラハムソン、デイヴィッド・フリードマン「だらしない人ほどうまくいく」、文藝春秋社（2007）

である。

もっとも、この本を紹介したのは常々、この社長がこの本に書いてあるようなことを言っていたからなのだが、、、

◆きっちりがいいなど、誰が決めたのだろう？

この本は非常に面白い指摘をしている。

それは、人間はきっちりしなくてはならないと思いこんでいるが、ビジネス（パフォーマンス）という視点で考えたときに、本当に正しいのかという問題提起だ。むしろ、だらしない方がよい場合もあるのではないかと言っている。日本でも、だらしないのは敵のように嫌われるが、なぜ、嫌われるのか？

この問題に対して、

・病的なだらしなさ（片付けられない症候群）は議論の対象外
・たとえば、眼科医のようにだらしないのは論外という仕事もある

という前提を置いた上で、「だらしな系」と「きっちり系」という対立軸を設定して、だらしないことの効用を分析している。

分析内容については、この記事の最後につけておくが、この本も、この議論も結構考えさせられるものがある。おそらく、Ｈ社長の会社でもかなりの部分が当たっていたのだと思う。

歴史的に見ても、この種の価値観は為政者の都合のよいように作られるものだ。だらしないよりきっちりしている方がよいなどと誰が決めたのか？

身近なところでも、家庭で整理整頓してあたりまえだというのはたとえば、母親が片付ける手間が省けるので好都合だ。組織で計画的に物事を進めなさいというのは管理する手間が省けるという管理者にとって好都合だ。

これが都合ではなく、経済合理性があると言おうとすれば、エイブラハムソン先生らが言うように、片付けるのにどれだけのコストがかかって、それによってそのコスト以上の生産性の向上がみられる必要がある。

たとえば、プロジェクトマネジャーが計画を作って仕事をすることに対して、そんなことはやってられないと抵抗する背後には理屈がある。ただしいかもしれないし、情緒的な問題を経済合理性を使って言っているだけかもしれない。

◆何も考えずにキッチリがよいというのは思考停止

ただ、いずれにしても、どんな場合でもキッチリが良いのだというのは思考停止以外の何物でもないだろう。

この思考停止が単に整理整頓や計画のコストだけの話であればあまり大した問題ではないかもしれない。しかし、きっちりすることによって、創造性や柔軟性が排除され、機会損失が起こるようであれば、それこそ、きっちりと一度考えてみる必要がある問題だ。

だらしな系のプロジェクトマネジメントなんていうのもあるのではないかと思う。たとえば、ライトブレーンプロジェクトマネジメントやアジャイルプロジェクトマネジメントはその代表例ではないかと思う。

＜だらしな系の特徴＞
・素早く、劇的に、多様に、より少ない労力で状況に適応し、変化することができる
・異質なものを簡単に内側に取りこむことができる
・環境や情報や変化となじみ、そこから有益な影響を受けられる
・さまざまな要素に触れ、変化を促し、問題を顕在化させ、新たな解決策を導き出してくれる
・比較的少ない労力で目標を達成することができる。労力の一部をアウトソーシングすることができる
・大きく異なる要素でも内に組み込むことができるため、攻撃や妨害や模倣に対する抵抗力がある

＜きっちり系の特徴＞
・需要の変化や予期せぬ出来事、新たな情報に対して融通がきかず、対応が遅れがちである
・内に含めるものの量や種類を制限する。有益なものや、不可欠なものも排除してしまうことがある
・外部からの影響を遮断して、決して相容れることがない
・未知の存在や不測の事態を嫌い、それが現れると、即座に排除しようとする
・システムを維持するために常に大きな労力が必要になる。その労力はすべて自分で背負いこまなければならない
・強さと弱さを併せ持ち、たやすく破壊されたり、失敗をおかしたり、混乱したり、模倣されたりする

◆コーエン＆ブラッドフォードモデル

今日、コーエン＆ブラッドフォードの「Influnence without Autohrity」を日本に紹介され、ビジネスの展開をされている高嶋成豪さん、高嶋薫さんにお会いした。２時間弱のディスカッションだったが、有益な時間を過ごすことができた。

アラン・コーエン、デビッド・ブラッドフォード（高嶋薫、高嶋成豪訳）「影響力の法則―現代組織を生き抜くバイブル」、税務経理協会（2007）
https://mat.lekumo.biz/books/2007/12/post_df63.html

コーエン＆ブラッドフォードが提唱している影響力の法則は

法則１：味方になると考える
法則２：目標を明確にする
法則３：相手の世界を理解する
法則４：カレンシーを見つける
法則５：関係に配慮する
法則６：目的を見失わない

の６つを順に回していくモデルだが、今日はひたすら法則１に話題が集中した。実は、この本が出てから、何度か、コーエン＆ブラッドフォードのモデルをセミナーや講演で紹介したことがあるが、やはりこの部分に反応する人が多い。

◆敵になると思うから敵になる

多くの人は、ステークホルダに対して、敵だという先入観を持って接する。そうすると、自分たちが望んでいるように動いてもらうことはほぼ絶望的になる。セミナーでうなずいている人はたぶんそのことを実感している人だと思う。

なぜ、そんなにネガティブにものごとを考えるかということが問題だ。答えは一つ。

失敗したくないからである。プロジェクトを失敗させないためにプロジェクトマネジメントをやりだした組織は、ステークホルダをリスク要因だと考える。そして、言葉は悪いが、「足を引っ張られないためにはどうすればよいか」をひたすら考えるのだ。

心情的にはよく分かるのだが、このような発想パターンはジレンマだと思う。どんなプロジェクトでもステークホルダとの信頼関係を構築でき、ステークホルダの協力が得られれば失敗確率は劇的に少なくなるだろう。失敗したくなければ、これが正道だ。

ところが、失敗したくなければないほど相手を信頼できるハードルは高くなる。すると相手が中立的でも敵に見える。人間同士、付き合い方によって味方にもなれば、敵にもなる。敵だと見なされれば、そのプロジェクトに対して中立的な立場だった人が敵になるのは当然のことだ。結果として敵を増やすことになり、失敗の原因を作ることになる。

このジレンマを解消する答えはどこにあるのだろうか？

ここで重要な考え方はプラスサム（WinWin）だ。ゼロサムであれば、敵でも味方でもないステークホルダは敵だというのは間違いではない。しかし、プラスサムを目指すとすれば間違いである。

◆失敗の回避はゼロサム、プラスサムにするのがプロジェクトマネジメント

ここでよく考えてほしいのは失敗を回避するというのはゼロサムにすぎないということだ。

プラスサムにするというのはどういうことか。失敗を回避するのではなく、すべてのステークホルダが満足する結果を出すということだ。つまり、ストレッチされた目標を達成することだ。

プロジェクトであるので多少の差はあるにしろ、計画段階では目標に対して合意はできているはずだ。ところが、ゼロサムの発想で作られた目標のほとんどは不安定なバランスである。みんながぎりぎりの譲歩をし、三方一両損で、なんとか合意しているケースが多い。そのため、ちょっと計画からずれると瞬く間にバランスが崩れて、利害対立が起こる。

このような状況を回避するには、当初の合意の方法を変えるしかない。ゼロサムの三方一両損ではだめなのだ。目標を上げることによってプラスサムにするしかない。

たとえば、ＩＴ業界ではプロジェクトの失敗率が上がったというのが定説になっている。それはそうかもしれないが、顧客、プライム、ベンダーの範囲でプラスサムになっている気配はない。二次受け、三次受け、派遣契約、挙句の果てはオフショア、あくまでもゼロサムでなんとかしようと考えている。サルティナブルではないなあ。。。

◆仮説の共有はできていますか？

プロジェクトを進めていくに当たっては仮説（仮定）の存在を無視できないことは常識になってきている。ＰＭＢＯＫでは仮説を前提条件と呼んでいる。

仮説にはいろいろなレベルのものがあるが、たとえば、どんなプロジェクトマネジャーがプロジェクトでも設定しているものに「みんながプロジェクトを成功させたいと思っている」という仮説がある。ところがこの仮説がきちんとプロジェクト活動（プロジェクトチーム、ステークホルダ）の中で共有されているケースはまれである。

そんな馬鹿なと思う人は、次の問について考えてみてほしい。

あなた（プロジェクトマネジャー）はプロジェクトの進め方のすべてに対して行われる組織内ステークホルダのアドバイスはすべてプロジェクトの成功のために行われていると思うか？

もし、思えば、「みんながプロジェクトを成功させたいと思っている」という仮説は共有されていると考えてよいが、思わなければ共有されていないことになる。

この問いに対する答えとして多いのは、「成功させたいと思っているという仮説は共有されているのだが、成功の定義が違うので、ちぐはぐになっている」というものだ。そこで、成功の定義を共有する、プロジェクトの目的を共有するということになる。

◆プロジェクト活動の行動は仮説に基づく

こうやって文章として書いたものを読んでもらうとわかると思うが、実はこれは、問題解決策になっていない。成功の定義が共有されているという話と、「プロジェクトを成功させたいと思っている」という仮説が共有されているという話は全然別の話だ。

成功の定義が何であれ、仮説が共有されていれば、それを前提にしてそのプロジェクトの成功のために自律的な行動をとるということになる。そこで、コラボレーションが生まれる。しかし、そんなことは極めて稀である。

共有されていなければ、ひとつひとつ確認する。確認できればまだいいのだが、上にあげたような仮説だと確認のしようがない。

少し、考えていただきたいと思い、少し複雑な例をあげたので、混乱したかもしれないが、言いたかったことは仮説の共有というのはかくも難しいものだということだ。にもかかわらず、プロジェクトの中で、プロジェクトマネジャーやメンバー、あるいはステークホルダはそれぞれの仮説に基づいて行動している。

たとえば、プロジェクトメンバーは「自分の状況を報告をすれば、自分の活動を他のメンバーが理解し、問題が解消される」という仮説を持って仕事をしているはずだ。もっと作業的なところでいえば、「計画時に構想した手法でやればうまくいく」という仮説を持っているはずだ。

◆仮説は共有できないと混乱の原因になる

ところがこのようなチームで持つべき仮説は、共有できないと意味がない。意味がないばかりか、混乱の元だ。

たとえば、上の報告に関する仮説をメンバーの誰かが持っていないとしよう。蟻の穴から崩壊していくように、この仮説は成り立たなくなる可能性が大だ。手法の仮説が共有できていないとすれば、勝手な手法の検討するメンバーが出てきて、全体が混乱に陥る可能性がある。

情報を共有するのはある意味で難しいことではない。会議体など、比較的形式的なコミュニケーションでほぼできる。しかし、仮説の共有は極めて難しい。

そして、不確実性の大きいプロジェクトでは仮説の共有がプロジェクトマネジメントの生命線になることが多い。そのためには、プロジェクト憲章のようなスタティックなドキュメントだけでは不十分である。「相互理解」という意味での本当のコミュニケーションを実行していくこと、そして、そのためのコミュニケーションマネジメントが不可欠である。

あけましておめでとうございます。本年もよろしくお願いいたします。

お正月なので、今年度のテーマを含めて、ちょっと、浮世離れした話をしてみたい。

昨年、「おもてなしの源流」という本が出版された。お正月に改めて読み直してみた。「ビジネス書の杜」ブログに感想を書いているので、また、興味がある人はみていただきたい。

「主客一体」がビジネスの基本

僕の尊敬する思想家・田坂広志先生がこの本に書かれた推薦文によると、日本の「おもてなし」というのは、禅思想を源流とし、「主客一体」「一期一会」の思想を根底に持ち、「主客分離」「関係構築」を前提とした欧米の「サービス」とは全く異質のものだという。この本は、旅館、茶道、花街、祭りなどの日本的な伝統の残る場のフィールド調査で、「主客一体」「一期一会」の思想がどのように実現されているかを丁寧に書き上げた一冊である。

ここで、大胆な提言。

すべてのプロジェクトマネジャーは「主客一体」「一期一会」という思想を持つべきではないだろうか？

プロジェクトマネジメントの中でもっとも重要な仕事の一つはプロジェクトオーナー（顧客）や、そのプロジェクトに利害関係を持つ人との「関係構築」だとされている。重要なことはこれは「主客分離」を前提にして行われていることだ。

その中で、さまざまな意思決定をゆがませている原因が「関係構築」だと言える。たとえば、ＷｉｎＷｉｎの関係の中で、主も客も、お互いに妥協の産物としか思えないような意思決定を行っている。

ビジネスとはそういうものだという考え方もあるだろう。また、主客分離はダイバーシティの原則から出てくるものだという考え方もあるだろう。

このような考えがあることを知りながら、あえて、この前提は本当に正しいといえるのであろうか？と問題提起したい。

まず、最初に考えるべきことはプロジェクトという枠組みは、「主客一体の場」としてあるのではないかということ。

そして、その場は「一期一会」を前提とした場ではないかということだ。

プロジェクトにおける一期一会とは、その機会を一生に一度限りの機会だと考え、「主」はもちろん、「客」も、お互いの出会いを大切にし、その機会を活かすために、プロジェクトに対して全力でコミットすることである。そう考えると、一期一会はプロジェクトが求めているもの、そのものだと言っても過言ではない。

つまりは、主客一体と一期一会はプロジェクトの基本精神であるといっても過言ではなかろう。

このようなおもてなしの根底にある考え方をプロジェクトマネジメントの中に取り込んでゆくと、多くの問題が片付くように思える。

今年のテーマにしてはいかがでしょうか？

今年最後のメッセージです。

みなさんはプロジェクトマネジャーとしての品格について考えてみたことがありますか？
なければ、ぜひ、お正月にでも考えてみてください。

たとえば、川北義則さんは著書「男の品格」の中で

　　　品格とは何か？　美学である。

と書いています。

よく、「昔と比べると最近のプロジェクトマネジャーは小さくなった」という言葉を耳にします。これに対して「経営環境も、プロジェクトの質も違う」という反論もよく耳にします。

僕は基本的には後者の言い分を支持するのですが、たったひとつプロジェクトマネジャーの質で違いがあるとすれば、美学が持つかどうかではないかと思います。

２０代でプロジェクトマネジャーを任されて、すでに自身の美学を持っている人もいます。一方で、４０代後半で１００人規模のプロジェクトを管理しているのに、美学の「美の字」も持ち合わせない人も少なくありません。

必ずしも後者ような人がうまくできていないわけではありません。

だからこそ、美学なのです。ある意味で、自己満足ですが、すべての仕事の最終ゴールは自己満足だともいえます。

これはとても大切なことです。自分が満足できない仕事で、お客さまが満足するなど、あり得ません。ただし、順番を間違えないでください。自己満足は最後にあるゴールです。これを最初のゴールや中間ゴールにしてしまうと大問題になります。

そして、最初のゴールや中間ゴールではなく、最終ゴールにするために必要なのが「美学」です。来年は美学を探す１年にしましょう。特に若いプロジェクトマネジャーの方は美学を持ってください。

こちらの記事でヒントになる本を紹介しています。

では、来年もよろしくお願いします。

◆「ハーバード流」プロジェクトマネジメントのポイント

最近、この本を読んでいて、プロジェクトマネジメントとして最低限することってなんだろうか？と考えてしまった。

その本とはこれ。

メアリー・グレース・ダフィー（大上 二三雄、松村 哲哉、上坂 伸一、エム・アイ・コンサルティンググループ株式会社訳）「プロジェクトは、なぜ円滑に進まないのか」、ファーストプレス（2007）この本では、プロジェクトをスムーズに進めるためのポイントとして

・必要なリソースを見きわめる
・目標をはっきりと定める
・途中で必要な修正を施す

という点にポイントを置いている。

◆よく言われるポイント

マネジメントとしてプロジェクトマネジメントをとらえれば当たり前のことだが、今、一般的に考えられているポイントと微妙に違う。いわゆるプロジェクトマネジメントの識者に尋ねると、たぶん、この３つの上の２つの代わりに、「ステークホルダとうまく話をつける」、「リスクを上手に管理する」の２項目が入り、

・ステークホルダとうまく話をつける
・リスクを上手に管理する
・途中で必要な修正を施す

の３つのポイントを上げる人が多いような気がする。組織文化の違いはあるが、おそらく、マネジメント「感」が違うのだと思う。というより、プロジェクト感が違うといった方がよいかもしれない。

◆プロジェクトに対する見方、捉え方

プロジェクトは組織から与えられた目標の達成だと考えていると、だいたい、こういう答えになるだろう。要するに目標達成の阻害要因を排除することと、目標が変わった場合の対処をうまくやることに尽きるということだ。

２００４年にダイヤモンド社から、

すぐに解決!プロジェクト―30分で読める!プロジェクト成功の秘訣がわかる!

という本が出版されている。ファーストシンキングシリーズと銘打って何冊か出ている中の一冊だ。この本では、

・プロジェクトの目的が何かを明確にさせる
・本当の責任者を見極める
・周囲の力を借りる

の３つにポイントを置いている。スコープを明確にすることも、リスクに対応することも明示的には入っていない。たとえば、周囲の力を借りることにより、リスクに対応している。

◆トム・ピータースのセクシープロジェクト

また、トム・ピータースの

「セクシープロジェクトで差をつけろ!」

でも、ポイントになっているのは、

・プロジェクトの目的を明確にする
・多くの人を味方にする
・走りながら考える

の３点である。やはり、プロジェクトやスコープマネジメントは明示的にははいってこない。

この問題は真剣に考えてみる必要がある。

みなさんにとって、３つのポイントを上げるとすればなんですか？

◆顧客はだれか

顧客との良好な関係を保つことは難しい。といよりも、対立的な関係になることが少なくなり。なぜだろう？

プロジェクトからみたときの顧客と言ってもいろいろなケースがある。典型的なものだけでも以下のようものがある。

まず、ＳＩプロジェクトのように顧客に直接商品を売って対価を得るという関係がある。この場合は、プロジェクトの顧客＝エンドユーザとなり、これがある意味でもっともわかりやすい。

多くの消費材商品のように市場があり、エンドユーザはいるが、その顧客へ届く経路に流通がある。この場合、プロジェクトにとっての（ステークホルダ）としての顧客は、顧客の声の代表ということになる。

生産材商品であれば、メーカが直接営業するケースも少なくない。この場合には、デリバリチャネルとしての流通はあるが、プロジェクトとしての実質的な顧客は自社内の営業部門のように、エンドユーザに影響力を持つ部門であることが多い。良いか悪いかはその営業部門の活動内容の問題なのでさてき、これも一種の社内顧客である。

社内の情報システム開発のようなプロジェクトだと、社内の利用部門が顧客になる。文字通り、社内顧客である。

◆エンドユーザとそれ以外という区分

これらを同じように扱うのは難しいかもしれないが、大きく分けてしまえば２つに分けることはできるだろう。エンドユーザとエンドユーザ以外である。

エンドユーザとそれが以外は何が違うかというと、「目先」の利益である。インターネットが普及してきて顧客と提供者の関係についての変化が盛んに言われるようになってきたが、モノにしろ、サービスにしろ、エンドユーザの手に届かないものは買えないという事実は変わらないし、すべてのものが宅急便で運べるわけではない。はやり、流通は強いし、今までの通り、流通までと、その先という区分は根強く残っている。

プロジェクトにとってみると、エンドユーザの満足を実現するのは、ＱＣＤとのコンフリクトがありので、苦労を伴うが、困難ではない。プロダクトスコープの問題である。

ところが、エンドユーザ以外を考えると、顧客として満足させることは非常に難しい部分がある。なぜか。

◆カレンシーを見つけるとうまくいく

ここで面白い概念をご紹介しよう。コーエン＆ブラッドフォードが「影響力の法則」というフレームワークの中で言っている概念で、カレンシーという概念である。カレンシーとは言葉としては通貨のことだが、通貨というはもの代わりに登場したものだ。つまり、相手からの何かを得たい場合には、対価が必要になる。エンドユーザの場合は、商取引であるので、文字通り、通貨がカレンシーになる。通貨を得るためにニーズに沿う商品を開発するわけだ。

流通であれば、まだ、通貨で行けるかもしれない。要するに仕切りを下げておけば何とかなるかもしれないが、多少、複雑である。ボリュームが出てくるからだ。つまり、１００円の利益が上がって、１００個売れそうなものと、１０個の利益があって１０００個売れそうなものはどちらがよいかという話になる。これはやや難しい。

顧客が社内の営業部門となると、カレンシーとして使える資源となると、ぱっと思いつかないだろう。ある営業マンはたくさん売れて自分の給料が上がることに価値を求めるかもしれないし、ある営業マンは顧客が喜ぶことに価値を見出すかもしれない。ある営業マンは営業部長が気にいるものであることに価値を見出すかもしれない。こんなことを考え出すときりがない。わけがわからない。

顧客との関係がうまくいくということは、このカレンシーをうまく見つけることができて、それをうまく提供できるということだ。

◆カレンシーは主観である

ここで重要なポイントは何がカレンシーになるかは価値観の問題であり、主観的な問題であることだ。流通の話で、１００円の利益が上がって、１００個売れそうなものと、１０個の利益があって１０００個売れそうなもののどちらを選ぶかはおそらく、組織としての主観（意志）の問題だ。つまり、戦略なり、ビジョンの問題である。営業部門の話になると、プロジェクトとの関係は営業部という組織よりは担当者との関係になり、ゆえに、営業担当者の主観の問題である。

さて、ＳＩ。上で分かりやすいといったことに違和感を感じた方もいらっしゃると思うが、結局のところ、同じ問題だ。違和感を感じた人は、組織かプロジェクトチームか個人かという見極めが難しいと思っている人だと思う。

実はこの問題は腹をくくって決めてしまうのがよい。たとえば、プロジェクトだと腹をくくれば、そのプロジェクトの意見を組織内に通していくことそのものがカレンシーになり、ステークホルダマネジメントになるからだ。

相手の組織の状況をみて、中途半端な態度をとるので、スコープ変更が起こるのだ。相手を徹底的に支援して、その見返りに、手戻りの防波堤になってもらう。たとえば、こんな関係を作っていくのだ。これが互恵関係である。

◆昔の日本企業の現場は本当に強かったのか？

「現場力」という言葉がある。正確な定義があるわけではないと思うが、「現場が強い」、「現場で会社が成り立っている」などの言霊のある言葉だ。

戦後の高度成長の中で、日本企業は一般的に現場力により成長してきたと認識されている。おそらくこれは、明確な戦略がない中で、現場が方向性を決め、それを次々に実行していくことにより、成長してきたことを指していると思われる。

この背景になるのが、「よいものを作れば売れる」という神話である。ここで、考えておかなくてはならないのは、高度成長期は本当に現場が強かったのかということだ。少なくともこの時代の日本人は勤勉だったし、工夫をする心にも富んでいた。これは間違いないと思う。その意味で現場が強いというのであれば、それは正しいだろう。この点については後でもう一度、触れたい。

◆戦略経営における現場力

その日本にも、戦略に基づく経営という考え方が取り入れられるようになってきたのは、おそらく９０年代の前半である。この時期は、バブルの崩壊とともも、右肩上がりの成長も停滞し、それまでのようにみんなが同じことをやっていたのでは、全員が立ち行かなくなるという危機感がでてきた時期だ。まず、立ち上がったのは製造業だ。現在、エクセレントカンパニーの地位を確立している企業は間違いなくこの時代に戦略的な経営に移行している。そして、やはり、「強い現場」、「現場力」が成功のキーワードになっている企業が多い。今のエクセレントカンパニーの戦略の３大成功要因は、情報技術、金融技術と現場力だろう。そして、日本の企業は現場力を競争優位源泉とする企業が多い。

では、戦略経営の中での現場力とはなんだろうか？戦略経営の中では、高度成長期のような現場の自由度はない。その中で、現場力が強いとはどういうことか。

現場力は、「あるべき姿」＝ビジョンに対して、策定された戦略を微調整しながら業務を進めていく能力である。あるいはこのために、現場で起こる問題（あるべき姿と現状のギャップ）を能動的に発見し、解決する力である。

◆リアルタイム経営のためにはプロジェクトの現場力が不可欠

戦略経営においては、戦略の精度を上げるためにだんだんモニタリングのスパンが短くなってくる。今は最低でも四半期で戦略を見直し、軌道修正をしている企業が多い。ただし、現実問題として考えると四半期というスパンが限界だろう。

そこで注目されているのが、プロジェクト経営とプロジェクトマネジメントなのだ。四半期より短いサイクルで戦略の修正をするためには、開発や販売などの業務をプロジェクト化し、現場としてのプロジェクトにその軌道修正の役割をゆだねるしかない。プロジェクトマネジメントの要素にはアカウンタビリティの確保があり、修正行動への介入は難しいとしてもモニタリングは可能であることも経営としては好都合である。現場の状況を見ながら、次のクオーターの戦略計画の微調整を行うことが可能になるからだ。

このように考えてみると、プロジェクトに要求されるのは、立ち上げ時の計画通りに行うことではない。自ら、プロジェクト環境を察知し、それに合わせてプロジェクトの計画を変えていくことである。この適応能力こそがプロジェクトマネジャーに求められる現場力である。

◆プロジェクトマネジャーに求められる現場力

では、現場力を持つためにプロジェクトマネジャーに求められるものは何か？以下の５つである。

特にプロジェクトマネジャーの方にはよく考えてみてほしいのだが、これはある程度の経営的意思決定を行う仕事なのだ。

つまり、プロジェクトにおいてはプロジェクトのメンバーまで戦略実行の一端を担っているという意識が必要であり、メンバーにそれを指導していくのはいうまでもなくプロジェクトマネジャーの仕事である。

◆なぜ、失敗すると、どんどん、はまるのか

先週末にフィギュアスケートのＮＨＫ杯のフリーをみていたら、ショートプログラムの上位選手が次々に失敗していた。失敗する様子を見ていると、失敗したものを立て直すのは難しいものだとつくづく感じる。

演技の最初の時期に失敗すると、そのあとのプランがきちんと実行できなくなってくる。理屈の上では、プラン通りに演技しないとどんどん状況が悪くなるというのは分かっているし、もう失敗するわけにいかないという気持ちが先立つのだろう。きっとあとの演技をより完璧にこなそうとする気持ちと、力が入るので事態がより悪くなる。

解説の荒川静香さんは盛んに「忘れて」とか「平静になって」とか言っているが、それが難しいのだろう。

多分に心理的な話だと思うが、この話はプロジェクトにおいても、そのまま、当てはまる。プロジェクトが深刻なトラブルに陥ったときに、冷静に進めていくというのは難しい。一般的な話でいえば、理由は組織の「眼」にある。組織がどう評価するかは別にして、多くのプロジェクトマネジャーは組織の「眼」を必要以上に意識する。上司だ。

◆はまるパターン

組織の眼を気にし始めたプロジェクトマネジャーがはまるパターンは２つある。一つは、何とかしないといけないとあせり、目先の状況がよく見えるような対応をすることだ。たとえば、要員を追加するといった策はこの典型であることが多い。

もう一つは上位組織にゆだねてしまう。つまり、上位組織の指示を受け入れることによって、その場をしのぐという行動に出る。その場をしのぐという言い方をしたのは、多くの場合、不適切な判断であっても受け入れてしまうことが多いからだ。本質的には上と同じ。とりあえず、受け入れればそれ以上評価が下がることはないという錯覚に陥るのだ。

◆あせりは伝染する

話は競馬に移る。地方競馬からのＪＲＡに転入してきて大活躍をしているベテラン安藤勝己騎手がＪＲＡのスター騎手である武豊騎手について「ジョッキーが心の中に勝ちたいと思うと、その思いが馬に伝わって、馬も力んでしまい、最後に効いてくる。彼はそれがたくさん勝てる理由だろう」と評価しているという記事をスポーツ雑誌で読んだ。

この心理もプロジェクトに当てはまる。プロジェクトマネジャーが焦ってなんとかしようと思ってしまうと、騎手と馬の関係のように口に出して何も言わなくてもチームに伝染する。チームメンバーが焦ってしまう。これによって、品質などのミスが出てくる。このパターンは多い。

◆いったん、断ち切り、プロジェクトを落ち着かせることが重要

著者はよくプロジェクトを失敗しないようにやるのではなく、成功させるように考えるべしと言っているが、トラブルの時に失敗しないようにすると逆効果であることが多い。スケートの例の如く、トータルで失敗しない（つじつまを合わせる）ためには、何とかして取り返さなくてはならないと思ってしまうのだ。トラブルが起こったら、まず、チームやステークホルダも含めて冷静になることを目指す必要がある。そのためには、まずはプロジェクトを落ち着かせることだ。これが安定化である。

ＰＭＢＯＫの立ち上げプロセスは、英語では「Initiation」である。イニシエーションは通過儀礼という意味が一般的である。通過儀礼とは、出生、成人、結婚、死などの人間が成長していく過程で、次なる段階の期間に新しい意味を付与する儀礼のことだ。

日本で一般的にイニシエーションという言葉が認知されたのは、オーム真理教が話題になったときだと思う。彼らはキリスト教徒同じく入信の儀式をイニシエーションと言っていた。オーム事件の後で、そのイメージの悪ささからか、イニシエーションに「洗脳」という言葉があてられるようになってきて、あまりよくないイメージがある。

しかし、宗教の中でもイニシエーションというのは重要な意味を持っている。キリスト教では、神と人間とを仲介し、神の恵みを人間に与える秘跡（あるいは、洗礼）と呼ばれる儀式があるが、これがイニシエーションである。

神戸大学の金井壽宏先生は、これに加えて、

　そこから始まる

という意味を持つと指摘し、新卒社員が入社時の「リアリティ・ショック」を乗り越えるには（イニシエーション）が必要だと述べている。

米国の産業組織心理学者D・フェルドマンは、

・「職場集団への加入儀礼（グループ・イニシエーション）」
・「職場の仕事上の課題面での加入儀礼（タスク・イニシエーション）」

という二つのイニシエーションがあると指摘している。これは、導入研修などのOff JTの話ではなく、配属先の職場になじむための二つの課題である。

また、慶応大学の榊原清則先生は、フェルドマンの説をさらに具体的にし、

会社に入ったときに，個人は組織に適応し，その組織文化を内面化しようとする。その際に個人は２種類のイニシエーションに直面する。第１は，新しい世界での仕事に慣れ，課題がうまくこなせるかどうかという「課題」イニシエーションである。第２は，その世界で出会う新しい人々と文化にうまく溶け込めるかどうかという「人・文化」イニシエーションである。これらのイニシエーションを通過することで，個人は組織に適応し社会化していく。

と指摘している。

このようにイニシエーションというのは極めて意味の深い言葉であり、儀式である。

これをＰＭＢＯＫの日本語版では「立ち上げ」という言葉で片付けている。これでは、プロジェクトを巡るメンバーの不適合や不全が起こっても全く不思議ではない。ＰＭＢＯＫの訳語の適切さをめぐってはいろいろな議論があるが、すべての訳語の中で、これが一番ひどいのではないかと僕は思っている。

スコープは訳をあきらめて、スコープのままで、プロジェクトマネジメントを行う組織の中では普通に使われるようになってきた。その例に学び、イニシエーションをカタカナ英語に変えてほしい。