エンジニアとPdMを兼任して良かった/大変だったこと

-------------------------------------------------------
この記事はQiitaのProduct Manager Advent Calendar 2019の2日目に向けて書きました。普段はTwitterにいることが多いので、興味を持ってくださった方はTwitterでも繋がれると嬉しいです！
-------------------------------------------------------

エンジニア歴1年少しの私ですが、今年の新規開発でPdMとフロントエンドエンジニアを兼任する機会がありました。

約5ヶ月の開発期間で感じた、エンジニアがPdMを担当することのメリット/デメリットを共有したいと思います。

PdMとエンジニアを兼任するキッカケ

大きな企業だと、PdMとエンジニアは採用から分かれていることが多く、一つのプロダクト内での兼任はめったに無いと思います。
弊社の場合、昨年までPdM的な役割はCTOがすべて担っていました。

しかし、今年はプロダクト数の増加、メンバーの入れ替わりなど環境が変わり、その中で始まった新規開発において、CTOからPdMにアサインされたのがキッカケです。

エンジニアがPdMを兼任するメリット

1. 技術面も含めた決定がスムーズ

新規開発中に仕様やデザインの変更が生じると、実作業の追加や各関係者への確認でスケジュールは遅れがちになります。
その際、関係者間を取り持つのがPdMの役割かと思いますが、今回は私が開発も担当していたことで、変更時のコミュニケーションは比較的スムーズでした。

例えば今回、本リリース10日前に「これでは、表示されている値の意味をユーザーが勘違いする可能性がある」とUI上の問題をセールスチームに指摘されました。

すぐにデザイナーと代替案の相談に入りましたが、リリース直前ということもあり工数ギリギリです。

幸い、APIの変更が不要なことと、フロントエンドを私が担当していたこともあり
- 代替案に対する工数の見積もり
- 全体のスケジュールへの影響
- ドキュメントやユーザーに配布したマニュアルへの影響

をその場でまとめて確認して決定をすることができました。

2. 技術面のリスクに早めに気付ける

今回の新規プロダクトは、既に社内で運用されている別プロダクトのデータを一部で使用するものでした。

そのため、仕様が決まったタイミングで

- どのプロダクトからデータを引くのか
- データの持ち方がプロダクトごとで異なっていないか
- そのデータは新規プロダクトで必要なタイミングで入力されているのか

など、運用も含めたチェックをすぐに行いました。
ここには別プロダクトのエンジニアからも、たくさん協力を得ています。

実際に、「ユーザーのステータスa, b, cをプロダクトAから引けると思っていたが、プロダクトAではステータスがa, bにしか分かれておらず、ステータスｃを追加する必要がある」など、関連プロダクトの修正が必要な箇所も見つかり、ドキッとしたのを覚えています...。

これらの情報は、遅くともAPI作成時には発覚するものですが「仕様が決まった時点で少しでも早くチェック・修正する」ことが大切です。

なぜなら
- 新規プロダクトと関連プロダクトを同じエンジニアが担当していると、修正でスケジュールが遅延する
- プロダクトの修正がリリースに間に合っても、運用上必要なデータがまだ入っていない、という事態が起きる

からです。

今回すぐに関連プロダクトの確認が必要だ！と判断できたのも、他のエンジニアとのコミュニケーションをスムーズに進められたのも、PdMに仕様・運用・開発の知識が（最低限ですが）あったからだと思います。

こういった技術・データ面を含んだリスクヘッジはエンジニアの得意分野になるのではないかと感じました。

エンジニアがPdMを兼任するデメリット

1. エンジニアとしての自分を消す必要がある

今回はワイヤーフレームも私が作成しましたが、フロントエンドエンジニアが本職なので、ついつい「こっちの構造にすると(Vueの)コンポーネント使い回せるよなぁ...」「これ組むの大変だな」と考え始めてしまいます。

しかし、ワイヤーフレームを作る段階では、プロダクトの目的を達成するためにベストのものを考える必要があり、実装面のことを考えてはいけません。

プロダクトの初期段階から実装を考えすぎることは、過剰な守り（工数削減や作りやすさの重視）に繋がり、プロダクトの可能性を潰すことに繋がります。
エンジニア×PdMがやらかしがちなミスではないかなと感じました。

2. 集中力がもたない

PdMの業務は、ものすごくざっくり言えば「課題を見つけて解決すること」だと思いますが、普段のエンジニア業務はコードを書いて「解決すること」がメインです。

そのため、課題を見つけるために別チームとコミュニケーションを取ったり、自分の意見を伝えるために多くの文章を書くのは、普段の業務とかなり異なりエネルギーを使う部分でした。

また、開発が始まるとPdMの業務とエンジニアの業務が並行して進みます。
タイプの違う仕事を同時に進めると、どうしても切り替えが難しく集中力や効率が落ちてしまう...。
私は自分で「コードを書く日」「セールスチームと話しながらドキュメントを作る日」というように、PdM業務とエンジニア業務を日毎に分けて対応していました。

3. 業務量もプレッシャーも増える

これは兼任が決まった時点で分かっていたので、デザイナーに最初にUIを作ってもらい早めにコーディングに入る、長期休暇をずらして差込み作業が入る可能性を減らす、などで調整していました。

ただ、実装がうまく進まないときは、自分で決めたスケジュールを自分が遅らせるのでは...？と言う不安に駆られるときもありました。
開発リーダーや先輩エンジニアなど、素直に周りに頼ってメンタルを保つのも仕事です！！

これからのキャリアについて

エンジニアのキャリアもまだ2年目に入ったばかりですが、今後の選択肢として早めにPdMの経験ができたのはとても良かったと思います。

ユーザーインタビューやセールスチームとの打ち合わせなど、普段のエンジニア業務ではできない経験を通して、自分の書くコードがユーザーに与える意味、そしてビジネスとして会社に与える意味を考えるきっかけになりました。

今後、私ができることは、「技術も分かるPdM」を目指して今のプロダクトをメンバーと一緒に進化させていくこと。もしくは、「UX/ビジネス面の知識もあるエンジニア」を目指して(独学でも)知識と経験を重ねることだと考えています。

------------------------------------------------------------------------
この記事は、第1回 名古屋初心者LT大会で話した内容を含みます。
時間の都合上、話せなかった内容も追加して、改めてまとめました。

当日のスライドはこちらからご覧ください。
------------------------------------------------------------------------