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

1

2014年11月12日

ＧＭＯインターネット株式会社

次世代システム研究室

藤村新

アジャイルな

オフショア開発

～オフショア開発の動向、問題点とその改善施策～

2

目次

1) 自己紹介

2) 発表の目的

3) オフショア開発の歴史と背景

4) オフショア発注先の各国の特徴

5) オフショア開発のトレンド

6) オフショア開発成功事例

3

目次

7) 次世代システム研究室でのオフショア開発事例

8) 現状の問題点

9) 改善施策

10)実施結果

11)[デモ]ツールを使ったコミュニケーション

12)まとめ

4

目次

1) 自己紹介

2) 発表の目的





藤村新 Arata Fujimura

GMOインターネット次世代システム研究室

Twitter: aratafuji

6

＋正しく続ける

やりたいこと

7

正しいものを(プロダクトディスカバリーフェーズ)

デザイン思考

顧客開発モデル

リーンスタートアップ

ビジネスモデルキャンバス

ユーザーエクスペリエンスマップ

ユーザーストーリーマッピング

インセプションデッキ

8

正しくつくり(開発フェーズ)

アジャイル開発

スクラム

XP

ドメイン駆動設計

正しく続ける(運用フェーズ)

リーン開発

継続的デリバリー

今時インフラ

インフラCI

Immutable Infrastructure

9

目次

1) 自己紹介

2) 発表の目的





10

次世代システム研究室では GMOベトナムラボセンター

(ベトナム/ハノイ) と密接に連携しながらGMOインター

ネットグループのシステム開発等に取り組んでいるが、

必ずしもうまくいっているとは言えない状況

11





GMOインターネットグループの各社でもオフショア開発

に取り組んでいるが、あまりうまくいってなさそう

12





GMOインターネットグループの各社でもオフショア開発

に取り組んでいるが、あまりうまくいってなさそう

問題点を分析し、有効な改善施策を提案できればグルー

プに多大な貢献ができるのではないか

13

つまり、目的は

14


オフショア開発の現状を調べ

問題点を洗い出し

15




改善施策を考え[仮説立案]

実践し

仮説検証して次の改善施策につなげることにより

新しいオフショア開発パターンを編み出し

16




改善施策を考え[仮説立案]

実践し

仮説検証して次の改善施策につなげることにより

新しいオフショア開発パターンを編み出し

GMOインターネットグループに貢献すること

です。

17

目次

1) 自己紹介

2) 発表の目的





●参考資料

ミャンマーオフショア開発は「中国プラスワン」戦略の主役となるか

http://www.atmarkit.co.jp/ait/articles/1401/17/news015.html

19

1990年代

インドや韓国との間でソフトウェア分散開発の試み

以下の事情から2000年以前と以降でオフショア開発

の中身が全く異なる

インターネット環境が未整備

JavaやWeb関連技術など分散開発に適した技術が

発展途上

20

2000～2003年：中国ブーム到来と一時的終焉

大企業の企業戦略を担う役員がオフショア開発に関心

地理的に近くて漢字が通じる中国が最有力候補地

大手SIが中国沿岸部の大都市に進出

中国現地法人を立ち上げたり、中国の既存パートナー

と組んで人材の囲い込みを行なう

2003年に株価が記録的な安値を付けるなどの日本経

済落ち込みや、SARSの影響により短期間で収束

21

2004～2008年：中国復活、ベトナムブーム到来

中国経済躍進、日本経済もゆるやかな回復基調

「猫も杓子もオフショア開発」といった雰囲気

中国での人件費高騰、反日感情

日本のオフショア開発ベンダーはベトナムに軸足を移

し始める

2005年当時、中国のSE：60万人に対してベトナムの

SE：3万人と、規模は20分の1であり、言語の壁と国

内市場規模の違いから、中国を脅かす存在にはならず

一方中国沿岸部の大都市でも、オフショアビジネスで

甘い汁を吸える時代は終わった

22

2008～2009年：世界同時不況、現場は成熟

2008年9月、リーマンショック

オフショア人材流動が止まり、現場は成熟

自転車操業的に仕事を回してきたオフショア開発ベン

ダーが淘汰される

23

2010～2012年：オフショア開発は第二ステージへ

景気は回復しないが、オフショア開発の重要性は高まる

中国は一歩先に景気回復し、激しい人材流動に戻る

「オフショア開発2.0 」

