副業で入ったけどタスクがないからPMっぽいことをした話

Transcript

1. 副業で入ったけどタスク がないからPMっぽいこと をした話 樋口修也
2. スピーカー フロントエンド,認証認可 2019年 東京のIT企業に新卒入社 2020年 転職し札幌で小売業DX 2022年 情報安全確保支援士 ダブルダッチ,ダンス,筋トレ 暗号技術入門(結城浩) 樋口修也(25) 担当: 経歴: 趣味: 愛読書:
3. 今日話すこと • 対象 ◦ チーム(2,3人)からチーム(5,6人)人を増やそうとしている組織の管理者 ◦ 始まったばかりのチームにジョインするメンバー • 内容 ◦ チームが大きくなるとき問題点 ◦ culturenote というプロダクトの既存の画面をリニューアルする際に実践した方法 • 注意事項 ◦ 批判的コメントはなるべくご遠慮いただいた上で、 SNSの投稿を歓迎します！！
4. Culturenote とは • ボトムアップの発信文化を作り、 全社横断の相互理解を加速する コミュニケーションツール • 30人の壁といわれる組織が大きく なることで社風が失われていく問 題を解決する
5. プロダクト施策から開発へ • 現状 ◦ デザイナー1人、エンジニア2人の全て副業メン バーでプロトタイプを作成した段階 ◦ 協力的なクライアントと効果検証を済ませる • 要望 ◦ これからクライアントの課題を解決するために素 早く修正改善を積み重ねていきたい ◦ 特に全面的なUIのリニューアルを実施したい 工数の追加 提供と改 善FB
6. プロダクト施策から開発へ 見かけ上はチームが4名→6名になったということ PO デザイナ エンジニア エンジニア PO デザイナ エンジニア エンジニア エンジニア エンジニア
7. デッドロックが発生 見かけ上はチームが4名→6名になっただけ たがリソースのバランスの都合上、以前の進め方ができなくなった PO・社長 デザイナ エンジニア エンジニア エンジニア エンジニア 一人で4人分のデザイ ンが間に合わんか見 積もりを先に出して欲 しい デザインがないか ら工数が見積もれ ない... リニューアルが いつどれができ るか知りたい
8. 手数とナレッジも足りず 副業で入って１週間で 工数見積もり兼タスク整理を引き取ることに PO・社長 デザイナ エンジニア エンジニア エンジニア エンジニア デザインで手一杯 新規機能で手一 杯 この規模のチーム 開発初めてなので 助けてほしい あ、じゃあタスクない からやっときますねー
9. 課題の整理と対応 • スコープ ◦ デザインが全て完成していないので厳密には定義できない ▪ UIのリニューアルなのでアバウトな範囲で定義可能 ▪ スコープの最大量を画面の URL単位で定義しチケット作成すれば良い ▪ 上記で定義した最大量から POに確認し不要なチケットを引き算的に削減していく • リソース ◦ 各メンバーの稼働時間が不明瞭 ▪ MTGや運用保守を除いてみんなの稼働可能時間を集約 • スケージュール ◦ POの意見としては「いつ何ができるか」さえ把握できれば調整可能 ▪ 優先順位を３段階で定義し POに決定してもらい順位ごとにタスクの計画を練る ◦ 各タスクの見積もりができていない ▪ 概算工数を初めてジョインのメンバーもいるので肌間 *1.3でえいやで割り出す ▪ リソースを加味していつ頃どの機能ができるかを算出し POに提示 規模感を考慮しPMBOKのスコープ,資源,スケジュールだけフォーカスした
10. notion でタスクのフォーマット化と全量作成 命名規則として「新UI画面実装_内容」とする 優先度を新設しPOに３段階評価で各画面のこの値 を決めてもらう 超概算でいいので感覚値でいいのでバッファを持っ た数字で見積もりを時間単位で行っておく。 全く検討がつかないところは歴の長いエンジニアに超 概算を任せる リニューアル対象のパスを記載し、画面単位でリ ニューアルしてく方針とする
11. notion で最大量のタスクを洗い出すために デザイン未完成のタスクには WIP:をつける 本当に要るのか疑問のタスクには Q:をつけPOに 確認
12. notionでスコープを詳細に定義 フロントとバックの改修内容をざっくり記述し超概算 工数を出す。 Figmaのnotion埋め込み機能を使ってどの画面に 関する修正かをわかりやすくする
13. notionでスコープを詳細に定義 URLだけでは再表示の工数やパスワード再設定の時 など表示の手間が発生するので手軽に確認できるよ うスクショで対象画面を載せておく 質問したい人にメンションをつけていつ誰がメンション を飛ばしたかわかるようにしておく POの確認を取る欄を設けてタスクのスコープが POの 確認済みか否かを把握できるようにしておく
14. その結果 POが目標としていた期日に ユーザー利用機能 のリリース達成! 見積もり通り管理者機能は後出しへ 新しくジョインしてパフォーマンスをはっきすることができました。
15. 余談: 新しく入る人の工数管理ができないはあるある • PMや開発経験が豊富な人 ◦ 単純に業務量が多く忙しい • 経験が少ない人 ◦ ナレッジがない 新しく入る人の工数管理難しいのはどこも同じ 新しく入る人員が自主的に動く必要があり、場所によっては当たり前のこと。
16. 最後に メンバーは入った時こそ手が回ってないところを自発的に補うことが重要 管理者はある程度メンバーに期待感を伝えることが重要 プロダクトに興味ある方 DMください @shu038fw ヒグ!!