【Ltech#17】スクラムを利用したアジャイルオフショア開発のとりくみ

2021.06.09 株式会社LIFULL 水野慎也（webエンジニア） スクラムを利用した アジャイルオフショア開発のとりくみ ベトナム・ホーチミンの開発子会社であるLIFULL Tech Vietnam(LFTV)との開発において、スクラムを利用したオフショア開発のためにとり くんだ体制作りや運営の苦労・工夫についてお話しします。 Copyright© LIFULL Co.,Ltd. All Rights Reserved.

1．自己紹介 私についてのおはなしをします 2．LFTVと担当業務の紹介 LFTVとは？何をやっているか？について 目次 3．スクラムを利用したモダンオフショアとは オフショアでのスクラムの体制やそのねらいなど 4．具体的な開発フロー 一般的なスクラムのスプリントイベントに加え、 オフショアならではの工夫している点など 5．工夫・課題等 運用にあたっての改善した工夫や残っている課題など Copyright© LIFULL Co.,Ltd. All Rights Reserved.

自己紹介 水野 慎也(みずの しんや) LIFULL歴 13年目（主にLIFULL HOME'S本体の開発業務に従事した後、不 動産クライアント向けLIFULL HOME'S管理画面の新規開発・改 修などを担当)。 しごと アプリケーションエンジニア・スクラムマスター（駆け出し ） LFTV(ホーチミンにあるLIFULL開発子会社)と一緒に、LIFULLの自 社システム開発やその開発環境整備を推進。 しゅみ ウェイトトレーニング（14年くらい。ガチ勢） 旅行（国内バイクツーリング・海外食べ歩き） 飲酒・外食（下町居酒屋めぐり、宅飲み） 最近はソロキャンプとコーヒーをよくします。 Copyright© LIFULL LIFULL Co.,Ltd. Co.,Ltd. All All Rights Rights Reserved. Reserved. Copyright©

LFTVと担当業務の紹介 LFTVの紹介 LIFULL Tech Vietnam Co.,Ltd. ● LIFULLグループ会社 ● ベトナム・ホーチミン所在 ● 社員数60人くらい ● オフショア開発・ラボ型開発・ソフトウェア開発・ アプリケーション開発・クリエイティブ制作 ● LIFULL本社の開発PJの請負業務がメイン ● PJ・部署ごとに契約を結び、スポット〜中長期の開 発業務をLIFULL本社社員と共に担当 Copyright© LIFULL Co.,Ltd. All Rights Reserved.

スクラムを利用した モダンオフショアとは レガシーオフショアの「安かろう悪かろう」のイメージから脱却し、 アジャイル（スクラム）を利用して、日本・オフショア先のフラットな関係を築き、品質の高いモダンオフショアを目指そう。 というものです。 海外の開発会社はコンピュータサイエンスの学位保持者が多く、 現在は依然として低コストと動員力（人員の増減の容易さ）は有効です。 リモートワーク中心の開発になった世の中かと思います。 今まさに、元々リモートでやるしかなかったオフショア開発の優位性が上がっている状況ではないでしょうか。 Copyright© LIFULL Co.,Ltd. All Rights Reserved.

