見出し画像

OJTだけでPMスキルが身につくという誤解

西田PMP｜現場の違和感を、構造でほどく

OJTだけで、プロジェクトマネージャとして必要なスキルが身につく。

そう考える人は、意外と少なくない。

もちろん、OJTは重要である。
現場でしか学べないことはある。
実際のプロジェクトの空気感、関係者との調整、想定外のトラブルへの対応、会議体の運営、報告の仕方、リスクの見立て。

こうしたものは、机上の学習だけでは身につきにくい。

しかし、それは「OJTだけで十分」という意味ではない。

むしろ、OJTだけでプロジェクトマネジメントを学ぼうとすると、かなり危うい理解になりやすい。

通常運転のPM業務に派手さはない

プロジェクトマネージャの通常運転時の業務は、外から見るとあまり派手ではない。

定例会を開く。
課題を確認する。
進捗を確認する。
リスクを確認する。
関係者に状況を共有する。
必要に応じて調整する。
資料を更新する。
報告する。

表面だけを見れば、定型作業を繰り返しているように見えるかもしれない。

しかし、それはかなり断片的な見方である。

本当に重要なのは、その状態でプロジェクトを運転できるように整えるまでの過程にある。

プロジェクトの目的を整理する。
スコープを定義する。
体制を組む。
役割分担を明確にする。
計画を作る。
リスクを洗い出す。
品質の考え方を決める。
コミュニケーションルートを設計する。
意思決定の場を作る。
エスカレーションの条件を決める。

こうした土台があるから、プロジェクトは一見淡々と運営できる。

通常運転が静かに見えるのは、何もしていないからではない。
静かに運転できる状態を、事前に作っているからである。
むしろ派手さがあってはいけない。

ここを見落とすと、PMの仕事を誤解する。

表面だけを見ても、背景にある知識体系は見えない

筋の良いPMであれば、当然そのバックグラウンドにはPMBOKなどの知識体系がある。

そして、それを自分の現場で使いこなすためのスキルも持っている。

ただし、その知識体系は表面には見えにくい。

たとえば、あるPMが会議で淡々と課題を整理していたとする。

表面だけを見れば、単に課題一覧を読み上げているように見えるかもしれない。

しかし実際には、その背後でいろいろな判断をしている。

この課題は誰がオーナーを持つべきか。
期限は妥当か。
リスクに昇格すべきか。
他チームへの影響はあるか。
意思決定者に上げるべきか。
まだ現場で処理できる段階か。
計画変更に波及するか。
品質、コスト、納期のどこに影響するか。

こうした判断は、単なる経験則だけで成り立っているわけではない。

プロジェクトマネジメントの知識体系を前提に、現場に合わせてテーラリングしている。

しかし、知識体系全体を知らない人が表面だけを見ると、そのテーラリングが読み取れない。

なぜその会議体になっているのか。
なぜその粒度で課題を管理しているのか。
なぜそのタイミングでエスカレーションしているのか。
なぜそのリスクを重く見ているのか。

これらを理解するには、背景にある体系を知っている必要がある。

断片から体系を作ろうとする危うさ

この構造は、象の一部だけを見て、象全体を理解したつもりになる話に近い。
ただし、もう少し厄介である。

象の一部を触って、象を理解したつもりになるだけではない。
断片的に象を撫でて、そこから「哺乳類という分類の定義」まで導き出そうとしているようなものだ。

これはさすがに無理がある。

正しく象そのものとその成り立ちを理解したいのであれば、まず哺乳類という分類を知る方がよい。
そのうえで、象がその分類の中でどのような位置にあるのかを理解する。

そうすれば、象だけでなく、他の動物についても同じ分類軸で理解できる。

これはプロジェクトマネジメントでも同じである。

個別のプロジェクトをいくつか見ただけで、プロジェクトマネジメント全体を理解したつもりになるのは危うい。

もちろん、個別事例から学べることはある。

しかし、個別事例はあくまで個別事例である。

その背後にある知識体系を知らなければ、何が本質で、何がその現場固有の事情なのかを切り分けられない。

分類定義は、分解能そのものである

体系的な理解をすると、視野が広がる。

対象そのものだけでなく、その上位概念や分類軸も理解できるからだ。

PMBOKを学ぶ意味も、そこにあると思っている。

PMBOKを暗記すればPMになれる、という話ではない。
PMBOKに書かれていることをすべてそのまま現場に適用すればよい、という話でもない。

大事なのは、プロジェクトマネジメントという領域を理解するための分類軸を得ることである。

スコープ。
スケジュール。
コスト。
品質。
資源。
コミュニケーション。
リスク。
調達。
ステークホルダー。

こうした観点を持つことで、目の前のプロジェクトを分解して見ることができる。

今起きている問題は、スケジュールの問題なのか。
スコープの問題なのか。
品質の問題なのか。
ステークホルダー調整の問題なのか。
コミュニケーション設計の問題なのか。

この分類軸がないと、すべてが「なんとなく大変」「現場が混乱している」「誰かが頑張るしかない」という見え方になってしまう。

逆に、分類軸があれば、対象が変わっても同じ解像度で理解できる。

