プロジェクトマネジメントとは「基準を作ること」である

久津（@Nunerm）です。

今回はプロダクトマネジメント（以下PdM）ではなくプロジェクトマネジメント（以下PjM）の話を書きます。

PjMにおいて大事なのは「基準を作ること」だという話です。

余談：PdMとPjM

いきなり余談ですが、よく「プロダクトマネジメントとプロジェクトマネジメントは違う」という話をよく聞きます。（違いについてはこちらの超わかりやすい記事にお任せします。）

元々プロジェクトマネージャーをやり、その後プロダクトマネージャーにシフトした自分としては、PdMとPjMの「どちらか」ではなく、両方できる人が強いと思ってます。PjMはプロジェクトのリスクを減らし効率的に進めるための武器なので、プロダクトマネージャーにとってはプロダクトが達成したい世界への最善の道筋を見つけることに役立ちます。逆にPdMの視点を持っているプロジェクトマネージャーは、事業戦略や優先度を把握しているのでステークホルダーとの調整などで役立ちます。

ただし自分がどっちを主軸にしているのかは明確にしておかなくてはいけません。例えば、「リスクが高いけどプロダクトの成長に大きく寄与する施策」の実行可否を検討している場合、PjMの立場だとリスクヘッジを重視するので、成長度合いを下げてでも失敗しない方法を選ぶ力学が働きますが、PdMの立場だとプロダクトの成長第一なので、成長度合いを最大限にするべくチャレンジする力学が働きます。

これを一人の人格がやってしまうと中途半端な成果しか出なくなりますし、周りのメンバーから見ると「いつも判断軸がぶれている」と思われてしまいます。なのでPdMとPjMを完全に別の人間がやり、双方にチェックし合う関係ができるのが理想ですが、組織の都合上難しい場合は、片方の役割を主軸とし、あくまで補助としてもう片方の知識を活用する意識が必要だと思います。

プロジェクトマネジメントは習得が難しい 

では本題に入ります。

PjMはPMBOKなど知識体系やノウハウがかなり溜まっている分野です。しかし、それをただ学んでもすぐに自分の武器になるには至りません。

その１つめの理由は、必要な知識の幅が大きく、インプットだけで全部習得するのはほぼ不可能だからです。

PMBOKガイド第6版は、49個のプロセスを、幅広いプロジェクトに適用可能な5個の基本的なプロセス群と10個の知識エリアとに分類する。

Wikipediaより

２つ目の理由は、適用するプロジェクトの種類によって様々な応用が求められるからです。業種、組織の規模、組織の成熟度、組織文化などによって、得た知識の適用方法を変えないといけません。例えば前職のリクルートでは、人数も多くメンバーの我が強いので、「しっかり管理して暴走や衝突を防ぐ」マネジメントが必要でしたが、出向した会社は意志の強い人が少なかったため、「皆の意見をしっかり吸い上げる」マネジメントが求められました。

このような理由から、PjMの習得は容易ではないと思っています。要はある程度の経験（成功と失敗）が必要で、その中で自分なりの「適用方法」を身につけていくのです。

若手にプロジェクトマネジメントを習得させるには…？

今勤めているCAMPFIREは平均年齢が（たぶん）20代後半で、しかも25歳で子会社の社長になったり23歳で新規事業の部長になったりするような環境なので、PjMの経験がないまま多くのことを管理する立場になってしまった若手が多いのです。そんな彼ら、彼女らからは「スケジュール管理が難しい」といった悩みが出てきます。

この環境ではもはや老害と化しつつある32歳の自分がPjMに関するアドバイスをすることがあるのですが、やはり細々とテクニックを伝えても伝わりません。しかも自分は基本的に大企業でのPjM経験をベースにしているため、自分のアドバイスが100%適用可能かどうか自分でも自信がありません。

なので、PjMにおいて大事なことをとにかくシンプルな言葉で表そうと頭を悩ませた結果、「プロジェクトマネジメントとは基準を作ること」に至りました。

スケジュールにせよ、リスクにせよ、スコープにせよ、コミュニケーションルールにせよ、物事が曖昧なままプロジェクトが進むことを許さず、必ず基準を作ってそれを遂行することが求められます。例えば、スコープが「新たに決済機能を作る」と定義されていた場合、そのための画面やテーブルなどはスコープ内であることは誰でもわかりますが、決済機能で使う共通モジュールのリファクタリングまで含めるかどうかは決めておかないといけません。ある人は後々のことも考慮してこのプロジェクトでリファクタリングしておいた方がいいと考えても、一刻も早くリリースしたい他の人は後回しにしたいと考えるかもしれません。そういう所を曖昧にしたまま進めていくと、後々になってズレに気づき衝突が起こるのです。こういうものは早い時点で「やる・やらない」の基準を決めておく必要があります。

とはいってもプロジェクトを開始する前に全ての曖昧なものを洗い出して基準を決めることは、かなりの経験を持っていないと難しいので、プロジェクト進行中に曖昧なものを見つけてそれが障壁になるようならすぐに基準を決める、という姿勢を持っておけば十分だと思います。同様に、現時点で持っている情報では予測不可能なものは無理やり基準を作るのではなく基準の決定を先送りしてしまい、いつ基準を決めるのかさえ決めておけば良いです。

全てのPjMの活動はこれに基づいていると考えています。逆に言えば、それを達成できるなら方法はガントチャートだろうがチケット管理ツールだろうが何でもいいと思っています。なので、方法やテクニックは各々で考えてもらって（もちろん参考になる事例とかは伝えます）、自分からは「プロジェクトマネジメントとは基準を作ること」というメッセージを若手に伝えていきたいと思います。とにかく「曖昧なまま進んでいるものはないか？」と気にしながら日々を過ごすことが良いPjMの第一歩である、これが自分の考えです。

若手の役に立ちますように…

※本記事は自身のブログ記事からの転載です。