プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと

Transcript

1. プロダクト志向なエンジニアが もう一歩先の価値を目指すために 意識したこと ProductEngineerSession #3 2025/06/26 株式会社ニーリー　石倉和真

2. 2 自己紹介 石倉 和真(Kazumasa Ishikura) @kazu_real20 株式会社ニーリー　プロダクト開発リード • 2022年にニーリーに参画 •

   キャリア：DMM.com → ニーリー • 主にtoB領域のグロースに係る案件を日々フルサイクルに担当 • 元々はギタリストとして活動していたことも🎸

3. 3 事業・プロダクト紹介

4. 4 本日のお話 1. プロダクト志向なエンジニアという自負はあるが... 2. もう一歩先の価値を目指すために意識したこと 3. 意識したことで得られたこと 4. まとめ

5. プロダクト志向なエンジニア という自負はあるが... 5 1

6. 6 プロダクト志向なエンジニアという自負はあるが... 「この機能、ユーザーのためになってる？」 「自分のコードがどうビジネスに貢献してるかわからない…」 前職時代の僕

7. 7 プロダクト志向なエンジニアという自負はあるが... 入社後初の評価面談で次のフィードバックをいただく😭 １）顧客要望を素直に受け入れすぎ ２）業務・オペレーションに対するDeepDiveが足りない

8. 8 プロダクト志向なエンジニアという自負はあるが... 半期の取り組みを振り返ると、たしかに...と頷かされた😮 １）顧客要望を素直に受け入れすぎ ”何を解決すべきか” ”なぜ解決すべきか”ではなく、”どのように実現するか”ばかり考えていた。 ２）業務・Opsに対する深掘りが足りない 要求しか見えていなかったために、その先にある業務やオペレーションに対して意識が及んでいなかった。

9. もう一歩先の価値を 目指すために意識したこと 9 2

10. 10 もう一歩先の価値を目指すために意識したこと 改善するために意識するようにしたこと １）Who / What / Why を意識したコミュニケーション 誰の何を解決するもので、それをなぜ今やるべきなのかを整理する。

    疑問や不足情報があれば、その時点でヒアリングする。 ２）リリースだけでなく、その後の運用に対しても関心を持つ リリースされて終わりではなく、リリース後のフォローまでをセットで考える。 機能が評価されるのは運用に載ってから。 → 運用に載らない機能は評価すらされない。 既存業務・オペレーションを理解し、機能をどうやって組み込むかを模索し、ユーザにとっての使いやすさを 意識する。

11. 11 もう一歩先の価値を目指すために意識したこと Episode. 申込者の審査自動化機能を実装した時の話... ◆ 要求概要 • 申込者情報が特定条件に抵触するかを自動的に判定し、 抵触したものはリストアップ・担当者が目検でチェックできるようにしたい •

    抵触しない場合は、自動的に審査通過として処理させたい • 併せて、審査で扱う情報の管理も画面からできるようにしたい

12. 12 もう一歩先の価値を目指すために意識したこと Episode. 申込者の審査自動化機能を実装した時の話... ◆ Who / What の把握 •

    一部申込者に対して、”顧客担当者”が目検で審査を行なっている • 審査のやり方は固まっているが、1件1件目検するのはかなり工数がかかる • 担当者が本来やるべき業務にリソースを充てられる状況を作りたい To-Be（あるべき姿）の把握だけでなく、 As-Is（今抱えている課題・状況）を把握することを特に意識

13. 13 もう一歩先の価値を目指すために意識したこと Episode. 申込者の審査自動化機能を実装した時の話... ◆ Why の把握 • 審査で扱う情報の特性上、業務を担当者以外へ分散することも難しい •

    新規申込者は右肩上がりだが、増加に伴って審査対象数が増大しており、審査業務 の工数が既に逼迫している • なので、審査業務を省力化を図るために、審査業務を自動化したい この要望で期待する効果が何かの具体を知る。 抑えるべきポイントを意識することで、期待ギャップを小さくする。

