プロジェクトマネジメントのアイシンク
  • 企業研修
  • 公開講座
  • コンサルティング
  • PMドック
  • PMラボ
  • アイシンクについて

コラム

Home > コラム > 佐治与志也

佐治与志也

PMざっくばらん相談室

[佐治与志也] PM系講師

プロジェクトマネジャーの皆様から寄せられる質問に、PM講師の佐治がご回答いたします。
皆様の悩み、スッキリ解決いたします!

今回から、PMの皆さんから寄せられた悩みに、PM講師の佐治が回答していきます。

第1回は、小林さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

小林さん 38歳/PM歴6年/製品開発プロジェクトのマネジャー

私の悩みは、上司のTさんです。とにかく、言うことがコロコロ変わるんです。

まず、仕様が変わります。人が一生懸命作っている最中に「それもういらないから、代わりにこれを作ってくれ」と平気な顔をして言ってきます。

さらに納期も変わります。当初、12月末までといっていた納期を、急に「11月末までに仕上げてほしい」などと言います。

せっかく立てた計画がむちゃくちゃです。メンバーからも「どうなっているんだ」と突き上げが来るし、私はストレスのかたまりです。上司にも何度か、仕様とかはっきりしてから依頼して欲しいと要求しましたが、ぜんぜん改善されません。

私は、どうしたらよいのでしょう。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

それは困りましたね。そのような状況ではストレスがたまるのも仕方ありませんね。

ところで、小林さんはプロジェクトの計画をどのように考えていますか?
「計画は守るもの」と考えていたら、それが崩されるとストレスになります。

「計画は変わるもの」と考えたらどうでしょうか。
「プロジェクトにおいて計画は定期的に見直すものだ」と言ったら驚きますか?

実は、プロジェクトにおいて、守るべきはビジネスニーズであって、計画ではないのです。

今、小林さんがとりくまれているプロジェクトのビジネスニーズはなんでしょうか。
その製品が売れて会社の利益になることではないでしょうか。

その製品がクリスマス商戦を意識したものであれば、クリスマスに間に合わせるために、仕様を変更する、あるいは縮小することもあるでしょう。
また、自社製品が差別化できるはずの機能を競合他社が具備していることが分かり、新たに差別化が必要となって、売り出し時期を早めることもあるでしょう。

プロジェクトマネジメントには、このような状況に対応する、大変便利なツールがあります。それは「プロジェクト憲章」です。

「プロジェクト憲章」はプロジェクトを立ち上げるにあたり、そのプロジェクトのビジネスニーズ(背景および目的)、成果物、納期、予算、終了条件などを明らかにするドキュメントです。

特に、ビジネスニーズが大切です。これが明らかになれば、重要なのが仕様(スコープ)なのか、納期なのか、予算なのか、あるいは他の要素なのかが分かります。

おそらく、上司の方も気まぐれで発言をしているのではないと思います。

依頼を受けたら、まずプロジェクト憲章を作ってみたらいかがでしょうか。
それは、プロジェクト全体ではなく、小林さんが引き受けようとする範囲を対象としていれば十分です。ただしそこには、全体のビジネスニーズを含んでいることが重要です。

「プロジェクト憲章」を通して、上司の方とビジネスニーズが共有できていれば、きっと仕事がもっとやりやすくなります。
そして、変更要求があっても、きっと納得して受け入れることができるようになり、ストレスが減ることになると思います。

ぜひ、お試しください。


第2回は、佐藤さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

佐藤さん 34歳/PM歴3年/製品開発プロジェクトのチームリーダー

私の悩みは、プロジェクトマネジャーのNさんが私の業務の忙しさをまったく理解してくれないことです。

Nさんからの依頼内容は、協力会社さんに委託しています。

もちろん協力会社さんが実施している作業についても、進捗管理やレビューが必要ですし、その管理の工数はばかになりません。

ところがNさんは、「作業はほとんど外注しているのだから、君自身は余裕があるだろう」と言って、次から次へと仕事を割り振ってきます。

一方で、「プロジェクトでは終結が大事だから、しっかりとノウハウの蓄積をしろよ」などと言います。

終結の時期には、たいてい次のプロジェクトの立ち上げと重なっていて、終結の時間なんてとてもとれません。

どうしたらNさんに、管理も時間のかかる仕事だとわかってもらえるでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

それは困りましたね。そのような状況ではストレスがたまるのも仕方ありませんね。

ところで、佐藤さんはプロジェクト業務を開始する前にWBS(Work Breakdown Structure: プロジェクトの作業範囲を構造的に示したもの)を作成していますよね。

WBSで明らかになった仕事について、計画して実行しているはずです。

WBSの原則を思い出してください。「WBSにない仕事はやってはいけない」、これは裏を返せば、「プロジェクトでやるべき作業はすべてWBSにいれなければならない」のです。

佐藤さんは、進捗管理やレビューといった協力会社の業務管理を必要だからやっているはずです。ならば、外注管理もひとつの作業としてWBSに明記し、スケジューリングし、その工数を予算に計上する必要があります。

そうすれば、佐藤さんの業務も定量化されて、上司に見えるようになるはずです。

実は、終結がなかなか実施できないという事象も、同じ原因で起きている可能性が高いのです。

佐藤さんの「終結作業:プロジェクトマネジメント報告書作成」は、WBSに含まれていないのではないですか。WBSに含まれておらず、担当者も割り当てられていなくて、スケジューリングもされていない作業が実行されるはずがありません。

WBS作成にあたっては、無条件にレベル2に「プロジェクトマネジメント」という要素を配置することをお勧めします。
そして、レベル3以下に、「外注管理」あるいは「プロジェクトマネジメント報告書作成」といった作業を配置します。

こうすれば、これらの作業がやるべき作業として見える化され、そしてスケジュールに入れておけば実行されるようになります。

ぜひ、すぐにでもお試しください。


第3回は、関さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

関さん 45歳/PM歴15年/技術開発プロジェクトのチームリーダー

私のチームは専門分野を扱っていて、複数のプロジェクトを掛け持ちしています。したがって、複数のプロジェクトのさまざまな会議に呼ばれるのですが、何をやっているのかわからない会議や、いつ終わるのかわからない会議に悩まされています。かといって、自分が主催する会議が効率的というわけでもなく…。

なにかいい手はないものでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

それは困りましたね。そのような状況ではストレスがたまるのも仕方ありませんね。

ところで、関さんは、会議そのものがプロジェクトだと言ったら驚きますか?
プロジェクトの要件である「始まりと終わりがある(有期性)、必ず独自な部分を含む(独自性)」をみると、全ての会議がこれらの要件を満たしていることに気づかれると思います。

したがって、会議のマネジメントをプロジェクトマネジメントのプロセスに従って行えば、会議を効率化できるはずです。

具体的に考えてみましょう。

まず、プロジェクトの立ち上げでは「プロジェクト憲章」を作成し、そのプロジェクトが「何のために、何を目的として、何を成果物とするか」を明らかにします。
会議でも「何のために、何を目的として、何を成果物とするか」を明らかにして、関係者と共有することが大切です。

私の経験でも、「説明会」という名目で召集された会議に出席していたところ、本当の目的は「レビュー」だったということがありました。説明会と思って黙って聞いていたら、いきなり上司から意見を求められて面食らったこともあります。
こんな調子では、「何をやっているのかわからない会議」になってしまいます。

次に「WBS」を作成してスコープを明らかにしなくてはいけません。
会議においてはアジェンダ(討議項目)を明確にすることがこれに当たります。

WBSを作成したら、必ずセットで行わなければならないのが「責任分担マトリックス(RAM)」の作成です。

会議の場合では出席者の選別です。これは、必要な人が確実に参加して、不必要な人が参加していないことが大切です。

必要でもないのに呼ばれた人は「この忙しいのになんでここにいるんだ」と思い、マイナスのオーラを放つでしょう。
また、必要な人が参加していないと、「だいたいまとまったようだが、彼がいないので決定できない」という事態が生じ、せっかく参加した人たちのモチベーションが下がってしまいます。

さらに、「タイムマネジメント」も大切です。マイルストーンを決めて、時間を管理して、納期(会議終了予定時刻)を守りましょう。
「次の予定があるのに」とイライラして時計を見ながらでは有効な議論ができません。

最後に「終結」も重要です。会議のあとで結論について、ある人は、「いい案だったけど保留になって残念だった」と言い、同じ会議に参加していた別の人が、「え?それって、決定だろう」と言ったとしたら、何をやっているのかわかりません。
会議の最後には十分な時間をとって、決定事項の確認をし、早いうちに議事録を関係者にまわして確認をとる必要があります。

「会議をプロジェクトとしてマネジメントする」。
ぜひ、すぐにでもお試しください。


第4回は、宮下さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

宮下さん 39歳/PM歴10年/ITプロジェクトのプロジェクトマネジャー

私は、いわゆる一人PMです。
2週間前から手掛けているプロジェクトのことで、とても困っています。

このプロジェクトは受注後に私に回ってきたのですが、開始にあたって、内容を精査したら、見積りが甘々で、受注金額の倍の工数がかかることがわかりました。

上司に相談したら、納期まであと3か月しかないし、受注してしまったんだからとにかくやってくれと言われました。

当初、納期と品質は絶対と訊いていたので、コストは融通がきくのかと思っていたところ、コストも予算通りやるようにいわれました。
これから休日もなく、毎日残業したとしても終わるかどうか見えません。どうしたらよいのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

それは困りましたね。そのような状況ではストレスがたまるのも仕方ありませんね。

一見無理に見えるプロジェクトを押し付けられるということの背景を考えてみましょう。

ひとつは、上司が宮下さんなら何とかしてくれるだろうと期待していることが考えられます。

そして、もうひとつは、かなり無理そうだけれども不可能ではないと思っているということです。
これは、上司が、リスクをとってチャレンジを要求していることを意味します。

このような状況において、宮下さんがすべきことは2つ考えられます。

一つは、成功確率を最大限にあげるような選択をすることです。

これには、成果物を作り出す作業する上でも、マネジメントする上でもベストを尽くすことが求められます。
そこに休日のすべてと連夜の残業が含まれるかどうかは常識の範囲内で判断します。

そしてもう一つは、チャレンジの状況、すなわちリスクの最新情報を確実に上司に伝えることです。

リスクが日に日に小さくなっていくのであれば、それはプロジェクトの成功につながるでしょう。

もし、リスクが日に日に大きくなっていくのであれば、どこかでこれ以上リスクが大きくなると手の打ちようがなくなるというポイントに達します。
失敗するとわかって、手を打たない上司はいません。
そこで、納期と品質が絶対であれば、コストをあきらめて要員を調達するなどの手を打つはずです。

まとめると、宮下さんのやるべきことはプロジェクト成功に向けてベストをつくすということと、リスクを常に上司に見せることです。課題を可視化し、一緒に対応を考えてもらうよう、上司を巻き込んでいくことです。

良く見かける悪い例として、初めは上司にリスクを説明したけれど何もしてくれないからと言って勝手にあきらめ、上司へのリスク開示をしなくなるケースを見ます。
この場合、上司は連絡が来ないことはなんとかなったことだと、勝手に解釈して、最後に裏切られたように感じるのです。
これではいけません。

「リスクマネジメントをしっかり行って、リスクを上司に見せ続ける」。
ぜひ、すぐにでもお試しください。


第5回は、河田さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

河田さん 36歳/PM歴9年/ITプロジェクトのプロジェクトマネジャー

私は総人員4〜5人の比較的小さなプロジェクトを任されています。

その見積のことで悩んでいます。

ただでさえ、少なめの見積りで、のちのち予算が足りなくなることが多いのに、上司は問答無用で予算を削ろうとしてくるのです。

これでまた最後に予算オーバーになって、叱責されるかと思うとたまりません。

どうしたらよいでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

それは困りましたね。そのような状況ではストレスがたまるのも仕方ありませんね。

問答無用で予算を削ろうとする上司に対抗するには、やはり見積に自信をもつ(=精度をあげる)ことが必要です。

ここでは、どうしたら工数見積もりの精度を上げられるのかを考えてみましょう。

私がよく紹介する見積精度向上の4つのポイントは、以下の4点です。

  1. 正確なWBSを作る
  2. わかる人が見積もる
  3. 過去のデータを活用する
  4. 適切なバッファを確保する

今回は、中でも特に見落としがちな2と4について詳しく見てみましょう。

2.わかる人が見積もる

見積もり作業を行うのはリーダーやマネジャーの仕事だと思っている、あるいはメンバーをわずらわせたくないという思いから、自分1人で見積り作業をしていませんか。

しかし、見積もり作業にはメンバーを加えることが大事です。

工数を見積もるときは、「業務の内容」がわかることが重要ですが、「作業を実施する要員の能力」も必要な情報ですね。

実は、要員の能力を一番知っている人は要員(メンバー)であり、要員を見積もり作業に加えることが見積精度の向上につながります。

さらに、要員を見積もり作業に加えるともう一つ大きなメリットがあります。見積に加わった要員は、見積に対してそれを守ろうとするモチベーションが高くなる、ということです。

4.適切なバッファを確保する

バッファは持ってはいけない(=甘い)という先入観を持つ人がいます。
しかし、リスクに見合ったバッファを持たない見積りはたいてい破たんします。

バッファを考慮した見積技法が3点見積と呼ばれるものです。

1つの作業に対して、何人日といった見積もりは1点見積です。

これに対して、楽観的には何人日、悲観的には何人日、もっともありそうな場合(最頻値)が何人日というように、3点を押さえるのが3点見積です。

悲観値から離れて楽観値に近くなるほど達成の可能性は低くなります。

楽観値が8人日、最頻値が10人日、悲観値が16人日なら、16人日を下回れば下回るほどリスクが高くなります。

個々の作業の見積りを厳しく(楽観値に近く)見積もると、予算の達成の可能性も低くなるので、予算を守るために相応のバッファが必要になります。

このバッファのことをPM用語で「コンティンジェンシー予備」といいます。

十分なバッファを確保するもあり、少ないバッファでチャレンジするのもありですが、プロジェクトマネジャーとしては、リスクを把握した上で判断することが重要です。

「見積精度向上の4つのポイントを実施し、自信を持って上司と交渉する」。
ぜひ、すぐにでもお試しください。


第6回は、内藤さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

内藤さん 34歳/PM歴7年/設備設計部門の係長

昨年学んだプロジェクトマネジメントの技法を、さっそく現場で活用しようとしたのですが、なかなか思うようになりません。

現場のほとんどの課長職がその種の手法を、「学習する気がない」「時間がない」「今までのやり方でできていたから大丈夫」といって取り合ってくれません。

