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

by SHINCHI, Takahiro

Slide 1

Slide 1 text

1 / 48 ゼロから始めるプロジェクトマネジメント Key Points 2024.7.11 情報システム室進地崇裕

Slide 2

Slide 2 text

2 / 48

Slide 3

Slide 3 text

3 / 48 自己紹介 2021 年1 月にクラスメソッドにジョイン。4 年目。仕事趣味   業務改善したり営業支援したり    モンハン尺八ワンコと遊ぶ   

Slide 4

Slide 4 text

4 / 48 略歴 Web 制作会社でPM 、SE SIer でPM 、SE Web 制作会社でPM 、SE コンサルティング会社でPM クラスメソッドでPM 、SE      つまり  基本的にPM （Project Management ）でご飯を食べてきた人ですただし、大規模プロジェクト管理の経験はありません。 Max20 人月ぐらい。一番多いのは6 人月前後。  

Slide 5

Slide 5 text

5 / 48 このセッションの栄養素学べること  PM の経験ゼロでも今日から試せるノウハウ短期間に少人数でクイックに結果を出すことを求められるプロジェクト管理のノウハウ実戦で磨いた野生の知恵    学べないこと  大規模プロジェクト管理のノウハウ体系的、かつ、アカデミックなPM 理論  

Slide 6

Slide 6 text

6 / 48 PM の最優先事項はデスマーチ回避だと考えています。失うものその有様お金顧客や会社のお金が湯水のように消えていきます仲間みんなやめていきます健康もちろん、身体も心も壊します家族家族を大切にできず、見限られたりします目指す PM の理想像デスマーチ遭遇にて失うもの 

Slide 7

Slide 7 text

7 / 48 既にデスマーチになっている？全力で逃げてください

Slide 8

Slide 8 text

8 / 48 デスマーチを回避する PM 術計画編 1 進行編 2 佳境編 3 ふり返り編 4

Slide 9

Slide 9 text

9 / 48 計画編プロジェクト計画書を作るスケジュールは確率だと頭に叩き込む不用意に日付は出さない見積とスケジュールはメンバーに出してもらう休暇は当然、バグ治しやリファクタリング、CI/CD 環境構築、オペトレも計画に入れておく見せる相手によってスケジュールの粒度は変える設計を一日でも早く行い、レビューを受ける QA エンジニアにレビューしてもらうお客様の担当者は味方でも、お客様の同僚はそうじゃないかもしれない 2 ヶ月以上かかる案件は最初からPhase2 を用意しておく課題管理表、要求管理表、バグ票を用意する           

Slide 10

Slide 10 text

10 / 48 進行編シングルタスクをなるべく維持する急かさない家族の急用を常に優先させるバッファのコントロールはメンバーに任せるスケジュールに遅れがちなメンバーには小さなタスクから任せる新規要件は工数を3 倍にして、扱いを判断する定例Mtg は最小化する進捗ではなく、障害を確認する計画、見積はズレる。重要なのは理由を説明できること         

Slide 11

Slide 11 text

11 / 48 佳境編順序付き一覧表をメンテナンスし続けるリリース手順書を早めに作る重要なバグ修正と重要な機能開発ではバグ修正を優先する QA エンジニアがNo というならリリースしてはいけないメンバーの健康状態に気を配る毎日決まった時間に稼働し、決まった時間に退勤する      

Slide 12

Slide 12 text

12 / 48 ふり返り編必ず打ち上げを行う稼働率の実績値を出す Phase2 以降で本当に行うべきことを改めて考える   

Slide 13

Slide 13 text

13 / 48 計画編計画編

Slide 14

Slide 14 text

14 / 48 プロジェクト計画書を作るプロジェクトのゴールは搖れる  なぜ、このプロジェクトが必要なのか？解決したい課題とゴールを明確化しておくおすすめ資料    デジタル・ガバメント推進標準ガイドライン実践ガイドブック - デジタル庁  ゴールの変遷を書き留めるだけでも意味がある  プロジェクトの外部環境、内部環境の変化に追髄しやすくなるプライオリティの付け方に迷った時に立ち戻れる後のふり返りでも役に立つ   

Slide 15

Slide 15 text

15 / 48 https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2013/hh765979(v=vs.120)?redirectedfrom=MSDN スケジュールは確率だと頭に叩き込むスケジュールには揺れがある  スケジュール算出のベースとなる見積には最大4 倍の誤差が生じるスケジュールはあくまで確率にすぎないという共通認識をプロジェクト関係者で共有する  

Slide 16

