shirasud dev

PjM兼Webエンジニアのつぶやき

プロジェクトマネジメントが評価され会社からMVPの賞をいただきました

f:id:shirasud:20210402224106j:plain

1年前は失敗続きでこんな記事を書いてましたが shirasud.hatenablog.com

プロジェクトマネジメント(PM)をやるようになってから半年

やっと上手くいったと思えるような経験ができたのと

メンバーの開発体験(DX)を最大化する姿勢を評価されたので学びと反省をまとめる

賞をいただいた当日に書いてるので少しエモくてポエミーな記事になるかも

PMをやることになったきっかけ

最初はPMのイメージって「大変そうだな」「自分がマネジメントなんておこがましいな」とか、なんか高尚なイメージが強かった

当時はなかなか自分のバリューが出せず試行錯誤していて

Figmaやってみたりフロントエンド強くなるぞーと意気込んでみたり

1つの技術に特化した職人的なエンジニアに憧れがあって、とにかくコードを書いて自分の武器を磨きたい気持ちだった

そんな時に「プロジェクトリーダーやってみない?」と僕が絶対的信頼を置いているマネージャーの方に言われ

迷った挙げ句、以下の理由でやることにした

  • FFSの因子で「受容性」が高いから向いてると思うよっていう後押し
  • コードが書けなくなるわけではない
  • プロジェクトのラインを増やすことで若手が新しいチャレンジができる

人のためと言われると「受容性」の因子は弱いんです

要は流されるがまま心変わりして、やってみようって気持ちになったから

※ FFSは会社のメンバー全員受けている性格診断で、キャリア選びやチーム編成に使われています

備考としてなんとなく古巣の記事のリンクを貼っておく

www.businessinsider.jp

うまくいったこと

メンバーのことを知る、とにかく会話する

ランチをしたり、雑談をしたりプライベートの出来事とか自分もなんでも相談するしなんでも発言しやすい空気感を作る

メンバーの目標をチームの目標として捉える

今期は設計力を向上させるところを目標に置いてます、じゃあ上手くいかなくてもいいからこのタスクやってみようか

ベロシティを上げるにはどうしたらいいか、どこがネックになってる?じゃあ開発環境整えるとこから議論してみようか

時には上長に、メンバーのこの目標厳しすぎませんか?っていう意見もしました

いろんな角度からチームに貢献してくれてるのに、評価されないみたいな構造をなくしたかった

メンバーがもっている情報レベルが同じになるまで根気強く説明を続ける

技術レベルもドメイン知識もばらつきがある状態で初期の設計フェイズはとにかく時間をかけました。 タスク分解、規模見積もりも全員でやりました。 同じ説明を2,3回しないといけないような場面もあったけどわからないまま進むよりまし メンバーにとっても自分にとっても学びがあり 結果としてコードの品質を高められたので必要な時間だと思いました

今は正直わからないことがわからない状態だと思うし、わからないことは何度でも説明するから聞いてねってコミュニケーションはとるようにしてました blog.tinect.jp

ブラックボックスは早めにつぶしておく

ここを後回しにして、後からやらないといけないことがドサッと増えても

物理的に無理なもんは無理なんですよ

あらかじめバッファをもって計画を立てておく

とはいえ設計時にどんだけ頑張っても多少の漏れや仕様変更は出てくる それを見越して計画を立てておかないとすぐに炎上案件が出来上がる

プロジェクト進行の責任者として時にはわがままを言う

自分「このデザインをお願いしたいんですけどいつ頃できそうですか?」

デザイナー「他の案件もあって忙しいので、来週の木曜とかでいいですか?」

自分「プロであるあなたの見積もりに絶対的信頼は置いてます。ただ、ここが進捗しないと次に大きな影響があります。一時的に優先度上げてもらって来週の火曜までにできませんか?」

デザイナー「なるほどー、わかりました。検討します」

自分「わがまま言ってごめんなさい」

デザイナー「いえ、進行管理に責任をもってるプロとして当然の発言だと思います」

という出来事が1回ありました。結果間に合わせることができました。

受容性の僕にはつらい行動でしたが、相手がプロであると同時に自分もプロなんですよね。

良い関係性だったのが幸いしました。

うまくいかなかったこと

自分が決めないとメンバーが動けない構造になっている時があった

自分でなんでもやりたくなってしまって、初期は仕様面の調整は全てやってる時期があった けっこう心理的負荷が高いのと、メンバーの手が空いてしまうタイミングがあった

「仕様面が一部決まってないですが、○○さんとコミュニケーションとって調整してください」 ってお任せできるようになってからはだいぶ楽になったし、普通に上手くやってくれる(助け舟はもちろん出す)

メンバーを信頼できてなかった反省と成長機会を奪ってた反省があった

燃えそうになったら最悪自分が土日出てなんとかすればいいやの考え方

責任感をもっているとも言えるんだけど

この考え方のせいでアラートを出すのが遅くなり外からリソースを借りることになった

それも自分の意思でヘルプを出したのではなく、マネージャーから提案された形で

早々に第三者意見を頼ればよかった

設計アイデアが煮詰まった時に重苦しい空気のまま、ひねり出そうとして時間を浪費したが

三者を頼った時にぐっと進捗した

自分たちだけで解決しなきゃという固定概念があったと思う

まとめ

ここに書ききれないくらい、まだまだ自分には課題はある

ただ、僕と一緒のチームでやりたいですとか、一緒にやってみてやりやすいですとか

自チームからも他チームからもありがたいフィードバックを数件いただいている

僕が困ってる時に助け舟を出してくれるメンバーもいる

仕事をする上で何より関係性が大事だと思うし

これからもメンバーの開発体験、ワーカーエクスペリエンスに真摯に向き合いながら仕事していきたい