"ラボ" がチームビルディングで経験した４つの学び

はじめに

Repro AI Labs の 今井 @taison124 です。

Repro は昨年7月にマーケティングの自動化を目的として AI を用いた機能の研究開発を担うチーム Repro AI Labs を立ち上げました。チームではデータ分析から PoC、実際にプロダクトの機能やサービスを開発し運用するところまでを行っています。

本記事は 3/28 に行われた Machine Learning Team Building Pitch での LT をもとに、そんな幅広い役割をもつ "ラボ" チームのチームビルディングについて紹介します。現在もまだまだ課題は多く、これをやればうまく行くという方法論は提示できません。あくまでチームでの失敗やその改善として取り組み続けていることをまとめたものです。

相互補完的なフォーメーション

学び

Repro AI Labs の立ち上げより前に、データを使って価値を提供するチームを先行して立ち上げました。メンバーは２名＋技術顧問１名の３名体制でした。当初は順調に思えたものの、すぐに業務が回らなくなってしまいました。

一般的な Web サービスにおいては、以下のような開発フローになると思います。

ところが機械学習の機能を開発する場合、以下のように増えます。

さらにデータを扱うチームである以上、その対応領域は多岐に渡ります。

そしてその分、ステークホルダーも多くなります。

それまでの開発と比較してやることが多く、失敗も多いことがわかりました。それを前提として社内外でコミュニケーションをとり全員で取り組むことが大事だと感じました。

改善

そこで上記のような開発フローや対応領域に対して何が足りないかに向き合い、フォーメーションを組みました。各々の強みで相互補完的に対応することで、この広い範囲と複雑さをもつ機能開発に対応できるようにと考えました。

たとえ異なるチームであっても協力できる Repro だったからこそ 機能をリリース するところまで達成できたと思います。

スクラム

学び

開発が進み、リリースの前後やさらに運用を安定化させるフェーズに入ると、やらなければならないことは増えていきます。

• 実装に加えて、精度確認を含む機能のテスト
• 安定的なバッチ運用体制や監視システムの構築
• 社内外への説明、プレスリリースの準備
• 次にむけた機能の要件定義や PoC

すると、デイリーミーティングが以下のようになっていました。

各々でバラバラに進んでいるという状態です。お互いに "なぜ" それをやっているのかが見えず、何か困ったことがあっても協力できなくなります。同じ目的に向かって開発しているはずなので、より協力できるチームになるよう、やっていることを話せる必要性を感じました。

改善

この困っていることや助けられることがコミュニケーションできる状態を目指して、スクラムを導入しました。お互いがやっていることを可視化し、将来的なロードマップや目的といった "なぜ" を見えるようにするのが狙いです。

さらには結果として以下のような状態が生まれました。

• 自分たちが何をするべきで、何をするべきでないかを話せる
• 差し込みのタスクをそのまま着手せず分担できる
• スプリント単位で振り返りをすることで、改善プロセスを回せる

R&D の色が強く専門性が求められるラボのようなチームではアンマッチという懸念もありました。しかしマクアケ吉田さんの プロジェクトの成功率を上げるために、チームリーダーができること・やるべきこと という記事に感銘を受け、導入を決意しました。記事にある "よくある「1タスク1人だよね」という前提を、まずはぶっ壊してください。" というところが、今回の課題の背景にあるのではないかと感じたからです。強い専門性が必要であったとしても、協力し開発を進めるためには相互の理解も必要だからです。

フィーチャーチーム

学び

それから改善プロセスに取り組み続けた結果、次のような課題に直面しました。

• PoC の回数は増えるけれど機能や施策に繋がらない
• AI 機能の目的があやふやになる
• 顧客への提供価値が明確に定義できていない

つまり "ラボのためのラボ" になってしまい、顧客へ提供する価値が最大化できていない状態です。もちろんコアである AI・機械学習は大事ですが、それをどう使うかを中心にしてしまい、もっと顧客中心の開発を行うことの重要性に気が付きました。

改善

そこで "エンドツーエンドで顧客中心の機能を実現する、安定した長期間存続するチーム" ( 大規模スクラム Large-Scale Scrum p.77 ) として提唱されているフィーチャーチームを目指すことにしました。PoC や機械学習機能に限定せず、顧客に提供する価値までコミットするということです。

そうすることで、さらには以下の効果を促します。

• 顧客の価値を中心にすることで、リリース後の価値が実感できる
• 他のチームと協力はしあえるけれど、依存はしない状態
• 依存しないことで自分のチームで足りないところがわかり、投資できる

自分たちで成長し続けられるチームを目指せるということでもあります。

フロー効率の意識向上

学び

LT では上記までの取り組みを発表しました。さらに直近の取り組みを紹介します。

広範な開発範囲と専門性をもつチーム特性上、属人性が高くなります。さらにフィーチャーチームになったことで、専門性のある場所を他のチームに任せるより、チームでカバーしていこうという意識が高まりました。すると、チームメンバー個人の領域は広くなります。結果として、チームにおけるお互いの距離が遠くなってしまい、チームで取り組んでいる感覚が希薄になっていきました。

顧客へ価値を提供するサイクルを早め、さらにはよりよい品質に上げる。そのためにも、もっとチームとしての一体感をもって取り組める必要性がメンバー全員の意見として出ました。

改善

ただいま 株式会社 SKYS 豊田さんにアジャイルコーチとしてアドバイスをいただいています。

この課題を解決するため、豊田さんの提案でフロー効率の意識を高める取り組みを始めました。チームとしての一体感を出し、より協力的な体制と成長できるコミュニケーションパスを作り、リリースまでの属人性を低減することが目的です。リソース効率に寄ってしまう状態を継続的に防ぐための試みでもあります。

具体的には、まずチーム全員で自分がやっていることを付箋で出しあい、全体の流れを俯瞰しました。

このように可視化し、定期的に見直しながらチームでコミュニケーションを行います。その結果、

• 自分と他のメンバーとのタスクや専門性の関係がコミュニケーションできる
• あまりチームとして着手できていない領域がわかる
• 自分が今後やっていきたい領域の話をして、技術的な投資ができる

という状態を目指しています。そうすることで、顧客へ価値を提供する速度やクオリティを上げていければと考えています。

おわりに

いかがでしたでしょうか？

R&D の不確実性を含み、専門性が多岐に渡ることで、プロダクトから独立してしまいかねないラボチーム。そんなチームにおけるチームビルディングの課題とその取り組みを紹介しました。「はじめに」でも書いたように、課題はまだまだ山積みです。ただ大事なのはその課題にチームメンバーが向き合って、"顧客に価値を提供する" という目的を軸に改善を続けられることだと感じています。

また現在 Repro の開発チーム全体で LeSS の運用を始めようとしています。今後 LeSS が本格運用される中で出た学びやその改善策については、いずれこの Tech Blog で紹介されることでしょう。

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

本記事がチームビルディングの参考になれば幸いです。