PM不足時代の「役割」としてのプロジェクトマネージャー学習/育成論

今回は徒然にプロジェクト、および、プロジェクトマネージャーについて思うことをまとめたい。プロマネで日々苦しみながらも活躍する実プレイヤー、プロマネ不足に悩む雇用者、渋々プロマネ役を拝命したエンジニア志向の方、他、プロジェクトマネジメントの担い手不足という課題に直面する人々に送る。

プロマネやりたくない問題

プロマネと言われて皆やりたくない！！！となるのは何故だろう。

責任が重い、能力不足、コミュ力不足、未知への不安、非プログラマ化、なんか偉そうだから（イメージが）嫌、等々あるけど個人的に思うのが要するに、ようわからん、プロマネって結局何なの？っていう認識の不足、あるいは、いろいろな人がいろいろなPM像を持っていてPMとはこういう存在！という共通認識がないことだと思う。

特に日本の場合は「PM」という役割と、「係長」「部長」という役職とが明確に分けられておらず、得意不得意置いといて偉くなるならPMになれ、あるいは、実プレイヤーは部下がやるからPM業務を一切せず名ばかりなPM枠を課長が担う（承認フローにだけいる）、等が蔓延していることがそれに拍車をかけているように思う。

PMの下積み経験？

当たり前だがプロマネは課長になったからいきなりできるようになるものではない。正しく経験を踏んで出世しているのであれば、それは下積みを経てできるようになるものだろう。さて、ここでそもそもプロマネの下積み経験とはなんだろうか。
少なくともコードを書いてただけ、ビジネス本を読んでただけではみんなの思う「プロマネ」はマネごとすらできないだろう。

プロマネの業務とスキルセットについては検索すればいくつか出てくる。それに依れば、多岐に渡る経験とスキルの獲得が求められている。RPGゲームでいう高次職。ナイトとヒーラーという全く別領域の職を経ないとパラディンにはなれないように、技術知見とビジネス知見とを併せ持たないとPMにはなれないとされている。

えっ…PMの役割、重すぎ！？

しかしこれは色々と求めすぎなのではないか。少なくともはじめから両方を兼ね備えた人間はいるはずがない。多少の経験、スキル不足を許容して下積みができる環境が用意できない限り、この人材不足の世の中ではPMは一生育たないはずだ。

このPM不足時代、スーパーエリート化しているプロジェクトマネージャーという役割を再定義してみることで、もっとPMの成り手が増えて担い手、雇用双方ハッピーになったりしないだろうか。

PMの役割分解

さて、PMに求められているもの、いわゆるスキルセットは何か。調べると色々出てくるが、疑わしいもの、必ずしも一人のスーパーマンに頼らなくても良さそうなものを排除していき、残った機能こそがPMにおいて求められる能力、と考えてみよう。

コミュニケーション能力、交渉力

どんな役割だろうがあるに越したことはない。ただし、プロジェクトの進行、管理の点でより説明が可能な人物、論拠を示せる人物がいるのであれば必ずしもPM自身がやる必要性は低いはずだ。極論、口下手でも決まることが決まればどんなやり方でもOK。

予算管理

動き出す前は十分議論されないといけない話の一つではあるが、必ずしも一人でやる必要もないし、決まってしまえばプロジェクト議論中にお金の話に戻ることはほぼない（というか戻っている時点でそのプロジェクトは正しく進捗できていない）。

分野知識・専門性

あれば議論はスムーズだが、そもそもPMがはじめから全てを知っていることは稀だと思う。また、一義的に進捗状況を管理する意味では、その中身については別の専門家が監修していれば事足りる。

進捗報告

レポートラインへの報告と、プロジェクト内部の管理の如何は全く関係ない。レポーティングに時間を取られる状態は寧ろプロジェクト課題なのでPMの能力ではなくプロジェクトとして解決すべき問題だ。

決断力、問題解決力

PMとしてプロジェクトの指針を示せることは重要だ。一方で、決断のための問題をどう解決するかはPMの能力だけではなく、チームで解決していけば良い。

課題管理、進捗管理

