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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まず、一冊の本を紹介しよう

ＭＢＡが会社を滅ぼす
https://mat.lekumo.biz/books/2006/07/__3d22.html

オビにこうある。

業績不振の米国企業のエグゼクティブのＭＢＡ取得比率　９０％
業績好調の米国企業のエグゼクティブのＭＢＡ取得比率　５５％

この本の原題は、　MANAGERS NOT MBAs　だ。

この数字を出した出版社の意図はよく分かる。まさに本書のタイトル。しかし、米国企業では半数以上のエグゼクティブがＭＢＡの保有者であるという風にも読める。

それはさておき、この本、マイケル・ポーターと並ぶマネジメント論のグル　ヘンリー・ミンツバーグが書いただけあって、マネジャーを育成することの難しさを的確に指摘し、それに対する彼独自の大胆な提案をしている。いろいろと共感することはあるが、一つあげると、マネジャーの教育はマネジャー経験があり、問題意識を持つものを対象にしないと意味がないと述べている。プロジェクトマネジャーもそうだ。

日本の教育はここを間違えているのではないだろうか？まず、問題意識がない。「まず、プロジェクトを失敗してはならない」という問題意識すらも怪しい。これは、プロジェクトマネジメントのガバナンスを明確にせず、集団牽引体制を取っているのが原因。

組織的にプロジェクトマネジメントをするという発想は悪くないと思うが、組織でプロジェクトマネジメントを行うことと、ガバナンスを曖昧にしておくというのは別の次元の話。いくら集団マネジメントをしていても、プロジェクトに関わるメンバーの一人ひとりに自分の責任と義務を聞いて具体的な答えが出てこないようであれば、話にならない。

だから、プロジェクトマネジャーは自分自身に問題意識を持たない。組織の方に目が行くので、仕組みや制度の問題指摘や改善に終始する。

そんなはずはない。どう少なめに見ても、プロジェクトマネジメントの失敗原因の８０％はプロジェクトマネジャーの個人の資質にある。組織的な取り組みをした場合には、求められるリーダーシップの質が変わってくるので、この数字は９０％とかに上がってくるだろう。

だからこそ、経験を通して、自分の足らないところを見つけ、育成プログラムの助けを借りながら開発していくことが必要。

このサイクルを作ることが、ＰＭＩの掲げるプロフェッショナルプロジェクトマネジャーのエシックスであるし、ドラッカーをはじめ、多くのプロフェッショナル論で真っ先に語られていることである。

このサイクルができなければ、

　　「 PROJECT MANAGERS NOT PMPs　」

といわれるようになってもおかしくない。現に、事例としては少ないが、ＰＭＢＯＫの適用の不適切さが原因でプロジェクトそのものを失敗させて事例を２～３知っている。

日本企業の課題は、組織的なプロジェクトマネジメントと個人のプロフェッショナリズムの滋養を如何に両立させていくかだ。

これがミンツバーグのこの本、全体の問題指摘でもある。

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

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

不思議だ。

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

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

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

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

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

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

多様性をいかす組織

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

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

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

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

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

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

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

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

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

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

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

あまり、普段書かないことが、プロジェクト計画を作ること自体があまりにも無計画に行われているように思う。

プロジェクト計画書を作るというと何か書き物でもするイメージだが、実行可能な計画を作るためには、多くのアクティビティが絡む。少なくとも、計画書に書いてある内容は、稟議とかいったレベルではなくて、関係者が合意をしていなくては計画とはいえない。

関係者はメンバーに限らない。顧客もいれば、途中で作業的なかかわりが出てくるステークホルダなどである。

おそらく、このアクティビティはマイルストーンだけでコントロールしていくようなボリュームではないだろう。

計画を作って進めていく必要がある。少なくとも、コミュニケーション計画を作り、打ち合わせをしていくことは不可欠である。そのようなメタなマネジメントが必要ではないか？それがない限り、おそらく、計画に取れる時間は変わらず、相変わらず、間に合わせで作った計画に振り回されるプロジェクト運営は続くだろう。

前回のコラムでは監査の必要な理由と、プロジェクトマネジメントにおける監査の意義を説明した。

　https://mat.lekumo.biz/pmstyle/2006/07/post_5080.html

今回は、もう少し、プロジェクト監査について深く考えてみたい。その前に、少し、監査の基本を整理しておく。

◆監査の主体者

監査の定義は前回述べたが、監査には３つの主体がある。監査依頼者、被監査者、および、監査人（監査員）である。前回述べたように、監査の公正さはこの３つが独立し、健全な関係にあった初めて担保される。これらの言葉は以下のように定義される。

