アジャイルなオフショア開発(Rakuten techtalk)

アジャイルな オフショア開発 ～オフショア開発の動向、問題点とその改善施策～ 2014年11月12日 ＧＭＯインターネット株式会社 次世代システム研究室 藤村 新 1

目次 1) 自己紹介 2) 発表の目的 3) オフショア開発の歴史と背景 4) オフショア発注先の各国の特徴 5) オフショア開発のトレンド 6) オフショア開発成功事例 2

目次 7) 次世代システム研究室でのオフショア開発事例 8) 現状の問題点 9) 改善施策 10)実施結果 11)[デモ]ツールを使ったコミュニケーション 12)まとめ 3

目次 1) 自己紹介 2) 発表の目的 3) オフショア開発の歴史と背景 4) オフショア発注先の各国の特徴 5) オフショア開発のトレンド 6) オフショア開発成功事例 4

藤村 新 Arata Fujimura GMOインターネット 次世代システム研究室 Twitter: aratafuji

やりたいこと ＋ 正しく続ける 6

 正しいものを(プロダクトディスカバリーフェーズ)  デザイン思考  顧客開発モデル  リーンスタートアップ  ビジネスモデルキャンバス  ユーザーエクスペリエンスマップ  ユーザーストーリーマッピング  インセプションデッキ 7

 正しくつくり(開発フェーズ)  アジャイル開発  スクラム  XP  ドメイン駆動設計  正しく続ける(運用フェーズ)  リーン開発  継続的デリバリー  今時インフラ  インフラCI  Immutable Infrastructure 8

目次 1) 自己紹介 2) 発表の目的 3) オフショア開発の歴史と背景 4) オフショア発注先の各国の特徴 5) オフショア開発のトレンド 6) オフショア開発成功事例 9

 次世代システム研究室では GMOベトナムラボセンター (ベトナム/ハノイ) と密接に連携しながらGMOインター ネットグループのシステム開発等に取り組んでいるが、 必ずしもうまくいっているとは言えない状況 10

 次世代システム研究室では GMOベトナムラボセンター (ベトナム/ハノイ) と密接に連携しながらGMOインター ネットグループのシステム開発等に取り組んでいるが、 必ずしもうまくいっているとは言えない状況  GMOインターネットグループの各社でもオフショア開発 に取り組んでいるが、あまりうまくいってなさそう 11

 次世代システム研究室では GMOベトナムラボセンター (ベトナム/ハノイ) と密接に連携しながらGMOインター ネットグループのシステム開発等に取り組んでいるが、 必ずしもうまくいっているとは言えない状況  GMOインターネットグループの各社でもオフショア開発 に取り組んでいるが、あまりうまくいってなさそう  問題点を分析し、有効な改善施策を提案できればグルー プに多大な貢献ができるのではないか 12

つまり、目的は 13

つまり、目的は  オフショア開発の現状を調べ  問題点を洗い出し 14

つまり、目的は  オフショア開発の現状を調べ  問題点を洗い出し  改善施策を考え[仮説立案]  実践し  仮説検証して次の改善施策につなげることにより  新しいオフショア開発パターンを編み出し 15

つまり、目的は  オフショア開発の現状を調べ  問題点を洗い出し  改善施策を考え[仮説立案]  実践し  仮説検証して次の改善施策につなげることにより  新しいオフショア開発パターンを編み出し  GMOインターネットグループに貢献すること です。 16

目次 1) 自己紹介 2) 発表の目的 3) オフショア開発の歴史と背景 4) オフショア発注先の各国の特徴 5) オフショア開発のトレンド 6) オフショア開発成功事例 17

