ヤフーとベトナム拠点の海を越えたスクラム開発の話

皆様、始めまして、Techbase Vietnam でYahoo!ゲーム案件を担当しているディンと申します。 ベトナムホーチミン市にあるヤフーの子会社であるTechbase Vietnam（TBV）は2015年に設立され、ヤフーの約20サービスの開発を担っています。
TBV　ホームページ：　https://www.techbasevn.com/jp/

今回はゲームサービスの開発チームにおける、スクラムの導入についてご紹介します。

スタート当初の課題

2018年8月よりゲームサービスの既存システムを刷新する目的で、TBVでその一部の開発を担当することになりました。ヤフー側はスクラムで開発を進めていましたが、TBV側は当初ウォーターフォールスタイルで開発を進めておりました。チームの技術力が上がり、業務の理解が進んだ結果、品質、開発スピードともに改善できました。結果として、担当業務においてTBVが担当する開発の範囲は詳細設計～結合テストにまで拡大しました。ですが、開発工程全体においては、部分的な貢献に留まっているという課題がありました。

ヤフー側とTBV側の体制は以下でした。

また、ヤフー側では以下の作業が必要で、TBVと仕事をするために「追加」で必要な仕事が多いという課題もありました。

1. 見積もりとスケジュールの確認、毎日の朝会・週次会議で進捗、課題の確認
2. 案件を依頼するための要求資料作成
3. 各工程の成果物（設計、ソースコード、テスト結果）のレビュー

スクラム開発の導入の決定

担当業務の狭さ、ヤフー側管理コストの高さという課題を解決するため、以下の2つが必要であると考えました。

1. プログラム製造がTBVの目的ではなく、ユーザーにサービスを届けることが目的。そのため、TBVの開発チーム主体的になる必要がある（≠言われたことだけを実行するチーム）。開発メンバー全員がWhyを理解しながら、Whatを実行する必要がある。（当時はWhatを指示されるだけだった）
2. Whyを理解するためヤフーの担当者（計画者・プロダクトオーナーと開発メンバー）との距離を縮め、直接コミュニケーションする必要がある

この2つの要求を満たすため、スクラムを導入することにしました。開発だけではなく開発目的を理解し、サービスの価値、事業計画に対して、より貢献することを目標としました。

導入前のトレーニング

スクラムの導入はゲームサービスだけでなく、TBV全体で行われました。TBVで担当している案件の中から、ゲーム案件を含む3案件がスクラム導入のパイロットとして選ばれました。

スクラムのフレームワークを形だけで適用するのは簡単ですが、スクラムで定義されている内容の目的・想定される効果の理解、自己改善力をチームで身につけることは難しいことでした。さらに、TBV側だけではなくヤフー側にも今までのやり方を変更してもらうことが必要です。そのため、ヤフーのアジャイルコーチに、ヤフー側、TBV側の両方に対して、約半年間、コーチング、トレーニングをしてもらいました。

スクラムトレーニングの様子

スクラム導入計画

• ヤフー側から要求をタスクにブレークダウンする代わりに、Product backlog（PBL）で管理する運用に変更
  →受け入れ条件と品質条件を明確化
• 見積もりはチームリーダーがやっていたが、チームメンバーがPlanning pokerによりポイントを見積もりするようにした
  →チームコラボレーションの活性化
• スケジュールはチームリーダーが立てていたが、チームがスプリントプランニングで次のスプリントで実施するPBLを選ぶようにした
  →優先順位の理解
• 開発工程ごとに作成した成果物をヤフー側にレビューしてもらう代わりに、各スプリントで開発した機能を含む動くソフトウエアのデモにより、ヤフー側にレビューしてもらうように変更
  →動くソフトウエアによる確認によりレビューが容易となり、細かくレビューできるため修正対応のコストが小さくなる
• スプリント終了ごとに 振り返り会（レトロスペクティブ）を行い、開発チームメンバーが良いポイント・改善必要ポイントを共有、アクション決定するようにした
  →早いタイミングで課題解決のアクションが取れ、自己改善できるチームに成長できる

