【前編】プロジェクトマネジメント勉強会

プロジェクトマネジメントのノウハウを学びたいが、座学で学んでも実践的ではない。そんなニーズにお答えして、具体的なケースをピックアップしながらケーススタディ形式で学ぶ勉強会を開催しました。

PM経験者でインプットを増やしたい方や、現在はエンジニアだが今後はPMもやっていきたいという方、PMという選択肢も視野に入れながらキャリアを考えていきたいジュニアの方に向けて、今後も継続的に開催していく予定です！

以下、当日のディスカッションパートから一部抜粋して内容をお届けしていきます。
（尚、個人情報管理のため参加者の方々のお名前はアルファベットで表記いたします。）

もともとPMになりたくてエンジニアになった

大津：
実際にマネジメントをしている人の中でも、PM（Project Manager）としての知識を体系的に学んで資格などを取っている人から、そんなつもりはなかったが気づいたらPMになっていたという人まで、さまざまな人がいると思います。

AさんがPMにキャリアを定めたきっかけや、仕事のやりがい、難しい点などを教えていただけますか？

A：
私はもともとエンジニアをしていて、そこからPMという職種に舵を切りました。実はもともとPMを目指していて、そのステップとしてエンジニアになったんです。なので、会社員時代から上司に「マネジメントに興味がある」という話をすることで仕事内容を誘導してもらいました。そういった社内の仕事を通じて知見を溜め、フリーランスに転向してITディレクターやPM関連の仕事を受けるようになりました。

そもそも、なぜPMになりたかったのかというと、単純なのですが、ひとりで何かをやるより、いろんな人を巻き込んだほうが大きなことができそうだと思ったからです。そこに旗振り役として関わっていきたいと思い、目指し始めました。

PMをやっていて難しいと思うことは山ほどありますが、例えば、最近はオフショア開発の関係でベトナムチームとの付き合いが多く、言語や文化の壁に結構悩まされています。

PMとITディレクターとの違い①：管理

大津：
お話の中に、「PM」と「ITディレクター」が出てきましたが、この二つはどう違うのでしょうか？

A：
私の中では結構重なっていると思うのですが、ITディレクターはやらず、PMが絶対にやることが2つあると思っています。

１つ目は、お金の管理です。ITディレクターは、プロジェクト収支などのおおよそは知ってるものの、細かい額はあんまり知らない場合も多いです。

２つ目は、人のアサインです。ITディレクターもメンバーが足りないというアラートをあげることは出来るものの、どこかから人を引っ張ってくる権限はないと思っています。

大津：
よくPMってヒトモノカネの管理をするみたいな話があると思ってて、ITディレクターってそれらの管理はしないということなのでしょうか？

A：
管理という側面でいうと、進捗管理と品質管理の2つは完全にITディレクターの業務の中核かなと思っています。最終的な「これを本番にリリースしていいかどうか」という決定を出すのはITディレクターの役割だと思いますね。

PMとITディレクターとの違い②：プロジェクトへの帰属

B：
話を聞いていて思ったのですが、みなさんはプロジェクト単位で案件に参加することが多いのでしょうか？

私の場合、1-2年単位で特定の会社に常駐することが多いのですが、プロジェクトに属していない人がITディレクター、プロジェクトに属してマネジメントするのがPMという認識でした。その辺はいかがでしょうか？

A：
私の場合は、プロジェクト単位で参加することが多いですね。そして、どちらかというとPMは複数のプロジェクトをたくさん見ているイメージです。だから当然忙しくもあって、一つのプロジェクト全ては到底見切れないので、そのサポートをするポジションとしてITディレクターがいるイメージを私は持ってます。

ITディレクターは基本的に1つ、多くても2つ3つのプロジェクトを中長期的に見て、確実に問題なく進捗させることが役目。一方、PMはもう少し引いたマクロな視点でプロジェクトを見ている、というのが私の現場でのイメージですね。

プロジェクトマネジメントは千差万別

大津：
プロジェクトが大きくなると、ユーザー・事業会社側でのPMと、ベンダー・開発会社側でのPMがいる場合もあると思うのですが、その場合の役割分担というのはどうなっているのでしょうか？

C：
ベンダー・開発会社側のPMは、開発会社の中にいる担当のプロジェクトリーダーの上で、お金も契約も見る役割と理解しています。彼らは開発経験もあり、どちらかというと作る側としての知見に強みを持っています。

一方でユーザー・事業会社側のPMは、ITディレクターに近い位置づけで、プロダクトオーナーが示す方向性に対してベンダーを率いるという役割が多い印象です。なので、技術と知識はそこまでいらないと思います。

ただ、コミュニケーションという観点でいうとIT知識はある程度ないとなかなか難しいので、そういう意味では自分が手を動かして作る経験をしていないと苦労するところもあるかと思います。

プロジェクトマネジメントといっても千差万別で、PMあるあるとしては「PMって依頼したけどこれはプロジェクトマネジメントじゃない」「これがプロジェクトマネジメントだ」みたいに認識が食い違うこと。そういった認識齟齬には常に注意が必要です。

D：
ということは、会社さんによってプロジェクトマネジメントの定義が違うってことなんですかね。

Cさん：
違うと思いますよ。僕自身もともとPMも統括もやっており、リーダーの指導をすることもあるのですが、契約がうまく見れないです、ベンダーさんの言うことがわからないです、など人によって状況はさまざま。そういったところを適宜指導しながらプロジェクトが燃えないように進めるということをしていました。

燃えたら燃えたでどっぷり入らないとダメなので、そういう時は、たとえば開発会社のリーダーが潰れたら、そこに乗り込んでいって開発メンバーの方を集めて、タスク割をし直して、みなさんが潰れないぐらいの仕事内容を決めて、ここまでやれば大丈夫っていうのを積み上げて、スケジュールを切り直して・・・みたいなリカバリーをすることもあります。

大津：
結構綺麗に行くケースの方が少ないってことですかね。

C：
そうですね、トラブルなしでいくことの方があまりないと思います。うまくエンジニアさんが噛み合わされば、本来プロマネはいらなかったりするのですが。プロマネがいる時点でバッファーが多くなり開発工数がかさむ場合もあるので、なるべく自分（PM）が入らなくてもいいようなチームを作りというのが、最短でエンジニアリングを進めるためにはキーにもなってきますね。

後半へ続く…