●参考資料 ミャンマーオフショア開発は「中国プラスワン」戦略の主役となるか http://www.atmarkit.co.jp/ait/articles/1401/17/news015.html

 1990年代  インドや韓国との間でソフトウェア分散開発の試み  以下の事情から2000年以前と以降でオフショア開発 の中身が全く異なる  インターネット環境が未整備  JavaやWeb関連技術など分散開発に適した技術が 発展途上 19

 2000～2003年：中国ブーム到来と一時的終焉  大企業の企業戦略を担う役員がオフショア開発に関心  地理的に近くて漢字が通じる中国が最有力候補地  大手SIが中国沿岸部の大都市に進出  中国現地法人を立ち上げたり、中国の既存パートナー と組んで人材の囲い込みを行なう  2003年に株価が記録的な安値を付けるなどの日本経 済落ち込みや、SARSの影響により短期間で収束 20

 2004～2008年：中国復活、ベトナムブーム到来  中国経済躍進、日本経済もゆるやかな回復基調  「猫も杓子もオフショア開発」といった雰囲気  中国での人件費高騰、反日感情  日本のオフショア開発ベンダーはベトナムに軸足を移 し始める  2005年当時、中国のSE：60万人に対してベトナムの SE：3万人と、規模は20分の1であり、言語の壁と国 内市場規模の違いから、中国を脅かす存在にはならず  一方中国沿岸部の大都市でも、オフショアビジネスで 甘い汁を吸える時代は終わった 21

 2008～2009年：世界同時不況、現場は成熟  2008年9月、リーマンショック  オフショア人材流動が止まり、現場は成熟  自転車操業的に仕事を回してきたオフショア開発ベン ダーが淘汰される 22

 2010～2012年：オフショア開発は第二ステージへ  景気は回復しないが、オフショア開発の重要性は高まる  中国は一歩先に景気回復し、激しい人材流動に戻る  「オフショア開発2.0 」  オフショア保守運用  3カ所以上での他拠点オフショア開発  オフショアアジャイル開発  オフショア保守運用以外は目立った進展無し 23

 2013年：第二次「中国プラスワン」、ミャンマーブーム  人件費の高騰、反日暴動の影響から脱中国の機運上昇  「中国の代替」ではなく、「中国の補完先」  多くの企業の関心を集め始めたのがミャンマー  ミャンマーブームと同時に、第二次ベトナムブーム  大企業：ミャンマー  中小企業：ベトナム 24

目次 1) 自己紹介 2) 発表の目的 3) オフショア開発の歴史と背景 4) オフショア発注先の各国の特徴 5) オフショア開発のトレンド 6) オフショア開発成功事例 25

 主なオフショア発注先  インド  中国  ベトナム  ミャンマー  大前提  低価格？＆日本語対応の中国  技術力＆国際対応のインド  既に棲み分けが進んでおり、これからも役割分担は起 きないと見られている 26

 インド  世界的に見れば最大のオフショア開発先  上流工程の知識、実績が豊富  英語での対応が可能  世界標準の開発手法(日本の開発手法と異なる)  人件費が高い  優秀なエンジニアの確保が難しい  人月単価(平均)：約30万円  コストダウンではなく技術力が目的でオフショア開発 を行なう企業が多くなってきている 27

 中国  ITインフラが整備されている(主に沿岸部)  日本との距離が近く、時差も少ない  エンジニアの数が多く優秀なエンジニアを確保しやすい  日本語能力が高い  人件費が高くなってきている(主に沿岸部)  離職率が高い  反日感情、政治リスクがある  人月単価(平均)：約35万円(沿岸部)  日本語能力は極めて高く、企画力や創造力に長けている 人材も豊富 28

 ベトナム  中国、インドと比較して人件費が安い  国の施策としてオフショア開発に力を入れている  親日である  優秀なエンジニアの確保が難しくなってきている  インド、中国に比べて開発者のスキルが若干低い  日本語、英語能力共、若干低い  人月単価(平均)：約25万円  親日でコストも安く、日本語もある程度通じ、小型案件 から対応可能というバランスの良さが人気の要因 29

 ミャンマー  人件費が安い  国民性が日本と似ていてチームワーク重視  ITインフラがまだ整備されていない  オフショア開発の歴史が浅い  人月単価(平均)：約18万円  オフショア開発最後のフロンティアと呼ばれ、エンジニ アの人件費が最も安い国。今後一番期待され、一番のび しろがある。 30