正直、これだけは役割としてPMがしないといけないこと。ただ、スキルセットというよりは与えられた役割でしかない。顕在化している課題というものを机の上にあげ、誰かしらに解決してもらう。その解決はいつまでにしないとプロジェクトとして進まないか、課題・広く言えばタスクの前後関係を明らかにする。
個人的な意見とするが、PMはこれだけやっていれば良いし、PMに求めるのはこの点だけでも良いはずだ。

PMってそんなに難しいこと？

これまで私は業務としてプロダクトオーナーやその補佐役としてのプロジェクトマネジメントに携わってきているが、どこの場面を切っても一つのプロジェクト（≒期間）で上記全てを同時に求められたことはない。もちろんそれは周りの理解を得られたとても幸運なことなのかもしれないが、一方で全部やらなくてもプロマネはやれるよな、と強く思うに至っている。

そこで、役割を担う被雇用者、役割を与える雇用者双方の観点で、これからの「妥当な」「役割として」のPMが増えるよう、どのようにプロマネを学べばいいか、どのようにPMを育てればいいか、持論を並べていく。

プロマネのススメ for employee

というわけで、上記のPMのスキル要件はあくまで理想論、目指す姿である、としよう。一部が欠けていたとしてもある程度成り立たないとそもそもプロマネに誰もなれない。鶏と卵的な話で、優秀なPMはプロマネ経験を経て育つが、経験はPMに着任することで初めて得られるものだからだ。

であるから、プロマネはスキル、経験、ましてや役職（階級）の適正レベル感で割り当てられるのではなく、多少の足りないところは目をつむり、まあ一旦は本人のやりたいと思うことが重要ではないか。

PMという役割の魅力

ということで私の思うPMの魅力について語る。
PM＝大変なお仕事、というのは一つの悲観的な見方でしかない。PMとは魅力にあふれたお仕事である。スキル不足云々を取り払ったときに、是非なってみたいと思う方がでてくるよう、普遍的なPMの魅力を書き連ねてみる。

意外と技術。理系脳が生きる分野

プロマネが扱う業務やツールは意外と理系脳を生かしやすいものである。
プロマネの教本的な存在としてPMBOKというものがあるが、それはまさに先人のやってきたことが詰まった学習本である。プロジェクトは水モノとは言うものの、ある程度汎用的な考えがあり、また、それをそのまま活用していけるところは多くある。

極論いえば、うまくいく公式、定理みたいなもの（≒フレームワーク）が用意されていて、それをパズルピースのように当てはめ、駆使して管理することこそがプロマネなのだ。

例えば進捗管理の利用されるツールとしてはWBSやバックログというものがある。これらはSaaSサービスやウェブにツールテンプレートとして落ちているのでそれを自分なりに使い方をカスタマイズして使うと良い。やりたいことは課題出しとそのスケジュール感やタスクの前後関係、優先順位の可視化だが、ツールを使っていればそれは自動でできる。便利な世の中だ。初めはこの項目なんだろうな？と思うかもしれないが、後々困った時にあって便利と思うこともあるだろうし、不要なら使わなければいい。

こういう公式を取捨選択しながら自分の今取り扱っている問題にあてはめ、解いていくやりかた、ってまさに理系がやってきたことだろう。プロマネはコミュニケーション形成や承認プロセス・進捗管理を対象とした数学ととらえて自分のできる領域の作業化してしまえばよいのだ。（感覚的には直接的な計算問題というよりは、函数論の証明問題的な印象。）

DX。働き方改革。これからのプロマネ像は「効率厨」

よく言われる、PMの業務負担の重さ、束縛時間の多さ。ここはまさに今のPM不足時代こそ改善すべきポイントだ。旧PM像にあるような、無限打ち合わせ編への耐久力、体育会系なノリはもういらない。いかに効率的にプロジェクトを回していくか。そのためには他人の工数はもちろん、自分の工数も、いや、自分の時間こそ重要なコストとして管理できるのはプロマネならではの裁量であるし、それが成果に直結するはずである。とどのつまり、プロジェクトをまともに動かしたいなら私の仕事量は自分で調整させろ、と言える立場である！

