プロダクトエンジニア一年生のしくじり 〜フリーランスがプロダクトエンジニアになるまで〜

Transcript

1. 【Product Engineer Night #7】 プロダクトエンジニア一年生のしくじり 〜フリーランスがプロダクトエンジニアになるまで〜 アセンド株式会社 宮沢拓真
2. 2 今日お話ししたいことの前に 2 これからプロダクトエンジニア的な働き方を 意識してやっていきたいんだ！ もしくは最近気になり始めたんだ！ と言う人どのくらいいますか？
3. 3 今日お話ししたいことの前に 3 そういう方に向けた話です！
4. 4 自己紹介 4 社会人になってからずっと フリーランスエンジニア 宮沢 拓真 Miyazawa Takuma プロダクトエンジニア 2024年4月にフリーランスを辞め アセンド入社 プロダクトエンジニア一年目
5. 5 今日お話ししたいことの前に 5 この一年目のしくじりを話します！
6. 6 6 フリーランスエンジニアの特徴 フリーランスはプロダクトエンジニアと真逆。 フリーランスエンジニア プロダクトエンジニア 任される単位 タスク単位 プロダクトの領域単位 任され方 仕様やデザインは 決まっている 自分で要件定義から行う
7. 7 今日お話ししたいこと 7 今までのスタイルは真逆。 業界のバックグラウンドもない。 その中でのしくじりと学び。 そんな僕が一年でどのようにプロダクトエンジニアとして成長し、 一領域のオーナーになれたか。
8. 8 8 どんなしくじりをしてきたか？ ③ 「PdM」「PjM」「エンジニア」の人格迷子 ① 顧客や営業の言うことを鵜呑みする ② オーナーシップが芽生えない ③ 「PdM」「PjM」「エンジニア」の人格迷子
9. 9 9 しくじり　その1 顧客や営業の言うことを鵜呑みする
10. 10 10 〇〇の機能が必要なんだけど... （CSの人が言うなら必要なんだろう...） はい〜。バックログ積んどくね〜。 ちょっと待って！お客さんは何に困ってるの？ よくよく話を聞いてみると… 〜ある日〜 CS 僕 上司 しくじり
11. 11 11 全然違うソリューションに落ち着いた！ しかも、最初に提案されていた機能より はるかに手軽な改修で済むことがわかった！ しくじり
12. 12 12 最適解を導けるのはエンジニア • CSのドメイン理解は高く、顧客との接点も多い • 「彼らの言ってることが正しいのでは」と思い、話を深掘りしな かった • 彼らはドメインエキスパートであっても、プロダクトに関しては 我々の方が詳しい • 「顧客の事情」と「プロダクトの事情」どちらも考慮した上で適 正解を導けるのはエンジニア 分析 なぜ 振り返り
13. 13 13 背景情報を聴く・課題を再定義する 今一度、何が起きたのか「ストーリーで聞くこと」を意識 HowではなくWhyを聞き出すことで、 顧客が本当に困っていることを正しく定義し直す（課題の再定義） 学び
14. 14 14 「課題の再定義」について詳しくはぜひこのスライドを見てね https://speakerdeck.com/moeka__c/purodakut ojia-zhi-woyin-kishang-geru-ke-ti-nozai-ding-yi- toiuxi-guan 学び
15. 15 15 しくじり　その2 オーナーシップが芽生えない
16. 16 16 プロダクトの一領域の開発を 1人で完結できたぞ。 ビジネスサイドからの要望に答えられ ているし、役に立ててるはずだ！ 〜またある日〜 オペレーションレベルの視差で満足 しくじり
17. 受け身でタスクを実行するだけでなく、ロジックスがSaaSと してどうあるべきか思考してください。 それが出来ないと一領域のオーナーとして裁量権を渡してい くことができません。 17 17 上司 求められるレベルは違ったのか... プロダクト・ビジネスレベルの視座まで求められる しくじり
18. 18 18 ビジョンがないと視座が上がらない プロダクトに対して自分なりの方向性やビジョンがない 分析 リアクティブなスタンスになってしまう
19. 19 19 オーナーシップを養う 自分の携わるプロダクトがどうあるべきかを思考して、 主体的かつ前のめりな姿勢でトップラインをあげていく オーナーシップ ではオーナーシップはどうやったら養えるのか？ 分析
20. 20 20 ロードマップで視座を上げる • プロダクトロードマップを作る過程でドメイン知識が得られる • 自分でプロダクトビジョンを考えるきっかけになる 出来は気にせず、自分なりにロードマップを考えよう！ 学び
21. 21 21 しくじりその3 「PdM」「PjM」「エンジニア」の人格迷子
22. 22 22 お客さんに提案したいから、 ◯日までにこの機能が欲しいんだ！ 〜またまたある日〜 営業 ブラッシュアップしたいけど、スコープを広げた ら絶対期限に間に合わない…どうすれば… 僕 しくじり
23. 23 23 何が起きているのか しくじり分析 役割 考えるべきこと プロダクトマネージャー クオリティ上げ プロジェクトマネージャー 期日管理 エンジニア 技術的な実現可能性 プロダクトエンジニアの役割は三つ 分析
24. 24 24 しくじりの分析 プロダクトのトップラインをあげないといけないのに、 期日を気にして間に合うことを意識した仕様にしてしまう プロダクトマネージャーの人格と プロジェクトマネージャー×エンジニアの人格が喧嘩 この3人格が自分の中でごっちゃになる。 分析
25. 25 25 適切に人格を使い分けましょう！
26. 26 26 は難しいので、
27. 27 27 目的を変えることで役割を使い分ける フェーズによって目的を変えましょう！ フェーズ 目的 役割 要件定義フェーズ toBeを見据える プロダクトマネージャー 詳細設計フェーズ 今回どこまで作るか どうやって作るか プロジェクトマネージャー エンジニア 要件定義では理想の姿（toBe）を描く スコープ調整は後で考えるとブレなく進められる 学び
28. 28 まとめ 28 教訓 その1 「〇〇が必要」をそのまま受け取らず、「なぜそれが必要なのか」を深掘りする。 課題の本質を理解すれば、より適切でシンプルな解決策が見えてくる。 教訓 その2 言われたことをこなすだけでは成長しない。ロードマップを描くことでドメイン理解が 深まり、自分なりのビジョンを持って視座高く動けるようになる。 教訓 その3 PdEの役割は状況に応じて切り替えるべきもの。要件定義では理想の姿（toBe）を描 き、スコープ調整は後で考えるとブレなく進められる。
29. 29 最後に 29 とはいえ、 今回話したことも僕自身まだ全然出来てないので、 一緒にしくじりながら成長していきましょう！ 僕のしくじりが少しでも皆さんの 学びに繋がれば幸いです。
30. We are hiring !!! 30 プロダクトエンジニアを切実に求めています。 宮沢 拓真の 𝕏 (@westlagoon114) お気軽にフォローください。 生産性高く Full Stack TypeScript で開発したい プロダクトエンジニア募集！