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

このメッセージはこのブログの１００エントリーになる。小さな達成を喜びたい。

さて、今回は以前書いた「隠すというスタイル」の記事に対して、「匿名」で、「公開不可」の批判的な意見をいただいた。コメント機能があるので、こういうやり方にはあまり対応したくないのだが、頂いたメッセージを読んでいるうちに僕の表現の稚拙さで誤解を与えているような気がしてきた。

そこで、今回は特別に、ブログ上でそれにお答えしたい。

「隠す」というスタイル
https://mat.lekumo.biz/ppf/2007/04/post_378a.html

プロジェクトマネジメントとして行うべき活動には３つの種類がある。

１番目は、プロジェクト成果（目標）の管理。レスポンシビリティを果たすための活動だ。

２番目はプロジェクトの目的・目標・使命の達成のために必要な問題解決。これには多種多様な要素が含まれている。この部分が狭い意味での「マネジメント」である。

３番目は、プロジェクトスポンサーをはじめとするプロジェクト外部のステークホルダへの説明責任を果たすための管理。これは成果の管理と連動するアカウンタビリティを果たすための活動だ。

レスポンシビリティとアカウンタビリティの区別がつかない方はこちら。

戦略ノート１３１回　アカウンタビリティとレスポンシビリティ
　http://pmos.jp/honpo/note/note131.htm

さて、ＰＭＯが標準を作るときに、あるいは、プロジェクトマネジャーがプロジェクトマネジメントのやり方を構築していくときに、真っ先にすべきことはこの整理だ。しかし、プロジェクトマネジャー本人も、ＰＭＯもこのような整理をしないままで、決まったやり方をしろとか、時間がないだとか言っているケースが多い。この整理をしない限り、どこまですべきかという議論は神学論争に過ぎない。

プロジェクトマネージャー養成マガジンの発刊以来、プロジェクトマネジメントのスタイルを持つべきだということをいい続けてきたが、これは１番目や２番目のやり方についてであり、３番目についてではない。

好川が「隠すというスタイル」を肯定しているように受け止めた方もいらっしゃるようだが、好川自身はこんなスタイルは論外だと思っている。

なぜなら、アカウンタビリティにかかわることであり、これに対してプロジェクトマネジャー自身のスタイルなどありえないと思うからだ。アカウンタビリティをどのように果たすかということは、プロジェクトマネジャーの問題ではなく、組織のプロジェクトマネジメントの問題であり、組織がプロジェクトマネジャーの任命の際に指定する類のものである。この点ははっきりしている。

もちろん、そのなかで、いかに効率的にアカウンタビリティを果たすかといった「マネジメント」の問題はある。これはスタイルだと思う。

このような前提の中で、現状を考えると云々というのが「隠すというスタイル」という記事でで書きたかったことである。

蟻の穴から崩れるという言葉がある。

コンサルタントのキャメル・ヤマモトさんの「鷲の人、龍の人、桜の人米中日のビジネス行動原理」という本を読んでいたら、非常に面白い指摘に出会った。

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

この本そのものの紹介はビジネス書の杜の記事を参考にして欲しいのだが、日本人、米国人、中国人の行動分法を分析し、その文法から、実際の価値観や行動を比較している本。

米国人は「スタンダードを自由に決めて守らせる」という行動文法を有しており、いろいろな行動をしている。日本人はソフトウェアも含めてモノを売り込むが、米国人は基準を売り込む。ヤマモトさんは、４０１ｋ、ＳＯＸ法などの法律系、ムーディーズの格付け、マクドナルド、スターバックスなどのマニュアルシステムや、ライフスタイル、はては、ＭＢＡまですべてこの類だという。まあ、そういわれると、ＰＭＢＯＫとか、ＰＭＰなどまさにこれだろう。

面白いのはここから。日本人が基準を作ると、「官僚的」になって、ものごとにやたらと時間がかかるようになるが、米国人は「誰にでも分かる標準的な基準がたくさんあるおかげで、ものごとが生産的に進む」と指摘している。その典型が、転職。標準化されているので、他の企業にいってもその日から仕事ができるようになる。これは、まさにプロジェクトマネジメントでよく言われていること。

