導入の決め手はカスタマーサクセス。 サイクルタイムを60%以上短縮に成功したアドウェイズのTeam+ の活用ノウハウとは？
エージェンシー事業やアドプラットフォーム事業を手がけるインターネット広告企業、アドウェイズグループでは、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。
今回は、株式会社ADWAYS DEEEアドテクノロジーディビジョンにてバイスゼネラルマネージャーを務める府金さん、シニアテクニカルマネージャーを務める飛田さん、ユニットマネージャーを務める三田谷さん、リードアプリケーションエンジニアを務める大島さんにインタビュー。開発生産性の計測にあたって「Findy Team+」を導入した理由や、チームでKPIとして設定した数値目標、取り組み後にどのような変化があったかなどについてうかがいました。
目次
自分たちの開発速度を認識するため、生産性の計測を開始
――最初に、皆さんのこれまでのご経歴や現在の役割について教えてください。
府金：2016年に新卒で入社し、アフィリエイト広告配信の自社サービスにてバックエンドエンジニアを担当していました。3年目から本格的に開発チームのマネジメント職にキャリアを変更し、スクラムマスターやプロジェクトマネージャーを経て、現在は部署全体の組織設計やピープルマネジメントにも貢献しております。
飛田：2008年に新卒で入社し、現在に至るまでアフィリエイト広告配信システムの開発に従事しています。機能の設計開発から運用保守まで、フルサイクルで業務に取り組んできました。ここ数年は、所属部署全体の技術マネジメントにも関わっており、システムの性能向上やセキュリティ対策など、技術的な側面において改善を推進しています。
三田谷：2015年に新卒で入社し、アフィリエイト広告配信の自社サービスにて、エンジニアとして働いていました。3年目あたりから開発チームのマネジメントを行うようになり、スクラムマスターやプロジェクトマネージャーとして活動しつつ、最近はプロダクトマネジメントについても一部関わっています。
大島：2022年に新卒で入社し、アフィリエイト広告配信の自社サービスにてフルスタックエンジニアとして新機能開発や既存プロダクトのモダナイズに取り組んでいます。また、チームのスクラムマスターとして各種ミーティングのファシリテーションやスクラム研修の実施なども行っております。
――開発生産性の計測に取り組まれた背景について教えていただけますか？
府金：まずはシンプルに、開発生産性が業界のトレンドワードになってきたことから、私たちも開発生産性向上のために計測を行いたいという考えがありました。もともと自分たちの組織では、開発速度が特別速いとも遅いとも感じていなかったのですが、マネージャーから「もう少し速くできないか」と言われることがあったんです。
当時は、自分たちの開発速度がどれくらいなのか、ピンときていない状況だったので、やはりそこはしっかりと計測をすべきだなと。ひいては、明確に自分たちの開発速度を認識したうえで、改善していきたいと考えたことが背景にありました。
――「Findy Team+」の導入前にも、計測は行われていましたか？
府金：当時はGitLabでのコード管理がメインだったので、GitLabのAPIを使用してイベントデータを取得し、計測をしていました。レビューの完了など、サイクルタイム的なイベントはラベル運用を行い、それらを活用してフローの計測を行いました。
取得したデータは「Re:dash」というBIツールを使って、チームごとに可視化。四半期に一度、組織全体で見て、目標を決めて各チームで追っていました。
――計測を行っていたなか、どのようなきっかけから「Findy Team+」に興味を持っていただきましたか？
府金：当時の方法では、やはりメンテナンスコストがかかっていました。計測を行うにしても、目標設定を行うにしても、メンバーが変わるなどチームに変化があったときに、なかなか対応が追いつかない部分があったんです。
メインとなるプロジェクト開発を優先しなければならない状況で、そこにコストをかけすぎるのはあまり本質的ではないと考え、代替できるツールを探していました。国内外問わず、さまざまな計測ツールを探したところ、「Findy Team+」がサポート面でも機能としても使いやすそうだと感じたので、導入に至りました。
飛田：もともと、ダッシュボードの構築や、分析に対して、そこまで時間をかけられないという話がチーム内で出ていたんですよね。「Findy Team+」は、そうした課題をカバーしてくれるサービスのため、大変重宝しています。
――海外サービスを含めた他サービスとの比較のなかで、「Findy Team+」のどういったところが導入の決め手になりましたか？
飛田：機能面では特に大きな差はなかったのですが、海外のサービスに関しては、最近は円安の影響でコストの見通しが立ちにくいところがありました。ただ最終的に決め手になったのは、サポート体制が充実している部分ですね。
私たちがこういう取り組みでSaaSを導入するのは初めてだったので、導入から走り始めるところまでしっかりサポートしてもらえるかを重視していました。なぜなら、導入後、「具体的に何から取り組んだ方がいいのか」、「自社に適した改善事例は何か」などリサーチや検討方法に多くの時間を取られ、改善への着手が遅れてしまうケースがあると考えたからです。
実際に、導入時からとても手厚くサポートしていただきながら、導入から取り組みの開始まで進めることができました。
また、相談をさせていただいた際に、これまでの他社改善事例のノウハウや、弊社の状況に合わせた使い方など、粘り強くサポートしていただいたことに非常に感謝しています。
1日あたり1人1プルリクの作成をチーム目標として設定
――開発生産性の計測にあたって、ゴールをどこに設定されていましたか？
府金：業界的にも事業的にも不確実性が高いなかで、どれだけの価値をいかに早く提供できるかが、重要なポイントであると考えています。とはいえ、開発したものが毎回きちんと価値につなげられているかと言えば、決してそうではないこともあるんです。
そのなかで、成功するものを見つけてそれだけをやるというより、課題を見つけてアウトプットを出して、結果を検証する。成功するためには、その繰り返しが重要だと思っています。そういった仮説検証サイクルを高速にまわして、結果的にユーザーへの価値提供を早めていきたいというのが、生産性向上を目指す大きな背景です。
――飛田さんと三田谷さんからも、補足的な内容があればお願いします。
飛田：開発生産性を段階に分けると、プルリク作成数のような作業量としての生産性から、最終的には収益につながる生産性まで、レベル分けができると思います。まず自分たちの組織における、そういったレベル、いわば基礎の状態を可視化し把握することが最初の目的としてありました。
三田谷：チームでプロダクト開発をまわしていくなかで、どこに障壁があるのかをいまいち把握できていなかったんです。例えば、アイディアなどの整理が遅れてサイクルが悪くなっているのか、開発速度によってデリバリーが遅れているのか。その切り分けをしたいと考えていました。
実際に計測を始めると、プロダクト開発部分に限って言えば、生産性は案外それほど悪くないことが見えてきて、組織としての自信にもつながりました。逆に、もっと上流のところを頑張らなければならないという課題を認識できたことも、良かったと思っています。
――KPIとして設定された定量数値はありますか？
府金：計測を始めた直後は、もともと開発速度を測りたいという意図があったので、サイクルタイムやリードタイムを注視していました。ただ、外的要因によって大きく時間がかかってしまっていたなど、仕方がない部分も多く、どう改善しようかと悩んでいました。
そうしたなか、去年ファインディさんが主催する「開発生産性Conference」に参加したときに、多くの企業がプルリク作成数を追っていることがわかりました。しかも、あまり深く考えずプルリク作成数を増やしていっても効果があるという話を聞き、目指すのに良さそうだと思ったので、1日あたり1人1プルリクの作成をチーム目標に設定しました。
また、それをチーム目標に設定した副次的な効果として、個人のOKRで関連する目標を立ててくれる人も出てきました。例えば、チーム全体のプルリク作成数を増やすためのアクションを何件する、ジュニアエンジニアならプルリク作成数を何件目指す、といった目標設定にもつながっていきました。
――1日あたり1人1件のプルリクを出すという目標に対しては、具体的にどのような取り組みをされましたか？
府金：設定したチーム目標に対する、振り返りを実施するようにしました。前月のプルリク作成数やサイクルタイムなどを見て、チームと一緒に分析します。特にプルリクのなかでも時間がかかったものを深掘りしていくと、チームでどこで時間がかかっているのかという傾向が見えてきます。
例えば、レビューに時間がかかっているとか、アプルーブした後リリースまでに時間がかかっているとか。それは個人というよりチームとしての、プロジェクトの性質の問題だったり、開発プロセスの問題だったりするので、次にどうしていくべきかという議論をしました。
――1on1などの場面でも「Findy Team+」をご活用いただいていますか？
府金：1on1ではまだあまり取り入れられていないですね。個人の詳細データを見て、プルリク数が増えているとか、自分が作成したプルリクに対するレビュー時間が短くなっているとか、そういった話は少しずつしているものの、全体的な取り組みとしてはまだできていません。
プルリクの分割でリードタイム短縮、より安定した開発に
――実際に「Findy Team+」で御社の直近1年の数値を見てみると、プルリク作成数が過去に比べてぐっと伸びてきているのがわかります。
府金：そうですね。プルリク作成数が増えたことは、大きな実績だと思っています。GitLabからGitHubへの移行時期も含まれるので、実際にはマージリクエストだった分がプルリクエストになって量が増えた部分もあると思います。ですが、GitHubに移行したことでこうして可視化でき、分析や改善のサイクルがまわるようになったので、移行自体に意義を持たせられたと感じます。
また、プルリク作成数を増やすというチーム目標を持ったことで、各チームのなかでタスク分割に関する意識が大きく上がりました。弊社ではスクラム開発をしているのですが、ストーリーのなかのタスクを分割する際に、プルリク1件に対してタスクの粒度を合わせることを意識するようになってきています。
――レビュー分析を見ると、しっかりとプルリクの粒度が細かくなってきていることがわかります。粒度が細かくなってから、レビューのリードタイムの波も小さくなっていますが、安定してきた実感はありますか？
府金：少し前の波については、GitHubの操作があまり浸透しておらず、ブレがあった部分もあるかなと思いますが、最近は徐々に安定してきていると感じます。まだ劇的に速度が上がったと実感するレベルではないのですが、プルリク1件あたりの見る範囲が減ったことで、レビューに着手するハードルが下がり、着手までの時間もレビューにかかる時間も短くなりました。
また、プルリクの粒度が細かくなったことで、仮に今後問題が出てきても、ロールバックまでの時間も短くなるので、長期的に見ても速度が上がったと言えると思います。
――こうして数値が変化するなか、定性的な面で感じた変化があれば教えてください。
府金：定性面で言うと、振り返りのなかでも、エンジニアから「レビューがやりやすくなった」という声をもらっています。それから、タスクの分割に意識が向いたのと同じように、チーム内で生産性という言葉が浸透してきました。生産性向上のためには、「どのように開発に向き合うべきか」という議論が増えてきたことも、意識変革としては大きかったですね。
また、プルリク数を増やすために、スキマ時間を活用した動きも見られました。例えば、メインのプロジェクトではなくともイシューの消化をしておこうとか、以前失敗したテストを修正しておこうとか、そういう細かいプルリクをつくる工夫をしてもらえたことも良かったです。
そのほかには、計測を始めてからは部署の全体定例のなかで、データをもとにパフォーマンスが良くなったチームを共有するようになりました。計測していなかったときは、そもそも評価自体ができない状態だったので、評価の成熟にもつながったと思います。
飛田：プルリクを細かくしてレビューしやすくなるように、みんな意識して取り組んでくれたので、1回のレビュー量がかなり減りました。なので、レビューする立場としては、取り組みをする前後では心理的な負担が大きく変わりました。それに付随して、コンフリクトの数も圧倒的に減ったと思います。
チームや個人での「Findy Team+」のさらなる活用拡大へ
――取り組みを進めるなかで、難しかったポイントがあれば教えてください。
府金：正しく計測するために、GitHubのフローを浸透させるところは難しかったです。基本的には一般的な定義に従う形で問題ないと思うのですが、蓋を開けてみたら、意外とそれに準じていないチームやメンバーが結構いたんですね。一度説明するだけでは定着しなかったので、振り返りのたびにチェックリストなどを使って、継続的に意識づけしていく必要がありました。
あとは、可視化した数字を見て、課題の仮説を立てて検証していくところですね。例えば、「この数字が悪いから、ここが問題なんじゃないか」と仮説を立てて、実際にチームに聞きに行ってみたら、そこは意外と問題ではなかったり、外的要因が大きかったり。そういったところは、今もまだ難しいポイントではあるのですが、データをもとに課題を見つけて、愚直にトライしていくしかないと思っています。
三田谷：開発生産性チームが主導する形で、チームを巻き込んで振り返りを行い、そこで課題は明らかになってきました。ただ、それをどう改善していくのか、検討できた改善策をいつ実施するのか、といった確実に改善していくためのサイクルがまだ整理しきれていません。当然メインのプロジェクトがあって、それとの兼ね合いもあるので、そこは現在進行形で難しいところですね。
――開発生産性の計測に関する今後のトライとして考えていることを教えてください。
府金：やはりプルリクの計測やリードタイムの改善は、一度取り組んで終わりではなく、継続していくべきものだと思っています。今後、チームやプロジェクトが変化していくなかでも、そこは続けていきたいです。
前期はプルリク作成数を追うことに留まっていましたが、現状はFour Keysすべての計測ができるようになったので、デプロイ数も追っていくなど、より上のステップに行きたいと思っています。
飛田：開発生産性に対する意識が高まってきて、実際に「Findy Team+」を見て分析している人も増えましたが、なかにはまだあまり活用できていない人もいます。なので、そういった人にも、「Findy Team+」をより使ってもらえるようにアプローチしていきたいですね。
開発生産性についてはDevOpsの文脈を通じた話も多いので、今後はよりDevOpsに関わるケイパビリティを高めていく動きを通して、パフォーマンスに関する数値をチームと一緒に伸ばしていきたいと思っています。
三田谷：実は現在、スクラムで実施している振り返りの手法をアップデートする予定であり、そこに「Findy Team+」のデータを取り入れて、よりチームや個人での活用を広げていこうと思っています。上流のリードタイムなどのデータも今集めているので、それらを活用し、開発生産性の観点をしっかり取り入れた振り返りを、毎週実施できるようにしていきたいと考えています。
大島：これまではチーム単位での活用がメインだったのですが、チームは個人の集合体でもあるため、個人のパフォーマンスや成長も重要です。今後は個人の成長のための材料として、1on1などでもしっかり活用していきたいです。
――それでは最後に、御社の開発組織についてのアピールをお願いいたします。
府金：ADWAYS DEEEのプロダクトチームでは、エンジニアだけでなくプロダクトマネージャーやデザイナーなど複数ロールがワンチームに属するフィーチャーチームでプロダクト開発に取り組んでいます。
そのため、一つの目標に向かって技術職だけでなく営業職の方とコミュニケーションを取りながら協働する楽しさも醍醐味の一つです。
また、スクラムやXPなどアジャイル開発を実践し、生産性高く高速な価値提供することを目指しています。
ADWAYS DEEEは良い意味で事業も組織もまだまだ発展途上です。一緒にあるべき姿を描き、実現に向けて取り組んでいく仲間を待っています。
――府金さん、飛田さん、三田谷さん、大島さんありがとうございました！
※株式会社ADWAYSでは、エンジニアを募集しています。
https://findy-code.io/companies/1652/jobs
※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