　監査依頼者：監査を要請する組織、または人
　被監査者：監査される組織（プロジェクト）
　監査人：監査を行う力量を持った人

◆誰が誰を監査するか

上のような主体があるときに、監査の種類は誰が誰を監査するかで、第一者監査（いわゆる内部監査）、第二者監査、第三者監査に分けることができる。

第一者監査は内部監査を呼ばれるもので、組織内で独立した監査チームが組織の他部門を監査するものである。ビジネスの中で実施されるプロジェクトの監査はほとんど内部監査になる。

第二者監査、第三者監査はいずれも独立した組織が他の独立した組織を監査する。

第二者の場合には発注者が同組織である。例えば、ＳＩのプロジェクトで委任契約先の活動を発注者が監査することがあるが、これは第二者監査である。

第三者監査は依頼者が外部の監査人に依頼して、組織内の被監査者の監査を行うケースである。このようなケースはビジネスの中では珍しいが、公的性格のプロジェクトではよくあるケースだ。

◆何を監査するのか

監査の内容は大雑把にいえば、２つある。

一つ得られたパフォーマンス（実績）が妥当なものかどうかをチェックする監査である。これが前回述べたコンプライアンスの監査であり、定められた基準に合致しているかどうかが問題にされる。当然、合致していない場合には、不適合となる。パフォーマンスでよく問題になるのは、はやり、変更をめぐるものである。

例えば、１５％のスケジュール遅れが発生したら、シニアマネジャーに分析と改善計画を報告するという変更管理ルールを決めていても、結局の正しく実行されないといったケースだ。これは、監査としては比較的分かりやすい。

もう一つはプロジェクトマネジメントシステムが妥当なものであり、それが適切に運営されているかどうかをチェックするものである。

これはシステム監査という呼び方をされることが多い。こちらは若干分かりにくい。システム監査の立場からは、上の問題は必ずしも不適合であるとは断定できない。そのような事実（データ・ログ）が発見された場合、その是正として、バリアンスの大きさに関係なく、１ヶ月に一度、シニアマネジャーに対して報告をするというコミュニケーション計画を追加したとし、この措置によるこの問題は繰り返し起こらないと判断されるので、不適合とは判断されない。逆に、これでもまだ、同じ問題が起こるだろうと判断されれば不適合だと判断される。

◆プロジェクトマネジメントにおける監査の必要性

というインプットの元で、もう一度、プロジェクトマネジメントの監査の必要性について考えてみる。

プロジェクトマネジメントの標準化の最も難しい点は、その標準を導入してもプロジェクトが成功するとは限らないことだ。プロジェクトマネジメントというのは本質的にそのような位置づけにある。プロジェクトの成功を保証するものではないが、やらないよりはやった方がよい。これが基本的な位置づけである。

このような位置づけからすると、パフォーマンス監査は必ずしも重要ではない。むしろ、システム監査を通じて標準の評価とマネジメントの改善をしていく。そこに最も重要な意味があるといえる。

前回のコラムでは監査の必要な理由と、プロジェクトマネジメントにおける監査の意義を説明した。今回は、もう少し、プロジェクト監査について深く考えてみたい。その前に、少し、言葉の整理をしておく。

◆監査の主体者

監査の定義は前回述べたが、監査には３つの主体がある。監査依頼者、被監査者、および、監査人（監査員）である。前回述べたように、監査の公正さはこの３つが独立し、健全な関係にあった初めて担保される。これらの言葉は以下のように定義される。

　監査依頼者：監査を要請する組織、または人
　被監査者：監査される組織（プロジェクト）
　監査人：監査を行う力量を持った人

◆誰が誰を監査するか

上のような主体があるときに、監査の種類は誰が誰を監査するかで、第一者監査（いわゆる内部監査）、第二者監査、第三者監査に分けることができる。

第一者監査は内部監査を呼ばれるもので、組織内で独立した監査チームが組織の他部門を監査するものである。ビジネスの中で実施されるプロジェクトの監査はほとんど内部監査になる。

第二者監査、第三者監査はいずれも独立した組織が他の独立した組織を監査する。第二者の場合には発注者が同組織である。例えば、ＳＩのプロジェクトで委任契約先の活動を発注者が監査することがあるが、これは第二者監査である。第三者監査は依頼者が外部の監査人に依頼して、組織内の被監査者の監査を行うケースである。このようなケースはビジネスの中では珍しいが、公的性格のプロジェクトではよくあるケースだ。

