Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

プロジェクト管理しないという提案

1,400 views

Published on

DevLOVE現場甲子園2015「東北大会」発表資料

Published in: Engineering

プロジェクト管理しないという提案

  1. 1. プロジェクト管理しない という提案
  2. 2. プロジェクト管理 スケジュール管理 課題管理 バグ管理
  3. 3. プロジェクト管理のメリット 開発スケジュールが見通せる 全員が状況を把握できる 打ち合わせが短縮できる
  4. 4. 漏れがなくなる 効率的に開発が進められる 責任範疇が明確になる プロジェクト管理のメリット
  5. 5. 漏れがなくなる 効率的に開発が進められる 責任範疇が明確になる プロジェクト管理のメリット
  6. 6. でも、 その管理って 本当に必要ですか?
  7. 7. 自己紹介 森 英寿 株式会社ZIG CTO Twitter: @h_mori Facebook: hidetoshi.mori
  8. 8. 開発プロダクト TweetMe SOICHA ATND暦 ZIGNOTE. Zappers (開発中)
  9. 9. 現在の会社 2014年2月 3人で株式会社ZIGを設立 B to C プラットフォーム戦略 ビジネスモデル: 広告収益 リーン・スタートアップ
  10. 10. リーン・スタートアップ 価値の薄い要素を最小限に抑え 素早く改良を重ね成功に近づける ビジネス手法
  11. 11. プロダクト・マーケットフィット 提供が本当に可能か? 需要があるか? マネタイズが可能か?
  12. 12. なぜリーンなの? 新しいアイディアに資金調達は難しい プロダクト・マーケットフィットが検証される までリーン戦略しか取れない
  13. 13. 成長曲線
  14. 14. 損益分岐点
  15. 15. バーンレート
  16. 16. スタートアップ = チキンレース
  17. 17. 目的 開発が遅延せずバグのなく品質の高いシステム を作る
  18. 18. 目的 開発が遅延せずバグのなく品質の高いシステム を作る
  19. 19. 目的 開発が遅延せずバグのなく品質の高いシステム を作る 多くのユーザーに利用されるサービスを提供する
  20. 20. 目的 開発が遅延せずバグのなく品質の高いシステム を作る 多くのユーザーに利用されるサービスを提供する (※特にカネ払いの良い顧客)
  21. 21. 戦略 少ない予算でプロトタイプ開発 少ない予算で検証 少ない予算で修正 早急にPMFを検証し資金調達
  22. 22. 手段 徹底的に無駄を排除 価値が薄い機能を捨てる 主要な機能をのみをブラッシュアップ
  23. 23. 話を戻します
  24. 24. プロジェクト管理の現状 スケジュール管理 実装検証項目が多い 正確なスケジュールが引けない リスケの嵐
  25. 25. プロジェクト管理の現状 スケジュール管理 実装検証項目が多い 正確なスケジュールが引けない リスケの嵐 時間がないのに更にリスケ工数がかかる
  26. 26. プロジェクト管理の現状 課題管理 膨大な要望・課題数・矛盾 優先度が定性的な独断
  27. 27. プロジェクト管理の現状 課題管理 膨大な要望・課題数・矛盾 優先度が定性的な独断 重要じゃない機能にコストをかける
  28. 28. プロジェクト管理の現状 バグ管理 膨大なバグ報告 重複しまくり 膨大なチケット整理
  29. 29. プロジェクト管理の現状 バグ管理 膨大なバグ報告 重複しまくり 膨大なチケット整理 デバッグ疲れ → モチベーション低下
  30. 30. 弊害 思考停止
  31. 31. 管理しないとどうなる? 管理コストが減る 打ち合わせ回数が格段に増える 裁量の範囲が広くなる 意思決定スピードが上がる 思考の幅が広がる
  32. 32. スケジュール管理 概略スケジュールのみ  ↓ 変化に対応した柔軟なリスケが可能
  33. 33. 課題管理 アイディアがたくさん生まれる 価値(費用対効果)が低いものを捨てられる 重要なことは何度も議題に上がる  ↓ 優先度がより明確になる   ※重要度 x コストで実装フェーズが決まる
  34. 34. バグ管理 クリティカルなバグから着手  ↓ ※例)1%の環境下で起こるバグは後回し
  35. 35. 仕様変更に対する意識 開発者 >リスク共有による不安解消 >より良い仕様のアイディア 企画者 >費用対効果の高い最適解
  36. 36. 高いモチベーションが維持できる
  37. 37. プロジェクト管理のメリット(再掲) 開発スケジュールが見通せる 全員が状況を把握できる 打ち合わせ時間が短縮できる 漏れがなくなる 効率的に開発が進められる 責任範疇が明確になる
  38. 38. プロジェクト管理のメリット(再掲) 開発スケジュールが見通せる 全員が状況を把握できる 打ち合わせ時間が短縮できる 漏れがなくなる 効率的に開発が進められる 責任範疇が明確になる ユーザーのためではなく 提供者の論理
  39. 39. 前提条件 絶対的なメンバーの信頼 価値あるモノづくりの意識 ホラクラシー型組織構造
  40. 40. 最後に スケールする組織、サービスは質の開発が重要 “ 価値 = 質 x (量^2) ” – ランチェスターの法則
  41. 41. ご静聴ありがとうございました

×