現在JavaScriptの設定が無効になっています。このページを利用するにはJavaScriptの設定を有効にしてください。Yahoo!ゲーム案件を担当しているディンと申します。Vietnam(TBV)は2015年に設立され、ヤフーの約20サービスの開発を担っています。https://www.techbasevn.com/jp/今回はゲームサービスの開発チームにおける、スクラムの導入についてご紹介します。スタート当初の課題2018年8月よりゲームサービスの既存システムを刷新する目的で、TBVでその一部の開発を担当することになりました。ヤフー側はスクラムで開発を進めていましたが、TBV側は当初ウォーターフォールスタイルで開発を進めておりました。チームの技術力が上がり、業務の理解が進んだ結果、品質、開発スピードともに改善できました。結果として、担当業務においてTBVが担当する開発の範囲は詳細設計~結合テストにまで拡大しました。開発工程全体においては、部分的な貢献に留まっているという課題がありました。ヤフー側とTBV側の体制は以下でした。ヤフー側では以下の作業が必要で、TBVと仕事をするために「追加」で必要な仕事が多いという課題もありました。担当業務の狭さ、ヤフー側管理コストの高さという課題を解決するため、以下の2つが必要であると考えました。プログラム製造がTBVの目的ではなく、ユーザーにサービスを届けることが目的。そのため、TBVの開発チーム主体的になる必要がある(≠言われたことだけを実行するチーム)。開発メンバー全員がWhyを理解しながら、Whatを実行する必要がある。(当時はWhatを指示されるだけだった)Whyを理解するためヤフーの担当者(計画者・プロダクトオーナーと開発メンバー)との距離を縮め、直接コミュニケーションする必要があるこの2つの要求を満たすため、スクラムを導入することにしました。開発だけではなく開発目的を理解し、サービスの価値、事業計画に対して、より貢献することを目標としました。導入前のトレーニングスクラムの導入はゲームサービスだけでなく、TBV全体で行われました。TBVで担当している案件の中から、ゲーム案件を含む3案件がスクラム導入のパイロットとして選ばれました。スクラムのフレームワークを形だけで適用するのは簡単ですが、スクラムで定義されている内容の目的・想定される効果の理解、自己改善力をチームで身につけることは難しいことでした。TBV側だけではなくヤフー側にも今までのやり方を変更してもらうことが必要です。そのため、ヤフーのアジャイルコーチに、ヤフー側、TBV側の両方に対して、約半年間、コーチング、トレーニングをしてもらいました。スクラムトレーニングの様子スクラム導入計画スクラム導入セミナーの後、チームでディスカッションし、スクラム適用で変更するポイントを以下のように決定しました。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、リーダーは仕事の仕方を変えていきました。この変更には懸念もありました。従来、品質や進捗の管理のために直接的にメンバーに関わっていたチームリーダーが、スクラムマスターとしてチームの観察・サポートするという立場になることで、責任・権限が小さくなったと感じてやる気が下がってしまったり、逆に開発チームが自分たちの責任が重くなったように感じてプレッシャーを感じたりするのではないかという懸念です。この懸念については、スクラムにおける役割と責任をしっかり全員に説明するとともに、チームの意見もヒアリングしたことで、全員が納得することができました。プラクティス導入での課題スクラムフレームワーク導入段階では、いくつかの課題が発生しましたが、一つずつ解決していきました。チームのコラボレーションを強化するためにモブプログラミング導入したが、導入直後は一時的に生産性が下がってしまった→モブプログラミングの導入で期待できるチームのスキルアップやコラボレーション強化をヤフー側に説明し、理解を得ました。全てに対して適用するのではなく、効果的なタスクをスプリントプラニングで決定するようにしました。直後は生産性が下がったものの、モブプログラミングを行うことでチーム全体の知識やスキルが上がり、結果的には生産性は上がっている状態になりました。スプリント期間が1週間なのでスプリントで完了できないPBLがあり、品質下がってしまうケースがあった→PBLを小さく定義できるようにチームでブレーンストーミングをしたり、レビュー時間を無くすためにモブプログラミングを適用したり、今までリーダーが1人で行っていたテスト業務をチーム全員ができようにしたりなどの工夫をしました。振り返り会であまり意見が出ず、雰囲気が悪くなってしまった→チームで共通のメトリックを設定し、振り返り会でこれを評価したり、スクラムマスターがメンバーの発言を促進するために工夫をすることで、チームの雰囲気を良くすることができました。Fun/Done/Learn手法(※)などは効果的でした。オブジェクト広場よりhttps://www.ogis-ri.co.jp/otc/hiroba/others/ActivityPocket/FunDoneLearn.html最後にスクラムの導入において、私たちのチームでは、やらされるのではなく、自分たち自身で目標(Vision)を設定し、目標にコミットし、その目標を必ず達成するという決意を持って頑張りました。Criteria)を満たす自ら課題を見つけ共有するチームになるまだまだ改善する必要がありますが、ゲームサービス開発チームにおけるスクラム導入は成功したと思います。スクラム導入後、ヤフー側からコメントをもらいました。スプリントレビュー計画をTBVが担当することで、自主性が生まれ、手戻りが少なくなったデモでレビューすることによって、各工程の成果物(設計、ソースコード、テスト結果)のレビューが減った開発を依頼する際の資料作成が少なくなった開発を依頼した後のJIRA管理を、TBV側が担当することで、業務の対応範囲が計画~タスク実行まで広がったため、TBV側からの提案数が増えた導入後、手戻りが減った。体感で品質が5%程度は上がったように思う一方、TBVのチームがスクラムを通して感じたことは以下です。毎週、動くソフトウエアを使ってヤフーにデモをすることで、その場でフィードバックをもらえるため、目標達成を実感できる機会が増えた自分が担当しているタスクだけではなく、チーム全体で開発しているという一体感が生まれた。課題があればチームに相談し、時にはブレーンストーミングを行った。実際の開発においてもモブプログラミングをしたことで、コラボレーションの意識が強くなり、やる気も高くなったリーダーや先輩レビューに頼るのではなく、品質は自分で守る、という責任感が強くなったゴール指向というマインドセットが強化されたので、チームメンバーが共通のゴールに向かって、まっすぐ業務をするようになったベテラン、若手とは関係なく、皆が新しい技術・難易度が高い作業にチャレンジできたため、チーム成長が早くなった"お互いを認め合うことをコミットし、結果だけではなく結果に至るまでの行動から変えていくこと。"この言葉を大切に、今後も自律し、自己成長できるチームを目指していきます。JAPANでは情報技術を駆使して人々や社会の課題を一緒に解決していける方を募集しています。詳しくは採用情報をご覧ください。JAPANのサービス開発を支える技術やデザイン、文化を発信しています。Reserved.このページの先頭へ。