プロセス１３：プロジェクトマネジメントノベル
クエスチョン1：読者からの質問に答える

メルマガの内容に対していくつかの質問を戴いている。個別に対応していたが、同じ質問が出てくるようであるので、公開回答に切り替えたいと思う。そこで、今回は、過去に戴いた質問に対する回答をまとめて配信する。

なお、質問メールにはいろいろなことが書いてあるものが多いので、その中から質問部分のみを抽出している。また、質問者の方に個別の回答したものとは微妙に内容が違っているものがある。これは見直したためということで、ご了解戴きたい。さらに、順序は質問を受けた順序ではなく、Activity順に並べ替えてある。

今後もときどき、このような形で質問集をやりたいと思いますので、どんどん、質問をください！

では、質疑開始！

Ｑ１：
ステークホルダ分析の定型的なやり方があれば教えてください？また、ステークホルダというのはどの範囲で考えるのでしょうか？考え出したらキリがないようにも思えるんですが（Activity4）

Ａ：
まず、何のためにステークホルダ分析をするのかということがあります。ＰＭＢＯＫではステークホルダ分析はコミュニケーションマネジメントのツールとして位置づけられています。このストーリーの中では、プロジェクトの構想をする際のリスクの洗い出しを目的に行っています。
目的によって若干の違いはあると思いますが、
　・ステークホルダ（役割・立場・役職）
　・各ステークホルダが持っている期待
　・各ステークホルダが受ける利益と損失
　・各ステークホルダのリスク許容度
　・各ステークホルダの期待が成就される条件
を順に洗い出していけばよいでしょう。
次に範囲ですが、これはおっしゃるとおりでキリがありません。定性的に言えば
　プロジェクトの目的に重大な影響を与える
ということになりますが、定量的に考えるのは難しく、感覚的になると思います。一種の人間関係のマネジメントでもありますので、それでよいかとも思います。


Ｑ２：
ＭＥＣＥについて詳しく教えてください（Activity4）

Ａ：
プロジェクトマネジメントＯＳ本舗に解説記事がありますので、こちらをお読みください。

Ｑ３：
アクテックの木村がコンサルティングとして、アプリケーション開発支援を行うことになったが、今回のホンダ電子とアステックの取引関係でフィーが取れるのだろうか？
（Activity4）

Ａ：
（この質問はメールではなく、知人の読者から口頭で受けた質問。パッケージを入れてコンサルフィーが取れるのかというところからきている質問です）
プロジェクトマネジメントとあまり関係のない話だと思われる方も多いかと思いますが、ひとつ重要なことが含まれているので取り上げました。プロジェクトの中に無償というように立場があいまいな要員がいるのは大きなリスク要因になります。なおかつ、コントロール不能なリスク要因になってしまう可能性があります。そこで、このようなケースでは、リスク対策費と位置づけで、立場を明確にすることが必要だといえます。

Ｑ４：
プロジェクトマネジメントスタッフというのは何をするのですか？（Activity5,Lesson3）

Ａ：
文字通り、プロジェクトマネジメントを行うためのスタッフです。ちょっとした規模のプロジェクトですと、マネジメントドキュメントの作成に大きく手をとられることがあります。このような作業はプロジェクトオフィスということでアシスタント的な立場の人が処理していきます。これにより、プロジェクトマネージャーは本来の仕事である意思決定や、ステークホルダの調整業務に専念することができます。このアシスタント的な人も含めて、プロジェクトマネジメント全体にかかわる人をプロジェクトマネジメントスタッフといいます。
しかし、プロジェクトの規模が大きくなってくると、本来の業務である意思決定や調整業務についても一人で対応するのは難しくなってきます。このような場合にはいくつかの分業の方法があります。ひとつは、プロジェクトをさらに小さな単位のチームに分けて、チームごとにリーダーを置いてそのリーダーにマネジメントして貰う方法です。もうひとつは、プロジェクトマネジメントの機能を（例えば、ステークホルダ、コスト、スケジュール、品質といったものに）分類し、それぞれに責任者をおくことによって分業をするというケースがあります。このような場合、分業した体制をプロジェクトマネジメントチームと呼ぶことがあります。
いずれにしても、プロジェクトマネジメントの生産性を挙げるためには、重要なポイントになります。