目次 1) 自己紹介 2) 発表の目的 3) オフショア開発の歴史と背景 4) オフショア発注先の各国の特徴 5) オフショア開発のトレンド 6) オフショア開発成功事例 31

 オフショアの受託スキルの向上とブリッジSEの減少  オフショア先のリーダー層に、入社以降オフショア開発 を経験し続けてきた人材も増えてきた  そういった優秀なリーダーがいるオフショア先への仕事 の依頼に関しては専用のブリッジSEが不要になる場面も  大量動員から少数精鋭  以前はオフショア側の動員力と低価格を中心とした大量 動員の面での活用が中心(プログラミング、テスト中心)  コミュニケーション環境の充実化、オフショア側の受託 能力の上昇、日本側のオフショア委託能力の上昇  ハイスキル・ローコストのハイパフォーマンス人材 32

 オフショアファースト  「プロマネ＋オフショア開発者」といった開発体制も珍 しくなくなってきた  ボリュームと難易度に合わせて日本人エンジニアを追加 で動員するような、オフショア前提、日本人はプラスで、 のようなオフショアファーストの開発体制  新天地の開発  主にミャンマーなど東南アジア方面の新たな国々  電気などインフラもままならず、通信網も脆弱 ●参考資料 2014年近年のオフショア事情 - プロマネブログ http://getlife.hateblo.jp/entry/2014/05/21/063000 33

目次 1) 自己紹介 2) 発表の目的 3) オフショア開発の歴史と背景 4) オフショア発注先の各国の特徴 5) オフショア開発のトレンド 6) オフショア開発成功事例 34

ウィさんレポート(ベトナムオフショア開発) 35

まとめると、  チーム体制  日本側:2名(PM:1, アーキテクト:1)  ベトナム側:9名(PL:1, QA:2, 開発:6)  開発期間  7ヶ月間(2006年6月～12月：ベトナムブーム期)  開発手法  ウォーターフォールモデル  オフショア側作業  詳細設計, プログラミング, 単体テスト, 結合テスト 36

 "プロマネ＋オフショア開発者"体制(オフショアファースト)  上流工程からオフショア側のPMを参加させ、他のメンバー が詳細設計から参加させる  オフショア側のチームメンバーの語学力を向上させる  ドキュメントとプロセスを標準化する  情報共有を徹底する  用語の定義を統一させ、共通認識にする  レビュー回数を増やす  QAチームで品質保証する  ベトナムのインフラがまだ弱いため、停電、洪水などの対 策を検討する 37

日本国内での外部委託のように「大体こんな感じで開 発してほしい」と口頭で説明し、そのまま進めること は危険極まりない。 要件定義はドキュメント化する必要がある。

ここまでで開始から15分経過なら良いペース！

目次 7) 次世代システム研究室でのオフショア開発事例 8) 現状の問題点 9) 改善施策 10)実施結果 11)[デモ]ツールを使ったコミュニケーション 12)まとめ 40

GMOベトナムラボセンターの実施状況  チーム体制  日本側:4名  ラボ専任[日本人](1名)  研修で来日中の[ベトナム人](3名)  ベトナム側:3名  開発案件  ゲーム開発  KPIツール開発 41

 現状の業務発注フロー  設計、仕様書作成をラボ専任担当(国内日本人)が行なう  Skypeと画面共有で仕様を伝達  要件定義書等は作っていない  RedmineのBacklogsプラグインのカンバンでステータ ス管理、Worktimeプラグインで工数管理  Skypeによる朝会、定例MTGで進捗確認  アウトプットの受け入れ確認をラボ専任担当が実施  一回で仕様を満たしていることは少ないため、複数 回の発注、確認のサイクルを繰り返して完了 42

 Keep  信頼関係  メンバー全員、1年間日本で働くようにしている  3ヶ月に1回専任担当＋αがベトナム出張  改善意欲  日本からの要望にできるだけ答えられるようにし たいという気持ち  実績  改善の余地は多いが、アウトプットは出せている 43

 Problem  コミュニケーション  テキストチャット、ボイスチャットだけではなか なかうまく伝わらない  質問、回答のタイミングがすれ違う  早く聞けばすぐに解決するような問題も多い  国内で伝えたり、出張時に行なった研修が定着しない  徹底されておらず、放置気味になっている  アジャイル開発研修など 44

