Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
2つの300人日案件をオフショア開発した体験談
Search
aketada
May 19, 2021
270
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
2つの300人日案件をオフショア開発した体験談
aketada
May 19, 2021
More Decks by aketada
See All by aketada
多拠点開発の生産性を飛躍的に向上させるプロジェクト管理手法
aketada
1
2k
設計レビューのコツと心構え
aketada
0
21k
Quality First & Fastを実現するオフショア開発のポイント9選
aketada
1
2.1k
Featured
See All Featured
Information Architects: The Missing Link in Design Systems
soysaucechin
0
970
Code Reviewing Like a Champion
maltzj
528
40k
Producing Creativity
orderedlist
PRO
348
40k
Prompt Engineering for Job Search
mfonobong
0
340
How Software Deployment tools have changed in the past 20 years
geshan
0
34k
Accessibility Awareness
sabderemane
1
140
Noah Learner - AI + Me: how we built a GSC Bulk Export data pipeline
techseoconnect
PRO
0
200
<Decoding/> the Language of Devs - We Love SEO 2024
nikkihalliwell
1
240
How STYLIGHT went responsive
nonsquared
100
6.2k
Stewardship and Sustainability of Urban and Community Forests
pwiseman
0
220
AI Search: Where Are We & What Can We Do About It?
aleyda
0
7.6k
職位にかかわらず全員がリーダーシップを発揮するチーム作り / Building a team where everyone can demonstrate leadership regardless of position
madoxten
62
54k
Transcript
2つの300人日 案件をオフショア開発 した体験談 アウトソーシング TIPS LT会 樋口朱理
樋口 朱理 情報系学部を卒業。 某パッケージベンダーで6年間上流~下流工程を経験。 最後の半年はインド人メンバーを部下に持ち、リーダーとして新規開発に従事。 2019年ラクスに転職し、オフショアを担当。 300人日規模の案件を2件経験。 ベトナム人とチャットでやりとりしながら、日本とベトナムの間に立つのが主な仕事。 休日は酒、犬、子どもに専ら費やしている。 株式会社ラクス
楽楽精算開発2課 オフショアチーム リーダー 自己紹介 2
オフショア開発って? 3
日本 委託先の国 オフショア開発って? 4 • 開発業務を海外企業/現地法人などに委託すること • 人件費が安く労働力が豊富な国が主になっている 中国/インド/ベトナム/ミャンマー/インドネシア などなど
• コミュニケーションのミスや技術力不足による品質などの問題が生じやすい
私が実体験した オフショア開発の 問題点 5
オーダー 6
オーダー 7 カレーください! かしこまりました
受注 8
結果 9
違い 10 ライス 牛肉 スパイシー 鶏肉 さつまいも まろやか バケット みじん切り
たまねぎ 薄切り たまねぎ
仕様の認識齟齬 →結果的に大幅な手戻り 11 オーダーあるある
何が悪かったんだっけ? 曖昧なオーダー • 考えてみて?空気読んで? • 委託先に忖度させるのは事故のもと 「考えてみて」はバクチになってしまう • 日本はハイコンテクスト社会 「空気読んで」は責任放棄
理解が異なる • 「わかりました」は「わかってない」 • 説明不足/不備 • 誰がいつどんな問題をどうしたいんだっけ。 • 情報不足と確認不足 12
まずは発注側が襟を正すこと 13 対処方法
まずは発注側が襟を正すこと オーダーを具体的に • 辛いカレーライスで牛肉メインでたまねぎはみじん切り • GIGO(Garbage-In Garbage-Out) • 目の前の相手は己の「映し鏡」 こまめに細かく確認する
• 「嵐の前の静けさ」 を警戒する • 要求は全部言う 私は帝国ホテル風のビーフカレーライスが食べたい気分なんだ →帝国ホテル風はよくわからないけど、ライスに確定 スパイスたっぷりがいいな→辛いのがいいんだな • 細かく確認する お肉は牛肉で合ってる? →当店は鶏肉です 具材は細かく切ってある? →要望があれば細かく切れます で帝国ホテル風に出来る? →帝国ホテル風って何? 14 とにかくクイックレスポンス • 並行で開発していると手戻りリスクがどんどん増す • 情報鮮度が落ちるとまた学習の時間が必要になる
「考えさせること」、「決めること」を分ける 分からないものは分からない 15 日本のシステムであれば、日本の業務を理解する これには圧倒的情報共有不足 すべての情報を開示できるわけではない 彼らももらった限りある情報の中で考えている よって、決められるものは決める DB設計であれば、エンティティの関連、項目名の意味
16 Tips/あるある
そもそも無意識に期待していることが多い 間の問題が落ちまくる 周囲の影響は考えているものと期待している • 自分が担当じゃないと思ってた • 互いにお見合い状態に →役割を明確にしてグレイゾーンを減らす 17 なかなか納品されない
すぐに納品されると期待している • 期日と優先順位が曖昧 • 急かした結果、品質悪に →WBSをしっかり引く →余裕をもった計画を →急かすのでは、「分ける」 日本の仕様と違う よしなに合わせてくれるものと期待している 2拠点で開発を実施した結果 両者で仕様が合わないことに・・ 「やっぱりこうして」の後出しジャンケンはNG 結果的に • デスマーチにさせてしまう • 不安にさせる →仕様を確認するポイントを設ける 隣燃えてるけど 俺のところじゃないし わかんないけど こっちでいいよね ここは 間に合うと 言っておこう 間に合います!
なんでも言える信頼関係を目指す 18 発注者が本音を開示してこそ、委託先も本音で話す まずは聞き入れる体制をしっかりとること 逐一指導してしまうと、円滑なコミュニケーションの阻害要因になる スケジュールの遅延、バグの発生が発生しても冷静に対処する 返報性の原理 先に自分の内面を開示すると、相手も同じように開示してくれる
まとめ 19 • オーダーは具体的に • とにかくクイックレスポンス • こまめに細かく確認する • 「考えさせること」、「決めること」を分ける
• WBSをしっかり引く • 余裕をもった計画を • 急かすのではなく、「分ける」 • 役割を明確にしてグレイゾーンを減らす • 仕様を確認するポイントを設ける • なんでも言える信頼関係を目指す
ありがとう ございます 20