どうすれば小さなチームでも大きな成果を出せるのか

26,189 views

Published on

スクーの授業で使った資料です。
ソフトウェア開発をしていく中で、沢山のリソースやお金をつぎ込んで開発するのではなく、どうすれば少人数のチームで低コストな中で開発を続けていくことで、大きな成果を出す為の考えかたについて説明しています。

Published in: Technology
1 Comment
72 Likes
Statistics
Notes
  • hey hallo coukd not understand but any way all the best
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
26,189
On SlideShare
0
From Embeds
0
Number of Embeds
17,335
Actions
Shares
0
Downloads
118
Comments
1
Likes
72
Embeds 0
No embeds

No notes for slide

どうすれば小さなチームでも大きな成果を出せるのか

  1. 1. Schoo WEB-cumpas   少⼈人数のチーム、低コストで開発を続けていくためのプロセスを学ぶ   どうすれば⼩小さなチームでも                          ⼤大きな成果を出せるのか   2013/03/21   株式会社ソニックガーデン   倉貫義⼈人  @kuranuki  
  2. 2. 本日のアジェンダ (5分)   (6分)   (6分)   (18分)   (5分)  
  3. 3. ど う す れ ば ⼩小 さ な チ ー ム で も                           ⼤大 き な 成 果 を 出 せ る の か  はじめに  
  4. 4. 小さなチームでも大きな成果を出すために
  5. 5. 今日お話すること
  6. 6. 今日のまとめ
  7. 7. ど う す れ ば ⼩小 さ な チ ー ム で も                           ⼤大 き な 成 果 を 出 せ る の か  ⼩小さなチームの採る戦略略  
  8. 8. よくある開発の落とし穴
  9. 9. ソフトウェア開発のパラメータ(変数)
  10. 10. 小さなチームでも大きな成果を出すために
  11. 11. ど う す れ ば ⼩小 さ な チ ー ム で も                           ⼤大 き な 成 果 を 出 せ る の か  ソフトウェアの価値とは?  
  12. 12. ソフトウェアの価値が産まれるのはいつからか? 売上   損益分岐点   変動費   固定費   t 売上開始点  
  13. 13. 「品質」とはなにか?   「誰が顧客なのかがわからなければ、何が品質なのかも わからない。」(リーンスタートアップより)    そのテストの⽬目的はなにか?何を売っているのか?   プログラム の正しさ   仕様の正しさ   ビジネスの正しさ  
  14. 14. 「Point of Sales」から「Point of Use」へ Point of Sales Point of Use 買った時点が最⾼高で、そこ 常に使っている時点で最⾼高、 から陳腐化が始まるもの   最新のものを利利⽤用できる  q q 利利⽤用中が最⾼高品質   買った時点が最⾼高品質   (常にアップグレード)   利利⽤用   すぐに利利⽤用開始   償却   構築   t t 製造業   サービス業  
  15. 15. 「Point of Use」で大事なこと 継続性  …  ビジネスを                 継続していけること   保守性  …  ビジネスの                 変化に追随すること  
  16. 16. ど う す れ ば ⼩小 さ な チ ー ム で も                           ⼤大 き な 成 果 を 出 せ る の か  単位を⼩小さくすること  
  17. 17. 大企業的な発想でのやり方 市場   市場分析 リリース ビジネス   依頼/発注 要件 納品 開発   設計 実装 テスト 半年〜
  18. 18. 小さなチームでの役割分担 事業に責任をもつ ビジネス   オーナー   プロダクト   プログラマ   オーナー  ソフトウェアがどう動けば ソフトウェアが動く状態正しいかに責任をもつ にすることに責任をもつ
  19. 19. 小さなチームでのプロセス プロダクトオーナー エンドユーザ ①ユーザストー ⑦いつでも確認 ⑨利用 リーを登録 ③普段の対話 ⑤週1の会議 ⑧リリース ④ソース共有 ②見積もり後 ⑥継続デプロイ に作業開始 プログラマ記載の社名・製品名・ロゴは各社の商標または登録商標です。
  20. 20. 小さなチームのエンジニアリング 継続的リリース   コードの共同所有   リファクタリング   ペアオペ   テストコード   コードレビュー  フレームワークの統⼀一   プラットフォームの統⼀一  
  21. 21. ど う す れ ば ⼩小 さ な チ ー ム で も                           ⼤大 き な 成 果 を 出 せ る の か  優先順位を決めること  
  22. 22. 無駄のない開発
  23. 23. 無駄のない開発
  24. 24. 無駄のない開発
  25. 25. プロダクトオーナー   チケット(ユーザストーリー)の追加と   出来上がったチケットのアクセプトとリジェクト   すでに実装が済ん 仕様の決まってい だチケット るチケット 今のイテレーショ するかどうか決め ンでするチケット ていないチケットシンプルに優先順で並ぶだけ   チケットを上から順に   プログラマ   実装していくだけ  
  26. 26. ど う す れ ば ⼩小 さ な チ ー ム で も                           ⼤大 き な 成 果 を 出 せ る の か  なるべく作らないこと  
  27. 27. パラダイムシフト   バグをなるべく出さないようにする        →  バグが出てもすぐに直せるようにする    サーバは落落ちないようにする        →  落落ちてもすぐに復復旧できるようにする    データ変更更ないように設計する        →  データ変更更しても対応できるようにする    ビジネスのプランを重視する        →  ユーザのフィードバックで製品を変える  
  28. 28. 本当の生産性を高めるには?
  29. 29. 「構築」→「計測」→「学習」 (リーンスタートアップより) ア イ デ ア   学 習   構 築   デ ー タ   コ ー ド   計 測  
  30. 30. 無駄のない開発
  31. 31. ど う す れ ば ⼩小 さ な チ ー ム で も                           ⼤大 き な 成 果 を 出 せ る の か  今⽇日のまとめ  
  32. 32. 今日のまとめ
  33. 33. そのために、これから考えるべきこと 「仕組み」と「気持ち」の両⽅方が⼤大事  

×