書いてないこと、仕様が間違っていることを汲み取っ て対応してくれるとありがたいのになー。 危険極まりない。 間を埋める新しいオフショア開発手法が必要だ！

とあるゲーム開発案件の状況  チーム体制  日本側:4名  プロデューサー[日本人](2名)  ブリッジSE[ベトナム人](2名) ※掛け持ち  ベトナム側:5名※最大  開発[ベトナム人](5名)  開発案件  ゲーム開発  ネイティブアプリケーションのリニューアル 46

 Problem  ソースコードの理解不足  現バージョンのソースコードを渡すのみで各種機 能追加を依頼したので、局所的な理解のまま力技 で進めてもらってしまった  そのため、以下の問題が発生  他への影響が想定できないため、バグ多発、見 積もりの精度低下  全体最適化ができない 47

 Problem  プロジェクトマネージャーとプロデューサー(プロダ クトマネージャー)を同一人物が兼務  本来なら相反する役割  プロジェクトを守る存在がいない状況  オフショアチーム側(ブリッジ)で品質を担保できない  明らかなバグを含んだ状態で製品が上がってくる  ザックリとした仕様のため、1度のやり取りで完成す る事が少ない  計画は1度のやり取りで終わる前提のため、遅延が 多発しスケジュールが組めない 48

目次 7) 次世代システム研究室でのオフショア開発事例 8) 現状の問題点 9) 改善施策 10)実施結果 11)[デモ]ツールを使ったコミュニケーション 12)まとめ 49

問題点まとめ  1度のやり取りで完成しない  オフショアチームの見積もり精度が低い その結果  遅延を繰り返す  モチベーションが下がる  スケジュールが信頼できなくなる  相手を信頼できなくなる 50

問題点まとめ  オフショアチームで品質を担保できない その結果  日本側の担当者(プロデューサー)の負荷増大  明らかなバグから細かいバグまで全て確認し、指摘す る必要がある 51

問題点まとめ  あとちょっとの修正も、修正を依頼するためのコストが 結構かかる その結果  95%完了から完成までしばらく時間がかかる 52

目次 7) 次世代システム研究室でのオフショア開発事例 8) 現状の問題点 9) 改善施策 10)実施結果 11)[デモ]ツールを使ったコミュニケーション 12)まとめ 53

改善施策1

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

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

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

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

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

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

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

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

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

95%完了から先が長い

95%完了から先が長い 再度指示書を書いて、完 成してもらう

95%完了から先が長い 再度指示書を書いて、完 成してもらう

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

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

Rough Fill Closing

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

Rough Fill Closing

 ザックリ開発するフェーズ  7割程度の完成度を目指す  Backlogの時点で、ストーリーはレディ(着 手可能、仕様記載済み)な前提  ストーリーをタスク分割時に、オフショア 側開発者に工数を見積もってもらう  Roughのレビューフェーズで、専任担当 は完成までに必要な仕様を詳細に伝える 75

Rough Fill Closing

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

Rough Fill Closing

 完成させるフェーズ  日本側の発注者(エンジニア)が対応する 79

改善施策2

ちゃんと 教える

オフショア開発先の技術 力が向上しない

オフショア開発先の技術 力が向上しない 課題や時間を与え、主に 自習で学んでもらう

オフショア開発先の技術 力が向上しない 課題や時間を与え、主に 自習で学んでもらう

オフショア開発先の技術 力が向上しない 研修を実施して、必要な 技術をちゃんと教える

 ベトナム出張時研修(2014年1月)  カードモデリング実践  ふりかえり実践  インセプションデッキ実践  アジャイル開発の基礎講習  スクラムの基礎講習  スクラムの知識テスト  リーンカンバンの基礎講習  ストーリーマッピング実践  アジャイル開発プロセス体験  マシュマロチャレンジ 86

 ベトナム帰国前研修(2014年9月)  自己組織化ゲーム  スクラム座学  アジャイル開発プロセス体験  インセプションデッキ実践  ユーザーストーリーマッピング基礎  スクラムガイド自習  スクラムインフォグラフィックス  ユーザーストーリーマッピング応用 88