「高次に」ものづくりができる

一生コードを書くことをお仕事にしたいという人もいるだろうが、一方で大きな開発を手掛けたいと思う人にとっては、多くの開発工数が必要となる。PMという業務は、その工数を管理し、人に動いてもらって自分の思い描くモノ・コトを形作るお仕事である。それは一人では作れないような大きな成果を求める人には魅力的ではないだろうか。

今までニーズが消えたことはない

PM不足時代、とは言うが、そもそもPMが足りていた、余っていたことはないだろう。なので、仕事には困らない。自分のできることが仕事にできて、好待遇ならおいしくないですか！？

つぶしがきく

多分この技術は腐らないよ（AI？知らないね・・・）

専門分野は武器になるが足かせにはならない

プロジェクトにかかわると、ある程度その分野（ex.通信、教育、医療、EC、...）の専門家扱いされ重宝される。一方で、PMとしての役割は別分野でも期待され引く手あまたである。
これは一般的な技術職では得られない一挙両得な要素だろう。技術職は下手をすると専門家扱いされて他の分野への移籍障壁となりやすい（これはこれで別課題）。

PMになるための勘どころ磨き

以上の流れのとおり、ここではあくまでPMとしての経験の浅い人がいかにPMとして成長していくか、についてを論じたい。
ただし、ここで議論したいのは、どのような研修を受ければよいか、とか、どのハウツー本、ウェブツール何がいいか、とかそんなあたりは議論しない。話は逸れるが、この記事を書くためにPM不足について検索したら「もっと社員研修を増やせ」論が出てきてゾッとしたわい。やめてけろ。

なので、ここではPMとしての勘どころをどう磨くかの話にしたい。まあいわゆるライフハック的な観点だ。

計画脳、作業脳

自分ワードですまない、多分もっといい言葉・表現はあることはご容赦いただきたい。PMを語るうえで私はこの２つの概念みたいなものがあるな、と思っている。
計画脳とは、計画するための脳の使い方。具体的にはスケジューリングや、作業分解、割り振り、段取りを考えることである。そして、作業脳とは、計画をもとに実行する脳の使い方。具体的にはコーディング、資料詳細ページ作成や、交渉、Etc...。そして、この２つは同時に使うことはとても難しい（少なくとも私にはできない）。

そして、本当にPMとしてのスキルを発揮するには、前者の計画脳を鍛えあげ、意識的に動かすことだと強く感じている。つまり、PMは計画する人として、時間・人・状態の管理のためのあらゆる段取り「だけ」を行い、極論、そのための手段は別の人に動いてもらうことが理想だと考えている。（なのに、世の中PMにはスキル・才能として後者を求めすぎている感じがしている。）

優秀な人材はもちろん計画と作業の両方が的確で早い。ただ、上記の２つの脳の使い分けは必ずしもできていないケースを見てきた。優秀な人（は概して嫌な予感、リスクを感じ取れる人である）ほど、計画中に作業に流れる（些末なところが気になり始める）し、優秀な人でも、作業量に追われると優先順位を見誤る。優秀な人がPMであったとき、それは致命傷となる。そういうわけで、PMこそ手を動かす作業してはいけない、という考えに行きつくのだ。

鍛えよう、計画脳

PM人材として他者から一歩リードしていくなら、鍛えどころはここだ。自分の中の計画脳をうまく引き出せるように行動の癖付けをすることだ。
業務で必ずしもPMになれなくてもその能力は鍛えられる。自分に与えられた業務・業務外のことを計画（兼作業）者として、一人プロジェクトをバーチャルに作ればよい。（あくまで自己の能力ハックとしてのやり方のおすすめであり、一人プロジェクトをおすすめするわけではないことは注意されたい。）

• Myプロジェクトを立案する
  • 業務でなくても良い。日曜プログラミングとかあたりがおすすめか。
  • プロジェクトの成立条件を意識する
    • 目標がある（目標を決める）
    • 未知情報がある（ただの作業＝ルーチンワークでない）
    • 締切が決まっている（締切を決める）
    • コスト・日程上限がある（上限を決める）
  • やみくもに動くのではなく、段取りに落とす。PJとして自分を律し、自分を動かす。
  • 失敗の理由を考える
    • 計画上の抜け漏れが主な理由になる。同じ失敗をしないだけ、PMとして優秀になれる。