そもそもプロジェクトマネジメントは、プロジェクトマネジャーあるいはそのレベルにいる人がまず身に着けて実施しないかぎり、うまくいかないのではないでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

せっかく新しいマネジメントを身に着けても、上の方々が旧来の方法でやろうとするということでは、ストレスを感じていることと思います。

しかし、人を変えるということはとても困難なことです。

ここでの効果的な対処方法はステップバイステップです。

あなたが、プロジェクトの一部だけを担当している場合でも、ご自身の担当部分はプロジェクト(有期性、独自性を持つ)だと思われます。

まずは、ご自身が任された範囲だけを対象にマネジメントを適用してみましょう。具体的には、任された範囲のWBSを作成して、リスクを洗い出して、リスク対応計画を立ててみるなどです。

そして見える化と共有(上位のマネジメントを含む)を心掛けます。その範囲のマネジメントをやりきるだけでもかなりの努力と時間が必要だと思います。

もし、それをやりきることができれば、その影響はおのずと周りに伝わるものです。

新しいマネジメントが効果を上げることを見て初めて、周りの人も注意を向けてくれるでしょう。

「お、あいつ、うまくやっているじゃないか」と思われればしめたものです。そこで初めて、新しいマネジメントを提案する、あるいは適用範囲を広げていくのです。

できるところから、あるいは任されたところからステップバイステップで進める。ぜひお試しください。


第7回は、曽我さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

曽我さん 44歳/PM歴12年/システム会社の課長

プロジェクトマネジメントを学んで、不確実性の高いプロジェクトを実施するにあたっては、バッファ(予備)が必要であることが理解できました。

11ヶ月の工期でメンバー10人でぎりぎりであれば、バッファを考慮して11人体制でプロジェクトに臨みたいと考えています。

ところが、あらかじめバッファ予算を持つことが、社内的に認められていないのです。

その結果、毎回のようにプロジェクト終了近くになると工程が遅れていて、納期を守るために、連日残業を重ねるはめになります。

また多くの応援を依頼するはめになり、結局いつも当初予算をオーバーしています。

どうしたら、もう少しマネジメントらしいマネジメントができるようになるのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

せっかく新しいマネジメントを身に着けても、上の方からの圧力で思うようにならないというのでは、ストレスを感じてしまいますね。

ところで、曽我さんの中で、工数と工期がごっちゃになっていませんか?

工期上のバッファを持つことと、工数(予算)上のバッファを持つことは必ずしも同じではありません。

どうやら曽我さんの中では納期ぎりぎりまで追われることが当たり前になっているので、「プロジェクトを早めに終える」という発想が抜けているようですね。

多くの人数を投入して、なにごともなければ、プロジェクトはその分納期よりも早く終わるのです。

そうすれば、工期上のバッファを確保した上で、予算は変わらないことになります。

頂いた例では、「10人×11ヶ月」で110人月が予算ですから、この予算を変えずに、「11人×10ヶ月」で110人月として計画します。

スタート時から多めのメンバーを用意して、1ヶ月前倒しでプロジェクトを終えるように計画するのです。

早めに推移していれば、たとえ業務の追加・変更要請が生じても、納期を守りやすくなります。

またコスト的にも、初めから予算に余裕を持つことは上司として認められないかもしれませんが、変更が生じた後での予算の追加なら認めてもらいやすいはずです。

多めの人員で、前倒しで計画する。ぜひお試しください。


第8回は、坂口さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

坂口さん 31歳/PM歴2年/機械メーカーの主任

少ないながら複数のプロジェクトをマネジメントしてきた私からみると、どう考えてもスケジュールもコストも品質も全然うまくいくと思えないプロジェクトを上司から任されてしまいました。

正直、やる気も失せてしまうぐらいなのですが、どのようにマネジメントしたらよろしいのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

はなからできそうもないプロジェクトを任されて、自分の評価が下がることが目に見えている。このように思えるときは本当にやりきれませんね。

このようなケースで、あり得るひとつの理由は、実は依頼者が計画通りいくことを期待していない場合です。

「ちょっと目標が高すぎるかもしれないが、勉強のため、チャレンジを味わってもらおう」といった場合です。無理を承知でやってみろ、ということですね。

このようなケースでは、依頼者とよく話し合えば解決します。

もうひとつのケースは、プロジェクトの不確実性が高いために、依頼者本人も納期やスコープの見積もりが精度よくできていない場合です。

このような場合は、プロジェクト全体をいくつかの段階にわけて管理することが大事です。このプロジェクトの段階のことを「フェーズ」と呼びます。

不確実性の高いプロジェクトも、進めていくうちにだんだんとその姿が見えてきます。そのとき、進むか引くか、あるいは方向を変えるかの判断が、フェーズに分けて管理することで可能になるのです。

たとえば私の経験したプロジェクトに、大気汚染防止法が施行された際ですが、今まで野焼きしていた堤防に生えている草の処理をどうするかを検討するというプロジェクトがありました。

発注時の依頼者の頭にあったのは、焼却炉を建設するか、それは大型のものか、小型のものを分散させるのか、あるいは専門業者に委託するのかという視点のみでした。

ところが当初の計画段階で、「刈り草を有効活用してはどうか」というアイデアが出たため、堆肥にした場合、家畜の飼料にした場合、製紙の原料にした場合…というように、際限なく検討範囲(スコープ)が膨らんでいきました。

この計画フェーズのレビューにおいて、「工数が増えてプロジェクト単体では赤字になるかもしれないが、あとにつながるのであればとことんやろう」という上司(スポンサー)の判断があり、製紙については、実際に工場に持ち込んで試験的に紙を作るところまでやりました。

このようにフェーズ移行では、当初計画のまま次フェーズに進んでいいのか、あるいは計画を変更して進むのか、あるいは中止するのかを、スポンサー、場合によっては依頼者を含めて検討します。

プロジェクトマネジャーとして肝心なのは、スポンサーや依頼者が正しく判断できるように、それぞれの選択肢の影響とリスクをわかりやすく伝えることです。

また、当初から不確実性が高いことがわかっているなら、フェーズ移行の基準をあらかじめ作っておくことも、フェーズ移行をスムースにする上で有効です。

不確実性の高いプロジェクトではフェーズ移行をしっかり管理する。ぜひお試しください。


第9回は、斉木さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

斉木さん 33歳/PM歴2年/機械メーカーの技術職

プロジェクトマネジメントを学んで、いかにマネジメントが必要かを痛感しました。

しかし、実際にマネジメントを行うとなると、上司がそのための時間を取ることを許してくれるとは思えません。

実務作業を行うだけで、時間がめいっぱいです。

どうしたら、マネジメント時間の確保について上司を説得できるでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

せっかく学んだことが、活かせないとなると、ストレスを感じてしまいますね。

ところで、斉木さんの行っているプロジェクトは、マネジメントが必要だと感じているということは、それなりの複雑さを持ったプロジェクトなのでしょうね。

複雑なプロジェクトにはマネジメントが必要です。

マネジメントが必要なプロジェクトに対して、適切なマネジメントを行っていないのであれば、それによるロスが生まれているのではないでしょうか?

例えば、プロジェクト憲章を作成せず、プロジェクトの背景や目的を誤解したままでプロジェクトを進めたら、依頼者の意図と違った余計な作業をする可能性はありませんか?

WBSを作成せず、プロジェクトのスコープを合意することなしに進めたら、しなくてもよかった作業に工数をかけたり、手戻りで工数が増えたりしませんか?

リスク登録簿を作成せず、上司とのリスク共有を行っていないために、リスク発生時にどたばたになって、非効率なトラブル処理をするはめに陥りませんか?

プロジェクトマネジメントを行うと、行わない場合より、トータルの時間・工数は小さくなります。そうでないとマネジメントの意味がありません。

もし、これまでマネジメントをせずに20日で実施していた一連の作業があったとすれば、1日をマネジメントに費やした場合、トータルは21日ではなく、当初と同じ20日かそれ以下でできる可能性が高いのです。

それならば、上司にマネジメントのための追加の時間を要求しなくても済むはずですね。

ぜひ一度しっかりと「プロジェクト憲章」なり「WBS」なり「リスク登録簿」なりを作成して、上司を含む関係者と共有してみてください。

きっと、これらを関係者と共有することによって、プロジェクトがいかにスムースになるかに驚かれることと思います。

複雑なプロジェクトではマネジメントがトータル工数を減らします。ぜひお試しください。


第10回は、西村さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

西村さん 36歳/PM歴5年/技師

組織内グループのリーダーを務めています。

ついつい自分自身で多くの作業を抱え込んでしまうためか、なかなかマネジメント(特にプロジェクト開始前の計画立案)に十分な時間を掛けられていません。

本来は自分自身の作業をもっとメンバーに割り振りたいのですが、メンバーのスキル不足や時間的な制約もあって、なかなか進められていません。

なにかいい方法はないでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

マネジメントもしなくてはならない一方で、実作業もしなければならない。
プレイング・マネジャーは、本当に忙しくて大変ですね。

現在は、おそらく西村さん自らが作業したほうが、品質面でも納期の面でも有利であることは確かなのでしょう。

もしかしたら、西村さんの技術者としてのアイデンティティを確保するという面でも、作業に未練をお持ちかもしれません。

でも、あえてすべての作業をメンバーに割り当てることをお勧めします。

たとえスキルの問題があっても、我慢してメンバーを担当に割り当てます。

そして、最初から最後まであなたの支援が必要になるとしても、あくまでも作業主体はそのメンバーにして、そのメンバーのスキル向上を目指さなくてはなりません。

そうして組織の生産性を向上することが根本的な解決につながります。

また、少しでもマネジャー自身が作業に没頭することは、たいてい全体の調整に不具合が生じることとなり、結果的に時間のロスへとつながるリスクが大きくなります。

スキルがないから、時間がないからというのは、単なる問題の先送りでしかありません。

今は、かえって時間がかかることになっても、メンバーに作業を任せて、将来に向けた組織作りをしてください。

ただし、メンバーが4〜5人以下なら、あなたはマネジメントに専念してはなりません。

もし専念したら、メンバーから不満が上がるでしょう。

その場合はあなたも作業の一部を担当する前提で作業の割り当てをすることが必要です。

一人のリーダー、あるいはマネジャーが直接面倒をみるメンバーの数はプロジェクトの内容によって異なりますが、一般的に6−8人が適正です。

それよりもメンバーが多くなってきたら、マネジメントの一部を代行するサブマネジャーの育成も考えるといいでしょう。

「今だけでなく、将来の組織の生産性を考えて、メンバーに作業を任せていく」。
ぜひご検討ください。


第11回は、大谷さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

大谷さん 37歳/PM歴7年/通信関連会社技術部

工期9ヶ月ほどの中規模プロジェクトのマネジャーをやっていますが、関連部門が多く、状況をしっかり把握できないことに困っています。

自分の部署だけで対応できる案件ではスムースに行くことが、他の部門がからんでくるとうまくいきません。何か問題があってもなかなか伝わってこず、どうしようもなくなってから初めて言われることが多いのです。

先日も、システム部門が使っている業者の工程が間に合わない可能性が高いことを、システム部門では早くからわかっていたにも関わらず、こちらには全く連絡がなく、予定日の前日になって急に「1週間延びる」と言われたことがありました。

予定通りに準備を進めていた私の部門では、段取りを変更するのが大変で、多くの人に迷惑をかけてしまいました。

なにかいい方法はないでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

確かに、複数の部署が関係するプロジェクトをまとめるのは、本当に大変ですね。

何かあっても、なかなか言ってくれないというのは、変にネガティブな情報を伝えて混乱させてはいけないという遠慮があるからかもしれません。また、次工程の内容に関心が薄いのかもしれません。

これはつまり、他部門の人々の中に「大谷さんたちと同じチームの仲間だ」との意識が十分に育っていないからではないでしょうか。
チームビルディングが不十分な状況が伺えます。

ところで大谷さんは、チームビルディングの対象は、普段一緒に仕事をしている部門内に限るものと考えてはいませんか?

他部門が別の場所で作業をしていても、同じプロジェクトのために作業するメンバーはみな一つのチームであり、チームビルディングの対象と捉えるべきです。

チームビルディングは、チームの気持ちを一つにして、チームの目的達成のためにパフォーマンスが高いチームを育てることです。

その第一歩が、キックオフから始まる「フォーミング」とよばれるプロセスです。
キックオフがプロジェクト開始の単なるセレモニーになっている事例をみかけますが、本来キックオフはチームビルディングの重要な活動です。

フォーミングでは、次のことを行います。

  • 目的の共有
  • 役割の明確化
  • お互いをよく知るための活動(自己紹介、懇親会)
  • メンバーへの期待を示す
  • プロジェクトの意義を示す

他部門にまたがるプロジェクトでは、特にお互いをよく知るための活動が不十分になりやすいので、時間をかけてよく実施する必要があります。

以前私はゼネコンに勤務していて、瀬戸大橋建設プロジェクトにメンバーとして参加したことがあります。
そのときは、他部門どころか、複数の会社が集まって1つの共同企業体を形成するというチームでした。

そこでは、初日のキックオフミーティング以降、毎日のように懇親会が開催されたのです。

もちろん朝から飲んでいたわけではなく、夕方からでしたが、関係者が多いため、いろいろな組み合わせで懇親会を行う必要がありました。

当時は私も若かったので、「なんでこんなに飲み会があるのか」と思っていましたが、今にして思えば、チームビルディングのためだったのだと思い返されます。

関係者がお互いに打ち解けて、言いたいことが言える関係になることがチームビルディングの最初の成果です。

「複数部門が関係するときは特にチームビルディングに注力する」。
ぜひご検討ください。


第12回は、倉田さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

倉田さん 34歳/PM歴5年/IT関連

6人のメンバーを取りまとめるプロジェクトリーダーとしてIT系の開発プロジェクトに参加しています。

毎週プロジェクトマネジャーに対して担当分の進捗を報告しなければならないのですが、メンバーからの進捗報告が期限どおりにあがってきません。

毎回催促が必要になるうえに、催促しても報告してこないメンバーに対しては、私から直接出向いて進捗を聞かなければならないこともあります。

私自身、プレイングマネジャーでただでさえ忙しいのに、進捗管理で余計な工数をとられてイライラしてしまいます。

なにか進捗の把握を容易にする方法はないものでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

プレイングマネジャーという立場で忙しい中、メンバーの進捗管理にも気を配るのは、本当に大変ですね。

ところで、メンバーあるいは部下が報告して、リーダーあるいは上司はそれを受け取るというのがあるべき姿なのでしょうか。

