挑戦と失敗の経験がPMの素地になる。

PMって仕事の内容は地味な割に、存在としては目立つ。
やっぱり僕もメンバーの頃は、PMを見上げながら憧れたり不満を抱えたり、いろんなことを考えていた。

そしてPMやってみて、何が一番大事なのか、どういう経験が役立ってるか、今僕が感じてることを書く。（結局いつもと同じようなことをたくさん書いてしまった気がするけど）

とにかく、みんな好きなことを書いて楽しそうなので、僕も僕だけの感性で書きたくなったのである。

僕のPMとしてのスタイル

僕の仕事は順調でなければならない。
これは絶対である。とにかく良い状態を作り出して維持することが信条だ。

なぜなら、物事がうまく回らないときは、通常時より何倍も労力がかかる。ミスをすれば報告や説明工数がかかるし、信頼を失えば調整や承認などに奔走する時間が激増するだろう。
そういったことに工数を消費するようになれば、アウトプットの品質は大幅に落ちる。

そのため、僕と一緒に働く人は1時間かかる仕事はきっちり1時間で終わらせるようにしてもらい、時間があるからとダラダラしないようにお願いする。
今までも何度も書いてるが、爆速で仕事を片付ければ余裕が生まれる。

案件終了日まで仕事はさせない。数週間前にはクローズの段取りをつけて報告書も作成に着手する。2週間前にはクローズに向けた報告を行い、1週間前には納品物を送付して次の案件の受発注をする。
ギリギリまで仕事をするタイプのPMだと、最後まで慌ただしい仕事をメンバーに強いることになりがちである。これは良くない。
仕事が収まってから案件をクローズするのでは遅い。完了見込みを先行して報告して、どういう状態で案件を完遂させるのかを合意するのだ。たとえば、導入予定製品の検証案件があったとすれば、検証予定項目の5～7割が消化できた段階でゴールに向けた報告をする。課題もまとめる。
顧客もおおよその感触がわかった段階で次の判断が必要だったりする。あるいは、状況を報告しなければならないかもしれない。そして次のアクションを決断しなければならないとしたら、早めにその方向性を決めるためのネタが必要なのだ。

そういうわけで、僕はあんまり報告書にも時間をかけない。
報告が速いので顧客とのギャップも起こりにくい。
だいたい前倒しで仕事が進むので、メンバーもほとんど残業しないで済む。

時間が余ったら、遊んだり勉強したり周りの人を助けるように言う。

PMに向いてる人

僕はかなり偏ってると思うけど、僕から見てPMに向いてる人は前のめりな仕事をする人である。
気になることがあれば首を突っ込まずにはいられないタイプだ。
そして勇気ある判断ができることが大事だ。

「これ、確認した方がいいかな」
と思ったときに結局確認できない人は絶対にPMになってはいけない。受け身な人は素直に上から指示をもらって動く仕事をした方がいい。

PMって潜在的な問題を潰す活動をしなければならない。
実は計画が間違ってるのではないか、技術的に課題がクリアできてないのではないか、作業者の納期の認識が甘いのではないか、顧客の理解が合ってないのではないか、そういう不安を感じたときに払拭する行動をどれだけ早く適切にできるかがPMに求められる動きである。
これが、前のめりな仕事をするということである。

しかし、確認してわかることだけではない。
中にはよくわからないまま判断しなければならないこともある。
そこで役立つのが挑戦と失敗の積み重ねである。

僕のしょぼいキャリア

今でこそクラウドエンジニアとして人並み以上にはスキルを身につけているし、クラウドセキュリティについても平均的な専門家には負けないくらいの自信はある。
PMとしても順調だし、大変売り上げに貢献できていて評価もされていて仕事が楽しくて仕方ない。
メンバーが困っていたらすぐに手を動かしてなんとかする。（サーバに入ってログを読んで調査に没頭する時間は楽しい）

