1

2014年12月25日

ＧＭＯインターネット株式会社

次世代システム研究室

藤村 新

アジャイルオフショア開発モデル

2

• RFCモデル(アジャイルオフショア開発モデル)について

- 概要

- 詳細

- RFCモデルを支える技術

• GMOインターネットグループにおけるオフショア開発状況

- ヒアリング結果

- 提案

- 課題

- まとめ

アジェンダ

藤村 新 Arata Fujimura

PMI日本支部 アジャイルPM研究会所属

4

正しいものを

正しくつくり

正しく続ける！

やりたいこと

5

マスター・センセイからの教え • 正しいものなんて存在しない

• 正しいものを(いつまでも)チームで探し続ける

- それがプロダクトディスカバリー

- プロダクトオーナーのせいにしない

6

マスター・センセイからの教え • プロダクトオーナー

- ROIの最大化を目指す

• スクラムマスター

- 学びの最大化を目指す

• 開発チーム

- 多様性が重要

- ベクトルの向きが合っている必要はない

7

前回の発表

8

スライドをアップロード

9

フィードバック

10

楽天 Tech Talk

11

フィードバック • Done is better than perfectであって、Roughで

さくっとざっくりしたものを作ってもらうコンセプト

は超イイとおもう

• こういう風に成長途上なモデルとそれを考えた人

の話聞けたのはなんか凄い楽しかった

12

オフショア大學

13

フィードバック • 独自の取り組みをされており、KPI測定して改善

されているところが印象的でした。

• 状況に合わせて改善を続けること、その仕組が

重要であると感じました。

• RFCモデルは国内の請負にも適しているのでは

ないかと感じました。

14

RFCモデルについて

おさらい

頑張っても 効果が薄い事は 諦める

一度のやり取りで期待通りのアウトプットが出てこない 1度のやり取りでの完成を諦めた初回ザックリ開発

見積もりの精度が低く、完了予定が見えない ザックリ開発工数だけ見積もってもらい、実見積もりは完了係数を使って算出

※完了係数とは、 (サイクルタイム / Roughフェーズの見積もり日数)の平均 で求める係数。 Roughフェーズの見積もり日数に完了係数を掛けることで、予想完了日が算出できる。

95%完了から先が長い 最後の5%は日本側で完成させる

Rough Fill Closing

23

RFCモデル詳細

ユースケース図

前フェーズ

Rough

Rough

Rough

Fill

Fill

Closing

32

RFCモデルを支える技術ツール

Trello

GitLab

Jenkins

RFCツール

RFC for Trello

38

FAQ • Q：やり取りで使っている言語は？

- A：日本語。

• Q：Roughの見積もり精度は？

- A：慣れたタスクの精度は高いが、新規の場合

は精度が低くなる。

• Q：完了係数から算出する見積もり精度は？

- A：まだ計画の指標としては使えていない。

39

FAQ • Q：費用対効果は？

- A：コスト(1/3), 期間(2倍)を目指している。

• Q：手戻りは発生する？

- A：Fill(Review)→Fill(Doing)などは発生する。

• Q：スケールするの？

- A：受入担当もオフショアに移し、RFCチームを

増やすことによってスケールすると考えている。

40

デモ

41

GMOインターネットグループにおける オフショア開発状況

42

オフショア開発状況ヒアリング • 6社8プロジェクトについてヒアリング実施

- GMO RUNSYSTEM

- GMOゲームセンター(3プロジェクト)

- GMOゲームポット(1プロジェクト)

- GMOシステムコンサルティング(2プロジェクト)

- GMOメディア(ラボプロジェクト)

- GMOリサーチ(育成プロジェクト)

43

オフショア開発状況ヒアリング • ヒアリング内容

- 契約形態

- ブリッジSE利用有無／利用言語

- チーム構成／人員配置

- フェーズ／納品物／利用ツール

- K(P)T

44

契約形態

ラボ契約

62%

受託契約

38% ラボ契約

受託契約

45

ブリッジSE有無／利用言語

62%

25%