Ｑ５：
工数の見積もりにはどのくらいの精度が求められるのでしょうか？（Activity8）

Ａ：
これは難しい問題だと思います。エンジニアリング的には見積もり精度は工法の確立、品質の確保、基準工数の確立のために極めて重要な問題ですし、正確であればあるほど、工法の発展に貢献するという意味で好ましいと思われます。
ところが、ものづくりではなく、知識労働では、見積もり精度というのは見積もり方法のみに依存するわけではなく、環境要因、特に人的要因に大きく影響されます。このときに問題になるのはプロジェクトの目的・前提・制約です。例えば、スケジュールを厳守することがプロジェクトの前提である場合、精度が高ければ実現できるかというとこれは別の問題になります。現場を見ていると、精緻な計画や見積もりが、スムーズなプロジェクトの推進の阻害要因になっているケースも現実には少なくはありません。理論的にもＴＯＣプロジェクトマネジメント（ＣＣＰＭ）などが存在している理由はここにあります。
そのように考えると、求められる見積もり精度というのは絶対的なものではなく、プロジェクトごとに決まってくるという前提で、見積もりの目的を明確にし、その目的を達成できる精度を確保するというスタンスが重要だと思われます。
もちろん、見積もり技術がない限り、そのようなスタンスも取りようがないわけで、その意味で技術としての見積もり精度は無限に必要だとも言えるわけですが。

Ｑ６：プロジェクトマネージャーの補佐というロールは一般的ですか？また、その場合、プロジェクト（マネジメント）オフィスとの役割分担はどのようになるでしょうか？（Activity10）

Ｑ：
これは著者の知っている範囲ということになりますが、クロスファンクショナルなプロジェクトを組織する場合には比較的一般的な役割のようです。クロスファンクショナルなプロジェクトの場合、また、プロジェクトマネージャーは役員クラスであることが多く、マネジメント実務に深くコミットすることは困難です。その一方で、調整業務を中心にして、やらなくてはならないことはきわめて多いというのが現実です。
ところが、この調整業務は専門マターである部分が多く、単に事務作業として行うことは難しい部分があります。そこで、補佐的な役割の人を置いて、その人を中心に進めていくというスタイルをとるケースが多く見られます。

Ｑ７：
ストーリーを読む限り、目的に対するリスクというのは、計画に対するリスクに依存しているように思いますが、そのような理解で正しいですか？（Activity12）

Ａ：
依存するといいますか、計画に対するリスクは目的に対するリスクを大きくするという関係があります。逆、つまり、計画のリスクを抑えると目的のリスクが小さくなるという関係にはありません。

Ｑ８：
リスクがあまり具体的に書いていないのでよくわかりませんが、われわれの組織ではそもそも識別できないリスクというのがあると考えています。それについてはどのように考えればよいのでしょうか？また、もしあるとすれば、どのように扱えばよいのでしょうか？（Activity13）

Ａ：
この質問は実際のコンサルティングの際にもよく受ける質問です。識別できないリスクという概念がプロジェクトマネジメント的には矛盾しているということをまず押さえてください。つまり、プロジェクトマネジメントとしてリスクマネジメントはできないということです。
その上で、現実的にプロジェクトではそのようなケースは多々あるわけですので、プロジェクトとして何か手を打つ必要があります。それはコンティンジェンシープランを作るといった具体的なことではなく、リスクマインドを高めておくとか、プロジェクトマネージャー（リーダー）の危機時のリーダーシップを高めるといった抽象的な解決策にならざるを得ないと思います。

　（２００４．１０．２１号より抜粋）
購入はこちらまぐプレバナー