こんにちは、クロスオーダー請求書チームでバックエンドエンジニアをしている中松です。今回は、最近挑戦している「PMへの道」についてお話しします。
はじめに
約1年前にバックエンドエンジニアへと転向しましたが、今もキャリアについて悩んでいます。技術者としてさらに専門性を高めるべきか、マネジメント方向に進むべきか…まだ答えは見つかっていません。私のチームにはPM（プロダクトマネージャー）が1人しかおらず、小さな案件がたくさんあるので、少しでも力になれないかとPMに興味を持ちました。以前の職場ではエンジニアとデザイナーの橋渡し役をしていたこともあり、コミュニケーションが好きな自分には多少向いているのではと思ったのです。その話をマネージャーに軽く相談したところ、「やってみましょう！」と快諾してくれ、この挑戦が始まりました。こうしたスピード感と、やりたいことに挑戦させてくれる環境は、弊社の大きな魅力です。
PMとは
ここでいうPMは「プロダクトマネージャー」のことです。プロダクトマネージャーは、製品（物理的製品とデジタル製品の両方）開発のリード役で、ビジネス戦略を立て、機能要件を特定して立ち上げまでを導く役割です。現在、私が担当している範囲ではディレクター的な役割も含まれ、ビジネスチームやお客様からの要望を基に、要件を決めて実装内容を検討する役割を担っています。エンジニアからPMに転向され、活躍されている方も知っているので、エンジニアとPMは親和性が高いのではないかと感じています。
要件定義1件目
同じチームにはPMに興味があるエンジニアがもう1人いるため、彼と一緒に1つの案件を担当しました。先輩PMの作成してくれた勉強会資料やテンプレートを活用しながら進めました。今までの案件資料を改めて見直すと、「なぜ作るのか」「作ることでどんな課題が解決され、ビジネスチャンスがあるのか」が詳細に記載されています。今までエンジニアとして作業する際、こういった部分に疑問を持つことが少なく、流し見していた自分にハッとさせられました。この部分を重要に感じているデザイナーやエンジニアも多いはずです。ただ、言われたものを作っているだけでいいのか、とエンジニアとしても浅かったなぁと反省しました。
ある程度要望を機能に落とし込み、CSの方にヒアリングを行いながら疑問点を解消し、使いやすいものにするための確認を行いました。最後にもう1人のメンバーとアイデアを持ち寄り、最終的にどんなものをアウトプットするかを検討しました。先輩PMさんに言われたのですが、エンジニア視点からいくと不要なものや難しそうなものが要件から落とされていて、良くも悪くもシンプルになっているということでした、実際、実現できるかどうか、実装コストがある程度予想できる分、これは必要なのか？と勝手に落としてしまっている部分がありました。本当にユーザーが必要なことが実現され、使いやすいものになっているのかと、いいバランスをとって仕様を決める必要があります。作っても誰にも使われないような機能になってしまっては意味がありません。時には実装が難しくても挑戦してみる必要がある仕様もあるのです。
要件定義2件目
現在、2件目の要件定義を1人で進めています。前回よりも分かりやすい機能だったため、ヒアリングを進めながらデザイナーにデザインを依頼する段階まで来ました。しかし、請求書サービスの現状を完全に把握しておらず、既存の機能を使えば簡単に済んだ部分を見落としていました。日々進化するサービスを完全に把握するのは難しいですが、少しでも現状をしっかり確認しておくべきだったと反省しました。また、ヒアリングの際に自分の考えを伝えることの難しさを感じ、説明力不足を痛感しました。当たり前なのですがPMだけでなく、誰にとっても、説明力は必要だと実感しています。
まとめ
元々プロジェクトマネージャー、ディレクターがいない環境でユーザーと直接小さいプログラムを作っていたので要件定義なんてそんなに難しくないだろうと思っていたのですが、人に作ってもらうお願いしなければならないというのが、より作る意味や内容を説明するという部分で非常に難しいです。確かに自分もよくわからない設計書をもらってもなんで作らなあかんねん〜ってなることはあるので、エンジニアの立場もわかる分より丁寧に作らなければいけないです。自分が何になっていくのか、というところはまだわかりませんが、いろんな人の立場を経験することで一緒に働く人によりリスペクトを持って仕事ができそうな気がしています。バックエンドの仕事がメインにはなりますが、もう少しPMのお仕事も経験したいです。
個々のやりたいことに挑戦させてくれるクロスマートの開発チームに興味を持ってくださったなら、ぜひ採用ページもご覧ください！ xorder.notion.site
