プロジェクトマネジメントとは？経験から学ぶ視野と視座

by なおと

Slide 1

Slide 1 text

©Fusic Co., Ltd. 0 プロジェクトマネジメントとは？経験から学ぶ視野と視座 2024.06.22 なおと @NaotoCoding PHP CONFERENCE FUKUOKA 2024

Slide 2

Slide 2 text

©Fusic Co., Ltd. 1 なおと Naoto ・株式会社Fusic所属・Rubyist ・新卒3年⽬(24) ⾃⼰紹介はじめにエンジニア

Slide 3

Slide 3 text

©Fusic Co., Ltd. 2 CONTENTS ⽬次 1. PMの定義 2. PMを任せてもらえるまで 3. プロジェクト概要 4. 試み・結果・学び 5. 視野・視座の変化 6. まとめ

Slide 4

Slide 4 text

©Fusic Co., Ltd. 3 PMの定義 1

Slide 5

Slide 5 text

©Fusic Co., Ltd. 4 PMの定義 PM(プロジェクトマネージャー) 開発しやすい環境を整える内部⾯お客様とプロジェクトの成功を定義する外部⾯

Slide 6

Slide 6 text

©Fusic Co., Ltd. 5 PMの定義 PM(プロジェクトマネージャー) • 要件定義 • 詳細設計お客様とプロジェクトの成功を定義する外部⾯

Slide 7

Slide 7 text

©Fusic Co., Ltd. 6 PMの定義 PM(プロジェクトマネージャー) • タスク管理 • スケジュール管理 • チームビルディング開発しやすい環境を整える内部⾯

Slide 8

Slide 8 text

©Fusic Co., Ltd. 7 PMを任せてもらえるまで 2

Slide 9

Slide 9 text

©Fusic Co., Ltd. 8 PMを任せてもらえるまで 1年⽬前半 • 研修 1年⽬後半 • 開発業務に従事 • スケジュールはPMに引いてもらう

Slide 10

Slide 10 text

©Fusic Co., Ltd. 9 PMを任せてもらえるまで 2年⽬前半 • 開発業務に従事 • ⾃⾝のタスクとスケジュールを管理 2年⽬中旬 • 開発者リーダーとしてシステム開発を⾏う • ベテランエンジニアに相談役になってもらう • 他開発者のタスク分け、スケジュール管理

Slide 11

Slide 11 text

©Fusic Co., Ltd. 10 PMを任せてもらえるまで 2年⽬後半 • PMに挑戦させてもらう • 徐々にステップアップ Point

Slide 12

Slide 12 text

©Fusic Co., Ltd. 11 プロジェクト概要 3

Slide 13

Slide 13 text

©Fusic Co., Ltd. 12 POINT u 新卒2年⽬をPMとするには規模が⼤きい u 売り上げ⾦額1000万超 u 要件定義期間を含めシステム作成期間は4ヶ⽉間顧客訪問サービス管理システム⻄部ガス株式会社さま顧客の元に向かい、ガス機器点検等を⾏う訪問サービスのためのシステム • 営業員に訪問先の顧客を割り当てる機能(管理者⽤画⾯) • 営業員が訪問を⾏った際にその結果を保存する機能(営業員⽤画⾯) プロジェクト概要

Slide 14

Slide 14 text

©Fusic Co., Ltd. 13 プロジェクト概要開発チーム PM(私) (2年⽬エンジニア) PM補佐 (5年⽬エンジニア) 技術リーダー (5年⽬エンジニア) 開発者 (4年⽬エンジニア×1) (1年⽬エンジニア×2) テストチームお客様

Slide 15

Slide 15 text

©Fusic Co., Ltd. 14 プロジェクト概要開発チーム PM お客様やりとり開発技術リーダー品質担保開発者お客様仕様詰めテストチームシステムテスト PM補佐仕様共有開発 PM相談

Slide 16

Slide 16 text

©Fusic Co., Ltd. 15 試み・結果・学び 4

Slide 17

Slide 17 text

©Fusic Co., Ltd. 16 試み・結果・学びお客様との距離を近く保つ試み1

Slide 18

Slide 18 text

©Fusic Co., Ltd. 17 試み・結果・学び • 外部定例の提案(特に開発初期はオフラインミーティング) • 迅速なレスポンス • 定期的に偽りのない進捗報告やったこと試み1 お客様との距離を近く保つ

Slide 19

Slide 19 text

©Fusic Co., Ltd. 18 試み・結果・学び試み1 お客様との距離を近く保つ結果成功(⻄部ガスさまに感謝) • 解決したい問題の知識のインプットが早くなった • 知識によって提案が少しずつ変化させ、価値あるシステム構築が可能 • 全員で安⼼不安を共有することで、正しく焦ることが可能結果

Slide 20

Slide 20 text

©Fusic Co., Ltd. 19 試み・結果・学び試み1 お客様との距離を近く保つ結果成功 • ファシリテーション能⼒の向上 • 資料作成能⼒の向上結果(個⼈)

Slide 21

Slide 21 text

©Fusic Co., Ltd. 20 試み・結果・学び試み1 お客様との距離を近く保つ結果成功学びお客様もチーム。全員でシステム開発を⾏おう。 • 問題について⼀番知っているのはお客様 • 巻き込まないでどうする！学び