リーダーがメンバーのところに進捗を聞きに行くと、時間の無駄になるのでしょうか。

メンバーのところに行って直接メンバーと話をすると、進捗だけではなく、リーダーにとって貴重な情報が手に入ります。

メンバーの顔色を見れば、彼らのモチベーションが高いのか低いのか、あるいは何か問題を抱えているのではないかといったことがわかってきます。

そこで問題があれば、いち早くその問題に対処することができます。

それは将来に向けて、とても効率的なことではないでしょうか。かえって時間ロスが減ることになりませんか。

ぜひ、一日に一回はメンバーのところに行って、雑談をしてみてください。きっと有用な情報が手に入るでしょう。そして、メンバーとの信頼関係が向上するはずです。

メンバーにしてみれば、毎日自分たちのことを気にかけてくれるリーダーは、信頼できるリーダーなのです。

そのうちに、メンバーにしても気がかりがあれば、自らリーダーに相談しに来てくれるようになります。

「メンバーの情報がほしければ、自分から取りに行く」。
ぜひご検討ください。


第13回は、牧村さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

牧村さん 38歳/PM歴10年/情報システム部

私の部署では、常時7〜8つ のプロジェクトが走っていて、私はそのとりまとめをしていますが、各プロジェクトの進捗がうまくつかめなくて困っています。

プロジェクトマネジャーによっては、毎週きちんと進捗率を報告してくれるのですが、「忙しくて・・・」といった理由で、なかなか報告してくれない場合が多い状況です。

上がってくる報告も、その進捗率の根拠が不明で、その精度に不安があります。

上司からは定期的に正確な進捗報告を求められており、毎週のように進捗管理で苦労しているのですが、なにかいい方法はないでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

確かにプロジェクトを管理する上で、進捗の把握というのは本当に大変ですね。

進捗を報告してくれないという件については、ひとつには先月ご紹介した通り「マネジャーが自ら進捗を聞きに行く」という手がありますが、もうひとつ、進捗管理を容易にする手法を紹介しましょう。

進捗報告がはかばかしく上がってこない原因のひとつに、「進捗報告に手間がかかる」ということが考えられます。

よく見かける手間がかかる進捗報告のやり方は、「作業ごとの進捗率を報告する」というものです。

この方法では、報告者は作業毎の進捗率を算定するという手間をかけなくてはなりません。
これはあたりまえのように思われるかもしれませんが、実はもっと簡単な進捗報告の方法があるのです。

それは、「50−50ルール」あるいは「0−100ルール」と呼ばれる方法です。

「50−50ルール」では、ある作業について、着手したら50%、完了したら残りの50%を計上します。
「0−100ルール」では、ある作業について、完了したら初めて100%と報告します。

これだけ聞くと、精度が低くて話にならないように感じるかもしれませんが、この方法は、スケジュール表の1つのタスクをさらに分解した担当者レベルの作業で行うものです。

たとえば、あるプロジェクトについて、末端レベルの作業が100個あったとします。

このとき、3つの作業に着手していて、そのうちの2つがすでに完了していれば、「50-50ルール」なら、それぞれの作業の報告は、50%のものが1つと100%のものが2つで、プロジェクトレベルでの集計結果は 0.5/100 + 2.0/100 = 2.5/100 = 2.5% となります。

決して、精度が低いとは感じないのではないでしょうか。

個々の作業についてその進捗率を出そうとすると過大な手間がかかりますが、着手したかあるいは完了したかの判断をするのはきわめて容易です。

報告の手間がかからなくなると、報告自体も容易に上がってくるようになるはずです。

この報告方法の精度を高めるコツは、作業ごとの粒をそろえることです。大きな作業の完了と、小さな作業の完了では意味が違います。

大きいプロジェクトなら個々の作業は1週間程度、小さいプロジェクトなら個々の作業は2〜3日程度の工数となるようそろえておきましょう。

もし、さらに精度を高めたいなら、作業ごとの重み付けをする方法もあります(EVMと呼ばれます)。
その場合は、それ相応のマネジメント負荷が増えることを承知する必要があります。まずは、重み付けなしで、運用することをお勧めします。

「末端の作業は『着手・完了』で進捗を管理する」。
ぜひ、お試しください。


第14回は、大河原さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

大河原さん 31歳/PM歴2年/SE

私の部署では、イナズマチャートというツールを使って、進捗管理をしています。

そのため、タスクごとの進捗を上からうるさく求められ、特に大きく計画から遅れているタスクについては、その理由だの対策だの多くのレポートが必要になります。

だけど、タスクによっては、そんなに急がなくてもいいタスクもあります。

今の進捗管理は何かおかしいような気がするのですが、どうするのが正しいのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

大河原さんのおかしいと思う気持ちは、よくわかります。
イナズマチャートは、わかりやすい一方で、“危ない”ツールでもあります。

イナズマチャートでは、ガントチャートをベースに、計画より進んでいるタスクについては、進捗に応じて基準線(状況報告日)より右に、計画より遅れているタスクについては、進捗線の左に進捗度をプロットし、それを折れ線でつないだもので、右左にジグザグなイナズマに似た形のチャートを表します。

そのことにより、計画の進み遅れが視覚的にとてもわかりやすくなります。

イナズマチャートによる報告を受けるマネジャーは、どうしても左に大きく振れている(計画より大きく遅れている)タスクに目がいきます。
ところが、そこにイナズマチャートによる管理の“危なさ”があるのです。

なぜなら、計画から大きく遅れているタスクほど、プロジェクトにとって問題が大きいとは限らないからです。

具体的な例を示しましょう。

システム開発のプロジェクトにおいて、あるパーツはモジュールAとモジュールBの2つの部品からなっているとします。

モジュールAの開発は、隣のチームが担当していて、所要期間は10日間です。
一方モジュールBの開発は、あなたのチームが担当していて、所要期間は6日間です。

さて、5日目が終わった時点で、モジュールAの作業が1日分遅れていて、モジュールBの作業が2日分遅れていたとき、モジュールBの作業を遅れを取り戻すことのほうが重要でしょうか。

モジュールBの作業が遅れたままで、2日超過の8日間かかったとしても、このパーツの完成時期にはなんの影響も与えません。
しかし、モジュールAが1日の遅れを取り戻せずに11日間かかったら、パーツの完成時期が1日延びてしまいます。

これはとても単純な例ですが、どんな複雑なプロジェクトでも、「その遅れが完成時期(納期)の遅れに直結するタスク」と、「ある範囲までは遅れても完成時期に影響しないタスク」があるのです。

この「完成時期に影響しない遅れ」のことをプロジェクトマネジメント用語で「フロート」と呼びます。

したがって、重要なのは「計画よりどれだけ遅れているか」ではなくて、「その遅れがフロートを超えているか」どうかなのです。
フロートを把握していないと、取り戻すべき遅れなのか、放置可能な遅れなのかが判断できません。

よく耳にするタスクの優先度がわからないという悩みの答えもここにあります。

フロートがないタスクが優先なのです。
フロートを把握して初めて合理的な進捗管理が可能になります。

このフロートを見える化する手法がクリティカル・パス法と呼ばれる手法です。

ぜひ、クリティカル・パス法を学ばれて、フロートを見える化してみてください。


第15回は、木村さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

木村さん 42歳/PM歴14年/製品開発プロジェクトのマネジャー

PMBOK®を学んでみると、いたるところで「過去の情報」が出てきて、精度の高い計画を立てる上でプロジェクトの教訓を残していくことがいかに大事かよく理解できました。

しかし、少なくともいま自分が所属する部署では、過去の情報が活用できる状況にはありません。

なぜなら、プロジェクトの終結時期は、次のプロジェクトの立ち上げ時期でもあり、いかにスムーズにプロジェクトを立ち上げるかに手一杯になって、とても終結を行う余裕はありません。

どうしたら、きちんと終結ができるようになるのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

終結は、簡単なようで実際に行うのは難しいようです。
私が今まで見てきた中でも、終結は実施されていないことが多いプロセスです。

しかし、終結のプロセスがまったく実施されていないということは、組織にとって大変もったいないことです。
少しでも終結を実施することは驚くほど効果があります。

まずは、最低限の終結を行って、ステップバイステップで範囲を拡大したらいかがでしょうか。

終結が実施されないことの原因の一つは、終結には「時間がかかる」との思い込みがあると感じています。

終結では、終了報告書といったドキュメントを必ず新たに作成しなければいけないと思っていませんか。
実はそんなことはありません。

終結でまとめるべき主要項目は以下の通りです。

  1. 当初の計画
  2. 計画に対しての修正・変更
  3. 実績
  4. 改善すべき事項

これらのうち、1,2,3については、日頃の進捗管理、変更管理を普通に実施していれば、プロジェクトの終結時点ではほとんどすることがないはずです。

この段階で必要なのは、不要なファイルの削除と、フォルダーの整理ぐらいです。

紙の時代やディスクが高価だった時代には、このような記録の保存自体、かなりの手間が必要でしたが、いまのようなディスクの容量が気にならない時代にあっては、無理に時間をかけて整理しなくても、必要なファイルがわかるところにあれば十分です。

このように考えれば、ひとりひとりの終結に向けての記録整理は最小限であれば1-2時間でできてしまいます。

「4.改善すべき事項」については、関係者が集まってレビュー・ミーティングを開き、その結果を議事録のような形で残すのが有効です。

終結はプロジェクト全体の最後ではなく、フェーズごとに行うことが肝心です。

終結をプロジェクト全体の最後にやろうとすると、最初のころの記憶が定かでなくなるだけでなく、フェーズが変わると関係者も入れ替わって、もはやレビュー・ミーティングに必要な人員を集められなくなります。

以上から、終結の要点をまとめると

  • まずは、ファイルやフォルダーの整理だけといった簡単なことだけから始めて、必要に応じて範囲をひろげる
  • 日々の進捗管理、変更管理をきちんと実施しておく
  • フェーズごとに終結、とくにレビュー・ミーティングを実施する

となります。

いかがでしょうか、これならすぐにでも着手できるのではないでしょうか。
ぜひ今後は終結のプロセスを実施してみてください。


第16回は、遠藤さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

遠藤さん 36歳/PM歴8年/製品開発プロジェクトのリーダー

プロジェクトで、過去の情報、教訓が役に立つことはよくわかります。
プロジェクトの最後には「プロジェクト終了報告書」をまとめて、実績や教訓をまとめる「終結」が必要なこともわかります。

しかし、プロジェクトの終了時には、たいてい次のプロジェクトが控えていて、いかに次のプロジェクトをスムーズに立ち上げるかで頭がいっぱいです。

そもそも、プロジェクトにおいて、スコープ以外の活動に割く時間もお金も認められていません。
結果、実績も教訓も有効に蓄積されていません。どう考えたらいいのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、終結は必要だと思っていても、現実にはなかなか実施できないということですね。お悩みはごもっともです。

まず、遠藤さんは「終結はプロジェクトのスコープ外」と思っていらっしゃいますが、実はそう思っていること自体が問題です。

弊社では、コンサルティング案件を引き受けた場合、お見積もりの詳細に「プロジェクト終了報告書作成」という項目を入れます。
そして、プロジェクト終了時には、プロジェクトの成果を収めるとともに、「プロジェクト終了報告書」を作成して、顧客に対して「どう計画して、何をしたか、どうなったか」といったプレゼンを行います。

このことは、顧客にとっても今後の継続的なプロジェクト遂行のための大きな資産になります。

しかし、顧客によっては、できるだけ経費を節減したいという名目で、「プロジェクト終了報告書作成」を見積もりから外すことを求めてくる場合もあります。

その場合は、見積もりから外したとしても、社内的なWBSには、プロジェクトマネジメントの項目の下に「プロジェクト終了報告書作成」という項目を明記し、実行しましょう。

なぜなら、「プロジェクト終了報告書」がないと自社自体のノウハウが蓄積できないからです。
ノウハウ蓄積こそが組織としての資産なのです。

「プロジェクト終了報告書作成」は、顧客のためのだけのスコープではなく、実施する側の組織のために必要なスコープなのです。
ただし、相当のお金をいただけない場合は、顧客向けプレゼンは実施しません。

もし、遠藤さんが実施するプロジェクトのWBSに「プロジェクト終了報告書作成」が入っていなければ、きっと役割分担にも、スケジュールにも「プロジェクト終了報告書作成」が入っていないことになるでしょう。

そうしたら、誰が、スコープにもなく、割り当てにもスケジュールにもない作業をするのでしょうか。

したがって、実効ある終結を行うためには、まず計画段階から「プロジェクト終了報告書作成」をスコープに入れること、具体的には「WBSに入れること」が肝要です。

もし、「プロジェクト終了報告書作成」を含むWBSを上司が認めないようなことがあれば、その段階で、上司を説得する必要があるかもしれません。

そのときは、前号で解説したように「プロジェクト終了報告書作成」は、そんなに手間がかかるものではないということをお話ください。

「計画では、『プロジェクト終了報告書作成』も必ずスコープに入れる」。
ぜひお試しください。


第17回は、鈴木さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

遠藤さん 38歳/PM歴9年/システム開発プロジェクトのリーダー

自分が納得できないプロジェクトを進めていかなければならないことがとてもストレスです。
今やっているプロジェクトも、予算達成はほとんど不可能で、利益の確保は絶望的です。

受注前から、上司に対して「利益が出ない=受けてはいけないプロジェクト」だと伝えているのですが、まったく聞く耳をもってくれません。

このような上司を説得するにはどうしたらよいのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、納得できないプロジェクトに取り組まなければならないのはストレスでしょうね。

あなたとしては、当然断るべきと思うプロジェクトを引き受けてしまう上司の考え方は間違っていると思うわけです。

ただ、このような意見対立の原因は、実は、上司あるいはあなたの考え方自体に問題があるのではなく、誤解に基づくことが多いように思います。

もし、あなたが納得できない状態でプロジェクトを進めているのなら、あなたはモチベーションも上がらず、けっして良いパフォーマンスは出ていないことでしょう。
さらに、あなたが納得していないなら、あなたの下で働くメンバーはもっと納得できていないでしょう。

納得できていないメンバーで構成されたチームのパフォーマンスはどうなるのですか。

つまりこれは、「チームビルディング」の問題です。チームビルディングは、チームのパフォーマンスを高める活動であり、その最初のステップは「目的と成果の共有」です。

相手が聞く耳を持たないようにみえるからといって、そのまま過ごすのは得策ではありません。
食い下がってでも、「目的と成果の共有」を行う必要があります。

通常、上司は、部下よりも多くの情報を握っていることが普通です。
上司はその多い情報をもとに判断をするので、少ない情報だけから判断する部下とは見解が異なることになるのです。

