Agile Japan 2015

アジャイルなオフショア開発
2015年4月16日

ＧＭＯインターネット株式会社
次世代システム研究室
藤村 新 / 片山 貴博
1藤村 新
ふじむら あらた

アジャイルPM研究会所属

片山 貴博
かたやま たかひろ
GMOベトナムラボセンター
経営メンバーアジェンダ• オフショア開発の経緯• RFCモデルとは• RFCの理想• RFCの現実• まとめ3

オフショア開発の経緯

4

2013年3月11日 「GMOベトナムラボセンター」設立

http://cloud.watch.impress.co.jp/docs/release/20130326_593209.html

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

優秀なベトナム人が欲しい！

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

採用基準

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

採用基準

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

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

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

ちゃんとできてない…
12

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

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

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

体制図

GMOベトナムラボセンター
ベトナム(ハノイ)

リーダー

受入担当
仕様策定・発注・受入リソース・タスク管理

国内

問題
多発
18

主な問題点• 一度のやり取りで期待通りのアウトプットが出てこない• 見積もりの精度が低く、完了予定が見えない• 95%完了から先が長い• 品質が低い19発生した問題に対し試行錯誤を重ねて導き出した

コンセプト
20

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

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

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

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

一度のやり取りで期待通りのアウトプットが出てこない
1度のやり取りでの完成を諦めた初回ザックリ開発見積もりの精度が低く、完了予定が見えない見積もりの精度が低く、完了予定が見えない時間をかけて見積もりの精度を上げてもらう見積もりの精度が低く、完了予定が見えない時間をかけて見積もりの精度を上げてもらう見積もりの精度が低く、完了予定が見えない
全体見積もりは諦め、ザック
リ開発工数だけ見積もってもらい、全体見積もりは完了係数を使って算出※完了係数とは、(リードタイム/ザックリ開発工数)の平均で算出する係数。
ザックリ開発工数の見積もり日数に完了係数を掛けることで、予想完了日を算出できる。

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

再度詳細な指示書を書き、完成させてもらう

95%完了から先が長い

再度詳細な指示書を書き、完成させてもらう

95%完了から先が長い

オフショア側での完成は諦め、最後の5%は日本側で完成させる

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

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

品質が低いメンバーのスキル向上も品質も諦める品質が低いメンバーのスキル向上も品質も諦める品質が低い開発の初期段階からレビューを実施するなど、レビュー回数を増やす

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

RFCモデルとは

43

RoughFillClosingベースはリーン開発のカンバン

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

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

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

50

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

52

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

53ざっくり開発するフェーズ
7割程度の完成度を目指す

アウトプットの完成度を上げるフェーズ
9割以上の完成度を目指す

優先度順に並んだPBI※Readyな状態(仕様記載済み)

完成させるフェーズ

国内(受入)担当

完成したタスク完了係数 ＝
Lead Time / RR
オフショア担当

Lead Time
Lead Time ＝
R × 完了係数
PBIを分割したタスク
RoughのDoingにかかる日数(R)を見積もる

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

RFCの現実

https://www.flickr.com/photos/brian_tomlinson/14678017291/

56

• 多くの前提条件• 共通言語は日本語であること• 受入担当はコードを理解できるエンジニアであること• ソースコードのバージョン管理が適切に行われていること• チケットベースで成果物をレビュー、検収できること
57• 受入担当について• 仕様策定・落し込み、発注、受入、修正指摘と行う事が多く、開発メンバーが増えれば増える程負荷も増大• 受入担当が兼務の場合、そこがボトルネックになる58• 効果について• 開発メンバーが業務に精通してくる事で受入担当の負荷が軽減され、その結果として費用対効果が現れてくるが、短期プロジェクト
では難しい
59

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

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

まとめ

62

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

いいんです！

64http://www.slideshare.net/kiroh/reintro-scrum-kansumi2013a3/46ただし、検査と適応は必須

結論

どんな開発プロセスを採用する場合でも、ふりかえりを定期的に実施し、プロセスの検査と適応を継続的に行っていくことが重要次世代システム研究室ではエンジニアを募集しています！

http://recruit.gmo.jp/engineer/jisedai/ご清聴、ありがとうございました70