ステークホルダーマネジメントって何?
ステークホルダーについては以前
ステークホルダーって何? - こそだテック〜プロマネ的子育ての回でも話しましたが、
プロジェクトをするにあたりとても大切な利害関係者のことです。
ステークホルダーマネジメントは日本語で分かりやすくいうと家庭の場合多少の語弊はあるものの、利害関係のある人達の戦略的ご機嫌とり、と言えます。
自分の達成したい目標=旅行を成し遂げるために、賛成派も反対派もどちらにもある程度満足し理解してもらうための方法論です。
こう言うと、小賢しい感じがしてしまいますが、対立していがみ合ったり、誰かがすごい不利益を不本意に受けたり、ものすごく不幸な人が全体で発生するより、プロマネスキルを使って計画的に、どの利害関係者も程度問題はあれそれなりに満足してもらえるというのが平和な解決で私は好きです。
ステークホルダーマネジメントは継続的に行うものになり、プロジェクト立ち上げ時に属性と賛成派なのか、反対派なのか、どのように扱うのかを決めます。
ステークホルダー達を満足させられるかどうかにプロジェクトの成功がかかっており、家庭においては馴れ合いがビジネスよりもずっとおきやすく、「言わなくてもわかるだろう」「察してよ」的な事が起きやすいのですが、まずはパートナーときっちり情報連携をし、目線を合わせるのが一番大切です。
あーー、そういえばバアバにこれ言うの忘れてた!といった事、家庭でのプロマネなら良くありますよね。そういうことを未然にふせげるのがステークホルダーマネジメントです。そう思うと、転ばぬ先の杖、とも言えるツールなのです。
RACI って何?
ステークホルダーの話を前回しましたが、今回は誰をどのくらいご機嫌をとるのかを戦略的に考えるツール(小賢しいですが、家庭では頭の中で何となく考えることをフレームワークといって誰もが使えるツールにして標準化して行います)をご紹介します。
グローバル標準でよく使われる概念としてRACI(レイシー)というステークホルダーマネジメントのツールがあるので、これを使って例えば、Kay一家の旅行プロジェクトのステークホルダーマネジメントを行ってみましょう。
RはResponsible(実行に責任がある人)実務作業に責任がある人のことで、これは普通はプロジェクトメンバーです。複数のチームからなるプロジェクトチームであれば、それぞれのチームリーダーに相当するような人がResponsibleといえます。
AはAccountable(説明責任がある人)通常、説明責任を果たせる=Accountbleな人は1人にすべきと言われており、最終説明責任者です。複数の部署や会社にまたがるプロジェクトの場合はAccountableな人も複数名出てくる可能性もあります。
CはConsulted(相談や意見を求めるべき人)特定領域で専門家に意見を求める人をさし、例えば営業部のプロジェクトで、法務部などに何か法律面でのアドバイスを求めるようなシナリオです。
完全にプロジェクトチームメンバーだけの閉じた世界で完結すれば良いですが、大きいプロジェクトになればなるほど専門家の意見を聞くケースが増えます。場合によっては社外の専門家に聞くような可能性もあります。
IはInformed (情報共有をすべき人)を意味します。相談したり、実行したりはしないけど、何かあった時に報告、情報共有はしておかないといけない人達です。
Kay一家の旅行プロジェクトのステークホルダーは誰でしょうか?
家族は全員影響をうけるので、全員が対象です。
そして、パパママの会社の同僚、パパの実家、ママの実家の人々、子ども達の習い事も旅行中はお休みするため習い事の先生、そして旅行中は保育園もお休みですので保育園の先生方も対象に入りますね。
旅行のお土産を渡そうと思っている人が上記のステークホルダー以外にいるとしたら、その人も入れておくといいと思います。ここではパパの友達でハワイに旅行に行ったという△△にパパがお土産を渡すという想定にし、△△も入れましょう。
では、RACIに当てはめてみましょう。
パパとママが主な実行責任者ですので、Rはパパとママ、子どもも手伝えることがあれば戦力になるかもしれませんが、潜在能力は未知数ということで、?としておきました。
パパは最終説明責任者ということでA、その他事前に調整しないといけない人たちはC、今回の場合はほぼC=Iとなりました。
実務上もわりと同じで、ある時点では色々と相談しますが、プロジェクトの開始から、完了までを見るとある一時期を除いては、ただ情報共有をするだけの関係になることも多いです。
そして保育園やパパ友などは旅行後に、旅行土産を渡すだけですので、まさにIの関係です。
パパ | ママ | 子ども | パパ実家 | ママ実家 | パパ同僚 | ママ 同僚 | 保育園 | パパ友△△ | |
R(Responsible) | X | X | ? | ||||||
A(Accountable) | X | ||||||||
C(Consulted) | X | X | X | X | |||||
I(Informed) | X | X | X | X | X | X |
このように分けると、たんなる旅行計画も意外と色んな人に連絡したり、相談したりしないといけないことがわかってきました。
では次回はRACIにもとづいて、これらステークホルダーの巻き込み方を考えてみましょう。
PMP 受けるも更新も大変だが役に立つ
プロマネを長くやっていると、出て来る話題の1つ、グローバルな資格についてです。
プロマネは、特に国家資格というようなものがあったりするわけではないのですが、世界的にある程度標準モデルというのがあり、それらを理解していることは基本的に重要なことです。
プロマネ個々人でやり方やルールにばらつきがあると、全体を見た時に不具合が多いので、各企業毎にも標準化が進んでいますが、業界を超えて世界的に標準モデルがあるだろうというのが根底にあり、それを世界レベルでやっているのが、PMPという資格で、PMIという団体が運営しています。
うちの会社でもプロジェクトチームというのが世界各国におりますが、その数は数百名単位になります。もちろん会社特有のフレームワークというのもありますが、うちの会社でもPMPを1つのデファクト・スタンダードとして受け入れています。
去年、育休中にこの資格を取得しましたが、その際の奮闘記はまた次回の話とし、この資格の持つ意義を私なりに考えてみます。
PMPは、PMIの説明によると、
PMP® 試験は、PMI が策定した知識体系である PMBOK® (Project Management Body of Knowledge) ガイド に基づいて実施され、受験者のプロジェクトマネジメントに関する経験、教育、知識を測り、プロフェッショナルとしての確認を目的として実施されます。
専門知識を有していることを証明するために、米国PMI本部が資格認定を行うものであり、法的な資格、免許ではありません。
PMP® 資格は、プロジェクトマネジメントに関する資格のデファクト・スタンダードとして広く認知されており、プロジェクトマネジメント・スキルの評価基準として、IT・建設をはじめとする多くの業界から注目されています。
となっており、PMBOKというプロジェクト標準を理解したことを証明する資格です。
世界的にみてまさにデファクト・スタンダード(事実上の標準モデル)になっていて、例えば、先日アナウンスされましたが、アメリカ政府がPMI(PMPの母体団体)をアメリカ政府の正式プロジェクトマネジメント団体として任命し、PMBOKに基づくプロジェクトマネジメントを行う法令が通りました。
President Barack Obama Signs the Program Management Improvement and Accountability Act
日本でも官公庁のプロジェクト入札の条件でPMP資格保有者がいること、などの条件があるところもあります。
PMPを持っていなくても仕事はもちろんできますが、持っていると公式にPMBOKの標準モデルを勉強し、理解できているというお墨付きをもらっていることになります。ここが一番の売りだと個人的には思います。
プロマネを生業にしていると、会社指定の標準モデルや、なんとなく昔からあったやり方を使ってやりますが、人によってばらつきもあり、また、本来やっておくべきチェックや、フレームワークが抜けてしまい、その結果漏れのあるプロジェクト計画ができてしまう恐れがあり、世界標準を一度きっちり勉強するというのは、自分のベースを強化するという意味で重要だと思います。
ただし!
うちの会社でもそうですが、それが仕事の給与アップになるかというとならず、また、受験料が550USDくらいで、日本円では6万円超え(!)し、うちの会社ではサポート制度もなく、私は実費で受験しました。
4500時間以上の実務経験、36ヶ月以上のPM経験、そして、今までのプロジェクトの略歴を英語でPMIに送って、さらに上司の承認まで必要で、おまけに、受験するにも研修を受けなくてはならず、大体実務での知識経験意外に、追加で100時間〜2、300時間の追加時間をかけて準備しなくてはいけません。
しかも試験は4時間の長時間、1発勝負。
合格率は60%くらいなのですが、こんだけ高いハードルを満たした人が受けて60%なので、実際は意外と難しいです。模試で90%超えてないと受からないと言われてます。
周りでPMP受けて落ちたという人は聞かないのですが、それは当然で、
実務経験があるベテランPMが、さらに業務とは別に追加の時間をかけて勉強し、仕事を半日以上休んで、少なくとも上司には承認とらないといけないし周りにも公言することになるし、なにせ6万円かけて一発勝負なんで、一か八かのような受験は避けて、絶対受かるというところまで仕上げてから受けるからだと思います。
ちなみに、試験自体は自分で決めた日に受けることができますので、合格が厳しいと思えば先延ばしにすることもある程度は可能です。
私もこの資格は知っていましたが、この価格と労力の割に社内評価が低い、という点において長らく躊躇していましたが、一昨年下の子が生まれたのをきっかけに受けることにし、無事合格しました。
今はPMPホルダーです。
合格後、仰々しい↓資格証明書が送られてきました。(が、会社では特に評価も変わらないし、部署内では資格を知らない人も多いので、飾ってません。。)
が、この資格3年毎に更新し、3年以内にPMIが認定したトレーニング60時間相当を受けないといけないのです。受けるのも大変、維持するのも大変、しかも更新にもお金がかかる・・更新を諦める人も相当するいます。
受かって約一年が経ちましたが、特に周りの評価はこれによって変わらないものの、個人としては一段知識として上に行けた気がしています。PMBOKの標準モデルにそって仕事をしたり、困ったときにPMBOKガイドブックを読んでみたりということがありました。転職するときも、PMPホルダーであるのは、少なくともマイナスにはならないと思いますので、一応良かったと思っています。
あと、いくつになっても勉強し、成長できるんだという自信につながります。PMPを受ける人は数年の実務経験が必要なため、早くて20代後半、多くは30代、40代と思います。
多くの3、40代は資格取得勉強やプロマネ勉強を実務経験を積み上げる最初にやるので、積み上げた後はこういう仕事時間以外での努力をあまりしなくなる傾向があるように思うので、たまにはいいんじゃないでしょうか。
私も20代は会社が課す課題や業界の資格取得などを頑張っていましたが、30代になり子育ても入り、資格は一切とっていませんでしたし、仕事意外で勉強って何年もしていませんでした。
この資格をとるにあたり、久しぶりに受験勉強をしてみて、ここまで努力できるんだという自信につながりました。
では、次回は資格を取ったときの奮闘記をしたいと思います!
社会人歴に産休育休は入れたくないが引くわけにもいかない
4月が近づき、昔の会社の同期と同期会をする話が持ち上がり、ちょっと楽しみなKayです。
この時期になると、否応なしに自分が社会人何年目なのか、とカウントすることになり唖然とします。学生時代にインターンをしたのですが、その時にお世話になったのがちょうど社会人10年目の人で、その時は雲の上の人のような気がしました。
でも、今の自分も社会人10年を既に超えて、中堅の域に突入。。
時がすぎるのは早い・・
英語ではTime Flies(時間が飛ぶ)って言うのですが、まさに時間が羽をつけてパタパタ飛んで行ってしまってる感じ。特に子どもが生まれてからの数年は半端なく早い。
仕事と家庭とめちゃくちゃ忙しく、どちらも中途半端。仕事は昔のように夜中まで働くとかできないし、かと言って楽な仕事をしてるわけではなく、仕事量はむしろ増え続ける一方で、毎日切羽詰まる感じで必死に仕事してます。
この数年の手柄といえば、手抜きがうまくなった?人に投げるのがうまくなった?どうやって仕事量は変わらないのに、定時で帰るようになったんだけ。。要らない仕事をしなくなった? ホワイトカラーの生産性をあげるって良く言うけど、そんな生産性劇的に上がってるのか。。。?
ふと振り返ると「年食ってるだけじゃね?最近何かをちゃんと積み上げてるんだっけ?」みたいな時があって焦ることも多いです。
特に、ここ数年は産休、育休などで、実質空白の期間があるにもかかわらず、社会人になってからのカウント、要は大学卒業してから何年っていうカウントが普通なので、私は水増しされた社会人歴を背負っている気分です。
また今年の4月でもう一年、社会人として歳を重ねてしまいますが、2人分の産休育休あったし、ぶっちゃけ、マイナス3したい。
ただ、産休育休前後のキャリアが無駄なのかと言われるとそういうわけでもなく、それも含めて自分なので、社会人何年目?という話が出たら、大学卒業時点からカウントした年数を言って、言い訳を言える間柄の人には「でも間に2回産休・育休とってるから2年くらいはブランクありますけどね」と言ってます。
大学卒業してからの年数とキャリア年数が=にならなくなってきて、ここからは自分の努力の域だなーとヒシヒシと感じます。
ステコミって何?
先日ワーキンググループという話がありましたので、続いてステコミについてお話しましょう。
ステコミというのはステアリング・コミッティーの略で、英語ではSteering Commiteeと書きます。Steerというのは、舵を切るという意味で、強い力をもってぐいぐい方向を定めていく印象のある言葉です。Steerできる人が集まるCommitee、日本語でいうと、、適切な言葉がないようで日本企業と話をする時も「ステコミ」と呼んでます。
基本的にはかなり上層部の人を中心とした会議で、例えばある企業の営業システムの入れ替えプロジェクトであれば、営業部の部長、役員クラスと関係部署の部長、役員クラスが出て来るはずです。
ステコミの重要な役割は、企業のマネジメントまで話を通さないといけないことをEsclationすること、日本語で言うと上にあげる、ってことですね。そして、もう一つ決断をすることです。
適切な日本語表現がないのがちょっとおもしろいなと思うのですが、ステコミの重要なポイントは各ビジネスラインから決断できる人が集まらないといけないということで、私がいる外資系は決断できる人というのがかなり明確で、むしろ決断できないのに上層部にいる人は居ないのが普通です。
ところが、日系企業だとそうでもなく、以前私も日経企業と仕事をしたことがあるのですが、まずびっくりしたのが、会議に出てくる人数の多さ。
会議ではこちらは3人なのに、日系企業は10人以上も来て、しかもその場では何も決まらない、というような事がよくありました。
よく言われるように日系企業は外資に比べると決定権がどこにあるのか見えにくく、その結果ステコミに相当する会議を形成しにくいのではと思います。
アリババでも、私のちょうど考えているような事が書いてありました。
そうなんですよね~。。この意思決定スピードは、意思決定できる人がはっきりしてるからできるんだと思います。
日系企業が何人も会議に出てくるのに、決断がすぐできないというのは、和を大事にするということ以上に、決定権を持っている人が不明確というのが原因なのではと思います。このあたりは以前紹介したステークホルダーのところでRACIリストの話でも言いましたが、Resopnsibleな人はいるけど、Accountableな人が複数発生してしまっているか、居ない状態なのではと感じます。
そんなときは、RACIを使って、日系企業でも決断をする人(Accountable)な人をはっきりさせ、その人に決断を促す、相談は必要だけど、最後は決断を一人でしてもらうのも一つの手です。
こういうと、外資のステコミってすごそうなイメージですか?
ハイ。実際、かなり壮絶なんです。。事前準備が大変で、上層部が出てくるので下手なこと言えないし、分析が足りてないとすごい突っ込みを受けますし、準備不足だと公開処刑状態になることもあります。会議が終わった後は、いつもゲッソリ。。
日本企業のように根回しがそこまでないですし、予定調和は基本的にないので、かなり緊張します・・
1時間からせいぜい1時間半でおよそ決断に必要な情報やリスク、問題点などを伝えてその場か、遅くても数週間で決断にいたるようにアクションアイテムに落とし込みます。
外資系での根回しは少ないとはいえ、Esclationの場でもあるので、自分のレポートライン上のはるか上の上司に事前の情報共有せねばならず、事前からかなり厳しい指摘が入るので、ステコミの前1〜2週間はピリピリモードです。
とはいえ、ステコミは内部のミーティングがメインなので、そこまで時間を割きすぎるのもどうかと思うのですが、同時に役員クラスの人がひと目で分かるような資料を用意しうようとすると時間がいかんせんかかり、ステコミ前は根回し、ワーキンググループでの合意形成など同時並行で行うことが増え、負担感半端ないです。
頻度は(個人的には)月一くらいが適当で、重要な局面では2週間毎などにすることもありますが、やはり前述の通り準備もそれ相当の時間を要するので、結構ステコミの準備だけで多くの時間をさくことになりがちで、肝心のプロジェクトに関するタスクが滞るリスクがあります。
また、外資特有かもしれませんが、複数の拠点から上層部の人が参加するため、ビデオカンファレンスをする場合もありますが、多くの場合は電話会議です。
外資金融では一般的ですが、こういう電話会議用のツールを使い、会議室から参加したり、自分専用のオフィスを持っている役員は自分のオフィスから入ったりします。
実は、来週はステコミが控えているので、今から胃が痛いですが、頑張ります(汗)
クリティカルパスって何?
WBSを引くと、クリティカルパスが見えてくるという話を前回しましたが、ではクリティカルパスとは何でしょうか。
わかりやすい表現がネット上でありましたので、こちらをそのまま掲載します。
”最長経路”をクリティカルパスといいます。
プロジェクトの各工程を、プロジェクト開始から終了まで「前の工程が終わらないと次の工程が始まらない」という依存関係に従って結んでいったときに、所要時間が最長となるような経路のこと。クリティカルパスに含まれる工程に遅延が発生すると、その分だけプロジェクト全体のスケジュールも遅延するため、クリティカルパスに含まれる工程は特に遅れてはならない重要な工程として重視されることになる。
クリティカルパスとは|最長経路|critical path − 意味 / 定義 : IT用語辞典
クリティカルパスの中には、いくつもの重要のタスクが連なっている事が多く、それらのどれか1つでも遅れるとプロジェクト全体のスケジュールが遅延します。
そして、クリティカルパスは最長経路のため、余裕(これをプロジェクト用語ではフロートと呼びます)が全くありません。
クリティカルパスが遅れると前述のように、プロジェクト全体が遅延してしまうので、資源の投入(つまりマンパワーの投入)あるいは最適化(全体に影響がでないようにクリティカルパス内のタスクのやり方や期限を変えるなどして何とか間に合うようにする)が必要です。
資源配分に関してはこちらのサイトで細かく考えるべきポイントを書いているので、こちらを御覧ください
実務では、判断が難しいのが資源の投入です。特に長期のプロジェクトでは、プロジェクト参画メンバーの知識の積み上げが重要になってくるので、仮にプロジェクト全体が遅れそうだと言っても、誰かを投入すれば済むという話でもなかったりします。
火消し役のようなプロマネが投入されるというのは大きなプロジェクトでは往々にしてあることなのですが、その人がどれだけ早くプロジェクトにキャッチアップできるか等にかかっており、必ずしもいい結果を招くとも限りません。
特にプロマネサイドではなく、IT開発サイドや業務サイドの資源投入はキャッチアップする時間の確保が難しい可能性が高く(プロジェクトの進行に応じてメンバーが皆知識を蓄積しているので)、実務上、結局今いる人で何とかするという、一見根性論のような、はたから見たらありえない!こんなに働いてるのにこれ以上働かせるなんて!というような、事態に陥ることがあります。
実際に、IT業界で有名な法則に、ブルックスの法則というのがあり、遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけだ (英語: Adding manpower to a late software project makes it later.) という現象が起こることがあります。
普通、よっぽどのスーパーエンジニアとかでなければ、なかなかクリティカルパスが遅延しそうなプロジェクトをミラクルでなんとかすることはできないのです。ですから、それなりにできる社内のエース的な人がなんとか火消しで入ってくれても、むしろコミニケーションコストが最初はかかるし、キャッチアップするのに時間かかるし、本人も周りも、期待に対してパフォーマンスが上がらず辛い思いをする可能性が高いのです。ですから、そういうことを経験則上良くわかっている人ほど、単なる資源投入を嫌い、今のメンバーで何とかやろうとします。
すると、中にいる人からすれば人は投入されないし、仕事はきつくなるし、なんてしんどいデスマーチだ!となり、不平不満が出てきて、プロジェクトメンバーのモチベーション維持に苦心することもあります。
それでも続けると、いわゆるデスマーチプロジェクトになります。
回避策は、
クリティカルパスの遅れの可能性をできるだけ早くに潰すということです。後になればなるほど、本来PMの参考書にかかれているような資源の投入が現実的ではなくなり、かつプロジェクト全体の遅れる可能性が濃厚になってきます。
なので、できるだけ早い段階で遅れる可能性のあるものを潰すのが一番良いのです。
ただし、これは言うは易し行うは難し、
私も、はやプロマネ歴10年を超えましたが、クリティカルパスが何なのかを洗い出すのは簡単ですが、遅れを早い段階でつぶすというのは難しく、なかなかできていないのが現状です。
簡単なソリューションはなく、個別具体的に知恵を出し解決していくしかないとても難しい問題です。
WBSって何?
前回の記事で、ワーキンググループによるブレストをしたKay一家。
プロマネスキルを駆使し、課題や、やることリストが浮き彫りになってきました。
でも、やることは分かったとしてもこれからの数ヶ月間、ワーキンググループ(今回の旅行の場合は主にパパ、ママの二名)はどうやってやることのリストを管理していけばいいのでしょうか?
やることを理解したという状態から、実際に行動に落とし込み、完了するまでには大きな隔たりがあります。この隔たりを埋める代表的なツールがWBSです。
手書きのメモによる管理、スマホでリスト管理、Excelで管理、などやりかたは様々ですが、プロジェクトマネジメント上、こういったタスクリストというのをWBSと呼びます。実務でも、そのままダブルビーエスと呼びます。
正式にはWork Breakdown Structureといい、工程管理やスケジュール管理のツールです。
一般的には、タスクリストとガントチャート(工程表)が合わさったものをWBSと呼びますが、タスクリストだけでもWBSと言えて、具体的にはこんなイメージ↓
私もよく作ります。ベンダーさんや他社と一緒にやるプロジェクトをいくつも経験しましたが、皆さんフォーマットは違えども同じようにWBSにガントチャートをつけて全体管理をするケースが多かったです。
WBSがあることで、何が良いかというと(逆にタスクリストと較べて何が優れているかというと)、クリティカルパス(このタスクが遅れるとプロジェクト全体が遅れるというもの)が明確化されることと、前後関係がはっきりするということです。
Kay一家の旅行の場合は、
例えば、旅行の予約自体が遅れると旅行自体に行くことが危うくなってしまう恐れがあるので、旅行予約がまずクリティカルパスとしてとらえるタスクの1つです。その他も、これがないと他がうまくいってても全体が遅れる危険があるもの、例えばパスポートを取る(あるいはパスポートを持っている人であれば期限を確認し、旅行のタイミングでパスポートの期限が切れてしまうようなことがないよう確認する等)もクリティカルパスです。
このクリティカルパスを洗い出すためにも、WBSを書くと前後関係がはっきりして良いのです。ビジネスの現場ではマイクロソフトのプロジェクト派とExcel派に別れることが多いのですが、私の周りではExcel派がメジャーで、私も自分がリードする場合のプロジェクトでは私自身もExcelを使用しています。
Kay一家のWBSをざっと書いてみますと、こんな感じです。デジャブ感が半端ないのですが、、とりあえずイメージがつきやすいようにNo.1だけガントチャートを追記しました。
あとは、これをドンドン詳細にしていくだけです。そうやっていくと、あるタスクが終わらないと次に行けないタスクと、前後に関係なく進められるものが出てきますので、前後関係があるものを洗い出してそれを重要度高くかつ、クリティカルパスとして他のタスクとはちょっと扱いを変えて管理して行くことが重要です。
では、次回はクリティカルパスをもうちょっと深掘りしてみます。