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

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

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

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

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

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

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

前回の発表 7

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

フィードバック 9

楽天 Tech Talk 10

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

オフショア大學 12

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

RFCモデルについて 14

おさらい

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

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

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

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

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

Rough Fill Closing

RFCモデル詳細 23

ユースケース図

前フェーズ

Rough

Rough

Rough

Fill

Fill

Closing

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

Trello

GitLab

Jenkins

RFCツール

RFC for Trello

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

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

デモ 40

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

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

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

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

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

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

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

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

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

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

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

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

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

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

モッタイナイ

禁断の呪文 シナジー！

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

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

プロセス(RFC?) 59

ツール 60

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

人材育成 62

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

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

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

現状 68

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

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

誰が音頭を取る？ 74

ラボ契約

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

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

おわり 78