分類定義は、分解能そのものである。

何をどう分けて見るか。
どの粒度で現象を切り出すか。
どの観点で問題を把握するか。

それを与えてくれるのが、知識体系である。

劣化版オレオレPMBOKを作ろうとしていた話

以前在籍していた会社で、自社のプロジェクト標準を作るというタスクフォースが立ち上がった。

私はそのタスクフォースへの参加を申し出て、受け入れられた。

てっきり、PMBOKをベースにしながら、自社向けにプロジェクト標準を作る活動だと思っていた。

そのため、プロジェクトマネジメント知識体系の本を片手に、かなり意気揚々と参加した。

しかし、実態はまったく違っていた。

そのタスクフォースでは、これまで自社が関わった大手クライアントのプロジェクトから共通項を見つけて、自社のプロジェクト標準を作ろうとしていた。

つまり、既存の知識体系を参照するのではなく、自社の経験だけを集めて標準を作ろうとしていた。

言い方は悪いが、劣化版オレオレPMBOKを作るような話だった。

おそらく、その大手クライアントのプロジェクトの多くは、PMBOKなどの知識体系をベースにして運営されていたはずである。

つまり、本来参照すべき上位の知識体系がすでに存在している。

それにもかかわらず、その知識体系を直接見ずに、各社がテーラリングした後の成果物や運営方法だけを集めて、自社標準を作ろうとしていた。

この時ばかりは、さすがにないなと思った。

私はタスクフォースのリーダーに、

「みんなPMBOKを使っていると思いますよ」

と具申した。

しかし、どうやらすっかり機嫌を損ねてしまったようだった。

それ以来、そのタスクフォースは立ち消えになった。

先人の整理を無視するのは、効率が悪い

これはかなり極端な例かもしれない。

しかし、同種同質の考え方を持っている人は、意外と少なくない。

自分たちが見たもの。
自分たちが経験したもの。
自分たちの現場で使われていたもの。

そこから共通項を拾えば、体系的な理解に到達できると思ってしまう。

もちろん、経験から抽象化すること自体は重要である。

しかし、すでに先人が整理してくれた知識体系があるなら、まずそれを学ぶ方がよい。

なぜなら、先人たちは膨大な経験と議論の中から、その分類軸や概念を作ってくれているからである。

それを学ばずに、自分たちの限られた経験だけから同じものを作ろうとするのは、かなり効率が悪い。

しかも、多くの場合、同じ水準には到達しない。

既存の知識体系を学ぶことは、遠回りに見えるかもしれない。

しかし、実際には最も効率がよい。

先人の整理を使えば、最初から高い位置に立てる。
そこから自分の経験を照らし合わせることができる。
自分の現場に合わせてテーラリングすることもできる。

逆に、体系を知らないまま経験だけを積むと、いつまでも断片の寄せ集めになりやすい。

OJTは必要だが、OJTだけでは足りない

OJTは必要である。

現場で経験しなければ、知識は使える形にならない。

しかし、OJTだけでは足りない。

なぜなら、OJTで見えるものは、その現場で起きている表面だからである。

その表面の裏側にある設計思想。
知識体系。
分類軸。
テーラリングの意図。
判断の前提。

これらは、ただ見ているだけでは読み取れない。

体系を知っているから、現場で起きていることの意味がわかる。

現場を経験しているから、体系が机上の知識で終わらない。

どちらか一方では不十分である。

知識体系を学ぶ。
現場で使う。
経験を振り返る。
体系に戻して整理する。
また現場で使う。

この往復によって、知識はスキルに変わっていく。

新しい分野に入るなら、まず先人の整理に敬意を払う

これはPMやPMBOKに限った話ではない。

新しい分野に入門するときは、その分野で先人が整理してくれた知識を一通り理解するくらいの努力はした方がよい。

それは単なる勉強熱心さの問題ではない。

先人への敬意の問題でもある。

すでに多くの人が悩み、試行錯誤し、整理してくれたものがある。
それを見ずに、自分の断片的な経験だけで「わかった」と思うのは、かなり危うい。

もちろん、知識体系が万能だとは思わない。

現場にそのまま当てはまらないこともある。
古くなっている部分もある。
自分の状況に合わせて修正すべきこともある。

それでも、まずは学ぶ価値がある。

知識体系は、現場を縛るためのものではない。
現場を見るための分解能を与えてくれるものだ。

私は、できるだけ座学で学んだうえで実践することを心がけている。
そしてOJTはテーラーリングを試してみる場だと考えている。

もちろん、座学だけで実務ができるようになるとは思っていない。
しかし、何も知らないまま現場に飛び込み、断片的な経験だけでわかったつもりになることの方が、私はずっと危ういと思っている。

OJTだけでPMスキルが身につくという考え方には、かなり強い違和感がある。

経験は必要である。
しかし、経験だけでは体系にはならない。

断片をいくら集めても、分類軸を知らなければ、全体像は見えない。

だからこそ、PMを学ぶなら、現場に出るだけではなく、知識体系にも向き合った方がよい。

一見遠回りに見えるかもしれない。

しかし、結局はそれが最も効率のよい道なのだと思う。

いいなと思ったら応援しよう！