Slide 16 text

16 / 48 不用意に日付は出さない日付は一人歩きする  日付はスケジュールは確率ということを忘れさせるお客様の担当者は理解していても、お客様の上長や同僚は確定日程として受け取ってしまう  ` `  日付を出すなら不退転の決意で  どんなにプロジェクトの初期であっても日付を出すなら、それは必ず必達になってしまうと考えるそれを望まないなら、どんな形であっても日付は出してはいけないリリースは「2025 年夏」などのようにぼかす、直近のタスクには日付を明示して守る   

Slide 17

Slide 17 text

17 / 48 見積とスケジュールはメンバーに出してもらう真理: 同じタスクでも見積は担当メンバー毎に異なる  実際の担当メンバーに出してもらわない見積は出鱈目で意味がない（そこにはマネジメント側の希望が書いてあるだけ）人は交換可能ではないことを肝に銘じる   ` ` 真理: 同じ見積工数でも達成可能なスケジュールは担当メンバー毎に異なる  稼働できる時間、集中できる時間、掛け持ち状況や家庭の事情など、あらゆる条件が個別に違う自分で考えて出したスケジュールでなければ人は積極的にコミットしようとしない  

Slide 18

Slide 18 text

18 / 48 休暇は当然、バグ治しやリファクタリング、 CI/CD 環境構築、オペトレも計画に入れておく忘れられやすいスケジュールに影響する項目  休暇、病欠、家庭の不幸バグフィックスリファクタリング環境構築（CI/CD なども含む）オペトレ      バッファ（車間距離）を取らない運転はしないこと  別途バッファは必ずとる。想定外は必ず発生する。安全運転第一。事故ったらお客様も困る。 

Slide 19

Slide 19 text

19 / 48 見せる相手によってスケジュールの粒度は変える細かいタスクの積み上げで全体スケジュールを表現したくなる気持ちはわかるけど  偉い人達はタスクレベルのスケジュールには興味がなく、見通しも悪いメンバーはマスタレベルのスケジュールより、今週何をするのか、今日何をするのかが知りたいソースを１つにできれば理想的だが、タスクから積み上げると不用意日付が表に出てしまうリスクがある詳細スケジュールはメンバーに整備してもらい、そこから抽象化したマスタスケジュールをPM が用意する     確定している詳細に合わせてスケジュールの表現を変える  ふわっとしている部分はふわっとしたスケジュールをカチッとしている部分はカチッとしたスケジュールを  

Slide 20

Slide 20 text

20 / 48 設計を一日でも早く行い、レビューを受ける良い見積のベースは良い設計  設計を早く行えば行うほど、後工程のリスクは減る設計は必ず独りよがりになるので、レビューをしてもらうこと詳細設計はできなくても、概要設計はしておくと、計画変更時に役に立つ    良い設計を導くもの  良い設計のベースは良い要件良い要件のベースは良い要求（課題意識）要求が不明なプロジェクト => デスマーチへ一直線   

Slide 21

Slide 21 text

21 / 48 QA エンジニアにレビューしてもらう Shift Left  QA の観点を要求や要件のレベルから活用する考え方要求、要件、設計もQA エンジニアの厳しい視点で評価してもらう QA エンジニアは、批判的思考、例外検知、具体例で考える能力が高く、不備の検出にもってこい    UI や運用設計もチェックしてもらう  ユーザインタフェース、運用設計も批判的思考で早期にレビューしてもらうとGood せっかく作ったのに使いにくいを避ける  

Slide 22

Slide 22 text

22 / 48 お客様の担当者は味方でも、お客様の同僚はそうじゃないかもしれないお客様の担当者にも、当然ながら社内での立場がある  上長、同僚、経営層など、お客様の担当者を取り巻く関係に注意する本当に説得しなければいけないのは担当者を超えた先にいる人かもしれない   数字、日付、文章の一人歩きに注意する  お客様に提出する数字、日付、文章は一人歩きする前提で提出すること例）情シスのお客様に提出したリリース目処としての日付が、お客様のマーケティング部門に伝わってプレスリリースが計画されてしまった。  

Slide 23

Slide 23 text

23 / 48 2 ヶ月以上かかる案件は最初から Phase2 を用意しておくプロジェクトの真理  必ず要件は膨らむ物事は思ったより簡単には進まない思いつきの要件は後で考えると重要ではないことが本当に多い    ` ` 短期で終わると思われるプロジェクトもPhase 分けしておく  Phase2 を用意しておくことで「それはPhase2 で検討しましょう」が使える Phase1 、つまり本来大切にすべきことから注意が削がれない  

