A 2a：アジャイルなオフショア開発

1. 1 2015年4月16日ＧＭＯインターネット株式会社次世代システム研究室藤村新 / 片山貴博アジャイルなオフショア開発 Agile Japan 2015

2. 藤村新ふじむらあらたアジャイルPM研究会所属片山貴博かたやまたかひろ GMOベトナムラボセンター経営メンバー

3. 3 • オフショア開発の経緯 • RFCモデルとは • RFCの理想 • RFCの現実 • まとめアジェンダ

4. 4 オフショア開発の経緯

5. http://cloud.watch.impress.co.jp/docs/release/20130326_593209.html 2013年3月11日「GMOベトナムラボセンター」設立

6. 6 ミッション • GMOインターネットグループの技術力のさらなる向上 • ベトナムの優秀な人財（IT技術者）の確保と育成 • インターネットの最先端技術の検証や研究

7. 7 ミッション • GMOインターネットグループの技術力のさらなる向上 • ベトナムの優秀な人財（IT技術者）の確保と育成 • インターネットの最先端技術の検証や研究優秀なベトナム人が欲しい！

8. 8 採用基準 • 日本語能力試験でN3以上 • 来日可能 • 1年間国内研修を実施 • 人柄が良い • 技術力がある • 20代半ばくらいの若手

9. 9 採用基準 • 日本語能力試験でN3以上 • 来日可能 • 1年間国内研修を実施 • 人柄が良い • 技術力がある • 20代半ばくらいの若手日本語話せる良い人！

10. 11 国内研修の実情 • 基本は2名ずつ実施 • 現在3期目(2名受入中) • 帰国した4名中1名退職 • 日本語能力は向上 • (なんちゃって)OJT • (たまに)研修実施

11. 12 国内研修の実情 • 基本は2名ずつ実施 • 現在3期目(2名受入中) • 帰国した4名中1名退職 • 日本語能力は向上 • (なんちゃって)OJT • (たまに)研修実施ちゃんとできてない…

12. 14 ラボセンターといっても、実際はオフショア開発が主な事業内容。

13. 15 とりあえずやってみた (2013年～2014年)

14. 16 当時の状況 • 体制 • 受入担当：1名(日本人) • 開発チーム：5名(ベトナム人) • 内3名はハノイ勤務 • 内2名は東京勤務(研修中) • 開発対象 • 主に社内ツール(KPIツール)

15. 受入担当リーダー仕様策定・発注・受入リソース・タスク管理ベトナム(ハノイ) GMOベトナムラボセンター体制図国内

16. 18 問題多発

17. 19 主な問題点 • 一度のやり取りで期待通りのアウトプットが出てこない • 見積もりの精度が低く、完了予定が見えない • 95%完了から先が長い • 品質が低い

18. 20 発生した問題に対し試行錯誤を重ねて導き出したコンセプト

19. 頑張っても効果が薄い事を諦める

20. 一度のやり取りで期待通りのアウトプットが出てこない

21. 一度のやり取りで期待通りのアウトプットが出てこない時間をかけてもっと詳細な仕様書を準備する

22. 一度のやり取りで期待通りのアウトプットが出てこない時間をかけてもっと詳細な仕様書を準備する

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

24. 見積もりの精度が低く、完了予定が見えない

25. 見積もりの精度が低く、完了予定が見えない時間をかけて見積もりの精度を上げてもらう

26. 見積もりの精度が低く、完了予定が見えない時間をかけて見積もりの精度を上げてもらう

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

28. ※完了係数とは、 (リードタイム/ザックリ開発工数)の平均で算出する係数。ザックリ開発工数の見積もり日数に完了係数を掛けることで、予想完了日を算出できる。

29. 95%完了から先が長い

30. 95%完了から先が長い再度詳細な指示書を書き、完成させてもらう

31. 95%完了から先が長い再度詳細な指示書を書き、完成させてもらう