Slide 22

Slide 22 text

©Fusic Co., Ltd. 21 試み・結果・学び細かくタスク・スケジュールを分割した試み2

Slide 23

Slide 23 text

©Fusic Co., Ltd. 22 試み・結果・学び • 開発初期から、開発者⽤のタスクを全て細かく分割しようとしたやったこと試み2 細かくタスク・スケジュールを分割した

Slide 24

Slide 24 text

©Fusic Co., Ltd. 23 試み・結果・学び試み2 細かくタスク・スケジュールを分割した結果少し失敗 • 開発初期は情報が出揃っていないので、タスクを細かくしても正確ではない • 情報が⾜りていない状態でタスクを考えるには時間がかかる。システム構築する上では無駄な時間となってしまった結果

Slide 25

Slide 25 text

©Fusic Co., Ltd. 24 試み・結果・学び試み2 細かくタスク・スケジュールを分割した結果少し失敗 • 上⼿くいかないと悟り、早々にPM補佐に相談 • タスクを⼤きい単位で⽤意し、各開発者に細かいタスク、スケジュールを考えてもらう⽅針に変更リカバリー

Slide 26

Slide 26 text

©Fusic Co., Ltd. 25 試み・結果・学び試み2 細かくタスク・スケジュールを分割した結果少し失敗学び主要機能単位でタスク分割しよう • PMは細かい部分まで⾃分でやろうとすると時間がない • PM補佐に早めに相談してよかった学び

Slide 27

Slide 27 text

©Fusic Co., Ltd. 26 試み・結果・学び試み2 細かくタスク・スケジュールを分割した結果少し失敗学び主要機能単位でタスク分割しよう • ⾃分が開発するとどれくらいの時間を要するか、⾒積もった上でタスクとして開発者に渡すこと • 悲観的にスケジュールを考えることをおすすめする Point

Slide 28

Slide 28 text

©Fusic Co., Ltd. 27 試み・結果・学び 2つの内部定例を実⾏試み3

Slide 29

Slide 29 text

©Fusic Co., Ltd. 28 試み・結果・学び • 以下2つを実⾏ • 毎⽇15分間、午前中に本⽇の予定、問題点等共有を⾏う定例 • 社内でよく⾏われているものを踏襲 • 週末に1度1時間、その週のチームの動きについて振り返る定例 • 社内で浸透していない挑戦やったこと試み3 2つの内部定例を実⾏

Slide 30

Slide 30 text

©Fusic Co., Ltd. 29 試み・結果・学び試み3 2つの内部定例を実⾏結果成功 • 毎⽇の進捗共有の場があることで全体把握が⾏いやすい • 振り返りの場があることで開発者の不安が浮き彫りになり、毎週チームの動きを改善していける結果

Slide 31

Slide 31 text

©Fusic Co., Ltd. 30 試み・結果・学び試み3 2つの内部定例を実⾏結果成功学び開発者と業務改善を⾏うのがPM(当然) • 開発者は様々な⾓度からチームの動きに不安を覚えているはず • 開発者の声を聞くのは必須 • 業務改善の時間を設けると結果的に効率よく開発ができる学び

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

©Fusic Co., Ltd. 33 試み・結果・学び結果成功も失敗もした • 上司に有効な使い⽅を聞いていたBacklogは、タスク管理しやすかった • 我流のFigmaは、仕様の修正とともに変更に時間がかかる負債となった o デザイナーに⾒てもらって負債ということに気づいた結果試み4 開発者にとって分かりやすいツールにこだわった ※ FigmaもBacklogも良いツール、正しく使えていなかっただけ

Slide 35

Slide 35 text

©Fusic Co., Ltd. 34 試み・結果・学び学び分からないならその道のプロに聞こう • 我流で進めるよりプロに半⽇でも頼ってツールの使い⽅を聞く⽅が結果的に効率はよくなる • 趣味なら問題ない、PMの⽬的はより良いシステムを提供することだ学び結果成功も失敗もした試み4 開発者にとって分かりやすいツールにこだわった

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

©Fusic Co., Ltd. 38 試み・結果・学び学び⼈を頼って得た時間で、時間のない⼈を助けよう • 1〜4の学びを実践できると様々な⼈を頼ることになる • 様々な⼈が忙しくなった中、今度は⾃分が頼られに⾏く番学び試み5 年次の浅い開発者への積極的なフォロー結果成功

Slide 40

Slide 40 text

©Fusic Co., Ltd. 39 試み・結果・学び PM(プロジェクトマネージャー) お客様もチーム。全員でシステム開発を⾏おう主要機能単位でタスク分割しよう開発者と業務改善を⾏うのがPM(当然) 分からないならその道のプロに聞こう⼈を頼って得た時間で、時間のない⼈を助けよう

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

©Fusic Co., Ltd. 44 まとめ PMは広くシステムを⾒る必要があり、細部まで全て⾃分で管理するには時間が⾜りないできる限り早く、広く⼈を頼りなさいあなたが感じる苦しさへの解決策は、誰かが持っているはずだそして早く貴⽅を頼る⼈の元に駆けつけなさい広い視野で全体を⾒て、⾼い視座から障壁を払拭しなさい