2020.07.08

ベトナムダナン開発チームを急速に立ち上げた話

Pocket

はじめに

こんにちは。次世代システム研究室のT.Tです。

今年に入り、ここ数年携わっている開発プロジェクトで大きめの開発体制の変更があり、半年程経て新しい開発体制が形になり始めました。主な変更点としてはベトナムのダナン拠点の開発チームによる開発を主体とした開発体制となった点です。この半年間で開発体制を軌道に乗せるために取り組んだ内容と成果をご紹介したいと思います。

目次

  1. 成果と取り組みの概要
  2. 背景
  3. ダナンチームの状況
  4. 体制変更の方針
  5. 各段階での指針
  6. 各段階でのフィードバックの内容
  7. 改善結果
  8. 今後の課題
  9. ベトナムコミュニケーション
  10. まとめ

成果と取り組みの概要

成果としては、次世代システム研究室のメンバーを主体として開発していたプロジェクトの開発体制を、約半年でダナン拠点の開発チームを主体とした開発体制に変遷できたことです。効果が高かった取り組みとしては以下の点だったかと思います。

  • 品質と期限に対するダナン拠点の開発チームの意識付け
  • アプリケーション開発への集中
  • タスク単位での詳細なフィードバック

この部分に焦点を当てながら進めていきたいと思います。

背景

次世代システム研究室では東京とベトナムでのオフショア開発体制の展開を進めていて、ベトナムにはそのためのベトナムラボという研究開発拠点があり現在ハノイ、ホーチミン、ダナンの3拠点があります。ダナン拠点自体は2年前に設立されましたが、昨年の頭くらいにようやく新しいメンバーの採用が決まり、4月頃からダナン拠点で開発チームが立ち上がりました。若いメンバーが多く開発経験も浅いこともあり、昨年の一年間は次世代システム研究室のメンバーが開発の主体となりアプリケーション開発やサーバー構成管理を担当して、ダナン拠点ではバックエンドや運用ツールの開発、フロントエンド周りのバグ修正等を主に担当していました。しばらくその体制を見据えていたのでダナン拠点の各メンバーが次世代システム研究室メンバーと直接やりとりをして業務を進めて、それぞれが業務を通じて技術力と日本語力を向上させながら業務範囲を広げて行く体制を取っていました。

しかし、開発体制の変更でそれまで主体として開発していた次世代システム研究室側のメンバーが半分くらいになることになり、実際にはその体制は一年も経たずに変更することとなりました。そのためアプリケーション開発やサーバー構成管理をあまり経験できていない状態でダナン拠点のメンバーを主体とした開発体制に移行することになりました。

ダナンチームの状況

体制変更前でもダナンチームでアプリケーション開発やサーバー構成管理を担当する体制案は検討したことがあり、それに関連した業務を担当してもらう機会が何度かありました。その際は図のような体制で進めていました。事業主体となる事業部から次世代システム研究室が開発の依頼を受けて、各次世代システム研究室メンバーがダナンチームに設計開発を依頼して、その開発成果物を受け入れてリリースする体制です。

旧開発体制
この体制で進めてみたもののうまく軌道に乗らないところがあり、開発の主要部分の担当を任せることができないまま今年の開発体制変更を迎えたわけですが、その要因は以下のようなものでした。

  • 次世代システム研究室側での再テストが必要
  • ダナンチームからの完了報告時点からの差戻しや手戻りが多い
  • 本番環境に適用するために考慮が足りない部分は次世代システム研究室側で対応が必要
  • 期限内にリリースできない

ハノイ拠点の立ち上げ時期にも同じような問題は起きていてましたが、前任者を中心に継続的な改善を続けてそういった問題は解消されて、ホーチミン拠点にもノウハウが引き継がれて来ていました。他拠点と比較してダナンチームのどこに問題があるのかはっきりと分からないので、うまくいっていない部分を洗い出しつつ改善を進めることにしました。

他拠点の取り組みは以下参照。
ベトナムとのオフショア開発ではRFCモデルがフィットした話
ベトナムオフショア開発 – “期限”への意識
ベトナムオフショア開発 – スピードと品質の改善
ベトナム拠点との共同開発