ちなみに、日本人の官僚的という話は、日本に限った話ではなく、組織論では、マックス・ウェーバーが発見した官僚制のメリットに対して、マートンが「逆機能（行き過ぎて、デメリットになること）」という表現でデメリットとして指摘していることだ。ただし、神戸大学の加護野忠男先生によると、日本型組織は特に逆機能が激しいそうだ。

ヤマモトさんは、米国人にこのようなことができる理由を「ナンセンスなルールでも、決めれば守るし、破れば処罰する」からだといっている。さらに、これに対して、日本人は、決めてもそこまでやらないし、そもそも、紙に書いてある基準より、書いてない暗黙の基準を重視しているから、できないと指摘している。

ステレオタイプな分析すぎるとは思うが、的外れではない。

このような指摘をすると、すぐに、多様性の話が出てくる。そして、次に日本人の「誇り」である「トヨタ」の話になる。日本人は、トヨタのように、向上心が強く、ものごとを改善していくＤＮＡを持っている。

しかし、よく考えて欲しいのは、トヨタの文化というか、やっていることは、「ルールを決める、決めたらやる、そして、やってみて合理的でなければ変える」というサイクルになっていることだ。ヤマモトさんが指摘している米国流の次を行っているのだ。

日本の多くの組織は、前半をはしょっている。「そんなことは決めなくてもできる」とか「言われなくても分かる」とか、「自分には自分のやり方がある」とかいう。それは素晴らしいことだと思う。

しかし、素晴らしいアイディアがあってもトヨタのように根付かない理由もここにある。ヤマモトさんは「場の空気を読んで行動するのが得意」といっている。こう言えば聞こえはいいが、悪くいえば、「場当たり的」なのだ。

まず、愚直にルールを守るところから始めないと、プロジェクトマネジメントもこれ以上の成果はでないだろう。とくに、ＩＴ系の企業ではこれを痛感する。

現に、米国系企業でプロジェクトマネジメントで大きな成果をあげている組織は徹底的にレビューをしている。例えば、計画レビューを通らなければ、プロジェクトには着手させないというくらい厳しい組織も少なくない。日本人的に言えば、お客さんから急かさせているのに、場の空気が読めない、現場を知らないＰＭＯだということになる。

日本はどちらを選ぶのだろうか？少なくとも、場の空気を重視する人は、トヨタを日本経営の代表だとは思うべきではないだろう。

プロジェクトマネジメントの中で品質マネジメントというのが分かりにくいという人が意外なくらい多い。同時に、特にソフトウエアプロジェクトの従事者では品質マネジメントに対する誤解があるように思う。

品質マネジメントの前提は、「ライフサイクルの全期間を通じて完璧なものはできない」ということである。

ハードウエアもソフトウエアも、出荷時に完璧なものを作ること自体、困難である。

ハードウエアだと、仮に出荷時に完璧なものができたとしても、経年変化があり、その性能が保たれる保証はない。

ソフトウエアの場合には、もう少し複雑である。「モノには経年変化があるが、ソフトウエアは未来永劫、同じように動く」という話があるからだ。ソフトウエアの内容にもよるが、一般的に情報システムを使い始めて年月が経過するとデータ量が増え、状況が変わってくる。これは一種の経年変化だ。しかし、これはある程度テストでシミュレーションをしているので、未来永劫動くと考えたくなる。しかし、シミュレーションで完全にすべてのケースを押さえることはできない。例えば、限界値だけで大丈夫だとするのは不十分なことが多い。データの増え方によって性能への影響が変わってくることが多く、組み合わせの世界がでてしまう。すると、やはり、完璧なものはできないことになる。

さて、このような状況で品質計画とは何か、品質マネジメントとは何かということになる。エンジニアは二言目には品質は絶対であるという。ここで言っている絶対とは、完璧ということではない。（契約的な）瑕疵がないということに過ぎない。ここまではスコープであるので当たり前の話だ。

ただし、そうであっても、特に納期とのトレードオフは一考の余地がある。エンジニアの人に言わせれば品質が第一であるが、これはプロジェクトの目標による。プロジェクトの目標が競合より早く商品を世に出すことであれば、品質を落としてでも、早く市場に出すという考え方はありうる。

