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
PM初めて1年の振り返り
Search
mae
July 19, 2025
89
0
Share
PM初めて1年の振り返り
mae
July 19, 2025
More Decks by mae
See All by mae
若手向けITコミュニティを運営する理由
mae_hidari
1
4.9k
コミュニティ運営のコツ
mae_hidari
1
79
Featured
See All Featured
エンジニアに許された特別な時間の終わり
watany
106
240k
Pawsitive SEO: Lessons from My Dog (and Many Mistakes) on Thriving as a Consultant in the Age of AI
davidcarrasco
0
120
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Game over? The fight for quality and originality in the time of robots
wayneb77
1
160
Tell your own story through comics
letsgokoyo
1
900
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Building Flexible Design Systems
yeseniaperezcruz
330
40k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
49
9.9k
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
0
480
Exploring the relationship between traditional SERPs and Gen AI search
raygrieselhuber
PRO
2
3.8k
The agentic SEO stack - context over prompts
schlessera
0
750
Art, The Web, and Tiny UX
lynnandtonic
304
21k
Transcript
PM初めて1年 振り返り
• 会社で現PJ プロジェクトマネージャーになって1年2ヶ月 • 自分 経験を振り返って次 アクション 仮説を立てたい • 「内省をLTにしてみた」
• PMについて tipsやスキル 紹介しない • 自分 振り返りと共に、みんな 経験や質問から気づきが得られたら嬉しい どんなLT?
名前:まえ ロール:フロントエンジニア (5年くらい) → PM(1年くらい) 会社:鈴木商店 仕事:toB 受託案件、準委任契約でアジャイル開発に近い 趣味: ・バロック音楽
楽器演奏(特にヴィオラ・ダ・ガンバ) ・古代ギリシャ語で哲学書を読む ・17世紀オランダ絵画 修復技術に私淑 を休日に嗜んでおりもっ ら高尚 自己紹介
PMをやっています。 toB 受託開発で、PM1人、フロント1人、バックエンド1人 準委任契約で納期 決めず毎月決められた金額内でそ 時に優先度 高い開発を取 り組む進め方 なにをしているか
• PMやってみて感じたこと ◦ プログラマーとPM やってたこと 違い ◦ 全部PMが決めなくてもいいかも ◦ 「今」完遂しなくてもいいかも
◦ スケジュールがすべてを解決、見積もりが命かも(またいつか) ◦ 期待値が前提かも(またいつか) • 今後やりたいこと ◦ お客さんと仕事を作っていく ◦ 次 次を考えながら次に取り組むチームを目指したい 目次
PMやってみて感じたこと
プログラマーとPM やってたこと 違い PG とき気にしてたこと • 目 前 機能 •
納期 • 設計 • 可読性 • 抽象化 • 責務 分離 • 会社全体 興味あること (採用・コミュ) PMとして気にしていること • お客さん 期待値 • 予算、工数 • メンバー モチベ • メンバー 体調 • スケジュール • 今クリティカルにやるべきこと • 今やらなくてもいいこと
全部PMが決めなくてもいいかも PMになって「決定する」が難しかった。 例え 「お客さんから不具合報告あったけど、開発リリース カツカツ、調べてもらったけど原 因 かなり根が深そうだし、再現が不安定」 不具合な で早く直さないと行けないけど、 そうなると予定していたリリース
遅れるし そもそも不具合がどれくらい工数使う かわからない。 変数が多すぎてお客さんになんて言え いい か、 スケジュール どうすれ いい か分からなかった。
全部PMが決めなくてもいいかも 今ならわかること 「不具合な で早く直さないと行けない」← お客さんが決めること ※こ 時 不具合に関して お客さんが決めるため 判断材料を集めて提示して考えてもらえ
いい。 材料から導ける現時点 ベストエフォートが提案できたら尚良し。 まず「決定する人」 自分かどうか、 他にいるならそ 人が判断できるように動くとよさそう。
「今」完遂しなくてもいいかも PMになって「落とし所を見つける」 がうまくなった 例え 「要件定義 中で要望された追加機能が使われなかった」 「機能開発で共通化に時間をかけたけど他部分で使われなかった」 必要以上にコストを使ったしまった話。 PM 仕事に対して「今必要か」を意識するべきっぽい。
「今」完遂しなくてもいいかも 「要件定義 中で要望された追加機能が使われなかった」 → 一旦基本機能をリリースして、必要なら今後対応しましょう。 「機能開発で共通化に時間をかけたけど他部分で使われなかった」 →今 共通化せずに、他部分で必要になったら共通化しよう。 リソースを無駄遣いしないように「落とし所」が大事だと思った。 落とし所と
「今必要なこと」「今じゃなくていいこと」を切り分けて 「今じゃなくていいこと」をどうやって管理するかを決めること
今後やりたいこと
お客さんと仕事を作っていく お客さんが満足しているかがめっちゃ大事。 → 金額に見合った仕事ができているか 期待されていることを達成できているか アジャイル受託な で、数字化が難しい。 プロカンで貰ったアドバイス 「仕事が作れているかが
とつ 指標」 お客さん やりたいことを達成すると満足してもらえる。 PJ 安定度 「お客さん やりたいこと」がこ 先もあるかが指標になるかも。
お客さんと仕事を作っていく お客さんとコミュニケーションを取って、 お客さん 仕事を理解し、 一緒に問題を見つけて提案していきたい所存。
次 次を考えながら次に取り組むチームを目指したい 個人的に 「いい仕事 余裕から生まれる」と思ってる。 仕事が楽しい→もっとお客さんに貢献したい (逆 持続性に欠ける気がする。信頼と 「持続するか」だと思っている) 仕事が楽しいとき
やっ り、自分が成長しているときだと思う。 メンバーが成長を実感して、お客さんに貢献したくなるチームにしたい。 そ ために 「次 次に実現したいこと」を考えながら 「次に実現したいこと」に取り組むと視野が広がって成長を促進できたらいいな