ブログ | 株式会社ジーニー Geniee,Inc.

2021 11.11

GENIEE SSP開発チームのスクラムを取り入れた開発について

: ジーニー

Share

GENIEE SSP開発チームの齋藤です。ジーニーには2019年に新卒入社して、今年度で3年目になります。

SSP開発チームではスクラムを取り入れた開発を始めておよそ一年経ちました。チームでスクラムをどのように取り入れたか、スクラムを取り入れてから何が改善されたか、という点を書いていこうと思います。

齋藤洋平 / 宮城大学(事業構想学部)卒業後、2019年に入社。R&D本部アド・プラットフォーム開発部 SSP開発チームリーダー。

1. SSP開発チームの業務と抱えていた課題

2. そもそもスクラムとは

3. スクラムの課題に立ち向かう

4. スクラムを取り入れて改善されたこと

5. まとめ

1. SSP開発チームの業務と抱えていた課題

SSP開発チームでは広告収益を最大化するためのアドプラットフォームであるSSP(Supply Side Platform)の運用や改修、その他収益の全般的な最適化ツールを開発します。

■主な業務

普段はざっくり次のような業務があります。

– 管理画面の開発(React)

– APIやバッチなどサーバーサイドの開発(PHP, Go, Python)

– 広告フォーマットなどのWebクライアントサイドの開発(JavaScript, TypeScript)

– SSPやその周りのシステムの改修(C++)

– その他広告が正常に配信されているかの調査など

■スクラムを取り入れる前のSSP開発チームの課題

スクラムを取り入れる前は、エンジニアの属人化が問題になっていました。いわゆるバックエンド、フロントエンド、というような区切りで開発の担当者が決められ、PMと担当者間で仕様が決まるという体制です。開発を担当した者しか詳細を把握してない場合が多く、問題が起きた時に担当者が既にチームにいない場合は、誰かが一から仕様を調査する必要がありました。

PMと担当者という体制の場合、要件の認識が合っていないことによって開発の遅延が起きることがありました。また、エンジニアの経験や能力次第で開発が遅れてしまうということもしばしばありました。特に最近はほとんどのエンジニアがリモートで勤務しているためコミュニケーションの機会も減りました。これも情報共有においては障害になることがあり、開発の遅れの原因の一つでした。

2. そもそもスクラムとは

2020年版のスクラムガイドでは、スクラムの定義について次のように述べられています。

> スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。

> スクラムのルールは詳細な指示を提供するものではなく、実践者の関係性や相互作用をガイドするものである。

2020-Scrum-Guide-Japanese.pdf スクラムガイド 2020年11月

…このように、抽象的な定義です。

定期的にスクラムガイドは更新されますが、2017年版と比べて2020年版では、スクラムを最小限かつ十分なフレームワークに戻すことを目的とし指示的な表現を減らしてあるようです。「スクラムとは〇〇であるべき」みたいな型に合わせるものではなく、開発チームの体制や業務に合わせて、チームの課題を解決するためにスクラムを取り入れました。

■スクラムを取り入れる

これまでSSP開発チームで抱えていた属人化の課題の解消や、開発の遅延を防ぐ・検知する、コミュニケーションの機会を増やす、といったことを目的にスクラムを取り入れました。機能をどれだけ開発できているか可視化する目的もありました。

■スクラムチーム

スクラムを取り入れてチームの編成が変わりました。PMの要望にチームで応えられるよう、それぞれに得意な領域を持ったメンバーの機能横断型チームとしてスクラムチームを構成しています。

■具体的な運用

AtlassianのJiraというツールを使っています。2週間を1スプリントとし、開始と終了にスプリントプランニング、スプリントレビューを行います。毎日15分から30分程度のデイリースクラムでコミュニケーションをとり、進捗や問題を明らかにしています。

ツールの運用の工夫として、スプリント中の差し込みタスクを記録するためのバックログを事前に作っている点が少し変わっていますが、これは後述します。基本的にはスクラムガイドに従ったフローです。

(工夫としてスプリント中に発生した差し込みを記録するためのバックログを用意している)

3. スクラムの課題に立ち向かう

ガイドラインに従って一般的と思われる形でスクラムを取り入れましたが、スクラムのフレームワークで解決できない課題があります。例えば差し込みタスクは事前のプランニングの外にあるので、こちらへの対応が課題になりました。また、広告フォーマットの仮説検証など、通常の開発とは違う取り組みにも対応が必要でした。