こういうと、「そんなことをしたら、顧客に品質が悪いというイメージを持たれて、結局、競争に負けてしまう」という人が多い。これが正しいのは、日本とドイツくらいだ。それ以外の先進国でそんな品質意識を持っている国はない。

むしろ、上の出荷時には完璧ではないという点も背景に問題になるのは、出荷後の品質マネジメントである。

ある会社でこの話をしていたら、薬の議論になった。薬のように人の命に関わるものはまずいのではないかという話だ。これも違う。薬の場合、認可が契約仕様だと思うが、これは人体には安全であることを保証しているに過ぎず、効能書きどおりの効果があるかどうかは確率の世界だし、ある程度の確率で効果があれば認可される。薬の場合の販売後の品質は、薬剤師による如何に症状に適応する薬を飲むかのコンサルティングで行われる。

最近、事故が目立つ飛行機もそうだ。飛行安全性に影響を与えるところは網羅的なテストがされるが、それ以外の部分は、はやり、納期と開発費との見合いの話になる。不良が出てきた場合には、如何に迅速に対応し、部品を交換し、如何に稼動時間を増やすかで行われる。クルマや原子力プラントだって同じ発想だ。

この品質の議論は、ブランドの議論である。日本にメジャーなブランドが少ないのは、結局、上市後の品質マネジメントがきちんとできている企業が少ないからだ。それどころか、中国との戦いだとかいってコスト競争に巻き込まれ、逆行している。松下電器が顕著な例だ。あんなにナショナルブランドの構築に貢献したナショナルショップを捨てた。

話がそれたが、プロジェクトにおける品質マネジメントというのは、成果物のデリバリー時に絶対的な品質とそうではない品質をきちんと整理し、そうではない部分については、フォローの体制を構築することだ。

ポイントは「期待に沿うこと」である。そして、期待に沿うというのは、予め、持っているものに適合することではない。期待を一緒に創り上げていくことである。

ここがきちんと整理できない限り、プロジェクトマネジメントは答えのない方程式を解くような仕事になる。

ＰＭＡＪの「プロジェクトマネジャーの成功要因」ＳＩＧ活動に参加していてあるメンバーから非常に考えさせらる話を聞いた。

　うまくやるために情報を隠す

と主張するプロマネの話である。このプロマネは計画に細かいことを書かない。当然、ＰＭＯによる計画書レビューでは指摘されることになる。そのときに、プロマネの言い分がこれだというのだ。

本来なら、この話は即座に否定すべきであろう。プロジェクトマネジメントはアカウンタビリティとレスポンシビリティに立脚するものだからだ。しかし、必ずしも否定できない理由が２つあるように思う。

一つ目は、「計画を作って組織全体でちゃんとプロジェクトマネジメントをしましょうね」という話は、理想像であって、エグゼクティブスポンサー、プロジェクトスポンサー、プロジェクトメンバー、ＰＭＯなどがきちんと対応できるという前提の話である。

残念なことだが、プロジェクトマネジャーの中には、スポンサーやＰＭＯとあまり詳細に情報共有をすると、検討はずれな介入をされて邪魔だと考える人がいてもおかしくないという組織の現実がある。もちろん、情報共有すれば支援をしてもらえる部分もあるので、最後はそろばん勘定ではあるが、「組織での情報共有がプロジェクトを円滑に進める」という命題が無条件に成り立つような状況ではない組織がほとんどだろう。

この話はあまり本質的ではない。組織のプロジェクトマネジメント成熟度が高まってくればいずれは解消する話だ。だが、もうひとつの話はもっと本質的な話である。それは、ステークホルダマネジメントとして、計画をあまりちゃんと作らない方がよいという議論である。この議論が顕著に出てくるのはＣＣＰＭ（ＴＯＣの考え方に基づくプロジェクトマネジメント）でポイントになっているサバである。

このサバの話もＣＣＰＭのように、プロジェクト、あるいはプログラムで共有し、全体最適になるように使えばよいというほど単純な議論ではないだろう。ステークホルダがいるということは、目標、あるいは、成功の認識が異なる可能性がある。言い換えれば、価値観が異なる可能性がある、ある意味で価値観が異なることが正常な状態であるともいえる。
その中で、落とし処を探して、そこにもっていくことがプロジェクトマネジメントのミッションであるが、そのためには何が必要か？「期待に沿う」ことである。