体制変更の方針

アプリケーション開発への集中

今までの開発体制が軌道に乗らない要因はサーバー構成管理のタスクで特に顕著だったため、ダナンチームではアプリケーション開発部分にだけ集中して担当してもらう体制にしました。

段階的なアプローチ

元々は各メンバーが技術力と日本語力を向上させて各々がブリッジエンジニア兼開発エンジニアとして共同開発できる体制を目指していましたが、体制変更時点では大分ギャップが大きかったため、いったん役割を分担したチーム体制を目指すことにしました。ここで目指す体制は図の4段階目のものですが、それまでの開発チームの状況から判断すると、最初からその体制で始めても次世代システム研究室側メンバーが半分くらいになった状態をカバーできる体制は立ち上がらないだろうと思い、図の1段階目から段階的に体制を移行していくことにしました。

新開発体制
狙いはダナンチームに品質と期限に責任を持てるようになってもらい、リリースフローから次世代システム研究室側メンバーの工数を減らすことでダナンチームとプロジェクトチームとしての生産性を上げることです。

役割分担

最終的な開発体制を目指すために、ダナンチームに依頼したタスクの品質と期限に責任を持つブリッジエンジニアとテックリードを一人ずつ担当してもらうことにし、ブリッジエンジニアは機能の仕様面で齟齬がないこととタスクの期限について責任を持ち、テックリードは仕様通りにアプリケーションが実装されていることについて責任を持つ分担にしました。ブリッジエンジニアには拠点の立ち上げメンバーでダナン拠点のマネージャー、テックリードには去年の業務内容で技術力の成長性が高く業務への取り組み姿勢が最も良いと判断したメンバーを一人アサインしました。

段階の移行方針

各段階に指針の基準を達成するための期間の目安は設けましたが、達成できるまでは次の段階には移行しない方針で進めました。次の段階に移行するタイミングで前段階の反省点と次の段階での行動目標をブリッジエンジニアとテックリードの人に改めて伝えてから次の段階に移行しました。

各段階での指針

第1段階

期限に責任を持つ
  • 期限内に完了させるように自分から行動する
    • 細かく分割されたタスクを期限内に完了させる
    • 期限内に完了できるように適切なタイミングで質問する
    • 期限内に完了できない場合は、そのことが分かった時点で報告する
この段階では1時間から4時間の短いタイムボックスに収まるようにタスクを細かく分割して、どうすれば時間内に完了できるかを考えながら進めてもらいました。

第2段階

仕様と期限に責任を持つ
  • 適切な仕様で実装できるように自分から行動する
    • 仕様が不明な状態で実装を進めない
    • 仕様で不明な箇所は早い段階で質問する
  • 期限内に完了させるように自分から行動する
    • 次世代システム研究室ではタスクの最終期限以外は管理しない
    • ダナンチームでの開発中は聞かれた時に質問に回答するだけ(最初に伝えた仕様から変更がある場合は次世代システム研究室から伝える)
    • 次世代システム研究室でリリース前にテスト結果の確認をして動作テストもする

第3段階

チーム全体で仕様と期限に責任を持つ
  • チームメンバー全員が仕様と期限に責任を持つ
    • 仕様と期限についてはブリッジエンジニアが全体責任者(他担当者分含む)
    • バグをなくしたり非機能要件部分はテックリードが全体責任者(他担当者分含む)
  • 適切な仕様で実装できるように自分から行動する
    • 次世代システム研究室でリリース前にテスト結果だけ確認する
    • 期限内に完了させるように自分から行動する

第4段階

ダナンチームだけで本番環境にリリースできる
  • 本番環境にリリースする
    • ダナンチームがリリースの判断基準を持ち、事業部に確認して承認を得る
    • リリース後に発生する問題はダナンチームが発見して解決する

各段階でのフィードバックの内容

各段階ではその段階ごとの指針を達成するために改善して欲しい部分を主にフィードバックしました。実際に伝えたフィードバックは業務の進め方やタスクごとの設計や実装、テスト結果への指摘等ですが、正しい仕様で実装して期限内に完了させるためにフィードバックしたものだけ抜粋します。

