パーソナルコーチングサービス「mento（メント）」の開発・運営などを行う株式会社mentoでは、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。

今回は、mentoのCTOを務める松山さんと、エンジニアの吉谷さんにインタビュー。「Findy Team+」を導入する前にあった組織の課題や導入後の取り組み、開発生産性の計測のベネフィットをどのように感じているかなどについて伺っていきます。

レビュー滞留による停滞感、結果指標のなさが課題に

――まず最初に、お二人の主なご経歴や現在の業務について教えてください。

松山：2014年に新卒で株式会社リクルートに入社し、ずっとソフトウェアエンジニアとして働いてきました。2019年11月にmentoに入社し、CTOをしています。ロール的には、経営とエンジニアリングのマネージャーですが、チームが小さいのでコードも書いています。

割合としては、経営を2割、マネジメントを4割くらいやりつつ、残りの4割はコードを書いているようなイメージですね。あとは、コーポレートのエンジニアリングのところも、僕が見ています。

吉谷：2017年に新卒で株式会社FiNC Technologiesに入り、3年前にmentoに入社しました。エンジニアとして、スクラムチームのなかでコードを書きつつ、より生産的に活動できるようにチームを改善していくところを主に担っています。

――開発組織の規模や体制、掲げているミッションについて教えていただけますか？

松山：全社の組織規模としては今、正社員が17人。シリーズBの資金調達に向けて動いているところで、ラウンドでいうとシリーズAなので、まだまだアーリーステージのスタートアップです。

開発組織の体制は小さく、正社員は僕と吉谷の2人のみ。プロダクトチームとしては、業務委託で複数名に手伝っていただいている状況で、デザイナーやPdM、データサイエンティストがおり、スクラムチームとしては7人くらいです。

開発組織のミッションは、「Findy Team+」を使って開発のリードタイムを追っていくことと、もう1つは採用ですね。組織で内定承諾の数を採用KPIとして持っているので、今はその2つを組織のミッションとしています。

――「Findy Team+」を導入する前、どのような課題がありましたか？

吉谷：いくつかありましたが、まず1つはチームの形に関する課題です。もともとはスモールチームに、エンジニアやプロダクトマネージャー、Biz側のメンバーもいる構成になっていました。

そのとき、エンジニアのケイパビリティが上手く活きないという課題感があり、それに対してプレッシャーを感じてしまうメンバーもいました。そのため、最終的にはエンジニアチームをつくり、エンジニアリングにフォーカスするという意思決定をしています。

もう1つの課題は、レビューの滞留。レビューする人が属人化してしまっていたり、業務委託の方のプルリクはどうしてもリードタイムがかかってしまったりなど、いくつかの原因からレビューが溜まっていました。それによって、なんとなくの停滞感や上手くいっていない感覚がありました。

松山：レビューの課題に関しては、さらに言うと結果指標がなかったんです。レビューが溜まっていることによって、我々の何が良くない状況になっているのかがわからない。どこか気持ち悪いという感覚はあるけれど、どこにどんな不具合が起きているのか共通認識を持てない、というのが大きな課題の1つでした。

――「Findy Team+」を導入いただいた背景やきっかけについて教えてください。

松山：経緯としては、最初に組織変革の話があり、エンジニアチームを切り出すにあたって、エンジニアチームのKRをどうするか考えていました。アウトプット偏重になりすぎて顧客価値に繋がらないプロダクトを作ってしまうチームにしたくないので、アウトカムの目標を置きたかったのですが、チームを切り出したばかりの状況でいきなりアウトカムまで追おうとすると、チームとして動きづらくなってしまいます。

なので、まずはアウトプットの目標を置こうと考え、そこでグローバルスタンダードな指標であるFour Keysをベースにしようと思ったんですね。ただ、Four Keysを自分たちで可視化するのは大変だと思い、調べてみたところ「Findy Team+」のことを知りました。さらに、イベントでブースが出ていて、実際に「Findy Team+」のデモを見られたので、その次の日に問い合わせました。

定義の議論に時間をかけずに済むことがメリットの1つ

――「Findy Team+」を導入する前、開発生産性の計測に関する取り組みはされていましたか？

松山：していなかったです。基本的には「これくらいのものは、これくらいの期間でつくりたいよね」という何となくの合意があって、それをスクラムのイテレーションのなかでやっていました。振り返りで「もうちょっと上手くできたかも」といった話はあったものの、振り返りの頻度もそれほど高くなく、あまり機能はしていませんでした。

