成長期のスタートアップにおけるチーム開発の罠
•Download as PPTX, PDF•
55 likes•9,021 views
http://connpass.com/event/11350/ 2015.2.19 ベストアプリ勉強会＠Sansan
Recommended
More Related Content
Viewers also liked
Viewers also liked (12)
Similar to 成長期のスタートアップにおけるチーム開発の罠
Similar to 成長期のスタートアップにおけるチーム開発の罠 (20)
成長期のスタートアップにおけるチーム開発の罠
- 6. 自己紹介 浅野千尋 Chihiro Asano – 役職：Co-Founder 取締役CTO – 担当：アカウントアグリゲーション本部 • 自動アグリ先金融機関の新規対応、保守、運用 • アライアンス関係 – マネーフォワードをやる前 • マーケット（株式市場）の人でした • データ分析＆投資ロジックの研究 • アルゴリズムベースのトレーディングシステムの研究開発 • それを元にした私募ファンドと公募ファンドを実際に運用 6
- 7. 僕がマーケットから教わった3つの指針 – リスクをコントロールする • リスクは取りすぎても取らなすぎてもいけない。 – 本質的な思考と行動をする • 何が本質なのか？という問いを常に自問する。 – 俯瞰的な視点を持つ • 局所最適解に陥ってはいけない。全体最適を常に考える。 7
- 8. 僕がマーケットから教わった3つの指針 – リスクをコントロールする • リスクは取りすぎても取らなすぎてもいけない。 – 本質的な思考と行動をする • 何が本質なのか？という問いを常に自問する。 – 俯瞰的な視点を持つ ★今回はこれの話 • 局所最適解に陥ってはいけない。全体最適を常に考える。 8
- 9. 今日のテーマ ▶ スタートアップによく発生するチーム開発の罠 – マネフォのPFMスマホチーム事例紹介 – 何が起こったか、どういう対策を行ったか – 今後どうしていけば良いのか 9
- 10. スマホアプリ開発体制【創業期】 2013年前半 – 当然1人体制 • コミュニケーションコストゼロ！ • 開発にのみ集中できる – デザイン？ワイヤー？そんなものは無い。 • 漢らしくエンジニアが直接作りこむスタイル – ベンチャーはスピードが命。とにかく作って世に出す。 – 2013年1月 iPhoneアプリ初版リリース – 2013年3月 Androidアプリ初版リリース 10 2013年前半 2013年後半 2014年前半 2014年後半
- 11. スマホアプリ開発体制【成長期】 2013年後半 – 苦節8ヶ月。ようやく2人体制に。 • まだまだコミュニケーションコストはかからず • むしろ相談出来る相手が出来て開発スピードは加速する – 見積もった工数が超過しそうになった場合 • 漢らしく気合と根性でなんとかする – バグを発見してもその場ですぐに修正 • コード全体を把握してるので影響範囲の予測が可能 11 2013年前半 2013年後半 2014年前半 2014年後半
- 12. スマホアプリ開発体制【拡大期】 2014年前半 – 4人体制に倍増 • デザイナーやマーケティングとの関わりも追加 • この頃から若干コミュニケーションコストが多くなってくる – しっかりとワイヤーを作り、UIデザインも作りこむように • 工数は増えたが、手戻りが少なくなったのでスピードはトントン – でも全体的になにやら雲行きが怪しくなってくる • 自分以外が書いたコードが多くなってくる • スピード優先でいいんだっけ？ • テストあまり書かれてないよね 12 2013年前半 2013年後半 2014年前半 2014年後半
- 13. スマホアプリ開発体制【試行錯誤期】 2014年後半 – 8人体制になって一気に３つの罠にハマる – バグ修正や新機能追加の際の影響範囲が予測できない 顕在化する暗黙知問題 – テストのカバレッジが低い – スピードを優先してきた結果、ReadableなCodeになってない 蓄積された技術的負債 – 見積もった工数が超過すると他のメンバーに影響が出るように – 関わる人数が多くなりすぎて意思決定すらままならない 増大するコミュニケーションコスト 13 2013年前半 2013年後半 2014年前半 2014年後半
- 15. ここで大きな意識の変化が起こる 問題意識を持ったエンジニアが、チームの為に動いた – 個人の生産性から、チームの生産性を重視するように • 自分のアウトプットが出ない理由を他の人に求めるのではなく、 チームとしての問題だと捉えて解決しようとする – チームの皆を巻き込んで、より良い解決案を提示し、自分で 行動を起こしてみる – 他のエンジニアも影響され、チームを良くする方向にモチベー ションが高まった 15 これこそが俯瞰的な視点を持つということ
- 16. 実際にどう対応したか ▶ 暗黙知問題への対策 – 少人数で開発してきた箇所がブラックボックス化していた – 日々のコードレビューに加えて、コードレビュー会を別 途実施し、技術的な背景やサービスの仕様を共有。 – Qiita::Teamの導入。WIPでも共有していく文化を作る。 – 少し込み入った仕様の場合とにかくQiitaにまとめ、情報を オープンにしていく文化を創る。 16
- 17. 実際にどう対応したか ▶ 技術的負債の解消 – とりあえずスピード優先で突き進んできた結果として技術的負 債が蓄積し、バグが出やすいコードになっていた。 – こまめなリファクタリング • 常にコーディングとリファクタリングはセットで行う • Readable Codeを意識して保守性を高めたコーディングを行う – 機能リリース後の振り返り会を行い、見積もりを精緻化し、 リファクタリングの時間を確保 – 今まで両デバイス兼任でやっていたAndroidとiOSのエンジニア をそれぞれ専任で分ける事で、各OSにおける最適なコーディン グを追求。 17
- 18. 実際にどう対応したか ▶ コミュニケーションの効率化 – 関係者が多くなりすぎて意思決定スピードが落ちていた – チームを大きな目的に応じて２つに分ける • チームに最適化した開発プロセスを別々に導入し、 意思決定を各チームへ委譲する • 中長期プロダクト開発チーム（スクラム開発体制の導入） • グロースハックチーム（とにかくPDCAを早く回す体制） – 朝のスタンドアップミーティング – ランチMTGで開発体制についての振り返りを実施 – KPIダッシュボードを作成し、エンジニアも含め全員で毎日の数 値を追って施策の効果をチームで共有する 18
- 19. まとめ 唯一の正解となるチーム開発体制なんて無い – スタートアップでは会社の成長はあっという間 – 『誰かが変えてくれる』と思って何も行動しないでいると、そ れだけで急激に生産性が落ちていく – 今まで紹介した施策は全て2014年後半に、エンジニア主導で導 入されたものばかり – そして共通していることは、全てチームメンバーを巻き込んで 進めているという点 19 エンジニア自身が俯瞰的な視点を持ち、 変え続けるプロセスそのものが最も大切である