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

前回のコラムでは、プロジェクトモニタリングという観点から、プロジェクトマネジメント活動やプロジェクト支援活動を整理してみた。コラムでは、できるだけ手法に入らないようにしているが、読者の方からプロジェクト監査のイメージがよく分からないので、教えて欲しいというメールを戴いたので、イメージを説明するために、少しだけ、具体的な内容に踏み込んでみよう。

◆プロジェクト監査の種類

まず、一口にプロジェクト監査といっても、目的やタイミングに応じていくつかの種類に分かれる。もちろん、目的が違うのでタイミングが違うという見方も見ることもできる。

プロジェクト監査を大きく分けると、プロジェクトマネジメントやプロジェクトの監査を一義的とするものと、周辺状況からこれらに対する分析を加えるものの２種類がある。前者はプライマリー監査、後者はセカンダリー監査などといわれることがある。

プライマリー監査には

・プロジェクトマネジメント監査（プロジェクトの任意のマネジメントプロセス）
・プロジェクトパフォーマンス監査（実行・統制プロセス）
・プレプロジェクト監査（計画プロセス）
・ポストプロジェクト監査（終結プロセス）
・プロジェクトマネジメントメソドロジーレビュー

などがある。（）内が一般的な実施タイミングである。プロジェクトマネジメントレビューは特にこの時期というのはないが、マネジメント手法の評価は結果に依存する部分が大きいことを考えると、終結プロセスで行うのが妥当だろう。

◆プロジェクトマネジメント監査の実際

まず、最初にイメージを掴んでもらうために、プロジェクトマネジメント監査についてPMstyleの内容の一部を例示する。

プロジェクトマネジメント監査のレビューの対象としては、

１．プロジェクトマネジメントの効果を生み出せるプロジェクト作業計画と支援計画
２．プロジェクト作業計画と支援計画策定の有効性
３．プロジェクト資源管理と作業成果の監視
４．ベンダー管理と作業成果の監視
５．顧客に対する契約上の義務の実行

などを設定している。これに対して、監査視点を設定しておき、その視点から監査を実施するという方法をとっている。例えば、２．の「プロジェクト作業計画と支援計画策定の有効性」という対象であれば、

（１）適用可能な計画に従ってプロジェクト作業が完遂しているか
（２）作業計画に対してプロジェクト実績のトラッキングが示されているか
（３）作業計画の変化の見極めと対応がタイムリーに行われているか
（４）計画変更に当たっては承認された手続きが使われているか

といった監査視点が設定されている。

◆監査視点のボリューム

ちなみに、PMstyleでは、

・プロジェクトマネジメント監査（７対象２２視点）
・プロジェクトパフォーマンス監査（５対象１９視点）
・プレプロジェクト監査（６対象２５視点）
・ポストプロジェクト監査（３対象１２視点）
・プロジェクトマネジメントメソドロジーレビュー（３対象１１視点）

が設定されている。

◆セカンダリー監査の種類

これ以外にセカンダリー監査がある。セカンダリー監査としてPMstyleが行っているものには

・顧客満足度監査
顧客が望む目的がどの程度達成されているかをレビューすることにより、顧客とのビジネスリレーションシップを検査

・プロジェクトリカバリー監査
プロジェクトマネジメント監査とプロジェクトパフォーマンス監査であるが、不適合度に監査焦点を置いた検査を行う

・プロジェクト支援計画監査
個々のプロジェクトに対して、事前に策定されたプロジェクト支援計画をレビューする

・プロジェクトリソース活用監査
リソース配置の充足度を、特定のタスクに対する配置実行のタイムリーさの観点を中心に検査する

・プロジェクトチームパフォーマンス監査
プロジェクトチームメンバーに対して、プロジェクト作業の担当と、技術的能力、専門能力の整合をレビューする

・ベンダー監査
ベンダーやコントラクターが適正なプロジェクトマネジメントを行っているかをレビューする。検査は、プロジェクトにおけるプロジェクトマネジメント監査と同じ視点で行う。