32. 95%完了から先が長いオフショア側での完成は諦め、最後の5%は日本側で完成させる

33. 品質が低い

34. 品質が低い自己学習や研修を実施することにより各メンバーのスキル向上を目指す

35. 品質が低い自己学習や研修を実施することにより各メンバーのスキル向上を目指す

36. 品質が低いメンバーのスキル向上も品質も諦める

37. 品質が低いメンバーのスキル向上も品質も諦める

38. 品質が低い開発の初期段階からレビューを実施するなど、レビュー回数を増やす

39. これら改善施策を盛り込んだ開発モデルを考えてみた。

40. 43 RFCモデルとは

41. Rough Fill Closing

42. ベースはリーン開発のカンバン

43. Doing DoingのステージをRFCに細分化

45. 48 • ザックリ開発するフェーズ • 7割程度の完成度を目指す • 着手する前にザックリ開発工数を見積もってもらう

47. 50 • Roughフェーズでのアウトプットの完成度を上げるフェーズ • 9割以上の完成度を目指す

49. 52 • 完成させるフェーズ • 日本側の受入担当者(エンジニア)が対応する

50. 53 RFCの理想 https://www.flickr.com/photos/emiliokuffer/8359208711/

51. 優先度順に並んだPBI ※Readyな状態(仕様記載済み) PBIを分割したタスク RoughのDoingにかかる日数(R)を見積もるざっくり開発するフェーズ 7割程度の完成度を目指すアウトプットの完成度を上げるフェーズ 9割以上の完成度を目指す完成させるフェーズ R Lead Time 完了係数＝ Lead Time / R Lead Time ＝ R × 完了係数完成したタスクオフショア担当国内 (受入)担当

52. • 検査と適応の仕掛け • アウトプット(ソースコード)の検査と適応を各フェーズのレビューで行なう • レビューを早めに(Roughから)多めに(最低2回)実施することで、アウトプットの透明性を維持する

53. 56 RFCの現実 https://www.flickr.com/photos/brian_tomlinson/14678017291/

54. 57 • 多くの前提条件 • 共通言語は日本語であること • 受入担当はコードを理解できるエンジニアであること • ソースコードのバージョン管理が適切に行われていること • チケットベースで成果物をレビュー、検収できること

55. 58 • 受入担当について • 仕様策定・落し込み、発注、受入、修正指摘と行う事が多く、開発メンバーが増えれば増える程負荷も増大 • 受入担当が兼務の場合、そこがボトルネックになる

56. 59 • 効果について • 開発メンバーが業務に精通してくる事で受入担当の負荷が軽減され、その結果として費用対効果が現れてくるが、短期プロジェクトでは難しい

57. 60 • 費用対効果について • 開発メンバーのコスト：1/3 • 開発期間：約2倍(感覚値) • 受入担当のキャパシティが3名まで、50%コミットだとトントン • キャパを増やすか、コミット率を下げるか、期間を短縮しないと費用対効果が出ない

58. 61 • 今後予定している改善 • 受入担当業務をオフショア側で行う • 受入担当者育成に注力 • 短期の来日研修も検討

59. 62 まとめ

60. 63 • 現場で発生した問題に対して試行錯誤した結果、RFC モデルは生まれた • プロセスとしてのRFCモデルは確立されつつある • しかし、既に現場との乖離も生まれ始めている…

61. 64 いいんです！

62. http://www.slideshare.net/kiroh/reintro-scrum-kansumi2013a3/46

63. ただし、検査と適応は必須

64. 結論どんな開発プロセスを採用する場合でも、ふりかえりを定期的に実施し、プロセスの検査と適応を継続的に行っていくことが重要

65. 次世代システム研究室ではエンジニアを募集しています！ http://recruit.gmo.jp/engineer/jisedai/

66. 70 ご清聴、ありがとうございました

A 2a：アジャイルなオフショア開発

Arata Fujimura

Transcript