ただ、上司はそのことに気付いていないことも多いのです。
「こんなことは、みんな知っていて当然だろう」といった感じです。

そこで、まずは、上司が考えているであろう「目的と成果」を明文化して、上司に確認してもらいましょう。

1.目的
 例:プロジェクト単体では利益が出なくても、他部門の関連事業で利益が上がっている。したがって、このプロジェクト単体の利益ではなく、損が出ない範囲で継続的に受注することによって、他部門とのトータルでの利益を目指している。

この「目的」はいわゆるビジネスニーズであり、ここの認識が上司-部下間でずれていることが多いのです。

2.成果
 例:要求されたシステムを納めるだけではなく、顧客側担当者に対して「継続発注に値する会社」という好印象を持ってもらうこと

この「成果」は、モノだけではなく、評判・ノウハウといった、「目に見えない成果」も忘れずに記載することが重要です。

たいていは、これらの項目のうちにいくつか誤解のもとがあります。
明文化によって誤解をなくすことができれば、納得してプロジェクトに取り組めるはずです。

「チームビルディングのためには、目的と成果を明文化し、納得するまで食い下がる」。
ぜひお試しください。


第18回は、足立さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

足立さん 33歳/PM歴5年/社内システム部門のリーダー

私には女性の部下が一人いるのですが、まだ入社2年目で、手取り足取りとは言わないまでも、一通り指示がないと動いてくれません。

彼女主体で、彼女には難しい部分を私がサポートするつもりで仕事を計画してみても、なかなか思うようにできないようで、最後には8割がた私が作業をしてしまっていたということもしばしばです。

どうしたら、彼女にもっと多くの仕事を責任を持ってこなしてもらえるようになるのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、足立さんはプレイングマネジャーでありながら、新人教育係でもあるということで、けっこうなストレスを感じていることでしょう。

「部下がやるはずの仕事をいつの間にか自分がやっている」という事態の一番の原因は、自分と部下の作業区分が不明確なことです。

主担当とサポートということで、十分に区分けをしていると思っているかもしれませんが、プロジェクトマネジメントの原則からいうと、WBSの作成において「作業の責任分担ができるところまで詳細化する」ことが重要です。

たとえば、
「作業A…担当:部下/サポート:リーダー」
と設定するだけでは、部下の依存心を制限するには十分とは言えません。

作業Aの

計画: 部下
計画レビュー: リーダー
成果物作成: 部下
成果物レビュー: リーダー
手直し: 部下

というように作業を詳細化して、実作業はすべて部下の仕事であることを明確にするといいでしょう。

もう一つ大事な点として、部下が難しいと感じるであろう作業で、自分がやったほうがよっぽどうまくいくとしても、我慢して部下に割り当て、その成長を支援するという姿勢が大切です。

最初のうちはかえって時間がかかり、いらいらすることも多いでしょうが、きっと報われる日がきます。

「WBSは作業の責任分担が可能になるレベルまで詳細化する」。
ぜひお試しください。


第19回は、杉本さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

杉本さん 32歳/PM歴6年/IT企業のプロジェクトリーダー

私には部下が5人いるのですが、その中の1人の作業が計画上の締切に間に合わないことがよくあります。

また、彼は、遅れる可能性があることを報告してこないで、最後の最後まで粘るので、遅れる報告を受けたときには、いつも打つ手がごくごく限られてしまいます。

何度か注意したのですが、一向に改善されません。なにかいい手はないでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、リーダーとしては、作業の遅れは大変気にかかるでしょうし、報告が上がってこないことも、ストレスに感じていることでしょう。

でも、もしかしたら、そのメンバーこそが正直なメンバーではないですか。

不確実性の高いプロジェクトにおいては、「もっとも可能性の高い工期」を見積もって計画しているとすれば、実は計画通りにいく可能性よりも、遅れる可能性が多いことを十分に認識しているでしょうか。

計画よりも工期が早まる場合は、これ以上絶対に早くならないという限界があります。

一方、計画よりも工期が遅れる場合は、理論上は無限大まで遅れる可能性があります。
ただし現実的には、遅れる幅は、早まる幅よりやや大きいか2-3倍くらいでしょうか。

たとえば、作業A が不確実性の高い作業で、もっとも可能性の高い工期が10日だったとすると、

  • もっとも早くなる場合の工期(楽観値)は 8日
  • もっとも可能性の高い工期(最可能値)は 10日
  • もっとも遅い場合の工期(悲観値)は 16日

という見積もりになります。(実際の値は、業務の不確実性次第です。)

つまり、工期の可能性の分布は、早まりと遅れが等分な正規分布ではなく、遅れの幅のほうが広い、非対称な分布なのです。

したがって、不確実性の高い作業の工期を本当に最可能値で見積もった場合は、「計画通り」(上記の工期で8日、9日、10日)という報告より、「遅れそうだ」(上記の工期で11日、12日、13日、14日、15日、16日)という報告が多いのは自然です。

いつも「計画通り」と報告してくるメンバーは、実は見積もりに余裕を隠している可能性があります。

では、なぜメンバーは余裕を隠したり、遅れそうでも、ぎりぎりまで報告しないのでしょうか。
それはたいてい、遅れそうだと報告するとリーダー(あなた)が「なぜ、遅れるのか」と問いただすからです。
しかもときには怒気を含んだりしていませんか。

メンバーに最可能値での見積もりを求めるなら、リーダーは、遅れる可能性が高いことを覚悟しなければなりません。
不確実性が高い作業は、メンバーが努力していても特別な理由なしに遅れることがあります。

遅れる見込みの報告が早く欲しいなら、報告を受けても、問いただしたり、批判してはいけません。

報告を冷静に受け止めて、善後策を考えます。あなたが「遅れそう」という報告を冷静に受け止めることがメンバーに伝われば、メンバーも無理に報告を遅らせたり、余裕を隠したりしなくなります。

プロジェクトマネジメントでは、率直なコミュニケーションが生産性を上げます。

「不確実性の高い作業の工期は、最可能値より遅れる可能性が高いことを認識して報告を受ける」。
ぜひお試しください。


第20回は、西沢さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

西沢さん 37歳/PM歴10年/機械メーカーのプロジェクトマネジャー

お客様(発注者)との役割分担で、困っています。

お客様に依頼したレビューが忘れられていたり、レビューのための十分な人員を用意していなかったりで、スケジュールに支障をきたすこともしばしばです。
あまりしつこく念を押すのもお客様に失礼かとも思ってしまいます。

きちんとお客様に役割をこなしていただけるような方法はないものでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、お客様が期待通り作業をこなしてくださらないからといって、なかなか強くは言えないですね。

かといって、そのままスケジュールが遅れるとお客様からお叱りを受ける。
これはストレスですね。

これは、お客様の作業とそのスケジュールへの影響が見える化できていないことに問題があるのではないでしょうか。

この解決には、WBSとロジック・バー・チャートが有効活用できます。

WBSは、チーム内の作業だけを見える化すればいいものではありません。

お客様の作業もWBSに含めて管理することが必要です。

お客様の作業が明記されたWBSを、お客様と共有するのです。

WBSの作業ごとの担当者にお客様の名前を明記し、できれば、お客様の作業だけ目立つように色分けするといいでしょう。
もちろん、RAM(責任分担マトリックス)にもお客様の名前を明記します。

そして、お客様の作業もロジック・バー・チャートに表示するようにすれば、その遅れがスケジュール全体に及ぼす影響をすぐに見ることができます。

そうすれば、お客様も安易に作業を遅らせることはなくなるでしょう。

ロジック・バー・チャート
クリティカル・パスを表現できるスケジュール表示手法
RAM(責任分担マトリックス)
作業ごとの責任分担を明確にあらわす一覧表

「お客様の作業もWBSに含めて、ロジック・バー・チャートで管理する」。
ぜひお試しください。


第21回は、遠山さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

遠山さん 46歳/PM歴18年/機械メーカーの部門マネジャー

直接プロジェクトマネジメントに関わることではないかもしれませんが、相談させてください。

ご存知の通り、当社では、ここ2-3年はプロジェクトマネジメントに力を入れてきました。

いい成果を出して、顧客にも感謝してもらい、当然次期も継続してなにかしらの案件をご発注いただけるものと期待していたにもかかわらず、受注につながらないケースが増えているように感じています。

発注者側に確認しても、特に弊社に問題があったわけでもなく、発注者側に予算縮減などの動きがあったわけでもないようです。

なにか参考になる、うまい施策があれば教えていただけないでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、プロジェクトが上手く完了する以前に、プロジェクトそのものが受注できないと元も子もありません。

部門マネジャーのお立場とすれば、一番のストレスかもしれませんね。まずは顧客満足と顧客からの信頼が前提ですが、ここではプロジェクトマネジメントの観点から考えてみましょう。

遠山さんのところの部署では、プロジェクトあるいは業務終了ごとにプロジェクト終了報告書を作成していますでしょうか。

プロジェクト終了報告書の主要な項目は下記の4点です。

  1. 当初の計画
  2. 計画に対しての修正・変更
  3. 実績
  4. 改善すべき事項

継続受注のポイントはこの「4.改善すべき事項」にあります。

この項目は見方を変えると「改善提案書」であり、次期プロジェクトに向けてのプロポーザルになります。
「4.改善すべき事項」に次期プロジェクトの種を仕込んでおくのです。

私自身も以前に同じ失敗をした経験があります。

同僚と一緒に担当した案件で、同僚が担当した部分は継続受注につながったのに、私の担当分はそれっきりということがありました。

そのとき、その同僚になぜだろうかと相談したときに言われたことが、「お前の終了報告書は、完結型になっているからいけないんだ。継続型にしないと次につながらないぞ」でした。

次のプロジェクトの対象になる種(改善項目、追加開発項目など)を仕込んでおけばよかったのです。

例えば、ITシステムの開発プロジェクトであったなら、「××部分のデータ分析のサポートをする機能があれば現場の生産性が上がると感じます」といった具合です。

そのためには、プロジェクト遂行時から、顧客の担当者だけでなく、ユーザー部門と密なコミュニケーションをとっておくと、種を見つけやすいでしょう。

プロジェクトの終了にあたっては「次期につながる種を仕込んだ終了報告書を提出する」。
ぜひお試しください。


今回は、柿本さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

柿本さん 43歳/PM歴16年/精密機械メーカーのプロジェクトマネジャー

このところ、プロジェクトでのトラブルが続き、納期遅延やコスト超過が頻発しています。

そこで、トラブルの原因となるリスクを徹底してマネジメントしようとしているのですが、なかなかうまくいきません。

小さなリスクまで網羅しようとするときりがありませんし、小さなリスクと大きなリスクが混在していると、判断を誤りやすくなるように感じています。

どうしたら、もっとも効率的にリスク対策ができるのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、プロジェクトのリスクには大きいものも小さいものもあり、どこまで小さいリスクを洗い出し、マネジメントする必要があるのかには悩みますよね。

もしかして、リスクのマネジメントをプロジェクト全体で一括して行おうとしていませんか。

リスクのマネジメントおよびそれを具体化するリスク対応計画書は、「レベルを分けて複数作成する」とすっきりします。

そして、リスクのマネジメント対象は、大きい小さいで分類しようとするより、WBSに紐付けしたレベルで分類したほうが取り扱いやすくなります。

WBSのそれぞれの要素については、責任分担マトリックスなどを活用して、必ず責任者と担当者を割り当てます。

次にそれぞれの責任者(全体をまとめるプロジェクトマネジャーに対して、プロジェクトリーダーなどと呼ばれることが多いようです)は、自分の責任範囲についてブレークダウンしたWBSを作成しマネジメントします。

そのときに、プロジェクト全体のリスク対応計画書とは別に、自分の責任範囲固有のリスクに対するリスク対応計画書を作成します。

同じように担当者は、担当者として任された範囲固有のリスクに対するリスク対応計画書を作成するわけです。

そうすると、担当者が気にするべき、いわゆる小さいリスク(たとえば、その担当者の作業が計画より遅れるリスク、あるいは担当者に任されたはずの作業に技術的な問題が発生するリスクなど)は、担当者レベルのリスク対応計画書に記載され、その担当者によってマネジメントされます。

もしそのリスクが、担当者のレベルで収まらないリスクであれば、その上位マネジャーであるプロジェクトリーダーのレベルに持ち上げられ、プロジェクトリーダーのリスク対応計画書に追加されてマネジメントされます。

同じようにプロジェクト全体のリスク対応計画書には、全体のレベルでのリスクと、プロジェクトリーダーのレベルで収まらないリスクとが記載されてマネジメントされることになります。

プロジェクトに大きな影響を与える大きなリスクは上位のリスク対応計画書に、比較的影響の小さいリスクは下位のリスク対応計画書に記載され、それぞれのレベルでマネジメントされるようになります。

そうすれば、自然と扱うリスクの大きさがリスク対応計画書ごとそろって、効率的にマネジメントできるようになります。

「プロジェクトマネジャー、プロジェクトリーダー、担当者それぞれが作成するリスク対応計画書で、それぞれのレベルに対応したリスクをマネジメントすること」をぜひお試しください。


今回は、中村さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

中村さん 33歳/PM歴7年/日用品の製品開発プロジェクトのリーダー

今回任された製品の開発が、いままでに実績のないもので、過去の事例がまったく役に立ちません。

スケジュールやコスト計画はおろか、WBSすら満足にかけない状況です。

こんな状態で、スケジュールやコストを計画しても、とても守れる気がしません。

こんな状況でのプロジェクトマネジメントは、どのように進めたらいいのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、「プロジェクトマネジメントはまず計画から」といわれていますが、計画そのものができないとなれば、不安になりますね。

ましてや、実績のないプロジェクトですから不確実性も高く、不安が募ることと思います。

このような実績のないプロジェクトでは、最初に詳細な計画をたてようとしても無理なだけでなく、無駄であることを承知しなければなりません。

わからない内容で無理やり計画しても、その計画はきっと段階を経て、次々に変更されていく運命にあります。

このようなときには、「ローリング・ウェーブ計画法」という手法を使います。

この手法では、すぐに取り掛かる内容については詳細に計画しますが、先の計画については、わかる範囲でおおざっぱな計画にとどめ、プロジェクト進行によって段階的に詳細化していくというものです。

「ローリング・ウェーブ計画法」の名称は、岸から見た遠くの沖に見える波は大きくうねっているものの、岸に近づくにつれて波は細かくなり、足元にくるころにはさざ波になっているという現象にたとえて、「遠くのものは大雑把に、近くのものは詳細に」を示しています。

この手法を用いるときのポイントは、「フェーズ移行」をしっかり管理することです。

