1. 成長期のスタートアップにおける
チーム開発の罠
株式会社マネーフォワード CTO 浅野千尋
1

2. ▶ マネーフォワードの会社紹介
2

3. ▶日本No.1の個人向け家計・資産管理サービス
▶日本最大規模のクラウド会計サービス
3
B2C and B2Bのそれぞれでトップレベルのシェアを獲得
FinTech業界を牽引するサービス

4. ターゲットユーザーとサービスマップ
4
Platform
資産管理
資産運用
収支改善
消込
経費 給与
会計
請求書
確定申告
自社
開発
ビッグデータ
分析
決済
システム
広告
システム
API
提供
個人
中小法人
個人事業主
Core
Technology
Platform
Application
セキュリティ
ビッグデータ解析
アカウントアグリゲーション

5. サービス・コンセプト
5
お金が見えると 未来が見える

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年後半

14. こまった・・・
14
チームに蔓延する「どうすんだよこれ・・・」感

15. ここで大きな意識の変化が起こる
問題意識を持ったエンジニアが、チームの為に動いた
– 個人の生産性から、チームの生産性を重視するように
• 自分のアウトプットが出ない理由を他の人に求めるのではなく、
チームとしての問題だと捉えて解決しようとする
– チームの皆を巻き込んで、より良い解決案を提示し、自分で
行動を起こしてみる
– 他のエンジニアも影響され、チームを良くする方向にモチベー
ションが高まった
15
これこそが俯瞰的な視点を持つということ

16. 実際にどう対応したか
▶ 暗黙知問題への対策
– 少人数で開発してきた箇所がブラックボックス化していた
– 日々のコードレビューに加えて、コードレビュー会を別
途実施し、技術的な背景やサービスの仕様を共有。
– Qiita::Teamの導入。WIPでも共有していく文化を作る。
– 少し込み入った仕様の場合とにかくQiitaにまとめ、情報を
オープンにしていく文化を創る。
16

17. 実際にどう対応したか
▶ 技術的負債の解消
– とりあえずスピード優先で突き進んできた結果として技術的負
債が蓄積し、バグが出やすいコードになっていた。
– こまめなリファクタリング
• 常にコーディングとリファクタリングはセットで行う
• Readable Codeを意識して保守性を高めたコーディングを行う
– 機能リリース後の振り返り会を行い、見積もりを精緻化し、
リファクタリングの時間を確保
– 今まで両デバイス兼任でやっていたAndroidとiOSのエンジニア
をそれぞれ専任で分ける事で、各OSにおける最適なコーディン
グを追求。
17

18. 実際にどう対応したか
▶ コミュニケーションの効率化
– 関係者が多くなりすぎて意思決定スピードが落ちていた
– チームを大きな目的に応じて２つに分ける
• チームに最適化した開発プロセスを別々に導入し、
意思決定を各チームへ委譲する
• 中長期プロダクト開発チーム（スクラム開発体制の導入）
• グロースハックチーム（とにかくPDCAを早く回す体制）
– 朝のスタンドアップミーティング
– ランチMTGで開発体制についての振り返りを実施
– KPIダッシュボードを作成し、エンジニアも含め全員で毎日の数
値を追って施策の効果をチームで共有する
18

19. まとめ
唯一の正解となるチーム開発体制なんて無い
– スタートアップでは会社の成長はあっという間
– 『誰かが変えてくれる』と思って何も行動しないでいると、そ
れだけで急激に生産性が落ちていく
– 今まで紹介した施策は全て2014年後半に、エンジニア主導で導
入されたものばかり
– そして共通していることは、全てチームメンバーを巻き込んで
進めているという点
19
エンジニア自身が俯瞰的な視点を持ち、
変え続けるプロセスそのものが最も大切である

20. ご清聴ありがとうございました
20
マネーフォワードでは一緒にサービス開発を行う
エンジニア、デザイナー絶賛募集中です！
recruit.moneyforward.com