最近は見事に1投稿ごとにテーマがバラバラになっている訳ですが、そのうち試用がてらNAVERまとめでも使ってまとめてみようと思います。
して、今回のテーマはプロジェクトマネージャーについて。久々に直接自分の仕事に絡むお話を書いてみたいと思います。
例えば東京スカイツリーも「プロジェクト」でしょうし、詳細は存じかねますが昨年の震災から生じていた電力不足への対応も「プロジェクト」だったのではないかと思います。
個人的には、Wikipediaに記載されていた「プロジェクトマネジメント」のページの「プロジェクトとは」に記載される内容が説明として分かり易かったので、以下に該当箇所を抜粋します。
ということで、上記の記載内容は偏りも無く極めてシンプルに要点がまとめられている良記事と思います。
プロジェクトが失敗するパターンとして、目標や範囲（スコープ）が曖昧なままプロジェクトが始まってしまい、その影響でプロジェクト内の様々な行程がベローンと伸びてしまい、それにあわせて予算も期限もベローンと伸びてしまう、というお話は比較的良くある事ではないでしょうか。
また、初めはよかれと思って立てた計画が、いざプロジェクトがはじまってみたら or プロジェクトが終盤に近づいたら「コレジャナイ感」満点だった等という事も、割とあるのではないかと。
そもそも「プロジェクト」は、今まで取り組んだ事の無い新しい領域へのチャレンジとしての取り組みとなることが多いと思いますので、その先どう進んでいいのか分からない事だらけで始まることは、ある程度やむを得ないでしょう。
では誰が進むべき道筋を作って行くのでしょう？
それがプロジェクトマネージャの一番大事な仕事だと思うのです。
プロジェクトマネージャの具体的な役割はググれば幾らでも出て来ますし、またITの領域では資格試験があるくらいなのでここでは割愛し、自分が今までの体験から思う事をまとめます。
プロジェクトマネージャは、自分がマネジメントするプロジェクトの行く末をイメージし、プロジェクトメンバーにそれを伝えた上で、各メンバーの役割と果たすべき約束を明確にし、そして約束を守ってもらう為に全力を尽くす事が、仕事のほぼ全てを占めるといっても過言ではないと考えます。
プロジェクト計画は、予算や体制が余裕しゃくしゃくという事は殆どありません。予算も人員もカツカツで、こんなんでプロジェクト出来るんかいなという状態である事が大半と思われます。
しかし、プロジェクトマネージャは、予算や体制で無理があれば、「出来ない約束をしてはいけません」。考えられる手段を全て行使して、ギリギリまで粘り強く交渉をすべきです。
なお、IT業界ではプロジェクト自体が赤字でも、プロジェクトに伴い導入される機器やプロジェクトカットオーバー後の保守・メンテナンスで取り返すというあまりよろしくない商慣行が往々にして見受けられますが、プロジェクトマネージャとしては、そのような奥の手でもTotalで予算が確保出来るのであれば、後で「プロジェクト側には予算を回せない」等といった手のひら返しを食らわぬよう、内部で稟議決裁にその旨盛り込む、議事をがっちり確保する等関係者のコミットメントを押さえておくべきです。
また、プロジェクト計画時にクリアにならない領域もなるべく潰しておくべきなのですが、先にも書いた様に、新たな試みであれば相応に見通しがつかない領域も出てくるのが普通です。
見通しがつかない領域について、それを理由に放ったらかしにしておけば、プロジェクトメンバーは不安を覚え、プロジェクトについて来てくれません。
しかし、見通しがつかない要件も、殆どの場合プロジェクトの進行に伴いクリアになって行きますので、その領域に対しいつまで要件をクリアにしなければならないのかを逆算し、その期日をプロジェクトメンバーに伝え、他の領域に対する影響を極小化する努力をすべきと考えます。
この時に大事な事も、やはり「出来ない約束をしない（またはさせない）」事です。メンバーに初めから果たせない約束を強いても後々プロジェクトは破綻します。ですから前述の様に、メンバーに約束を守ってもらえるギリギリのところで納得をしてもらえる様、根気よく折衝をする必要があります。
ニュアンスとしては、「約束」というよりは「契約」と言った方が良いかもしれません。そのくらいに重みを感じ、かつ慎重にメンバーに役割を把握してもらうことが重要です。
※規模に応じてサブプロジェクトや委託先に置き換えてお読み下さい。
一旦計画が確定し、プロジェクトが走り出したら、プロジェクトマネージャはメンバーが計画時に伝えた役割・約束を果たす事が出来るのかを常に確認し、メンバーが約束を果たしきれる様、ナビゲートをし続ける必要があります。これはメンバーに「約束をまもれこのやろう」と体育会系のノリでどやせば良いという訳ではありません。
プロジェクトメンバーのミッションが滞り無く進む様、自らがメンバー間のハブとなり、プロジェクトに必要な情報の流通を率先して整え、また流通する情報を俯瞰し、滞りがあればその原因を把握の上、プロジェクト全体への影響を勘案の上対策を打つ必要があります。
一度プロジェクトが走り出してしまえば、プロジェクトマネージャとメンバーは同じ船に乗る運命共同体のようなものです。
プロジェクトマネージャは船長で、プロジェクトメンバーは船の動力に責任を持つ機関士、船の操舵に責任を持つ操縦士、船外の状況や外部との情報交換に責任を持つ通信士と言った具合に役割を明確化し、それぞれの責任範囲で最大限の仕事をしてもらう事で船が目的地に向かって進む訳です。
例えば万が一動力にトラブルが出れば、船の動力を縮退するなり修理をするなり必要が有り、またそれを船長が把握して操縦士や通信士に適切な情報伝達と指示を出さないと、目的地まで到着をする確率が著しく減少する事になります。不意な天候不良に対し、操縦士が速度を落とす、航路変更をする等の対応も同様と思われます。
プロジェクトとて全てが計画通りに進む事はまず無く、何らかの想定外の事象が発生するものです。計画では不意の自体を折り込んでスケジュールにある程度の余裕を取る等の対応は（それが許される状況であれば）一般的に検討事項に遡上すると思われますが、単にスケジュールに余裕を見ればOKという話ではありません。
プロジェクトマネージャは、予測不能な事態を出来る限り早く捉え、それが全体に波及する前に把握した上で、出来る限り短い時間内に適切な対処を取り、プロジェクトに所属する各メンバーが、自らの役割を果たす事が出来る様、いつも目を光らせていなければならないのです。
■プロジェクトマネージャは、「オーガナイザー」
自分は「当局の急襲がきっかけで、システムの現場を離れる事に（後編）」で書いた様に、現在は主に社内プロジェクトをモニタリングする部門の長として仕事をしていますが、何よりPMO組織の立ち上げとルール・スタンダード（基準）の策定、およびこれらを運用に乗せ、社内に定着させるまでをプロジェクト化し、自分がプロジェクトマネージャとして推進を担っていました。
して、今回のテーマはプロジェクトマネージャーについて。久々に直接自分の仕事に絡むお話を書いてみたいと思います。
■そもそも「プロジェクト」って何？
自分はちょっと前までずっとIT屋だったので、プロジェクトといえば「システム開発・構築・導入」が思い浮かぶのですが、実際には業種や業態により様々ですね。例えば東京スカイツリーも「プロジェクト」でしょうし、詳細は存じかねますが昨年の震災から生じていた電力不足への対応も「プロジェクト」だったのではないかと思います。
個人的には、Wikipediaに記載されていた「プロジェクトマネジメント」のページの「プロジェクトとは」に記載される内容が説明として分かり易かったので、以下に該当箇所を抜粋します。
ということで、上記の記載内容は偏りも無く極めてシンプルに要点がまとめられている良記事と思います。
さて、この投稿を読んで頂いている方は、何らかの形で「プロジェクト」に関わった事があると想定していますが、ご自身が関わったプロジェクトが上記内容に照らし合わせ、特徴を備えていたか、条件を満たしていたか振り返ってみて下さい。
■プロジェクトリーダーが進むべき道筋を作る
プロジェクトが失敗するパターンとして、目標や範囲（スコープ）が曖昧なままプロジェクトが始まってしまい、その影響でプロジェクト内の様々な行程がベローンと伸びてしまい、それにあわせて予算も期限もベローンと伸びてしまう、というお話は比較的良くある事ではないでしょうか。
また、初めはよかれと思って立てた計画が、いざプロジェクトがはじまってみたら or プロジェクトが終盤に近づいたら「コレジャナイ感」満点だった等という事も、割とあるのではないかと。
そもそも「プロジェクト」は、今まで取り組んだ事の無い新しい領域へのチャレンジとしての取り組みとなることが多いと思いますので、その先どう進んでいいのか分からない事だらけで始まることは、ある程度やむを得ないでしょう。
では誰が進むべき道筋を作って行くのでしょう？
それがプロジェクトマネージャの一番大事な仕事だと思うのです。
■目標に至る道筋を作り、関わる人達のコミットメントを得る
プロジェクトマネージャの具体的な役割はググれば幾らでも出て来ますし、またITの領域では資格試験があるくらいなのでここでは割愛し、自分が今までの体験から思う事をまとめます。
プロジェクトマネージャは、自分がマネジメントするプロジェクトの行く末をイメージし、プロジェクトメンバーにそれを伝えた上で、各メンバーの役割と果たすべき約束を明確にし、そして約束を守ってもらう為に全力を尽くす事が、仕事のほぼ全てを占めるといっても過言ではないと考えます。
プロジェクトの行く末をイメージし、プロジェクトメンバーにそれを伝える：
プロジェクト計画等の初期フェーズにおいては、プロジェクトの全容を見据え、計画時点ではクリアでは無い部分も含め、進むべき道を定め、メンバーを率いて行くのがプロジェクトマネージャの大切なミッションと考えます。プロジェクト計画は、予算や体制が余裕しゃくしゃくという事は殆どありません。予算も人員もカツカツで、こんなんでプロジェクト出来るんかいなという状態である事が大半と思われます。
しかし、プロジェクトマネージャは、予算や体制で無理があれば、「出来ない約束をしてはいけません」。考えられる手段を全て行使して、ギリギリまで粘り強く交渉をすべきです。
なお、IT業界ではプロジェクト自体が赤字でも、プロジェクトに伴い導入される機器やプロジェクトカットオーバー後の保守・メンテナンスで取り返すというあまりよろしくない商慣行が往々にして見受けられますが、プロジェクトマネージャとしては、そのような奥の手でもTotalで予算が確保出来るのであれば、後で「プロジェクト側には予算を回せない」等といった手のひら返しを食らわぬよう、内部で稟議決裁にその旨盛り込む、議事をがっちり確保する等関係者のコミットメントを押さえておくべきです。
また、プロジェクト計画時にクリアにならない領域もなるべく潰しておくべきなのですが、先にも書いた様に、新たな試みであれば相応に見通しがつかない領域も出てくるのが普通です。
見通しがつかない領域について、それを理由に放ったらかしにしておけば、プロジェクトメンバーは不安を覚え、プロジェクトについて来てくれません。
しかし、見通しがつかない要件も、殆どの場合プロジェクトの進行に伴いクリアになって行きますので、その領域に対しいつまで要件をクリアにしなければならないのかを逆算し、その期日をプロジェクトメンバーに伝え、他の領域に対する影響を極小化する努力をすべきと考えます。
各メンバーの役割と果たすべき約束を明確にし、約束を守ってもらう為に全力を尽くす：
プロジェクトマネージャは、全体的な計画がある程度纏まった段階で、計画内容からプロジェクトメンバー※が果たすべき役割と約束を明確化し、それをメンバーに伝えます。この時に大事な事も、やはり「出来ない約束をしない（またはさせない）」事です。メンバーに初めから果たせない約束を強いても後々プロジェクトは破綻します。ですから前述の様に、メンバーに約束を守ってもらえるギリギリのところで納得をしてもらえる様、根気よく折衝をする必要があります。
ニュアンスとしては、「約束」というよりは「契約」と言った方が良いかもしれません。そのくらいに重みを感じ、かつ慎重にメンバーに役割を把握してもらうことが重要です。
※規模に応じてサブプロジェクトや委託先に置き換えてお読み下さい。
一旦計画が確定し、プロジェクトが走り出したら、プロジェクトマネージャはメンバーが計画時に伝えた役割・約束を果たす事が出来るのかを常に確認し、メンバーが約束を果たしきれる様、ナビゲートをし続ける必要があります。これはメンバーに「約束をまもれこのやろう」と体育会系のノリでどやせば良いという訳ではありません。
プロジェクトメンバーのミッションが滞り無く進む様、自らがメンバー間のハブとなり、プロジェクトに必要な情報の流通を率先して整え、また流通する情報を俯瞰し、滞りがあればその原因を把握の上、プロジェクト全体への影響を勘案の上対策を打つ必要があります。
一度プロジェクトが走り出してしまえば、プロジェクトマネージャとメンバーは同じ船に乗る運命共同体のようなものです。
プロジェクトマネージャは船長で、プロジェクトメンバーは船の動力に責任を持つ機関士、船の操舵に責任を持つ操縦士、船外の状況や外部との情報交換に責任を持つ通信士と言った具合に役割を明確化し、それぞれの責任範囲で最大限の仕事をしてもらう事で船が目的地に向かって進む訳です。
例えば万が一動力にトラブルが出れば、船の動力を縮退するなり修理をするなり必要が有り、またそれを船長が把握して操縦士や通信士に適切な情報伝達と指示を出さないと、目的地まで到着をする確率が著しく減少する事になります。不意な天候不良に対し、操縦士が速度を落とす、航路変更をする等の対応も同様と思われます。
プロジェクトとて全てが計画通りに進む事はまず無く、何らかの想定外の事象が発生するものです。計画では不意の自体を折り込んでスケジュールにある程度の余裕を取る等の対応は（それが許される状況であれば）一般的に検討事項に遡上すると思われますが、単にスケジュールに余裕を見ればOKという話ではありません。
プロジェクトマネージャは、予測不能な事態を出来る限り早く捉え、それが全体に波及する前に把握した上で、出来る限り短い時間内に適切な対処を取り、プロジェクトに所属する各メンバーが、自らの役割を果たす事が出来る様、いつも目を光らせていなければならないのです。
■プロジェクトマネージャは、「オーガナイザー」
自分は「当局の急襲がきっかけで、システムの現場を離れる事に（後編）」で書いた様に、現在は主に社内プロジェクトをモニタリングする部門の長として仕事をしていますが、何よりPMO組織の立ち上げとルール・スタンダード（基準）の策定、およびこれらを運用に乗せ、社内に定着させるまでをプロジェクト化し、自分がプロジェクトマネージャとして推進を担っていました。
このプロジェクトを立ち上げる時に社長から直々に言われた「お前はこの組織を定着させる為に、オーガナイザーとして振る舞い、社内組織全体を盛り上げ、引っ張って行け」という言葉が、今も頭から離れません。
最初に話を聞いた時は「それって昔Lotus社から出ていたPIMの事ですか？」と一瞬思ったのですが、ググってヒットしたページを見て行ったところ、Wikipediaには「団体が組織拡大のために、人を勧誘して構成員にすること」「この言葉そのものはいわゆる既成左翼の世界で主に使われていたが、現在ではさまざまな組織一般で用いられている」等と、なかなかインパクトのある文言が．．．
自分は世代的に学生運動が盛んだった後の世代で有り、学も無いので「既成左翼」といわれても正直ピンと来ないのですが、社長のメッセージを「決まりごとや規律だけではなく、極論を言えば皆を思想で洗脳する位の勢いでやれや」と受け取りました。
自分はそのメッセージを受け、プロジェクトメンバーを含む会社全体に当該プロジェクト、およびその成果を定着させるべく、自分が考えられるありとあらゆる手段を尽くしました。
おかげで「【雑記】目下の悩み（前編）」にも書いた様に、いまだ社内に若干の悔恨を残す状況ではありますが、何とか社内的にも対外的にも、一定の域まで至ったと評価が得られる所まで至りました。
世の中のプロジェクトマネジメントに関する書籍や文献では、覚えるべき事やすべき事がキレイに整理され、それらが秩序立てて説明されています。またプロジェクトが頓挫した事例も相応に露見する様になり、どう対処すれば回避出来たか等の解説もあわせて一般の目に触れる様になりました。
しかし実態のプロジェクトの現場は、そんなきれいごとで話が割り切れるような事はまれで、多かれ少なかれ、複数の関係者間の利害関係が複雑に絡み合うカオス状態となることが殆どです。
プロジェクトマネージャは、そんな中でもがきながら皆が納得する（ネガティブな方向であれば皆が妥協する）現実解を探し、その解に向け自らの責任で結果を出す事が求められるのです。
