第４回ペパボテックカンファレンスで話した内容になります

1. GMO Pepabo, Inc.
Hikaru Watanabe
2015/11/12 第４回ペパボテックカンファレンス
10年続くサービスで
ネクスト10年を戦うための
体制作り

2. 自己紹介
ライティ (@hikalin8686)
カラーミーショップのシステム責任者
2011年5月入社(5年目)

5. 目次
> 10年続くサービスの紹介
> ネクスト10年を戦う体制とは？
> まとめ

6. 10年続く
サービスの紹介

8. 独自ドメインでネットショップが作れる

9. 数値
> 2005年2月1日 サービスローンチ
> ショップ数 43,600件(2015年9月時点)
> ショップページの総PV 約1,200万/日

11. ロゴの変遷
> 10年で3回変わってます

12. ネクスト10年を
戦う体制とは？

13. 10年続くサービスの課題
> 肥大化する仕様
> 複雑化するコード
> 陳腐化するミドルウェア

14. それらが招く
開発スピードの減速

15. どうやって開発スピー
ドを維持するか？

16. システムの課題
新しいことをするときに阻害されない状況を作る
肥大化する仕様
・ドキュメントをちゃんと作る
・仕様をちゃんと調べて共有する
複雑化するコード
・コードレビューする
・コーディング規約
・システムのリプレース
陳腐化するミドルウェア
・継続的なバージョンアップ
・構成管理ツール
・クラウド化

17. システムの課題
新しいことをするときに阻害されない状況を作る
肥大化する仕様
・ドキュメントをちゃんと作る
・仕様をちゃんと調べて共有する
複雑化するコード
・コードレビューする
・コーディング規約
・システムのリプレース
陳腐化するミドルウェア
・継続的なバージョンアップ
・構成管理ツール
・クラウド化
お客様の困った!を
解決する運用のお話

18. システムの課題
新しいことをするときに阻害されない状況を作る
肥大化する仕様
・ドキュメントをちゃんと作る
・仕様をちゃんと調べて共有する
複雑化するコード
・コードレビューする
・コーディング規約
・システムのリプレース
陳腐化するミドルウェア
・継続的なバージョンアップ
・構成管理ツール
・クラウド化
ウェブサービスを開発す
るために詩をを書いた話
JWTを使った簡易SSO
で徐々にシステムをリ
ニューアルしている話

19. システムの課題
新しいことをするときに阻害されない状況を作る
肥大化する仕様
・ドキュメントをちゃんと作る
・仕様をちゃんと調べて共有する
複雑化するコード
・コードレビューする
・コーディング規約
・システムのリプレース
陳腐化するミドルウェア
・継続的なバージョンアップ
・構成管理ツール
・クラウド化
ネクストステージに繋が
るインフラ基盤づくり

20. 人の課題
個人 技術力を上げる
技術基盤チームによる
支援
チーム 増員
・単純に人を増やしても
スピードは上がらない
・大人数で開発するため
の体制を作る

21. 大人数で開発するた
めの体制作り

22. 大人数で開発するための体制作り
> 役割ごとにチームを作る
> カラーミーショップでのチーム分け
> 開発チームは５∼6人
> スクラムによる開発

23. 大人数で開発するための体制作り
> 役割ごとにチームを作る
> カラーミーショップでのチーム分け
> 開発チームは５∼6人
> スクラムによる開発

24. 役割ごとにチームを作る
10年続くサービスはやることがいっぱい
・不具合対応
・新規機能開発
・既存機能の改修
・売上アップ施策の対応
・社内業務のためのシステム改修
・ミドルウェアのバージョンアップ
・DC移設対応
・お問い合わせ対応
・社外連携の仕様変更
・ランディングページの作成
・有料テンプレートの作成
etc...

25. チームの役割/目的を
単一にして集中してもらう

26. 大人数で開発するための体制作り
> 役割ごとにチームを作る
> カラーミーショップでのチーム分け
> 開発チームは５∼6人
> スクラムによる開発

27. カラーミーショップでのチーム分け
新カゴチーム
新しいカートシステムを
作る
継続率チーム
ユーザーの満足度を上げ、
継続率を上げることを目
的とする
新規チーム
申込数を上げるためのUI
改善・施策を実施
焼山チーム
デザイナのみで構成
有料テンプレの作成やLP
の作成やらいろいろ
システム改善チーム
直接ユーザーに関係しな
いシステムの改善をする
チーム

28. 大人数で開発するための体制作り
> 役割ごとにチームを作る
> カラーミーショップでのチーム分け
> 開発チームは５∼6人
> スクラムによる開発

29. 開発チームは５∼6人
> スクラムが機能しやすい
> 意思決定が早い
> 情報共有しやすい

30. 大人数で開発するための体制作り
> 役割ごとにチームを作る
> カラーミーショップでのチーム分け
> 開発チームは５∼6人
> スクラムによる開発

31. スクラムによる開発
見える化
なんでこの作業
やっているの？
目的を説明しつつ、優先
順位をつける
納得感を持って作業が
できる
やらされている
感じがある
細かいタスクの割り当て
はチームに任せる
受託感の解消
どこまでやれば
終わりなのかが見えない
タスクはすべて付箋に書
き出す
残タスクが見える
何がどこまで進んでいる
かがわからない
期間内でやるもの・作業
中のもの・完了したもの
を付箋で管理
進 ・開発スピードがみ
える

32. スクラムによる開発
チーム感
なんでオレだけ…
タスクはチームで消化す
るもの
一人だけ負荷がかかるよ
うな事態を回避
ここの実装どうしよう∼
朝会などで課題感も共有
してみんなで解決
より良い解決方法を短時
間で出せる

33. まとめ

34. まとめ
> Webサービスで10年もやっていると
システム的・人的な課題がでる
> それを放置していると、開発スピード
が下がる
> 開発スピードを下げないために、課題
を解決するためにリソースを投資する

35. ご静聴ありがとう
ございました