第1段階

  • 期限を決めていない
    • 先に期限を決めてどうすれば期限内に完了できるか考えながら進める
  • 状況の共有が遅い
    • 期限内に完了できないことが分かったらその時点で連絡する
    • 駄目な例: 2時間の見積もりでアサインしたタスクに対して「2時間後に初めて質問する」、「途中に何の連絡もなく4時間後に完了させて報告する」
  • タスクの進め方
    • 調査1 => 修正1 => 調査2 => 修正2

      調査1、調査2 => 修正1、修正2
      下の進め方がより全体の進み具合を把握しやすい、期限内に完了させやすい
  • タスクの内容を理解していないか読まずに進めている
    • 読んであまり理解できなかったので他の人に聞いて理解してから進める => OK
      読んだが理解できていないまま進める => NG
      何が書いてあるか全然理解できないので読まずに進める => NG
  • バッチジョブのパフォーマンス計測の報告内容が曖昧
    • 処理時間の結果は「早い、遅い、時間が掛かる」ではなく1秒、1分、1時間等の具体的な時間を伝える
  • 依頼された内容より多く対応している
    • 手戻りが発生する危険性を減らすため一部分だけ設計と実装をして、方針を確認してから進めるようにしたかったが全体的な実装まで進めていた

第2段階

  • 影響範囲を考慮する
    • 機能追加した影響で既存の機能でエラーが発生したので影響範囲を考慮する
  • 実装方針の事前確認がなかった
    • 実装方針の事前確認がなかったので再実装が発生した
    • (大きく異なる)実装方針がいくつかある場合は事前に確認する
  • リリース予定日は変えないようにスケジュールする
    • 事業部側に伝えるリリース予定日は事業部以外の他のグループ会社のサービスにも影響を与える可能性があるので一度決めたリリース予定日は変えないようにする
    • リリース日程にはある程度余裕を持たせる

第3段階

  • 依頼者への確認依頼が遅い
    • 事前にミーティング等で仕様確認していても実装完了した時点で仕様に齟齬があることが頻繁にあるので早めに確認してもらう
  • 開発完了日とリリース予定日の認識がずれている
    • リリース予定日に次世代システム研究室側のレビューと事業部側の確認、追加の修正作業が発生して予定より遅れた

第4段階

  • 大きなタスクは分割して対応を進める
    • 見積もりも難しい場合は範囲を小さくして実際に進めてから全体を見積もる
    • 効果が大きそうなところだけ対応する
  • 安全なリリース計画を立てる
    • 影響範囲が大きい場合に分割してリリースできる場合は分割してリリースする
    • 影響範囲が大きくて分割もできない場合は先にプレ本番環境(*)で確認する

* 本番環境と同じデータで確認できる開発者用の環境(ステージング環境もありどのタスクもステージング環境で動作確認はしているがサーバー構成やデータが本番環境とは少し異なっている)

改善結果

次世代システム研究室メンバーが減る前の旧体制、新体制の前半と後半をそれぞれ2ヶ月間で比較した際の平均ベロシティの状況は次の表のようになりました。旧体制の平均ベロシティを100%としています。前半後半ともに目標値を超える平均ベロシティを達成できました。前半後半共に開始時点では達成できないくらいの数値を目標にしていて、それを超える水準で達成できたのでチーム全体としてとても良いパフォーマンスが発揮できたと思います。

旧体制 新体制前半 新体制後半
平均ベロシティ実績 100% 60% 94%
平均ベロシティ目標 48% 90%

新体制のベロシティは次の図のように推移しました。


スプリント47以降が後半部分に当たりますが、コミットした業務量を達成できているのと安定して高いベロシティが維持できるようになっています。

開発段階の各期間やタスクの依頼経路は実際には計画していたような綺麗な形での移行は進められませんでしたが、幸い各段階での指針に基づいて業務を進めてもらい、うまくいかなかった部分について期待している行動内容をフィードバックして改善を進めるための機会は十分に得られました。

