Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
「最短で達成する 全体最適のプロジェクトマネジメント」読書メモ

Part1 プロジェクトは人が行うもの

  • プロジェクトとは
    • 今までやったこと無いことをする
    • 高い不確実性
    • 納期がある
    • 人が行うもの
  • 人にまつわる6つの問題行動
    • サバよみ(スケジュールに余裕を持たせる)
    • 予算と時間をあるだけ使う
    • 一夜漬け(ギリギリまでやらない)
    • 過剰管理(タスクに繋がりがあると遅れは伝搬する)
    • 早く終わっても報告しない
    • マルチタスク

Part2 マルチタスクをなくせ!

  • マルチプロジェクト・マルチタスクは却って納期を遅らせる
  • 優先順位を決めて集中する
  • 「今はやらない」ことで「集中する」ことが可能になる
  • 集中して取り組むと品質、キャッシュフローも改善する

抵抗の6階層

抵抗は予め想定し、階層に従って、ひとつずつコンセンサスを作って取り組んでいく。

  1. 取り組もうとしている問題が問題であるとは思わない
  2. 解決しようとしているやり方に合意できない
  3. この解決方法を実行すると、ネガティブな問題が発生する
  4. 提案されている解決方法を実行するのに、障害があるので現実的でない
  5. 知らないことに対する恐れ

重みづけに記号を使う

評価項目に点数で重み付けをするよりは記号を使う。 (◎○△×。。)

他の評価基準が低くても極めて重要でどうしてもやるという経営判断の場合には☆を付ける。

集中

集中は、Not To Do(やらない)ということを決めることではじめてできる

Part3 目標を共有せよ

  • 目標はODSCですり合わせる
    • これが全部できたら最高ですか
    • 完成したODSCは経営幹部とすり合わせる

ODSC

  • Objectives(目的)
    • 目的はなんですか
    • 他にありませんか
    • 財務、顧客、業務プロセス、成長と育成、経営理念、社会貢献の視点は入っていますか
  • Deliverables(成果物)
    • 成果物はなんですか
    • 他にありませんか
    • 成果物は手段にあたる。ODSCは目的と手段を切り分ける
  • Success Criteria(成功基準)
    • 成功基準はなんですか
    • 基準は測定可能であること

言ったことはそのまま書く

  • 本人の言葉がそのまま反映されると自己原因性が生まれる
  • モチベーションは自己原因性から生まれる

ODSCで人材育成

  • 成長視点からの目的を記述する
    • どう成長したい
    • こうなりたい
  • プロジェクトの成功と個人の成長の実現がオーバーラップ
    • 使命感が生まれる

Part4 成功へのシナリオを作る

  • 段取りがプロジェクト成功の8割を握る
    • 段取り八分
  • ODSCをゴールに置いて、さかのぼってタスクを洗い出す
    • その前にやることはなんですか
    • ほんとうにそれだけですか
    • ○○したら☓☓できるんですね
  • タスクは声に出して読み上げる
    • 声に出して議論すると、他人の脳みそを使える

🤔 プロダクトバックログからスプリントバックログ作るときに使えそうだなぁ

タスク

  • 動詞で「〜する」と表す
    • 時間や担当者が自然にイメージされる
  • 全体像を見るためのもの
    • 細かすぎても大雑把でもいけない
    • 備忘録やチェックリストは別でやればよい
    • 数は50~100を越えると難しくなる
  • 分かりやすく書く
    • 専門用語を避ける
    • 外部の助けを得られる

Part5 期間短縮!

  • サバ取り段取り
    • 担当を割り当て、リソースの重複とマルチタスクをなくす
    • 各タスクのサバはとりわけ、プロジェクトのバッファにする
    • チャレンジの合計期間の50%が目安(チャレンジの見積もりを五分五分と考える)
    • 🙄「チャレンジ」と「サバ」に分けるのがかなり難しいと思う
    • 💭 自分の作業が予定通りに終わらなかった場合、何のペナルティもなく誰も責めなかったとしても、責任を感じるものではないかな
  • ☹️ マルチプロジェクトに合わせて人員配置をしていくのがどうにも気に食わない
    • 💭 メンバーはタスクに携わるのではなく、プロジェクトに携わるべきでは
  • 🤔 期間を短くすることと、タスクを可能な限り少なくすることが解決策だと思ってる
    • 💭 スコープを小さくし、期間を短くし、プロジェクトを可能な限り早く「終わらせる」
    • 💭 継続するか、辞めるか、経営判断の機会を増やす
  • 「ゆとり」はみんなでつくる
    • 全員同席の重要性
    • 🤔 密度を高く保つには人数も鍵になってくるだろう
  • 気がかりなことの原因を解消し利点に変える
    • 🤔 インセプションデッキでいうところの、「夜も眠れない問題」かな

Part6 全体最適の先手管理!

  • 進捗率は「あと何日」で管理する
    • 🤔 タスクを小さくして測定可能な完了条件で進捗を測るのがいいと思っている
    • 😲 が、見積もりの訓練になるというのはその通りだなと思った
    • 未来のことを聞いている。過去は変えられないが未来のことを変えられる
    • 😎 よい
  • プロジェクトマネージャが現場に聞きに行く
    • "プロジェクトマネージャのしごとは、進捗を管理することではなく、プロジェクトを成功させるようにマネジメントすることである"
    • 問題があるとしたらなんですか
    • 何か助けられることはないですか
  • バッファは公開することで信頼関係が生まれる
    • 公開することで、問題が明らかなのに手を打たなかったことが問題になる
    • 担当者、プロジェクトマネージャ、経営者を守る
    • プロジェクトにはそもそも不確実性がある
    • 予想できないものでバッファが使われるのは健全(天候、病気、技術的問題)
    • 準備不足による遅れは悪い遅れ
  • プロジェクトマネジメントは「プロジェクト管理」ではなく「プロジェクト経営」
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.