693 Views
December 28, 14
スライド概要
社内勉強会で発表した資料です。
前半はRFCモデル(アジャイルオフショア開発モデル)についての概要、詳細フロー、RFCモデルを支える技術について。
後半はGMOインターネットグループにおけるオフショア開発状況のヒアリング結果を元に、今後のオフショア開発の進め方の提案、それに伴う課題などについてまとめてみました。
Agile Practitioner / CSP-SM, CSP-PO(Certified Scrum Professional) / Modern Offshore Development / Vietnam / Paris Hilton / RareJob / BOOKOFF / TIER IV, Inc.
アジャイルオフショア開発モデル 2014年12月25日 GMOインターネット株式会社 次世代システム研究室 藤村 新 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