タイムバンクでみるプロジェクトの立ち上げとMVP

1. Confidential
1
タイムバンクでみるプロジェクトの立ち上げとMVP
2018.06.18
Tanaka.y.p

2. Confidential
2
自己紹介
• 金融系 -> 組み込み系 -> Web(Ad, SNS, Game)
-> BigData, ML -> Vendor -> FinTech
• フロントからインフラまでが得意、Hadoop/Spark
系, あとMLあたり。デザインは無理ぽ。
• Apache Spark周りでいくつか著書あります。お小
遣いください。
• Web記事もいくつかあります。お小遣い(ry

3. Confidential
3
時間取引所 Timebankとは？
時間取引所
専門家 ユーザ
芸能人
起業家
投資家
選手
アイドル
学者
社長 政治家
空き時間を
販売
時間を購入
空き「時間」を売買できる取引所
 タイムバンクは個人の空き時間を売買できる取引所です。
※今日のお話は個人の見解であり、
所属する組織の公式見解ではありません。

4. Confidential
4
System背景情報

5. Confidential
5
今日のアジェンダ
 プロジェクトの立ち上げとチームビルディングの話
 チームカラーの意識(スキルとバックエンドの話)
 目線合わせとエンジニアチームの責任
 重要視したこと、諦めたこと
 チームで成長のためにやってること、今のフェーズ
 タイムバンクで見るMVP
 MVPとリリースサイクル
 The Wizard of OZ
 具体例) イベントの施策と開発
 MVPに失敗したと思っていること
 まとめ

6. Confidential
6
プロジェクトの立ち上げとチームビルディングの話

7. Confidential
7
チームカラーの意識
 あなたは理想チームが作れる人脈と予算と期間を持っていますか？
 最初の立ち上げ開発
 サーバーサイド
 フロント
 iOS
 Android
Phper ぼく（Python/Scala)
入社4ヶ月目 入社0ヶ月目

8. Confidential
8
チームカラーの意識 2
 得意な言語/やりたい言語/やったことある言語がバラバラ
 レイヤの違いによるスキル差異(インフラ寄り、ミドル寄り、サー
バー寄り、フロント寄り)
 オンプレ / クラウド
 Ansible / Chef
 Jenkins / CircleCI
 SQL(MySQL / Postgre) / NoSQL (Mongo / Couch)
 MVC / UCDD / (Clean Architecture)
 jQuery / Vue.js / React + Redux
 背景職の違いによる「良いシステム開発」の違い
 Ad, Game, Webはスケーラビリティ・速度重視
 OSS系は構造や安定性を重視
 金融系はDocumentや安全性を重視

9. Confidential
9
チームカラーの意識 3 発生したこと
 第一次マサカリ大戦争の勃発
そのPull Reqest
ありえないんで
Closeしまし
た！！！

10. Confidential
10
目線合わせとエンジニアチームの責任
 私たちはプロフェッショナルか？
 基礎研究 / R&Dをやるために集まったのか？
 エンジニアリングとサービスのバランスについてどう思うか？
 対話 & 対話 & 対話 （我々のスタンスの話）
 対話 & 対話 & 対話（何にコミットすべきか）
 全てのメンバが100%の力を発揮すればバ
グは０になるのか？
 リリースサイクルは速くなるのか？
 サービスの継続性の担保は重要なのか？

11. Confidential
11
重要視したこと諦めたこと（合意の方向性)
 エンジニアがなすべきことはフェーズを分けて考える
 新しい体験を最速でユーザーに届ける為に必要な方法を議論する
 初期リリース ~
 リリースを最優先（出来上がったものを優先）
 Unitは諦める、結合・機能テスト側でカバー
 MVCを一旦意識するが、書き方や微妙な部分は個々
 インフラのスケーラビリティも部分的に諦める
 リリースはdailyで行う
 デプロイ周りは諦めない
 誰でもデプロイできる
 仕様書の体裁や粒度は諦める、無くてもOKとする
 ただしチケット化は諦めない。チケットが正
 Bizの口頭仕様もエンジニア側でフォローする。
 1日30分の対面のコミュニケーションは義務
 リモートは一旦NG
 決めたことは中途半端にやらない。やるならやりきる

