小さな判断で育つ、大きな意思決定力 / 20251204 Takahiro Kinjo

2025/12/4 pmconf 2025
https://2025.pmconf.jp/

株式会社SHIFT
DAAE統括部 DAAE部
ワスレナイグループ グループ長補佐
金城 貴大

Transcript

1. 小さな判断で育つ、 大きな意思決定力 不具合チケットから学ぶプロダクトマネージャーの基礎
2. 2 自己紹介 2 前職でライフサイエンス領域の製品開発に従事し、要件定義 から設計、開発、テスト、保守まで一気通貫で経験。 SHIFT入社後はテストの現場で3年間の経験を積み、最大 40名規模のテストチームを率いるプロジェクトマネージャーを担 当。 2022年からは自社SaaS「ワスレナイ」のプロダクトマネージャー として、開発経験とテスト現場で培った知見を基盤に、品質と スピードの両立を目指したプロダクトづくりに取り組んでいる。 株式会社SHIFT 金城 貴大 Takahiro Kinjo DAAE統括部DAAE部ワスレナイグループ グループ長補佐
3. 3 会社紹介 ソフトウェアの品質保証・テスト事業から DXの総合企業、AIネイティブなSIカンパニーに • エンジニア_正社員:正社員雇用のエンジニア （他社からの出向者含む) • エンジニア_有期雇用: アルバイト、契約社員 • パートナー: 自社リソース(正社員)が足りない場合に、 業務を担ってもらうSES企業のエンジニア 売上高 1,106 約 億円 エンジニア数 12,700 人超 売上高の推移 （※） エンジニア数の推移 会社名 株式会社SHIFT 本社所在地 東京都港区麻布台1丁目3番1 麻布台ヒルズ森JPタワー 全国拠点 大阪・札幌・仙台・新潟・ 浜松・名古屋・広島・福岡 代表者 丹下 大 設立日 2005年9月7日 上場市場 東証プライム（3697） 資本金 21百万円 ※2024年8月末時点 従業員数 連結：14,726人 単体：7,815人 ※2025年5月末時点 グループ会社 42社 ※2025年10月時点 ※：2024年8月期 出典： SHIFT_2025年8月期第3四半期 決算説明会 資料_P.57 ◼売上高：110,627百万円 ◼経常利益：10,537百万円 ◼当期純利益：5,715百万円 3 出典：SHIFT_2025年8月期第3四半期決算説明会資料 _P.10
4. 4 担当サービス「ワスレナイ」の紹介
5. 5 １,５００
6. 6 とあるシステムの不具合の数
7. 7 意思決定力を鍛えたチャンスの数
8. 8 なぜ意思決定力を鍛えるチャンスか 当時、テストを担当。 不具合起票時に優先度をつけてPdMに報告する、ということを行ってきた。 不具合チケットの優先度付けを行っていくなかで プロダクトが大切にしている価値観を学んだ。
9. 9 本日のアジェンダ 1. 意思決定力の大切さ、身につける難しさ 2. なぜ不具合優先度付けが効果的か 3. ジュニアPMに不具合優先度付けをやってもらった 4. まとめ
10. 1.意思決定力の大切さ、身につける難しさ
11. 11 PMの仕事は「判断」の連続 PMが決めなければいけないことが山ほどある • 機能の優先順位 • 仕様の妥協点 • リリースの可否 etc..
12. 12 PMのキャリアにおける「育成のパラドックス」 経験がないから 任せてもらえない 任せてもらえないから 経験できない このループをどう断ち切るか？ PMの価値は「決めること」にある。 しかし、ジュニアPMは「決め方」を学ぶ機会がない。
13. 13 本を読んでも「決める力」は身につかない 本が教えてくれるのは 「一般的な正解(セオリー)」 どんな名著を読んでも 「私たちのプロダクトはどの方向を目指すべきか」 という問いの答えはどこにも書いていない。 知識も必要だが、状況に応じた「意思決定のトレーニング」が重要 現場で必要なのは 「個別具体的な意思決定」
14. 14 PMの意思決定に必要な3STEP STEP2 選択と決断 STEP1 情報探索 STEP3 合意形成 現在の機能利用状況、市場 分析、要望の棚卸し等を実 施する。 集めた情報をもとに期間内で 何をやるか決める。 なぜ今のロードマップなの かを説明する。
15. 15 判断のトレーニングとして 不具合チケットの優先度付けが 判断のトレーニングの場として最適
16. 16 前提：不具合チケットとは何か 不具合チケット＝「仕様とのズレ」を管理するためのもの プログラムの不具合（バグ）、使い勝手の違和感（UX）、仕様書の考慮漏れ など 大量に発生するため、限られた期間内ですべてを直すことは不可能 →PMは基準を決めて優先度を決定する Priority 定義・アクション P1 (Critical) 最優先で修正 開発を止めてでも即時対応 P2 (Blocker) リリース不可 テスト期間終了までに必ず直す P3 (Normal) 次回以降 のリリースで修正で問題なし P4 (Won’t Fix) 直さない 仕様として許容する
17. 17 例）不具合チケット優先度付けにおける3STEP STEP2 選択と決断 STEP1 情報探索 STEP3 合意形成 事象の発生条件、影響度、 不具合とする根拠、を調べる。 確認した事象と今のプロダクト 状況に合わせて優先度をつけ る。 なぜその優先度をつけたか 説明する。
18. 2.なぜ不具合優先度付けが効果的か
19. 19 3STEPにおける躓き 各STEPが毎回思い通りに進むとは限らない STEP2 選択と決断 STEP1 情報探索 STEP3 合意形成
20. 20 STEP1の躓き 情報探索あるある そもそも情報（材料）が100%揃うことはない STEP2 選択と決断 STEP1 情報探索 STEP3 合意形成
21. 21 STEP2の躓き STEP2 選択と決断 STEP1 情報探索 STEP3 合意形成 決断の壁あるある 情報が足りないから決められない、優先度をつい上げちゃう
22. 22 STEP3の躓き STEP2 選択と決断 STEP1 情報探索 STEP3 合意形成 合意形成の壁あるある 自信なく持ち込む、結果、差し戻される
23. 23 この躓きを乗り越える魔法の手段がある
24. 24 「意思決定の千本ノック」 不具合チケットの巻！
25. 25 なぜ不具合チケットなのか →「高速な学習サイクル」 不具合チケットはマネージャーやチームとのすり合わせを通じ、 「価値基準の同期」を1日2回のペースで繰り返せる 機能開発 不具合チケット 12回 700回 フィードバックの回数（年間）
26. 26 「価値基準」を獲得せよ 最後に頼れるのは情報ではなく、自分の中の「価値基準（ものさし）」 不具合優先度付けの本質 チームやプロダクトの「価値基準」を 自分の中にインストールし、磨き上げるプロセス。 これができると、材料不足の状況でも「決められる」ようになる。
27. 27 テスト時代の実例「P1 vs P2」 私の判断：P2（リリースまでに直す） 理由： テスト期間内に直せばよいのでP2。直るまでは他のテストを進められれば問題 ないと判断。 PMの判断：P1（最優先） 理由： ハッピーパスが通らないと他の不具合検出のタイミングも遅れる。全体的にスケ ジュールが遅れる可能性が出るため、テストブロッカーはP1にする必要がある。 重要機能（Epic）でテストブロッカーとなる不具合を検出
28. 28 学び：「正しさ」はプロダクトの価値観で決まる 私の優先事項 「仕様書通りか」 「QAチームの効率」 重要な気づき 私の判断は、別のプロダクト（プロジェクト）なら正解だったかも しかし、「今のプロダクトが何を優先しているか」という価値観に合っていなかった →「自分視点の正解」ではなく「プロダクトの価値基準」を探す姿勢を学んだ PMの優先事項 「プロダクトの提供価値」 「開発チーム全体の進捗」
29. 29 優先度付けの経験が現在の「スタイル」を作った 不具合対応で学んだのは単なる処理速度ではない。 「プロダクトチームと価値観を同期する方法」である。 1. 対 事業責任者（週2回の棚卸し） • 「なぜやるか」を説明し、責任者の思想・価値観を吸収する 2. 対 ユーザー（ヒアリング） • 要望を鵜呑みにせず、自分の言葉で言い換えて内容を確認することで ユーザーの要求に潜む価値観を引き出す 今のプロダクトでの実践
30. 3.ジュニアPMにやってもらった
31. 31 実践: ジュニアPMに優先度付けをやってみてもらった 不具合チケットの優先度付けをジュニアPM（新卒）にやってもらった 期間 3か月 方法 朝会夕会で理由を説明 →その場でフィードバック 対応数 170件
32. 32 施策始めたころのやりとり 過去に別画面の類似機能のチケットの 優先度がP3だったためP3にしました。 今回発生する画面では主要な機能であ り、顧客影響が大きくリリースまでに直す必 要があるのでP2が適切です。 ジュニアPM 私 雰囲気で誤った優先度をつける 暗黙的な価値基準をフィードバックする×170回 雰囲気
33. 33 現在 ボタンを押すと「このアクションを実行する権限がありませ ん。」というエラーが表示され、権限制御自体はできていま した。 ただ、閲覧権限ユーザーにとって実行できないボタンはそも そも表示すべきではないと思います。 まだリリースまでは猶予があり、修正する余裕もあるため、 P2にしました。 ボタンを押したときの挙動まで確認していて 素晴らしい。 理由も納得できるのでP2でいきましょう！ ジュニアPM 私 事象: 閲覧権限ユーザーでログインしたときに「通知チャネルを追加」ボタンが表 示される STEP2 選択と決断 STEP1 情報探索 STEP3 合意形成
34. 34 実例: ジュニアPMに優先度付けをやってみてもらった 「作業者」から「意思決定者」への脱皮を果たした STEP 初期（Before） 現在（After） 探索 情報不足で手が止まる 「どうすればいいですか？」 判断基準（仕組み）自体を提案 「本番環境の項目を追加すべき」 選択と 決断 ある情報だけで なんとなく決める 事象を理解しつつ、現在プロダクトが置か れている状況を加味して判断できる 合意形成 チケットの記載内容を 読み上げるだけ どのように思考して探求、決断をしたかの プロセスを説明できる どのように変わったか
35. 35 ジュニアPM本人のコメント 苦労したこと • 情報や仕様理解が不足しているチケットでは、「不具合なのか仕様なのか」 「どこまでを期待値とみなすか」の判断に時間がかかった 工夫したこと・学んだこと • 仕様への理解と他の人の手がけているバックログへの理解も深まり、プロダク トの全体像の解像度がはっきりしたように感じている • チケット内容の理解のために、設計書・バックログを確認し、「ここまでは自分 の理解」「ここから先は不明点」と切り分けてから起票者や先輩に相談する ようにした →この「自分で理解できた範囲を明確にし、不明点を関係者に確認する」 という進め方は、他のタスクでもそのまま応用でき、仕事全体の進め方とし ても役立っている
36. ４. まとめ
37. 37 大きな意思決定の機会は中々回ってこない だからこそ、目の前の「不具合チケットの山」を活用しましょう 大切なのは一つひとつのチケットを「単なる作業」で終わらせず、 「意思決定の練習」と捉えること 日常の小さな判断の積み重ねが、いつかあなたを「強いPM」にします 意思決定力は「日常」でこそ育つ
38. 38 不具合チケット優先度付け やってみたいけどそもそもテストがちゃんと回ってないよ、、という方 おまけ ぜひ SHIFT にご相談ください！
39. おわり 39