Slide 24

Slide 24 text

24 / 48 課題管理表、要求管理表、バグ票を用意する忘れないこと、プライオリティ以上に、聞いてもらえていること  お客様は自分のメッセージが受け止められていない、大事にされていないことに不安を感じ、怒る各種管理表はメッセージを受け止めたことを示す確実な方法   もちろん本来的な意味でも重要  課題、課題と紐付けた要求の一覧はコミュニケーションコストを削減するメンバーも何のためにやっているのか、何が一番今大事なのか一目瞭然最初、ちょっと面倒だけど必ず用意する   

Slide 25

Slide 25 text

25 / 48 進行編進行編

Slide 26

Slide 26 text

26 / 48 シングルタスクをなるべく維持するマルチタスクは予測不可能性を高める  どんなに見積の精度を高めても、マルチタスクが台無しにするスイッチングコストもバカにならない PM がマルチタスクを要求してしまっているケースもままある    最速で対応して欲しいならやることを詰め込まない  暇になったメンバーにPM が追われるぐらいがいいバランス 

Slide 27

Slide 27 text

27 / 48 急かさない急かしてもいいことは何もない  全力で働いていないという不信を示すことになる品質の低い成果物が突貫であがってくるだけ   重要ポイント  人を急かしても早く動くことはできたとしても早く考えることはできない  ` `

Slide 28

Slide 28 text

28 / 48 家族の急用を常に優先させるほぼ全ての人にとって家族の急用は第一級優先順位事項  家族 >>> 超えられない壁 >>> 労働（プロジェクト）メンバーの家族を大切にしない = メンバーを大切にしない、と同義   いざという時に稼働してもらえるかは信頼貯金の残高次第  信頼貯金が低い状態で命令しても動いてくれないか、動いてくれても辞めちゃいます。信頼貯金は普段の態度が全て（急にはたまらない）  

Slide 29

Slide 29 text

29 / 48 バッファのコントロールはメンバーに任せるバッファをメンバーから取りあげない  バッファの必要量はメンバーによって異なる PM が専横的にプロジェクトの全バッファをコントロールすることは手間がかかりすぎる   プロジェクトチームの共有バッファは過去の稼働率から推定する  過去の稼働率のデータがある場合はそこから推定する過去データがない場合はKKD （私の場合は全体の20 〜30% 程度確保する）  

Slide 30

Slide 30 text

30 / 48 スケジュールに遅れがちなメンバーには小さなタスクから任せる特定のメンバーの進捗が遅れがちの時は  依頼の粒度を細かくする小さく任せて、小さく達成してもらう（成功体験を積み重ねる）徐々に粒度を大きくする    疑ってはいけない大前提  本人は常に一生懸命やっている 

Slide 31

Slide 31 text

31 / 48 新規要件は工数を 3 倍にして、扱いを判断する設計、実装、テストを考慮する  実装しか考えていないケースが多い設計、テストの工数を過小評価していないか？大体等分になっているか？   直感的に思った工数に3 をかける  基本、即答は避ける即答が求められた場合は、パッと思った工数に3 をかけて回答するやるやらないはもちろんのこと、日付は絶対に即答しない   

Slide 32

Slide 32 text

32 / 48 定例 Mtg は最小化する Mtg では何も成果物は生み出されない  決定は行われるが、製造は行われない Mtg をする＝実際にモノを作る時間が削られるすべての定例は例外なく形骸化する    メンバー同士のコミュニケーションは推奨する  生産に必要なコミュニケーションはむしろ推奨チームビルディングのための懇親会や雑談の時間も重要  

Slide 33

Slide 33 text

33 / 48 進捗ではなく、障害を確認する進捗よりも障害の存在に注目する  障害がなければ、物事は勝手に進捗する進捗会議は進捗を確認する場ではなく、PM が障害を認識するための場   PM の仕事は誰よりも早く障害を発見し、それを除去すること  「予定通り」という結果を生むために邪魔になる「障害」を取り除くことに注目、注力する「障害」の中身は多岐に渡り、その中にはメンバーの人生の問題も横たわっている  

Slide 34

Slide 34 text

34 / 48 計画、見積はズレる。重要なのは理由を説明できることビジネスゴールすらズレる。ましてや、計画をや  ズレが問題なのではなく、その理由を説明できないことが問題航海日誌のようにゴールと現在地の記録をとり続ける   Resposibility = Response + bility  責任 = 説明責任を果たす（実行責任ではない）環境は常に流動的（外部環境が変わる、内部環境が変わる、あなたが変わる）プロジェクトゴールが変化したらプロジェクト計画書をアップデートする    全員に口頭で説明して回るわけにはいかないので 