――「Findy Team+」の導入について、どのようにして社内の理解を得ていきましたか？

松山：導入については僕が決める立場にあるので、社長を説得したといったエピソードなどは特にありません。ただ、自分たちでFour Keysを計測するプログラムを書く選択肢もあったなかで、「Findy Team+」を導入することにしたのには理由があります。

KRを決めるとき、そのKRの定義の細かいところを議論したりするじゃないですか。例えば、Four Keysの変更までのリードタイムとは、どこからどこまでなのかとか。でも、その定義を議論している時間は何も価値を生み出していないので、無駄だと思っているんですよ。定義は何でもいいからひとまず決めて、コードを書いていきたいわけです。

「Findy Team+」の場合は、「この項目はこう取っています」と決まっていますよね。なので、まずはそれに全部乗っかって、その数値を良くしていこうと。その改善活動のなかで、指標がイケてないなとか、僕らのプロセスならこういう定義の方がいいなとか、そういうものが出てきたら後から変えていけばいいと考えました。

そうした定義の議論に時間をかけなくて済むところが、「Findy Team+」の良かったポイントの1つ。なので、社内でもその指標に沿ってやっていくことを伝えて、スムーズに導入が進みました。

――導入後に取り組みを進めていくなかで、難しかったポイントはありましたか？

吉谷：「Findy Team+」で見られる指標はたくさんあるので、どの指標をどう見ていけばいいのかという部分が難しかったです。そうしたなか、カスタマーサクセスの方とのミーティングで、「まずはリードタイムから見ていきましょう」とお話いただけたので、そこにフォーカスしていくことができました。

特にリードタイムのなかでも、レビューからアプルーブまで、アプルーブからマージまでを良くしていくといった話ができたことは、すごく良かったと思っています。そこまで決まれば、あとは改善していくだけなので、そこからはスムーズに進んでいきました。

ただ、まだ「Findy Team+」をみんなが主体的に見る状態にはできておらず、僕や松山さんが見てシェアしている状況です。「Findy Team+」はすごく綺麗に可視化されていますし、深堀りがいがあるデータもたくさんあると思うのですが、そこはまだ僕も含めて触りきれていない印象がありますね。

週2回のレビュー会を設け、全員のレビュー優先度をアップ

――レビューの課題については、どのように改善を進めていきましたか？

吉谷：レビューに関しては、特に僕に属人化しているところがあったので、みんなでレビューしていくことと、レビューを優先的にすることをチームで合意しました。具体的には、火曜と木曜に1時間ずつレビュー会を設けて、そこでエンジニア全員でレビューする時間を取っています。

レビュー依頼が来たらすぐにレビューをするのが理想ではあるのですが、コンテキストスイッチもあるので、レビューするタイミングをつくって、レビューが溜まっていたら対応するという意識をつけていきました。

――レビュー会を設けることに対して、ネガティブな反応などはありませんでしたか？

吉谷：レビュー会を設ける前のことを思い出すと、そこに時間をかけていいのかという不安があったように思いますね。コードを書く方が生産的な感じがして、その時間を使ってどうなるのか、あまりイメージがつかないというか。

松山：効率が悪いのではないかという漠然とした不安があるんですよね。それは効率をどう捉えているかだと思っていて、おそらく多くの人が、エンジニアみんなが100%の稼働でコードを書いてるのが効率の良い状態だと思い込んでいるんだと思うんですよ。

それはエンジニアを1つのリソースと捉えたときの効率としては正しくても、ものをデリバリーしていくことを考えたとき、みんながコード書いてるとレビューでスタックしてしまって、デリバリー効率としてはあまり良くなっていないんですよね。

一人ひとりの効率が多少落ちても、レビューしたりQAしたりした方が、世の中に出ていくスピードは上がる。そういう話は、理論的には理解できても、本当に正しいのかという不安がついてまわります。でも、結果指標が可視化されていると、自分たちがやっていることが間違いではなかったとわかるので、そこで自信につながる部分があると思います。

吉谷：加えて言うと、僕自身もリソース効率が100％になっていない状態への不安は、まだあります。例えばレビュー会で1時間取って、エンジニア4人でやっていた場合、僕がレビューを3人に分配するんですよ。

そうすると上手くパスできないタイミングがあって、フロントエンドエンジニアの人は今レビューするものがないけど、10分後から動作確認タイムになる、みたいなことが起こるんですね。そうすると、その10分間はどうしても暇になってしまいます。

