総合二次元コンテンツサービスを展開する株式会社viviONでは、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。

今回は、viviONでクリエイター支援プラットフォーム「Ci-en」の開発や運営に携わる、松永さんにインタビュー。「Findy Team+」でどのような指標に着目しているかや、開発生産性の可視化を通じて、チームにどのような変化があったかなどについて、お話をうかがいました。

クリエイター支援プラットフォーム「Ci-en」を運営

――まず最初に、これまでの簡単なご経歴と現在の役割について教えてください。

松永：新卒でSIerの会社に入り、その後1年ほどで株式会社エイシスに入社しました。エイシスではさまざまなサービスの保守運用や新規開発に携わり、2021年に行われたグループ組織再編のタイミングで、新設されたviviONに転籍しました。2022年4月から「Ci-en」というサービスに携わり、現在チームのリーダーを務めています。

組織の構成としては、Webサービスを担当するWebユニットがあり、そのなかに「Ci-en」のチームがあります。そのWebユニットのリーダーとして、「Ci-en」のサービス運営におけるエンジニアのピープルマネジメントを担いつつ、コードを書いたりコードレビューをしたりといった現場的な作業もしています。

――開発組織全体の規模や、「Ci-en」のチーム体制について教えていただけますか？

松永：組織全体では、60名くらいのエンジニアがいます。「Ci-en」のエンジニアチームは、リーダーの私とメンバーの3名で、合わせて4名。これとは別にデザイナーや、ディレクションチームに属しているPdMを含むディレクターが関わっています。

――現在チームでは、どのようなミッションを掲げていますか？

松永：「Ci-en」というプロジェクト全体としては、クリエイターが自分のやりたいことを実現できるようにしていくという目標を掲げています。そのなかでエンジニアチームとしては、PdMが求めている機能のリリースや改善に、常に満足のいくスピードとクオリティで応えていくことを目指しています。

――それに対して、チームで課題になっていた部分はありますか？

松永：もともと「Ci-en」というサービスが始まったときは、別のリーダーがいて、私がメンバーとしてメインの出力になっていました。ですが、自分がリーダーになったことで、現場業務以外の仕事が増えて、なかなか機能開発ができなくなってしまいました。その影響で、チームとしての出力が落ちている期間が続いていて、そこを改善しようと、まさに今取り組んでいるところです。

――チームで設定されているOKRやKPIはありますか？

松永：「Ci-en」のエンジニアチームとしてはOKRを掲げておらず、事業部全体のOKRに対してアプローチする形をとっています。事業部のOKRでは、Objectivesに「クリエイターが実現したい世界をCi-enでなら叶えられる」というプロダクトのビジョンを掲げています。

Key Resultsに設定されているのは、「このジャンルで活動するならCi-en登録必須と呼ばれるジャンルをつくる」、「ファンを獲得し、クリエイター活動が続けられるサービスになる」、「Ci-enにしかない体験を提供し、新規ユーザーを獲得してクリエイターに還元する」の3つ。そして、この各Key Resultsに対して、それぞれKPIが設定される形になっています。

課題だったレビューの滞りを「Findy Team+」で可視化

――現在チームでは、どのような開発手法をとられていますか？

松永：もともとずっとウォーターフォールで開発していたのですが、ある時期に全社的にアジャイル開発をやっていこうという波がありました。そのときから、「Ci-en」のチームでもスプリントを設定して、2週間ごとにタスクの整理をしながら進めています。 ただ、厳密に決まったスプリントのなかでリリースするわけではなく、ウォーターフォールとアジャイルが混ざっているような形ですね。「Ci-en」のなかで締め切りなどの融通がきくため、必ずしもスピード感が大事ではない部分もあり、ウォーターフォールの名残も強いです。

――開発生産性の計測に取り組み始めたきっかけを教えてください。

松永：結果的に計測が始まった、という表現が正しいかなと思っています。「Findy Team+」を知ったのは、昨年の「Findy Team+ Award」の記事を見かけたことがきっかけでした。それを別のリーダーに共有した結果、気付いたら話が進んでいて、導入してみることになったという経緯があります。