• 作業に取り掛かる前に段取りを決める
  • 資料作成であれ、コードであれ。まずは計画する癖をつける。
  • 計画≒作業分解。着手する前に何をやらないといけないかを決める
  • 計画中は作業のことは考えない、もし自分作業だとしても明日の自分に投げろ
  • 計画を見通すための作業は必要な分だけをやる。分解できたらすぐ戻れ。
• いきなり作業するな、の意味を考える
  • モノづくりの基本「とりあえず作ってみる」、の逆のケースがあることを知る
    • 具体的にはロードマップから外れることは作業の全ロスのリスクがあることを知る
• 未知の領域は、未知と既知の分解で見えてくることを意識する
  • （できるかどうか）わかること、わからないことを一緒にしない、課題を分解する
  • わからないことをどうわかることにできるかを計画し、作業化
  • わかることの作業から取り組まない（やれることから手をつけるのをやめる）
• 計画は遠回りとは限らないことを知る
  • 例えば小さな資料作り、コーディングでも頭の中でやっているはず
  • 「作業」が大きく・多くなるほど、「計画」は作業の先行着手になる
  • 適切な分割ができれば、一人（自分）でやる必要がなくなる
• 理想的プロマネ像を高く持たない。ただしなにが求められているかは理解する
  • いかに作業はしないで人に振るか、を考える
    • 自分でやるだけPMとしては時間ロスであると心得る
  • その代わり、計画には時間をかける必要があることを知る
    • PMであるかぎり、自分で計画しないことは一切進まないと思え

ここに書いていることを極論でまとめると、PMとしては計画することだけやり、一人で業務上負いきれないなら他を頼れ、ということだ。PMの業務はこれに尽きる。逆にそれ以外で手一杯になりがちなのがPM負担が多すぎるが故、そして、なり手がいない理由に直結していると断言できる。PMはもっと他の人を頼っていいはずなのだ。

そして、それくらいPMの業務負担を減らしても、PMは重宝される。まあ個人の見える範疇ではあるけど、課題管理、進捗管理ってできる人そんなにいないんですよ。それくらい計画脳って意識的に使える人が少ないんだと思うんよ。

学習論まとめ

• PMイヤイヤの論点
  • PM業務に悲観しすぎ。やりがいは絶対にある。
  • PMを神格化（何でも屋に）し過ぎ。この程度の役割で良い＆周りが支える必要がある
• PMの素養について
  • やるべきは計画脳活性化
  • ほんとに、計画できる人は強いんですよ。

プロジェクトとは何か for employer

話は変わって、そもそもプロジェクトマネージャーとはプロジェクトを管理する役割である。なるほど、ではプロジェクトとはなんだろうか、改めて問い直してみる。ググればいくつか定義が掲載されているのでそちらを参考にされたいとして、ここでは逆にプロジェクトではないものを定義してみる。

- ルーチンワークではない
- 量産物・単なるテンプレ化された作業ではない
- 個人プレイではない
- 追加リソース（人・金）が許容される
- 際限ない（エターナル化している）

これはよくあるプロジェクト定義を読み、敢えて逆を書いてみたものではあるが、なんと残念なことにこれら要素を含んだものをプロジェクトと呼び、大層ご立派に管理されていることか。

毎年行われる業務改善プロジェクト、同一テンプレートで横展開される営業プロジェクト、社員不足で実質一人開発プロジェクト、炎上に炎上を重ねて人数倍増＆2年延期でビッグリリースにこぎつけるプロジェクト…
プロマネ不足を考える前に、プロジェクト「定義」不足を疑った方が良い。あなたの会社は本当にプロジェクトを立案できているのだろうか？

誰しもプロジェクトマネジメントしている