オフショア保守運用

3カ所以上での他拠点オフショア開発

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

オフショア保守運用以外は目立った進展無し

24

2013年：第二次「中国プラスワン」、ミャンマーブーム

人件費の高騰、反日暴動の影響から脱中国の機運上昇

「中国の代替」ではなく、「中国の補完先」

多くの企業の関心を集め始めたのがミャンマー

ミャンマーブームと同時に、第二次ベトナムブーム

大企業：ミャンマー

中小企業：ベトナム

25

目次

1) 自己紹介

2) 発表の目的





26

主なオフショア発注先

インド

中国

ベトナム

ミャンマー

大前提

低価格？＆日本語対応の中国

技術力＆国際対応のインド

既に棲み分けが進んでおり、これからも役割分担は起

きないと見られている

27

インド

世界的に見れば最大のオフショア開発先

上流工程の知識、実績が豊富

英語での対応が可能

世界標準の開発手法(日本の開発手法と異なる)

人件費が高い

優秀なエンジニアの確保が難しい

人月単価(平均)：約30万円

コストダウンではなく技術力が目的でオフショア開発

を行なう企業が多くなってきている

28

中国

ITインフラが整備されている(主に沿岸部)

日本との距離が近く、時差も少ない

エンジニアの数が多く優秀なエンジニアを確保しやすい

日本語能力が高い

人件費が高くなってきている(主に沿岸部)

離職率が高い

反日感情、政治リスクがある

人月単価(平均)：約35万円(沿岸部)

日本語能力は極めて高く、企画力や創造力に長けている

人材も豊富

29

ベトナム

中国、インドと比較して人件費が安い

国の施策としてオフショア開発に力を入れている

親日である

優秀なエンジニアの確保が難しくなってきている

インド、中国に比べて開発者のスキルが若干低い

日本語、英語能力共、若干低い


親日でコストも安く、日本語もある程度通じ、小型案件

から対応可能というバランスの良さが人気の要因

30

ミャンマー

人件費が安い

国民性が日本と似ていてチームワーク重視

ITインフラがまだ整備されていない

オフショア開発の歴史が浅い


オフショア開発最後のフロンティアと呼ばれ、エンジニ

アの人件費が最も安い国。今後一番期待され、一番のび

しろがある。

31

目次

1) 自己紹介

2) 発表の目的





32

オフショアの受託スキルの向上とブリッジSEの減少

オフショア先のリーダー層に、入社以降オフショア開発

を経験し続けてきた人材も増えてきた

そういった優秀なリーダーがいるオフショア先への仕事

の依頼に関しては専用のブリッジSEが不要になる場面も

大量動員から少数精鋭

以前はオフショア側の動員力と低価格を中心とした大量

動員の面での活用が中心(プログラミング、テスト中心)

コミュニケーション環境の充実化、オフショア側の受託

能力の上昇、日本側のオフショア委託能力の上昇

ハイスキル・ローコストのハイパフォーマンス人材

33

オフショアファースト

「プロマネ＋オフショア開発者」といった開発体制も珍

しくなくなってきた

ボリュームと難易度に合わせて日本人エンジニアを追加

で動員するような、オフショア前提、日本人はプラスで、

のようなオフショアファーストの開発体制

新天地の開発

主にミャンマーなど東南アジア方面の新たな国々

電気などインフラもままならず、通信網も脆弱

●参考資料

2014年近年のオフショア事情 - プロマネブログ

http://getlife.hateblo.jp/entry/2014/05/21/063000

34

目次

1) 自己紹介

2) 発表の目的





35

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

36

まとめると、

チーム体制

日本側:2名(PM:1, アーキテクト:1)

ベトナム側:9名(PL:1, QA:2, 開発:6)

開発期間

7ヶ月間(2006年6月～12月：ベトナムブーム期)

開発手法

ウォーターフォールモデル

オフショア側作業

詳細設計, プログラミング, 単体テスト, 結合テスト

37

"プロマネ＋オフショア開発者"体制(オフショアファースト)

上流工程からオフショア側のPMを参加させ、他のメンバー

が詳細設計から参加させる

オフショア側のチームメンバーの語学力を向上させる

ドキュメントとプロセスを標準化する

情報共有を徹底する

用語の定義を統一させ、共通認識にする

レビュー回数を増やす

QAチームで品質保証する

ベトナムのインフラがまだ弱いため、停電、洪水などの対