12. Confidential
12
重要視したこと諦めたこと（合意の方向性)
 プロモーション / 広告流入時期 ~
 それでもリリースを最優先
 Unitは諦める、結合・機能テスト側でカバー
 基本的にUnitは書く、個々の粒度で。無くてもOK
 お金に絡む部分は書く。
 ただしSkipリリースをすることもある
 MVCを一旦意識する。
 個々Approveした上で、commentは残していく。
 リファクタは個々の時間の範疇で行う。
 インフラのスケーラビリティ
 Web/APIなどはスケール可能にする。
 アジャイル(スプリントMTG)を諦める
 認識合わせの為のチーム内勉強会を週１で取るようにする

13. Confidential
13
チームで成長のためにやっていること、今のフェーズ
 ~ 今
 まだリリースを最優先
 新規部分についてUnit, MVCを意識する
 明らかにおかしいものはどう直して欲しいかを記述
 マイクロサービス化進めて部分的な再構築を始める
 勉強会の中で質についての会を増やす
 週1日リモートワークの日を作る
 Wikiにdocument化を一部進める
 課題
 仕様のサイロ化進んで知らない機能が増えてる
 初期と違う仕様が多く、モンキーパッチが目立ってきた
 エンジニアの稼働が高い
 チケット着る側・仕様を詰める側がボトルネックになってきた

14. Confidential
14
タイムバンクで見るMVP

15. Confidential
15
MVPとリリースサイクル
 タイムバンクでのリリースサイクル
 本番リリース@サーバー 約１回 ~ 2回 / day
 アプリが絡む大型のリリース 約１回 ~ 2回 / week
 開発のラインは２本+αをベースに設計
 サーバー1名 / iOS 1名 / Android 1名で１機能 x 2
 +α(Hotfix, イベント, その他(オズの魔法使い役))
 大型のリリース
 金曜日申請(iOS), 月曜日リリースをベース
 水曜日 or 木曜日辺りに申請判断
 木曜日の段階でクラッシュする場合は遅延
 正常ケースが困難な場合も遅延

16. Confidential
16
The Wizard of Oz
 の前にMVP(検証可能な必要最低限のプロダクト)とは
 実際にユーザーにサービスを提供し、それがユーザーに利用さ
れるまではただの仮説で、提供者の都合の良い思い込みである。
 であるから、ユーザーに必要最低限の機能をまず提供し、その
フィードバックを得て仮説検証を行いサービスを適宜方向調整
することで、余計な開発コストの削減やプロダクトマーケト
フィットを目指す手法。Wizard of Oz（オズの魔法使い）もそ
の手法の一つ。タイムバンクでは一部意図してWizard of Ozと
スモークテストを行ってます。
 Wizard of Ozとは
 本来システム化されている(ように見える)フロントプロダクトを、
実際は生身の人間が手動で操作することで初期開発費用(期間)を
大幅に削減し、システム化のリスクを回避する手法。
要は、人が頑張ってる状態

17. Confidential
17
The Wizard of Oz 2
 そもそも少人数開発のリスクはどこにあるのか？
時間
コスト
リスク

18. Confidential
18
The Wizard of Oz 3
 MVPで何がうまいか？
時間
開発コスト
リスク

19. Confidential
19
具体例) イベントの施策と開発例 ※あくまで架空の例です
 要件：
 ユーザーの売り注文に対し、買い注文の絶対数が少なく（事実）ユーザーの買い
控えにつながっているのではないか？（仮説１）また、市場全体の価格が上昇す
ることで、セカンドバイの心理的障壁が薄れるのではないか？(仮説２)
 検証：
 買い注文に対してランキングを作成し、上位者にインセンティブを付与することによって、
