この記事は アソビュー！ Advent Calendar 2019 - Qiita 21日目の記事です。
アソビューにてバックエンドエンジニアの服部と申します。
今年の夏よりベトナム開発組織 ASOVIEW VIETNAMのCTOに任命され、組織のスケールアップをメインミッションとして日々奮闘してます。
最近はベトナムにくると「帰ってきた...」というホーム感がでるようになってきました、不思議です。
はじめに
オフショア開発を初めてみたはいいが、どこかうまくいってない。
開発は進んでるしリリースもできてるんだけど、人の入れ替わりは多いし
どこか日本と現地で噛み合っていないような。。。
アソビューでは2018年にベトナムにオフショア開発拠点を自社で立ち上げおります。
ベトナム開発拠点の立ち上げから1年。
新規開発系のプロジェクトはうまく回っていたが、エンハンスメント案件系の対応チームがこの問題に直面しており、スケールしづらくなってました。
それを少しだけ改善した話。
ここで説明しないもの
スクラムガイドに記載されている事柄について
なんかうまくいってない
ベトナム開発拠点が立ち上がってちょうど1年たった頃くらいから、
日本のメンバーから下記のような声がよくあがるようになってきました。
もちろん自分も同じように言っていた１人です。
- 依頼通りのものが出てこない
- 各タスクの進捗がわからない
- コード品質が悪い
- プロダクトバックログに積まれたタスクが山ほどあるのにタスクがないと言われる
- PO/決裁権のある人が知らないないものが開発されている
- 数ヶ月で人がすぐ辞めていく
etc...
（これってベトナム組織の問題なの...？というものが多数混ざってますが一旦。）
離職率も上がっているように見え、ベトナム開発組織でなにが起きているのかみんないまいちちゃんと把握できてない状態でした。
ということで、ベトナムに参りました。
何が起きていたか
ベトナムに来て最初やっていたことは、とにかく毎日観察/調査です。
- 日本側と「どのような」やりとりを「どこで」やってるのか
- どんなイベント（朝会/定例等）をやっているのか
- だれがリーダー的なポジションで、だれがコミュニケーションの中心にいるのか
etc...
訪越して2-3週目くらいたってようやく、どうやらベトナム組織単体の課題ではなく、
日本組織にも大いに課題がありそうということが見えてきました。
下記一例ですが、
- 複雑なレポートライン
- 事業をまたがり自由に依頼
- ブリッジエンジニアを通さない依頼
- 不確実性の高いタスク
- 要件定義がきちんとされていないタスク
- POを通さずに要件定義されたタスク
- いろんな人が自由に作ったtodoレベルのタスク
- 何に貢献しているのか説明されていないタスク
- 柔軟すぎる開発体制
- 開発計画のない作業体制
- 作業の振り返りをしていない
- チーム間のメンバー移動がフレキシブルに行われている
もちろんベトナム組織からも下記の不満が出てきていました。
- 案件依頼にルールがない
- タスクをやってもリリース直前で止められる
- タスク完了直前で仕様変更がある
- 事業貢献度がわからない
- 開発の進め方にルールがない
これではベトナム組織も疲弊するのは当然です。
これ、ほとんどスクラム開発で解決できそう
課題としては、日本組織は開発依頼体制が、ベトナム組織は開発受け入れ体制が整備されていないこと。
スクラムガイドラインに則った開発ができるように整備すれば、両方とも解決できそう。
日本組織では2年ほど前よりスクラム開発を導入し、知見も溜まってきております。
採用/教育含めスクラムマスターをベトナムで急遽起用するのは現状難しそうだと判断し、
CTO兼スクラムマスターとしてスクラム開発を数チームに導入し、改善を図ってみることにしました。
スクラム導入の下準備
とはいえ、「スクラム開発やろうぜ！」といって始められるわけではないので下準備（スプリント0の実施）をしていきます。
巻き込まないといけな人が多いので、実際にスプリントを回し始めるより大変です。
ベトナム開発チーム内での準備
ベトナム開発組織のメンバーは全員スクラム開発をやったことがないとのこと。
スクラムガイド にベトナム語訳があったので、1週間以内に読んでくることを依頼。
また、下記を並行で実施しました。
- 日報の提出依頼
- 毎朝、同じ時間に朝会の実施（のちにデイリースクラムに移行）
- スクラムガイドの読み合わせ
- スクラムイベントの簡単なシミュレーション
- タスク管理ツールのルール化
POとの調整
チームの整理および当時のプロダクトバックログや今後のタスクに関してはPOと整理しました。
- チームの整理
- ベトナム開発チームの数/メンバー構成は変えない
- 事業ごとにベトナム開発チームをつけ管理することを合意
- プロダクトバックログの整理
- 不要なもの（個人のtodoや決済権を通ってないタスク）は削除
- 要件定義できていないものはICEBOXへ
- 必要なタスクの作成
- タスクの依頼ルートの整理
- 基本的にPOがタスクを作成する
- POがOKを出した場合のみ、そのタスクに関してのみ代理でスクラムマスターがタスクを作成することができる（これはスクラムガイドに反してますが今回OKとしてます）
- メンバー/サポートからの依頼の吸い上げはPOが参加するミーティングでやるやらを判断する
そしてスクラムへ…
初めてのスクラムイベント
スクラムイベントの初回実施時は、どのチームでも質問責めにあいます。
1つ1つの行動や発言に対して
- なんでやるのか
- 今のはどう言う意味か
- こうした方が効率がいいと思う
いろんな意見が出てきますが、ちゃんと意味を説明し、また初回なので教科書通りにやっていくことを伝えます。
とはいえみんなポジティブで、「スクラム開発やってみたい！だから教えて欲しい！」という姿勢なので、
やりにくさや進めづらさはなかったです。
導入してどうなったか...
課題としてあげた部分に関してはほぼ解消。
また以前は個人プレーが割と多いと感じてましたが、イベントをこなすにつれてチームでゴールを達成するにはどうすればいいか。という良い空気も出てきました。
ここ、さらっと書いてしまっていますがスクラム導入までの整理や調整が本当に大変で、導入後は日々みんなで改善を繰り返していくだけです。
とはいえ、課題はまだまだ
以前よりよくなった！とはいえ開発チームが自走し、かつ組織がスケールしていくには課題がまだまだあります。
日本の遊びをもっと世界に広めたい！、オフショア開発や海外経験してみたい。もしそういうことに興味がある方はぜひ一緒に働いてみませんか？
というわけで、アソビューでは一緒に働ける、世界をワクワクさせたい仲間を募集してます。
hrmos.co