期待に沿うということは、自分たちがどう感じるかということではないし、ましてや、品質に対する誤解のように絶対的に正しいということではない。

重要なことは、プロジェクトの進行の中で、その期待を作りこんでいけるということなのだ。これに失敗すると、初期の約束ではダメということになるし、うまくいえば、ずいぶんと軽いものになるだろう。このようなことは現実に起っている。

そう考えると、初期に明確な計画を示さない、言い換えるとコミットメントをしないというやり方はステークホルダマネジメントのひとつのやり方であるといえなくはない。

これが言いか悪いかは、プロジェクトマネジメントの議論ではない。ＰＭＢＯＫ流のプロジェクトマネジメントは、米国流の株主に対するアカウンタビリティが高く、統制上、レスポンシビリティが高い経営スタイルを前提にしている。ここが崩れてしまえば、ＰＭＢＯＫ流プロジェクトマネジメントの妥当性はない。

しかし、企業の株主（ステークホルダ）に対する責任としてはアカウンタビリティとともに業績責任がある。実際にイギリスやフランス、ドイツの企業には、アカウンタビリティよりも、業績責任を重視する企業も少なくない（これは、米国と欧州先進国のダイバーシティの違いだと思われる）。

業績責任を重視するなら、最小限の情報しか経営に出さないプロジェクトマネジメントというのもアリだろう。

非常に深い問題である。

今年度の仕事も一段落した。昔ほどではないが、新年度の仕事が立ち上がるまでのこの時期は貴重な充電期になる。

評論家の立花隆氏がよくＩＯ比という言葉をよく使う。インプット（Ｉ）とアウトプット（Ｏ）の比で、ＩＯ比が高ければ高いほど、情報がつまったいい仕事と評価することができるという話。立花氏が評論活動をする際に品質保証のために保っているＩＯ比は１００：１だという。

比のとり方はいろいろだと思うが、１００：１というと、例えば、１００冊の本を読んで１冊の本を書く。１０００時間の取材をして、１０分間の講演をする。こんな感じ。凄い密度である。

ＩＯ比は、知識労働のバランスシートといってもよいだろう。

１０年くらい前に立花氏の著作でＩＯ比の話を読んでそれ以来、ＩＯ比というのを結構気にしている。コンサルをやっている限り、せめて３０：１くらいのＩＯ比は保ちたいと思っている。３０：１を切ると、危険水域だと思う。

３０：１のイメージだが、例えば、

　１時間の話をするのに、最低３０時間の調査や取材をする
　１時間のコンサルをするのに、最低３０時間の類似経験をする

など。コンサルのインプットは、たぶん、経験と情報だと思う。できれば、経験２０、情報１０くらいのＩＯ比を保ちたいと思っている。

気をつけているのは、バランスだ。経験０、情報３０というのは論外だが、逆に、経験３０、情報０になってしまうと３０：１のＩＯ比でも別の意味で危険水域に入ると思っている。サスティナブルではなくなる。サスティナブルであるためには、何よりも、経験と情報のバランスが大切だと思っている。

ただし、経験というのは曲者で、仕事すべてが経験になるわけではない。十分の一もあればいいところではないかと思う。すると、３０時間の経験をしようと思えば、３００時間くらいの仕事をしなくてはならない。これは結構なものだ。

ちなみに、セミナーのようなパッケージものをつくる場合には、ＩＯ比をあげるようにしている。５０：１くらいを目標にしている。例えば、７時間のセミナーを作る際には、３５０時間の調査、経験をベースにするように心がけている。

さて、マネジャー。日本の平均的なマネジャーのＩＯ比というのはどのくらいだろうか？まず、目立つのは１：１、あるいは、せいぜい、２：１くらいのＩＯ比でやっている人が多いことだ。マネジャーやシニアマネジャーになってくると、仕事をしても、ほとんどアウトプットだ（それでなくては給料分の仕事はできない）。従って、仕事はほとんど経験（インプット）にならない。そこで、１は情報を中心にほそぼそという感じになる。どこかで断片的な話を聞いてきたら、そのまま試してみるの繰り返しっていう感じか？

ただし、これでいいかというと要注意。大企業だと問題が顕在化しないが、中小企業だとこのタイプの社長がやっている企業はまず成長しない。大企業でもこのようなマネジャーは確実に組織を蝕む。

