Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

なおと
June 22, 2024
500

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

PHP CONFERENCE FUKUOKA 2024での発表資料です。

https://fortee.jp/phpcon-fukuoka-2024/proposal/eb2e25af-3437-4a7f-9cee-a0f67d112bd5

なおと

June 22, 2024
Tweet

Transcript

  1. ©Fusic Co., Ltd. 2 CONTENTS ⽬次 1. PMの定義 2. PMを任せてもらえるまで

    3. プロジェクト概要 4. 試み・結果・学び 5. 視野・視座の変化 6. まとめ
  2. ©Fusic Co., Ltd. 6 PMの定義 PM(プロジェクトマネージャー) • タスク管理 • スケジュール管理

    • チームビルディング 開発しやすい環境を整える 内部⾯
  3. ©Fusic Co., Ltd. 8 PMを任せてもらえるまで 1年⽬前半 • 研修 1年⽬後半 •

    開発業務に従事 • スケジュールはPMに引いてもらう
  4. ©Fusic Co., Ltd. 9 PMを任せてもらえるまで 2年⽬前半 • 開発業務に従事 • ⾃⾝のタスクとスケジュールを管理

    2年⽬中旬 • 開発者リーダーとしてシステム開発を⾏う • ベテランエンジニアに相談役になってもらう • 他開発者のタスク分け、スケジュール管理
  5. ©Fusic Co., Ltd. 12 POINT u 新卒2年⽬をPMとするには規模が⼤きい u 売り上げ⾦額1000万超 u

    要件定義期間を含めシステム作成期間は4ヶ⽉間 顧客訪問サービス管理システム ⻄部ガス株式会社 さま 顧客の元に向かい、ガス機器点検等を⾏う訪問サービスのためのシステム • 営業員に訪問先の顧客を割り当てる機能(管理者⽤画⾯) • 営業員が訪問を⾏った際にその結果を保存する機能(営業員⽤画⾯) プロジェクト概要
  6. ©Fusic Co., Ltd. 13 プロジェクト概要 開発チーム PM(私) (2年⽬エンジニア) PM補佐 (5年⽬エンジニア)

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

    品質担保 開発者 お客様 仕様詰め テストチーム システムテスト PM補佐 仕様共有 開発 PM相談
  8. ©Fusic Co., Ltd. 18 試み・結果・学び 試み1 お客様との距離を近く保つ 結果 成功(⻄部ガスさまに感謝) •

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

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

    お客様もチーム。全員でシステム開発を⾏おう。 • 問題について⼀番知っているのはお客様 • 巻き込まないでどうする! 学び
  11. ©Fusic Co., Ltd. 23 試み・結果・学び 試み2 細かくタスク・スケジュールを分割した 結果 少し失敗 •

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

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

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

    主要機能単位でタスク分割しよう • ⾃分が開発するとどれくらいの時間を要するか、⾒積もった上でタスク として開発者に渡すこと • 悲観的にスケジュールを考えることをおすすめする Point
  15. ©Fusic Co., Ltd. 28 試み・結果・学び • 以下2つを実⾏ • 毎⽇15分間、午前中に本⽇の予定、問題点等共有を⾏う定例 •

    社内でよく⾏われているものを踏襲 • 週末に1度1時間、その週のチームの動きについて振り返る定例 • 社内で浸透していない挑戦 やったこと 試み3 2つの内部定例を実⾏
  16. ©Fusic Co., Ltd. 29 試み・結果・学び 試み3 2つの内部定例を実⾏ 結果 成功 •

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

    開発者と業務改善を⾏うのがPM(当然) • 開発者は様々な⾓度からチームの動きに不安を覚えているはず • 開発者の声を聞くのは必須 • 業務改善の時間を設けると結果的に効率よく開発ができる 学び
  18. ©Fusic Co., Ltd. 33 試み・結果・学び 結果 成功も失敗もした • 上司に有効な使い⽅を聞いていたBacklogは、タスク管理しやすかった •

    我流のFigmaは、仕様の修正とともに変更に時間がかかる負債となった o デザイナーに⾒てもらって負債ということに気づいた 結果 試み4 開発者にとって分かりやすいツールにこだわった ※ FigmaもBacklogも良いツール、正しく使えていなかっただけ
  19. ©Fusic Co., Ltd. 34 試み・結果・学び 学び 分からないならその道のプロに聞こう • 我流で進めるよりプロに半⽇でも頼ってツールの使い⽅を聞く⽅が結果 的に効率はよくなる

    • 趣味なら問題ない、PMの⽬的はより良いシステムを提供することだ 学び 結果 成功も失敗もした 試み4 開発者にとって分かりやすいツールにこだわった
  20. ©Fusic Co., Ltd. 36 試み・結果・学び • 経験が浅い⼈には特に話しかけた • 開発で困っていることはないか? •

    重いタスクを振った時には予め難しいものだと伝える やったこと 試み5 年次の浅い開発者への積極的なフォロー
  21. ©Fusic Co., Ltd. 37 試み・結果・学び 試み5 年次の浅い開発者への積極的なフォロー 結果 成功 •

    (やりすぎない)先回りフォローで⼆度⼿間を防いだ • ⼼のケアにもなる • 開発速度の底上げ 結果
  22. ©Fusic Co., Ltd. 38 試み・結果・学び 学び ⼈を頼って得た時間で、時間のない⼈を助けよう • 1〜4の学びを実践できると様々な⼈を頼ることになる •

    様々な⼈が忙しくなった中、今度は⾃分が頼られに⾏く番 学び 試み5 年次の浅い開発者への積極的なフォロー 結果 成功