それに加えて、私がリーダーになってから、レビューが滞りがちになっていることがチームのなかで課題になっていました。なので、その部分が数字として見えるのはいいなと思い、計測を始めました。

――そうした課題に対して、計測を始める前に行っていたアプローチはありましたか？

松永：計測前にしていたのは、レビューであまり細かいところまで指摘しすぎないようにすることと、レビューコメントにラベルをつけて、どういう意図の指摘かを明示することくらいでした。

――計測を始めたタイミングで、どういったゴールを設定されていましたか？

松永：ゴールについては、今も明確には決めていない状態です。数字が良くないことはわかっていて、できる限り改善していこうと半年ほど取り組んできましたが、社内の事情もあり、まだ数字が安定しているとは言えません。なので、もう少し期間を見て現実的な良い数字を把握し、それを維持することを目標にしようと今のところは考えています。

――社内の他チームでも、開発生産性の可視化に取り組まれていますか？

松永：他のチームでも、もともと開発生産性に興味があって自発的に取り組んでいるチームもあれば、「Ci-en」で成果が出始めたときに、それを共有したことがきっかけで導入を決めたチームもあります。取り組み方については、各々のチームリーダーが個別に設定して決めています。

――取り組み事例の共有も積極的に行われているのでしょうか？

松永：そうですね。一定のタイミングで部署ごとの発表や開発部内の共有会があるので、そういった場で取り組みの成果を共有しています。そのほかにも、「Findy Team+ Award」に選出されたことを、会社の週報に載せてもらうなどして広めていっています。

取り組みにより、レビューへの意識がポジティブに変化

――チームで見るべき数字として設定された指標や、その指標に決められた背景を教えてください。

松永：レビューの時間に関するところが課題になっていたので、まず最初に変更行数を小さくすることを目標としました。それから、レビューからアプルーブまでの時間を短くすることと、プルリクのオープンからレビューまでの時間を短くすること。この3つを見るべき指標として設定しました。

これは「Findy Team+」のカスタマーサクセスの方に、レビューに時間がかかっている課題について相談した際に、どの指標から見ていくといいかアドバイスをいただき、それをもとに設定しています。

――可視化していくことに対する、チームメンバーの反応はいかがでしたか？

松永：変更行数を小さくしてプルリクが見やすくなったことや、数字として見えるようになったことで、レビューに対する積極性が出てきて、ポジティブな意識の変化があったと感じます。週次で行っている振り返りでも、数字が良くなっていれば喜び、悪くなっていればへこむという感じで、楽しみながらやれている面もあると思います。

――生産性に関連する振り返りは、「Findy Team+」を導入する以前からされていましたか？

松永：導入前は、まったくしていませんでした。これに関しても、カスタマーサクセスの方とのやり取りのなかで、他社での事例を教えていただいて、うちでもやってみようと始めた取り組みです。

――振り返りで数字を見るようになって、難しかったことがあれば教えてください。

松永：影響範囲が広いタスクが発生しているときに、どうしても時間がかかるプルリクがあり、それが如実に数字に出てしまうことがあります。それは仕方がないことなのですが、メンバーがその数字に慣れてしまうと良くないなという危機感はありますね。

一方で、該当するタスクをこなしているメンバーにとっては、数字を悪化させているとプレッシャーに感じてしまう可能性があるので、そこも気にする必要があると思っています。

――そういった場合、メンバーの方にはどのようなフォローをされていますか？

松永：振り返りの場では、そういう性質のものだということを、チーム全体に伝えています。加えて、各メンバーとの1on1でも、個人の責任だと思いすぎないように、頼れる部分は頼ってほしいと、いつも伝えるようにしています。

――振り返りで数字が悪化している傾向が見られたとき、どういったコミュニケーションをされていますか？

松永：該当のプルリクを見て、なぜ時間がかかっていたのか、曖昧にしないようにチームメンバー全員で認識を合わせるようにしています。もしそれが決済のような機能的に重要な部分であれば、時間がかかっても仕方ないものだと確認することもあります。

――週次の振り返り以外でも、「Findy Team+」を見ているタイミングはありますか？