13% ブリッジSE有(国

内)/日本語

ブリッジSE無/英

語

ブリッジSE有(海

外)/日本語

46

フェーズ

新規＆運用

37%

新規

25%

運用

25%

その他

13% 新規＆運用

新規

運用

その他

47

納品物

ソースコード

45%

apk/ipa 33%

グラフィック

22%

ソースコード

apk/ipa

グラフィック

48

利用ツール

Skype

Redmine

Excel

Trello

Github backlog

Skype

Redmine

Excel

Trello

Github

backlog

49

Keep(発注側) • 人的リソースの柔軟性

- コスト削減

• 信頼関係が築けてきた

- 頻繁なMTG 、出張時の交流

- チームとして成熟

• 成果物を継続的に出し続けられている

- ざっくり仕様でも作ってくれる

50

Try(発注側) • 次の案件も同じチームでやりたい

- ラボ契約

- 関係性の維持

- 長期的なスケジューリング

• 技術向上施策

- オフショア側に技術レベルの高いチームを作る

• 企画・設計段階からオフショア側も参加

51

Try(オフショア側) • 国際標準を採用したい

- フレームワーク、ゲームエンジン

- ツール、フォーマット

• ビジョン、ゴールを共有してほしい

• 企画・設計段階から参加したい

• ラボ契約でチームを継続したい

- チーム解散時に離職する傾向がある

52

改善施策例 • 一度デスマーチを経験

• 別のプロジェクトを実施することになった

• 発注側、オフショア側それぞれでふりかえり実施

• オフショア側でMTG実施

- オフショア側での成功事例を教えてほしい

- 実際の現場の作業を見学させてほしい

- 両社ふりかえりの共有

53

改善施策例 • 今後の取り組みとして決めたこと

- プロジェクトの初期フェーズで、オフショア側

チームリーダーと通訳が来日し、発注側と机を

並べて一緒に設計を行なう

- 実装フェーズには、発注側のエンジニアがベト

ナムに行って一緒に開発を行なう

54

所感 • うまく回ってるプロジェクトもあれば、うまく回って

ないプロジェクトもある

• 各社の足並みがバラバラ

- GMOインターネットグループ内のオフショア開

発なのに、情報共有がされていない

- 契約も、ツールも、プロセスも、フォーマットも、

全部バラバラ

モッタイナイ

禁断の呪文

シナジー！

57

情報共有 • 各社各プロジェクト間で情報共有

- ツール、プロセス、フォーマットの共有

- ふりかえり(KPT)の結果共有

58

契約 • GMOインターネットグループとしてのラボ契約

- 継続した信頼関係

- ノウハウの共有

- プロセス、ツール、フォーマットの標準化

- 人材育成の効率化

- オフショアエンジニアの離職防止

59

プロセス(RFC?)

60

ツール

61

フォーマット(UML?)

http://thinkit.co.jp/article/40/1/

62

人材育成

65

初期からの協働

http://www.slideshare.net/papanda/ss-31975018

66

特に重要

http://www.slideshare.net/papanda/ss-31975018

67

課題 • 部分最適化に成功しているプロジェクトに対して、

全体最適化のメリットを提供できるか

- 独自の試みでチームビルディングを進めている

- 全体最適化を考える余裕は無い？

• 各社、各プロジェクトの目的、ゴールは異なる

- 長期的視点(育成)、短期的視点(スポット)

68

現状

70

GMO RUNSYSTEM社内で 情報共有してもらえないか

72

GMO RUNSYSTEM社内で 情報共有してもらえても

発注側がバラバラだと意味が無い

74

誰が音頭を取る？

ラボ契約

76

まとめ • 効率の良い方法をノウハウ化、ノウハウ集を共有

しよう

- まずは両社とも情報共有からはじめてみる

• 次世代システム研究室＋GMOベトナムラボセン

ターで担える役割を模索したい

• オフショア開発でも、結局は人と人とのつながり

が一番重要

http://agilemanifesto.org/iso/ja/manifesto.html

78

おわり