• Home
  • コーポレートブログ Geniee’s BLOG
コーポレートブログ

Geniee’s BLOG

ジーニーは最先端の広告テクノロジーで
顧客の収益を最大化します。

こんにちは、R&D本部2019年卒エンジニアの増田です。
マーケティングテクノロジー開発部SFA開発チームでチームリーダーをしています。

増田 航/早稲田大学大学院卒業後、2019年入社。GENIEE SFA/CRM事業本部プロダクト開発部GENIEE SFA/CRMグループGENIEE SFA/CRM開発チーム2 リーダー

今回は15~20人の中規模な開発チームにおいて、どのように振り返りの活動を導入して定着させていったかについて話そうと思います。

振り返りを導入した経緯

SFA開発チームでは2年ほど前からスクラムでの開発フローを導入し始めました。ただ、導入して3ヶ月の間はスプリントレトロスペクティブと呼ばれる振り返りのイベントがなかったため、開発体制などに関して問題点を議論して改善をするプロセスがありませんでした。ちょうどそのタイミングで、前職でスクラムでの開発を長く指揮していた経験のある新しいマネージャーの方が参画したため、その方と当時のリーダー陣で相談をして振り返りのイベントを設けることにしました。

導入にあたって考慮したこと

前提として弊社の開発部署は一つのプロダクトに対して、2~4程度のチームで構成され、さらにチームはリーダーと2~4人のメンバーで構成されています。
私が新卒で配属された部署でも振り返りのイベントが四半期に一度ほど行れていたのですが、個人的に以下のような点で問題があると感じていました。

  • リーダー、マネージャー、PMでの議論だっため、決定事項を伝える際にメンバーの納得感が薄かった
  • 開催頻度が少なかったため、開発フローをガラッと変えるような大きな改善になっていた
  • 改善アクションが多く、全てを実行することが困難だった

これらを考慮した上でSFAチームでの導入の際には、以下のように開催ルールを工夫した上で導入を開始しました。

  • メンバーとリーダーのみの場とすることでメンバーからの率直な意見が出やすいようにした
  • 開催頻度を四半期に一度から隔週に増やし、改善のためのアクションの個数を絞ったり、すぐに始められるような簡単なアクションを設定することで、改善のハードルを下げた
前部署SFAチーム
参加メンバーリーダー、MGR、PM、部長リーダー、メンバー
開催頻度四半期に一度隔週
改善アクションの個数優先度の高いものは全て1-2個
改善アクションの粒度部署内で行えるものチーム内で行えるもの
振り返りのフレームワークKPTKPT

導入後の課題

導入後1ヶ月ほど運用をしてみて、いくつか課題が上がってきたため、3つほど紹介したいと思います。

1.チーム内で解決できないような課題も意見として挙がってくる
一つめの課題は例えばプロダクト内でテストコードをどう運用していくかといった、プロダクトチーム全体で共通認識を持って行うことや、組織体制に関わることなど、チームの中だけでは解決できないような課題が振り返りで意見として出てくるというものです。これについてはチームの振り返りとは別でリーダー以上で組織改善定例を行っており、そこに議題として持っていくことでプロダクト全体への周知を行っていました。

2.毎週よかった点や問題点を挙げるのが大変
二つめの課題は開催頻度を多くしたために出てきた課題で、自分も同じことを導入時に考えていました。これについては記載のハードルを下げて個人的なことでもなんでもいいから書いてもらうようにしました。また、最近では振り返りのフレームワークをもう少し雑談形式にして日々のつぶやきのような形でフランクに話せるように工夫をしています。一年以上続けていますが、意外と毎週色々な意見が聞けています。

3.プロダクトや組織の愚痴になってしまう
三つめの課題は、問題点の議論がプロダクトや組織や個人に対する愚痴になってしまうといったものです。振り返りの場で愚痴が多くなってしまうとチームの雰囲気も悪くなってしまうため、ファシリテーターがうまく本質的な課題だけを抽出したりしてコントロールする必要があります。

具体的にどのような改善ができたか

最後に具体的に振り返りの中で出てきたアクションでどのような改善に繋がったかをご紹介します。
数として多かったのは、ドキュメントやコードの管理の改善でした。機能改修に当たってドキュメントが少なかったので仕様調査・機能改修と一緒にドキュメントを整理するといったことや、プロダクトコードとは直接関係がないような作業自動化のコードなどのGitでの管理などです。
次に多かったのは、リリースや本番での作業、問い合わせ等に関するフローの見直しでした。これはチーム内で完結できないことも多いですが、現場の意見として他チームや他部署にも問題提起することで全体での改善が行えていたと思います。
また、情報共有という面で、メンバーが直面した課題や作業効率化のためのツールの設定などを他のメンバーと共有して効率化を図ることも振り返りの中で行えていました。

まとめ

振り返り自体は多くのチームが行っているかと思いますが、実際の改善に繋がらなかったり、現場の意見をうまく吸い上げられなかったりと課題があるかと思います。振り返りを行っても実際の改善が行われないと開催の意義がなくなってしまうため、まずはチーム内ですぐに始められる改善から徐々に進めていくのが良いと思います。

一緒に働く仲間募集中!
【ジーニーのリクルートサイトはこちら】
https://geniee.co.jp/recruit/

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

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

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

Contents

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開発チームでスクラムを取り入れた際の工夫や改善された点の紹介でした。スクラムを取り入れた開発の一例として参考になればと思います。

参考

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

一緒に働く仲間募集中!

【ジーニーのリクルートサイトはこちら】

https://geniee.co.jp/recruit/

Back to top