ユーザーの買い注文が増え（検証１）、市場全体の価格が上昇し（検証２）、心理的な障壁
が薄れるか？（検証３）
 開発に必要なもの：
 ランキングを表示するページ
 ランキングに参加するページ
 ランキングを計算するbatch
 イベント期間を管理するテーブル
 ランキングを格納するテーブル
 ランキング参加者を格納するテーブル
 インセンティブを付与する機能
 イベントの作成・変更管理機能
 ランキング参加者の管理機能
 不正検知機能
だいたい二週間〜三週
間後に開催可能なイベ
ント

20. Confidential
20
具体例) イベントの施策と開発例2 ※あくまで架空の例です
 検証可能かどうか？：
 測定可能か？
 その検証項目は定量的か？
 定量的に判断するデータは取得しているか？
 比較対象のデータはあるか？
 短期か長期か？
 短期的に検証可能な項目か？
 検証：
 買い注文に対してランキングを作成し、上位者にインセンティブを付与することによって、ユーザーの買い
注文が増え（検証１）、市場全体の価格が上昇し（検証２）、心理的な障壁が薄れるか？（検証３）
 検証３は定性的であり、定性->定量化が必要
 心理的な障壁が定量的に表される数値ってなに？
 どのように計測するの？
 どのようにデータ取得するの？
 判断：
 検証可能なようにディスカッションし、定量化を行う
 聞かなかったことにする
 ディスカッションは最も工数が重たい作業
 特にデータ分析において新たな軸（心理的表現）を探るパターンは意味消失するか、
限定的な解釈が可能になる程度なので工数に対して効果が見込めないので避けるのも
あり！

21. Confidential
21
具体例) イベントの施策と開発例3 ※あくまで架空の例です
 ランキングを表示するページ
 ユーザーが見るページなので必要
 ランキングに参加するページ
 そもそも入り口の動線なので必須
 ランキングを計算するbatch
 ぼくが２じかんおきくらいにSQLたたく
 イベントを管理するテーブル
 直接Controllerにでもかいとけばおけ
 ランキングを格納するテーブル
 表示するデータなんで必要
 ランキング参加者を格納するテーブル
 流石に参加管理は必要
 インセンティブを付与する機能
 イベント終了後、まとめて付与
 イベントの作成・変更管理機能
 継続的にやるなら作る
 ランキング参加者の管理機能
 継続的にやるなら作る
 不正検知機能
 悩むけどMVPなら外してもOK
だいたい一週間弱で開
催が可能
開催中に並行で実装
可能
検証を待ってから実装
この部分とこの部分は手で頑張る！！！
(オズの魔法使いにぼくはなる！)

22. Confidential
22
失敗したと思っている例 ※あくまで架空の例です
 イベントを定常化後、インセンティブを変更して再度検証を繰り返したケース
 ランキングを表示するページ
 ユーザーが見るページなので必要、アレンジでいける
 ランキングに参加するページ
 そもそも入り口の動線なので必須、これもアレンジでいける
 ランキングを計算するbatch
 バッチもアレンジでいける！
 イベントを管理するテーブル
 すでに定常イベント済みなのでflg追加でウハウハ
 ランキングを格納するテーブル
 表示するデータなんで必要、すでにある
 ランキング参加者を格納するテーブル
 流石に参加管理は必要、これもある
 インセンティブを付与する機能
 インセンティブが変更になったので、大幅に回収必要!
 自動的に付与していたものを、イベント終了後、手動でまとめて付与する対応
 イベントの作成・変更管理機能
 すでにある
 ランキング参加者の管理機能
 これもある
 不正検知機能
 そうそうに対応したのである！

23. Confidential
23
失敗したと思っている例 ※あくまで架空の例です
 ユーザビリティを下げた結果
 ユーザーの期待値
 イベント終了直後にインセンティブが付与される
 とった対応
 3日後に手動でインセンティブ付与
 結果
不具合扱い＼(^o^)／
ユーザー体験を損ねるもの(期待値に満たないもの)
は「最小限の検証可能なプロダクト」の失敗例で
す。

24. Confidential
24
まとめ
 チーム立ち上げのフェーズ
 MVPはうまく使えば、プロダクトオーナー、開発者、そしてユー
ザーも幸せな手法