新規プロダクト開発のボトルネックを解消!スクラムマスターがチームの中で果たす役割とは―VideoTouch
※本記事は2021年8月にインタビューを実施し、公開された内容です。2022年12月時点の企業名・役職に更新しています。
「動画の地平をひらき、世の中をポジティブに」というミッションを掲げ、動画を軸として複数の事業を展開しているVideoTouch株式会社(旧:株式会社Viibar)。現在、同社の取締役CTOである浅見さんが指揮を執るのが、動画トレーニングプラットフォーム「VideoTouch」の開発・運営です。
ゼロベースから挑戦したプロダクト事業の推進を支えたのは、FLEXY経由で稼働しているエンジニアやデザイナー、そしてスクラムマスターです。どのようにチーム体制ができあがっていったのか、取締役CTOの浅見亜希子(gaooh)さんにお伺いしました。
目次
開発組織をゼロから立ち上げるために自走できるメンバーを採用
VideoTouch株式会社 取締役CTO 浅見亜希子(gaooh)さん
― 今回、FLEXYが支援させていただいたプロジェクトについて簡単に教えてください。
VideoTouch開発に至る背景として、SaaSをはじめとした継続課金型のサービスが広がりを見せる中では、受け身ではなく能動的にユーザーを成功へと導き、顧客のLTV(ライフタイムバリュー)を高める役割としての「カスタマーサクセス」の重要性が増しています。その中で、カスタマーサクセスが顧客へサービスに関するレクチャーをする際に大きな業務負荷が発生していたため、ユーザーがより直感的にサービスを導入できるよう、従来のマニュアルを動画へと置き換える動きが盛んです。
ところが動画作成自体にも手間暇がかかり、コア業務を圧迫してしまうことがあります。これを解決するために立ち上げたのが、当社の「VideoTouch」です。VideoTouchは、ビデオの収録・編集・共有・分析を低コストで実現。より効果的でスケーラブルなカスタマーサクセスを実現する、動画トレーニングプラットフォームです。
開発は0-1からのスタートだったのでプロダクトチームを作る必要があったのですが、社内にエンジニアは私を含めて2名だけで、MVP検証に必要な機能を実装するためのリソースが不足していました。そこでFLEXYさんから、まずVideoTouchのプロダクト開発に必要だったエンジニアやデザイナーをご紹介いただきました。その後プロジェクト体制をつくるためのスクラムマスターの方もご紹介いただきました。
FLEXYからご紹介したポジション | エンジニア、UI/UXデザイナー、スクラムマスター |
---|---|
案件内容 | 新規プロダクトの開発 |
契約期間 | 3ヶ月〜(更新あり) |
稼働頻度 | 週3日~4日程度 ※1日8時間稼働でない方も含む |
働き方 | フルリモート |
― 最初に採用したのはエンジニア2名とデザイナー1名だったとお伺いしています。どのような基準で採用されたのでしょうか
今回は0-1のフェーズですので、プロダクトの要件や利用技術、開発ルールがしっかり定まっているわけではありません。また、VideoTouchは実際にカスタマーサクセスの部署がある企業にヒアリングをしながら、カスタマーサクセスにおける課題や困っていることを抽出して解決方法を考えようとしていました。
そこで特定の技術に秀でているというよりは、プロダクト開発において何が課題なのかをコミュニケーションを取りながら一緒に考え、自走できる方を優先して採用しました。面談の際も、スキルチェックに加えて、これまでプロダクト開発でどんな動きをしてきたのかを中心にお伺いしています。
ボトルネックを解消する手段としてスクラムマスターを紹介してもらえた
― では、ここからはスクラムマスターであるAさんにフォーカスしてお話をお伺いできればと思います。
Aさんがジョインしたのはどのような経緯ですか?
採用と開発を進める中で私はソフトウェアエンジニアとして手を動かすのはもちろん取締役CTOとして重要で技術的な意思決定やプロセス整備などプロダクトチームとしてのリーダー的な役割を務めていたのですが、徐々にチームの人数が増えるに従って、スクラムマスター的な動きもするようになりました。責務が増えた結果、どうしてもプロジェクト推進において私がボトルネックになることが多くなってしまって。この状態ではエンジニアを増やしてもスピードアップできないと判断し、FLEXYさんからの採用も一旦ストップしていました。この状態を改善するために、スクラムマスターのAさんにジョインいただいたんです。
とはいえ、私からスクラムマスターを探してほしいとご依頼したわけではありません。私がボトルネックになってチームが回らない状態になっていたのを見て、FLEXYのコンサルタントである野谷さん(※)が自発的にAさんを紹介してくれました。
― スクラムマスターの存在は、やはりチームにとって大きいのでしょうか?
そもそもスクラムマスターとリーダーは相反する役割です。リーダーはチームを引っ張って意思決定をする立場である一方、スクラムマスターはチーム自体がどうしたいか、第三者的な立ち位置から問いかける立場にあります。一人が両方の役割を担うと立場の切り替えが大変だというのも、私だけでは上手く立ち行かなかった理由の一つです。
Aさんにスクラムマスターを任せることで私が開発自体や取締役CTOとして重要な意思決定に集中し、Aさんが客観的にチームを見る体制を作れたのは、チームの成長にとって大きなメリットです。特に今回のプロダクトはユーザーの課題解決ができているかを都度ユーザーに聞いて判断しています。Aさんがいることで、スクラムのスプリントレビューにお客様も巻き込んで会話して、フィードバックをもらいながら開発を進める体制が実現できていますね。
スクラムによる密なコミュニケーションに加えモブプロも実施
― FLEXYからジョインしているそれぞれのメンバーはどんな頻度で稼働していますか?
今ジョインいただいているメンバーの方は、週3~4日程度の稼働ですが、コミュニケーション自体は毎日取れるようにしています。エンジニアによっては毎日3時間ずつ、少しずつコミットしてくれている方もいますね。
― フルリモートということですが、コミュニケーションはどのように取っていますか?
スクラム自体がしっかりコミュニケーションを取ることを前提としたフレームワークなので、密にコミュニケーションしています。毎日の朝会と毎週の振り返りに加え、普段は何かあればSlackやDiscordで話しかけて解決するような体制です。
最近はモブプロもやろうとしています。ただ、ずっとオンラインでつながっているとそれはそれで非同期で働くメリットが失われてしまいますし、業務委託の方々は稼働時間も少しずつ異なります。そこでコアタイムを決め、その中でモブプロの時間も定めようとしていますね。
カスタマーサクセスやDX、業務改善に興味がある方には面白い事業
― 先ほどエンジニアやデザイナーの採用軸について伺いましたが、御社のエンジニア組織にフィットするのは具体的にどのような人物なのでしょうか。
必ずしもプロダクトオーナーや他のエンジニアに言うことが正しいとは限らないので、自分の意見を持って、良いプロダクトを作るための議論に参加してもらって、それらの過程を「楽しい」と感じられる方がフィットするのではないでしょうか。またそのように作ったものを仮説検証をした結果「やっぱり違った」ということもありますし、変化を前向きに受け入れられるといいですね。
技術的な面では、言語がTypeScriptとRuby(Rails) ではあるものの、実際作るものはChromeの拡張機能であったり、動画解析処理の関係上、インフラとしてAzureを使っていたりするのですが、社内のメンバーも調べながらだったり、Microsoftのアーキテクトに相談しながら進めることが多いです。動画周りに関してはそれこそ日進月歩で進化が激しい分野でもあるので、単に経験があるというよりは、新しい知識や、技術を学びながら試行錯誤することに抵抗がないと嬉しいです。
もちろん、今まさに事業を立ち上げているフェーズですので、プロダクト自体の理解以上に、プロダクトが解決しようとしている課題やカスタマーサクセス業界に興味があることも大切です。
― カスタマーサクセスが好きなエンジニアというのは、どのような志向性を持った方なのでしょうか。
例えば昔0-1で立ち上げた組織に所属していて、自分でプロダクトを作りながらユーザーサポートをやっていたようなエンジニアは、いかにカスタマーサクセスの業務が大変かを知っています。実際、VideoTouchに対して「当時こんなプロダクトがあったら」と言ってくれる方も多いです。
もちろん直接カスタマーサクセスの経験がなくても、労働集約型で解決していた課題をプロダクトやサービスで解決することに興味がある方も大歓迎です。そういうプロセス改善に興味がある方なら、面白いと感じていただけると思います。
企画/編集:FLEXY編集部