策を検討する

日本国内での外部委託のように「大体こんな感じで開発してほしい」と口頭で説明し、そのまま進めること

は危険極まりない。

要件定義はドキュメント化する必要がある。

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

40

目次



9) 改善施策

10)実施結果


12)まとめ

41

GMOベトナムラボセンターの実施状況

チーム体制

日本側:4名

ラボ専任[日本人](1名)

研修で来日中の[ベトナム人](3名)

ベトナム側:3名

開発案件

ゲーム開発

KPIツール開発

42

現状の業務発注フロー

設計、仕様書作成をラボ専任担当(国内日本人)が行なう

Skypeと画面共有で仕様を伝達

要件定義書等は作っていない

RedmineのBacklogsプラグインのカンバンでステータ

ス管理、Worktimeプラグインで工数管理

Skypeによる朝会、定例MTGで進捗確認

アウトプットの受け入れ確認をラボ専任担当が実施

一回で仕様を満たしていることは少ないため、複数

回の発注、確認のサイクルを繰り返して完了

43

Keep

信頼関係

メンバー全員、1年間日本で働くようにしている

3ヶ月に1回専任担当＋αがベトナム出張

改善意欲

日本からの要望にできるだけ答えられるようにし

たいという気持ち

実績

改善の余地は多いが、アウトプットは出せている

44

Problem

コミュニケーション

テキストチャット、ボイスチャットだけではなか

なかうまく伝わらない

質問、回答のタイミングがすれ違う

早く聞けばすぐに解決するような問題も多い

国内で伝えたり、出張時に行なった研修が定着しない

徹底されておらず、放置気味になっている

アジャイル開発研修など

危険極まりない。

書いてないこと、仕様が間違っていることを汲み取って対応してくれるとありがたいのになー。

間を埋める新しいオフショア開発手法が必要だ！

46

とあるゲーム開発案件の状況

チーム体制

日本側:4名

プロデューサー[日本人](2名)

ブリッジSE[ベトナム人](2名) ※掛け持ち

ベトナム側:5名※最大

開発[ベトナム人](5名)

開発案件

ゲーム開発

ネイティブアプリケーションのリニューアル

47

Problem

ソースコードの理解不足

現バージョンのソースコードを渡すのみで各種機

能追加を依頼したので、局所的な理解のまま力技

で進めてもらってしまった

そのため、以下の問題が発生

他への影響が想定できないため、バグ多発、見

積もりの精度低下

全体最適化ができない

48

Problem

プロジェクトマネージャーとプロデューサー(プロダ

クトマネージャー)を同一人物が兼務

本来なら相反する役割

プロジェクトを守る存在がいない状況

オフショアチーム側(ブリッジ)で品質を担保できない

明らかなバグを含んだ状態で製品が上がってくる

ザックリとした仕様のため、1度のやり取りで完成す

る事が少ない

計画は1度のやり取りで終わる前提のため、遅延が

多発しスケジュールが組めない

49

目次



9) 改善施策

10)実施結果


12)まとめ

50

問題点まとめ

1度のやり取りで完成しない

オフショアチームの見積もり精度が低い

その結果

遅延を繰り返す

モチベーションが下がる

スケジュールが信頼できなくなる

相手を信頼できなくなる

51

問題点まとめ

オフショアチームで品質を担保できない

その結果

日本側の担当者(プロデューサー)の負荷増大

明らかなバグから細かいバグまで全て確認し、指摘す

る必要がある

52

問題点まとめ

あとちょっとの修正も、修正を依頼するためのコストが

結構かかる

その結果

95%完了から完成までしばらく時間がかかる

53

目次



9) 改善施策

10)実施結果


12)まとめ

改善施策1

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

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

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

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

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

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

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

95%完了から先が長い

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

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

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

Rough Fill Closing

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

Rough Fill Closing

75

ザックリ開発するフェーズ

7割程度の完成度を目指す

Backlogの時点で、ストーリーはレディ(着

手可能、仕様記載済み)な前提

ストーリーをタスク分割時に、オフショア

側開発者に工数を見積もってもらう

Roughのレビューフェーズで、専任担当

は完成までに必要な仕様を詳細に伝える

Rough Fill Closing

77

Roughフェーズでのアウトプットの完成

度を上げるフェーズ

9割以上の完成度を目指す

Rough Fill Closing

79

完成させるフェーズ

