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

Slide 1

Slide 1 text

【Product Engineer Night #7】プロダクトエンジニア一年生のしくじり〜フリーランスがプロダクトエンジニアになるまで〜アセンド株式会社宮沢拓真

Slide 2

Slide 2 text

2 今日お話ししたいことの前に 2 これからプロダクトエンジニア的な働き方を意識してやっていきたいんだ！もしくは最近気になり始めたんだ！と言う人どのくらいいますか？

Slide 3

Slide 3 text

3 今日お話ししたいことの前に 3 そういう方に向けた話です！

Slide 4

Slide 4 text

4 自己紹介 4 社会人になってからずっとフリーランスエンジニア宮沢拓真 Miyazawa Takuma プロダクトエンジニア 2024年4月にフリーランスを辞めアセンド入社プロダクトエンジニア一年目

Slide 5

Slide 5 text

5 今日お話ししたいことの前に 5 この一年目のしくじりを話します！

Slide 6

Slide 6 text

6 6 フリーランスエンジニアの特徴フリーランスはプロダクトエンジニアと真逆。フリーランスエンジニアプロダクトエンジニア任される単位タスク単位プロダクトの領域単位任され方仕様やデザインは決まっている自分で要件定義から行う

Slide 7

Slide 7 text

7 今日お話ししたいこと 7 今までのスタイルは真逆。業界のバックグラウンドもない。その中でのしくじりと学び。そんな僕が一年でどのようにプロダクトエンジニアとして成長し、一領域のオーナーになれたか。

Slide 8

Slide 8 text

8 8 どんなしくじりをしてきたか？ ③ 「PdM」「PjM」「エンジニア」の人格迷子 ① 顧客や営業の言うことを鵜呑みする ② オーナーシップが芽生えない ③ 「PdM」「PjM」「エンジニア」の人格迷子

Slide 9

Slide 9 text

9 9 しくじり　その1 顧客や営業の言うことを鵜呑みする

Slide 10

Slide 10 text

10 10 〇〇の機能が必要なんだけど... （CSの人が言うなら必要なんだろう...）はい〜。バックログ積んどくね〜。ちょっと待って！お客さんは何に困ってるの？よくよく話を聞いてみると… 〜ある日〜 CS 僕上司しくじり

Slide 11

Slide 11 text

11 11 全然違うソリューションに落ち着いた！しかも、最初に提案されていた機能よりはるかに手軽な改修で済むことがわかった！しくじり

Slide 12

Slide 12 text

12 12 最適解を導けるのはエンジニア ● CSのドメイン理解は高く、顧客との接点も多い ● 「彼らの言ってることが正しいのでは」と思い、話を深掘りしなかった ● 彼らはドメインエキスパートであっても、プロダクトに関しては我々の方が詳しい ● 「顧客の事情」と「プロダクトの事情」どちらも考慮した上で適正解を導けるのはエンジニア分析なぜ振り返り

Slide 13

Slide 13 text

13 13 背景情報を聴く・課題を再定義する今一度、何が起きたのか「ストーリーで聞くこと」を意識 HowではなくWhyを聞き出すことで、顧客が本当に困っていることを正しく定義し直す（課題の再定義）学び

Slide 14

Slide 14 text

14 14 「課題の再定義」について詳しくはぜひこのスライドを見てね https://speakerdeck.com/moeka__c/purodakut ojia-zhi-woyin-kishang-geru-ke-ti-nozai-ding-yi- toiuxi-guan 学び

Slide 15

Slide 15 text

15 15 しくじり　その2 オーナーシップが芽生えない

Slide 16

Slide 16 text

16 16 プロダクトの一領域の開発を 1人で完結できたぞ。ビジネスサイドからの要望に答えられているし、役に立ててるはずだ！〜またある日〜オペレーションレベルの視差で満足しくじり

Slide 17

Slide 17 text

受け身でタスクを実行するだけでなく、ロジックスがSaaSとしてどうあるべきか思考してください。それが出来ないと一領域のオーナーとして裁量権を渡していくことができません。 17 17 上司求められるレベルは違ったのか... プロダクト・ビジネスレベルの視座まで求められるしくじり

Slide 18

Slide 18 text

18 18 ビジョンがないと視座が上がらないプロダクトに対して自分なりの方向性やビジョンがない分析リアクティブなスタンスになってしまう

Slide 19

Slide 19 text

19 19 オーナーシップを養う自分の携わるプロダクトがどうあるべきかを思考して、主体的かつ前のめりな姿勢でトップラインをあげていくオーナーシップではオーナーシップはどうやったら養えるのか？分析

Slide 20

Slide 20 text

20 20 ロードマップで視座を上げる ● プロダクトロードマップを作る過程でドメイン知識が得られる ● 自分でプロダクトビジョンを考えるきっかけになる出来は気にせず、自分なりにロードマップを考えよう！学び

Slide 21

Slide 21 text

21 21 しくじりその3 「PdM」「PjM」「エンジニア」の人格迷子

Slide 22

Slide 22 text

22 22 お客さんに提案したいから、 ◯日までにこの機能が欲しいんだ！〜またまたある日〜営業ブラッシュアップしたいけど、スコープを広げたら絶対期限に間に合わない…どうすれば… 僕しくじり

Slide 23

Slide 23 text

23 23 何が起きているのかしくじり分析役割考えるべきことプロダクトマネージャークオリティ上げプロジェクトマネージャー期日管理エンジニア技術的な実現可能性プロダクトエンジニアの役割は三つ分析

Slide 24

Slide 24 text

24 24 しくじりの分析プロダクトのトップラインをあげないといけないのに、期日を気にして間に合うことを意識した仕様にしてしまうプロダクトマネージャーの人格とプロジェクトマネージャー×エンジニアの人格が喧嘩この3人格が自分の中でごっちゃになる。分析

Slide 25

Slide 25 text

25 25 適切に人格を使い分けましょう！

Slide 26

Slide 26 text

26 26 は難しいので、

Slide 27

Slide 27 text

27 27 目的を変えることで役割を使い分けるフェーズによって目的を変えましょう！フェーズ目的役割要件定義フェーズ toBeを見据えるプロダクトマネージャー詳細設計フェーズ今回どこまで作るかどうやって作るかプロジェクトマネージャーエンジニア要件定義では理想の姿（toBe）を描くスコープ調整は後で考えるとブレなく進められる学び

Slide 28

Slide 28 text

28 まとめ 28 教訓その1 「〇〇が必要」をそのまま受け取らず、「なぜそれが必要なのか」を深掘りする。課題の本質を理解すれば、より適切でシンプルな解決策が見えてくる。教訓その2 言われたことをこなすだけでは成長しない。ロードマップを描くことでドメイン理解が深まり、自分なりのビジョンを持って視座高く動けるようになる。教訓その3 PdEの役割は状況に応じて切り替えるべきもの。要件定義では理想の姿（toBe）を描き、スコープ調整は後で考えるとブレなく進められる。

Slide 29

Slide 29 text

29 最後に 29 とはいえ、今回話したことも僕自身まだ全然出来てないので、一緒にしくじりながら成長していきましょう！僕のしくじりが少しでも皆さんの学びに繋がれば幸いです。

Slide 30

Slide 30 text

We are hiring !!! 30 プロダクトエンジニアを切実に求めています。宮沢拓真の 𝕏 (@westlagoon114) お気軽にフォローください。生産性高く Full Stack TypeScript で開発したいプロダクトエンジニア募集！