◆何を監査するのか

監査の内容は大雑把にいえば、２つある。

一つ得られたパフォーマンス（実績）が妥当なものかどうかをチェックする監査である。これが前回述べたコンプライアンスの監査であり、定められた基準に合致しているかどうかが問題にされる。当然、合致していない場合には、不適合となる。パフォーマンスでよく問題になるのは、はやり、変更をめぐるものである。例えば、１５％のスケジュール遅れが発生したら、シニアマネジャーに分析と改善計画を報告するという変更管理ルールを決めていても、結局の正しく実行されないといったケースだ。これは、監査としては比較的分かりやすい。

もう一つはプロジェクトマネジメントシステムが妥当なものであり、それが適切に運営されているかどうかをチェックするものである。これはシステム監査という呼び方をされることが多い。こちらは若干分かりにくい。システム監査の立場からは、上の問題は必ずしも不適合であるとは断定できない。そのような事実（データ・ログ）が発見された場合、その是正として、バリアンスの大きさに関係なく、１ヶ月に一度、シニアマネジャーに対して報告をするというコミュニケーション計画を追加したとし、この措置によるこの問題は繰り返し起こらないと判断されるので、不適合とは判断されない。逆に、これでもまだ、同じ問題が起こるだろうと判断されれば不適合だと判断される。

◆プロジェクトマネジメントにおける監査の必要性

というインプットの元で、もう一度、プロジェクトマネジメントの監査の必要性について考えてみる。

プロジェクトマネジメントの標準化の最も難しい点は、その標準を導入してもプロジェクトが成功するとは限らないことだ。プロジェクトマネジメントというのは本質的にそのような位置づけにある。プロジェクトの成功を保証するものではないが、やらないよりはやった方がよい。これが基本的な位置づけである。

このような位置づけからすると、パフォーマンス監査は必ずしも重要ではない。むしろ、システム監査を通じて標準の評価とマネジメントの改善をしていく。そこに最も重要な意味があるといえる。

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

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

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

僕は、３０台の頃、京都でソフトウエアエンジニアリングの研究をしている研究所で仕事をしていたことがある。このときに、ソフトウエアエンジニアリング環境の開発プロジェクトで一緒に仕事をした在京の中堅ソフトウエア会社の知人ができた。

彼はその成果を活用して独立して、生産性を売りにしたソフトウエア開発会社を作った。僕は頼まれて顧問（アドバイザー）に就任した。

最初の５年くらいは順調だった。社員も毎年、１～３名ずつだが増えて、５年目には３億円くらいの売り上げができる企業になった。基本的に外注はせずに、エンジニア１０名ほどでこの売り上げを記録していた。いわゆる人月計算でいくと、１人年間３０００万円なので、月２５０万円である。今と較べれば、ＳＥサービスの単価は１．５～２倍の時代なのだが、それでも結構な数字である。

もちろん、顧客の理解があってのことだが、そんなにはったりの営業をする男ではなく、正味、生産性が高かったのだ。ただ、ソフトウエア生産技術の研究開発を自らがリードし、その半端ではない費用を使っており、そんなに利益率は高くなかった（僕の報酬もその枠から出ていた）。

６年目くらいからしばらく、踊り場に差し掛かった。そして、８年目を迎えたときに、改めて、１０年目に向けた事業規模拡大のコンサルティングの依頼を受けた。彼の計画は研究開発費を人件費に回し、大幅に人を増やし、売り上げを１０億に持ていくことだった。

彼とはクライアントというよりも友人に近かったので、かなり、真剣に議論し、結果として依頼を断り、顧問も辞任した。

その後、２年くらいの間に４０名以上の人を採用し、１０年目には総勢で５０名近くなった。外注も積極的に活用し、売り上げは１０億が見えるところまで行った。コンサルを断ったことで、多少疎遠になっていたが、結構、羽振りがよく、とてもよい場所にオフィスを構え、高級外車を乗り回しているといううわさを聞いた。

この会社が今、どうなっているかはあえて触れない。彼とのつきあいは復活している。

今週の東洋経済でＳＥの業務環境の悪化の問題を経営的視点から取り扱っている。富士通だの、日本電気だのといった大きな企業は問題の本質が見えにくいが、結局、この友人と同じ構図があるだけではないかと思う。

同じ号で、トヨタの品質危機の特集をやっているのはなかなか心憎い編集だが、そのトヨタのワールドクラスの品質の生みの親である大野耐一氏の言葉。

　　　「やりやすい」を動機にするな