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

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

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

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

4
目次
1)自己紹介
2)発表の目的

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

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

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

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

9
目次
1)自己紹介
2)発表の目的

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

11
GMOインターネットグループの各社でもオフショア開発に取り組んでいるが、あまりうまくいってなさそう

12
GMOインターネットグループの各社でもオフショア開発に取り組んでいるが、あまりうまくいってなさそう
問題点を分析し、有効な改善施策を提案できればグループに多大な貢献ができるのではないか

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
オフショアファースト
「プロマネ＋オフショア開発者」といった開発体制も珍しくなくなってきた
ボリュームと難易度に合わせて日本人エンジニアを追加で動員するような、オフショア前提、日本人はプラスで、のようなオフショアファーストの開発体制
新天地の開発
主にミャンマーなど東南アジア方面の新たな国々
電気などインフラもままならず、通信網も脆弱

34
目次
1)自己紹介
2)発表の目的

35
次研Qさんレポート(ベトナムオフショア開発)

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度のやり取りでの完成を諦めた初回ザックリ開発

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BacklogのストーリーからToDoのタスクへの落とし込みについて、ツールを実際にどうやっているのか、デモしてもらいます。
デモのシーン
ラボ専任担当のTKです。
ベトナムラボセンターのQです。

100
目次
9)改善施策
10)実施結果
12)まとめ

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

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

More Related Content

What's hot

Viewers also liked

Similar to アジャイルなオフショア開発

More from Arata Fujimura

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