プロジェクトの「補助線」

サラリーマンのプロジェクトマネジメント

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

失敗はなくならない

本ブログは移転しました。こちらをご覧ください。

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

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

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

三つ目は

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

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

一つ目は

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

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

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

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

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

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

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

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

　自分たちは失敗はしない

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

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

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

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

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

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

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

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

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

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

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

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

【補助線】プロジェクトマネジメントというギミック

本ブログは移転しました。こちらをご覧ください。

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

　コアマネジメントスキル

である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【補助線】「こと・もの」分析でスコープマネジメント

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【補助線】「計画する」とはどういう行動か

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

【補助線】コミュニケーションはマネジメントの礎

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なぜ、日本には女性ＰＭが少ないのか

本ブログは移転しました。こちらをご覧ください。

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

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

不思議だ。

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

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

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

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

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

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

多様性をいかす組織

http://people.weblogs.jp/books/2005/10/post_0d0f.html

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

プロジェクトマネジャーの足らない理由は？

本ブログは移転しました。こちらをご覧ください。

プロジェクトマネジャーが足らないといっている組織は多い。

足らない意味はいろいろである

・キャリア的にプロジェクトマネジャーにできる人の数が足らない

・組織として任せるに足るプロジェクトマネジャーが足らない

・顧客から認められるプロジェクトマネジャーが足らない（特にＳＩ）

プロジェクトマネジャーってどのように選んでいるんだろう？

よいエンジニアがよいプロジェクトマネジャーになるとは限らない。

しかし、「実績」に注目すれば、エンジニアとして実績の上げられなかった人は、やはり、プロジェクトマネジャーとしてもダメという烙印を押されることも事実だ。

ここの矛盾を整理しないと、プロジェクトマネジャー不足の問題は解消しないだろうな。。。

ＰＭがうまく行けば問題は解決する！？

本ブログは移転しました。こちらをご覧ください。

ＳＩビジネスをめぐるエンジニアの劣悪な業務状況は、失敗プロジェクトで発生している。

それゆえに、プロジェクトマネジメントがうまく機能し、プロジェクトが成功させることが問題解決の方法である。

この仮説は本当に正しいのだろうか？

行動はもう十分

本ブログは移転しました。こちらをご覧ください。

なんだかんだといって、３～４年前に較べると、プロジェクトマネジャーは行動するようになってきたと思う。

ＰＭ養成マガジンは、ひたすら、行動すること、行動する能力を高めることに焦点を当てて活動をしてきた。

このような状況の中で、ある大手企業の人材開発マネジャーと話をしていて、プロジェクトマネジャーの育成には何が必要なのだろうか？と改めて考える機会があった。

もっと行動が必要なのか、あるいは、行動は十分で省察することが必要なのか？

別の言い方をすれば、行動する能力を高めるべきなのか、既存の行動について省察する能力を高めるべきなのだろうか？

上の人材開発マネジャーと話をしている中で感じたのは、組織の目的とマネジャーの育成が混乱しているのではないかということだった。

組織の目的は常に行動をすることである。これは間違いない。

しかし、今、プロジェクトマネジャー育成の目的は「行動の質を高めること」に移りつつあるのだと思う。

みんな十分に行動をしているのだ。しかし、必ずしも十分に結果がでない。空回りしてしまう。

この問題意識が芽生えたのは２年くらい前である。それ以来、ずっとＰＭ養成マガジンとしてどういうスタンスで行こうかと迷っている。

少なくとも、社内標準があってそれなりに従っているとか、ＰＭＰの資格をとって自分なりにシステマティックな方法で取り組んでいるといった人は、もう十分に行動をしていると考えてよい。問題は行動の質だ。しかし、そこで、立ち止まっている人が非常に多い。

しかし、ＰＭ養成マガジンの読者にはそうではなく、まだまだ、行動する能力を身につける必要のある人も多い。この辺が悩ましいところ。ＰＭ養成マガジンもブログ化もさることながら、読者を再定義しなおす時期に来ているのかもしれない。

この悩みはしばらく続きそう。