ここで、プロジェクトマネジャーについて考えてみよう。ＩＯ比はどのくらいでありたいか？専門職であることを考えると、５：１とか、可能なら１０：１のＩＯ比は保ちたい。あなたのＩＯ比はどのくらいだろうか？一度、計算してみてほしい。

ちなみに、プロジェクトマネジャーにとって、インプットになる経験（プロジェクト）は以下のようなものである。

組織にとって新しい課題解決となるプロジェクト
火消しの仕事
大規模化、クライアントの多様化したプロジェクト
見本となる人との出会いの中でやるプロジェクト
同じ価値感、異なる価値観の人とやるプロジェクト
失敗プロジェクト
プロジェクトマネージャーの交代が起ったプロジェクト
メンバーの業績に問題のあるプロジェクト

以前、メルマガで書いたことがあるが、プロジェクトマネジメントにおける責任には、アカウンタビリティとレスポンシビリティがある。

第１３１回　アカウンタビリティとレスポンシビリティ
http://www.pmos.jp/honpo/note/note131.htm

問題は、どこで責任を明確にするかだ。

例えば、リーダーが自分のチームのメンバーの設計作業の成果物をきちんとレビューしていなかった。そのため、その設計を受けた後段の作業が少し混乱してしまった。ミーティングでは責任追及が始まった。メンバーが悪いだとか、リーダーが悪いだとか。

結局、「組織だからリーダー」がきちんとチェックすべきだという結論になった。

この例で本当に悪いのは誰か？

プロジェクトマネジャーである。事前にリーダーやメンバーの責任を明確にしていない。最低でも、マネジャー　－　リーダー　という体制であれば、リーダーのマネジメントＲＡＭだけでも明確にしておく必要があるのにそれを怠った。ここに問題がある。

プロジェクトでは責任を明確にしなくてはならない。しかし、問題が発生したときに犯人探しをしても問題解決にはならないという。犯人探しをしている時間があれば、その時間で問題の収拾にかかった方が賢明である。そういう教訓である。

どこに間違いがあるかというと、事後に責任を明確にしようとしていることだ。プロジェクトマネジメントで責任をはっきりしなくてはならないのは、事前の責任である。事前の責任をあいまいにしておいて（というか、何かあったらみんなで協力してことに当たろうと誓っておいて）、何か起ったら責任追及をする。

熱さに懲りて膾を吹くではないが、責任追及をしていると、雰囲気が悪くなるので、コトが起きても責任を追求しない。こうなると最悪だ。

ＰＭＢＯＫにプロアクティブという概念がある。ＰＭＩ流プロジェクトマネジメントの根幹をなす概念である。プロジェクトマネジメントの根幹を成すといってもよいかもしれない。

アカウンタビリティについてはステークホルダマネジメント、レスポンシビリティについてはその名のとおり、ＲＡＭといった優れた責任定義のツールがある。このようなツールを使って、必ず、計画段階で責任を明確にしておく。これがプロジェクトマネジメントの本質である。

ちなみに、事後の責任は「連帯責任」が正しい。明らかにあるメンバーのミスでも連帯責任であるし、プロジェクトマネジャーのミスもメンバーとの連帯責任である。事前の責任の明確化の必要性と、事後の連帯責任という認識があって初めて、チームマネジメントというのが必要になってくる

先日、リカバリーについて述べたが、もうひとつ、リカバリーに関連してはっきりさせておきたいことがある。

プロジェクトと計画というのを分けて考える必要があることだ。リカバリーという言葉は、

　・プロジェクトのリカバリー
　・計画のリカバリー

という両方の意味で使われるが、この２つは全然意味が違う。前者は目標変更であり、後者は計画変更である。

実は、この区分が必要なのはリカバリーだけではなく、リスクである。リスクにはプロジェクトリスクと計画リスクがある。プロジェクトリスクはプロジェクトのゴールに影響を与えるリスクであり、計画リスクは計画の実行に影響を与えるリスクである。

例えば、技術リスクを考えてみよう。製品の構成技術が実現できないかもしれないというリスクはプロジェクトリスクである。これに対して、設計を効率化する技術に問題が生じるかもしれないというリスクは計画リスクである。

