PLAY DEVELOPERS BLOG

HuluやTVerなどの日本最大級の動画配信を支える株式会社PLAYが運営するテックブログです。

HuluやTVerなどの日本最大級の動画配信を支える株式会社PLAYが運営するテックブログです。

PM を経験したことでエンジニアとしての働き方はどう変わったか

こんにちは。2024年5月に中途入社しました、OTTサービス技術部第2グループの千葉です。

私は前職でエンジニアとしてのキャリアをスタートし、その後、エンジニアとして開発業務を続けながらプロジェクトマネージャー(PM)も兼務して、自社サービスの開発に携わっていました。 そして現在はPLAYでエンジニアとして、動画配信サービスの開発を行っています。

エンジニアとPMを両立する立場を経験したことで、技術的な視点だけでなくプロジェクト全体を俯瞰する視点を意識するようになり、少しずつですが以前より広い視野で物事を捉えられる場面が増えたと感じています。その経験は、現在のエンジニア業務にも少しずつ活かされていると思います。

今回は、エンジニアがPMを経験することで得られた視点や学び、そしてそれが現在のエンジニアとしての働き方にどのように影響しているのかをお伝えできればと思います。

エンジニア業務に活きるPM経験の学び

PMを兼務していた時期を振り返ると、エンジニアだけだった頃とは違う視点が増えたなと感じます。ここでは印象に残っているポイントを取り上げながら、エンジニア業務にどのように役立っているかをお話しします。

コミュニケーションの重要性

PMとして活動する中で、エンジニア同士のコミュニケーションだけでなく、ビジネスサイドやデザイナー、カスタマーサポートなど、関わるメンバーが広がりました。それまでは開発チーム内での情報共有が中心でしたが、PMとしては様々な役割の人たちとうまく連携しなければなりません。その中で、相手の立場を考えながらどう情報を伝えるかを学べたと思います。特に、技術的な説明をエンジニアではない方でも理解できるように噛み砕いて伝える工夫をしたり、専門用語を避けたりといった配慮をすることは意識しました。例えば、システムの挙動や技術的な制約を説明する際には、専門用語をそのまま使わずに、図や例え話を用いて噛み砕いて説明するようにしました。最初はうまく伝わらずに苦労することもありましたが、相手の立場や理解度に合わせた伝え方を意識することで、少しずつ伝わるようになったと感じています。

プロジェクトが進むにつれて、メンバーの役割や目的を理解し合えるようになり、意思疎通がスムーズになりました。結果的に意見交換が活発になり、信頼関係も深まったと思います。この経験は現在のエンジニア業務にも活かされており、コードレビューや仕様調整の場面などで、相手に合わせたコミュニケーションを取ることでスムーズに作業を進めることができています。

このテーマについては、『他者と働く──「わかりあえなさ」から始める組織論』(他者と働く──「わかりあえなさ」から始める組織論 | 宇田川 元一 |本 | 通販 | Amazon)から多くを学びました。立場や役割の異なる方とコミュニケーションをする上での具体的なテクニックが豊富に紹介されているので、エンジニアの皆さんにはぜひ一読をおすすめしたいです。

リスク管理や優先度付け

PMとしてプロジェクトを進めるうえで、不確実性をできる限り減らしつつ「どれを先に手がけるべきか」を見極める大切さも学びました。エンジニアとしては「どう実装するか」に関心が向きがちですが、PMの視点だと「今いちばん重要なことは何か」「どんなリスクが潜んでいるか」を常に考えるようになります。

たとえば、要件定義の段階で不確定要素を洗い出したり、開発期間にバッファを持たせるなど、小さな工夫を積み重ねることで大きな手戻りを防ぎやすくなります。仕様変更があっても慌てずに対処できたり、予定外のトラブルに柔軟に対応できたりするメリットは大きかったです。

優先度を意識しながら作業を進める癖がついたことで、手戻りを最小限に抑えたり、予想外のトラブルに対しても冷静に対処したりできるようになったと思います。

チーム全体の調整やサポート

PMとして活動していた時期は、チーム全体の進捗状況やタスクの偏りに気を配っていました。エンジニア業務のみを担当していると、自分のタスクをこなすことに注目しがちですが、PMを兼務したことで「チーム全体でどう動けば効率が良いか」を考えるようになりました。

特に意識していたのは、以下の点です。

進捗の見える化

プロジェクト全体の進捗が見えにくい状態だと、遅延に気づくのが遅れてしまいます。そのため、タスク管理ツールを活用して進捗状況を可視化し、チーム全体が「今どの作業が優先なのか」「どのタスクが遅れそうなのか」を把握できるように工夫しました。

ブロッカーの早期発見

開発が止まる要因(ブロッカー)が発生した場合、放置するとチーム全体の進捗に影響が出てしまうことがあります。PMとしては「どのタスクが止まっているか」「その原因は何か」を早めに把握し、メンバー同士の連携をサポートすることで、ブロッカーをできるだけ早く解消するようにしました。

こうした取り組みは、現在のエンジニア業務でも活きています。自分のタスクだけでなく、チーム全体の進捗を意識し、周りのメンバーが困っているときはフォローに回るなど、自然にサポートできるようになったと思います。

エンジニア視点でのPM経験の価値

PMの経験を通して、エンジニアとしての視野や考え方が大きく広がりました。普段は技術的な課題や実装方法に集中しがちですが、「プロジェクト全体をどう動かすか」「ビジネスの意図をどう技術に落とし込むか」といった視点にも目を向けるようになったのは大きな変化です。

たとえば、ステークホルダーとの調整やリスクの洗い出し、優先度の判断など、エンジニアだけではあまり深入りしない領域にも携われたことで、「なぜこの機能が必要なのか」「どんな成果が期待されているのか」といった目的意識を持ちながら開発に取り組む習慣が身につきました。

さらに、プロジェクト全体の流れを意識することで、自分のタスクがどこにどう影響するのかを考えるようになりました。結果として、「今やっている作業は本当に最優先なのか」「この判断が後続の工程に影響を及ぼさないか」といった視点が身につき、タスク管理や優先度の柔軟な調整に役立っています。

振り返ると、PM経験は技術的な成長だけでなく、「エンジニアとしての動き方」を見直す良いきっかけになったと思います。チームとして最大限の力を発揮するにはどうすればいいか、自分はどんな役割を担うべきか。そうした問いを常に考えるようになったのは、PM経験のおかげだと感じています。

まとめ

PMとしての経験は、エンジニアとしての視野や考え方を広げる貴重な機会でした。技術的な視点だけでなく、プロジェクト全体やビジネス的な側面を意識することで、チームがどう動けばより良い成果を出せるのかを考えるようになったと思います。

エンジニアとしてコードを書くことに集中する時間ももちろん大切ですが、その先にある「なぜこの機能が必要なのか」「プロジェクト全体の中で自分のタスクがどう影響するのか」といった視点を持つことで、日々の業務の質も変わってきました。

PMとしての経験を通じて得た知識や視点は、今のエンジニア業務にも自然と活かされていると感じています。技術とマネジメントのどちらかに偏るのではなく、両方の視点をバランスよく活かしながら、これからもより良いサービスづくりに挑戦していきたいと思います。

もし機会があれば、皆さんもぜひPMの役割を経験してみてはいかがでしょうか。