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.

【schoo WEB-campus】どうすれば小さなチームでも大きな成果を出せるのか

2,547 views

Published on

schoo WEB-campusは「WEBに誕生した、学校の新しいカタチ」。
WEB生放送の授業を無料で配信しています。

▼こちらから授業に参加すると、先生への質問や、ユーザーとのチャット、資料の拡大表示等が可能です。

https://schoo.jp/class/91/room

Published in: Business
  • Be the first to comment

【schoo WEB-campus】どうすれば小さなチームでも大きな成果を出せるのか

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

×