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
0
71
PM初めて1年の振り返り
mae
July 19, 2025
Tweet
Share
More Decks by mae
See All by mae
若手向けITコミュニティを運営する理由
mae_hidari
1
3.2k
コミュニティ運営のコツ
mae_hidari
1
72
Featured
See All Featured
Become a Pro
speakerdeck
PRO
29
5.5k
Statistics for Hackers
jakevdp
799
220k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
1k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Facilitating Awesome Meetings
lara
54
6.5k
Art, The Web, and Tiny UX
lynnandtonic
301
21k
Adopting Sorbet at Scale
ufuk
77
9.5k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
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 安定度 「お客さん やりたいこと」がこ 先もあるかが指標になるかも。
お客さんと仕事を作っていく お客さんとコミュニケーションを取って、 お客さん 仕事を理解し、 一緒に問題を見つけて提案していきたい所存。
次 次を考えながら次に取り組むチームを目指したい 個人的に 「いい仕事 余裕から生まれる」と思ってる。 仕事が楽しい→もっとお客さんに貢献したい (逆 持続性に欠ける気がする。信頼と 「持続するか」だと思っている) 仕事が楽しいとき
やっ り、自分が成長しているときだと思う。 メンバーが成長を実感して、お客さんに貢献したくなるチームにしたい。 そ ために 「次 次に実現したいこと」を考えながら 「次に実現したいこと」に取り組むと視野が広がって成長を促進できたらいいな