schoo Web講義「どうすれば小さなチームでも大きな成果を出せるのか」 株式会社ソニックガーデン　代表取締役 倉貫 義人

memo.md

#どうすれば小さなチームでも大きな成果を出せるのか 少人数のチーム、低コストで開発を続けていくためのプロセスを学ぶ

株式会社ソニックガーデン　代表取締役 倉貫 義人

http://schoo.jp/class/91

対象：チームでソフトウェア開発をしているエンジニアやディレクター

###大企業との違い

• 無駄があるかないか
• 小さなチームなら無駄をなくせる
• 機敏
• 大企業とおなじルールで戦わない

###小さなチームのとる戦略 ####落とし穴

• いつまでも完成しない
• 完成しても使わない
• 直したくても改修まで手が回らない

作り方がマズイのが原因

####3つの要素

• スコープ：何を作るか
• 期限：いつまでに
• リソース(コスト)：人

####小さなチームでは

• 期限は自然に決まる
• リソースは限られてしまう

####どうするか コストを固定してスコープを調整する

###ソフトウェアの価値

• 完成時点では価値はゼロ
• 売上を上げてから価値が生まれる
• 良い物をつくれば人が集まる。とは限らない
• ユーザーのフィードバック

###品質

• 顧客によって品質が決まる。

• 「誰が顧客なのかがわからなければ、何が品質なのかもわからない」(リーンスタートアップより)

• 品質はマーケットに出てからわかる。

• Point of Useにする。

• 常に使っている時点が最高品質。

####品質の指標

• 継続性

• 使い続けられること。

• 保守性

• 直しやすいこと。ソフトウェアはずっと動き続けるので。

##無駄のないチームを作るために ###単位を小さくする

• チームメンバーの役割をシンプルに。
• 多すぎると伝言ゲームが発生してしまう

###小さなチームのプロセス

• ユーザーストーリー：PIVOTAL TRACKER
• コミュニケーション：youRoom
• 会議：skype
• コード共有・レビュー：github
• 継続デプロイ：heroku
• リリース：AWS

1週間周期での継続リリース

###優先順位

• 優先順位の高いもの → もっとも売りたいもの

###パラダイムシフト

• バグを出さないようにする → 出てもすぐに直せるようにする
• サーバーは落ちないようにする → 落ちてもすぐに復旧できるようにする
• データの変更がないように設計する → データ変更しても対応できるようにする
• ビジネスのプランを重視する → ユーザーのフィードバックで製品を変える

柔軟・DRYにしておく

###なるべく作らない

• 何を作らないかを決める
• LP用意するだけでビジネスの検証ができるなら、わざわざ作る必要はない

##これから考えるべきこと

• 自己組織化
• ビジネスモデル
• カルチャー
• コードレビュー等の浸透
• 振り返り

report.md

#無駄をなくすために、まずできること ##単位を小さくする 「顧客に価値を届ける → フィードバック」のイテレーションを機能単位で回す。
※フィードバックに柔軟に対応できるコードを書く
統合テストが終わって初めて顧客にフィードバックを求めるのは博打のようなもの。

##優先順位 必ずシーケンシャルな優先順位を設定する。
「高」「中」「低」のようにカテゴリで分けてしまうと、結局「高」に偏ってしまう。

##なるべく作らない 自分は作る側の人間だが、「本当に作る必要があるか？」という視点で考えてみる。
結果、作らずに済むのであればコスト削減になるし、価値のあることに集中できる。