■差し込みタスクへの対応の難しさ

差し込みタスクはスクラムチームの進捗を妨げる障害になるので、基本的には引き受けないようにしますが、どうしても改修や調査をやらねばならない時があります。

差し込みタスクのような予定していない作業が増えると、スプリントで完了させることのできるタスクの量が安定しづらくなり、機能のリリースで価値をもたらすまでの時間が増えてしまいます。

■スプリントごとの差し込みタスクの量を調べてバッファを持つ

スプリントで実行する作業計画を立てる際に、その期間で発生する差し込みタスク分のバックログを作り、差し込みが発生するたびに追加しています。このようにしてスプリント内の差し込みタスクがどの程度あったか記録しておくことで、次回以降のスプリントにバッファを持たせるようにしています。

(差し込みタスクは誰がどれくらい時間を取られたか記録し後から把握できるようにしている)

■遊撃部隊的な動きで対応する

SSP開発チームでは、広告フォーマットの開発やフォーマットのABテストなどの仮説検証を行うこともあります。このような開発は状況に合わせて試行錯誤する作業になるため、どれくらいの開発が必要か事前に予測がしづらいです。

そこで、プランニング時にアサインするタスクを少なめにした遊撃部隊のような要員も含めています。このメンバーはプランニング時点でアサインするタスクをかっちり決めないことで、事前に予測できないタスクに対応します。

このような取り組みで差し込みタスクや仮説検証のタスクに対応可能にし、スクラムの課題に立ち向かう工夫をしています。

4. スクラムを取り入れて改善されたこと

スクラムを取り入れて体制がいくつか改善されました。エンジニア個人の能力の幅を広げる意識と、チームで知識を共有して属人化を防ぐ意識が定着しています。

■チャレンジしやすい環境になった

> スクラムチームは機能横断型で、各スプリントで価値を生み出すために必要なすべてのスキルを備えている。また、自己管理型であり、誰が何を、いつ、どのように行うかをスクラムチーム内で決定する。

2020-Scrum-Guide-Japanese.pdf スクラムガイド 2020年11月

スクラムガイドに従い、機能横断で自己管理型であることを目指しています。

機能横断型のチームになるためには、それぞれ得意な領域を持った他のメンバーとの連携やコミュニケーションが必要です。また、スクラムのメンバーは自己管理型を意識し、作成したバックログの中から自分たちでタスクを選んでいくようにしています。

タスクはリファインメント時に可能な限り分割されています。必要であればペアプログラミングも行いながら開発することで、経験が少ない領域にも小さなタスクから挑戦しやすくなりました。

■属人化の解消をチームで意識するようになった

スクラムを取り入れる前は、いわゆるフロントエンド・バックエンド、といった領域によっておおよその担当者が決まっており、担当者とPMとの間で仕様が決められるという体制でした。これは属人化の原因になっており、ある領域で優秀な一人のエンジニアにばかり任せるという状態が見られました。

スクラムを取り入れてからは、PMからの要望をチームで理解し、バックログに分割しています。スプリントで目標にしたバックログの完了はチームの責任として考え、チーム全体が仕様を理解するための意識が生まれ、属人化の解消に繋がっています。

5. まとめ

僕の所属するSSP開発チームでは、チームや組織・プロダクトの実情に合わせてスクラムを取り入れて運用しています。スクラムを取り入れて改善された点は、エンジニア個人の能力を広げる挑戦がしやすくなったことと、チームで理解して属人化を防ぐ意識ができたことです。開発する機能の遅れにも気が付きやすくなりました。

どうしても発生する差し込みタスクに対しては、一定量の受け入れる準備をしていることや、遊撃要員はある程度自由に動けるようにするような工夫をしています。それ以外はほとんどスクラムガイドに従うようにしており、従来の開発体制と比べて開発フローが改善したと感じています。

スクラムは組織が価値を生み出すためのフレームワークです。チームや開発項目で抱えている問題に向き合い、スプリントごとの振り返りで開発の体制を継続して改善することが重要でしょう。

ここまでが、GENIEE SSP開発チームでスクラムを取り入れた際の工夫や改善された点の紹介でした。スクラムを取り入れた開発の一例として参考になればと思います。