1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Xin chào! :flag_vn: こんにちは!:flag_jp:
ポーラ・オルビスホールディングスのITプロダクト開発チームで、スクラムマスターを務めている川田です。

以前に別の記事でご紹介したように、私たちはベトナムのオフショアチームと一緒に開発を進めています。(冒頭のXin chàoはベトナム語でこんにちは、の意味です:sunglasses:

言語・文化の違いや時差がある中で、オフショア開発を実践してみて大事だなと感じたポイントや工夫していることをご紹介します!

オフショアとスクラム開発

スクラム開発を進めるうえで困ったことがあったとき、私は「スクラム現場ガイド」という書籍をよく参照します。(マイナビ出版、Mitch Lacey著、安井力・近藤寛喜・原田騎郎 訳、ISBN:978-4-8399-5199-3)

こちらの書籍の「第4部 上級サバイバルテクニック」の「28章 アウトソースとオフショア」では、以下のように記されています。

オフショアへのアウトソースは、どんな手法でも難しいものだ。とりわけアジャイルなプラクティス、たとえばペアプログラミングやコアタイム、デイリースタンドアップを考えれば、アジャイルとアウトソースの組み合わせは込み入ったものとなるし、ある意味で高価に付く。

この書籍は2016年に発売されたものですが、コロナ渦を経て世の中の状況は大きく変わりました。リモートで業務を進めるための技術・サービス・プロセスが整備され、以前よりはオフショア開発のハードルが下がっているのではないでしょうか。それでも、オフショアチームと一緒にスクラムを組み、アジリティ高くプロダクトをリリースするためには工夫が必要です:rugby_football::rugby_football::rugby_football:

適切なアウトソース先(国)を選択する

そもそも論として、アジャイル開発に適したアウトソース先を選択することが重要です。システム運用をアウトソースする場合であれば、あえて時差の大きな国を選ぶことでお互いが夜間になる時間帯をカバーし合うことができます。一方で、ソフトウェア開発においては時差が少ないほどコミュニケーションの効率がよいです。ちょっとした質問の回答や作業の依頼を行うのに、時差によって1日かかってしまうのはもったいないですよね。日本におけるソフトウェア開発のアウトソース先としてベトナム・フィリピン・インドの人気が高い理由の1つはここにあると考えています。

タスクの振り分け

ウォーターフォール開発であれば、実装フェーズやQAをまとめてアウトソースする手段が取れると思います。アジャイル開発ではプログラマーやテスターといった限定したロールのメンバーを置くことは基本的にしないので、一貫した機能(ユーザーストーリー)をどのように振り分けるかを考える必要があります。私たちのチームでは、特に以下のポイントを考慮してタスクの振り分けを行っています。

  • 期限の長さ(緊急度)
  • 要件や実現方法が明確かどうか

スクラムにおいてはWIP(Work In Progress、仕掛中のタスク)が無くなった時点でスプリントバックログの上から順番にタスクを取れば、振り分けは必要ないのではと思われるかもしれません。しかしながらタスクの性質に応じてざっくり振り分け、オンショアとオフショアそれぞれのチームで自立的にタスクを進められる方が全体としてアジリティは高くなります。スクラムチームが2つあって、共通のバックログとコードベースを用いて協調しながら業務を進めるイメージですが、片方のチームがもう一方のサブチームとなるのではなく、対等な関係性の自立したチームとして体制を整えることができるならアジャイル開発においてオフショアを活用できる可能性は十分にあると思います:thumbsup:

必ず実施するスクラムイベント

スプリントの中で実施するスクラムイベントはオンショアとオフショアの両チームで一緒に実施することが理想ですが、言語の違いもあり、出席するよりは開発を進めた方が良いのではと感じることもあるでしょう。スクラムイベントに出席するだけが目的になっているのであればやめるべきですが、チーム毎にイベントを開催することで言語を気にすることなく効率的に機能する可能性が高いため、省略せずに必ず実施した方が良いものがあります。それがデイリースクラムとスプリントレトロスペクティブです。
デイリースクラムはスプリントゴールに対する検査と適応を行う場なので重要であることは明白ですが、オフショア開発を活用するうえでは開発プロセスに対する検査と適応を行う場であるスプリントレトロスペクティブが特に重要であると感じています。オンショアとオフショアそれぞれのチーム内でのプロセスはもちろんのこと、チーム間のコミュニケーションとコラボレーションにも着目し、双方の視点で検査します。また、振り返った内容をお互いに共有することでチームの状況、考え方、文化を理解・尊重し、同じプロダクトを作るうえでベストな開発プロセスを一緒に考えていくことが重要です:two_men_holding_hands::two_women_holding_hands:

ブリッジSEの重要性

スクラムイベントを進める上で、そして日々の細かなコミュニケーションにおいても、オフショア開発におけるブリッジSEの役割は非常に重要です。オンショアとオフショアチーム間で共通言語を用いてコミュニケーションが取れたとしても、異なる考え方や文化、細かいニュアンスの違いをうまく橋渡しする調整役が必要です。ブリッジSEを通してオンショアとオフショアが一体となり、ワンチームになれるかどうかがアジャイル開発におけるオフショア活用の成功のカギ:key:であると感じます。
また、ブリッジSEに求められる能力はアジャイル開発だからといって特別な内容はありません。アジャイル開発の特性を活かし、個人の対話や顧客との協調を優れたコミュニケーション能力で支えること、そして変化へ迅速に対応する柔軟性と適応力が特に重要です。

最後に

最初から開発体制を整えることが難しく、オフショア開発の利用を検討するケースは少なくないと思います。昨今で人気のアウトソース先は国をあげてITに力を入れているためエンジニアのレベルも高く、アジャイル開発の経験があるメンバーも増えています。
私たちの取り組みが皆さんのオフショア活用の参考になれば幸いです!:smiley:

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?