14. 14 もう一歩先の価値を目指すために意識したこと Episode. 申込者の審査自動化機能を実装した時の話... ◆ 運用・オペレーションの把握 局所最適ではなく、全体最適を図るために、 フローの全体像の把握、そして改善すべき工程の具体を把握する。

15. 15 もう一歩先の価値を目指すために意識したこと Episode. 申込者の審査自動化機能を実装した時の話... ◆ WF・プロトタイプを作成し、具体情報を基に迅速に仮説検証する 具体情報を頻繁に共有し、早期により具体なフィードバックを得る。 開発段階から期待ギャップを小さくすることを意識する。

16. 16 もう一歩先の価値を目指すために意識したこと Episode. 申込者の審査自動化機能を実装した時の話... ◆ WF・プロトタイプを素早く作成し、成果物の具体イメージをこまめにすり合わせる 大前提として... • 要求解釈を誤ると期待ギャップは容易に生ま れる

    • 顧客の頭の中で言語化できていない部分 （暗黙知）は要求に現れない ことを意識する。 仮定を避け、具体（プロトタイプ）で議論する ことが、期待ギャップを埋めることにつながる。 出典 ：https://pages.uoregon.edu/ftepfer/SchlFacilities/TireSwingTable.html

17. 17 もう一歩先の価値を目指すために意識したこと Episode. 申込者の審査自動化機能を実装した時の話... まだローンチには至っていませんが... UATの段階で関係者の皆さまから頂いたありがたい声🎉 • 操作体験が非常に良い、普段利用しているサービスに組み込んで欲しいくらい！ • 別事業でもこの機能をオプションとして売り込みに行きたい、転用できる？？

18. 意識したことで得られたこと 18 3

19. 19 意識したことで得られたこと １）後工程での致命的な手戻りがなくなった 細部まで擦り合わせることで、開発者・要望者の間で成果物に対するギャップを埋められるようになった。 その結果として、小さな手戻りはあっても、致命的なものはなくなった。 直接言われたわけではないが、肌感としてBizからの開発への信頼度が多少なりとも上がった気もしている ２）オーナーシップを強く持てるようになった 価値の解像度が荒い状態で臨む開発から得られる結果は、自分ごとに捉えられていなかった。 細部まで考え抜いた上で立てた上で得られた結果は、自分ごととして捉えられるし、よりより反省に も繋がる。そして自信にもつながる。

    その積み重ねがオーナーシップをより強くしてくれた。

20. 20 意識したことで得られたこと ３）フロー効率を重視した段階的なアプローチを採れるようになった ”今必要とされている”ことを明確にするからこそ、初めから100点を目指さない開発を意識できるよう になった。 結果として、必要な価値を最速で届けることができ、且つtoo muchな開発を避ける（無駄な開発リ ソースを割かない）ことにもつながった。 70点で始める業務効率化開発 こちらの記事で詳しく

    解説されてますので ぜひ！

21. まとめ 21 4

22. 22 プロダクト志向なエンジニアという自負はあるが... プロダクトエンジニア（に限らず全てのエンジニア） が特に意識すべきだと思ったこと １）わからないことをわからないままにしない 業務や課題を知らない状態で良いものは作れるはずがない。 可能な限り解像度を上げることが、価値を生み出す確度の高さにつながる。 ２）具体情報を用いてコミュニケーションする 俺の考える最強の機能！は大抵ウケない。 期待ギャップを生まないためにも、仮定ではなく具体で語る。

23. 23 プロダクト志向なエンジニアという自負はあるが... 事業成長を加速させる！ニーリーにおけるプロダクトエンジニアとは─ 弊社が考える プロダクトエンジニア像 を解説しています！

24. ニーリーではプロダクトエンジニア、 その他のポジションも積極採用中です！ https://jobs.nealle.com/ We are hiring!!!