「フェーズ移行」とは、最初の「調査・検討フェーズ」が終わって、次の「設計フェーズ」に移ること、あるいは「設計フェーズ」が終わって、さらに次の「開発フェーズ」に移ることのように、ひとつのフェーズから次のフェーズへ進むことをさします。

「フェーズ移行」では、新たに入手した情報をもとに、次フェーズの立ち上げ、そして「計画の見直しと詳細化」を確実に行います。

次フェーズの立ち上げでは、新たに明らかになった情報から「本当に次フェーズを開始しても良いかどうか」の判断を行います。

たとえば、開発には当初1000万円の予算を見込んでいたとして、「設計フェーズ」が終わってみると、実際には2000万円が必要だとわかったとしましょう。

そのとき、「2000万円かかっても重要な製品だから開発しよう」という判断もあれば、「2000万円もかかるなら開発を中止して、ほかに予算を回そう」という判断もあるわけです。

次フェーズが立ち上がったら、「計画の見直しと詳細化」を行います。

少なくともこれから実行するフェーズの計画は、実行に耐えられるだけの詳細な計画になっている必要があります。

このようにして、各フェーズは、そこまでに得られた情報によって、都度詳細化され、実行されていきます。

いかがでしょうか?よくわからないプロジェクトでは、無理にすべての計画を立てる必要はありません。

「実績のないプロジェクトでは、ローリング・ウェーブ計画法を用いて、フェーズ移行に注意する」をぜひお試しください。


今回は、安部さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

安部さん 38歳/PM歴12年/物流プロジェクトのマネジャー

プロジェクトの内容が明らかになって、いざメンバーを集めようとしても、組織に必要なスキルをもった人材が不足していて、スキル不足の人材を使わざるを得ません。

スキル不足のメンバーを指導する人材がほかにいてくれたらいいのですが、小さなプロジェクトなので、そのような人材もなく、結局私自身が指導にまわることになり、私の業務にも支障がでるようなありさまです。

どうしたらいいのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、必要なスキルをもったメンバーが集まらないと、品質や納期も危うくなり、その分をPMがカバーしようとしたら、その負担は相当なものになりますね。

ところで、スキル不足のメンバーの教育は、PMにとって余計な仕事だと思っていませんか。

まずは、メンバーのスキルアップを考えるのもPMの仕事だと認めることです。

人材教育は、長い眼で見て、組織が取り組むべき課題ですが、実際のところ、常にいずれかのプロジェクトに参加しているメンバーにしてみたら、スキルアップをする機会がなかなかないのが現状です。

そうなると、必要なスキルを身につけてからプロジェクトに参加してもらうこと自体無理があります。

メンバーのスキルアップもPMの標準的な役目でもあるので、プロジェクトの計画は、必要なスキルアップのためのトレーニングもプロジェクトのスコープ(作業範囲)に含めて考えます。

トレーニングを受ける時間や提供する時間も、スケジュール、および工数に組み込んで計画を見直す必要があります。

その上で、納期、品質、予算に問題があれば、通常のプロジェクトマネジメントの課題として取り組みます。

「メンバーのスキルアップもプロジェクトマネジャーの仕事」と認識して取り組みましょう。


今回は、梁瀬さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

梁瀬さん 36歳/PM歴12年/システム開発プロジェクトのマネジャー

開発終了まではだいたいスケジュールどおり進んでいても、最後のテスト段階で、予想外のバグが出てきて、納期に追われることがしょっちゅうです。

設計のレビューをしっかりしたり、開発部品のモジュール化を進めるなど、品質向上の努力をしているつもりですが、納期に追われる状況は一向に改善されません。

どうしたらよろしいのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、プロジェクトの最後の段階でいきなり想定外のバグ(品質上の欠陥)では、対応も大変ですね。

たしかに上流を含めて品質を向上させて、テストにかかる時間を短縮するのは正しい対応です。

しかし、最後にドタバタになると肝心の品質も確保できなくなりそうですし、場合によっては納期遅延なんてことも考えられます。

「納期に追われることがしょっちゅうです」というのは、実はマネジメント上の問題でもあるのです。

想定外のことがしょっちゅう起きるというのは、明らかに想定が甘すぎるのです。

これは、発生頻度の高いリスクとしてマネジメントする必要があります。

対策としては、テスト工程の見積もりの精度を向上させることも必要ですが、もうひとつスケジュール・バッファを設ける(スケジュールの日程に予備を設ける)ことが効果的です。

具体的には想定される適正人員より1-2割多めのメンバー(協力会社含む)を割り当てます。

そうすれば、早めに作業を進めることができ、想定外のバグに対しても対応する時間ができるはずです。

もし、想定どおりのバグだった場合に多めのメンバーがコスト増につながることを危惧するのであれば、バッファの期間をそっくり残して、早めにメンバーを解放してください。

「想定外がしょっちゅう起きるのは発生頻度の高いリスク」と認識して取り組みましょう。


今回は、西村さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

西村さん 31歳/PM歴6年/メーカーの製品開発プロジェクトのグループリーダー

私は、最近、プロジェクトマネジメントを学んで、現場での適用を試行錯誤で行っているところです。

なかでも苦労しているのがリスクマネジメントです。

「できるだけ多くのリスクを識別する(リスクを洗い出す)」というのがポイントのようですが、さしあたってアクションがいらないリスクまで挙げていったらきりがないように感じます。

アクションが不要なリスクを識別することは無駄ではないでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、リスクマネジメントを始めたばかりでは、その範囲にとまどうでしょう。

さしあたってアクションがいらないというのは、危険度が識別の段階では許容値(リスクリミットと呼びます)を下回っている状態だと思います。

このようなリスクを識別して登録簿に登録することの意義は、リスクの監視・コントロールの対象にするということです。

実際、失敗したプロジェクトを調べてみると、想定外のリスクで失敗したケースが意外と少ないことがわかります。

多くの失敗は、「想定していたけど、まず起こらないと思った」、あるいは「起きてもたいしたことがないと思った」と表現されるリスクによって引き起こされています。

つまり、許容値を下回っていたリスクが失敗の要因になることが多いのです。

リスクマネジメントのポイントは、識別段階では許容値を下回っていても、プロジェクトの遂行の中で許容値を超えるリスクに対して事前に予防することです。

例えば、A社という業者に部品の発注を予定していたとしましょう。A社は人気の業者で、忙しいと引き受けてくれないリスクがあります。

その場合は、B社に発注すれば良いと考えています。B社には、すでに別の部品を発注していますが、こちらは納期に余裕があるので、A社の業務を振り替えても支障がないと考えていました。

ところが、今日になって、B社に発注している部品の納期を前倒しする必要が生じました。納期に余裕があったはずのB社の業務量が超過気味となったのです。

もし、「A社が引き受けてくれないかもしれない」というリスクがリスク登録簿になければこれで終わりです。

いざ、A社にに発注するときになって引き受けてくれないとわかって、はじめてB社も容量いっぱいで無理だと分かり大慌てするかもしれません。

もし、このリスクが登録簿にあれば、リスクの担当者がB社の納期が変わった時点でリスクの条件が変わったことに気付きます。

そして、その段階で手を打てば、リスクを予防(リスクを許容値以下に抑える)できる可能性は大いにあります。

これが、識別段階で許容を下回っているリスクを登録することの効果です。

したがって、さしあたっては許容内にあるリスクでも、「監視の必要のあるリスク」は登録簿に載せることが重要です。

「許容内のリスクも識別することでプロジェクトを守ることができる」

是非ご留意ください。


今回は、島崎さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

島崎さん 32歳/PM歴5年/システム開発会社のチームリーダー

私は、システムメンテナンスのプロジェクトリーダーです。私の業務は継続的で切れ目がなく、プロジェクトマネジメントでいう「終結」の機会がありません。

また、「終結」を実施して教訓を残したとしても、業務に固有の内容になり、将来どのように役立つかがわかりません。

せっかく習得したプロジェクトマネジメントを活かすためにも、「終結」について具体的なアドバイスをお願いします。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、プロジェクトマネジメントでは、成果物を納めたあとの「終結」が教訓を蓄積して組織の力を蓄える上で非常に重要だと説かれていますが、現実とは乖離しているように感じられるのですね。

まず、「終結」はプロジェクトがすべて終わったときにだけ行うものではありません。

すべて終わってから行おうとするなら、プロジェクトの初期の記憶はかなり曖昧になってしまうでしょう。

また、フェーズが変わる(プロジェクトが新しい段階に進む)と、関係者も入れ替わって、「終結」に必要な教訓が得られなくなります。

したがって、「終結」はプロジェクトの終わりだけでなく、フェーズの終了ごとに行うことが効果的です。

島崎さんの場合、フェーズがはっきりしないようなので、半年に一度というように期限を区切って、中間点ごとにその間の教訓をまとめるようにしたらいかがでしょうか。

また、現段階で将来の有用性を予測すること自体難しいですし、有用と思われるものだけを残すことも教訓としては不完全になりがちです。

例えば、私が以前コンピュータメーカーに勤めていたころ、システムのトラブルがあって、苦労して対応したのですが、のちになって、そのときの課題管理の手法が役に立ったことがあります。

そのシステムのトラブル自体は特殊な固有の内容でしたが、管理手法が後々社内で標準として用いられるようになりました。

「終結」の段階では、トラブルの内容に注目していたので、課題管理の手法の新しさには気が付いていなかったのです。

もし、このとき、有用と思われるものだけ残そうとしていたら、この手法が教訓として残されたかどうか疑問です。

終結の段階では、将来に対する評価はさておき、プロジェクト、あるいはフェーズを終えた段階で感じる「改善すべき点」と「有効だと感じた試み」を残します。

もし、終結の作業自体を負担に感じるのであれば、「単にレビューミーティングを実施してその議事録を残す」といった、スモールスタートでも有効です。

「終結は中間点も含めて、その時点の教訓を残すもの」と認識して取り組みましょう。


今回は、原田さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

原田さん 39歳/PM歴11年/流通関連のプロジェクトマネジャー

プロジェクトの成功にはトップの支援(ヒト、モノ、カネ)が不可欠であると思うのですが、私のプロジェクトのトップ(スポンサー)は、あまり協力的ではありません。

本当に支援がないと困るので協力を依頼するのですが、「そこをなんとかするのがプロジェクトマネジャーの務めだろう」というばかりで、期待通りの支援をしてくれたためしがありません。

「プロジェクトが成功しないと困るのはお互いのはずなのに…なぜ?」と思ってしまいます。

どうしたら、必要な支援を得られるようになるのでしょうか。何かコツがあれば教えて下さい。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、困ったときに必要な支援を得られないのでは、プロジェクトマネジャーとしてつらいですよね。

トップの支援を得るためには、2つの視点が必要です。

  1. 支援の必要性を認識してもらうこと
  2. マネジャーとして信頼されること

支援の必要性を訴えるのは当然ですが、さらに訴えに真実性をもたせ、トップの行動を促すためには、マネジャー自身がトップから信頼され、好かれていることが重要です。

これら2つを実現するための一番のツールはコミュニケーションです。

つまり、定期的にトップに対して、簡潔な進捗報告をする必要があります。

普段は黙っていて、困ったときだけいきなり支援を求められても、トップの方も心の準備や支援の準備ができていないことが多いのです。

支援を必要とするかもしれない案件は、プロジェクトマネジメントではリスクとして取り扱われます。

進捗報告の中では、プロジェクトの進捗状況だけでなく、必ずリスクの状態と、トップの支援の有無を入れるようにします。

最初の計画時だけリスクを示しても、その後何も言ってこないと、トップの方も「何も問題がないのだろう」と思い込んでしまいます。

そこで、定期的な進捗の報告のなかで、リスクがどうなっているのか、支援が必要になりそうなのかを伝えられていれば、トップの方も準備することができます。

「リスクです、リスクです、リスクです」と日頃から報告されている案件を無視していれば、何かあったときにトップとしての責任を免れないという気持ちにもなります。

もちろん、手当たり次第にトップに上げるのではなく、プロジェクトマネジャーとしてできる限りのリスク対策をし、それを報告しておきます。

それで、ここぞというときに、支援の要請をするのであれば、トップの方も「やることはやった上での要請なんだな」と納得できます。

また、定期的なコミュニケーションはそれだけでも信頼感および好感度のアップにつながります。

たとえば、まったくの他人であったとしても、毎朝「おはようございます」とにこやかに声をかけてくれる人がいたら、いつしかその人がいい人に思えてきませんか?

「トップと定期的にコミュニケーションをとれば、必要な支援が得られる可能性が高くなる」と信じて、マネジメントに励みましょう。


今回は、川上さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

川上さん 36歳/PM歴8年/メーカーのプロジェクトリーダー

私が参加しているプロジェクトは、そこそこの規模の製品開発で、社内のいくつかの部門が協力して実施しています。

ところが、部門間の協力体制が不十分で、とくに情報のフィードバックがなくて困っています。

他部門で必要なはずの情報を提供しているのですが、うんともすんとも言ってこないので、本当にその情報が必要だったのか、あるいは適切な情報だったのか不安になります。

逆にこちらが必要な情報もなかなか送ってこなくて、催促してようやく出てくるものの、情報の欠落や遅延がまま見られます。

どうやったら、他部門からの情報のフィードバックが期待通りに手に入るようになるのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、プロジェクトで情報はキーになりますから、必要な情報およびそのフィードバックが得られないというのは、大変なストレスになりますね。

ところで、あなたは「コミュニケーションをマネジメントする」という意識はありますか?
実は、あなたからの「コミュニケーション・マネジメント」が不足しているために、相手からの情報も不足している可能性があります。

プロジェクトにおけるコミュニケーションのマネジメントの流れを整理すると次のようになります。

  • ステップ1 ステークホルダーの特定
  • ステップ2 ステークホルダーのニーズ把握
  • ステップ3 ステークホルダーとのコミュニケーション計画の共有
  • ステップ4 コミュニケーション計画の実行と変更管理
・ステップ1

ステップ1は、コミュニケーションの相手となるステークホルダーが誰なのかを明らかにすることです。
今回は、特定の部門とのやりとりで問題が生じているわけですから、ステークホルダーの特定はできていると考えられます。

・ステップ2

最初の課題はステップ2にあると思われます。
その部門の担当者との間でお互いのコミュニケーション・ニーズ(どんな情報を、どんなタイミングで、どんな方法で必要とするのか)が明らかになっていないため、情報の遅延や欠落が起きるのです。
まずは、徹底してお互いのニーズを明らかにして共有してください。

・ステップ3