Planning pokerはアジャイル開発で工数の見積もりを行う際に使われる手法です。
メンバーがそれぞれ数字が書かれたカードを持ち、見積もりするPBLアイテムに対するポイントを一斉に提示します。 意見が合わないようであれば、ディスカッションをし、その後再度ポイント提示をします。このディスカッションを繰り返すことにより、メンバー間でナレッジの共有や、お互いの理解が進み、チーム力が上がることが期待されます。

発生した課題と、解決のためのアクション

アジャイルコーチの助けを借りながら、スクラム開発への変更を進めていきましたが、進めていく中で課題がいくつもありました。その課題と解決した方法をご紹介します。

オフショアならではの距離や言語のギャップ

2001年に生み出されたアジャイルマニフェスト（アジャイル開発宣言）の中には、顧客とのコラボレーションが大切との記載がありますが、日本とベトナム間でスクラム開発を進めるには地理的、言語的ギャップがありました。

アジャイルマニフェスト
https://agilemanifesto.org/iso/ja/manifesto.html

＜地理的課題の解決＞
ヤフー側のプロダクトオーナー（PO）とTBV開発チームが要求に関する課題を直接相談したり、深く議論したりすることがなかなか難しい状況でした。テレビ会議システムやコミュニケーションツールはもちろんありますが、何かあったらすぐに話しかけるなど、スピーディーにコミュニケーションを取ることは難しかったのです。 これを改善するために、POをTBV側にも任命し、スクラムチームの役割がすべてTBVで完結するようにしました。POは日本語ができる開発メンバーをアサインし、そのメンバーがPBLを定義できるように業務知識強化を行いました。TBV側のPOは開発チームの状況を把握し、PBLを作成し、ヤフー側に報・連・相しました。

POをTBV側にアサインしたことで、以下の効果が出ました。

• スクラムチームの全員が同じ場所（ベトナム）にいるので、コラボレーションしやすく、課題を早めに対応できるようになった
• ヤフー側が参加しなくてよいセレモニー（会議）ができたため、ヤフーメンバーの時間を削減できた

＜言語的課題の解決＞
前述のとおり、コミュニケーションが大切なスクラム開発ですが、日本語とベトナム語の言語の違いで、コミュニケーションをするために時間が掛かってしまう状況でした。例えば、スプリントレビューで開発した成果物をヤフーにデモしますが、開発チームがベトナム語で説明した後で、TBV側のコミュニケーター（通訳者）が日本語に通訳しますので、時間が2倍なりますし、情報量が多すぎると情報をすべて通訳しきれない場合もありました。 改善ポイントとしては、日本語の得意なコミュニケーターが、開発者に代わりデモを実施するように変更しました。コミュニケーターがデモをできるように、開発チームはスプリントレビュー前にコミュニケーターをサポート（業務説明、デモ手順説明、事前練習）するようにしました。結果、以下の成果がでました。

• 通訳の時間がなくなったことでデモの時間が減り、スプリントレビューがスムーズに進むようになって、お互いの理解度も上がった
• （想定外の効果）コミュニケーターの業務知識・技術用語の理解力が上がった
• （想定外の効果）コミュニケーターが開発チームに案件に貢献している気持ちが高まり、やる気が上がった

管理職とスクラム開発チームのコンフリクト

TBVでは一般的な以下のような組織構成になっていました。上司が指示を出すコマンド・コントロール型の組織です。

プロジェクトマネジャー（PM）→チームリーダー→メンバー

ちなみに、ベトナムでは日本以上にコマンド・コントロール型のマネジメントが多く見られます。

そのため、管理職と開発チームで相談をして、スクラムのロールを考慮して以下の体制に変更しました。

• チームリーダーがスクラムマスターを担当し、チームを観察しサポートする
• PMはスクラム導入が成功するようにスクラムマスタ・プロダクトオーナーをサポートし、チームが常により良い形を目指している状態を作るために、アジャイルコーチと連携する

上記のとおり、コマンドとコントロール形式の指示型マネジメントに代わり、チームが自律して業務を遂行できるようにPM、リーダーは仕事の仕方を変えていきました。 ただ、この変更には懸念もありました。従来、品質や進捗の管理のために直接的にメンバーに関わっていたチームリーダーが、スクラムマスターとしてチームの観察・サポートするという立場になることで、責任・権限が小さくなったと感じてやる気が下がってしまったり、逆に開発チームが自分たちの責任が重くなったように感じてプレッシャーを感じたりするのではないかという懸念です。この懸念については、スクラムにおける役割と責任をしっかり全員に説明するとともに、チームの意見もヒアリングしたことで、全員が納得することができました。