目次 7) 次世代システム研究室でのオフショア開発事例 8) 現状の問題点 9) 改善施策 10)実施結果 11)[デモ]ツールを使ったコミュニケーション 12)まとめ 90

 Roughフェーズの見積もり日数、実際にか かった日数、完成までに要した日数(サイク ルタイム)等のメトリクスを収集  サイクルタイム÷見積もり日数で完了係数を 算出し、計画づくりに使用する

RFCモデルをご利用頂いたお客様の声！ 発注者(PM)のSさんにお聞きします。 実際にRFCモデルを適用してみた率直な感想を聞かせ て頂けますか？ そうですね。 今までもカンバンを使ってステータスの確認を行 なっていたのですが、Doingのタスクが終わりそう なのか、マズそうなのかがパッと見で判断つきませ んでした。 その点RFCモデルのカンバンはステータスが細かく 設定されているため、見える化が促進したと感じて います。 導入直後のSprintでは、残念ながら一部のストー リーが未達に終わってしまったのですが、今後の改 善に期待しています！

 Keep  見える化が進んだ  各タスクのステータスがひと目で分かる  Trelloの効果も大きい  タスクがレビューステータスの際は、次のタスクを自 ら取って進めるなど、自己組織化が促進した  ラフ見積もりの精度は想定通り高く、完了形数のバラ 付きもそれほど無かった  チームが慣れれば、計画づくりに使えると感じて いる 94

 Problem  ラボ専任担当の負荷増大  Rough仕様作成  Roughレビュー  Fill仕様作成  Fillレビュー  Closingタスク  ラボ専任担当がボトルネックになるケースがあった  レビュー待ち、Closingタスクの増大  スケールしない構造  研修が単発的にしか行えていない 95

 Try  ラボ専任担当のWIPを制限する仕組みの検討  GMOインターネットグループ各社のオフショア開発 への適用  RFCモデル  中規模プロジェクトへの適用  アジャイル開発プラクティスの実施  ふりかえりは実施しているが活かせていない  継続的、定期的な研修の実施  ベトナムでは3ヶ月に1回程度  国内では毎月1回程度 96

目次 7) 次世代システム研究室でのオフショア開発事例 8) 現状の問題点 9) 改善施策 10)実施結果 11)[デモ]ツールを使ったコミュニケーション 12)まとめ 97

 利用ツール  Skype  Trello  Redmine  join.me  Sqwiggle 98

目次 7) 次世代システム研究室でのオフショア開発事例 8) 現状の問題点 9) 改善施策 10)実施結果 11)[デモ]ツールを使ったコミュニケーション 12)まとめ 99

 オフショア開発の歴史と背景、トレンドを 自分なりに整理することが出来た  個人的には、守破離の「破」の段階へ進み たいと考えていたため、ちょうど良いタイ ミングでの試みだった(RFCモデル)  パターンを収集し、オフショア開発のパ ターン・ランゲージを作っていきたい 100

その後 102

現在の状況

 Keep  受け入れテスト時の品質向上  2014年3Q：85%→2014年4Q：100%  レビューを複数回実施しているため  作業ペースは早くなってきている  体感ベース  自己組織化促進  Backlogに積んでおくと、タスク分解、ブランチ作 成、実装、ラボ内レビューまで自発的に実施  メンバー間のレビュー精度向上 104

 Problem  期限に対する意識が低い  Due date になってもサラッと遅延  遅れることが問題ではなく、共有されないことが 問題  新規作業は完了係数が大きくなる  完了係数をそもそも活用できていない  メトリクスの集計が手間 105

 Try  完了係数の活用  Trelloプラグイン(RFC for Trello)検討  完了係数自動集計  Due date × 完了係数から受け入れ予想表示  受け入れ予想がSprint期限を過ぎる場合は警告  RFCモデルのパターン・ランゲージ化  オフショアパターン  敷居が高い…  RFCモデル導入マニュアル整備  他部署、他社への適用 106

SlideShareにアップした結果、 107

フィードバックをもらい、 108

講師をさせて頂くことになったり、

発表の機会を頂けた。 川口さん Satoさん

アウトプット、めっちゃ重要！ 111

おわり 112