PM業を経験して学んだソフトスキル

簡単に自己紹介

東京の企業でフロントエンジニアをしているhoriettyです。
2年ほど前にエンジニアの転職し、総勢20名ほどのベンチャーで働いています。
転職前はPCやOA機器を取り扱う専門商社や、清掃業をしており今の会社に入社するまではエンジニアとしての知識は全くありませんでした。
そんな私が一年ほど前から現在にかけて経験したPM業を通じて学んだ知識をここでお伝えできればと思いこの記事を書きました。

どうしてこの記事を書いたか

• 記事にすることで自分の知識として定着させる
• 自分と似た境遇の人の手助けになれば良い

こんな人に読んでもらいたい

• PMもやることになりそうなエンジニア
• 開発一本だけどPMの仕事を理解したいエンジニア

PMの前提

私の経験は一般的なPMとは少し違うのでざっくりその説明です

• 一般的なPM業
  • 要件定義、デザイン、バックエンド、フロントエンドの進捗や実装をマネージメント
• 私の場合
  • フロントエンドのみの進捗や実装をマネージメント

今回携わったプロジェクトは一般的にPMと言われる立場がおらず、各ジャンルのPMでMTGを行ない進捗や実装を共有しておりました
私はフロントエンドのPM的な立場だった為MTGに参加し、決まった仕様から他のフロントエンドメンバーに対しタスクの棚卸しやスケジューリングを行っていたので一般的なPM業とは異なる場合がありますがご了承ください。

心構

最優先はプロダクト

当たり前のことですが、最優先はプロダクトの成功です。
成功の定義はいくつかあると思いますが、私はプロダクトの収益拡大、リリース期限の遵守の二点を最優先事項としていました。
プロダクトの収益拡大のためのデザイナーやクライアントとの議論はフロントエンドの立場でも必要と感じましたし、実際そこから理解を深めておくことでフロントの開発も非常にスムーズに進みます。
リリース期限の遵守を実現するにはフロントの開発が止まっている状態を作らないことが重要だったので、そういった意味でも上記の議論は意味のあるものでした。

不透明な部分は先に調査しておく

不透明な箇所を不透明なまま進めていくと後々大変なことになりかねないので先に調査しておきましょう。
たとえば、「たぶんできる」で実装が決まり開発していたものが1ヶ月後に無理だとわかったときの大変さは誰でも想像つくと思います。
それを避けるためにも調査できるものは先に調査しておくといいです。

PMで苦労した点

絶望 モックアップ編

私の場合まずモックアップを作るところから始めました。
最低限の機能、導線とは言いつつプロダクト全体の基盤になるものだったのですが、ほぼ自分一人で作ってしまったためその後の本格的な開発が始まる際に他のフロントエンドメンバーを巻き込むのにかなり時間を割いてしまいました。
この様なケースを避けるためには、簡易的なモックアップの段階から他のメンバーにお願いするのが一番の理想形です。
メンバーが忙しくお願いするのが難しい場合でも、モックアップ完成後にメンバーを集め30分だけでもプロダクトの概要や仕様を伝えておくべきでした。

不安いっぱい MTG編

今まで頼まれた実装しかしてこなかった私が、急に全体のMTGに参加するのはもちろん不安です。
私の回答ひとつで機能が増え、期限が決まるなどもちろん経験したことはないからです。
中でも困ったのがMTG内で新たに生まれる新案に対しての返答。
優秀なエンジニアならばその場で実現可能かの判断、スケジュールなどを伝えられると思いますがまだまだ私にそこまでの知識はありませんでした。
これはどうしても起こり得ることなので、可能であれば知識豊富なエンジニアに同席を求めるかどうしても無理な場合は持ち帰って判断を仰ぎましょう。
わからないからといって適当な返答をしてしまうのは無責任なことですし、炎上のきっかけにもなりかねません。
また、上記はあくまで新案に対しての対応なので事前に議題に上がりそうなことへの深掘りや、ざっくりとしたアジェンダ準備はしておくことをお勧めします。

何やればいいんだ タスク整理 & 棚卸し編

PMの最重要タスクといっても過言ではないこちら。
絶望 モックアップ編からもわかる通り一旦自分で進めて後で人にお願いしよう精神でいるとフロント開発全体の手が止まることになるので要注意です。
やることはMTGで決まった仕様を落とし込みタスクとして切り出しメンバーにアサインするというものですが、粒度の大きい物をそのままお願いしても誰も動けません。
アサインする際はこんなイメージでやりましょう。

MTG直後（新たに実装する機能たち）

• 機能A
• 機能B
• 機能C

実際にアサインする時

• 機能A(タスク1 ~ 4が完了すると機能が完成)
  • タスク1
  • タスク2
  • タスク3
  • タスク4
• 機能B(タスク1 ~ 4が完了すると機能が完成)
  • タスク1
  • タスク2
  • タスク3
  • タスク4
• 機能C(タスク1 ~ 4が完了すると機能が完成)
  • タスク1
  • タスク2
  • タスク3
  • タスク4

とても簡易的な書き方で申し訳ないですがこんな感じです。
タスクごとにメンバーにアサインして進めてもらい、粒度の大きい機能を実装する。
実際には各タスクごとに順番があったり留意点、期限もあるのでその辺りもしっかりと共有することが大事です。
タスクをお願いする際に一番重要なのはいかにわかりやすく実装内容を伝えるかなのでそこには細心の注意を払いましょう。
また、実装内容に外部のプラグインが必要なケースもあると思いますが、そういった基盤作りはPMの方がやるとよりスムーズに進みます。
逆に言うとPMは基盤の開発メインで機能の実装などはメンバーに任せるイメージでもいいと思います。

どきどき リリース編

ここまでの業務を続けていると気づけばプロダクトも完成に近づき、いよいよリリースの日を迎えます。
リリース自体はあっという間に終わりますが、怖いのがリリース直後のバグ。
どんなリリース後もQAを行うと思いますが、重大なバグの見落としがない様なるべく多くのメンバーにプロダクトを触ってもらう時間を確保しましょう。
リリース当日や直前に言ってもなかなかメンバーの都合はつかないと思うので、事前にリリース日時を周知して大人数でQAを行うことをお勧めします。

まとめ

PMと聞いて「楽な仕事だー」と思う人はいないと思います。
私自身、最初にやることになった時は自分に務まるイメージすら湧きませんでした。
実際、序盤はなにをするかもわからずうまくいかないことだらけでしたが、周りの助言や失敗から学びなんとかリリースまで漕ぎ着けることができました。
PMといっても一人で全てをやるわけではないので、困った時には誰かに聞いたりして進めていければいいと思います。
この記事を読んで現在PM業をやっている人の肩の荷が少しでも降りたり、PM業に興味を持つ方が増えたら嬉しいです！