ダナン拠点と事業部でやり取りをする場合は自分が間に入っていましたが、第3段階の途中からダナン拠点のブリッジエンジニアから受け取る内容がそのまま事業部側に伝えても問題ない感じになってきたので、事業部と直接やり取りする形に変えてみました。その後もやり取りの内容は自分も確認していつでもフォローできるようにしてはいましたが、実際にはほとんど問題なくやり取りを進めることができていました。事業部と直接やり取りするのは第4段階より後の体制として考えていたので大分前倒しで実現できたことになります。

また、ダナンチームで開発フローを主体的に進める部分も順調に立ち上がり、第3段階の途中でダナンチームでテストが完了した時点での手戻りもほとんどなくなり、本番環境へのリリースまでダナンチームで主導する体制も前倒しで実現できました。

今後の課題

アプリケーション開発をダナンチームで品質を上げて期限内にリリースする体制は、体制案を前倒しで実現できた部分もあり予想以上に早く立ち上がりました。今後はアプリケーション開発に加えてサーバー構成の変更までできる体制を整えていきたいと考えています。その体制を実現するには以下のような課題が残っています。
  • メンバーによってはタスクを抱え込んで期限を超過することがある
  • 次世代システム研究室側のレビュー待ちや事業部での仕様確認待ち等でタスクを並行して進める状況になるとそれぞれのタスクがなかなか完了できない
  • サーバー構成を変更するためのメンバーのスキルアップや実務を担当する機会が必要

ベトナムコミュニケーション

次世代システム研究室での開発業務はベトナム拠点との共同開発体制で進めることが多く、主要な部分を任せることも多いのですが、遠隔地で業務を進めるためコミュニケーションも大事な要素になってきます。チームの立ち上げにも影響している部分もあると思うので個人的に取り組んでいることを紹介したいと思います。

ベトナム語を勉強してみる

以前会社の出張でベトナムに出張する機会があり、挨拶と自己紹介くらいできるようになろうと思って、出張する少し前から勉強を始めてそろそろ3年くらい経ちます。言語的には声調があることや語形変化がないところが特徴的だと思いますが、以前は漢字が使われていたこともあり漢越語に分類されているものには日本語に似ているものもあり親しみやすい側面もあります。発音が北部と南部で違い、中部とか他の地域でもまた違ってくるようですが北部のものが標準語のようなので北部基準で学んでいます。

普段はベトナムの小学校の教科書を読んだりYoutubeでベトナム語の動画を見たり、ベトナムラボのメンバーとベトナム語でチャットしたりして勉強しています。チャットで間違っていたり、勉強していて分からないところがあるとベトナムラボのメンバーが教えてくれます。

ベトナム語を話してみる

半年くらい勉強した頃にベトナム語を話して通じるか試してみたくなったので、酔っ払いながら来日していたベトナムラボのメンバーと会話してみました。その時はこんな評価を得ました。
  • P先生「ベトナム語の発音を習得するには3年掛かります」
  • Đさん「宇宙語みたい」
  • T先生「ベトナム人が話しているのを聞いたことがありますか」
ベトナム語の道のりは険しいです。

ベトナムに行ってみる

昨年のゴールデンウィークに旅行でベトナムに行きました。出張した時はダナン拠点がまだなく中部にはまだ行けていなかったので中部を中心に周る計画にしました。事前にベトナムラボのメンバーの何人かに旅行で行くことを伝えて日程が合うメンバーとも一緒に旅行に行きました。

ゴールデンウィーク期間はベトナムも連休が重なります。その期間中は中部を周る計画で4日半くらい滞在する計画でしたが、P先生は滞在期間中を通して一緒に行動してくれて観光地や夜の街、現地の人しか行かないようなビーチ等色々なところに連れて行ってくれました。ありがたや。

次はハロン湾に行くために飛行機でハノイに向かいましたが、搭乗日はベトナムの平日だったので挨拶を兼ねてダナンのオフィスに寄りました。まだ直接会ったことがないメンバーもいたので少し会話してからオフィスを出て飛行機に乗りました。

それからハノイのオフィスにも顔を出して、1年半ぶりくらいにハノイ拠点のメンバーと再会しました。皆さん変わらず元気そうで何よりです。就業時間が終わるのを待ってT先生やĐさんらと飲みに行きました。そうです。このために寄りました。

