PMという言葉を聞いたことがありますか？ プロジェクトマネジャーを略したものです。
そもそも、プロジェクトって？そしてプロジェクトマネジメントとは何でなのでしょう？
プロジェクトマネジメントを標準化したと言われる教本「PMBOK」から定義を引用してみましょう（https://loftwork.com/jp/news/2015/10/08_pmbok）。
まず、プロジェクトは、
プロジェクトを 2つの要素で定義しています。「有期的であること」、そして「独自性があること」です。
「有期的」とは、文字通り、期日があるということです。その作業をいつまでに 終わらせなければならないかが決まっている。それが「有期的であること」です。 一方「独自性」というのは、ほかの定常業務と比べて、何かしら新しい要素が加わっているということです。これまでやってきた仕事の機械的な反復では済まない 作業。それが「独自性がある」仕事です。この 2 点に適合していれば、その仕事は プロジェクトであるといっていいのです。
プロジェクトマネジメントは、
「マネジメント」と聞くと「管理」という言葉を連想しがちですが、プロジェクトマネジメントは、むしろ「プロジェクトを確実に成功させるための道筋づくり」
プロジェクトマネージャー（PM）とは
プロジェクト・マネージャーは、プロジェクトを計画する人であり、プロジェクトの進行やクオリティ、プロジェクトの最終的な成功に責任を負う人です。
私は某インターネットポータル会社で、5年ほどPMをしていました。担当していたのはビッグデータの利活用を推進するためのプロダクト開発です。プロダクト開発といってもピンと来ない方のためにいうと、日々インターネットブラウザ（ChromeやFirefox）を通じて触るシステムの開発を推し進めていました。
本当に最初は失敗ばかりでした。一緒に仕事をしたメンバーも嫌だったことはたくさんあったでしょうし、任せる上司も不安でいっぱいだったと思います。それでも仕事を任せてくれた上司と一緒にやり遂げてくれた同僚には感謝しています。周りのおかげで後半の3年は大きな遅延や事故なく、プロジェクトを完了できるまでになっていました。初めの2年とあとの3年の大きな違いはなんだろう、と考えて、絞り出したのが「５つの大切なこと」。
今回はそれを記事にしていきます。
プロジェクトの成功とは
プロジェクトマネージャー（PM）が、プロジェクトの成功を担う人というのは、前段の定義に出てましたが、実際にプロジェクトが成功するとはどういうことなのでしょうか？
プロジェクト成功の定義は、上記のPMBOKにも書かれていません。これは、私なりの定義です。
プロジェクトが成功するとは、
- ステークホルダーが納得した期日で、プロジェクトを終えること
- プロジェクトに参加したメンバーが、プロジェクト参画前よりレベルアップしていること
- プロジェクトの結果が、事業のKPIに貢献すること
です。
もう少し、私なりの定義を詳しく説明します。
ステークホルダーが納得した期日で、プロジェクトを終えること
1つ目の定義は、「ステークホルダーが納得した期日で、プロジェクトを終えること」です。ここには少し言葉の罠があって、決して初めに約束した期日にプロジェクトを終えることではありません。
外的要因によって、状況が変わりやすい現在において、プロジェクトが当初約束された期日のまま進むことは少ないものです。
それより大切なのは、ステークホルダーとしっかりコミュニケーションをして、「いつまでに期日を決めるか」を決め、「決めた期日に対するアップデートを行い」「最終判断日の期日を決めて」プロジェクトを進める。
そして、最終的に約束された日にプロジェクトを終えるのが1つ目のプロジェクト成功の条件です。
プロジェクトに参加したメンバーが、プロジェクト参画前よりレベルアップしていること
2つ目の定義は、「プロジェクトに参加したメンバーが、プロジェクト参画前よりレベルアップしていること」。単純なプロジェクトでは、右から左に流すだけで終わるものもあって、毎度レベルアップするのが難しいかもしれません。ただ、どんなに単純なプロジェクトでも、参加しているメンバーと「今回の個人的なチャレンジはなにか？」をキックオフ前に話し、できるだけプロジェクトの中に取り入れましょう。
過去の仕事を振り返ったとき、「あの仕事で、こういう経験をしたなぁ」と思ってもらえたら、そのプロジェクトは成功したといえると思っています。
プロジェクトの成果が、事業のKPIに貢献すること
プロジェクト成功の最後の条件は、「プロジェクトの達成が、事業のKPIに貢献すること」。ときに、やらなくてもいいプロジェクトや、やる意義の薄いプロジェクトが存在します。そういうプロジェクトをきちんと断れないのは、PMがプロジェクトのオーナーと話しきれてない場合がほとんどです。それでも政治的にやらなければならないものは、PMとして事業上の意義を見出すべきです。
使い手も便利にならなければ、売上も増えない、そんなプロジェクトに成功はありません。
ただし、ときに法令遵守や会社のポリシー遵守のためのプロジェクトが存在します。そういうプロジェクトは、事業KPIに直接の貢献はしませんが、長い目で会社や使い手を守るプロジェクトです。KPIへの影響が「見えにくい」ものでも、意義を理解して完了させるのが良いPMだと私は思います。
5つの大切なこと
PMを5年間やる中で、失敗したプロジェクトもたくさんありました。つまり上記の３つの条件を満たせなかったプロジェクトです。メンバーの組み合わせや組織の状況によって成功の確率も変わってきますが、自分自身がPMとして、以下の５つのことをやりきれたときは、プロジェクトの成功確度がグンとあがったという印象を持っています。
その5つとは、
- 要件・仕様は、数年後も見据えてできるだけ具体的に書面に残す。
- その上で、今回のプロジェクトでは何合目まで登るかをチームと共有する。
- プロジェクトを進める体制は、現場のチームに委ねる。
- ステークホルダーへ週報を出す。
- プロジェクトの終わり方を定義して、メンバーとシェアする。
こちらも、ひとつずつ噛み砕いていきます。
要件・仕様は、数年後も見据えてできるだけ具体的に書面に残す。
あくまでも、インターネット関連のプロジェクトの観点ですが、ひとつのプロジェクトで想定したすべてをやり切れることは、ほとんどありません。
当初描いていたことの3割というプロジェクトもあるでしょう。そのとき、プロジェクトで3割だけの要件・仕様を考えればいいのかというと、それは違います。
できるだけ、100%の要件・仕様を洗い出しましょう。数年後までかかるようなものでも構いません。将来起こりうる開発を想定しながら今できる3割のものづくりをすれば、次のプロジェクトを行う際の手戻りを少なくすることができます。
その上で、今回のプロジェクトでは何合目まで登るかをチームと共有する。
1つ目の大切なこと「要件・仕様は、数年後も見据えてできるだけ具体的に書面に残す。」ができている前提ですが、今回のプロジェクトでどこまでを達成すべきかをチームのメンバーと共有したときのほうが、プロジェクトをやり切れる力が高かった経験があります。
完璧なものを求めてしまうと、できない部分に対してネガティブな感情が混じりがちです。しかし、「今回やり切れなくても次のチャンスがある」という感情と「ここまでやり切らないと、次のプロジェクトの人に申し訳ない」という感情を行ったり来たりしながら、考えて進めたプロジェクトの仕上がりは、とても良いものになることが多かったです。
プロジェクトを進める体制は、現場のチームに委ねる。
プロジェクトによって、初めから計画を綿密にして手戻りなく精緻に進めたいチームもあれば、少しずつ形を作っていきながらアップデートしていくのが得意なチームもあります。寄せ集めのチームで、PMが細かく指示しないといけないチームもあります。
プロジェクトの要件と、全体的な目標の何合目まで登るかを決めたら、登り方はチームのみなさんに委ねましょう。PMに仕切ってほしいと言われたら、仕切ればいいですし、そうじゃないならPMとチームのコミュニケーションルールを決めましょう。
現場には現場の理論があります。無理してマネージャーの理論を押し付けても、ロクなことはありません。
ステークホルダーへ週報を出す。
以前、記事にもしましたが（自発的に週報を書けば、勝手に仕事が進む）、PMから見える景色をステークホルダーに共有することは大切です。
チームメンバーから見ると違うように見えている可能性もありますし、プロジェクトのオーナーや他の部署から見ると物足りないこともあります。ただ、PMから見える事実を淡々と毎週報告しましょう。
問題があれば、誰かが声を上げてくれます。声が上がるまでは、プロジェクトに集中しましょう。目の前のプロジェクトをやり切るのです。やり切れる体制を作るためにも、PMがしっかり週報を出して事実を共有しておきましょう。
プロジェクトの終わり方を定義して、メンバーとシェアする。
最後に、どういう状態がプロジェクトの終わりかを、各メンバーとしっかり話しましょう。関係者が多いプロジェクトになると、早めに役割を終了して違う現場にいったり、元のオペレーションに戻る人がいます。
それぞれのメンバーがどのタスクをどこまでやると、プロジェクトでの役割を終了したかと話し合いましょう。その舵取りをするのが、プロジェクト終盤でのPMの大きな役目です。
改めて、プロジェクトを確実に成功させるための道筋づくりとして、大切なことは以下の５つです。
- 要件・仕様は、数年後も見据えてできるだけ具体的に書面に残す。
- その上で、今回のプロジェクトでは何合目まで登るかをチームと共有する。
- プロジェクトを進める体制は、現場のチームに委ねる。
- ステークホルダーへ週報を出す。
- プロジェクトの終わり方を定義して、メンバーとシェアする。
最後に
今回は、某インターネットポータル会社で、5年ほどPMをしていたときのことを思い出しながら、筆を取りました。失敗ばかりの最初の2年も、今思えば貴重な経験です。
PMをやる上で、人それぞれ大切にしていることは違うと思います。それでも、プロジェクトという「有期的」で「独自性」のある仕事をしている人の一助になればと思い、文字にしました。
--筆者--
小迫 正実 (こさこ まさみ)
高校生で訪れたフィリピンのスラム街での体験から、人の命に関わる分野から経済を動かし、世界を変えたいというビジョンを抱く。
2012年慶應義塾大学卒業後、聖路加国際病院で医療の質を司るQIセンターの立ち上げに従事。分析業務から、データ×ITに課題解決の糸口を感じ2014年にヤフーに転職。広告データ事業に関わる。並行して一般社団法人Healthcare Opsを2017年に設立。2018年には公衆衛生修士をリバプール大学のオンラインコースで取得。2019年よりグループ病院経営企画部に転職し、病院のデジタルトランスフォーメーションに従事。
(edited by Junko Yabuki)