More Related Content
Similar to アジャイルなオフショア開発 (20)
More from Arata Fujimura (20)
アジャイルなオフショア開発
- 2. 2
目次
1)自己紹介
2)発表の目的
3)オフショア開発の歴史と背景
4)オフショア発注先の各国の特徴
5)オフショア開発のトレンド
6)オフショア開発成功事例
- 4. 4
目次
1)自己紹介
2)発表の目的
3)オフショア開発の歴史と背景
4)オフショア発注先の各国の特徴
5)オフショア開発のトレンド
6)オフショア開発成功事例
- 9. 9
目次
1)自己紹介
2)発表の目的
3)オフショア開発の歴史と背景
4)オフショア発注先の各国の特徴
5)オフショア開発のトレンド
6)オフショア開発成功事例
- 11. 11
次世代システム研究室では GMOベトナムラボセンター (ベトナム/ハノイ) と密接に連携しながらGMOインター ネットグループのシステム開発等に取り組んでいるが、 必ずしもうまくいっているとは言えない状況
GMOインターネットグループの各社でもオフショア開発 に取り組んでいるが、あまりうまくいってなさそう
- 12. 12
次世代システム研究室では GMOベトナムラボセンター (ベトナム/ハノイ) と密接に連携しながらGMOインター ネットグループのシステム開発等に取り組んでいるが、 必ずしもうまくいっているとは言えない状況
GMOインターネットグループの各社でもオフショア開発 に取り組んでいるが、あまりうまくいってなさそう
問題点を分析し、有効な改善施策を提案できればグルー プに多大な貢献ができるのではないか
- 16. 16
つまり、目的は
オフショア開発の現状を調べ
問題点を洗い出し
改善施策を考え[仮説立案]
実践し
仮説検証して次の改善施策につなげることにより
新しいオフショア開発パターンを編み出し
GMOインターネットグループに貢献すること です。
- 17. 17
目次
1)自己紹介
2)発表の目的
3)オフショア開発の歴史と背景
4)オフショア発注先の各国の特徴
5)オフショア開発のトレンド
6)オフショア開発成功事例
- 25. 25
目次
1)自己紹介
2)発表の目的
3)オフショア開発の歴史と背景
4)オフショア発注先の各国の特徴
5)オフショア開発のトレンド
6)オフショア開発成功事例
- 26. 26
主なオフショア発注先
インド
中国
ベトナム
ミャンマー
大前提
低価格?&日本語対応の中国
技術力&国際対応のインド
既に棲み分けが進んでおり、これからも役割分担は起 きないと見られている
- 27. 27
インド
世界的に見れば最大のオフショア開発先
上流工程の知識、実績が豊富
英語での対応が可能
世界標準の開発手法(日本の開発手法と異なる)
人件費が高い
優秀なエンジニアの確保が難しい
人月単価(平均):約30万円
コストダウンではなく技術力が目的でオフショア開発 を行なう企業が多くなってきている
- 28. 28
中国
ITインフラが整備されている(主に沿岸部)
日本との距離が近く、時差も少ない
エンジニアの数が多く優秀なエンジニアを確保しやすい
日本語能力が高い
人件費が高くなってきている(主に沿岸部)
離職率が高い
反日感情、政治リスクがある
人月単価(平均):約35万円(沿岸部)
日本語能力は極めて高く、企画力や創造力に長けている 人材も豊富
- 29. 29
ベトナム
中国、インドと比較して人件費が安い
国の施策としてオフショア開発に力を入れている
親日である
優秀なエンジニアの確保が難しくなってきている
インド、中国に比べて開発者のスキルが若干低い
日本語、英語能力共、若干低い
人月単価(平均):約25万円
親日でコストも安く、日本語もある程度通じ、小型案件 から対応可能というバランスの良さが人気の要因
- 30. 30
ミャンマー
人件費が安い
国民性が日本と似ていてチームワーク重視
ITインフラがまだ整備されていない
オフショア開発の歴史が浅い
人月単価(平均):約18万円
オフショア開発最後のフロンティアと呼ばれ、エンジニ アの人件費が最も安い国。今後一番期待され、一番のび しろがある。
- 31. 31
目次
1)自己紹介
2)発表の目的
3)オフショア開発の歴史と背景
4)オフショア発注先の各国の特徴
5)オフショア開発のトレンド
6)オフショア開発成功事例
- 34. 34
目次
1)自己紹介
2)発表の目的
3)オフショア開発の歴史と背景
4)オフショア発注先の各国の特徴
5)オフショア開発のトレンド
6)オフショア開発成功事例
- 36. 36
まとめると、
チーム体制
日本側:2名(PM:1, アーキテクト:1)
ベトナム側:9名(PL:1, QA:2, 開発:6)
開発期間
7ヶ月間(2006年6月~12月:ベトナムブーム期)
開発手法
ウォーターフォールモデル
オフショア側作業
詳細設計, プログラミング, 単体テスト, 結合テスト
- 42. 42
現状の業務発注フロー
設計、仕様書作成をラボ専任担当(国内日本人)が行なう
Skypeと画面共有で仕様を伝達
要件定義書等は作っていない
RedmineのBacklogsプラグインのカンバンでステータ ス管理、Worktimeプラグインで工数管理
Skypeによる朝会、定例MTGで進捗確認
アウトプットの受け入れ確認をラボ専任担当が実施
一回で仕様を満たしていることは少ないため、複数 回の発注、確認のサイクルを繰り返して完了
- 43. 43
Keep
信頼関係
メンバー全員、1年間日本で働くようにしている
3ヶ月に1回専任担当+αがベトナム出張
改善意欲
日本からの要望にできるだけ答えられるようにし たいという気持ち
実績
改善の余地は多いが、アウトプットは出せている
- 44. 44
Problem
コミュニケーション
テキストチャット、ボイスチャットだけではなか なかうまく伝わらない
質問、回答のタイミングがすれ違う
早く聞けばすぐに解決するような問題も多い
国内で伝えたり、出張時に行なった研修が定着しない
徹底されておらず、放置気味になっている
アジャイル開発研修など
- 46. 46
とあるゲーム開発案件の状況
チーム体制
日本側:4名
プロデューサー[日本人](2名)
ブリッジSE[ベトナム人](2名) ※掛け持ち
ベトナム側:5名※最大
開発[ベトナム人](5名)
開発案件
ゲーム開発
ネイティブアプリケーションのリニューアル
- 47. 47
Problem
ソースコードの理解不足
現バージョンのソースコードを渡すのみで各種機 能追加を依頼したので、局所的な理解のまま力技 で進めてもらってしまった
そのため、以下の問題が発生
他への影響が想定できないため、バグ多発、見 積もりの精度低下
全体最適化ができない
- 48. 48
Problem
プロジェクトマネージャーとプロデューサー(プロダ クトマネージャー)を同一人物が兼務
本来なら相反する役割
プロジェクトを守る存在がいない状況
オフショアチーム側(ブリッジ)で品質を担保できない
明らかなバグを含んだ状態で製品が上がってくる
ザックリとした仕様のため、1度のやり取りで完成す る事が少ない
計画は1度のやり取りで終わる前提のため、遅延が 多発しスケジュールが組めない
- 75. 75
ザックリ開発するフェーズ
7割程度の完成度を目指す
Backlogの時点で、ストーリーはレディ(着 手可能、仕様記載済み)な前提
ストーリーをタスク分割時に、オフショア 側開発者に工数を見積もってもらう
Roughのレビューフェーズで、専任担当 は完成までに必要な仕様を詳細に伝える
- 93. そうですね。 今までもカンバンを使ってステータスの確認を行 なっていたのですが、Doingのタスクが終わりそう なのか、マズそうなのかがパッと見で判断つきませ んでした。 その点RFCモデルのカンバンはステータスが細かく 設定されているため、見える化が促進したと感じて います。 導入直後のSprintでは、残念ながら一部のストー リーが未達に終わってしまったのですが、今後の改 善に期待しています!
発注者(PM)のSさんにお聞きします。 実際にRFCモデルを適用してみた率直な感想を聞かせ て頂けますか?
RFCモデルをご利用頂いたお客様の声!
- 94. 94
Keep
見える化が進んだ
各タスクのステータスがひと目で分かる
Trelloの効果も大きい
タスクがレビューステータスの際は、次のタスクを自 ら取って進めるなど、自己組織化が促進した
ラフ見積もりの精度は想定通り高く、完了形数のバラ 付きもそれほど無かった
チームが慣れれば、計画づくりに使えると感じて いる
- 95. 95
Problem
ラボ専任担当の負荷増大
Rough仕様作成
Roughレビュー
Fill仕様作成
Fillレビュー
Closingタスク
ラボ専任担当がボトルネックになるケースがあった
レビュー待ち、Closingタスクの増大
スケールしない構造
研修が単発的にしか行えていない
- 96. 96
Try
ラボ専任担当のWIPを制限する仕組みの検討
GMOインターネットグループ各社のオフショア開発 への適用
RFCモデル
中規模プロジェクトへの適用
アジャイル開発プラクティスの実施
ふりかえりは実施しているが活かせていない
継続的、定期的な研修の実施
ベトナムでは3ヶ月に1回程度
国内では毎月1回程度