ゼロから始めるプロジェクトマネジメント Key Points

Classmethod Odysseyの登壇資料です。

プロジェクトマネジメント経験ゼロでも今日から実戦できるKey Pointsをまとめました。

# 学べること
- PMの経験ゼロでも今日から試せるノウハウ
- 短期間に少人数でクイックに結果を出すことを求められるプロジェクト管理のノウハウ
- 実戦で磨いた野生の知恵

# 学べないこと
- 大規模プロジェクト管理のノウハウ
- 体系的、かつ、アカデミックなPM理論

1. 1 / 48 ゼロから始める プロジェクトマネジメント Key Points 2024.7.11 情報システム室 進地崇裕
2. 2 / 48
3. 3 / 48 自己紹介 2021 年1 月にクラスメソッドにジョイン。4 年目。 仕事 趣味   業務改善したり 営業支援したり    モンハン 尺八 ワンコと遊ぶ   
4. 4 / 48 略歴 Web 制作会社でPM 、SE SIer でPM 、SE Web 制作会社でPM 、SE コンサルティング会社でPM クラスメソッドでPM 、SE      つまり  基本的にPM （Project Management ）でご飯を食べてきた人です ただし、大規模プロジェクト管理の経験はありません。 Max20 人月ぐらい。一番多いのは6 人月前後。  
5. 5 / 48 このセッションの栄養素 学べること  PM の経験ゼロでも今日から試せるノウハウ 短期間に少人数でクイックに結果を出すことを求められる プロジェクト管理のノウハウ 実戦で磨いた野生の知恵    学べないこと  大規模プロジェクト管理のノウハウ 体系的、かつ、アカデミックなPM 理論  
6. 6 / 48 PM の最優先事項はデスマーチ回避だと考えています。 失うもの その有様 お金 顧客や会社のお金が湯水のように消えていきます 仲間 みんなやめていきます 健康 もちろん、身体も心も壊します 家族 家族を大切にできず、見限られたりします 目指す PM の理想像 デスマーチ遭遇にて失うもの 
7. 7 / 48 既にデスマーチになっている？ 全力で逃げてください
8. 8 / 48 デスマーチを回避する PM 術 計画編 1 進行編 2 佳境編 3 ふり返り編 4
9. 9 / 48 計画編 プロジェクト計画書を作る スケジュールは確率だと頭に叩き込む 不用意に日付は出さない 見積とスケジュールはメンバーに出してもらう 休暇は当然、バグ治しやリファクタリング、CI/CD 環境構築、オペトレも計画に入れておく 見せる相手によってスケジュールの粒度は変える 設計を一日でも早く行い、レビューを受ける QA エンジニアにレビューしてもらう お客様の担当者は味方でも、お客様の同僚はそうじゃないかもしれない 2 ヶ月以上かかる案件は最初からPhase2 を用意しておく 課題管理表、要求管理表、バグ票を用意する           
10. 10 / 48 進行編 シングルタスクをなるべく維持する 急かさない 家族の急用を常に優先させる バッファのコントロールはメンバーに任せる スケジュールに遅れがちなメンバーには小さなタスクから任せる 新規要件は工数を3 倍にして、扱いを判断する 定例Mtg は最小化する 進捗ではなく、障害を確認する 計画、見積はズレる。重要なのは理由を説明できること         
11. 11 / 48 佳境編 順序付き一覧表をメンテナンスし続ける リリース手順書を早めに作る 重要なバグ修正と重要な機能開発ではバグ修正を優先する QA エンジニアがNo というならリリースしてはいけない メンバーの健康状態に気を配る 毎日決まった時間に稼働し、決まった時間に退勤する      
12. 12 / 48 ふり返り編 必ず打ち上げを行う 稼働率の実績値を出す Phase2 以降で本当に行うべきことを改めて考える   
13. 13 / 48 計画編 計画編
14. 14 / 48 プロジェクト計画書を作る プロジェクトのゴールは搖れる  なぜ、このプロジェクトが必要なのか？ 解決したい課題とゴールを明確化しておく おすすめ資料    デジタル・ガバメント推進標準ガイドライン実践ガイドブック - デジタル庁  ゴールの変遷を書き留めるだけでも意味がある  プロジェクトの外部環境、内部環境の変化に追髄しやすくなる プライオリティの付け方に迷った時に立ち戻れる 後のふり返りでも役に立つ   
15. 15 / 48 https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2013/hh765979(v=vs.120)?redirectedfrom=MSDN スケジュールは確率だと頭に叩き込む スケジュールには揺れがある  スケジュール算出のベースとなる見積には最大4 倍の誤差が生じる スケジュールはあくまで確率にすぎないという共通認識をプロジェクト関係者で共有する  
16. 16 / 48 不用意に日付は出さない 日付は一人歩きする  日付は スケジュールは確率 ということを忘れさせる お客様の担当者は理解していても、お客様の上長や同僚は確定日程として受け取ってしまう  ` `  日付を出すなら不退転の決意で  どんなにプロジェクトの初期であっても日付を出すなら、それは必ず必達になってしまうと考える それを望まないなら、どんな形であっても日付は出してはいけない リリースは「2025 年夏」などのようにぼかす、直近のタスクには日付を明示して守る   
17. 17 / 48 見積とスケジュールはメンバーに出してもらう 真理: 同じタスクでも見積は担当メンバー毎に異なる  実際の担当メンバーに出してもらわない見積は出鱈目で意味がない （そこにはマネジメント側の希望が書いてあるだけ） 人は交換可能ではない ことを肝に銘じる   ` ` 真理: 同じ見積工数でも達成可能なスケジュールは担当メンバー毎 に異なる  稼働できる時間、集中できる時間、掛け持ち状況や家庭の事情など、あらゆる条件が個別に違う 自分で考えて出したスケジュールでなければ人は積極的にコミットしようとしない  
18. 18 / 48 休暇は当然、バグ治しやリファクタリング、 CI/CD 環境構築、オペトレも計画に入れておく 忘れられやすいスケジュールに影響する項目  休暇、病欠、家庭の不幸 バグフィックス リファクタリング 環境構築（CI/CD なども含む） オペトレ      バッファ（車間距離）を取らない運転はしないこと  別途バッファは必ずとる。想定外は必ず発生する。安全運転第一。事故ったらお客様も困る。 
19. 19 / 48 見せる相手によってスケジュールの粒度は変える 細かいタスクの積み上げで全体スケジュールを 表現したくなる気持ちはわかるけど  偉い人達はタスクレベルのスケジュールには興味がなく、見通しも悪い メンバーはマスタレベルのスケジュールより、今週何をするのか、今日何をするのかが知りたい ソースを１つにできれば理想的だが、タスクから積み上げると不用意日付が表に出てしまうリスクがある 詳細スケジュールはメンバーに整備してもらい、そこから抽象化したマスタスケジュールをPM が用意する     確定している詳細に合わせてスケジュールの表現を変える  ふわっとしている部分はふわっとしたスケジュールを カチッとしている部分はカチッとしたスケジュールを  
20. 20 / 48 設計を一日でも早く行い、レビューを受ける 良い見積のベースは良い設計  設計を早く行えば行うほど、後工程のリスクは減る 設計は必ず独りよがりになるので、レビューをしてもらうこと 詳細設計はできなくても、概要設計はしておくと、計画変更時に役に立つ    良い設計を導くもの  良い設計のベースは良い要件 良い要件のベースは良い要求（課題意識） 要求が不明なプロジェクト => デスマーチへ一直線   
21. 21 / 48 QA エンジニアにレビューしてもらう Shift Left  QA の観点を要求や要件のレベルから活用する考え方 要求、要件、設計もQA エンジニアの厳しい視点で評価してもらう QA エンジニアは、批判的思考、例外検知、具体例で考える能力が高く、不備の検出にもってこい    UI や運用設計もチェックしてもらう  ユーザインタフェース、運用設計も批判的思考で早期にレビューしてもらうとGood せっかく作ったのに使いにくいを避ける  
22. 22 / 48 お客様の担当者は味方でも、 お客様の同僚はそうじゃないかもしれない お客様の担当者にも、当然ながら社内での立場がある  上長、同僚、経営層など、お客様の担当者を取り巻く関係に注意する 本当に説得しなければいけないのは担当者を超えた先にいる人かもしれない   数字、日付、文章の一人歩きに注意する  お客様に提出する数字、日付、文章は一人歩きする前提で提出すること 例）情シスのお客様に提出したリリース目処としての日付が、 お客様のマーケティング部門に伝わってプレスリリースが計画されてしまった。  
23. 23 / 48 2 ヶ月以上かかる案件は最初から Phase2 を用意しておく プロジェクトの真理  必ず要件は膨らむ 物事は思ったより簡単には進まない 思いつきの要件は後で考えると重要ではないことが 本当に 多い    ` ` 短期で終わると思われるプロジェクトもPhase 分けしておく  Phase2 を用意しておくことで「それはPhase2 で検討しましょう」が使える Phase1 、つまり本来大切にすべきことから注意が削がれない  
24. 24 / 48 課題管理表、要求管理表、バグ票を用意する 忘れないこと、プライオリティ以上に、聞いてもらえていること  お客様は自分のメッセージが受け止められていない、大事にされていないことに不安を感じ、怒る 各種管理表はメッセージを受け止めたことを示す確実な方法   もちろん本来的な意味でも重要  課題、課題と紐付けた要求の一覧はコミュニケーションコストを削減する メンバーも何のためにやっているのか、何が一番今大事なのか一目瞭然 最初、ちょっと面倒だけど必ず用意する   
25. 25 / 48 進行編 進行編
26. 26 / 48 シングルタスクをなるべく維持する マルチタスクは予測不可能性を高める  どんなに見積の精度を高めても、マルチタスクが台無しにする スイッチングコストもバカにならない PM がマルチタスクを要求してしまっているケースもままある    最速で対応して欲しいならやることを詰め込まない  暇になったメンバーにPM が追われるぐらいがいいバランス 
27. 27 / 48 急かさない 急かしてもいいことは何もない  全力で働いていないという不信を示すことになる 品質の低い成果物が突貫であがってくるだけ   重要ポイント  人を急かしても 早く動くことはできたとしても早く考えることはできない  ` `
28. 28 / 48 家族の急用を常に優先させる ほぼ全ての人にとって家族の急用は第一級優先順位事項  家族 >>> 超えられない壁 >>> 労働（プロジェクト） メンバーの家族を大切にしない = メンバーを大切にしない、と同義   いざという時に稼働してもらえるかは信頼貯金の残高次第  信頼貯金が低い状態で命令しても動いてくれないか、動いてくれても辞めちゃいます。 信頼貯金は普段の態度が全て（急にはたまらない）  
29. 29 / 48 バッファのコントロールはメンバーに任せる バッファをメンバーから取りあげない  バッファの必要量はメンバーによって異なる PM が専横的にプロジェクトの全バッファをコントロールすることは手間がかかりすぎる   プロジェクトチームの共有バッファは過去の稼働率から推定する  過去の稼働率のデータがある場合はそこから推定する 過去データがない場合はKKD （私の場合は全体の20 〜30% 程度確保する）  
30. 30 / 48 スケジュールに遅れがちなメンバーには 小さなタスクから任せる 特定のメンバーの進捗が遅れがちの時は  依頼の粒度を細かくする 小さく任せて、小さく達成してもらう（成功体験を積み重ねる） 徐々に粒度を大きくする    疑ってはいけない大前提  本人は常に一生懸命やっている 
31. 31 / 48 新規要件は工数を 3 倍にして、扱いを判断する 設計、実装、テストを考慮する  実装しか考えていないケースが多い 設計、テストの工数を過小評価していないか？大体等分になっているか？   直感的に思った工数に3 をかける  基本、即答は避ける 即答が求められた場合は、パッと思った工数に3 をかけて回答する やるやらないはもちろんのこと、日付は絶対に即答しない   
32. 32 / 48 定例 Mtg は最小化する Mtg では何も成果物は生み出されない  決定は行われるが、製造は行われない Mtg をする＝実際にモノを作る時間が削られる すべての定例は例外なく形骸化する    メンバー同士のコミュニケーションは推奨する  生産に必要なコミュニケーションはむしろ推奨 チームビルディングのための懇親会や雑談の時間も重要  
33. 33 / 48 進捗ではなく、障害を確認する 進捗よりも障害の存在に注目する  障害がなければ、物事は勝手に進捗する 進捗会議は進捗を確認する場ではなく、PM が障害を認識するための場   PM の仕事は誰よりも早く障害を発見し、それを除去すること  「予定通り」という結果を生むために邪魔になる「障害」を取り除くことに注目、注力する 「障害」の中身は多岐に渡り、その中にはメンバーの人生の問題も横たわっている  
34. 34 / 48 計画、見積はズレる。重要なのは理由を説明できること ビジネスゴールすらズレる。ましてや、計画をや  ズレが問題なのではなく、その理由を説明できないことが問題 航海日誌のようにゴールと現在地の記録をとり続ける   Resposibility = Response + bility  責任 = 説明責任を果たす（実行責任ではない） 環境は常に流動的（外部環境が変わる、内部環境が変わる、あなたが変わる） プロジェクトゴールが変化したらプロジェクト計画書をアップデートする    全員に口頭で説明して回るわけにはいかないので 
35. 35 / 48 佳境編 佳境編
36. 36 / 48 順序付き一覧表をメンテナンスし続ける 全てのやるべきことは一箇所にまとめる  課題管理表、要求管理表、バグ票の日々のメンテナンスができていれば自然に達成できる  第一級優先順位を示し続ける  各表は優先度順に項目が並ぶようにする（プライオリティを明確に示す） 優先順位付けマシンになる ありとあらゆる活動が優先順位通りになるようにする   
37. 37 / 48 リリース手順書を早めに作る 要件の抜け漏れに早めに気づく有効打  リリース前後の運用への影響に気づける 周知連絡系のタスクを余裕を持って対応できる   リリース工程の工数は意外とかかる  誰がどの程度の工数を投じて何をするかを明確にする 本体システムの構築に必死でメンバーは失念しがち  
38. 38 / 48 重要なバグ修正と重要な機能開発ではバグ修正を優先する デバッグにかかる工数は読めない  デバッグの発生頻度、影響度、そして修正にかかる工数は読めない 不安定なシステムでは計画通りに進めることは困難   まずは安定稼働、機能開発はあと  計画通りに進めるには残バグ数を極小化することが最優先 割り込みタスクの抑制にもつながる  
39. 39 / 48 QA エンジニアが No というならリリースしてはいけない 崖に向かって全力疾走はしない  リリースすることが常に最優先とは限らない 危険な状態でリリースする方がビジネスに致命傷を与える可能性も   QA エンジニアを信頼する  QA エンジニアがNo というのは余程のこと ただし、議論してはいけないという意味ではない リリースが妥当なら説得できるはず   
40. 40 / 48 メンバーの健康状態に気を配る メンバーの人生 >>> 超えられない壁 >>> プロジェクト  優先順位を誤らない。メンバーの人生は唯一無二。 プロジェクトが終わってもメンバーの人生は続く 当然、倒れたらプロジェクトは計画通り進まない    次のプロジェクトも視野に入れる  心身が健康でありさえすれば、メンバーは自律的に学び、得たいものを得て成長する 次のプロジェクトにも参加してくれる可能性が高まる Who goes slowly goes far. （ゆっくりゆくものがとおくまでゆく）   
41. 41 / 48 毎日決まった時間に稼働し、決まった時間に退勤する PM の行動をなるべく予測可能にするメリット  メンバーやお客様が質問や問い合わせをしやすくなる 開発のリズムをPM が作り出すことができる イレギュラーな稼働を抑制できる    定時出勤、定時退社が最強  PM が無理する人だと思われると全員が不幸になる（鉄の意志は必要） PM の行動がタイムボックス化する  
42. 42 / 48 ふり返り編 ふり返り編
43. 43 / 48 必ず打ち上げを行う プロジェクトやフェーズが終わったことを明確に示す  プロジェクトのリズムを作る ダラダラと追加要件や残件対応が続くことを防ぐ 終わったというサインは報酬系にガツンとくる    感謝を示す最高の場  下手なチームビルディングより打ち上げ 反省よりも称賛を  
44. 44 / 48 稼働率の実績値を出す 次の見積精度をあげるために  実際のチームで実戦で得た、貴重なデータ 見積誤差、稼働の予実、実際の稼働率を算出しておく   稼働率は絶対に評価には使わないこと  チームに不信が蔓延る（チーム殺し） 正確な値も取れなくなる 稼働率の向上が目的なのではなく、予測の精度をあげることが目的   
45. 45 / 48 Phase2 以降で本当に行うべきことを改めて考える 絶対に必要だと思っていたはずのことが？  時間をおいて改めて検討すると、 絶対に必要ではなくなることは多々ある 重要と必要は違う  ` `  再度プロジェクト計画書に立ち戻る  プロジェクト計画書にあるゴールや課題に照らして、本当に必要なものだけPhase2 へ 
46. 46 / 48 通底していることは プロジェクトのために人があるのではなく、 人のためにプロジェクトがある ということ 縁あって出会ったプロジェクトメンバーと幸せなプロジェクト生活を！ Good Luck!! まとめ
47. 47 / 48
48. 48 / 48