アジャイルなオフショア開発
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 208 views

社内勉強会で発表した資料です。

社内勉強会で発表した資料です。

Statistics

Views

Total Views
208
Views on SlideShare
178
Embed Views
30

Actions

Likes
9
Downloads
5
Comments
0

1 Embed 30

http://recruit.gmo.jp 30

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 1 2014年9月29日 ＧＭＯインターネット株式会社 次世代システム研究室 藤村 新 アジャイルな オフショア開発 ～オフショア開発の動向、問題点とその改善施策～
  • 2 目次 1)自己紹介 2)発表の目的 3)オフショア開発の歴史と背景 4)オフショア発注先の各国の特徴 5)オフショア開発のトレンド 6)オフショア開発成功事例
  • 3 目次 7)次世代システム研究室でのオフショア開発事例 8)現状の問題点 9)改善施策 10)実施結果 11)[デモ]ツールを使ったコミュニケーション 12)まとめ
  • 4 目次 1)自己紹介 2)発表の目的 3)オフショア開発の歴史と背景 4)オフショア発注先の各国の特徴 5)オフショア開発のトレンド 6)オフショア開発成功事例
  • 藤村 新 Arata Fujimura GMOインターネット 次世代システム研究室
  • 6 ＋ 正しく続ける やりたいこと
  • 7 正しいものを(プロダクトディスカバリーフェーズ) デザイン思考 顧客開発モデル リーンスタートアップ ビジネスモデルキャンバス ユーザーエクスペリエンスマップ ユーザーストーリーマッピング インセプションデッキ
  • 8 正しくつくり(開発フェーズ) アジャイル開発 スクラム XP ドメイン駆動設計 正しく続ける(運用フェーズ) リーン開発 継続的デリバリー 今時インフラ インフラCI Immutable Infrastructure
  • 9 目次 1)自己紹介 2)発表の目的 3)オフショア開発の歴史と背景 4)オフショア発注先の各国の特徴 5)オフショア開発のトレンド 6)オフショア開発成功事例
  • 10 次世代システム研究室では GMOベトナムラボセンター (ベトナム/ハノイ) と密接に連携しながらGMOインター ネットグループのシステム開発等に取り組んでいるが、 必ずしもうまくいっているとは言えない状況
  • 11 次世代システム研究室では GMOベトナムラボセンター (ベトナム/ハノイ) と密接に連携しながらGMOインター ネットグループのシステム開発等に取り組んでいるが、 必ずしもうまくいっているとは言えない状況 GMOインターネットグループの各社でもオフショア開発 に取り組んでいるが、あまりうまくいってなさそう
  • 12 次世代システム研究室では GMOベトナムラボセンター (ベトナム/ハノイ) と密接に連携しながらGMOインター ネットグループのシステム開発等に取り組んでいるが、 必ずしもうまくいっているとは言えない状況 GMOインターネットグループの各社でもオフショア開発 に取り組んでいるが、あまりうまくいってなさそう 問題点を分析し、有効な改善施策を提案できればグルー プに多大な貢献ができるのではないか
  • 13 つまり、目的は
  • 14 つまり、目的は オフショア開発の現状を調べ 問題点を洗い出し
  • 15 つまり、目的は オフショア開発の現状を調べ 問題点を洗い出し 改善施策を考え[仮説立案] 実践し 仮説検証して次の改善施策につなげることにより 新しいオフショア開発パターンを編み出し
  • 16 つまり、目的は オフショア開発の現状を調べ 問題点を洗い出し 改善施策を考え[仮説立案] 実践し 仮説検証して次の改善施策につなげることにより 新しいオフショア開発パターンを編み出し GMOインターネットグループに貢献すること です。
  • 17 目次 1)自己紹介 2)発表の目的 3)オフショア開発の歴史と背景 4)オフショア発注先の各国の特徴 5)オフショア開発のトレンド 6)オフショア開発成功事例
  • 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)発表の目的 3)オフショア開発の歴史と背景 4)オフショア発注先の各国の特徴 5)オフショア開発のトレンド 6)オフショア開発成功事例
  • 26 主なオフショア発注先 インド 中国 ベトナム ミャンマー 大前提 低価格？＆日本語対応の中国 技術力＆国際対応のインド 既に棲み分けが進んでおり、これからも役割分担は起 きないと見られている
  • 27 インド 世界的に見れば最大のオフショア開発先 上流工程の知識、実績が豊富 英語での対応が可能 世界標準の開発手法(日本の開発手法と異なる) 人件費が高い 優秀なエンジニアの確保が難しい 人月単価(平均)：約30万円 コストダウンではなく技術力が目的でオフショア開発 を行なう企業が多くなってきている
  • 28 中国 ITインフラが整備されている(主に沿岸部) 日本との距離が近く、時差も少ない エンジニアの数が多く優秀なエンジニアを確保しやすい 日本語能力が高い 人件費が高くなってきている(主に沿岸部) 離職率が高い 反日感情、政治リスクがある 人月単価(平均)：約35万円(沿岸部) 日本語能力は極めて高く、企画力や創造力に長けている 人材も豊富
  • 29 ベトナム 中国、インドと比較して人件費が安い 国の施策としてオフショア開発に力を入れている 親日である 優秀なエンジニアの確保が難しくなってきている インド、中国に比べて開発者のスキルが若干低い 日本語、英語能力共、若干低い 人月単価(平均)：約25万円 親日でコストも安く、日本語もある程度通じ、小型案件 から対応可能というバランスの良さが人気の要因
  • 30 ミャンマー 人件費が安い 国民性が日本と似ていてチームワーク重視 ITインフラがまだ整備されていない オフショア開発の歴史が浅い 人月単価(平均)：約18万円 オフショア開発最後のフロンティアと呼ばれ、エンジニ アの人件費が最も安い国。今後一番期待され、一番のび しろがある。
  • 31 目次 1)自己紹介 2)発表の目的 3)オフショア開発の歴史と背景 4)オフショア発注先の各国の特徴 5)オフショア開発のトレンド 6)オフショア開発成功事例
  • 32 オフショアの受託スキルの向上とブリッジSEの減少 オフショア先のリーダー層に、入社以降オフショア開発 を経験し続けてきた人材も増えてきた そういった優秀なリーダーがいるオフショア先への仕事 の依頼に関しては専用のブリッジSEが不要になる場面も 大量動員から少数精鋭 以前はオフショア側の動員力と低価格を中心とした大量 動員の面での活用が中心(プログラミング、テスト中心) コミュニケーション環境の充実化、オフショア側の受託 能力の上昇、日本側のオフショア委託能力の上昇 ハイスキル・ローコストのハイパフォーマンス人材
  • 33 オフショアファースト 「プロマネ＋オフショア開発者」といった開発体制も珍 しくなくなってきた ボリュームと難易度に合わせて日本人エンジニアを追加 で動員するような、オフショア前提、日本人はプラスで、 のようなオフショアファーストの開発体制 新天地の開発 主にミャンマーなど東南アジア方面の新たな国々 電気などインフラもままならず、通信網も脆弱
  • 34 目次 1)自己紹介 2)発表の目的 3)オフショア開発の歴史と背景 4)オフショア発注先の各国の特徴 5)オフショア開発のトレンド 6)オフショア開発成功事例
  • 35 次研Qさんレポート(ベトナムオフショア開発)
  • 36 まとめると、 チーム体制 日本側:2名(PM:1, アーキテクト:1) ベトナム側:9名(PL:1, QA:2, 開発:6) 開発期間 7ヶ月間(2006年6月～12月：ベトナムブーム期) 開発手法 ウォーターフォールモデル オフショア側作業 詳細設計, プログラミング, 単体テスト, 結合テスト
  • 37 "プロマネ＋オフショア開発者"体制(オフショアファースト) 上流工程からオフショア側のPMを参加させ、他のメンバー が詳細設計から参加させる オフショア側のチームメンバーの語学力を向上させる ドキュメントとプロセスを標準化する 情報共有を徹底する 用語の定義を統一させ、共通認識にする レビュー回数を増やす QAチームで品質保証する ベトナムのインフラがまだ弱いため、停電、洪水などの対 策を検討する
  • 日本国内での外部委託のように「大体こんな感じで開 発してほしい」と口頭で説明し、そのまま進めること は危険極まりない。 要件定義はドキュメント化する必要がある。
  • ここまでで開始から15分経過なら良いペース！
  • 40 目次 7)次世代システム研究室でのオフショア開発事例 8)現状の問題点 9)改善施策 10)実施結果 11)[デモ]ツールを使ったコミュニケーション 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 目次 7)次世代システム研究室でのオフショア開発事例 8)現状の問題点 9)改善施策 10)実施結果 11)[デモ]ツールを使ったコミュニケーション 12)まとめ
  • 50 問題点まとめ 1度のやり取りで完成しない オフショアチームの見積もり精度が低い その結果 遅延を繰り返す モチベーションが下がる スケジュールが信頼できなくなる 相手を信頼できなくなる
  • 51 問題点まとめ オフショアチームで品質を担保できない その結果 日本側の担当者(プロデューサー)の負荷増大 明らかなバグから細かいバグまで全て確認し、指摘す る必要がある
  • 52 問題点まとめ あとちょっとの修正も、修正を依頼するためのコストが 結構かかる その結果 95%完了から完成までしばらく時間がかかる
  • 53 目次 7)次世代システム研究室でのオフショア開発事例 8)現状の問題点 9)改善施策 10)実施結果 11)[デモ]ツールを使ったコミュニケーション 12)まとめ
  • 改善施策1
  • 頑張っても 効果が薄い事は 諦める
  • 一度のやり取りで期待通 りのアウトプットが出て こない
  • 一度のやり取りで期待通 りのアウトプットが出て こない 時間をかけてもっと詳細 な仕様書を準備する
  • 一度のやり取りで期待通 りのアウトプットが出て こない 時間をかけてもっと詳細 な仕様書を準備する
  • 一度のやり取りで期待通 りのアウトプットが出て こない 1度のやり取りでの完成を 諦めた初回ザックリ開発
  • 見積もりの精度が低く、 完了予定が見えない
  • 見積もりの精度が低く、 完了予定が見えない 時間をかけて見積もりの 精度を上げてもらう
  • 見積もりの精度が低く、 完了予定が見えない 時間をかけて見積もりの 精度を上げてもらう
  • 見積もりの精度が低く、 完了予定が見えない ザックリ開発工数だけ見 積もってもらい、実見積 もりは係数を使って算出
  • 95%完了から先が長い
  • 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 目次 7)次世代システム研究室でのオフショア開発事例 8)現状の問題点 9)改善施策 10)実施結果 11)[デモ]ツールを使ったコミュニケーション 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 目次 7)次世代システム研究室でのオフショア開発事例 8)現状の問題点 9)改善施策 10)実施結果 11)[デモ]ツールを使ったコミュニケーション 12)まとめ
  • 98 利用ツール Skype Trello Redmine join.me Sqwiggle
  • BacklogのストーリーからToDoのタスクへの落とし込 みについて、ツールを実際にどうやっているのか、デ モしてもらいます。 デモのシーン ラボ専任担当のTKです。 ベトナムラボセンターのQです。
  • 100 目次 7)次世代システム研究室でのオフショア開発事例 8)現状の問題点 9)改善施策 10)実施結果 11)[デモ]ツールを使ったコミュニケーション 12)まとめ
  • 101 オフショア開発の歴史と背景、トレンドを 自分なりに整理することが出来た 個人的には、守破離の「破」の段階へ進み たいと考えていたため、ちょうど良いタイ ミングでの試みだった(RFCモデル) パターンを収集し、オフショア開発のパ ターン・ランゲージを作っていきたい
  • 102 おわり