Upload
Download free for 30 days
Login
Submit Search
A 2a:アジャイルなオフショア開発
18 likes
3,292 views
Arata Fujimura
Agile Japan 2015 A-2a:事例セッション(13:50-14:15) での発表資料です。
Engineering
Read more
1 of 70
Download now
Downloaded 35 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
More Related Content
PDF
アジャイルオフショア開発モデル
Arata Fujimura
PDF
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
Hironori Washizaki
PDF
開発モデルの作り方(守破離の破)
Arata Fujimura
PDF
「PdMと考えるQAとプロダクトマネジメント」
大貴 蜂須賀
PDF
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
PPTX
振り返り(アジャイルレトロスペクティブズ)
Keisuke Tameyasu
PDF
What is quality culture? Is it something tasty?
Yasuharu Nishi
PPTX
3 Amigosの考え方で、独立したQAチームがアジャイルテストチームになるまでの話
Koichiro Takashima
アジャイルオフショア開発モデル
Arata Fujimura
パターン QA to AQ: 伝統的品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ
Hironori Washizaki
開発モデルの作り方(守破離の破)
Arata Fujimura
「PdMと考えるQAとプロダクトマネジメント」
大貴 蜂須賀
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
振り返り(アジャイルレトロスペクティブズ)
Keisuke Tameyasu
What is quality culture? Is it something tasty?
Yasuharu Nishi
3 Amigosの考え方で、独立したQAチームがアジャイルテストチームになるまでの話
Koichiro Takashima
What's hot
(20)
PDF
正しいものを正しくつくる
toshihiro ichitani
PDF
アジャイルとスクラムとは 原則、価値、プラクティス
Yasui Tsutomu
PDF
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
Itsuki Kuroda
PDF
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
Yasuharu Nishi
PPTX
【Ltech#6 】LIFULLでのQAのあり方
LIFULL Co., Ltd.
PDF
概説 テスト分析
崇 山﨑
PDF
TDD のこころ
Takuto Wada
PDF
ゼロからはじめるプロダクトマネージャー生活
Takaaki Umada
PDF
Issueの書き方と伝え方
Rina Fukuda
PDF
ユーザーストーリーの分割
Arata Fujimura
PDF
スタートアップの"共同創業者"を選ぶ技術
Takaaki Umada
PDF
大企業アジャイルの勘所 #devlovex #devlovexd
Itsuki Kuroda
PDF
Leanstartupをリーンにヤル #リーンスタートアップ
Itsuki Kuroda
PDF
サービス開発における フロントエンド・ドメイン駆動設計の実践
TakefumiYoshii
PDF
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
PDF
君はyarn.lockをコミットしているか?
Teppei Sato
PPTX
Product ManagerとProduct Ownerの役割の違いについて
Noritaka Shinohara
PDF
Agile Quality アジャイル品質パターン (QA2AQ)
Hironori Washizaki
PDF
「ユーザーを理解するって言うほどカンタンじゃないよね」 UXデザイン・UXリサーチをもう一度ちゃんと理解しよう!
Yoshiki Hayama
PDF
LINE Developer Meetup in Tokyo #39 Presentation (modified)
Yasuharu Nishi
正しいものを正しくつくる
toshihiro ichitani
アジャイルとスクラムとは 原則、価値、プラクティス
Yasui Tsutomu
結果的に組織がAgileな状態であること #agile #scrum #leanstartup
Itsuki Kuroda
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
Yasuharu Nishi
【Ltech#6 】LIFULLでのQAのあり方
LIFULL Co., Ltd.
概説 テスト分析
崇 山﨑
TDD のこころ
Takuto Wada
ゼロからはじめるプロダクトマネージャー生活
Takaaki Umada
Issueの書き方と伝え方
Rina Fukuda
ユーザーストーリーの分割
Arata Fujimura
スタートアップの"共同創業者"を選ぶ技術
Takaaki Umada
大企業アジャイルの勘所 #devlovex #devlovexd
Itsuki Kuroda
Leanstartupをリーンにヤル #リーンスタートアップ
Itsuki Kuroda
サービス開発における フロントエンド・ドメイン駆動設計の実践
TakefumiYoshii
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
君はyarn.lockをコミットしているか?
Teppei Sato
Product ManagerとProduct Ownerの役割の違いについて
Noritaka Shinohara
Agile Quality アジャイル品質パターン (QA2AQ)
Hironori Washizaki
「ユーザーを理解するって言うほどカンタンじゃないよね」 UXデザイン・UXリサーチをもう一度ちゃんと理解しよう!
Yoshiki Hayama
LINE Developer Meetup in Tokyo #39 Presentation (modified)
Yasuharu Nishi
Ad
Viewers also liked
(20)
PDF
Agile Testing Learning journeys for the whole team at AgileJapan 2015
Kenji Hiranabe
PDF
システム開発の流れ(アジャイルソフトウェア開発)
Arata Fujimura
PDF
フィリピンのスタートアップにスクラムを導入しようとしてみたお話
Arata Fujimura
PDF
大規模スクラムの失敗から学んだこと #AgileJapan2015
Itsuki Sakitsu
PDF
Agile japan2014c 3プレゼン資料アジャイル経験0から3年で3億以上を稼いだ道のり ~とある中小ソフトベンダーの請負アジャイル開発実績~
健 渡会
PDF
アジャイルなオフショア開発(Rakuten techtalk)
Arata Fujimura
PDF
アジャイル開発研修
Arata Fujimura
PDF
CSPO、CSM研修に参加して
Arata Fujimura
PDF
Agile japan神戸サテライト アジャイルの入り口は意外と広い。その中はもっと広い
Yuichiro Yamamoto
PDF
[PO Meetup 4th] プロダクトを描きストーリーを語ろう
Yuichiro Yamamoto
PDF
SGT2014 プロダクトオーナー現場十色
Yuichiro Yamamoto
PPTX
ダイスワークゲーム
Yuichiro Yamamoto
PDF
[POMeetup 8th]ビジョンをシンプルに描くツールと、理解共有のススメ
Yuichiro Yamamoto
PDF
選択と自由の見地からのモチベーション考
Yuichiro Yamamoto
PDF
Xp祭り関西2013
Yuichiro Yamamoto
PDF
[Agile Tour Osaka 2013] プロジェクトを導くしなやかな背骨
Yuichiro Yamamoto
PDF
非開発者のためのアジャイル開発入門
Kiro Harada
PDF
三島teNet第9回ワークショップ アジャイルな開発とは(公開版)
Yasui Tsutomu
PPTX
Agile Discussion 1st
Takao Kimura
PDF
東京農工大セミナー
Arata Fujimura
Agile Testing Learning journeys for the whole team at AgileJapan 2015
Kenji Hiranabe
システム開発の流れ(アジャイルソフトウェア開発)
Arata Fujimura
フィリピンのスタートアップにスクラムを導入しようとしてみたお話
Arata Fujimura
大規模スクラムの失敗から学んだこと #AgileJapan2015
Itsuki Sakitsu
Agile japan2014c 3プレゼン資料アジャイル経験0から3年で3億以上を稼いだ道のり ~とある中小ソフトベンダーの請負アジャイル開発実績~
健 渡会
アジャイルなオフショア開発(Rakuten techtalk)
Arata Fujimura
アジャイル開発研修
Arata Fujimura
CSPO、CSM研修に参加して
Arata Fujimura
Agile japan神戸サテライト アジャイルの入り口は意外と広い。その中はもっと広い
Yuichiro Yamamoto
[PO Meetup 4th] プロダクトを描きストーリーを語ろう
Yuichiro Yamamoto
SGT2014 プロダクトオーナー現場十色
Yuichiro Yamamoto
ダイスワークゲーム
Yuichiro Yamamoto
[POMeetup 8th]ビジョンをシンプルに描くツールと、理解共有のススメ
Yuichiro Yamamoto
選択と自由の見地からのモチベーション考
Yuichiro Yamamoto
Xp祭り関西2013
Yuichiro Yamamoto
[Agile Tour Osaka 2013] プロジェクトを導くしなやかな背骨
Yuichiro Yamamoto
非開発者のためのアジャイル開発入門
Kiro Harada
三島teNet第9回ワークショップ アジャイルな開発とは(公開版)
Yasui Tsutomu
Agile Discussion 1st
Takao Kimura
東京農工大セミナー
Arata Fujimura
Ad
Similar to A 2a:アジャイルなオフショア開発
(20)
PDF
Introduction to NetOpsCoding
Taiji Tsuchiya
PPTX
インドのインターネット環境との戦い方
Kenichi Tatsuhama
PDF
4.5G/5G環境でのECサイトの高速化 ― 変わるモバイル購買体験
Yoichiro Takehora
PPTX
インドの低速なネットワーク環境の攻略法
Kenichi Tatsuhama
PPTX
Hueによる分析業務の改善事例
Masahiro Kiura
PDF
GEEK ACADEMY REAL Vol.2. 「最先端のデータ解析/Apache Sparkを利用したレコメンドエンジン開発」
Junichi Noda
PPTX
Webクローリング&スクレイピングの最前線 公開用
Lumin Hacker
PPTX
Osc tokyo20141019
Kiyoshi Ogawa
PPTX
.Netlab202107
TomomitsuKusaba
PDF
IIJmio meeting 10 端末の動作確認(後編)
techlog (Internet Initiative Japan Inc.)
PPT
企業と勉強会 @nifty エンジニアサポート
Daichi Morifuji
PPTX
GBDC 勉強会 #1 Python を用いたツール作成工数の最小化
Yutaka Kato
PDF
Embedded Webで加速するWeb of Things
Futomi Hatano
PDF
Enterprise Redmine
Dai FUJIHARA
PPTX
さくらインターネットベアメタル自動化への挑戦
Hiroki Ito
PDF
Site Reliability Engineering (SRE)を可能にするOpenPIEのご紹介
OSSラボ株式会社
PPTX
Q a9 for ics(lotus) developers
賢次 海老原
PPTX
『フルスタックエンジニアを目指す』ためのOpenStack勉強術 - OpenStack最新情報セミナー 2014年2月
VirtualTech Japan Inc.
PDF
JIMUC 生成AI分科会活動報告 2025/7/11 エレメンタムコンサルティングLLC 増田和紀
kazuki masuda
PPTX
Iots2018 20181203
Takashi Yamanoue
Introduction to NetOpsCoding
Taiji Tsuchiya
インドのインターネット環境との戦い方
Kenichi Tatsuhama
4.5G/5G環境でのECサイトの高速化 ― 変わるモバイル購買体験
Yoichiro Takehora
インドの低速なネットワーク環境の攻略法
Kenichi Tatsuhama
Hueによる分析業務の改善事例
Masahiro Kiura
GEEK ACADEMY REAL Vol.2. 「最先端のデータ解析/Apache Sparkを利用したレコメンドエンジン開発」
Junichi Noda
Webクローリング&スクレイピングの最前線 公開用
Lumin Hacker
Osc tokyo20141019
Kiyoshi Ogawa
.Netlab202107
TomomitsuKusaba
IIJmio meeting 10 端末の動作確認(後編)
techlog (Internet Initiative Japan Inc.)
企業と勉強会 @nifty エンジニアサポート
Daichi Morifuji
GBDC 勉強会 #1 Python を用いたツール作成工数の最小化
Yutaka Kato
Embedded Webで加速するWeb of Things
Futomi Hatano
Enterprise Redmine
Dai FUJIHARA
さくらインターネットベアメタル自動化への挑戦
Hiroki Ito
Site Reliability Engineering (SRE)を可能にするOpenPIEのご紹介
OSSラボ株式会社
Q a9 for ics(lotus) developers
賢次 海老原
『フルスタックエンジニアを目指す』ためのOpenStack勉強術 - OpenStack最新情報セミナー 2014年2月
VirtualTech Japan Inc.
JIMUC 生成AI分科会活動報告 2025/7/11 エレメンタムコンサルティングLLC 増田和紀
kazuki masuda
Iots2018 20181203
Takashi Yamanoue
More from Arata Fujimura
(20)
PDF
クラスメソッドベトナム設立しました
Arata Fujimura
PDF
リーンスタートアップ実践者によるSDGs事業立ち上げ支援の取り組み
Arata Fujimura
PDF
DevOpsを支える原則、3つの道
Arata Fujimura
PDF
モダンオフショア開発でIT人材不足の解消を目指す 〜 ベトナムでの取り組みとこれから 〜
Arata Fujimura
PDF
スクラムマスター募集中
Arata Fujimura
PDF
変化に強い、継続的に学習する組織に変わるためのステップとは
Arata Fujimura
PDF
クラスメソッドにおけるスクラム開発の光と影
Arata Fujimura
PDF
モダンオフショア開発のすすめ
Arata Fujimura
PDF
スクラムワークショップ
Arata Fujimura
PDF
最高のScrumキメた後にスケールさせようとして混乱したけど今はまた最高のScrumに戻って新型コロナの影響は皆無な話
Arata Fujimura
PDF
登壇勉強会 〜それぞれの流儀がそこにある〜
Arata Fujimura
PDF
アジャイル開発の原則を守りつつ、マルチサイト開発を行なう!
Arata Fujimura
PDF
PdMワークショップ
Arata Fujimura
PDF
最高のScrumキメた後にスケールさせようとして混乱した話
Arata Fujimura
PDF
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
Arata Fujimura
PDF
Experience DevOps Implementation Support Service
Arata Fujimura
PDF
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
Arata Fujimura
PDF
俺のレアジョブ利用法
Arata Fujimura
PDF
DevOps導入支援、始めました
Arata Fujimura
PDF
プラクティス厨から始めるアジャイル開発
Arata Fujimura
クラスメソッドベトナム設立しました
Arata Fujimura
リーンスタートアップ実践者によるSDGs事業立ち上げ支援の取り組み
Arata Fujimura
DevOpsを支える原則、3つの道
Arata Fujimura
モダンオフショア開発でIT人材不足の解消を目指す 〜 ベトナムでの取り組みとこれから 〜
Arata Fujimura
スクラムマスター募集中
Arata Fujimura
変化に強い、継続的に学習する組織に変わるためのステップとは
Arata Fujimura
クラスメソッドにおけるスクラム開発の光と影
Arata Fujimura
モダンオフショア開発のすすめ
Arata Fujimura
スクラムワークショップ
Arata Fujimura
最高のScrumキメた後にスケールさせようとして混乱したけど今はまた最高のScrumに戻って新型コロナの影響は皆無な話
Arata Fujimura
登壇勉強会 〜それぞれの流儀がそこにある〜
Arata Fujimura
アジャイル開発の原則を守りつつ、マルチサイト開発を行なう!
Arata Fujimura
PdMワークショップ
Arata Fujimura
最高のScrumキメた後にスケールさせようとして混乱した話
Arata Fujimura
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
Arata Fujimura
Experience DevOps Implementation Support Service
Arata Fujimura
アジャイル開発の原則を守りつつ、グローバルチームを立ち上げる!
Arata Fujimura
俺のレアジョブ利用法
Arata Fujimura
DevOps導入支援、始めました
Arata Fujimura
プラクティス厨から始めるアジャイル開発
Arata Fujimura
A 2a:アジャイルなオフショア開発
1.
1 2015年4月16日 GMOインターネット株式会社 次世代システム研究室 藤村 新 /
片山 貴博 アジャイルなオフショア開発 Agile Japan 2015
2.
藤村 新 ふじむら あらた アジャイルPM研究会所属 片山
貴博 かたやま たかひろ GMOベトナムラボセンター 経営メンバー
3.
3 • オフショア開発の経緯 • RFCモデルとは •
RFCの理想 • RFCの現実 • まとめ アジェンダ
4.
4 オフショア開発の経緯
5.
http://cloud.watch.impress.co.jp/docs/release/20130326_593209.html 2013年3月11日 「GMOベトナムラボセンター」設立
6.
6 ミッション • GMOインターネットグループ の技術力のさらなる向上 • ベトナムの優秀な人財(IT技 術者)の確保と育成 •
インターネットの最先端技術 の検証や研究
7.
7 ミッション • GMOインターネットグループ の技術力のさらなる向上 • ベトナムの優秀な人財(IT技 術者)の確保と育成 •
インターネットの最先端技術 の検証や研究 優秀な ベトナム人が 欲しい!
8.
8 採用基準 • 日本語能力試験でN3以上 • 来日可能 •
1年間国内研修を実施 • 人柄が良い • 技術力がある • 20代半ばくらいの若手
9.
9 採用基準 • 日本語能力試験でN3以上 • 来日可能 •
1年間国内研修を実施 • 人柄が良い • 技術力がある • 20代半ばくらいの若手 日本語話せる 良い人!
11.
11 国内研修の実情 • 基本は2名ずつ実施 • 現在3期目(2名受入中) •
帰国した4名中1名退職 • 日本語能力は向上 • (なんちゃって)OJT • (たまに)研修実施
12.
12 国内研修の実情 • 基本は2名ずつ実施 • 現在3期目(2名受入中) •
帰国した4名中1名退職 • 日本語能力は向上 • (なんちゃって)OJT • (たまに)研修実施 ちゃんと できてない…
14.
14 ラボセンター といっても、実際は オフショア開発が 主な事業内容。
15.
15 とりあえずやってみた (2013年~2014年)
16.
16 当時の状況 • 体制 • 受入担当:1名(日本人) •
開発チーム:5名(ベトナム人) • 内3名はハノイ勤務 • 内2名は東京勤務(研修中) • 開発対象 • 主に社内ツール(KPIツール)
17.
受入担当 リーダー 仕様策定・ 発注・受入 リソース・ タスク管理 ベトナム(ハノイ) GMOベトナムラボセンター体制図 国内
18.
18 問題 多発
19.
19 主な問題点 • 一度のやり取りで期待通りの アウトプットが出てこない • 見積もりの精度が低く、完了 予定が見えない •
95%完了から先が長い • 品質が低い
20.
20 発生した問題に対し 試行錯誤を重ねて 導き出した コンセプト
21.
頑張っても 効果が薄い事を 諦める
22.
一度のやり取りで期待通 りのアウトプットが出て こない
23.
一度のやり取りで期待通 りのアウトプットが出て こない 時間をかけてもっと詳細 な仕様書を準備する
24.
一度のやり取りで期待通 りのアウトプットが出て こない 時間をかけてもっと詳細 な仕様書を準備する
25.
一度のやり取りで期待通 りのアウトプットが出て こない 1度のやり取りでの完成を 諦めた初回ザックリ開発
26.
見積もりの精度が低く、完了 予定が見えない
27.
見積もりの精度が低く、完了 予定が見えない 時間をかけて見積もりの精度 を上げてもらう
28.
見積もりの精度が低く、完了 予定が見えない 時間をかけて見積もりの精度 を上げてもらう
29.
見積もりの精度が低く、完了 予定が見えない 全体見積もりは諦め、ザック リ開発工数だけ見積もっても らい、全体見積もりは完了係 数を使って算出
30.
※完了係数とは、 (リードタイム/ザックリ開発工 数)の平均で算出する係数。 ザックリ開発工数の見積もり日 数に完了係数を掛けることで、 予想完了日を算出できる。
31.
95%完了から先が長い
32.
95%完了から先が長い 再度詳細な指示書を書き、 完成させてもらう
33.
95%完了から先が長い 再度詳細な指示書を書き、 完成させてもらう
34.
95%完了から先が長い オフショア側での完成は 諦め、最後の5%は日本側 で完成させる
35.
品質が低い
36.
品質が低い 自己学習や研修を実施す ることにより各メンバー のスキル向上を目指す
37.
品質が低い 自己学習や研修を実施す ることにより各メンバー のスキル向上を目指す
38.
品質が低い メンバーのスキル向上も 品質も諦める
39.
品質が低い メンバーのスキル向上も 品質も諦める
40.
品質が低い 開発の初期段階から レビューを実施するなど、 レビュー回数を増やす
41.
これら改善施策を 盛り込んだ 開発モデルを 考えてみた。
43.
43 RFCモデルとは
44.
Rough Fill Closing
45.
ベースは リーン開発の カンバン
46.
Doing DoingのステージをRFCに細分化
47.
Rough Fill Closing
48.
48 • ザックリ開発するフェーズ • 7割程度の完成度を目指す •
着手する前にザックリ開発工数を見積もってもらう
49.
Rough Fill Closing
50.
50 • Roughフェーズでのアウトプットの完成度を上げる フェーズ • 9割以上の完成度を目指す
51.
Rough Fill Closing
52.
52 • 完成させるフェーズ • 日本側の受入担当者(エンジニア)が対応する
53.
53 RFCの理想 https://www.flickr.com/photos/emiliokuffer/8359208711/
54.
優先度順に並んだPBI ※Readyな状態(仕様記載済み) PBIを分割したタスク RoughのDoingにかかる日数(R)を見積もる ざっくり開発するフェーズ 7割程度の完成度を目指す アウトプットの完成度を上げるフェーズ 9割以上の完成度を目指す 完成させるフェーズ R Lead Time 完了係数 = Lead
Time / R Lead Time = R × 完了係数 完成したタスク オフショア担当 国内 (受入)担当
55.
• 検査と適応の仕掛け • アウトプット(ソースコー ド)の検査と適応を各フェー ズのレビューで行なう •
レビューを早めに(Roughか ら)多めに(最低2回)実施す ることで、アウトプットの 透明性を維持する
56.
56 RFCの現実 https://www.flickr.com/photos/brian_tomlinson/14678017291/
57.
57 • 多くの前提条件 • 共通言語は日本語であること •
受入担当はコードを理解できるエ ンジニアであること • ソースコードのバージョン管理が適 切に行われていること • チケットベースで成果物をレビュー、 検収できること
58.
58 • 受入担当について • 仕様策定・落し込み、発注、 受入、修正指摘と行う事が 多く、開発メンバーが増え れば増える程負荷も増大 •
受入担当が兼務の場合、 そこがボトルネックになる
59.
59 • 効果について • 開発メンバーが業務に精 通してくる事で受入担当の 負荷が軽減され、その結果 として費用対効果が現れ てくるが、短期プロジェクト では難しい
60.
60 • 費用対効果について • 開発メンバーのコスト:1/3 •
開発期間:約2倍(感覚値) • 受入担当のキャパシティが3名 まで、50%コミットだとトントン • キャパを増やすか、コミット率を 下げるか、期間を短縮しないと 費用対効果が出ない
61.
61 • 今後予定している改善 • 受入担当業務をオフショア 側で行う •
受入担当者育成に注力 • 短期の来日研修も検討
62.
62 まとめ
63.
63 • 現場で発生した問題に対し て試行錯誤した結果、RFC モデルは生まれた • プロセスとしてのRFCモデル は確立されつつある •
しかし、既に現場との乖離も 生まれ始めている…
64.
64 いいんです!
65.
http://www.slideshare.net/kiroh/reintro-scrum-kansumi2013a3/46
66.
ただし、 検査と適応 は必須
67.
結論 どんな開発プロセスを採用 する場合でも、ふりかえり を定期的に実施し、プロセ スの検査と適応を継続的に 行っていくことが重要
69.
次世代システム研究室では エンジニアを募集しています! http://recruit.gmo.jp/engineer/jisedai/
70.
70 ご清聴、ありがとうございました
Download