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
74
PM初めて1年の振り返り
mae
July 19, 2025
Tweet
Share
More Decks by mae
See All by mae
若手向けITコミュニティを運営する理由
mae_hidari
1
3.3k
コミュニティ運営のコツ
mae_hidari
1
72
Featured
See All Featured
The Power of CSS Pseudo Elements
geoffreycrofte
77
6k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
530
Why Our Code Smells
bkeepers
PRO
339
57k
Faster Mobile Websites
deanohume
309
31k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
How STYLIGHT went responsive
nonsquared
100
5.8k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.7k
Speed Design
sergeychernyshev
32
1.1k
Large-scale JavaScript Application Architecture
addyosmani
513
110k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
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 安定度 「お客さん やりたいこと」がこ 先もあるかが指標になるかも。
お客さんと仕事を作っていく お客さんとコミュニケーションを取って、 お客さん 仕事を理解し、 一緒に問題を見つけて提案していきたい所存。
次 次を考えながら次に取り組むチームを目指したい 個人的に 「いい仕事 余裕から生まれる」と思ってる。 仕事が楽しい→もっとお客さんに貢献したい (逆 持続性に欠ける気がする。信頼と 「持続するか」だと思っている) 仕事が楽しいとき
やっ り、自分が成長しているときだと思う。 メンバーが成長を実感して、お客さんに貢献したくなるチームにしたい。 そ ために 「次 次に実現したいこと」を考えながら 「次に実現したいこと」に取り組むと視野が広がって成長を促進できたらいいな