スクラムを利用したモダンオフショアとは スプリントは日本側・ベトナム側の2部制 今回は比較的規模の大きいチーム（日本：4名 ベトナム：10名）での運用体制をご紹介します。 日本チームは企画立案が中心、開発作業はほぼ完全にベトナムチームが担当するスタイルです。 メンバーの役割構成（日本側でも開発を行う等）や人数（小規模・BSE不在等）によって、役割や体制は適宜調整が必要です。 ※少人数であれば1部制の方がコミュニケーションのオーバーヘッドが少ない。ただし通訳を介す・慣れない英語でのやりとりなどで時間がかかりがち 日本チーム：バックログの作成・優先度選択 ベトナムチーム：詳細なバックログの作成 ※仕様策定・レビュー・受入テスト等を担当。 ストーリーレベルのチケット作成やベロシティ計測など ※実作業を担当。ストーリーチケットをもとに実作業粒度にした チケット作成・ストーリーポイント見積もりなど 1. PO：企画メンバー a. b. c. 開発する機能についての決定の責任を持つ バックログの優先度の選定 受け入れテスト 2. SM：リーダーエンジニア a. b. c. スクラム全体の円滑な運営に責任を持つ 開発に関する障壁の除外（開発環境や仕様に ついて等の問題解決） (受け入れレビュー) 3. 開発メンバー：代理PO（ブリッジSE） a. b. 開発メンバーの代表として状況を報告・相談 ストーリー単位のチケットを作業単位に分割 1. 代理PO：ブリッジSE a. 1. SM：リーダーエンジニア等 a. b. c. PPOやメンバーのサポート ベトナム側スクラムの運営に責任を持つ (レビュー) 1. 開発メンバー a. b. Copyright© LIFULL LIFULL Co.,Ltd. Co.,Ltd. All All Rights Rights Reserved. Reserved. Copyright© 日本側のPOのストーリーについての意図を 理解し、開発メンバーとの橋渡しを行う 具体的な作業レベルのバックログ作成とス トーリーポイント見積もり 実際の開発

具体的な開発フロー 具体的な開発フロー（スクラムイベント） それぞれのスプリントは並行で独立して動き（互いにとってブラックボックス）、両チームに在籍するブリッジSEが間を取り持ち ます。私のチームでは1スプリント1週間とし、各MTGは1時間程度（デイリースクラムは15〜30分）で運用中です。 日程 日本チーム ベトナムチーム スプリント開始日 ● スプリントプランニング ● スプリントプランニング スプリント期中 （毎日） ● デイリースクラム(ベトナムの進捗共有・相談 事の解決) ● デイリースクラム(開発メンバーの進捗確認・相 談) ● ● ● ブリッジSEとの1on1 バックログリファインメント ストーリーの仕様・受入条件の設定と説明（ プレ・スプリントプランニング） ● プレ・スプリントプランニング ○ ストーリーの仕様・受入条件説明を受ける ○ バックログ（ストーリー）チケットを元に 実作業レベルのチケットを作成 ○ プランニングポーカー（工数見積もり） ● スプリントレビュー・レトロスペクティブ ● スプリントレビュー・レトロスペクティブ スプリント期中 スプリント終了日 Copyright© LIFULL Co.,Ltd. All Rights Reserved.

具体的な開発フロー メリット・デメリット メリット ● 両チームが母国語でレトロスペクティブができる。（英語などでやると細かいニュアンスや主張が難しくなる) ● 従来型のオフショア開発より共創を促すことができる。（by Classmethod, Inc. Arata Fujimura） ○ BSEが代理のPOとして開発メンバーに「こうしてください」というhowだけでなく「なぜこうしたいのか」のwhyまで 伝えることによって、開発メンバーからの提案も得やすくなります。 デメリット ● スプリントのチケット管理が二重管理になる（日本とベトナムのスプリントボードが二箇所に分かれる） ○ ただし、私のチームでは実装・企画立案の分業ができているので、実装のベロシティを見たいときはベトナム側・全 体の進捗確認や企画立案のベロシティを見たいときは日本側、と見る場所を分けられています。そのためさほど二重 管理にはなっていません。（ストーリーチケットの転記の手間くらい） ● 日本チームエンジニアorベトナムチームBSEがボトルネックになりがち ○ 複数の機能開発が並行しているので、通常1人であることが多い日本側のレビュアエンジニア、ベトナム側BSEに業務 が集中しがち（※ これは2部制に限らないオフショア開発全体の課題ですが） ○ いかにこれらへの負荷を分散するかがポイントになります Copyright© LIFULL Co.,Ltd. All Rights Reserved.

