プロジェクト・マネジメントのコツ

PMPの受験対策

今、PMPの取得に向けて受験勉強をしている。
PMPとは、Project Management Professionalの略称で、アメリカにあるPMI(Project Management Institute)という団体が認定するプロジェクト・マネジメントに関する資格である。PMIはPMBOK(Project Management Body of Knowledge)と呼ばれるプロジェクト・マネジメントのガイドを発行しており、PMPの資格試験では主としてPMBOKの知識が問われる。
私の勤めている会社は、ほとんどの業務をプロジェクトの形態で実施している。私も事業部門にいた頃は、プロジェクト・マネジャーの仕事をやっていた。大規模なプロジェクトのマネジメントをしたことはなく、概ね数千万円規模、プロジェクトのメンバーは数名程度のプロジェクトを同時並行でマネジメントをしていた。
その頃は、体系的にプロジェクト・マネジメントの教育を受けることはなく、先輩のやり方を見よう見まねで、あとはプロジェクト・マネジメントの本を読みながら自分で工夫をしながらマネジメントをしていた。おそらく、日本のプロジェクト・マネジャーの多くはそのようにしてプロジェクト・マネジメントをしていたのだと思う。
今は、間接部門に異動になって、プロジェクト・マネジャーを支援するいわゆるPMO(Project Management Office) という部署にいる。しかし、体制は脆弱で、大した支援ができていないのが現状だけれども。
最近、会社でもプロジェクト・マネジメントの品質を上げようという問題意識を持っており、その一環としてPMPの資格取得の支援をしている。私もPMOにいるのだから、さすがにPMPの資格を取っていた方がよかろう、ということで、試験の準備をしている。
プロジェクト・マネジメントの実務経験はそれなりにあったし、プロジェクト・マネジメントの基本に関わる本はそれなりに読んでいたから、これは驚愕の事実、というような新発見はなかったけれど、アメリカ風に体系的な整理がされていて、すべきことを抜け漏れなく頭の中に入れておくこと、また、テクニカルタームの定義を確認することには役に立つと思った。
PMPの受験する資格のひとつに、35時間の研修を受けるという項目があり、会社が隔週土曜日にPMP受験者向けに研修会を開催している。一回7時間の研修で、今週の土曜日が最終回である。
ほぼ完全に試験対策のための詰め込み教育で、試験に出やすいポイントの解説と練習問題と答え合わせ、解説を延々と繰り返す講義である。最近の会社の研修は、参加型のワークショップスタイルが多いから、こういうオールドスタイルの研修は久しぶり（もしかしたら大学受験のための予備校以来かもしれない）なので、つかれるけれど、逆に新鮮さもある。先にも書いたように、実務経験がある人にとってはこれまでの経験、知識、ノウハウを整理する効果はあるけれど、この資格を取ったからといっても、即、プロジェクト・マネジメントができるようになる訳ではないだろう。

次期基幹システムの開発プロジェクト