次にそのニーズをどのようにして満足させるのかをコミュニケーション・マネジメント計画書に記述し見える化します。
コミュニケーション・マネジメント計画書では、それぞれの情報について、その内容、発信者、受信者、伝達方法、タイミングを明確にした一覧表を作成します。

例えば

  • 情報名・・・関連作業の進捗
  • 詳細・・・・作業の実績開始日、終了予定日、リスク
  • 様式・・・・Excelファイル(フォームNo3.2)
  • 発信者・・・XX部門 XXX(氏名)
  • 受信者・・・YY部門 YYY(氏名)
  • 方法・・・・電子メール
  • タイミング・毎週金曜日の18時まで

そして、その一覧表をお互いに確認して、不都合があれば訂正します。
このように計画段階でコミュニケーションの方法についてお互いの合意を取ることが重要です。

・ステップ4

あとは、確実にその計画書に基づいて情報の提供を行います。
そして定期的に、情報提供がうまくいっているかの確認を行い、不都合があればその都度訂正していきます。
情報の提供とその確認・変更の管理が上手くいっていれば、コミュニケーションは円滑に進むはずです。

「コミュニケーション・マネジメント計画書を活用してコミュニケーションを円滑にする」…ぜひお試しください。


今回は、村田さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

村田さん 34歳/PM歴7年/メーカーのプロジェクトリーダー

私が参加しているプロジェクトでは、新しい要素技術の開発を行っています。
これは不確実性の高いプロジェクトだったのですが、通常は予定期間の半分、約半年も経つと大体の状況が見えてきます。ところが、この案件は当初の目論見に反して、まったくめどが立っていないのです。

しかも、プロジェクトの終了条件が、「成果物ができるまで」ということになっているので、当初の目標期限はおろか、いつになったらめどが立つかすら分からない状況で、プロジェクトが継続しています。

あまりにも進捗が見えないので、不毛な検討が延々と続いて、関係するメンバーのモチベーションもすっかり下がってしまいました。
もう、プロジェクトを中止して、他の案件に資源を割り当てたほうが良いのではないかと思うのですが、上司は継続を指示するのです。

どうしたら、上司にプロジェクトの中止を進言できるのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、先の見えないプロジェクトをただただ検討し続けるのは、大変なストレスになりますね。
いただいた内容からは、次の2つの問題が見えてきます。

1)上司との目的の共有
2)フェーズ移行の管理

1)上司との目的の共有

村田さんが、当然中止すべきと考えているプロジェクトに対して、上司が継続を指示するには、それ相応の理由があるはずです。

上司は、メンバーよりも多くの情報を持っているはずなので、村田さんがご存じない情報を基に継続の判断をしている可能性があります。まずは、上司に継続の理由を尋ね、「プロジェクト憲章」(※)という形で文章化してみるとすっきりするかもしれません。

上司は村田さんが意識していなかった副次的効果に眼をつけていたり、あるいは成功確率が非常に小さいことを承知でチャレンジしようとしているのかもしれません。

※プロジェクト憲章とは…
 プロジェクトのビジネス背景・目的、期待する成果を現したもの

2)フェーズ移行の管理

不確実性の高いプロジェクトでは、最初から詳細な計画を立てることは困難です。
この場合は、プロジェクトを進めながら先の計画を立てていくといった計画手法が採られます。

ここで重要なのは「フェーズ移行の管理」です。
不確実性の高いプロジェクトは、いくつかの段階(フェーズ)に分けると管理しやすくなります。

特に成功確率が小さく、不確実性の高いプロジェクトのフェーズの例として、製薬会社における新薬開発プロジェクトのフェーズを紹介します。

  1. 概念
  2. リード化合物探索
  3. 非臨床試験
  4. 臨床試験(1)
  5. 臨床試験(2)
  6. 臨床試験(3)
  7. 申請承認

フェーズが進むたびに、検討に多くの時間と費用がかかるので、中止にすべきプロジェクトは早い段階で中止にする必要があります。例えば、「3.非臨床試験」までのフェーズはスムーズに進んだとしても、「4.臨床試験」(新薬開発などのために、人体を使った実験)以降ではさらに時間と費用を要するので、一定の基準が満たされないようであれば、即中止にすべきです。

つまり、フェーズ移行基準(どのような条件を満たすことが、次のフェーズに移行する条件となるか)が、プロジェクトを継続するか否かの明確な判断材料となります。

「プロジェクト憲章を作成し、上司と継続理由(背景・目的)の共有をするとともに、フェーズ移行の管理をしっかり行う」…ぜひお試しください。


今回は、北村さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

北村さん 36歳/PM歴8年/電機メーカーの主任

私が参加しているプロジェクトでは、複数のグループが関係しています。

一応WBSを作り、役割分担をして仕事をしているはずが、どうしてもグレーゾーンが残ってしまいます。

実行されていなかった作業について問い合わせると、「これは、うちのスコープではないから」という返答が返ってきます。

もっと細かく作業を定義して、役割分担表をつくればいいのかもしれませんが、どうしてもポテンヒットが生まれてしまいます。どうしたら、ポテンヒットをなくせるのでしょうか。

※ポテンヒット:野球用語で、打ち上げられた打球が野手と野手の中間にポトリと落ちるヒットのこと

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、せっかくWBSと役割分担表を作成しても、実際の作業が実行されていないと意味がありませんね。

たしかに役割分担をはっきりさせるためには、WBSを可能なレベルまで詳細化して、役割分担を明らかにすることが原則です。

しかし、すべてを明らかにすることは、マネジメントの手間が過大になり、かえって効率を下げるかもしれません。

それでは、問題の本質はどこにあるのでしょうか?役割分担の不明瞭さだけでしょうか?実は「これは、うちのスコープではないから」という姿勢こそが問題なのです。

実際の野球でのポテンヒットの予防策を考えてみるといいと思います。

ポテンヒットを防ぐには「声かけ」が重要ですよね。「オーライ!オーライ!」「オーイ、頼む!」などのコミュニケーションが取りこぼしを防ぐわけです。

同じことがプロジェクトについてもいえます。

グレーに見えたら、すぐに声かけ(コミュニケーション)をすれば、問題にならないはずです。

そのためには、グループが違っても、同じ成果物を作るチームメイトだという意識が必要です。

プロジェクトマネジメントのプロセスとしては、しっかりチームビルディングを行うことです。

「一緒にいいものを作ろう」「お互いにカバーしよう」という雰囲気になっていれば、ポテンヒットは起こりません。

「チームビルディングでポテンヒットを防ぐ」ぜひお試しください。


今回は、長野さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

長野さん 32歳/PM歴7年/通信機メーカーのチームリーダー

私は新製品開発プロジェクトの一部を担うチームのリーダーをしています。

プロジェクトにおいて、計画が重要であることは、よく承知しているのですが、スケジュールの計画がうまくできないのです。

全体のWBSは作成されていて、そのワークパッケージ(WBSを構成する要素で複数の作業を含む)のひとつを任されているのですが、ワークパッケージを構成する「アクティビティ(作業)の見積もり精度」が低いのです。

というのも新製品の開発は、多くの不確実性が伴い、わからない要素が多いので、どうしても工数が精度良く見積もれないのです。

一方で製品のマーケットリリースはできるだけ早めたいので、その結果、ぎりぎりの見積もりになって、遅延に次ぐ遅延でリスケジュール(スケジュールの再設定)の連続になってしまいます。

リスケジュールの多発は、チームの信用に関わりますし、チームメンバーのモチベーションにも影響します。

どうしたら計画段階での「アクティビティの見積もり精度」を向上させることができるのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、できるだけリスケジュールの起こらないような実効性の高い計画を立てたくても、その元になる「アクティビティの見積もり精度」の不確実性に邪魔をされてしまうのですね。

これでは、計画を守ろうとするメンバーのみなさんにもストレスが溜まるのも無理はありません。

たしかに見積もり精度を上げることは重要ですが、不確実性の高いプロジェクトの場合、少し対応を変える必要があります。

不確実性が高いということは、あとからあとから新しい情報や変更要求が出てくることになります。

このような場合は精度の高い見積もりを行っても、計画変更が生じてしまって、せっかくの精度が無駄になることがほとんどです。

不確実性の高いプロジェクトでは1回の見積もりで計画を固定するのではなく、プロジェクトの進捗に合わせて、新しい情報をもとに「再見積もり」をかけることがポイントになります。

同時に、再見積もりの結果をもとに、計画の見直しを随時行うのです。

「プロジェクトの計画は守るもの」と思い込んでいると、守れないときに苦痛を感じて、モチベーションが下がります。

不確実性の高いプロジェクトを遂行するときの心構えとしては、「計画は変わるもの」「見積もりは繰り返すもの」と思うことが重要です。

そうすれば、計画の変更や、リスケジュールに直面してもストレスを受け流すことができます。メンバーにも「計画は変わる」ということをあらかじめアナウンスしておくとよいでしょう。

再見積もりの実施、および計画の見直しのタイミングとしては、フェーズ移行時が一般的です。

新しいフェーズに入ると、新しい情報とともに条件も変わっている可能性が高いので、必然的に見直しが必要になります。

また、より詳細な情報が入ってきますので、その情報を基に、さらに詳細な見積もりや計画も可能になります。

そうやって、徐々に見積もりと計画の精度を上げていけばいいのです。

「不確実性の高いプロジェクトの見積もり精度は徐々に上げていく」、ぜひお試しください。


今回は、飯沼さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

飯沼さん 37歳/電機メーカーの総務部係

私が所属する総務部のようなスタッフ部門でも、年度初めに「職場環境の改善」といった年度目標を掲げて、ワーキング・グループを立ち上げるのですが、達成度の数値化が難しいのが悩みです。

毎年、年度終了時のレビューも「部内の雰囲気が以前より明るくなった」といった定性的評価(数値化できない評価)だけで、どれだけ達成できたのかがわかりません。

進め方も、具体的なアクションが取れないままに、日常の業務に紛れて時間だけが過ぎていき、年度の最後に辻褄あわせをしているようで満足感が得られません。

目に見える達成感が得られる何かいい方法はありませんか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、本来の業務とは別に設定されるワーキング・グループの管理は、なおざりになりやすく、悩ましいものですね。

ワーキング・グループの活動も、プロジェクトの特徴である、有期性(始めと終わりが明確であること:年度の終わりが活動の終わり)と独自性(必ず独自の成果物があること:職場環境の改善)を満たしているので、プロジェクトとしてマネジメントすることができます。

本件はまず、「プロジェクトの立ち上げ」に問題があるように思えます。「プロジェクトの立ち上げ」では、そのプロジェクトの「ビジネスニーズと目標・成果物」を明らかにする必要があります。

例えば、ビジネス・ニーズの出所が総務部長で、そのニーズが「部門の生産性が低いのを改善したい」ということであれば、部長にヒアリングして、期待される成果物を明確にします。

生産性の低さの根拠として、残業時間の多さが気になっていることがわかれば、「残業時間の低減」という成果物が出てきます。そうすれば、残業時間を1年間でどの程度低減するのかという目標値も自ずと設定することができます。

もし、対象が残業時間のように定量化(数値化)できるものに絞れない場合は、定性的評価を定量化することも手です。

例えば「雰囲気」についていえば、総務部員10人に対して、5段階でアンケートをとるといったことも、定量化の手法です。その場合は、「評価の平均点を現状の3.0から3.5以上に上げる」といった目標値が設定されます。

次に、進め方については「進捗管理」が必要です。マイルストーン(中間地点での目標値をもった期限)を設けて、その達成度を評価してください。

例えば、
 マイルストーン@:6月までに残業の原因を調査する
 マイルストーンA:9月までに対策案を作成する
 マイルストーンB:12月の時点での中間評価を行う …などです。

「達成感を得られる年度目標にするためには、成果物を明確化し、マイルストーンによる進捗管理をすること」、ぜひお試しください。


今回は、山形さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

山形さん 28歳/ITプロジェクトのチームリーダー

私は、プロジェクトマネジャーのTさんのもとで、システムの開発をしています。

Tさんはリスクに対してとてもうるさく、プロジェクトの着手段階でしっかりリスクを洗い出すことの重要性を強調しています。

ところが、十数個のリスクを洗い出し、対応まで考えて一覧表にしてみせると、「本当にこれだけか、まだ見逃しているリスクがあるんじゃないか」と言われます。

さらに、小さなリスクまで洗い出して表に加え、リスクによってはさしあたって対応が不要に見えるものもあるので、対応欄を空白にして提出すると、「このリスクの対応はどうなっているのだ」と問い詰められます。

私が、「このリスクは、さしあたっては対応の必要を感じませんので、現段階では受容します」と答えると、「リスクであることがわかっていて、何もしないということはありえないだろう」と追及される始末です。

このように、リスクを受容することが一切認められないのですが、これっておかしくないですか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、慎重なTマネジャーから見ると、小さなリスクでも何もしないとなると心配になるのですね。

まずは、リスクマネジメントの目的を共有することが肝心だと思われます。

リスクマネジメントの目的はなんでしょうか。リスクをなくすことでしょうか。
いえ、リスクはなくすことはできません。

リスクマネジメントの目的は、「リスクを許容以内に収めること」なのです。

そのためには、「リスクの危険度」を定量化することが必要です。

「リスクの危険度」は、リスクがどのくらいの確率で発生するのかという「リスクの発生確率」と、リスクが発生するとプロジェクトにどのくらいの影響があるのかという「リスクの影響度」をもとに定量化します。

例として、リスクの発生確率と影響度をそれぞれ「大」「中」「小」の3段階で定量化することにします。

対象とするリスクは、代表的なものとして、品質リスク、コストリスク、スケジュールリスク、スコープリスクがあります。

ここでは、わかりやすいものとして、スケジュールリスクを取り上げます。

まず、発生確率については、たとえば

  • ○発生確率が1%以下のリスクを「発生確率:小」
  • ○発生確率が10%以下のリスクを「発生確率:中」
  • ○発生確率が10%を超えるリスクを「発生確率:大」

と定義します。

また、リスクの影響度も、

  • ○2−3日以内の遅れにつながるリスクを「影響度:小」
  • ○2週間以内の遅れにつながるリスクを「影響度:中」
  • ○2週間を超える遅れにつながるリスクを「影響度:大」

と定義します。

リスクの発生確率、リスクの影響度をどう定義するかはプロジェクトごとに設定する必要があります。

次に、「危険度」を定義します。

  • ○「危険度:大」=「影響度:大」×「発生確率:中or大」
  • ○「危険度:小」=「影響度:小」×「発生確率:小or中」
  • ○残りの組み合わせ=「危険度:中」

危険度が定義できたら、目標とする「リスクの許容度」を設定します。