プロジェクトというから仰々しくなり、重厚となっていく。そしてプロジェクトの定義から外れていき、辛いだけのプロジェクトと呼ばれるもの、そして、プロジェクトマネージャーと呼ばれる損まわりが誕生してしまう。
プロジェクトマネジメントは何も特別なことではない。そして、仕事だけでもなくプロジェクトというものは世の中に溢れている。

例えば、みんなと旅行を計画する

- やることは決まっていない（未知である）
- 旅行が終わるまでの作業（有期）
- みんなの行きたいところを踏まえる（共同活動）
- 予算がある（予算性）
- 旅行中にタイムテーブル確認（進捗管理）

これだって十分、プロジェクト足り得る。計画立案・遂行者は一種のPMだろう。そして、実が伴っているのでプロジェクトの定義から意外と外れにくい。
わかりきっている場所はともかく、行ったことのない場所ならまずはやりたいこと（目的）を定めるだろう。予定を合わせるので日付は確定済み、計画が長引いたら仕事の影響が出るから少なくとも日程は順守。自分の身をきるなら予算を超えない範囲で組む必要があるので価格を何より確認するだろう。あとは性格によるが、少なくとも乗り物等の移動時間に遅れないように計画を組むだろう。

これが正しいプロジェクトのあり方ではないか。新しいことにチャレンジし、ただし、終わりは定め、人員・予算は固定したうえで進捗管理する。

これから外れるようなアクシデントが発生した場合は、リソース投入によるプロジェクト立て直しではなく目標未達で終了すればよい。
旅行の場合、アクシデントがあったら予定を変更する。目標を柔軟に変えてプロジェクト自体を破壊し再定義しているのだ。お財布・時間が自分のものなのでリソース追加投入という選択は最悪であることは身に染みてわかっている。一番手っ取り早いのは、プロジェクト自体を不履行にする（旅行の当初やりたかったことを諦める）のはごく自然で当たり前なのである。

日本の業務プロジェクトはそれができていないのが一番の課題に思える。一度立てた目標はたとえプロジェクトの破綻が見えても変えてはいけない不文律となり、日本代表でもないのに絶対に負けられないプロジェクトばかりが乱立されるのである。敢えて言葉汚く言えば、この目指すべき明確な目標を持つであろうPMすら自社で確保できてないのに、なんでプロジェクトだけが絶対厳守の状態で誕生するのか？それ自体順番がおかしいのではないか。

正しくプロジェクトを作る

もうここまでの流れから、PM育成に何が必要かは明確だろう。

プロジェクトを正しく定義して作ることに尽きる。そして、そのプロジェクトはたとえ成功裏に終了しなくてもよいと許容せねばならない。未知への挑戦は必ずしも成功するとは限らない、という当たり前のことを言っているだけである。
そのことを許容できればあとは簡単だ。やる気のあるPM候補をPMとしてあてがえばよい。なーに前述の通り、プロマネは特別な能力でもあるまい。

プロジェクトは正しく定義しないと意味がないばかりか、あるべき正しいプロジェクト感を持てず、小手先のテクニックや世渡りのための社内調整が得意なだけの不幸なPM候補を産むばかりである。そしてそれはあなたの会社の技術力不足に直結してくる。
不必要なルーチンワークをプロジェクトに仕立てていないか？不明確な目標を必達目標にしていないか？過不足のない人員・コストの裁量が与えられているか？そして、エターナルなプロジェクトを作っていないか？
これらがおかしいプロジェクトは始める前から失敗している。少なくともPM育成の観点では。

PM育成計画の立案

さて、ここからはいかに社内から将来のPMを育てるかを考えてみよう。上記で述べた通り、候補者はあくまで候補者であり、百戦錬磨なPM経験があるとは限らない。この候補者はどのようなスキルマッチが行われるべきかを考えてみたい。

PM候補を探す

PM候補となりうる社員はどのような特性があるだろうか。個人の考えとして、プロマネは決して難しい業務ではないと思っているが、だれもがなれるものでもないと思う。かなり特性が影響するだろう。その特性をざっと上げてみる。

• プロマネをやる気がある
  • 先ほどの記載の通り、まずは本人がやりたいと思うことが第一
  • 決して階級役職、人事都合では決まらないよね？