PMOとしての業務と並行して、社内の次期基幹システム開発のプロジェクトに関わっている。単純にシステムを更改するだけではなく、同時に業務改革を進め、さらに、子会社と共通したシステムを開発することによってグループ全体のシステム投資を節約しようという目的がある。これがこのプロジェクトをややこしくしている。
子会社といっても、もともと当社から分離独立した会社ではなく、他の企業の子会社を買収した会社である。このため、企業の文化やプロジェクト・マネジメントの思想、方法、規定にも大きな違いがある。また、当社と子会社の規模にはあまり差がなく、子会社側に子会社としての意識が乏しく、親会社である当社よりは大口顧客の方を向いていて、グループとしての統制はあまり取れていない。
私の担当は、営業管理、プロジェクト管理の業務プロセスの改革、当社と子会社のプロセスの統合、システム要件の定義を行うプロジェクト・チームのチームリーダーを補佐して推進させることが役割である。
当社の事業部門は、基本的にプロジェクト単位で仕事をしているから、PMBOK風に言えば強いマトリック組織であり、プロジェクト・マネジャーの権限が強く、プロジェクトを推進しやすい。しかし、次期基幹システム開発を担っているチームは、間接部門のメンバーから構成されている。間接部門は基本的に機能組織であり、プロジェクト・マネジャーの権限は弱い。ことに、子会社のメンバーに対しては指揮命令権がほとんどない。また、当社内のメンバーにしても、間接部門の社員は業務別に時間管理を行っていないため、このプロジェクトにどれだけの時間を投入すべきか計画されている訳ではない。プロジェクト・マネジャーには、ミッションが与えられているけれど、メンバーに対する作業の指示はあくまでも「依頼」という形になってしまう。特に、それぞれのメンバーの本業が繁忙期に入ると、このプロジェクトに関する業務は後回しにされてしまう。
私自身も、実質的にプロジェクト・チームの推進役を担っているけれど、正式に任命された訳ではなく、立場としては単なるチーム・メンバーの一員に過ぎない。
事業部門にいたときにプロジェクト・マネジャーをしていたときは、プロジェクトに関しては全権に近い権限を与えられていたけれど、現在は、それに比べればはるかに悪条件の元でプロジェクト・マネジメントをしている。そのことが、実にいい勉強になっている。

このような悪条件の元でプロジェクトを推進させるためのコツとして気がついたことをまとめておきたい。

率先して仕事をする

権限のあるプロジェクト・マネジャーでも、人を動かすためには、働きぶりに関してメンバーから敬意を受ける必要がある。今回は「指示・命令」ではなく、「依頼」で人に動いてもらわなければならない。そのためには、より他のメンバーからきちんと仕事をしているということを認めてもらう必要がある。
何か仕事を依頼するときも、まず、このパートは自分がやるので、このパートはお願いしたいという形で依頼する。あまり気分のよいことではないけれど、自分が仕事をした成果は、なるべく見える形でメンバーに示すようにする。
些細なことだけれども、プロジェクトの規律を維持するためには、締め切りを遵守する、打合せに遅刻しない、また、打合せの終了時間は必ず守る、議事録はなるべく速やかに作成するなど、仕事の上での基本動作は徹底する。その上で、期限を守らないメンバーにはやんわりとそのことを伝えるようにする。
しかし、注意しなければならないのは、メンバーに依頼することが難しいために、ついつい自分のタスクを増やしがちになることである。自分のできる限界を見極め、また、最適な人に作業をしてもらうことがリソース管理のポイントだから、過大な作業を自分に割り当てることは避けなければならない（自戒の念を込めて）。

支援するという姿勢を示す

「依頼」で人に動いてもらうためには、その人が仕事をしやすいような環境を整えるための支援を惜しまないという姿勢を示し、また、実際にそのように行動することが重要である。
作業を依頼するときには、その前提となる条件はなるべく整え、雑務はなるべく引き受け、その人でなければならないコアの部分を中心にする。その人が締め切りを守れなかったときも、その原因、例えば、その作業の障害となっている事象、本業で繁忙であるなどを聞き出し、支援できることは最大限に支援する。
通常のプロジェクト・マネジメントの場合には、メンバーの育成も考えて、ある程度ハードルの高い作業をあえて割り振り、それをメンバー自身で解決させるように誘導することもあるけれど、今回はそのようなことはせず、得意な作業に集中してもらうようにする。

自発性を最大限に引き出す

これは通常のプロジェクト・マネジメントと共通することかもしれないが、プロジェクト・マネジャーがあまり細部まで計画、管理しつくさず、あえてメンバーに計画、管理を委ねる余地を残して、自発的にプロジェクトに参加してもらうように仕向けるようにする。
例えば、締め切りの設定でも、こちら側から締め切りを提示すると、なにかと言い訳をされて遅延してしまうことが多い。そこで、こちらからはマスター・スケジュールを示し、依頼する作業の分割とそれぞれの作業の締め切りは作業を依頼する人自身にしてもらうように仕向ける。自ら締め切りを宣言、コミットすることになれば、人情としてなかなか遅延することはしにくくなる。また、目標はこちらから示すとしても、具体的な作業の方法はそれぞれの担当のメンバーに任せた方がより優れた作業計画ができるし、メンバー自身のモティベーションも高まる。

