Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Nealle
June 26, 2025
Programming
0
640
プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと
2025/6/26
https://pesess.connpass.com/event/355670/
Product Engineer Session #3
Nealle
June 26, 2025
Tweet
Share
More Decks by Nealle
See All by Nealle
JDDUG#15 DataDogで行うバッチ改善
nealle
0
59
「なぜ」を残し、SLOを育てる IaCによるSLI/SLO運用の実践
nealle
0
97
Datadogのログコスト最適化
nealle
0
93
今、アーキテクトとして 品質保証にどう関わるか
nealle
0
200
AI巻き込み型コードレビューのススメ
nealle
2
2.5k
Startup Tech Night ニーリーのAI活用
nealle
0
100
モビリティSaaSにおけるデータ利活用の発展
nealle
1
960
Pythonに漸進的に型をつける
nealle
1
220
品質ワークショップをやってみた
nealle
0
1.5k
Other Decks in Programming
See All in Programming
ふつうの Rubyist、ちいさなデバイス、大きな一年
bash0c7
0
590
go directiveを最新にしすぎないで欲しい話──あるいは、Go 1.26からgo mod initで作られるgo directiveの値が変わる話 / Go 1.26 リリースパーティ
arthur1
2
470
クライアントワークでSREをするということ。あるいは事業会社におけるSREと同じこと・違うこと
nnaka2992
1
310
社内規程RAGの精度を73.3% → 100%に改善した話
oharu121
13
7.6k
JPUG勉強会 OSSデータベースの内部構造を理解しよう
oga5
2
230
Takumiから考えるSecurity_Maturity_Model.pdf
gessy0129
1
120
AI時代のソフトウェア開発でも「人が仕様を書く」から始めよう-医療IT現場での実践とこれから
koukimiura
0
130
猫の手も借りたい!ので AIエージェント猫を作って社内に放した話 Claude Code × Container Lambda の Slack Bot "DevNeko"
naramomi7
0
250
Codex の「自走力」を高める
yorifuji
0
650
nilとは何か 〜interfaceの構造とnil!=nilから理解する〜
kuro_kurorrr
3
1.6k
モジュラモノリスにおける境界をGoのinternalパッケージで守る
magavel
0
3.4k
どんと来い、データベース信頼性エンジニアリング / Introduction to DBRE
nnaka2992
1
150
Featured
See All Featured
Scaling GitHub
holman
464
140k
Mind Mapping
helmedeiros
PRO
1
110
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4k
Unlocking the hidden potential of vector embeddings in international SEO
frankvandijk
0
190
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.7k
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
230
Test your architecture with Archunit
thirion
1
2.2k
Producing Creativity
orderedlist
PRO
348
40k
Context Engineering - Making Every Token Count
addyosmani
9
740
GraphQLとの向き合い方2022年版
quramy
50
14k
Typedesign – Prime Four
hannesfritz
42
3k
Transcript
プロダクト志向なエンジニアが もう一歩先の価値を目指すために 意識したこと ProductEngineerSession #3 2025/06/26 株式会社ニーリー 石倉和真
2 自己紹介 石倉 和真(Kazumasa Ishikura) @kazu_real20 株式会社ニーリー プロダクト開発リード • 2022年にニーリーに参画 •
キャリア:DMM.com → ニーリー • 主にtoB領域のグロースに係る案件を日々フルサイクルに担当 • 元々はギタリストとして活動していたことも🎸
3 事業・プロダクト紹介
4 本日のお話 1. プロダクト志向なエンジニアという自負はあるが... 2. もう一歩先の価値を目指すために意識したこと 3. 意識したことで得られたこと 4. まとめ
プロダクト志向なエンジニア という自負はあるが... 5 1
6 プロダクト志向なエンジニアという自負はあるが... 「この機能、ユーザーのためになってる?」 「自分のコードがどうビジネスに貢献してるかわからない…」 前職時代の僕
7 プロダクト志向なエンジニアという自負はあるが... 入社後初の評価面談で次のフィードバックをいただく😭 1)顧客要望を素直に受け入れすぎ 2)業務・オペレーションに対するDeepDiveが足りない
8 プロダクト志向なエンジニアという自負はあるが... 半期の取り組みを振り返ると、たしかに...と頷かされた😮 1)顧客要望を素直に受け入れすぎ ”何を解決すべきか” ”なぜ解決すべきか”ではなく、”どのように実現するか”ばかり考えていた。 2)業務・Opsに対する深掘りが足りない 要求しか見えていなかったために、その先にある業務やオペレーションに対して意識が及んでいなかった。
もう一歩先の価値を 目指すために意識したこと 9 2
10 もう一歩先の価値を目指すために意識したこと 改善するために意識するようにしたこと 1)Who / What / Why を意識したコミュニケーション 誰の何を解決するもので、それをなぜ今やるべきなのかを整理する。
疑問や不足情報があれば、その時点でヒアリングする。 2)リリースだけでなく、その後の運用に対しても関心を持つ リリースされて終わりではなく、リリース後のフォローまでをセットで考える。 機能が評価されるのは運用に載ってから。 → 運用に載らない機能は評価すらされない。 既存業務・オペレーションを理解し、機能をどうやって組み込むかを模索し、ユーザにとっての使いやすさを 意識する。
11 もう一歩先の価値を目指すために意識したこと Episode. 申込者の審査自動化機能を実装した時の話... ◆ 要求概要 • 申込者情報が特定条件に抵触するかを自動的に判定し、 抵触したものはリストアップ・担当者が目検でチェックできるようにしたい •
抵触しない場合は、自動的に審査通過として処理させたい • 併せて、審査で扱う情報の管理も画面からできるようにしたい
12 もう一歩先の価値を目指すために意識したこと Episode. 申込者の審査自動化機能を実装した時の話... ◆ Who / What の把握 •
一部申込者に対して、”顧客担当者”が目検で審査を行なっている • 審査のやり方は固まっているが、1件1件目検するのはかなり工数がかかる • 担当者が本来やるべき業務にリソースを充てられる状況を作りたい To-Be(あるべき姿)の把握だけでなく、 As-Is(今抱えている課題・状況)を把握することを特に意識
13 もう一歩先の価値を目指すために意識したこと Episode. 申込者の審査自動化機能を実装した時の話... ◆ Why の把握 • 審査で扱う情報の特性上、業務を担当者以外へ分散することも難しい •
新規申込者は右肩上がりだが、増加に伴って審査対象数が増大しており、審査業務 の工数が既に逼迫している • なので、審査業務を省力化を図るために、審査業務を自動化したい この要望で期待する効果が何かの具体を知る。 抑えるべきポイントを意識することで、期待ギャップを小さくする。
14 もう一歩先の価値を目指すために意識したこと Episode. 申込者の審査自動化機能を実装した時の話... ◆ 運用・オペレーションの把握 局所最適ではなく、全体最適を図るために、 フローの全体像の把握、そして改善すべき工程の具体を把握する。
15 もう一歩先の価値を目指すために意識したこと Episode. 申込者の審査自動化機能を実装した時の話... ◆ WF・プロトタイプを作成し、具体情報を基に迅速に仮説検証する 具体情報を頻繁に共有し、早期により具体なフィードバックを得る。 開発段階から期待ギャップを小さくすることを意識する。
16 もう一歩先の価値を目指すために意識したこと Episode. 申込者の審査自動化機能を実装した時の話... ◆ WF・プロトタイプを素早く作成し、成果物の具体イメージをこまめにすり合わせる 大前提として... • 要求解釈を誤ると期待ギャップは容易に生ま れる
• 顧客の頭の中で言語化できていない部分 (暗黙知)は要求に現れない ことを意識する。 仮定を避け、具体(プロトタイプ)で議論する ことが、期待ギャップを埋めることにつながる。 出典 :https://pages.uoregon.edu/ftepfer/SchlFacilities/TireSwingTable.html
17 もう一歩先の価値を目指すために意識したこと Episode. 申込者の審査自動化機能を実装した時の話... まだローンチには至っていませんが... UATの段階で関係者の皆さまから頂いたありがたい声🎉 • 操作体験が非常に良い、普段利用しているサービスに組み込んで欲しいくらい! • 別事業でもこの機能をオプションとして売り込みに行きたい、転用できる??
意識したことで得られたこと 18 3
19 意識したことで得られたこと 1)後工程での致命的な手戻りがなくなった 細部まで擦り合わせることで、開発者・要望者の間で成果物に対するギャップを埋められるようになった。 その結果として、小さな手戻りはあっても、致命的なものはなくなった。 直接言われたわけではないが、肌感としてBizからの開発への信頼度が多少なりとも上がった気もしている 2)オーナーシップを強く持てるようになった 価値の解像度が荒い状態で臨む開発から得られる結果は、自分ごとに捉えられていなかった。 細部まで考え抜いた上で立てた上で得られた結果は、自分ごととして捉えられるし、よりより反省に も繋がる。そして自信にもつながる。
その積み重ねがオーナーシップをより強くしてくれた。
20 意識したことで得られたこと 3)フロー効率を重視した段階的なアプローチを採れるようになった ”今必要とされている”ことを明確にするからこそ、初めから100点を目指さない開発を意識できるよう になった。 結果として、必要な価値を最速で届けることができ、且つtoo muchな開発を避ける(無駄な開発リ ソースを割かない)ことにもつながった。 70点で始める業務効率化開発 こちらの記事で詳しく
解説されてますので ぜひ!
まとめ 21 4
22 プロダクト志向なエンジニアという自負はあるが... プロダクトエンジニア(に限らず全てのエンジニア) が特に意識すべきだと思ったこと 1)わからないことをわからないままにしない 業務や課題を知らない状態で良いものは作れるはずがない。 可能な限り解像度を上げることが、価値を生み出す確度の高さにつながる。 2)具体情報を用いてコミュニケーションする 俺の考える最強の機能!は大抵ウケない。 期待ギャップを生まないためにも、仮定ではなく具体で語る。
23 プロダクト志向なエンジニアという自負はあるが... 事業成長を加速させる!ニーリーにおけるプロダクトエンジニアとは─ 弊社が考える プロダクトエンジニア像 を解説しています!
ニーリーではプロダクトエンジニア、 その他のポジションも積極採用中です! https://jobs.nealle.com/ We are hiring!!!