ＰＭＢＯＫでいえばプロジェクトリスクが存在している場合には、そのリスクは回避しないとプロジェクトを開始することはできない。プロジェクトリスクの多くは、プロジェクトに責任はなく、プロジェクトスポンサーが解決すべきリスクが多い。ちなみに、よく、「リスクをとる」という言い方をするが、これはプロジェクトリスクをとることを意味する場合が多い。リスクはどこまで行ってもリスクであり、リスクが起らないことにかけるわけだ。このような場合、リスクモニタリングをいくらしても仕方ない。この手のリスクが運悪く発生した場合には、プロジェクトリカバリーが必要になる。

これに対して、計画リスクは、可能性が大きい、あるいは、計画に対する影響が大きければ、計画の見直しという形で着手前に対応するが、それ以外の場合には、軽減措置をとった上で受容することが多い。しっかりとモニタリングすれば、マネジメントで解決できる範囲にあるからだ。これがリスクマネジメントであり、発生した場合には計画のリカバリーを行うことになる。

実際のプロジェクトを見ていると、プロジェクトリスクはかなり慎重に検討しているが、計画リスクはあまり考えていないケースが多い。計画そのものがそんなにクリティカルではないのでこれで済んでいるが、はやり、ここを何とかし、脂肪のない計画を作りたいものである。

それはそうとして、このプロジェクトと計画の区別がきちんとできることが、大局観の第一歩であることをよく認識しておきたいものだ。

先日、ＰＭＯリーダー養成講座の中のリカバリーマネジメントのセミナーを行った。このセミナーは、かれこれ、５回くらいやっているのだが、初めて満席になった。

PMstyleが提案しているリカバリーマネジメントは、「安定化」と「そのあとの計画変更」を明確に分けている。

安定化の話をするには、どのような場合にマネジメントが必要かということを整理しておく必要がある。プロジェクトのある時点で、ベースライン計画との差異があるという状態は、代表的には２つのケースがありうる。ひとつは、徐々に差異が大きくなっているケース。もうひとつはどこかでドンと差異が生じてしまって、それをそのまま引きずってしまっているケース。

例えば、スケジュールを考えてみてほしい。プロジェクト期間の３分の１が終わった時点でベースラインと１０％の差が出てきたとしよう。前者であれば、結構、大変な状況である。ほっておくと、おそらく、１５％、２０％とだんだん、差が大きくなってくると考えるのが自然である。このようなクリープ的状態では原因すら分からないことが多い。あるいは複合原因であることが多い。

これに対して、後者である場合、例えば、初期のリソース調達の問題で、着手が１０％遅れた。そして、それがそのまま残っているような場合だ。この場合はそんなに心配するような状況ではない。

この区別をせずに計画変更をしようとするとどうなるか。前者の場合は、計画変更をしてもまず、うまく行かない。スケジュールが遅れているからといって、要員の追加投入をして失敗するようなケースはほとんどこれ。

例えば、このケースの一因に必ずといってよいくらいあるのはコミュニケーションや人間関係の悪さである。そこに、追加要員を投入したらどうなるか。言うまでもないだろう。

これに対して、後者では、適切な時期に、予定通り納期を達成するための手を打てばよい。この場合、コストに対する自由度が出てくる。状態として問題であることは問題なのだが、その中でも回復コストを最適化する余地があるのだ。

このように考えると、まず、最初にすべきことは、プロジェクトが安定か、不安定化を判断することだ。安定な場合には、問題があってもその問題を解消する方法を考えていけばよい。不安定な場合には安定化が必要になる。

ところがプロジェクトマネジャー側の問題というのがあって、状況をよいように解釈したがるのだ。プロジェクトが不安定な状況で、例えば、これから３ヶ月の間にリカバリーしますといってみても信用できるはずはないのだが、そういうことを言う。「ひとつ上のプロマネ。」はなぜそうなったかは別にして、プロジェクトが安定か、不安定かの判断をしっかりとできるようになる必要がある。

どうするかって？セミナーにお越しください！（笑）

プロジェクトリカバリーマネジメント

http://www.pmstyle.biz/smn/recovery.htm