情報を最大限共有する、プロジェクトの全体を俯瞰する

私が関与しているプロジェクト・チームは、次期基幹システム開発というプロジェクト全体の一部分である。ともすると、プロジェクト全体の状況、意思決定などがプロジェクト・チーム、メンバーに伝わってこないため、今やっている作業の意味、意義が不明確になることがある。
そのため、私自身がパイプ役になり、プロジェクト全体の上層部となるべくコンタクトを取って情報を収集し、それをこまめにプロジェクト・チームに伝えるようにした。それによって、メンバーが今やっている作業の意味、意義、そして、全体スケジュールの中での位置づけを理解して、上記の自発性が高まることになる。
また、各自の作業だけではなく、プロジェクト全体のマスター・スケジュール、プロジェクト・チームの課題の全体像、一覧、WBSと進捗状況を定例会議で共有することが重要だと思う。

打合せを有効活用する

プロジェクト・メンバーは、それぞれの部署に属しており、また、会社も分かれている。通常は、メーリングリストを使って情報交換をするけれども、公式、非公式の打合せをなるべく有効活用している。
打合せの効用の一つに、締め切りの設定ということがある。作業は放っておくと遅延しがちである。そこで、マイルストーンとして打合せを設定してしまう。さすがに手ぶらで打合せに参加することはできないから、最低限の作業は進めてきてもらえる。
また、メーリングリストでの情報交換は、まさに情報の交換はできるけれど、意思決定の手段としては劣っている。意思決定に関わるべきメンバーを集めて、その場で意思決定をすることで、プロジェクトを推進することができる。
当然のことだが、打合せをしても、そのまま放置してしまっては、すぐに意思決定の内容があいまいになってしまう。打合せの最後に、決定事項、次回への作業とその担当をくどいぐらいに確認し、さらに、打合せ終了後になるべく早く議事録を作成して打合せに参加していない関係者も含めて共有することが致命的に重要である。打合せのファシリテーションでは、打合せ最後の確認と議事録作成がいちばん大切なことだと思う。

事前の準備に注力する

作業の依頼、打合せをするときに、事前の準備に注力をする。
常識的なことだけれども、打合せをするときには、事前にその打合せの目的、アジェンダ、得るべき成果について出席者に連絡をして、打合せの開始時に再確認する。資料は事前に配布して目を通してもらうことを徹底する。これの有無で、打合せの密度や打合せの方向性が見失われる危険性を大幅に減らすことができる。
分散しているメンバーを集めて打合せをするのは、時間の調整も難しく、貴重な時間である。それを可能な限り有効利用するためには、当たり前のことを当たり前にしておくことが必要である。
作業を依頼する場合でも、その作業の目的とその成果の利用方法については、十分整理して、わかりやすい資料を作成しておく。あいまいなところを残したまま作業を始めてしまうと、理解の相違から想定外の成果ができあがってしまうことも多いし、後続の作業に十分活用できないこともある。
依頼で作業をしてもらう場合には、メンバーからの信頼を得ることが必須である。そのためには、プロジェクトのなかでその成果が有効活用され、その作業をしたメンバーが貢献したことをわかりやすく示すことが重要である。依頼した作業が、無駄になってしまうと、それ以後、作業を引き受けてもらうことが難しくなってしまう。

終わりに

と、まあ、プロジェクト・マネジメントのコツ、という形で書いたけれども、結局はどのような仕事をする上でも共通のお作法をきちんと守るということにつきるような気もする。
もちろん、偉そうに書いたけれども、これを忠実に実行できている訳ではないけれど。