Slide 35

Slide 35 text

35 / 48 佳境編佳境編

Slide 36

Slide 36 text

36 / 48 順序付き一覧表をメンテナンスし続ける全てのやるべきことは一箇所にまとめる  課題管理表、要求管理表、バグ票の日々のメンテナンスができていれば自然に達成できる  第一級優先順位を示し続ける  各表は優先度順に項目が並ぶようにする（プライオリティを明確に示す）優先順位付けマシンになるありとあらゆる活動が優先順位通りになるようにする   

Slide 37

Slide 37 text

37 / 48 リリース手順書を早めに作る要件の抜け漏れに早めに気づく有効打  リリース前後の運用への影響に気づける周知連絡系のタスクを余裕を持って対応できる   リリース工程の工数は意外とかかる  誰がどの程度の工数を投じて何をするかを明確にする本体システムの構築に必死でメンバーは失念しがち  

Slide 38

Slide 38 text

38 / 48 重要なバグ修正と重要な機能開発ではバグ修正を優先するデバッグにかかる工数は読めない  デバッグの発生頻度、影響度、そして修正にかかる工数は読めない不安定なシステムでは計画通りに進めることは困難   まずは安定稼働、機能開発はあと  計画通りに進めるには残バグ数を極小化することが最優先割り込みタスクの抑制にもつながる  

Slide 39

Slide 39 text

39 / 48 QA エンジニアが No というならリリースしてはいけない崖に向かって全力疾走はしない  リリースすることが常に最優先とは限らない危険な状態でリリースする方がビジネスに致命傷を与える可能性も   QA エンジニアを信頼する  QA エンジニアがNo というのは余程のことただし、議論してはいけないという意味ではないリリースが妥当なら説得できるはず   

Slide 40

Slide 40 text

40 / 48 メンバーの健康状態に気を配るメンバーの人生 >>> 超えられない壁 >>> プロジェクト  優先順位を誤らない。メンバーの人生は唯一無二。プロジェクトが終わってもメンバーの人生は続く当然、倒れたらプロジェクトは計画通り進まない    次のプロジェクトも視野に入れる  心身が健康でありさえすれば、メンバーは自律的に学び、得たいものを得て成長する次のプロジェクトにも参加してくれる可能性が高まる Who goes slowly goes far. （ゆっくりゆくものがとおくまでゆく）   

Slide 41

Slide 41 text

41 / 48 毎日決まった時間に稼働し、決まった時間に退勤する PM の行動をなるべく予測可能にするメリット  メンバーやお客様が質問や問い合わせをしやすくなる開発のリズムをPM が作り出すことができるイレギュラーな稼働を抑制できる    定時出勤、定時退社が最強  PM が無理する人だと思われると全員が不幸になる（鉄の意志は必要） PM の行動がタイムボックス化する  

Slide 42

Slide 42 text

42 / 48 ふり返り編ふり返り編

Slide 43

Slide 43 text

43 / 48 必ず打ち上げを行うプロジェクトやフェーズが終わったことを明確に示す  プロジェクトのリズムを作るダラダラと追加要件や残件対応が続くことを防ぐ終わったというサインは報酬系にガツンとくる    感謝を示す最高の場  下手なチームビルディングより打ち上げ反省よりも称賛を  

Slide 44

Slide 44 text

44 / 48 稼働率の実績値を出す次の見積精度をあげるために  実際のチームで実戦で得た、貴重なデータ見積誤差、稼働の予実、実際の稼働率を算出しておく   稼働率は絶対に評価には使わないこと  チームに不信が蔓延る（チーム殺し）正確な値も取れなくなる稼働率の向上が目的なのではなく、予測の精度をあげることが目的   

Slide 45

Slide 45 text

45 / 48 Phase2 以降で本当に行うべきことを改めて考える絶対に必要だと思っていたはずのことが？  時間をおいて改めて検討すると、絶対に必要ではなくなることは多々ある重要と必要は違う  ` `  再度プロジェクト計画書に立ち戻る  プロジェクト計画書にあるゴールや課題に照らして、本当に必要なものだけPhase2 へ 

Slide 46

Slide 46 text

46 / 48 通底していることはプロジェクトのために人があるのではなく、人のためにプロジェクトがあるということ縁あって出会ったプロジェクトメンバーと幸せなプロジェクト生活を！ Good Luck!! まとめ