• ざっくり（雑に）考えられる
  • 分解こそがPMの仕事、詳細よりも概要、大きな塊で仕事を回せる人が望ましい
  • 課題を感知できる能力は望ましいが、いきなり解き始めようとする人は不適
  • 作成する資料はすっきり、逆に言うと味気ないくらい小脚色。おおざっぱと言われている。
  • まとめ好き。「要は～～ってことですね」みたいな言いまわしする人は向いてそう
• 論点整理ができる
  • 会議中はどうしても議論が発散しがち。ゴールを意識して議論を収束できるかどうか
  • 「ところで今何の話してるんでしたっけ？」みたいな言いまわしでゴールへ誘導しなおせる人
• 話を遮れる
  • 会議中はどうしても議論が発散しがち。明後日の方向に議論が向いたら断絶が必要
  • 「その議論後にしませんか？」みたいにぶった切れる度胸
  • 概して、自分の時間が削られるのが嫌、なタイプがこれができると思う
• イベントを開ける
  • 飲み会、勉強会、等々の開催、ファシリテーションは段取りの塊
  • でも一方で自分で開くのが面倒で仕事を他人に振る、くらいの傲慢さが欲しいところ
  • 自分一人ではできない、と思っている方が実はPM向きだと思う
• こだわりがない、少ない
  • あるべき論よりも進むことを優先できる方、柔軟にやれる方
  • 自分で決めなくてもいいと思っている、決まればなんだっていい。ただし決まったことはひっくり返らないよう画策できる。
  • 「すみません、勉強不足でわからないのですが～はどうすれば？」みたいなことを平然と言える人は強い
• 準備は入念
  • どんな軽い用事でも資料作成や聞くことメモ等、段取りを作っておける人
  • 「この打ち合わせ何か準備しておきますか？」みたいなあたりが聞ける人
  • パワポよりもメモ帳を多く使っている人の方が実はこの傾向が高い

PM育成のための枠を作る

何度も繰り返しているが、PMはプロジェクトがあって育つ。PMを育てるための適切な育成枠を作ろう。

• プロジェクトを細分化し、子プロジェクトを作る
  • 既存のプロジェクトが大きいものほど、その中の未知なる複数の目標に分解できるはず
  • 分解すれば課題解決方針はより明瞭になり、かつ、あてがうための適切な難易度のPM枠が作れるはず
• アシスタントPM枠を用意する
  • 既存のプロジェクトにPMがいるなら、そのお手伝いをする役を用意する
  • アシスタントはPMと並走しながら、具体的な作業・作業支援（資料作成等）を実施し、その役割を通してPMのやっていることに触れる機会を得る
  • PMは上記で再定義した「PM業」に専念させる
• PMマクロマネジメント。PM上位職を用意する。
  • PMのPMとしての出世キャリア（≠管理職化）を用意し、後輩PMへの育成の鎖がつながる仕組みを作る
    • PJ立ち上げのエキスパート化→育成中PMに立ち上げ後継続中プロジェクトを継承
    • PJを統括するPJ管理者化→子プロジェクトへの育成中PM参画
    • どちらの方法にしろ、上位PMは下位PMのマイクロマネジメントは決してさせないこと
• 失敗してもよいプロジェクトを作る
  • 例えば小さな改善業務や非業務（飲み会等）を任せてみる
  • ただし、実施に必要な「作業」は先輩、上司もやる（PMの指示で動く。PMが人を動かすことを学ばせる。）
  • 同じく、わからなくなったら周りが助ける、何が課題かを自分の言葉で示させる。
  • 失敗に怒らない、改善点を挙げる

育成論まとめ

• PM不足問題の論点
  • いくつかの「なれない、なりたくない」課題を解決するために、自社でできることはないか？
    • PMへの要件の見直し、負担軽減
    • PM能力を磨くための育成枠としてのプロジェクト整備
  • 皆が嫌なのはPMなのか、PMじゃなくてもできるはずの業務なのか、なんちゃってプロジェクトなのか？
  • いない、いない、と言いながらちゃんと育てる仕組みはあるのか？