そういう何かが止まっている時間ができてしまうことが怖くて、もしこれが10人になったら、何もしない時間が結構あるだろうなと。なので、そういう怖さを認識しつつ、何もない時間には他のことをやっていく必要があるのかなと思っています。

今後はデリバリー効率の改善やデリバリー品質の計測へ

――開発生産性を計測することによるベネフィットをどのようなところに感じていますか？

吉谷：やはり目標に数字が置けることと、それが改善しているかどうかが見えることですね。最初の1ヶ月はあまり変わらなかったのですが、それは溜まっていたプルリクを消化するタイミングだからという共通認識がありました。溜まっていたプルリクが消化できてからは早くなっていって、それが可視化できたので良かったです。

実際に導入初期の2023年11月ではサイクルタイムの合計値は94.8時間でしたが、2024年4月には26.1時間と約1/3以下の数値に改善してきています。

――メンバーの方々の意識や行動の変化を感じた部分はありますか？

吉谷：エンジニアのなかで、レビューを最優先にするという意識づけができました。最近は、OKRにプルリクのリードタイムではなく、JIRAのリードタイムを置いています。なので、エンジニアだけでなくプロダクトマネージャーなども同じように、タスクをなるべく滞留させず、早めにDONEするという意識がついています。

プルリクもそうですが、チケットを細かく分割していくところも、意識や行動の変化の1つですね。小さくチケットを切って、小さくリリースすることが意識的になってきたと思います。

基本的にダークローンチというか、ユーザーに影響がない範囲でどんどん出していくことによって、リリースの頻度も上がりますし、一つひとつのプルリクも小さくなります。「Findy Team+」でも見れていますが、変更行数もどんどん小さくなっていて、レビューに時間かかることが減ってきました。そういったところは良い変化だと思っています。

――プルリクを小さくすることについては、特に声掛けをせずとも自然とそうなっていったのでしょうか？

吉谷：そうですね。自然となっていった気がします。どうしてもレビューの頻度が少なくてリードタイムが伸びると、そこにどんどん変更が足されてプルリクが大きくなってしまいます。ですが、少なくとも週に2回のレビュー会がありますし、その前にもレビューされるので、プルリクが大きくなりにくくなったと思います。

――開発生産性の計測について、今後のトライとして考えていることを教えてください。

吉谷：今はレビュー会を正社員2人、業務委託4人くらいでやっています。今後、エンジニアメンバーが10人、20人と増えていったときにも、これが文化としてキープできているとすごくいいなと思います。

松山：デリバリー効率は健康指標だと思っていて、一定水準まで上がったら、もうそれ以上は求めてもきりがありません。例えば、プルリクの変更行数を5行にしましょう、なんて話は起きえないですよね。

なので、一定水準になったらそれを健康指標として、組織のコンディションが悪くなってしまったときに戻す力学が働くことが大事だと思っています。ただ、今はまだ健康指標にもなっていないので、まずはそこを目指していく段階。それができたら、定点観測していかに維持できるかが重要だと考えています。

もう1つ、Four Keysの文脈でいうと、僕らは現状デリバリー品質の部分が見れていません。直近もエラーが多いという課題が上がってきていますが、hotfix運用をしていなかったりリリースに影響がない本番障害があったりして、今はFour Keysの変更失敗率が「Findy Team+」で適切に取れないんですね。

ただ、ゆくゆくはそういった部分もプラットフォーム上ですべて管理して、我々の目標として追っていきたいので、そこは明確に今後の展望の1つだと思っています。

――それでは最後に、組織のアピールポイントについて教えてください。

吉谷：アピールポイントは、改善活動を気持ち良くできるチームだというところですね。プロダクトやサービスの価値にみんなが向かっていて、そのために改善活動するということを、すごくポジティブに捉えているチームだと思います。

松山：組織の小ささとフラットさは、アピールポイントだと思います。今回お話したような、エンジニアチームを切り出したり、KRにアウトプットの目標を置いたりといった話も、僕だけで決めているわけではなく、ヒアリングしながら吉谷と一緒に決めています。

エンジニアリングの枠に閉じずに、組織の目標をどうするか、採用をどう考えるかといったところまで、一人ひとりがやろうと思えばやれる環境があります。まだまだ小さな組織なので、自分をエンジニアという枠に収めたくない人にとっては、何でもできて面白い環境だと思います。

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

（※最後はチーム全員で写真撮影をして頂きました。）

※現在mentoでは、エンジニアを募集しています。 エンジニア求人　| mento

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