もし、リスクの許容度が「小」であれば、すべてのリスクの危険度を「小」にする必要があります。

これは裏を返せば、危険度が「小」と判断されたリスクは、受容可能ということです。

たとえば、ベテランメンバーのAさんがインフルエンザにかかるリスクを「影響度:中」×「発生確率:中」=「危険度:中」とします。

これは、許容度を超えるため受容できません。予防接種を受ける等の対策が必要でしょう。

いっぽう、Aさんの仕事をサポートするBさんがインフルエンザにかかるリスクは「影響度:小」×「発生確率:中」=「危険度:小」とします。

こちらは、危険度が許容度内に収まるため、受容可能となるわけです。

リスクを定量化して、リスクの危険度が許容度に収まっていることを説明すれば、Tマネジャーも受容することを納得してくれるでしょう。

「リスクを定量化してリスクの受容の可否を判断する」
是非お試しください。


今回は、里田さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

里田さん 34歳/ITプロジェクトのプロジェクトマネジャー

うちの会社では、ITのシステムを受注して開発したものを納品する仕事をしています。

自分たちでは上流工程を実施して、実際の開発作業はパートナー企業に委託しています。問題は、そのパートナー企業のC社です。

うちで扱ってるシステムは特殊なものが多く、技術的に経験のある特定の企業に頼りがちです。

C社もそのうちの1つなのですが、一つ大きな問題があります。

納期にルーズなのです。

最初のうちは、余裕を持っていたはずのスケジュールが、いつの間にか納期遅延必至の状態になるのです。

途中で、進捗報告を受けている範囲では、毎回「大丈夫です」という回答なのですが、最後になって納期に間に合わなくなってしまった…ということも度々です。

その都度、お客様に謝罪したり、納期遅延による後始末が大変です。

パートナー企業の進捗をしっかり管理するにはどうしたらいいのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、ふつうなら納期遅延が多発している企業とはおつきあいをしないのも一つの方法ですが、特殊な技術ゆえに代わりがいないのですね。それはお困りでしょう。

お伺いした範囲で見えることは、委託作業自体が、不確実性をはらんでいて、不確実性とスケジュールの関係、状況がつかめていないことが原因のように思えます。

このようなケースでの解決策は、スケジュールと不確実性(リスク)の見える化と共有です。

まず、C社に対して、スケジュールとリスクの見える化を強く求めましょう。

そして、定期的に打ち合わせをし、それらのスケジュールとリスクを共有して、C社とともに対応していきます。

以下に手順を示します。

1.スケジュールの見える化

リスクがスケジュールにどう影響するかを明らかにする必要があります。

そのためには、リスクに伴う作業の遅れが、他の作業と納期にどう影響するかを見える化するスケジュール表現が必要です。

その際に、「ロジック・バー・チャート」というスケジュール作図ツールが便利です。

「ガント・チャート」あるいは「バー・チャート」と呼ばれる一般的な作図ツールでも、作業ごとの開始日と終了日、期間が示されていますが、「ロジック・バー・チャート」では、さらに作業ごとの関連を図示します。

ロジック・バー・チャートによって、先行作業が遅れるとどのくらい後続作業が遅れるのか、さらには納期にどのくらいの遅れが影響するのかまで見える化できます。

2.リスクの見える化

プロジェクトでは、不確実性はリスクとしてマネジメントします。

それぞれの作業がどれだけ遅れるリスクがあるのか、あるいは更に追加される可能性のある作業はないのかをリストアップします。

まず、リスクへの対策を見える化してリストアップし、このリスクの対策をスケジュールに反映させます。

そして、プロジェクトの進捗に合わせて、リスクの見直しを行い、常に最新の状態に保ちます。

3.スケジュールとリスクの共有

見える化されたリスクと、それを反映したスケジュールをC社と共有できていれば、「納期遅延必至」という状況に追い込まれる前に状況把握ができて、必要な対策がとれるようになります。

ここで注意しなければならないのは、リスクをすべてC社の責任にしないことです。

もし、C社がリスクを明らかにしたとしても、里田さんの支援を得ることができず、その対策をすべてC社が引き受けざるを得ないとすれば、C社もリスクをしっかり共有しようとはしなくなるでしょう。

むしろ、うるさく言われないために隠そうとすらしかねません。

里田さんに必要なのは、共有したリスクはC社とともに解決するという姿勢です。

たとえば、要件で不明な点がリスクとしてあがっていれば、里田さんがお客様との要件確定のための協議を行う必要があります。

もし、お客様都合で確定ができないなら、その分の作業を納期後に再設定するなども考えられます。

パートナー企業の進捗をつかむには、
「企業のスケジュールとリスクを見える化し、共有する。そして、ともに対応する」
をぜひお試しください。


今回は、西村さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

西村さん 31歳/社内業務改善プロジェクトのリーダー

うちの部署では、本来の開発業務とは別に、部署の年度目標を設定して、毎月進捗を管理することになっています。

私は、部署のコミュニケーション問題を改善するプロジェクトのリーダーなのですが、メンバーの人たちから、必要な意見が出てこなくて、進捗も滞りがちです。

メンバーは、私よりも年長の方も含めて5人いるのですが、意見を求めても、全然出てきません。

個別に相談するとそれなりに意見がもらえるので、メンバー自身が意見を持っていないわけではないようです。

なお、メンバーの中には、客先で常駐しているメンバーもいるため、意見の収集はメールで実施することが多いです。

メンバーから意見を一通り引き出すにはどうしたらいいのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、意見を求めても、適切な反応がないのであれば、リーダーもモチベーションが下がりますよね。

原因としては、プロジェクトチームのチームビルディングが不足している可能性もありますが、ここでは別のケースを考えてみます。

実は、私も最近同じような体験をしたことがあります。ただし、その時は私がメンバーの立場でした。

私共コンサルタント同士も、必要に応じてアイデアの交換をします。

客先からの問い合わせに対して、自分の意見だけで対応するのではなく、同僚コンサルタントの意見を聞くことも多くあります。

先日、同僚からある課題についてメールで意見を求められました。

しかし、その内容はけっして私が得意とする分野でなく、むしろ同僚のOさんの方が適切と思える内容でしたが、私宛の問い合わせメールでしたので、私なりに意見を返しました。

そして、返信メールの最後に「この件はOさんのほうが専門だと思いますが、なぜ私に尋ねてきたのですか」と付け加えました。

その回答は「いつものように同報メールで尋ねても、誰からも返信がこないから、今回は個人宛にメールした。Oさんにも別途メールした」というものでした。

なるほど、同報メールだと私は私で「これはOさんの案件だ」と考えましたが、あくまでもこれは私の主観で、Oさんは「これは、佐治さんの案件だ」と考えたかもしれません。そうなると誰からも返信がいかないことになります。

同報メールだと、どうしても当事者意識が低くなるようです。

意見がほしければ、メールを個人宛にして、「あなたの意見が聞きたい」とすれば、受け取った側の緊張感が増し、当事者意識が高まります。

メンバーの意見を聞き出すには、「同報メールではなく個別メールで、可能なら個別に会って意見を聞く」が有効です。ぜひお試しください。


今回は、榊原さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

榊原さん 39歳/設備工事会社の係長

うちの部署では、数多くの設備工事のプロジェクトを抱えていますが、計画時にかなり無理なスケジュールを毎回要求されます。

それというのも、過去の事例の中でのベストの実績をもとに計画することを求められるのですが、ベストの実績というのは、かなり無理をして実現したケースなのです。

したがって、スケジュール・マンパワーの余裕を認めてもらえません。

さらに、マンパワーは、予算取得までに詳細が決められることが少なく、予算取得後にマンパワーを集めるのですが、計画通りに集まらないことも多く、もともとの計画が厳しい上に、2重に厳しいスケジュールになってしまいます。

どうしたらいいのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、厳しいスケジュールを守るプレッシャーに加えて、マンパワー不足が重なると、ストレスが倍増しますよね。

このような場合の対応は次のステップで考えていきます。

  1. 人数の確保
  2. 再見積もりと計画の見直し
  3. リスクの共有

@人数の確保

通常、マンパワーの余裕が認められないというのは、工数・コストの余裕が認められないということで、人数の余裕は認められる可能性があります。具体的には、「10人x11ヶ月=110人月※1」で計画されているプロジェクトであれば、「11人x10ヶ月=110人月」で計画できれば、少なくともスケジュールの余裕は確保できます。

※1:人月…1人が1ヶ月で行うことができる作業量(工数)を表す単位。

スケジュールの余裕があれば、段取りにも余裕ができて、残業や休日出勤、モチベーション低下などによる、パフォーマンスの低下を防ぐことができます。そうすれば、結果的に工数・コストにも余裕がでてきます。


A再見積もりと計画の見直し

当初の見積りが絶対と思わないことです。実施時に見積り通りのスキルをもったマンパワーが必要人数入手できることは稀です。

計画と違うマンパワーを使って、計画通りに進めるのは無茶というものです。

そこで、実行段階では、必ず再見積もりを行います。再見積もりは、必ず実際に作業をするメンバーと一緒に行ってください。

なぜなら、その作業にどのくらいの期間を必要とするかは、メンバーの力量によって異なってくるので、メンバーが見積りに参加しないと見積もり精度が下がってしまうからです。

さらに、メンバーにしてみれば、自分が見積りに参加したスケジュールには、納期を守ろうというモチベーションが働きます。

逆に、上司から、一方的に「このスケジュールでやれ」と言われたら、きっと「また、無理なことを押し付けて」といった気分になり、モチベーションが低下し、パフォーマンスも下がるでしょう。

再見積もりができたら、それをもとに計画の見直しを行います。


Bリスクの共有

再見積もりによる計画の見直しがリスクをはらんだものであれば、そのリスクを「リスク登録簿※2」に記載し、その危険性と対策案を見える化します。

※2:リスク登録簿…洗い出したリスクの発生確率と影響度、危険度、対策などを一覧にしたリスクマネジメントのツール

そして、その「リスク登録簿」を関係者、特に上司・スポンサーと共有します。

上司・スポンサーがそのリスクを承知していれば、さらにスケジュール遅延が致命的なものであれば、きっと積極的に対応に乗り出すでしょう。

厳しいスケジュールに対しては、「@人数の確保、A再見積もりと計画の見直し、Bリスクの共有」の3ステップで対応します。ぜひお試しください。


今回は、北村さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

北村さん 34歳/ITプロジェクトのマネジャー

私の担当するプロジェクトでは、成果物のかなりの部分を協力業者のみなさんに依存していますが、ひとつ困っていることがあります。協力業者のメンバーのひとり、私よりもかなり年上の方と、スピード感が合わないのです。

成果物を直して欲しい時も、時間がないと、ついつい自分で直してしまうことがよくあります。

開発向けでやってきた人なので、顧客向けにわかりやすく記述するのは、苦手のようです。だからといって、記述の仕方について指摘すると不機嫌になります。

このようなメンバーとどう接したらよいのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、協力業者のメンバーでしかも年長の方に、思い通りに動いてもらえなくて困っているのですね。

北村さんは発注者であるから「指示する立場」、対してそのメンバーは協力業者だから「指示を受ける立場」と思っているのではありませんか。そして、指示する立場としての威厳を保たねばならないとも…。

メンバーにとっても、一方的に指示を受けるのは、初心者でない限り、面白いものではありません。まして、その方は年長者なのですよね。きっと年長者、経験者としてのプライドもお持ちだと思います。

プロジェクトマネジャーは、「メンバーに対する指示者」というよりも、「専門家に対するコーディネーター」というつもりで接するのがいいと思われます。特に年長のメンバーに接するときには、相手を立てることが効果的です。

「指示内容を持ち込む」のではなく、「課題を持ち込んで、相談する」あるいは「一緒に解決策を考える」という姿勢で臨めば、より効果的な解決策が生まれるのではないでしょうか。

ご相談内容を例にすると、「ここの表現をこのように変更してください」と指示するのではなく、「初心者も読んで理解できるようなマニュアルにしたいのですが、どうしたらよいでしょうか」と相談する方が、うまくいきそうですね。

メンバーの立場としても、「やらされる」と感じるよりも、「協力を求められている」と感じたほうが、気分もよく生産性が上がります。そして、いいアイデアがでるでしょう。もし、よりよい改善案があれば、提案してもらえる可能性も増えます。

本当にそのメンバーの方が記述が苦手でも、北村さんと一緒になんとか解決したいと思うのであれば、「内容は任せてください。全力を尽くしましょう。ただし、顧客向けの記述が不適切であれば、その部分の手直しだけはお願いできませんか」という提案になるかもしれません。

また、日ごろからその方と非公式なコミュニケーションをとることも重要だと思います。ことさらに飲みに行くのが苦手であれば、定期的に1対1で話をするようなミーティングを設定することも有効です。

年上のメンバーに接するときは「課題を持ち込んで、相談する」
ぜひお試しください。


今回は、河合さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

河合さん 37歳/設計部門のチームリーダー

私は、プロジェクトの設計フェーズを担当しています。悩みはプロジェクトマネジャーについてです。

私のチームが担当する作業について、「作業計画、負荷状況、リスク等の情報出し」を求められるのですが、情報を提供してもそれっきりで、情報が活かされていると感じられません。

プロジェクトマネジャー向けの資料作成で時間がかかっている状況は、無駄にしか思えないのですが、そのまま言ったらプロジェクトマネジャーを怒らせそうです。
プロジェクトマネジャーにどのように伝えたらいいのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、無駄と感じる作業をやらされるのは苦痛ですよね。

しかし、「作業計画、負荷状況、リスク等の情報出し」を明確にして見える化すること自体は、河合さんがチームリーダーとしてチームのパフォーマンスを上げるために有用な作業のはずです。

そこで、「作業計画、負荷状況、リスク等の情報出し」は、プロジェクトマネジャーのためにしている余分な作業ではなく、ご自身のチームのための必要な作業と考えればいかがでしょうか。

そして、チームのために作成した資料をプロジェクトマネジャーに提出します。
そうすれば、余分な作業は発生しないはずです。

もしかしたら、プロジェクトマネジャーの求める情報は、チームのための情報と異なる点があるかもしれません。
そこは、直接プロジェクトマネジャー本人に聞いてみるのが確実です。
チームのための情報を提示して、プロジェクトマネジャーの期待とどう違うのかを確認します。

もし、プロジェクトマネジャーが違うものを期待していることがわかれば、その理由を聞くチャンスです。

「その情報の活用方法を教えていただければ、よりわかりやすい形で情報提供ができます」と聞くことは、難しいことではないでしょう。