プラクティス導入での課題

スクラムフレームワーク導入段階では、いくつかの課題が発生しましたが、一つずつ解決していきました。

• チームのコラボレーションを強化するためにモブプログラミング導入したが、導入直後は一時的に生産性が下がってしまった
  →モブプログラミングの導入で期待できるチームのスキルアップやコラボレーション強化をヤフー側に説明し、理解を得ました。また、全てに対して適用するのではなく、効果的なタスクをスプリントプラニングで決定するようにしました。直後は生産性が下がったものの、モブプログラミングを行うことでチーム全体の知識やスキルが上がり、結果的には生産性は上がっている状態になりました。

• スプリント期間が1週間なのでスプリントで完了できないPBLがあり、品質下がってしまうケースがあった
  →PBLを小さく定義できるようにチームでブレーンストーミングをしたり、レビュー時間を無くすためにモブプログラミングを適用したり、今までリーダーが1人で行っていたテスト業務をチーム全員ができようにしたりなどの工夫をしました。
• 振り返り会であまり意見が出ず、雰囲気が悪くなってしまった
  →チームで共通のメトリックを設定し、振り返り会でこれを評価したり、スクラムマスターがメンバーの発言を促進するために工夫をすることで、チームの雰囲気を良くすることができました。例えば、Fun/Done/Learn手法（※）などは効果的でした。

  Fun/Done/Learn手法 オブジェクト広場より
  https://www.ogis-ri.co.jp/otc/hiroba/others/ActivityPocket/FunDoneLearn.html

最後に

スクラムの導入において、私たちのチームでは、やらされるのではなく、自分たち自身で目標（Vision）を設定し、目標にコミットし、その目標を必ず達成するという決意を持って頑張りました。

◇Vision

• ヤフーとTBVで同じビジョンとゴールを持つ
• さらに高いレベルのパフォーマンスを発揮するため、ヤフーとTBVが真のワンチームとなる（一体感）
• 顧客満足度アンケート85点以上
• ヤフーに納品した後の不具合をなくす
• Cross-functionalなチームになる
• 生産性を向上し、プロダクトをデリバーしたときにすべてのAC（Acceptance Criteria）を満たす
• 自ら課題を見つけ共有するチームになる

まだまだ改善する必要がありますが、ゲームサービス開発チームにおけるスクラム導入は成功したと思います。

スクラム導入後、ヤフー側からコメントをもらいました。

• スプリントレビュー計画をTBVが担当することで、自主性が生まれ、手戻りが少なくなった
• デモでレビューすることによって、各工程の成果物（設計、ソースコード、テスト結果）のレビューが減った
• 開発を依頼する際の資料作成が少なくなった
• 開発を依頼した後のJIRA管理を、TBV側が担当することで、業務の対応範囲が計画～タスク実行まで広がったため、TBV側からの提案数が増えた
• 導入後、手戻りが減った。体感で品質が5％程度は上がったように思う

一方、TBVのチームがスクラムを通して感じたことは以下です。

• 毎週、動くソフトウエアを使ってヤフーにデモをすることで、その場でフィードバックをもらえるため、目標達成を実感できる機会が増えた
• 自分が担当しているタスクだけではなく、チーム全体で開発しているという一体感が生まれた。課題があればチームに相談し、時にはブレーンストーミングを行った。また、実際の開発においてもモブプログラミングをしたことで、コラボレーションの意識が強くなり、やる気も高くなった
• リーダーや先輩レビューに頼るのではなく、品質は自分で守る、という責任感が強くなった
• ゴール指向というマインドセットが強化されたので、チームメンバーが共通のゴールに向かって、まっすぐ業務をするようになった
• ベテラン、若手とは関係なく、皆が新しい技術・難易度が高い作業にチャレンジできたため、チーム成長が早くなった

"お互いを認め合うことをコミットし、結果だけではなく結果に至るまでの行動から変えていくこと。"

この言葉を大切に、今後も自律し、自己成長できるチームを目指していきます。