堀内LT資料
by
anycarry
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
anyCarry Inc. 「エンジニア経験が浅くともPOは務まるのか?」 LT資料 2022年11⽉2⽇ anytime,anywhere,anything,anyone Carry
Slide 2
Slide 2 text
本⽇のLT内容 (本⽇の流れ) 2 1. ⾃⼰紹介 2. LT⽬的 3. POを任されてから今までと今後の課題 - 開発チームの状況、現在の業務 - POになった経緯 - 任された時のPOについての認識レベルとその時の⼼境 - 任されてから取り組んだこと - 苦労したこと、⼤切にしていたこと - 今後の課題
Slide 3
Slide 3 text
⾃⼰紹介 3 • 堀内翔太 • 2021年6⽉にエニキャリに⼊社 • 前職: 9年間ほどメーカーのルート(法⼈)営業に従事 • エンジニアとしての経験は1年半程度 • PO歴は1年程度
Slide 4
Slide 4 text
LT⽬的 4 前提: まだまだ経験が浅く、試⾏錯誤段階。 こうした⽅が良い、こうすべき、といった意図はありません( *`ω´) ドヤァ ⽬的: 皆さんの何かしら気づきや振り返るきっかけになれば幸いです。
Slide 5
Slide 5 text
開発チームの状況 5 開発チーム: 4⼈(⾃分含め)、全員フルリモート *会社全体ではエンジニアは15名程度(社内外含め) 担当プロダクト: -⼀般ユーザー向けの誰でも簡単に配送依頼ができるモバイルアプリ (Expo+React Native) -ビジネス(法⼈向けの)誰でも簡単に配送依頼ができるWebサービス (Ruby on Rails) -ギグワーカー向けのコミュニティサービス(モバイルアプリ) (Expo+React Native)
Slide 6
Slide 6 text
現在の業務 6 POとしての業務: - プロダクトバックログの作成・管理(優先順位付) - 開発チーム全体の状況把握、バックログの内容説明 - ビジネスチームとの情報共有、要望のヒアリング、プロダクトのデモ - プロダクトが要件通りに機能しているかの動作確認 開発: - 担当プロダクトの機能開発 - ビルドから本番リリースまで⼀気通貫して⾏う
Slide 7
Slide 7 text
PO(プロダクトオーナー)になった経緯 7 ○POに任されたのは、”突然”・・・ ・当時の⾃分の業務: 与えられたタスクを諸先輩にフォローしてもらいながらこなす⽇々。 ⼊社当初に⽐べて難易度や重要性の⾼いタスクを任されるようになってはいたが、 POを任せる、という話は⼀切なかった。 ・当時の開発チームの状況: -すべてのプロダクトのマネジメントをCTO⼀⼈でやっていた。 -社員は私⼀⼈だった。 ○あるプロダクトのMTGにCTOの代理で出席した後、いつの間にかPOに →突発的ではあるが、⼊社まもなくして任せてもらえたのは ベンチャーっぽくて個⼈的にはアリ(笑)
Slide 8
Slide 8 text
任された時のPOについての認識と⼼境 8 ○POについての認識: そもそも”PO”という⾔葉を知らなかったorz ○任された時の⼼境: 前向きな気持ち:不安な気持ち = 1:99 ・不安要素: 圧倒的な知識不⾜、チーム開発もよくわかっていない、サービス理解も浅い 担当プロダクトチームとの直接的なやりとりほぼ皆無、経験・知識が豊富なCTOの後継、etc.. → ただ、これまでサポートもしっかりしていただいた経緯があったので、 なんとかなる、という⾃信もあった
Slide 9
Slide 9 text
任された時に取り組んだこと 9 やるべきこと、やらなくても良いことの認識・整理 ○そもそも”PO”の果たすべき役割・必要なスキルは何か? 教科書的には、 役割:プロダクトの意思決定、関係者との調整・情報共有、バックログの管理 etc 必要なスキル:コミュニケーションスキル、プロダクトに関する知識、マネジメントetc →⼀番の不安要素だった”技術に関する知識不⾜”は、 POする上で重要そうではなかったε-(´∀`*)ホッ
Slide 10
Slide 10 text
苦労したこと 10 “技術に関する知識は重要ではない”、とは⾔ったものの。。。 技術的な知識がないと、業務が円滑に進まないorz - 開発MTGの理解度30% →結論しかわからない - 作成できないバックログがちらほら (エニキャリのコアであるAWS serverlessの仕様についてある程度理解していない とバックログの作成ができない) - ビジネスチームにもなぜ~⼯数がかかるのか説明できない →ただ、質問しやすい環境ではあったので、 MTG前に⾃分で調べて不明な点はわかる⽅にすぐに確認していた。
Slide 11
Slide 11 text
⼤切にしてきたこと 11 技術や知識・経験が⾜りていない⾃分がプラスαできることは何か?という視点で考えた 円滑なコミュニケーション(幅広い意味での) -ビジネス側及び開発側とのやりとりに対してはできるだけ”即レス” -バックログには”背景と理由”を明記した →ビジネス側と開発側での認識の齟齬が起こらないようにした。 -感謝の気持ちを表現する 開発・ビジネスチーム問わず、何かをやっていただいた時には”ありがとうございます”と ⾔葉で表すようにした。
Slide 12
Slide 12 text
今後の課題 12 開発チームのMTGをより建設的な議論ができるような場にしていきたい 現状: バックログの内容説明及び進捗状況の確認のみ →(開発する上で)ボトルネックの解消、より開発しやすい⽅法など 掘り下げて議論することでより良い開発チームを築けるようにしたい。
Slide 13
Slide 13 text
結論 13 「エンジニア経験が浅くともPOは務まるのか?」 →なんとかはなる。 ただ、周りからの絶⼤な(笑)サポートがある場合に限る。
Slide 14
Slide 14 text
No content