工夫・課題等 細かい工夫 3月から2ヶ月少々（12スプリント）ほど運用し、振り返りを行って出てきた問題を改善した工夫などをご紹介します。 1 スクラムマスター・BSEの定期1on1 ベトナム側スプリントの問題を検知しづらい体制のため、 雑談を兼ねた定期的な相談の場を設けています。 ベトナム側の自主的な改善のチャレンジを聴けたりも。 2 デイリースクラムでの雑談 リモートワーク全体の問題としてチーム間のコミュニケー ションが不足するので、毎朝の雑談の機会も設けています 。 Copyright© LIFULL Co.,Ltd. All Rights Reserved. 出てきて解決した内容 ● BSEに集中したスケジュール管理分散 ● BSEのテスト仕様書レビューの負荷軽減 ● 多すぎたMTGの整理 ● スプリントプランニングの準備タイミング調整 … 毎日のデイリースクラム15min+雑談15min 日本側メンバーがあまり素顔を知らないベトナムメン バーのキャラとかをBSEが紹介したり。 ベトナムの人の名前って漢字由来のポジティブな意味 があるんですよ。Đức （徳）、Hiền （優しい）

工夫・課題等 3 開発ドキュメントの整備 弊社の開発ドキュメントのフォーマットが「企画の人が見 たい情報（企画書）」と「開発する人が見たい情報（仕様 企画書：開発する機能の意図を説明する →BSEが読む。 仕様書：開発する機能の詳細を説明 →開発メンバーが読む。こちらだけを翻訳すればok。 書）」とがごっちゃで辛かったので整備しました。 4 LFTVにシニアSE（日本人）配属 日本チームのエンジニア(兼スクラムマスター)の負荷分散の ため、弊社サービスのドメイン知識を持つ日本人エンジニ アにレビューや技術指導のサポートをしてもらっています 従来のオフショア開発を行う中から感じていたボト ルネックだったため、解消アイデアをLFTVボードメ ンバーと相談し、業務委託開発者をLFTV側で雇用し ていただき導入しました。 。 5 厳密なリリース日があるタスクの管理 全てのタスクのリリース日を厳密に守ろうとしすぎてスケジ ュール管理で疲弊。 リリース日が厳密なもの（社外告知している、他PJとの順番 がある等）のみを登録してデイリースクラムで確認。 Copyright© LIFULL Co.,Ltd. All Rights Reserved. あくまでリリース日ではなく、残ったストーリーポイ ントをベロシティで測って達成の見通しを立てる。 リリース日を気にしすぎるとなんちゃってアジャイル ウォーターフォールになりがち。

残された課題 残された課題 課題 概要 取り組み案 ベトナムチームの問題を本当に解決しきれて いるのか？ BSEとの1on1は実施しているが、チーム全体の問題は ベトナム側のレトロスペクティブを確認 発見・解決できているだろうか？ する。 リリース日の概念について誤解なく伝えられ ていない 「アジャイルはリリース日が決められないもの」と 考え方の浸透。スクラム勉強会。 ストーリーポイントの見積もりがメチャムズ チーム立ち上げからしばらくは日本チームの パワーが非常にかかる いうイメージになってしまっている。 レガシーなシステムを取り扱っているので、メンバ スケジュールの合意をステークホルダー ーが皆詳しくない・思わぬ地雷が埋まっていて見積 ととっておく。ベロシティ計測などでズ もりからよくずれる。 レに対する知見を得る。 レビューでのドメイン知識、設計思想、実装のお作 最初はがんばるしかない？ 法、環境構築のフォローなどが最初に必要。 ※ただし業務委託開発等でも同じ問題は発生します 。 体制が変わると適用できない部分も多い Copyright© LIFULL Co.,Ltd. All Rights Reserved. 日本側エンジニア0人体制は現状無理そう。このやり 社内で様々なパターンでのスクラム開発 方は単発・小規模の開発プロジェクトなどには向か が取り組まれているので、ベストプラク ない。 ティスを蓄積。

ご清聴ありがとうございました Copyright© LIFULL Co.,Ltd. All Rights Reserved.