３月８日にプロジェクトプロの峯本さんをお招きして、第２回のPMstyleスペシャルセミナーを実施した。今回のテーマ「内部統制とプロジェクトマネジメント」は、あまり、食いつきのよいテーマではなかったが、それでも、３０名近くの方にご参加頂いた。お越しいただいた方、本当にありがとうございました。

食いつきの悪かった理由で、何人もから指摘されたのは、「内部統制プロジェクト」の話、あるいは、内部統制プロジェクトのマネジメントの話だと思ったというもの。ある知人が言った言葉が印象に残った。「プロジェクトマネジメントと内部統制」って「セーラー服と機関銃」みたいな印象を受けるテーマだとか。。。むう

だれもプロジェクトマネジメントで内部統制ができるとは思っていない。でも、、、

これは今後の反省点になった。確かに内部統制プロジェクトでもプロジェクトマネジメントは重要だが、内部統制としてのプロジェクトマネジメントはその数十倍重要なテーマだろう。

それはそれとして、峯本さんの話は、今まで僕が聞いた話の中ではもっともプロジェクトマネジメントの話に具体的に言及した話で、主催者としてだけではなく、一受講者としても満足なセミナーだった。

今のブームともいえるような内部統制への関心の高まりの原因になっているのは、いうまでもなく、来年の春から施行される日本版のＳＯＸ法である 。なぜ、ＳＯＸ法という財務会計のシステムの健全性を規制する法律がこんなに関心を集めているかというと、実施基準（評価対象）の中に
　（１）財務報告に関する業務プロセス
　（２）事業目的に大きくかかわる勘定科目に至る業務プロセス
というものに並んで、
　（３）質的に重要な業務プロセス
という一項目があるためである。つまり、いくら財務関連の業務プロセスがきちんとしていても、それ以外の業務プロセスがきちんとしていない限り、問題になるからだ。

先日、ついに、日本での実施基準が明確になった。全般的な印象としては、米国の実施基準と比べて（３）が重視されている印象がある。これは日本人の考え方や、これまでの仕事のスタイルを考えてみると、非常に現実的だし、ある意味で、競争力の源泉になっていくことが予想されるので、評価できる。

中でも注目されるのが、非定型業務が（３）の中でも重視されていることである。非定型業務とはいうまでもなくプロジェクト業務である。言い換えると、Ｊ－ＳＯＸ法が施行されると、プロジェクトマネジメントをきちんとやらないとまずいという状況が発生したわけだ。

いよいよ、日本のプロジェクトマネジメントも正念場を迎える。今までのように、形を作っておけばよいといった状況からの一段の飛躍が必要になる。このテーマは、今後、PMstyleの重要課題として扱っていきたいと思うので、ひとつ上のプロマネ。を目指す方は、ぜひ、押さえておいてほしい！

ＰＭＯマガジンにプロジェクトマネジャーの権限についての記事を書いていて、ちょっと迷ったこと。

それは顧客に直接対応することは権限か、義務か？という点。ベンダーに対応することは明らかに権限のように思うが、顧客に対してはどうかといわれると、権限だと思っている人はほとんどいないし、実際に権限化していないようにも見える。

プロジェクトマネジャーの権限というのは多くの人が言うが、そもそも、義務と権限というのは何かという議論もある。プロジェクトマネジャーの権限とは、プロジェクトを成功させる上でプロジェクトマネジャーに意思決定をさせるべきものである。義務とは組織のガバナンスを維持するために行う仕事である。この話を組織ガバナンス（業務ガバナンス）の議論がごちゃまぜになっているので、話がややこしくなっている。

例えば、調達の決裁を考えてみよう。大雑把にいえば、調達内容に関する意思決定と調達方法に関する意思決定がある。一概には言えないが、調達方法によってプロジェクトの成功に大きな影響があるケースは珍しい。ところが、調達内容の意思決定は成果物に大きな影響があるし、成果物そのものだといえるケースも少なくない。

このような場合、調達内容の決定に関する権限委譲はするが、調達方法に関する権限委譲はしないというのが妥当な線だろう。ところが、このような整理をせずに、調達に関する権限委譲をするかどうかを議論するので話がややこしくなる。

さて、では、顧客に直接対応することは権限か、義務か。僕は権限だと結論したのですが、みなさんはどちらだと思いますか？

お客様がいない場合には、仮想顧客になるステークホルダで考えてみてください。