あなたは、ある進行中のプロジェクトを、プロマネとして急遽引き継ぐことになった。前任者は事情で職場を去り、引き継ぎはゼロに等しい。 あなたがまず、やるべき事は何だろうか? まずはプロジェクト・チームの部屋に行き、前任者のプロマネの席に座ってみる。周囲のメンバーはあなたを、怪訝そうな、あるいは不安と好奇の混じった目で見ている。 とりあえずは皆を集めて、ミーティングを開く。席上であなたは、前任者が都合でプロジェクトを離れざるを得なくなったこと(それは皆も知っていたが)、自分がその役割を引き受けたこと、まだ様子が分からないから皆に教えてもらいながら前に進みたいこと、心配しないでこれまで通り職務に邁進してほしいこと、などを伝える。そしてあなたからはじめて、順に時計回りで自己紹介をしてもらう。だが、親しい人間は残念ながら一人も居なかった。 席に戻って、小さなため息をつく。ともあれ、プロジェクトの状況を知らなければならない。でないと、何についても決断は下せないのだ。でも、プロジェクトの状況を知るとは、具体的にはどこからどう、手をつけたら良いのだろう? 何が分かれば、「このプロジェクトの状況は大体分かった」と言えるのだろう? あなたはもっと小さなプロジェクトのリーダーをやったことはあった。また、その時の体験から、少しはプロジェクト・マネジメントについても知っておく必要があるなと感じて、手の空いたときに勉強もしてみた。そこで、プロジェクトで一番大事なのは、スコープ・コスト・スケジュールの三要素だ、と学んだ。 コストは、もちろん原価のことだ。プロジェクトが守るべき予算は決まっている。それを超えることは原則、許されない。またスケジュールはいうまでもなく期間で、これも完了期限が決まっている。とくにこのプロジェクトの場合は、会社単位のイベントに紐づけられているので、期日の縛りは大きい。つまり、コストもスケジュールも、守るべき制約条件なのだ。 では、スコープとは何か。スコープとは制約条件なのか? あなたは勉強した内容を思い出してみる。スコープとは、プロジェクトが果たさなければならない責任範囲を示す。「スコープが増えた」といったら、それは責任範囲が、つまりやるべき仕事が増えたことを意味する。 ただし、コストは円単位で、スケジュールは日数の単位で、計量化することができる。じゃあスコープは? これは数値化するのが難しそうだ。ただ、増減や大小は比較できる。だからまあ、制約条件だと言えなくもない。 とにかく、まずはスコープ・コスト・スケジュールを知らなくてはならない。あなたの前任者は、一応「プロジェクト・マネジメント計画書」という書類を作って本社に登録してあったが、中身を見ると、完了期日と予算枠の金額以外は、ひどく抽象的なことしか書いていない。これで会社はよく承認したな。 ともあれ、スコープ=責任範囲を知るには、どうしたらいいか? そのためには、このプロジェクトが生み出すべき成果物、アウトプットは何なのかが、分かれば良いはずだ。何を作れば、このプロジェクトは終わることができるのか? そう。プロジェクトとは、終わりのある仕事なのだ。プロマネたる自分の任務とは、この仕事が無事に終わるよう、頑張ることだ。だからまず、ゴール地点の姿を理解しなければならない。 あなたはチームの中でもチーフ格にみえたメンバーに、成果物の全体像が分かる資料がないか、たずねた。すると、「プロジェクト開始時点にもらった仕様書です」という書類をすぐに出してくれた。あなたはざっと目を通してみる。うーむ、こんなものを作るのか。 それは一種の、環境モニタリング・システムだった。複数地点に計測器を配備し、継続的にCO2排出その他の環境負荷データを収集、専用サーバに記録保持する。SDGsとカーボンニュートラルが重視される今日、重要な仕組みだ。 ただ、そうなると、現地での設置作業や調整なども必要になる。成果物としてのハードやソフトを作って、誰かに渡したらお仕舞い、という訳にはいかない。関係者との調整作業も必要だ。成果物づくりに関わる以外の仕事もそれなりにある、ということだ。おまけに技術的に見ても、従来やったことのない機能を含んでいるようだ。つまり、技術開発要素があるのだ。だから試験も必要だ。 ともあれ、いつまでに、何を、いくら以内で作って動かさなければならないかは、分かった。ゴール地点の姿は、少しは見えてきたようだ。 だが、これでプロジェクトの状況把握が終わった訳ではない。今、プロジェクトはどこの地点にいるのかが分からなければならない。つまり、進捗と出費の実績を把握する必要があるのである。 プロジェクトの工程表を探したが、あなたの前任者は、線が4本引いてあるだけの、非常にラフな線表しか残していなかった。いやはや。予算表も、探したけれど見つからなかった。一体何を、マネージしていたのだろう? 仕方がないので、あなたはプロジェクト・チームのメンバーと、グループ毎に面談することにした。ところがこのミーティング、状況把握の目的のはずが、技術の問題や人間関係の問題を訴える場になっていき、毎回、決めたりなだめたりしなければならない事が、あなたの前に積み上がるばかりである。 数日後、元のオフィスに戻って上司をつかまえる。状況報告をして、方針やアドバイスをもらいたいと思ったからだ。だが、他にトラブル案件を抱えているらしい上司は見るからに多忙で、「後はよしなに」というだけだった。 まいったな。こういうとき、プロジェクト・マネジメントの標準では、何と何をおさえるべき、と書いてあるんだっけ? あなたは、昨年買ったが、読まずに積ん読になっていた『PMBOK Guide』第7版をめくってみた。何なに、プロジェクト・パフォーマンスには8つの領域があるって? これかな? その8領域とは、ステークホルダ、チーム、開発アプローチとライフサイクル、計画、プロジェクト作業、デリバリー、パフォーマンス計測、不確実性、の8つだった(ちなみにあなたは、英語版を入手して読んでいたので、上記の用語は日本語訳とは一部合致していない)。 うーん、何だか分かったような、分からないような・・ステークホルダやチーム員の把握が大事なのは当然だろう。だが計画はメロメロだったし、プロジェクト作業の把握って? それにパフォーマンス計測が別にあるのか。心配なのは設計の品質なのだが、それは計測できるのかな。なんだか頭がぐらぐらしてきた。 10日ほど過ぎ、飛び石連休がやってきた。あなたは、以前知り合った、別の会社のベテラン・プロマネを訪ねることにした。自分の仕事の内実を話すのは恥ずかしかったが、せめて何かアドバイスをもらえないかと思ったのだ。 もちろん技術面の詳細や予算枠など、社外の人には話せない部分もあった。が、とにかく自分が曖昧ながら把握したプロジェクトの状況を、あなたはその大先輩に説明してみた。そしてPMBOK Guideも参照してみたが、適用の仕方がよく分からなかった、とつけ加えた。するとその先輩は、意外な事を質問してきた。 「あなたは自分のプロジェクト・チームに、誰を配員するかについて、権限はあるんですか?」 ——いえ、ありません。それは上の人間が決めることです。 「チーム員の人事的な査定はするんですか?」 ——いえ、それもしません。僕は彼らの直属の上司ではありませんから。参考意見を聞かれることはありますが。 「じゃあ、あなたは予算の枠内で、発注先を選んで、自分の権限で発注できますか?」 ——発注には上司の承認が必要です。文房具とか小さなツール類は別として。 「なるほど、そうですか。だいたい分かりました。あなたは人事権、つまりアサインメントや人事評定の権限もなく、発注先を自分一人で選んで発注書を切れる訳でもない、と。」 ——はい。 「そしてスコープ(成果物の機能範囲)も、コアの技術も事前に決まっている。最終期限も決まっている。できるのはスコープの若干の調整と、人とタスクのアサイン配分によるスケジュールの調整だけだ、と。そういう理解でいいですね。」 ——その通りです。それでは何かまずいでしょうか。 「いいえ。ただ、もしそうなら、あなたはプロジェクト・チームの実務レベルのリーダーではあっても、『プロジェクト・マネージャー』とは呼べないですよ。マネージャーというからには、プロジェクト目的の達成に責任を負う訳です。その責任を果たすには、当然ながら権限が必要です。権限なしに責任はない。PMBOKは、マネジメントのための標準体系です。あなたの仕事がマネージャーでないなら、適用できる訳がないと、思いませんか? ——たしかに、しばらく前までは会社ではプロジェクト・リーダと呼んでいました。でもその後、マネージャーという呼び方に変わったんです。 「呼び方がどうであれ、中身が変わらないなら同じですよ。」 ——でも、僕はプロジェクトの達成には責任を持っていますよ。 「良い心がけです。では、教えてください。あなたのプロジェクトの目的は何ですか?」 ——目的は、環境モニタリングシステムを作って、立ち上げることです。 「それはゴールに過ぎません。つまりプロジェクトの完了条件です。お伺いしているのは目的です。」 ——・・目的って、ゴールじゃないんですか? 「違います。マラソン競技の目的は、42km離れたゴール地点にたどり着くことだと思いますか? 長距離走をやる人間なら、ゴールにはたいてい、入れます。大事なのは、なぜマラソンに参加したかです。それと同じで、なぜ環境モニタリングシステムが必要なのか、それでどんな良いアウトカムが生まれるかを、考えなければなりません。それが目的というものです」 ——うーん・・そうですか。でも、自分が仮にマネージャーでなく単なる実務リーダーだとしても、プロジェクトの状況を把握しなければならない事に代わりはありません。いったい、何と何をおさえたらいいか、教えていただけませんか。 「そうですね。そういう時、PMの実務では、7つ道具というか、整理すべき図表が7つほどあるんです。まあ、8つの場合もありますが。それによって、あなたのおっしゃった、スコープ、コスト、スケジュールの他に、組織やリスクなどを含めて、プロジェクトの現在位置を総合的に把握できるようになります。」 ——それを、ぜひ教えてください。 「いいですよ、多少説明に時間はかかりますが。ただ、その前にもう一つ、念を押しておきたいことがあります。ゴール地点と、現在位置が分かったとして、それからどうします?」 ——それから、って・・そりゃゴールへの道を邁進するのみです。他に何をするんです? 「あなたは前任者からの引き継ぎもなしに、見知らぬプロジェクトに放り込まれました。会社も、今のプロジェクトの状況を把握できていないでしょう。だとしたら、全速力で残りの道を邁進する前に、もう一つ考えるべき事があります。それは、本当に今のままプロジェクトを続ける価値があるのかどうか、です。 ——続けるか、どうか・・? 「そうですよ。現在位置とゴールとの距離が分かったら、いつ、たどり着けるのか、それまでどれくらい労力がかかるかも、想定できるはずです。その上で、ゴールで得られる価値と、この先にかけなければならない労力やコストを比較するべきです。それが明らかに不釣り合いなら、プロジェクトは中止すべきでしょう。 ——それを、僕が決めるんですか? 「いえいえ。決めるのはあなたの上司であり、会社です。ただ、あなたはご自分のアセスメントを報告する訳です。プロマネは一般に、自分に付託されたプロジェクトを途中で止める権限はありません。ですが、もうこれ以上、努力する価値がないと考えられるなら、率直に報告すべきです。」 ——・・そんなの、前代未聞です。ギブアップ宣言じゃないですか。クビになりかねません。 「すでに失敗が見えているプロジェクトを止めなかったら、それは経営の失敗になります。経営の失敗の方が、ずっと被害が大きいのです。別にあなたの今のプロジェクトが失敗だと言っているのではありませんよ。一般論として、です。」 ——もちろん、分かりますけれども、ただ・・それって自分の仕事なのかな。 「プロジェクト・マネジメントの目的って、何だと思います?」 ——え? プロジェクトの目的と同じじゃないんですか。 「違います。プロジェクト・マネジメントの目的とは、プロジェクトの価値を最大化することにあるのです。」 ——プロジェクトの価値を最大化、ですか・・ 「プロジェクトの価値には、金銭で測れる部分と、人材育成や顧客の信頼など、無形の価値があります。ですから、単なるコスト計算だけで決められるものではありません。ともあれ、仮にもし人員や費用を追加投入することで、それを上回る価値増大が期待できるなら、追加すべきですし、自分に権限がないのなら、会社に理解を求めるべきです。逆に、万が一プロジェクトを継続することで、かえって価値を毀損するならば、止める勇気を持つ方が良いのです。 ——プロマネって、そこまで考えるべきものなんでしょうか。 「まあ現実には、ここまでできる人は少ないでしょうね。ただ、プロジェクトとは価値創出のための活動であることを忘れないでください。そしてプロジェクト価値を総合的に判断することは、現場で最も情報の集中している、プロマネにしかできないことなのです。」 ◇- — -◇- — -◇- — -◇- — -◇ ここからは、お知らせです。来る9月29日(木)に、久しぶりにプロジェクト・マネジメントに関する1日セミナーを行います。上に書いた、プロジェクトの状況を把握するための、PM「7つ道具」をはじめ、プロマネが身につけるべき基本的なスキルと技術について、時間をかけて解説します。 オンライン形式ですが、グループ演習などもできる限り取り入れて、具体的な学びにつながるセミナーにしたいと考えています。遠隔地の方も参加しやすいと思いますので、ご検討ください。 「プロジェクトを成功させるマネジメント技法とその実践ポイント」(9月29日) 日時: 2022年9月29日(木) 10:30 ~ 17:30 主催: 株式会社日本テクノセンター セミナー詳細: 下記のURLをご参照ください(受講申込もここからできます) 大勢の方のご来聴をお待ちしております。 佐藤知一@日揮ホールディングス(株)
by Tomoichi_Sato
| 2022-08-20 11:56
| B1 プロジェクト・マネジメント全般
|
Comments(0)
|
検索
カテゴリ
全体 A 生産マネジメントとSCM A1 生産マネジメント全般 A2 生産計画と生産スケジューリング A3 在庫・調達計画 A4 コスト・品質・安全 A5 BOM(部品表) A6 サプライチェーン B プロジェクト・マネジメント(PM) B1 プロジェクト・マネジメント全般 B2 スコープ・WBS・プロジェクト組織 B3 プロジェクト・スケジューリング B4 プロジェクト・コストと見積 B5 プロジェクトの価値とリスク B6 プログラム・PMO・ガバナンス C システムとしての工場 C1 工場計画論 C2 スマート工場論 D 情報システムのマネジメント D1 製造業のITシステム D2 ITアーキテクチャ・データ活用技術 D3 ITって、何? E ビジネス・マネジメントと管理技術 E1 マネジメントの技術論 E2 設計のマネジメント E3 組織・経営・戦略論 E4 ビジネスのソフト・スキル E5 時間管理術 E6 メンタルと働き方のマネジメント F 考えるヒント F1 思考とモデリングの技法 F2 社会・言語・文化 G 書評 H English articles 未分類 最新の記事
記事ランキング
著書・姉妹サイト
ニュースレターに登録
私のプロフィル My Profile 【著書】 「世界を動かすプロジェクトマネジメントの教科書 「時間管理術 「BOM/部品表入門 (図解でわかる生産の実務) 「リスク確率に基づくプロジェクト・マネジメントの研究 【姉妹サイト】 マネジメントのテクノロジーを考える Tweet: tomoichi_sato 以前の記事
2026年 05月 2026年 04月 2026年 03月 2026年 02月 2026年 01月 2025年 12月 2025年 11月 2025年 10月 2025年 09月 2025年 08月 more... ブログパーツ
メール配信サービス by Benchmark 最新のコメント
ブログジャンル
画像一覧
|
ファン申請 |
||