しかし、スキルシートに書けば僕のスキルなんてしょぼいものだろう。
上流から下流まで全部経験したので一通りできるのだが、構築経験は半年くらいしかない。
これがインフラエンジニアとしてはだいぶ不利なのである。何しろほとんど運用経験しかない。しかも、その経験の大半が運用オペレータである。
セキュリティ経験も半年くらいの運用しかない。

しょぼすぎる。しかもすべての案件でメンバーだったので、ただの作業者である。

挑戦と失敗がすべてを救った

ただ、しょぼさを極めたせいか思い切りは良かった。失敗しても失うものが皆無なのだ。

自分の得意分野がない頃は何も未来が見えなかった。新しい領域はとにかくつらかった。クラウド基盤は最初は本当に苦労した。ウェビナーを受けても本を読んでもわからない。触っても理解できない。

そんな中で技術コミュニティを作ってバズったおかげで解決したというのは最近がっつり本に書いたので省略する。

今振り返ると、新しいことに挑戦して失敗して、それを乗り越える過程が自分の今を作ったと思う。

失敗も極める（慣れる）と怖くない。
触ってみてうまくいかなかったときに、全くダメだったのか、続ければ見込みがあるのかわかるようになる。失敗の肌感が身につく感じだ。
PMの仕事でも、失敗を回避するにはうまくいかない部分の分析力がものを言う。というか、未知の仕事は失敗を繰り返しながら最速で成功に辿り着くアプローチが必要な場合もある。この部分は失敗の数が多いほど引き出しが増えて有利になる。

挑戦と失敗。これは本当に大事だ。
案件が失敗してチームの空気が最悪になる経験も、幸い自分がPMになる前に済ませている。

しかし、失敗しなければ成功というわけでもない。
挑戦しなければ他者より前に出ることはできない。
「この案件は佐々木さんしかできない」
そう言ってもらうには、大きな成功が必要だ。誰もできないことをやって成功を重ねなければならない。
PM経験が薄い中で他人より評価されるためには、爆発的に活躍するしかなかったのだ。

僕の場合は挑戦と失敗の経験を積み重ねた結果、ようやく一人前のエンジニアになれた気がする。仕事ができる人を見上げてコンプレックスを感じることもなくなった。

PMが目指す未来

僕が興味あるのは、組織のマネジメントである。
組織づくりをして、自分の理想の組織を完成させたい。
そこでは全員が幸せな仕事をして、少ない時間で多くのアウトプットをする。
そこには苦しんで離脱していく人はいない。

幸い社内外で発信力はある方なので、会社の中でもPPAP活動を廃止することができたし、前例がないことを好きにやらせてもらってます。何やっても怒られないので思うようにやれてるわけです。
当然もっと裁量があれば大々的に行使して組織の成長に貢献もできる。人事権があれば炎上してるチームに介入して何とかすることもできる。今だとPMが僕じゃないので外からの遠回しな支援しかできない。

かつて、実力がなくて何もできない無力さを痛感する出来事はたくさんあった。仲間も倒れて去っていった。

そういう過去の弱い僕たちを助けたいと常に思う。
自分のプロジェクトの利益とか全く無視して、他者のためになるようなことに工数を使う。
僕がそういう姿勢だから、メンバーも生き生きと仕事ができる。メンバーもたくさん挑戦してくれる。失敗しても必ず僕が助けることが伝わってるからである。いい関係だろといっぱい自慢したいくらいである。

なのでよく「PMに技術力は必要か」みたいな話があるが、そんなものは重要ではないと思ってる。業務に必要なことが理解できないのは論外だが、前述した通り僕のスキルシートは弱い。
弱いけど5大クラウドのアカウントは持ってるし、ガッキーを作るために新しい技術へのアンテナを常に張っている。何よりすぐに挑戦して何かを得るので、平均的なエンジニアよりは常に一歩前にいる気がしている。

となると、やはり技術よりは挑戦と失敗の蓄積だと思うわけです。

#PMの仕事