顧客に価値を提供するラボチーム
今井太宗氏（以下、今井）：「顧客に価値を提供するラボチーム」ということで、Reproの今井と申します。よろしくお願いいたします。僕は、Repro AI Labsで責任者をやっています。
バックグラウンドとしてはソフトウェアエンジニアやPMと書いていますが、何でも屋です。
今日話すことは「ラボチームが改善し続けていること」です。話さないことというか話せないことなんですが「こうやったらうまくいくという方法論」ということで、「むしろ教えてください」というフェーズです。さっきの話を引用すると、データでやりたいことはあるのでがんばっています。という話になります。
最初にReproの紹介をさせてください。
Reproは「Marketing Platform」と言っていて、SDKが扱っているユーザのイベントデータを集めて分析、可視化したり、そのデータを元にセグメンテーションを行ったり、プッシュやメッセージといったユーザ向けのコミュニケーションを施策として実施しています。
具体的にいうと「継続利用をやめそうなユーザにプッシュ通知を配信したい」みたいなニーズがあり、この「やめそうなユーザだけに」という「やめ“そう”」の部分が予測になっていて、「機械学習を利用したパーソナライズ」をやっています。
なので「Repro AI Labs」が立ち上がりました。
チームを立ち上げ、しかし…
ちょうど1年前にチームを立ち上げました。当時、メンバー2人と顧問で「データを価値に変える」ということで立ち上げました。幸いにしてけっこうデータはあって、やりたいこともあるので、PoCや機能の実装を始めました。同時に、データがあるとBizサイドの、セールスだったりマーケのみなさんから「データ見たいよ」とか、もっと顧客に提案したいということで、そういった要求にも応えていました。
学びとしては「やることが多くて無理」という話です。
PoCをやって、分析やって、実装やって、ディスカッションをやって、みたいなスイッチングコストも半端ないです。人が足りていないと思っても埋める時間もないので、「俺って今何やってるんだろう」みたいな自問自答する時間が増えていきます。
「なんでなんだろうなぁ」と思ってたんですが、これって僕が Web アプリケーションエンジニアとしてやっていたときの開発フローってこれぐらいでした。MLだとそこにさらに検証だったりPoCをまわしたり、アルゴリズムの話があったりとか工程が膨れます。
他にも、Bizサイドとの話もありました。
データ分析や機械学習という軸を中心にして、Bizの中だと事業分析や意思決定に使ったり、顧客向けにレポーティングやアプリケーション開発みたいな、とにかくやることが多い、スタックも多い。ステークホルダーも多い。ということで、「オイオイオイ、死ぬわあいつ」みたいな感じですね。
（会場笑）
フォーメーションを作ったものの、個人技頼みに
改善として、フォーメーションを組みました。
やることが多いということで、PoCですとか、失敗も多いというのもあるので、それを理解してちゃんと周知していく。何が足りてないないかに真摯に向き合って、社内外でコミュニケーションをとって全員で取り組む。それで「こういった幅広い範囲と複雑さに対応できるフォーメーションを組む」ということをやりました。Reproありがたいのは、BizもDevも、顧客も大変協力的で、チームをまたいでフォーメーションを組めたのがよかったです。
その結果、半年弱で無事に機能をリリースすることができました。ところが、実装の佳境には、精度はどうだとか、実際バッチが落ちないかとか運用の体制だったり、AIってブラックボックスなのでちゃんと説明したり、プレスリリースの準備をしたり。それで終わりじゃないので、次の機能の要件定義とか、PoCまわして、実験まわして、みたいな。
人は多かったんですが、やることが散らかって個人技頼みになってしまいました。
せっかくフォーメーションを作ったのに個人技頼みになって、「新しく差し込まれたタスクやってます」とか「実験が失敗したので、第2弾やります」みたいな個々に報告しあう感じですね。個人では何をやっているかわかっているんですけど、「なぜ」というのがお互いが見えなくて、詰まったら詰まった人が個人で突破するしかない、みたいな状況になっていたんです。
スクラムを導入
改善策として、スクラムを組みました。
「自分たちが何にフォーカスすべきか」をしっかり話せるということ。差し込みをしっかりブロックして分断、あるいは分担していく。スプリント単位で振り返りをすることで、なんで詰まっていたのか、しっかり改善プロセスが回せます。なによりも可視化することで、「何が差し込みされているんだ」とか「実験失敗した」とか、こういうことをちゃんと話せる舞台を作りました。
R＆D色が強いチームだと、「スクラムってアンマッチなのではないのかな？」と、考えたんです。それは失敗が多かったり、けっこう中長期的な投資が多いからなのかなと思っていろいろ調べていたんですが……。
これはログミーTechの記事なんですけど、マクアケの吉田（慶章）さんが「メンバーをタスクに振り分ける」「『1タスク1人だよね』という前提を、まずはぶっ壊してください」、というこの記事がすごく心に刺さって、スクラムを導入しました。困っている人にコミュニケーションをとって、そうすることで協力が生まれます。「なんでこれつまっているんですか？」とか「これ困ってるんですよ」って、しっかり話すことで協力がうまれる。協力の過程で、知識の伝播やコラボレーションがうまれて、ちゃんと何をやっていて、何に困っているのかを、1週間、2週間単位で追うことが重要だなと思いました。
フィーチャーチームを意識する
最近、おかげさまでスクラムが回って改善も進んできました。ただ、PoCの施行回数は増えたんですけど、機能や施策に実際つながっているかというと、それほどガツンとつながってなかったり、AI機能の詳細部分とか目的がけっこうあやふやなまま進めてしまったり。あとは、このAI機能ってどういういいことあるんだっけ？ というようなことが定義できていないということが進んできて、学びとしては、上手く進みすぎた故に「なんのためのラボ？」というか、顧客への提供の軸がぶれてきたなぁ、というのがあって、AIにこだわりすぎたというところで、そこにツッコミが入って「このAI機能ってそもそもReproで使えるんですか？」みたいな。
目新しさとかプレスリリースみたいなところがゴールになってないか。あと、その機能を使うにはそもそも、それあるとおもしろいけど、おもしろいで終わってしまって実際に使えるユースケースになるには、まだまだ足りてない機能ってありそうだなみたいなところがわかってきたんです。
なので、改善としてはフィーチャーチームという意識を強くしました。
これは『大規模スクラム（LeSS）』という本を読んでいただけると、もっと詳しく書いてあります。「エンドツーエンドで顧客中心の機能を実現するチーム」。安定した長期間存続する練度の高いチームです。これの何がいいかというとPoCとか機械学習部分だけで終わらせず、価値までちゃんとコミットするということです。
「何ができるか」というところではなくて「どういう価値が顧客に提供できるのか」を話すということです。ある意味機械学習チームであることを捨てて、AIだけでなくそれが最大の価値につながるところまでやりきることをチームで意識しています。
なので、顧客の言葉で「これって、なんでよかったんだっけ？」みたいなことを、みんなで意識できるし、機能をリリースした後に価値がしっかり実感できると。「他のチームに依存はせず協力はしあえる状態」とは、まず、機械学習でアルゴリズムのいいバッチを作ったけど、あとはアプリケーションチームに任せるとか、「これ、めっちゃ負荷高いけどインフラチームの増強待ちだね」みたいなところではなくて、しっかりチームの中でコミットして、インフラチームや他のチームと「こういったところって負荷どうなの？」みたいなことをしっかり話し合って協力しあえる状態を作ることです。
知識はすぐ付くものではないので、インフラチームの場合は「インフラのこういうところ足りないよね」みたいなことがわかって「じゃあ先に〇〇しないといけないよね」みたいな投資ができたり、他のチームがリリース遅いから、みたいな他者責任にならずに、自分達でしっかり成長を促せる効果を狙うことを意識しています。
まとめです。「広さと複雑さに対応できるフォーメーション」「フォーカスと協力を生むためのスクラム」「価値提供のため成長するフィーチャーチーム」を意識しています。
正直「めっちゃやってます」みたいなことを言いましたが、まだぜんぜんできてなくて。昨日もKPTを1時間くらいやったぐらいで、まだまだ課題があります。でも意見を出してくれる素敵なメンバーが揃っていて、これからもチーム自体は改善し変化していくと思います。
ただ、変わらないことは「顧客に価値を提供するラボチームであり続ける」ということです。
ということで、素敵なチームなんで「WE ARE HIRING!!!」を入れさせていただきました。ぜひ興味を持った方は一緒に働きましょう。
あと1つ。これは宣伝なんですが、Meetupやるので、ぜひイベントに申し込んで下さい。素敵な登壇者が揃っています。ご清聴ありがとうございました。
（会場拍手）
