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

544 Views

December 28, 14

スライド概要

社内勉強会で発表した資料です。
前半はRFCモデル(アジャイルオフショア開発モデル)についての概要、詳細フロー、RFCモデルを支える技術について。
後半はGMOインターネットグループにおけるオフショア開発状況のヒアリング結果を元に、今後のオフショア開発の進め方の提案、それに伴う課題などについてまとめてみました。

profile-image

Agile Practitioner / CSP-SM, CSP-PO(Certified Scrum Professional) / Modern Offshore Development / Vietnam / Paris Hilton / RareJob / BOOKOFF / Classmethod, Inc.

シェア

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

アジャイルオフショア開発モデル 2014年12月25日 GMOインターネット株式会社 次世代システム研究室 藤村 新 1

2.

アジェンダ • RFCモデル(アジャイルオフショア開発モデル)について - 概要 - 詳細 - RFCモデルを支える技術 • GMOインターネットグループにおけるオフショア開発状況 - ヒアリング結果 - 提案 - 課題 - まとめ 2

3.

藤村 新 Arata Fujimura PMI日本支部 アジャイルPM研究会所属

4.

やりたいこと 正しいものを 正しくつくり 正しく続ける! 4

5.

マスター・センセイからの教え • 正しいものなんて存在しない • 正しいものを(いつまでも)チームで探し続ける - それがプロダクトディスカバリー - プロダクトオーナーのせいにしない 5

6.

マスター・センセイからの教え • プロダクトオーナー - ROIの最大化を目指す • スクラムマスター - 学びの最大化を目指す • 開発チーム - 多様性が重要 - ベクトルの向きが合っている必要はない 6

7.

前回の発表 7

8.

スライドをアップロード 8

9.

フィードバック 9

10.

楽天 Tech Talk 10

11.

フィードバック • Done is better than perfectであって、Roughで さくっとざっくりしたものを作ってもらうコンセプト は超イイとおもう • こういう風に成長途上なモデルとそれを考えた人 の話聞けたのはなんか凄い楽しかった 11

12.

オフショア大學 12

13.

フィードバック • 独自の取り組みをされており、KPI測定して改善 されているところが印象的でした。 • 状況に合わせて改善を続けること、その仕組が 重要であると感じました。 • RFCモデルは国内の請負にも適しているのでは ないかと感じました。 13

14.

RFCモデルについて 14

15.

おさらい

16.

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

17.

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

18.

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

19.

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

20.

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

21.

Rough Fill Closing

23.

RFCモデル詳細 23

24.

ユースケース図

25.

前フェーズ

26.

Rough

27.

Rough

28.

Rough

29.

Fill

30.

Fill

31.

Closing

32.

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

33.

Trello

34.

GitLab

35.

Jenkins

36.

RFCツール

37.

RFC for Trello

38.

FAQ • Q:やり取りで使っている言語は? - A:日本語。 • Q:Roughの見積もり精度は? - A:慣れたタスクの精度は高いが、新規の場合 は精度が低くなる。 • Q:完了係数から算出する見積もり精度は? - A:まだ計画の指標としては使えていない。 38

39.

FAQ • Q:費用対効果は? - A:コスト(1/3), 期間(2倍)を目指している。 • Q:手戻りは発生する? - A:Fill(Review)→Fill(Doing)などは発生する。 • Q:スケールするの? - A:受入担当もオフショアに移し、RFCチームを 増やすことによってスケールすると考えている。 39

40.

デモ 40

41.

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

42.

オフショア開発状況ヒアリング • 6社8プロジェクトについてヒアリング実施 - GMO RUNSYSTEM - GMOゲームセンター(3プロジェクト) - GMOゲームポット(1プロジェクト) - GMOシステムコンサルティング(2プロジェクト) - GMOメディア(ラボプロジェクト) - GMOリサーチ(育成プロジェクト) 42

43.

オフショア開発状況ヒアリング • ヒアリング内容 - 契約形態 - ブリッジSE利用有無/利用言語 - チーム構成/人員配置 - フェーズ/納品物/利用ツール - K(P)T 43

44.