などがある。これらはいずれも、必要に応じて、ＰＭＯが中心になって行うことが現実的であるが、プロジェクト支援計画監査については、ＰＭＯ自身の問題になるのでＰＭＯが指揮をして、第３者の監査人を立てて行う方がよいだろう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

視える化とは問題を顕在化することだ（カルマン・若松義人社長）

【効用】
・ＰＭ体質改善
　　計画力アップ、実行力向上、問題解決能力向上、リスク管理力アップ、
・ＰＭ力向上
　　チームをまとめる力の向上、リスク対応力向上
・トラブル緩和
　　モチベーション向上

【成分表示】

◆視える化とはきれいに見せることではない
◆プロジェクトの状態の可視化にこだわると問題が見えなくなる
◆可視化すべきは問題
◆形骸化を引き起こさない可視化を考える
◆見やすい可視化が、見逃しを引き起こす。

このサプリを服用したい方はこちら。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プロジェクトのモニタリングというのは単純明快なようで、結構、深い話である。

◆進捗報告

モニタリング活動の種類でみれば、３種類ある。

もっとも単純明快なのは、スケジュール、コスト、品質、リソースなど、ベースラインの設定（定量化）ができるもので、これに対しては進捗というモニタリング指標がある。進捗に対するモニタリングは、通常、進捗報告として、ボトムアップ式に行われる（ただし、これにしても、ＥＶに代表される計測方法などの課題があるので、単純明快とはいえないかもしれない）。

これらは目標に対するプロジェクトの状態を評価であり、コアプロセスとして行われるマネジメントである。

これに対して、目標に対する状態のモニタリングではなく、マネジメントの状態を知りたいという目的のモニタリングがある。ＰＭＢＯＫでいえば、マネジメント計画に対する実行状況を知りたいという場合だ。

◆トラッキング

ひとつの例として、進捗に大きな影響を与えるリソースパフォーマンスを考えてみよう。プロジェクト作業計画を作る際に、ある生産性を基準にして作った。すると、この生産性を引き出すことがマネジメントの重要課題になるし、その方策はマネジメント計画書においてきちんと計画されている必要がある。

ところが、こちらはベースライン（プロジェクト目標）のような形で定量的にモニタリングしていくことは相当難しい。例えば、残業時間のような間接的に推定する指標を持ちこんで定量化することができないわけではないが、最終的には値を解釈して評価すべきものであり、その意味で、本質的に現象を直接観察して、モニタリングすべき性格のものだ。

このように現象を直接観察するタイプのモニタリングはトラッキングと呼ばれる。トラッキングには、チームのパフォーマンス、主要なコミュニケーション、課題管理などが上げられる。

トラッキングの中で多少、特殊な位置づけにあるのが、リスクである。リスクマネジメントではリスク事象をトラッキングする。これは計画通りに言っているかどうかをトラッキングしているわけではないが、プロジェクトで発生する事象をモニタリングしているという意味ではトラッキングである。

◆監査

このようなトラッキングに対して、トラッキング自体が難しい、あるいは、個別事象をトラッキングしているとマネジメントコストが爆発的にかかるようなものがある。

例えば、コミュニケーション計画の中で、プロジェクトメンバーは毎日、当日の作業を正確にＰＭＳにインプットすると決めたとしよう。インプットしているかどうかは把握できるが、正しく入力されているかどうかはほとんどフォローできないだろう。トラッキングできなくはないが、凄いボリュームになるだろう。

あるいは、些細であっても問題が発生した場合には、関係者を集めてミーティングを行うという計画を作ったとする。この計画が計画通りに行われているかどうかをモニタリングするのは非常に難しい。

このような場合には監査というモニタリング方法をとる。

監査は個別の事象に注目するのではなく、視点を変えて、大局的に、全体的な傾向や、計画通りに行われた場合あるべき結果、インシデントなどに注目して、情報収集し、分析することによって状態が計画通りに行われているかどうかを判断する方法である。ある意味でサンプリング検査のようなものである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

非常に深い問題である。