プロジェクトマネジャーが期待する情報と理由がわかれば、それをどのように実現するかを含めて見える化し、プロジェクトマネジャーの了解を得ます。
作業計画であれば、いつ、どのような形で作成し、どのタイミングでプロジェクトマネジャーに提出するのかを見える化するのです。

このように情報提供について見える化したものを「コミュニケーションマネジメント計画書」と呼びます。

もし、コミュニケーションについて、誤解や疑念があるなら、コミュニケーションマネジメント計画書を作成するのが解決方法となることがよくあります。

コミュニケーションがどのように行われているかが見える化されていて、関係するステークホルダー間で合意されていれば、あとから「無駄な情報を提供させられた」あるいは「今さら言われても遅いよ」といった問題を予防できます。

「コミュニケーションを円滑に行うためには、コミュニケーションマネジメント計画書を作成する」
ぜひお試しください。


今回は、渡辺さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

渡辺さん 42歳/設計部門のグループマネジャー

私は、10月からグループを任され、現在6名の部下がいます。
ところが、ミーティングで意見を言うのは年長のメンバーばかりで、若手のメンバーから意見が出てこないのが気にかかっています。

「ほかに意見はありませんか?」と促してみても何も出てきません。

ときには、名指しで意見を求めるのですが、それでも
「特にありません」「その方針でいいと思います」
といった回答だけで、本当に納得してるのか不安です。

本当に何もないのであれば問題ないのですが、仕事をしている様子や顔色から、なんとなく「なにか言いたいことがあるのに、言えていないのでは?」と感じています。

このままでは、業務効率が上がらないのではと心配しています。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、何も言ってこないメンバーというのも不安ですよね。
10月から始まったばかりということでしたら、今はプロジェクトのチームビルディングにおけるFormingの段階と思われます。

強いチームを作るプロセスで、代表的なものとしてタックマンモデルというものがあります。それによれば、チームの形成は次の4段階で行われます。

  1. Forming 形成
  2. Storming 嵐の状態
  3. Norming チーム意識の形成
  4. Performing 目的指向での行動

ここでは、タックマンモデルについての詳細な解説は省略しますが、一つのポイントとして、強いチームを作るには「嵐の状態」が必要だとういうことです。

「嵐の状態」とは、メンバーの意見の衝突が起こり、議論が繰り返される状態です。
強いチームでは、メンバー全員が意見をぶつけ合い、納得するまで議論をする過程が必要なのです。

現状では、意見があっても言えていない状態で、これは「嵐の状態」を避けていることになります。

このままだと、そのメンバーは、納得していないまま作業を続けていく可能性が高く、ご心配のとおり、業務効率が上がらないことが懸念されます。

相手が何も言ってこないとしたら、その原因としては、次の3つが考えられます。

  1. 言うべきアイデアがない
  2. 言う機会がない
  3. 言う自信がない(遠慮している)

「1. 言うべきアイデアがない」が原因であれば事情が違うので、ここでは2, 3のケースを考えてみます。

いただいた文面から、「2. 言う機会がない」については、ミーティングの場を設けて、意見を促してみたり、指名しているのですから、これが主要因ではなさそうです。

いちばん、考えられる原因は「3. 言う自信がない(遠慮している)」です。

そのためには、遠慮する相手(先輩方)がいない場を設定するのが効果的です。
また、人は複数の人がいる場では、なかなか本音を言うことができません。
しかし、メンバーの本音を聞かないことには、あなたは安心できないでしょう。

そこで、あなたは、メンバー個別に1対1でミーティングを行う必要があります。
ただ、ことさらに個人を呼び出してミーティングを行うとなると、相手を緊張させてしまいますし、かといって昔流に「ちょっと飲んで行こうか」というのも、断られる心配があります。

そこで、当社(アイシンク株式会社)の事例を紹介します。

当社では、月に1度マンスリーミーティングの日というのが設けられています。
この日は、誰もが直上および直下の相手と1対1ミーティングを行うことになっています。

メンバーにしても、自分だけ呼び出されるとなると緊張しますが、ミーティングの日で、順番が来たとなれば、特に緊張することなくミーティングを持つことができます。
そこで、もし何事もなければ、5分程度の雑談をして終わることになります。
何か気がかりなことがあれば、「実は・・・・が気にかかっていて」と話が始まり、10分、20分、あるいは1時間にもおよぶ話し合いになるかもしれません。

上司の態度としては、なにか問題がないか問い詰めるようなことをしてはなりません。
また、「何を言っても平気だよ、受け止めるつもりだ」と伝えてください。
そのうえで、率直に「あなたの意見を聞いていないので、自分が不安に感じている」と伝えてください。相手の言葉を引き出すような感じでミーティングを進めて下さい。

定期的にこのような場(機会)を用意しておけば、メンバーが気がかりな問題を抱えたままでという状態を解消することができます。

「チームビルディングの初期では、定期的に1対1のミーティングの場を持つ」、ぜひお試しください。


今回は、浮田さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

浮田さん 36歳/開発部門のエンジニア

上流(設計)部門からの急な変更連絡が多くて困っています。

もともとうちの会社は部門間の風通しがよくありません。

情報はいつもぎりぎりになってから伝えられ、早めの提供を依頼しても、「まだ確定できないから」といった回答がきます。

特に当初の計画が変更になるときは影響が大きく、それまでに完了したはずの仕事が無駄になり、納期に間に合わせるのが大変です。

どうしたらよいでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、急な変更連絡は困りますね。

もしも、確定前でも「変更になるかもしれない」という情報を得られることができれば、かなり助かるわけですね。

これは、不確実な状態でも、その情報を共有するという「リスクマネジメントにおけるリスク共有の問題」ではないでしょうか。

本来なら部門を超えてリスクを共有する仕組みができていることが理想的なのですが、それを待っていたら、きっと長い時間がかかってしまうでしょう。

そこで、非公式なコミュニケーションを使ってみたらいかがでしょうか。
上流側の正式な変更情報の入手は難しくても、非公式な情報なら比較的入手しやすいものです。

プロジェクトでは、直上流と直下流の担当者との非公式コミュニケーションがとても重要です。浮田さんの例では、直上流は設計部門、直下流は開発・製造部門にあたります。

公式情報発表前でも、担当者は一番早く「変更が必要になるかもしれない」あるいは、「計画より遅れるかもしれない」といったリスクに関わる情報はつかんでいるはずです。

もしも、日ごろから、担当者レベルでそのようなリスクに関わる情報を共有できていれば、あなたの業務効率は格段に向上するはずです。

その情報をもとに、いち早くあなたのリスク対応計画書(*1)も更新できます。

場合によっては、他部門だけではなく、顧客担当者とも非公式コミュニケーションのルートを持っているととてもやりやすくなります。

「リスク情報は非公式コミュニケーションで共有する」、ぜひお試しください。


今回は、田辺さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

田辺さん 33歳/設計部のエンジニア

うちの会社では、企画と設計、製造を別部門で行っているのですが、どうしても企画部門の力が強くなってしまいます。外部からの受注案件に比べて、社内のプロジェクトは最初から仕様があいまいで、さらに変更要求も多く、そのタイミングもさまざまです。

はっきりしないままずるずると仕事が進み、気が付くと仕様が変更になっていることが多いのです。

そうなると、当初のスケジュールは厳しくなる一方で、追いつめられた挙句、納期遅延になることもあります。どうしたらいいのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、仕様がずるずると変化していくのは困りものですね。

本件では、2つ大きな問題があるように感じます。

  1. 仕様変更の承認手続き
  2. 変更の権限者

「1.仕様変更の承認手続き」については、受注案件である程度うまくいっているのであれば、同じことを社内プロジェクトでも適用する必要があります。

まずは、社内プロジェクトであっても、依頼者は顧客であると考えるのです。

一番肝心な手続きは、文章化です。

変更要求、変更承認、そして変更した場合のインパクト(影響)をしっかりと文章化していくのです。

いただいた内容だと仕様変更の結果、スケジュールにしわ寄せがいっているようですが、スケジュールの変更もインパクト(影響)のひとつです。

変更要求があれば、スケジュールに対するインパクト(影響)も含めて、その変更を実施するかどうかを判断するようにしなければなりません。

次に「2.変更の権限者」の問題です。

どうも企画部門の意向が強く働いているようですが、スケジュールにも響くような仕様変更であれば、プロジェクト全体の責任者(プロジェクトオーナー、スポンサー)の承認が必要です。

企画、設計といった部門の利害を超えて、「全体を統括する責任者」=「変更の権限者」が承認するようにシステムを変更する必要があります。

加えて、判断のもとになるインパクト(影響)の調査には、リスクも含めてください。

しかるべき責任者が、スケジュールやリスクも含めたインパクト(影響)を承知した上で承認するのであれば、実行する方も納得できるでしょう。

これらの変更を円滑に行うためには、プロジェクト開始にあたり、仕様の変更手続きをどうするかという「変更管理システム」を作成し、関係者と共有しておくことが有効です。

「変更管理システム」の主な要件は次の3つです。

  • 変更要求に関する文章のフォーム:インパクト(影響)分析の項目を含む
  • 変更の範囲に応じた権限者:会議体の場合もある
  • 変更をトレースできるしくみ:記録

「仕様変更は社内社外を問わず、変更管理システムに基づいて実施する」
ぜひお試しください。


今回は、木村さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

木村さん 41歳/メーカーの設計部マネジャー

うちの部署では、プロジェクトマネジメントを取り入れて、現実的なスケジュールの作成とその管理をすることになりました。

一人一人の作業負荷を見える化して、1日単位で人の割り当てと負荷を見ようとしたのですが、とても煩雑で、一通りの計画を立てるだけでも多大な時間がかかっています。

現場で、1日単位での管理をしてみたところ、実際には午前中にひとつの仕事をすませて、午後から別の仕事にかかるというような状況です。

また、ちょっとなにかの条件が変わると、すぐにつじつまが合わなくなって、やっと調整したスケジュールが意味をなさなくなるようなことが起きています。

今、問題になっているプロジェクトのメンバーは約20名ですが、どうしたらもっと簡単に現実的なスケジュール管理ができるようになるのでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、20名ものメンバーの負荷の調整を行うのは、大変ですね。

現実的な負荷の調整にはモデル化が有効です。

作業の負荷調整は、1日単位ではなく、週単位でモデル化して考えることをお勧めします。

例えば、ある1週間の作業について、Aさん、Bさん、Cさんが協力して実施するとします。

Aさんが月曜日に計画したものを、AさんとBさんが一緒に火曜日と水曜日に実行し、木曜日にCさんがレビューして、金曜日にBさんが手直しして完成するとします。

このような作業が複数並行しているときに、1日単位で負荷をみていると、とても煩雑になります。

そこで、1週間分のそれぞれの作業量で考えてみることにします。

  • Aさん:計画に1日、実行に2日で合計3日
  • Bさん:実行に2日、手直し1日で合計3日
  • Cさん:レビューだけで1日

AさんとBさんについては、5日のうちの3日で60%、Cさんは5日のうちの1日で20%この作業に関わると考えます。

プロジェクトのすべての作業について、Aさん、Bさん、Cさんの作業を積み上げていくと、1日単位ではなく、週単位での負荷のあらましが見えてきます。

例えば、「Aさんは、この週は作業1に60%、作業2に20%、作業3が30%だから、平均1時間程度の残業で吸収可能だな」というように判断します。

プロジェクト規模によって、週単位でも煩雑であるなら、2週単位、あるいは月単位でのモデル化もありです。

そうして、1日単位、あるいは半日単位の作業内の負荷調整は、担当者に任せてしまうのが、管理者にとっても、担当者にとっても都合がいいものです。

週単位、あるいは月単位で負荷が許容内であれば、実際は何とかまわるものです。

「作業の負荷調整は、週単位、あるいは月単位でモデル化して考える」
ぜひお試しください。


今回は、若宮さん(仮名)からの悩みです。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

若宮さん 46歳/開発部門のマネジャー

私のプロジェクトではスケジュール管理のために、メンバーから作業ごとの進捗率を報告してもらっています。

しかし、実際のところ、なかなか報告が上がってこないし、上がってきても精度が低すぎて役に立たないケースがあります。

たとえば、90%進捗しているという報告があったので、間もなく終わるだろうと思っていたらなかなか完了しない、また一方で、別のメンバーからの報告が20%となっていたので遅れを気にしていたら、すぐに完了の報告が来たりします。

なんとか進捗率の管理をスムースに行えるような手立てはないものでしょうか。

〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜・〜

回答

なるほど、進捗率の管理は難しくて、大変ですね。

でも、そもそもなんのために進捗率を必要としているのでしょうか。

それは、その作業が計画通り完了するかどうかを予測するためではありませんか?

そうであれば、進捗率ではなく、作業が計画通り完了するかどうかを直接メンバーに聞いてみたらいかがでしょうか。

メンバーの立場では、「進捗率」を報告するというのは結構難しいものです。

90%進捗と言うメンバーの本音は、10あるモジュールのうち9が完成したというもので、残りの1つが、すでに完了している9つのモジュールよりはるかに困難だという場合もあるでしょう。

20%進捗と言うメンバーの本音は、たまたま飛び込みで入った過去の別プロジェクトのメンテナンスで、どうしてもそれを優先しなければならなかったために、若宮さんのプロジェクトの作業の着手が遅れただけで、着手すればすぐに終わるものだったのかもしれません。

まずは、計画通りに終わるかどうかを聞いてみてください。

予定通りという回答であれば、若宮さんも安心できる一方で、回答したメンバーには、「計画通りと言った以上、なにがなんでも計画通りに完了させるぞ」といったモチベーションが働きます。

そして、作業の終了予定日に対して遅れそうだという回答であれば、何日遅れそうなのかを聞いてみてください。

たとえば、2日という遅れ日数の場合、フロート※と比べて、納期に影響があるかどうかを確かめてみます。

もしフロートの中で、その遅れ日数がカバーできるのであれば、「それ以上遅れないようにしてくれ」というだけでよいのですし、カバーできないのであれば、すぐに対策を取る必要があります。

フロートでカバーできるかどうかの判断には、いくら進捗率を聞いても役に立ちません。

遅れの日数がわかって初めてフロートと比較することが可能になり、対策が必要かどうかがわかるのです。

「作業の進捗は、直接作業の終了予定日に対する遅れを聞いて把握する」
ぜひお試しください。

※フロートとは、その範囲で作業が遅れても、全体の納期に影響を与えることのない日程上の余裕のこと

当社より毎月発行しております、メールマガジンに掲載したコンテンツです。
メールマガジンは無料でご購読いただけます。ご希望の方は、購読お申込みフォームよりお申込みください。