契約形態 受託契約 38% ラボ契約 62% ラボ契約 受託契約 44

45.

ブリッジSE有無/利用言語 13% 25% 62% ブリッジSE有(国 内)/日本語 ブリッジSE無/英 語 ブリッジSE有(海 外)/日本語 45

46.

フェーズ その他 13% 運用 25% 新規&運用 37% 新規&運用 新規 運用 その他 新規 25% 46

47.

納品物 グラフィック 22% ソースコード 45% ソースコード apk/ipa グラフィック apk/ipa 33% 47

48.

利用ツール backlog Github Trello Skype Excel Redmine Skype Redmine Excel Trello Github backlog 48

49.

Keep(発注側) • 人的リソースの柔軟性 - コスト削減 • 信頼関係が築けてきた - 頻繁なMTG 、出張時の交流 - チームとして成熟 • 成果物を継続的に出し続けられている - ざっくり仕様でも作ってくれる 49

50.

Try(発注側) • 次の案件も同じチームでやりたい - ラボ契約 - 関係性の維持 - 長期的なスケジューリング • 技術向上施策 - オフショア側に技術レベルの高いチームを作る • 企画・設計段階からオフショア側も参加 50

51.

Try(オフショア側) • 国際標準を採用したい - フレームワーク、ゲームエンジン - ツール、フォーマット • ビジョン、ゴールを共有してほしい • 企画・設計段階から参加したい • ラボ契約でチームを継続したい - チーム解散時に離職する傾向がある 51

52.

改善施策例 • 一度デスマーチを経験 • 別のプロジェクトを実施することになった • 発注側、オフショア側それぞれでふりかえり実施 • オフショア側でMTG実施 - オフショア側での成功事例を教えてほしい - 実際の現場の作業を見学させてほしい - 両社ふりかえりの共有 52

53.

改善施策例 • 今後の取り組みとして決めたこと - プロジェクトの初期フェーズで、オフショア側 チームリーダーと通訳が来日し、発注側と机を 並べて一緒に設計を行なう - 実装フェーズには、発注側のエンジニアがベト ナムに行って一緒に開発を行なう 53

54.

所感 • うまく回ってるプロジェクトもあれば、うまく回って ないプロジェクトもある • 各社の足並みがバラバラ - GMOインターネットグループ内のオフショア開 発なのに、情報共有がされていない - 契約も、ツールも、プロセスも、フォーマットも、 全部バラバラ 54

55.

モッタイナイ

56.

禁断の呪文 シナジー!

57.

情報共有 • 各社各プロジェクト間で情報共有 - ツール、プロセス、フォーマットの共有 - ふりかえり(KPT)の結果共有 57

58.

契約 • GMOインターネットグループとしてのラボ契約 - 継続した信頼関係 - ノウハウの共有 - プロセス、ツール、フォーマットの標準化 - 人材育成の効率化 - オフショアエンジニアの離職防止 58

59.

プロセス(RFC?) 59

60.

ツール 60

61.

フォーマット(UML?) http://thinkit.co.jp/article/40/1/ 61

62.

人材育成 62

65.

初期からの協働 http://www.slideshare.net/papanda/ss-31975018 65

66.

特に重要 http://www.slideshare.net/papanda/ss-31975018 66

67.

課題 • 部分最適化に成功しているプロジェクトに対して、 全体最適化のメリットを提供できるか - 独自の試みでチームビルディングを進めている - 全体最適化を考える余裕は無い? • 各社、各プロジェクトの目的、ゴールは異なる - 長期的視点(育成)、短期的視点(スポット) 67

68.

現状 68

70.

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

72.

GMO RUNSYSTEM社内で 情報共有してもらえても 発注側がバラバラだと意味が無い 72

74.

誰が音頭を取る? 74

75.

ラボ契約

76.

まとめ • 効率の良い方法をノウハウ化、ノウハウ集を共有 しよう - まずは両社とも情報共有からはじめてみる • 次世代システム研究室+GMOベトナムラボセン ターで担える役割を模索したい • オフショア開発でも、結局は人と人とのつながり が一番重要 76

77.

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

78.

おわり 78