日本側の発注者(エンジニア)が対応する

改善施策2

ちゃんと教える

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

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

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

86

ベトナム出張時研修(2014年1月)

カードモデリング実践

ふりかえり実践

インセプションデッキ実践

アジャイル開発の基礎講習

スクラムの基礎講習

スクラムの知識テスト

リーンカンバンの基礎講習

ストーリーマッピング実践

アジャイル開発プロセス体験

マシュマロチャレンジ

88

ベトナム帰国前研修(2014年9月)

自己組織化ゲーム

スクラム座学

アジャイル開発プロセス体験

インセプションデッキ実践

ユーザーストーリーマッピング基礎

スクラムガイド自習

スクラムインフォグラフィックス

ユーザーストーリーマッピング応用

90

目次



9) 改善施策

10)実施結果


12)まとめ

Roughフェーズの見積もり日数、実際にか

かった日数、完成までに要した日数(サイク

ルタイム)等のメトリクスを収集

サイクルタイム÷見積もり日数で完了係数を

算出し、計画づくりに使用する

そうですね。今までもカンバンを使ってステータスの確認を行なっていたのですが、Doingのタスクが終わりそうなのか、マズそうなのかがパッと見で判断つきませんでした。

その点RFCモデルのカンバンはステータスが細かく設定されているため、見える化が促進したと感じています。

導入直後のSprintでは、残念ながら一部のストーリーが未達に終わってしまったのですが、今後の改善に期待しています！

発注者(PM)のSさんにお聞きします。

実際にRFCモデルを適用してみた率直な感想を聞かせて頂けますか？

RFCモデルをご利用頂いたお客様の声！

94

Keep

見える化が進んだ

各タスクのステータスがひと目で分かる

Trelloの効果も大きい

タスクがレビューステータスの際は、次のタスクを自

ら取って進めるなど、自己組織化が促進した

ラフ見積もりの精度は想定通り高く、完了形数のバラ

付きもそれほど無かった

チームが慣れれば、計画づくりに使えると感じて

いる

95

Problem

ラボ専任担当の負荷増大

Rough仕様作成

Roughレビュー

Fill仕様作成

Fillレビュー

Closingタスク

ラボ専任担当がボトルネックになるケースがあった

レビュー待ち、Closingタスクの増大

スケールしない構造

研修が単発的にしか行えていない

96

Try

ラボ専任担当のWIPを制限する仕組みの検討

GMOインターネットグループ各社のオフショア開発

への適用

RFCモデル

中規模プロジェクトへの適用

アジャイル開発プラクティスの実施

ふりかえりは実施しているが活かせていない

継続的、定期的な研修の実施

ベトナムでは3ヶ月に1回程度

国内では毎月1回程度

97

目次



9) 改善施策

10)実施結果


12)まとめ

98

利用ツール

Skype

Trello

Redmine

join.me

Sqwiggle

99

目次



9) 改善施策

10)実施結果


12)まとめ

100

オフショア開発の歴史と背景、トレンドを

自分なりに整理することが出来た

個人的には、守破離の「破」の段階へ進み

たいと考えていたため、ちょうど良いタイ

ミングでの試みだった(RFCモデル)

パターンを収集し、オフショア開発のパ

ターン・ランゲージを作っていきたい

102

その後

現在の状況

104

Keep

受け入れテスト時の品質向上

2014年3Q：85%→2014年4Q：100%

レビューを複数回実施しているため

作業ペースは早くなってきている

体感ベース

自己組織化促進

Backlogに積んでおくと、タスク分解、ブランチ作

成、実装、ラボ内レビューまで自発的に実施

メンバー間のレビュー精度向上

105

Problem

期限に対する意識が低い

Due date になってもサラッと遅延

遅れることが問題ではなく、共有されないことが

問題

新規作業は完了係数が大きくなる

完了係数をそもそも活用できていない

メトリクスの集計が手間

106

Try

完了係数の活用

Trelloプラグイン(RFC for Trello)検討

完了係数自動集計

Due date × 完了係数から受け入れ予想表示

受け入れ予想がSprint期限を過ぎる場合は警告

RFCモデルのパターン・ランゲージ化

オフショアパターン

敷居が高い…

RFCモデル導入マニュアル整備

他部署、他社への適用

107

SlideShareにアップした結果、

108

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

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

発表の機会を頂けた。

川口さん Satoさん

111

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

112

おわり

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

Engineering