こんにちは、Magic Moment 採用担当です。
Magic Moment は2022年9月に製品開発体制を強化するため、スクラム体制を導入しプロダクト開発を進めています。そこで、なぜスクラム体制の導入に至ったのか、20名を超えたテックチームに現在の開発体制と目指す姿を語っていただきました。
プロダクト・チームが大きくなると同時に色濃くなっていた組織体制の課題
ー本日はよろしくお願いします!スクラム体制になり8ヶ月が経ちますが、現在の開発体制に至る経緯を教えてください。
清家:まず、これまでの開発体制を人数規模でお伝えすると現スクラム体制に至るまでに大きく3つのフェーズがありました。まず、2020年に開発をスタートしてから2021年1月にリリースするまで、1-6人のチーム規模で、まさに0->1のフェーズでした。Design Doc といったような企画的なところも走り始めたのはその頃です。
次に、2021年にプロダクトをローンチしてから 5-10 人のフェーズがあり、プロダクトマネージャーとデザイナーが1人ずつ加わり、1つのチームとして開発していました。徐々にロードマップを引いて企画を立て、デザインをしてといったようにプロセスとしても整備し始めたのがそのフェーズです。プロジェクトの規模に応じて2チームに分けたりする中で、次第にウォーターフォールのように期日のあるプロジェクトが始まっていきました。
そして2022年に10-15 人というフェーズとなり、ここはまさに前半が暗黒期、後半が転換期でした。
前半は、最初から在籍していたエンジニアでコンテキストリッチな人が Tech Lead としてアサインされたので、業務負荷が集中した上に属人化が激しくなっていき、それによりさらにコンテキストの共有がされず、分業化が進んでいった時期です。結果的に新しく入社した人が馴染めず、入ってきては辞めるという状況もありました。
自律して動けるチームをちゃんと作らなければいけないと危機を感じ、2022年後半から今のスクラム体制に移りはじめ、現在は20名を超えました。
ーとても苦しい時期だったのではないかと思いますが、2022年は具体的にどのような課題があったのでしょうか。
栗原:当時を振り返ると、1人のメンバーにしか出来ないことが多かったと思います。属人化を解決するためにチーム全体で把握していこうと試みましたが、そうするとインプットするドメイン範囲が広くなり、結果的にしっかりキャッチアップできるメンバーをつくれなかったという状況でした。このままでは良くないと考え、スクラム体制になる少し前の2022年7月頃よりプロダクト領域毎にチームを分け、各領域専門のメンバーでナレッジが蓄積されるような体制へ変えていきました。
もう一つは、ウォーターフォール化が進み、言われたまま作るような受託開発に近しい体制になってしまった時期だったため、各メンバーにとっては言われたことをやっているような感覚があり、作り甲斐がない、モチベーションが下がる、オーナーシップを持てないといった話も出てきていました。そのような課題から、自ら考え自分たちで機能にしていける独立したチームに分かれていったような気がします。
清家:スクラム体制の前は、メンバーは常に2つ以上のチームにアサインされていました。1つはマイクロサービスごとに区切られたチーム、もう1つは企画単位のプロジェクトとして組成されるチーム。 プロジェクト単位でアサインされたチームを中心に時間を使っていたのですが、企画・設計が進み、タスクに分解され、ある程度全体のスケジュールが決まった上でエンジニアがプロジェクトにアサインされていたため、個々のエンジニアにとっては相当息苦しさを感じる状態だったと思います。さらにアサインされるプロジェクトにドメインの関連性が薄い場合もあり、キャッチアップに時間がかかってしまったり、リリースしたものがその後実際にどういったインパクトがあったのかまでウォッチできない、といった課題感がありました。こういった課題が積み重なり、新しく入ってきたメンバーはキャッチアップコストを乗り越えられず、プロダクトに対しての愛着を持ちづらい、既存のメンバーに業務が集中する状態から抜け出せない、といった状況でどこをみても息苦しい状態になってしまいました。
そのようなタイミングで入ってくる新しいメンバーが馴染めずに出ていってしまう中でも、頑張って定着してくれた高橋さんや他のメンバーはとても苦労したと思います。
ー髙橋さん、実際に入社されたときはいかがでしたか?
髙橋:確かにやりづらい感はありましたね…(笑)周りのメンバーもずっと忙しそうにしてるので聞きづらいというのはありました。だからといって、逃げるのかと言うとそういった思いにはならず、この状態をどのようにすれば脱することができるのか、自分ができる全員の負荷を下げる方法とは何かと考え、全体的にコストが高かったリリース運用に関する改善を主導しました。そのように、ひとつずつ改善に向け取り組んでいく中でスクラム体制に移行していったことを覚えています。
目的は「自律」スクラム体制の導入を決意した決め手とその後の変化
ー続いて、スクラム体制を導入した決め手を教えてください。
盛:アジャイルの開発手法の中でデファクトスタンダードなものがスクラムで、もともと Magic Moment はスクラムに近いやり方でした。ただ、スクラムそのものではなく、Magic Moment なりにいくつかカスタムしたオリジナルの手法でした。 しかしそれは、スクラムの基本の 基 を経た上で生まれたスタイルかと言うと、そうではありませんでした。なので改めて、まずは教科書に立ち戻り、守破離の 守 である スクラムをしっかりとやろうということになりました。なのでもちろん他の選択肢もあったと思いますが、テックチームのみんなでごく自然とスクラムを選択したような記憶があります。清家さん、どうでしたか?
清家:そうですね。単にスクラムチームを作りたいという話ではなく、10人から15人になり、自律的に動けなくなっていた状況を解決するために自然と分業化が進んでいったのですが、それが逆に自律化を阻害するものだったのです。それならば自律化するためにフォーカスし続けられるチームを作ろうというのが主題でした。もともとスクラムっぽさを取り入れていたので自律という点でフィットしていたことや、プロダクトは成長して変化していくものなので、変化に追随していく手法として証明されている点もスクラム体制を導入した決め手になりました。
ー実際にスクラム体制になって感じる苦労やチームの変化はありましたか。
盛:スクラム体制に対する期待値調整や理解の差異はあったと思います。「スクラムをやると生産性が上がるんですよね」と言われることも珍しくないのですが、実際はそうではないので、そこにあるギャップを埋めるしんどさを感じました。 スクラムは生産性を爆増させるものではありません。物を正しく作ろうとすれば当然コミュニケーションを密に取ることになるし、最初はむしろ生産性が下がることさえあります。スクラム体制前のように、最初に詳細な見積もりをし期間を定め、あとは「よーいドン」ではなく、必要に応じてスコープやリリースを変えたりと調整の余地があるのがスクラムの特徴でもあります。そういった点は周囲への説明が難しかったり、理解にギャップがあったと思いますね。
栗原:良かった点もありました。以前は組織やチームの課題に対して何とかしなければと考えていたのは主に在籍期間が長いメンバーでした。後から入社したメンバーは開発やキャッチアップに必死で、チームに対してより良くしようといったことまで目を向けづらいように感じていたのですが、スクラム体制になり少人数のチームとなったことで、自チームをちゃんと作り上げようという思いが強くなったように感じます。例えば、チームでスクラムイベントを開いたり、オーナーを持ったり、スクラムに対してより良くするために意見を出し合ってチームを作ろうという雰囲気になったのはすごく良かったなと思います。
盛:チームの変化をきっかけに輪読会を開催したことも良かったのかなと思っています。今までスクラムを表面的に知っているつもりだったのを、みんなで書籍を元に学び直すなど、共通認識を持てるような取り組みができたのは良い成長だったと思います。
あとは、レトロスペクティブと呼ばれる振り返りの要素は大きな違いですね。 これまではテックチーム定例という場で全員で振り返りを実施していたのが、今はスクラムチームの中で実施するようになりました。そうなると自チームの課題に対して具体的なアクションを決めることができるので、主題であった「自律駆動」に繋がっていると思います。振り返りの要素はスクラムの中で重要視されているので、これは大きな変化ですね。
ーメンバー個々が動くべきことを追求しやすくなったということでしょうか?
盛:そうですね。チームごとに振り返りを行うようになったことの他に、スイッチングコストの問題が解消された点もあります。これまでのようにプロジェクトチームとマイクロサービスチームの2つに属していると、スイッチングコストがかかるというデメリットがあります。自分の働きが0.5ずつになるかというとそんなことはなく、感覚値でいうと0.4ずつくらいにしかならない感じ。結果的に0.2失われてしまいます。スクラムチームという1チームに属し、そこだけに100% 集中すれば良いというのは分かりやすくなりました。
ーチームが分かれていくと、これまでと異なり全体がわからなくなることもあると思いますが、どのように連携をされているのか教えて下さい。
髙橋:現在はテックチーム全体を見る私と清家さん、そして各スクラムチームの中をマネジメントをする Engineering Manager 、といったように階層構造をしっかり作っています。連携に関しては EM 会を開催し、各チームの情報を共有することで問題への対策を打つことができる体制になっています。順調に回り始め、最近は連携が強くなってきたと感じます。
また、Engineering Manager と Tech Lead の責務を明確に分けています。Engineering Manager はピープルマネジメント含めチームのアウトプットを最大化する責務を持ち、 Tech Lead は技術的なオーナーシップを持ってその技術をリードする責務と分けたことにより、カバー範囲が異なり協働もしやすく、能力が最大化されていると思っています。
技術を信じて世界を変えられる集団でありたい。これから目指すこと
ー テックチームのテーマでもある「技術的に卓越する集団になる」とはどのようなことでしょうか?目指している姿を教えて下さい。
髙橋:まず、このスクラム体制になり8ヶ月が経ち、目の前にある開発を十分に作り上げていくだけのチーム力や開発力は既にあると感じているものの、まだまだ品質を高めていく余地はあり、足りていないことがあると思っています。
技術に卓越するということは目の前にあるものをきちんと作り上げていくことと、新たな技術をキャッチアップし自分たちの力に柔軟に変えていけることの2つあると思います。 そのため、今後は新しいことを取り込んでいくことができる文化とそのケイパビリティをこのチームにもたらしたいと感じています。
実現するためには、片っ端から出てきた技術を知るだけでなく、触るのが良いのかなと思っています。 3月に実施した全社合宿が良い機会だったと思っていて、みんな楽しんでやる気持ちはあるので出来ると思います。ただそういうチャンスや時間の問題があり、今回は合宿ということで半分強制的に時間を作った状況ですが、通常はプロジェクトの納期がある関係でなかなか余白を作ることができないのが現状です。自主的にではなくチームとして全員がチャンスや時間を作ることができる仕組みや習慣が必要だと感じています。
清家:技術に卓越する集団であってほしいというのは、CEO の村尾から折に触れて言われるメッセージでもあり、よく考えるのですが、そこにあるのは「テクノロジーで世界を変えられる集団である」ということだと思っています。営業という世界をターゲットとしているので、その世界に精通していないと何も変えられないのではと思うこともあるのですが、大きくイノベーションを起こし考え方を変えていく時に、テクノロジーの世界だからこそアプローチできるものがあり、それを実現できるんだと信じ、挑戦しているというのが、技術に卓越している集団であるということなのかなと思っています。着実に実現していくだけではなく「技術を信じて世界を変えられると思っている集団」でありたい。
なので僕は「技術は How です」と言い切る人はあまり好きではなくて、技術いいじゃん、夢あるよねと思っていますし、夢があるから僕らはこういう仕事を選んでいます。その夢とは、今の成りではたどり着けない世界を ”きっと僕たちは作っていけるはずであり、その中心にあるのはテクノロジーであること” だと思います。Chat GPT を活用したいのではなく、Chat GPT のようなものをつくりたいというのが僕が思うイメージの1つです。どうやって実現できるのか、信じること、というのは難しいですし、夢物語のように感じてしまいますが僕としてはそのように捉えています。
ー夢を持ち信じることは様々な力を生むことができますし、そこに共感している人が今のテックチームにいますよね。
清家:そうですね、技術が好きで、可能性に夢を見る人たちがチームに多いと思っています。また、スクラム体制になった最近は特に生き生きしていて、それぞれが「らしさ」を発揮できるようになってきたと思います。
ー 3月の Magi Tech Day ※ の機能開発はすごかったですね。テクノロジーに無限大の可能性を感じました。テックチームでは、Chat GPTなど新しいサービスに触れる機会になったと思いますがいかがでしたか?
盛:今回の合宿はニーズとシーズがうまく融合したようなテーマだったと思います。 Chat GPT というシーズがあり、Magic Moment Playbook を使う営業担当者の課題をよくするというニーズとも上手く合わさっていました。そのため取り組む意義を感じつつ、 一方で技術ドリブンでなにかを変えていけるという楽しさも感じました。 直接全社メンバーの「おお!」という感動の声や反応を見れたこと、 半日でここまでできるんだぞ。というのを見せられたのはすごく良かったです。
栗原:僕は合宿の際に「これがスクラムチームだよね」と話すことがありました。これまでチームがバラバラだった部分もあったのですが、 合宿で出された1つのお題をみんなで意見を出し合い開発できたことに一体感を感じました。 僕のチームでは一番シンプルな開発案で発表しようとしていたのですが、途中でもっと行ける、もっとみんなに良いものを見せられるんじゃないかと話し合い、予定より実装内容をプラスして発表していました。スクラムチームってこんなに良いものなんだと思えました。
清家:それはそうですね。昨年のスクラム体制になる前にこの合宿をやっていたらブーブー だったかもしれないです(笑)。みんな前向きにやってくれているんだと思いました。
※ Magi Tech Day:2023年3月に全社合宿で開催したメインイベント。事前に Magic Moment Playbook を活用する全社メンバーへ Chat GPT や Slack 連携を利用した新機能のアイデアを募集し、合宿当日にエンジニアメンバーが実装しお披露目まで実施。
実装した新機能はプレスリリースで公開。
▼大規模言語モデル「GPT」の API 連携を活用した、セールスエンゲージメントプラットフォーム「Magic Moment Playbook」の新機能(β版)を開発
https://prtimes.jp/main/html/rd/p/000000023.000072978.html
ー素敵な変化ですね。良い方向に向かっている印象ですが、今後の課題はあるのでしょうか。
清家:本当の意味での自律になっているかというと、そうではないかなと。 まだ目の前のことに一生懸命になっていて、 ロードマップを自分たちで作っていくなど、自主的にやりたいことが出てくるかというとまだそこまでは行けていないです。課題というよりかは次のステップとして自分たちの領域でやりたいことをちゃんと作っていける 、そこに対して全員で共有しながら前に進んでいけるというのが本当の自律だすると、まだまだ階段を登って行かなければいけないところだと思っています。
髙橋:そうですね、テコ入れをしなくてはいけない1つだと思っています。現在ロードマップは私や清家さんがプロダクトチームと相談した上で作ったものをみんなに出していますが、もう一歩進むにはこういう技術を使いたいんだという will を出してもらわなくてはいけないので 、新しい技術を学ぶチャンスや機会をつくる仕組みが次のステップに必要だなと感じます。ある意味1つの崖の前に立ったというイメージだと思っていて、それを乗り越えるために次のステップが何か必要だという段階まで来たのだと思います。チームとして成熟してきたからこそだと思っています。
ーこれから進むステージがさらに楽しみです!最後に、チームの変化も感じられる今、どのような方と一緒に働きたいか教えて下さい。
盛:私はリーダー性がある方とご一緒したいです。元々そういう人は必要でしたが、スクラムチームが良い感じに一皮向けた今、タックマンモデルでいうと統一期に差し掛かっている頃だと思っていて。まだ機能期ではないと考えると、自発的に動いてくれる人や積極的な人、つまりリーダーシップを発揮してくれる人が必要だと感じます。これまでも求めていましたがその想いがより強くなっています。
栗原:チーム・プロダクトの成長が自身の成長であると考えてものづくりができる方と働きたいと思っています。チームビルディングやカルチャー醸成などエンジニアリング以外のところにも積極的に関わって、テックチームを一緒に成長させていってほしいです。シンプルにエンジニアリングが好きというのも個人的には好きです。
髙橋:私は新しい技術を正しく取り入れて価値に変えていける方に来ていただきたいです。先程話した通り、次は新たな技術を使って will を出していくことも必要になります。それを積極的に行ってチームに新鮮な風を入れてもらえると嬉しいです。
清家:今に限ったことではないですが、変化を楽しめる方と一緒に働きたいと常に思っています。組織や技術も、向き合っている顧客や課題も日々変化しています。思っていた通りに進まないことのほうが多いです。そのような状況を常に楽しみ前進できる方と仲間になり、共に新しい世界を創っていけることを楽しみにしています。
ーありがとうございました!