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
63
PM初めて1年の振り返り
mae
July 19, 2025
Tweet
Share
More Decks by mae
See All by mae
若手向けITコミュニティを運営する理由
mae_hidari
1
3k
コミュニティ運営のコツ
mae_hidari
1
71
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
5.6k
How to Ace a Technical Interview
jacobian
278
23k
Building Applications with DynamoDB
mza
95
6.5k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
A Tale of Four Properties
chriscoyier
160
23k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
282
13k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
530
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
Gamification - CAS2011
davidbonilla
81
5.4k
Unsuck your backbone
ammeep
671
58k
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 安定度 「お客さん やりたいこと」がこ 先もあるかが指標になるかも。
お客さんと仕事を作っていく お客さんとコミュニケーションを取って、 お客さん 仕事を理解し、 一緒に問題を見つけて提案していきたい所存。
次 次を考えながら次に取り組むチームを目指したい 個人的に 「いい仕事 余裕から生まれる」と思ってる。 仕事が楽しい→もっとお客さんに貢献したい (逆 持続性に欠ける気がする。信頼と 「持続するか」だと思っている) 仕事が楽しいとき
やっ り、自分が成長しているときだと思う。 メンバーが成長を実感して、お客さんに貢献したくなるチームにしたい。 そ ために 「次 次に実現したいこと」を考えながら 「次に実現したいこと」に取り組むと視野が広がって成長を促進できたらいいな