- 14:30 キーノートスピーチ(石橋)
- 14:50 pairs.goのアーキテクチャと運用を考慮したプロジェクト基盤の整備について(金子)
- 15:10 Go言語周辺ライブラリの活用(森川)
- 15:30 休憩
- 15:45 Go言語アプリケーションを実現したインフラ(松尾)
- 16:05 大規模プロジェクトマネジメントの勘所(石橋＆泉森)
- 16:25 休憩(会場配置変更)
- 16:50 分科会
- 18:30 懇親会
- 20:00 終了
- ユーザー数310万人
- 社員数95人
- 半数がエンジニア
- 2015年5月にIACに買収された
- アジア市場を制覇すること
- PHP(CodeIgniter) -> Go
- 売上数十億/年
- DBテーブル数158
- サービスのKPIとか数値はめっちゃ取ってる
- 設計をイチから
- DBの再設計
- スケールしない設計だった
- join前提
- シャーディングできない
- インフラの再設計
- MPA -> SPA
- Native appsのアップグレード
- 1年1ヶ月(はじめは6ヶ月、6月リリース予定だった)
- 30人
- 2億 (人件費、サーバ構築費等々含む)
2014年末
- 技術調査
- 基本設計
2015/1-2
- 基盤構築
- 開発環境構築
- 全体スケジューリング
2015/3-7
- ソフトウェア開発
- インフラ設計・構築
- (ここまでPHP版の開発も平行)
2015/8-10
- 品質
- データの整合性
- セキュリティ
- パフォーマンス
2015/11
- リハーサル＆リリース(台湾版)
2016/1-2
- リリース(日本語版)
...
- 人件費
- サーバコスト
- ソフトウェアテスト(外部会社)
- セキュリティテスト 2億 + 機会損失コスト
背景
- pairsは元々外注で開発されていて、技術負債の塊になっていた
- スケールしないDB設計
- クソコード
※ 元々外注でクソDB、クソコードになってしまったという点はOmiaiと同じ
- Safe Lang
- High Performance Lang
- Breakthrough Tech
https://speakerdeck.com/kaneshin/eureka-go-our-designing-of-a-microservices-architecture
- (ライブラリ紹介諸々)
http://www.slideshare.net/yokoninaritai/eureka-go-20151212
- iOS/Androidのフロント-フロント以外はすべて破壊して、作りなおした
-
技術負債の返済ができた
-
良いエンジニアを採用できた
-
この1年間で66人社員増(エンジニア38人)
-
6ヶ月計画(6月)
-
2015/04くらいにテストしてログインできないなどの欠陥だらけ
-
6月リリース予定 -> 8月リリース予定 -> 11月リリース
- 1年という長い期間なので、チームをしっかり組めないときつい
- スタープレイヤーのパワープレイに負荷が集中すると、そこがボトルネックになる
- 属人化問題を防ぐ
- チーム全体の状態がわかるものを作った
- ガントチャートでもなく、バックログでもなく...
- Google Spread Sheetで作った
- クリティカル・パスを見える化
- 旧DB -> 新DBへの移行については入念にテストして事故らなかった
- 既読が付く、付かないのような不具合はあった
- 最初は石橋さんの方でガチガチのWF
- WebやAPI、管理ツールの開発が始まった段階でカオスになり、5月に泉森さんに、それっぽくマネジメントを委譲
- 泉森さんが全体のスケジューリングをし直した
- WFをやめて、状況状況に合わせて進めた
- 2チームに分かれて、1チームはなんちゃってスクラムだった(もう続けてない)
- テストケース作成にディレクター陣だけを集めてなんちゃってスクラムを実施した
- どこのテストケースを作るかバックログをまとめた
- 結局はパワープレイでスクラムじゃなく、かんばんと朝会だけ
-
2015/06リリース予定で、6月まではガッツリとコードを書いてた(4人だけ)
-
検証に入ってリリースするぞ、という段階で、検証チームと第2開発チームを作った
-
最終的なリリース直前で、pairsチームの8割がGoに関わってた
-
残りはガーディアンチームとして、旧pairsを運用していた
-
ガーディアンチームはなんちゃってスクラムで進めてた
- 想定よりコンパイル速度が長かった(Revelのせい)
- Revelをやめる大きな理由
- Go言語はシンプルなので、新メンバーの立ち上がりが速い
- 品質保証
- データの整合性
- 負荷に耐えるパフォーマンス
- プロジェクト管理はしっかりやっとこう
- 最悪の事態をすべて洗い出しておく
- 開発に半年、検証に半年
- 開発と同等のコストが検証にかかると思っておくこと
- 「スクラム」としてはやらず、なんちゃってスクラム
- メンバーに「スクラム」とは言ってなかった
- リニューアルは計画と実際でどの程度ずれた？軌道修正は？
- 当初6ヶ月の6月リリース予定、4月時点の品質で無理と分かって、8月にズラしたがそれでもダメで、11月リリースに
- 旧 -> 新で機能の削除、追加はなかった
- レビュー＆マージルールはどうしてた？
- インターン生が多いので、その人たち(ジュニア)の分はレビューしてる
- MTGみたいなのはどうしてた？
- 少なめ
- スタープレイヤーには集中してもらうために、Syncでの質問も避け、スプレッドシートに記載して、夜に答えてもらってた
- リニューアルのための障壁になったのは何かある？
- Microservicesの結合テストが遅くて、ログインできない、いいねできないとか基本的な部分の不具合が多すぎた