松永：見たいとは思っているのですが、なかなか頻繁に細かいところまではチェックできていません。まだ見れていないページも多いので、今追っている3つの数字がある程度安定してきたら、もっといろいろなところを活用していきたいと思っています。

各メンバーが課題を意識し、自走できるチームを目指す

――開発生産性を可視化することによって、どのようなベネフィットを感じられていますか？

松永：やはりメンバーのレビューに対する姿勢が変化したところが、良かったと思うことの1つですね。それから、数字として見えるようになったことで、常に意識するようになったことも大きいと感じます。

私自身も、リーダー業務が忙しくてレビューを後回しにしがちなところがあったのですが、常に数字を意識するようになったので、それが改善につながっている部分が少なからずあるなと思います。

――取り組みを進めるなかで、メンバーから上がった声があれば教えてください。

松永：導入初期のころ、メンバーからは「小さいプルリクとはどれくらいなのか」といった声がありました。そこを具体的な数字にするのは難しいと思っているので、まずは各々が思う単位でやってもらうようにしました。

厳密に決めていないので、それほど負担にはなっていないだろうと思いつつ、逆に明確な目標がないからこそ難しいと感じる部分もあったかもしれません。

良い反応としては、やはり数字が目に見えて改善されていくことに対する達成感ですね。そういったところは、メンバーからも実際に良い声をもらっています。

――レビューのリードタイムを改善していくにあたって、難しいと感じたポイントはありますか？

松永：まずは、どうしても時間がかかるレビューが存在してしまうことですね。やはり決済関連などのコアな部分は、メンバーだけでなく、リーダーのレビューも通しておきたいと考えています。そのため、重要度が高い部分はレビューに時間が長くかかる状況が続いていて、ここをいかにメンバーで完結できるようにするかは、考えていきたいことの1つです。

また、数字だけを見ていると、すごく改善しているように見えても、実は障害対応でたくさんリリースしているだけだったというケースがあります。そういう数字だけでは見えない実態も、ちゃんと認識して取り組んでいかなければならないなと感じます。

あとは、プルリクを小さくして、複数のプルリクで一連の機能になるときに、小さくしすぎたがゆえにバグが発生してしまったこともありました。単体で見ると問題なさそうに見えたのに、つなげてみたら問題があったというケースで、そういったさじ加減も難しいなと思っています。

――今後のトライについて、現在考えられていることがあれば教えてください。

松永：今お話した課題に関連するところでは、障害対応にチームがかかりっきりになってしまうことがあったので、障害対応とは別にデリバリーラインを確保することを考えています。 また、プルリクを小さくしすぎることを防ぐ観点で、最近は設計段階で一度レビューを挟むように取り組み始めています。あとは、テストをちゃんと書くというところにも取り組んでいこうとしていますね。

――取り組みを通じて、今後目指していきたいチームのイメージがあれば教えてください。

松永：理想としては、各々のメンバーが課題を意識して自走できるようなチームになってほしいと思っています。「Findy Team+」を見て課題を特定し、その改善のためにどういった動きをしていくか、みんなから意見が出てくるようになったらいいですね。

私自身も開発生産性についてはあまりくわしくない状態から始めて、メンバーと近い目線で取り組んできました。あまりあれこれ押し付ける形にならないように進めてきたつもりなので、そこは今後も変わらずにやっていきたいと思っています。

――それでは最後に、組織のアピールポイントや一緒に働きたいエンジニア像を教えてください。

松永：エンジニアだからといって開発業務のみを行っているわけではなく、新機能や改善の提案、新しい取り組みへのチャレンジを全社として推奨しています。自身が担当するプロダクトでゼロからアイディアを出し、実装し、それを数百万人のユーザーに届けられるというのは、非常にやりがいのある仕事だと思います。

アイディアを形にしたい、新しい価値をユーザーに届けたい、とにかくオタク文化が大好き、そういった前向きなマインドを持ったエンジニアの方は、ぜひ一度採用ページを御覧ください！

――松永さん、ありがとうございました！

※viviONでは、エンジニアをはじめとした様々な職種を募集しています。 https://hrmos.co/pages/vivion/jobs

※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。 https://findy-team.io/service_introduction