楽しく飲んで騒いだのでそろそろ寝所に移動します。Đさんのご好意でバイクの送迎付きで自宅に泊めてもらいました。至れり尽くせりです。

飲み会の時にベトナムラボの副社長に明日ハノイメンバーで昼食を食べに行くから一緒に食べに行こうと誘われたので、ハノイを周遊する合間にまたハノイオフィスに寄りました。ハノイの別のグループ会社の女性も一緒に来ていて、日本語で会話していましたがベトナム語を勉強しているという話をしたら、ベトナム語を聞き取れるか試してみようということになり少し話してもらいました。何人か話してもらいましたが、一人だけちゃんと聞き取れました。全員北部の発音でしたがどうやらハノイ育ちの人の発音だけ聞き取れるようです。大してベトナム語が使えないことが分かったのでまた日本語に戻りました。

あくる日に最後の目的地のハロン湾に向かいました。週末の日程に合わせてT先生が諸々旅行の手配をしてくれました。T先生も同行してくれるので現地人向けのプランでも安心して行けます。ハロン湾では湾内を船やカヌーで周遊して奇岩を観て周ったり、鍾乳洞に入ったりして壮大な自然の景観が楽しめました。こうしてベトナム旅行は無事完了しました。感無量です。


ベトナム留学 with コロナ

日本でZoom飲み会をやっているという話がベトナムラボのメンバーにも伝わり、普段ベトナム語でチャットしているメンバーでZoom飲み会をやってみようという話になり一回やってみました。

最初の30分くらいは日本語で近況とかを話しました。頃合いになってきたので、チャットで今ならベトナム語が通じると思うと豪語していたのを受けて、懲りずにベトナム語で会話してみました。お題は自己紹介になりましたが、今更用意してもいなかったので少し考えながら話しました。結局3フレーズくらいしか話せませんでしたが、発音はちゃんと聞き取ってもらえたようです。少し成長しました。

その後1時間半くらい雑談していました。ベトナム語での雑談は聞き取るのが難しいです。ところどころ聞き取れますが全体としては何を言っているのか分かりません。日本語で話してくれると助かりますが大半ベトナム語で会話していたのでほとんど分からないまま傍聴していました。まだまだ修行が必要です。

時間が来たので解散になりましたが、締まり際に「今後はちゃんと自己紹介してくださいね」と結局叱られてしまいました。

まとめ

ベトナムは楽しい国ですね。機会があればまた行ってみたいです。あ、話が逸れ過ぎました。

今回ダナンチームの立ち上げに大きく寄与した改善点は、品質と期限へのダナンチームの意識を高める部分だったかと思います。他拠点の立ち上げ時点でも最初に取り組んでいた部分ですが、チームに対する期待値が高いとこういった基本的な部分が盲点になりがちなのかもしれません。また、比較的ダナンチームが得意領域だったアプリケーション開発に集中したことで、品質面で注力するべき部分が限定されて早期の立ち上げが実現できたと思います。あとはタスク完了後にここまで考慮して対応して欲しかったというフィードバックを詳細に伝えたところも効果があったと思います。ダナンチームのメンバーが何ができて何ができていないのかを洗い出しながら進めたため、各タスクの開始前には大まかな方針しか伝えられませんでしたが、タスク完了した時点ではある程度明らかになっているので改善策として伝えることができました。

こうした取り組みを2ヶ月程続けた辺りから、受け入れ時点の手戻りやテストで不具合が見つかることが大分少なくなり、その結果本番環境にリリースしたり事業部と直接やり取りをしてもらったりといった権限委譲的なところにも円滑に移行できた感じでした。

今後は次世代システム研究室側とDevOpsチームを組んだり、自律的な組織を目指して行きたいと考えていますが、まだサーバー構成やサーバー運用についての知識や経験が不足している状況なので、引き続き次世代システム研究室側でスキルアップを支援しながらより強い体制を目指していきたいと思います。

次世代システム研究室では、アプリケーション開発や設計を行うアーキテクトを募集しています。ダナン拠点との共同開発や新設された大阪拠点での研究開発チームの立ち上げにご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。

皆さんのご応募をお待ちしています。