## エンジニアが増えるなか、育成基盤をつくることがミッション

![hokan_interview_0613_1](//images.ctfassets.net/ngrpflsbp3rq/4gSdFXdgUEbw5P9MfcQBt/2cb15b16ef0ddcb6c35eadcc89f3a5f8/1__.jpg)

__――まず最初に、前島さんのこれまでの主なご経歴と現在の業務内容を教えてください。__

__前島__：大学院を出た後、新卒でITコンサルタントの会社に入社し、貿易の帳票管理システムやマスタ管理システムのプロジェクトリーダーとして、追加開発や運用保守に携わっていました。

その後は、スキルシェアプラットフォーム「TimeTicket」の創業期からグロース期にかけて、エンジニアとして参画。その2年後、クリエイティブ特化のクラウドソーシングを展開するMUGENUPからシステム部長としてのオファーをうけ、手を動かすだけでなく、マネジメントも経験しました。

その後、株式会社D2Cのスタートアップに事業全体を見渡す立場で参画したのですが、なかなか事業が思うようにいかない場面も多くありました。そうした中、hokanからお声がけいただき、改めて開発組織でバリューを発揮したい、hokanの経営陣の方々と一緒に働きたいという気持ちから、エンジニアリングマネージャーとして入社。2022年から2024年5月までは、人事責任者を務め、また今年の6月よりエンジニアリングマネージャーとして開発組織の課題解決に務めています。

__――hokanの経営陣の方々と一緒に働きたいと思ったのは、どのような理由からだったのでしょうか？__

__前島__：初めてお会いした時にhokanの経営陣は、すごく徳がある人たちだと感じました。自分たちの利益のためや承認欲求ではなく、hokanに参画してくれる人たちに還元したいと考えている。みんなで成長していこうという思いが強く、とても余裕が感じられたところが大きかったです。

__――現在の開発組織の規模や体制について教えてください。__

__前島__：ソフトウェアエンジニアやSRE、QAチーム、そしてCREというデータマイグレーションを中心に行うエンジニアや、テクニカルサポートエンジニアのチームを合わせるとTech Divisionは30名弱。それらをTech Div.長の小倉、テックリードの新井、CTOの横塚が管掌し、それぞれのチームを統括しています。

__――前島さんが今持っているミッションはどのようなものですか？__

__前島__：Tech Div.では主にエンジニアリングマネージャーとして、エンジニアの採用、イネーブルメント、育成や組織開発を中心に見ています。幸いにもエンジニアの人数が増えたので、これから先どうやって育成し、生産性を向上させていくかが課題です。これはすぐに数値として結果が表れるものではないため、まずは育成の基盤を整えることが直近のミッションです。

__――そうした育成を重視する観点は、会社のカルチャーとしての側面が強いですか？__

__前島__：そうですね。事業モデルがバーティカルSaaSであるため、エンジニアの人数が増えることで売り上げが直接的に伸びるわけではありません。1人当たりの生産性を上げることによって、非連続的な成長を生み出していくビジネスになります。

そのために求められるのは、バーティカルSaaSの場合、ドメインに深く入り込み技術を深めることです。となると、やはり育成が必要です。また、テクニカルスキルだけでなく、ビジネススキルも含めた育成が投資対効果を高めると考えています。

__――開発組織として設定されているOKRやKPIはありますか？__

__前島__：全社の方針に応じて柔軟に変わりますが、1つはスクラム開発におけるアウトプットの量です。例えばこのクォーターでは、ストーリーポイントやインシデント数、QAチケットの消化ストーリーポイント、サイクルタイムなどが指標に置かれています。

![hokan_interview_0613_2](//images.ctfassets.net/ngrpflsbp3rq/6CIVs8Odet0MNbeiXA1n5W/cd3f5b8baf797f4a1f300217dccfeeee/2__.jpg)

## 開発生産性の可視化を始めて、曖昧な議論がなくなった

__――「Findy Team+」を導入いただいて2年ほどが経ちましたが、当初はどのようなきっかけから導入いただきましたか？__

__前島__：そのころから開発生産性については注目していて、モニタリングしていきたいと話していました。ただ、実際に測るとなると、例えばGitHub上でのプルリクのマージまでのリードタイムなどがありますが、そのダッシュボードを手作業でつくるとかなりの手間がかかってしまいます。そういったタイミングで「Findy Team+」を紹介いただいたので、導入を決めました。

__――開発生産性の可視化を始めて、気づきや変化を感じた部分について教えてください。__

__前島__：曖昧な議論をしなくなったと思います。例えば開発が遅いとか、開発は今どうなっているのかと言われたときに、もちろん全体を通して問題や課題は様々ですが、開発のフローの中でどこがボトルネックになっているかなどは具体的な数値をすぐに確認できます。そこで見えた課題を解決していこうという、ビジネス側であれば当たり前の会話が、開発側では曖昧になっていたんですよね。そういう曖昧な会話がなくなったところは、良かったと感じます。

__――「Findy Team+」導入後、多くのエンジニアの方がジョインされたと思いますが、ジョイン後の立ち上がりスピードはいかがですか？__

__前島__：今いるエンジニアの大半は、「Findy Team+」が導入された状態で入ってきていて、ジョイン後の立ち上がりは計測できるようになったと思います。ただし、より成果を出しやすいオンボーディングや細かなゴール設定はまだ整備されていないので、今後はさらにオンボーディング体制を整えるフェーズとなります。
その上で現場のリーダーや私が1on1で状況や進捗を確認しながら、阻害要因なく開発できているかをモニタリングしています。

立ち上がりとしては、今後の施策次第ですが3ヶ月でパフォーマンスが発揮できる人材は数値ベースでいうとスムーズに開発に入れていることがわかります。最初の1ヶ月はキャッチアップして、2ヶ月目に入るときにはもう開発できるようになっていて、問題なく進んでいく状態です。

__――hokanでは、チーム全員でオンボーディングする体制が整えられていると聞きました。__

__前島__：全体の生産性を上げることは、入社前のプレボーディングからオンボーディングによってスタートしていきます。入社当初はわからないこともあるので、基本的に生産性は低い状態が当たり前だと思います。そこからいかに立ち上がりを早くして生産性を向上させていくかというとき、入社前の準備からオンボーディングが重要になります。その中で、同じチームなのに全然話したことがない人がいたら、非常に仕事がしにくいですよね。

そういったことを解消する一つの例として、全員で自己紹介の1on1をしたりしています。一人ひとりが懇切丁寧に教えるというよりは、ちゃんと全員の顔を知って、全員で話す。一緒に働く仲間ですから、全員でオンボーディングするのは当然だと思えるようにメッセージングしています。それ以外に、細かく指示を出したりはしていません。

しかし、組織拡大において出てくる課題解決はこれだけだと不十分になるため、ここからさらにアップデートして、この四半期ではもっと早く立ち上がりが早くなりパフォーマンスが発揮できるようにオンボーディングをアップデートしております。

__――オンボーディングが終わった後、意識すべきこととしてメンバーに伝えている内容はありますか？__

__前島__：メッセージという意味では私からは特にないです。これからやろうとしているのは、アクセラレーションやキャリア開発としてスキルマトリクスでチームのケイパビリティと個々の能力の可視化すること。それが整理されていないと、本人がやりたいことがあっても何を埋めていけばいいかが見えず、曖昧な議論になってしまうからです。

例えば、本人が「自動化テストをやりたい」と言ったとき、フロント側の知見がまったくないのに任せるのは無責任だと思っています。そういうときに、「フロント側の実装経験が少ないから、もう少しこれをやってからにしましょう」と伝えて本人とすり合わせるべきで、そのための土台をつくりたいと考えています。

__――「Findy Team+」導入後に入社された方から、自分のアクティビティやチームのデータが可視化されることに対して、ネガティブな声が上がったことはありましたか？__

__前島__：特になかったですね。可視化しているからといって、他の人と比較してコミットがどうかという話はしていないので、そういった理由もあるかもしれません。

![hokan_interview_0613_3](//images.ctfassets.net/ngrpflsbp3rq/5TzBzSBuucKgQ3kaAJvkXJ/1e378f2afc83f5ef06ebc19392b82750/3__.jpg)

## 人数の拡大や「Findy Team+」の進化に伴った変化も

__――エンジニアの人数が増えて、「Findy Team+」の使い方が変わってきた部分はありますか？__

__前島__：見るメンバーが増えたことで、どうやって「Findy Team+」を活用していくかという話が、より出てくるようになりました。今はまだ、定期的に見て改善していくサイクルが個々のチームでまわっていないので、次はそういったところに進んでいければと思っています。

当初は、プルリクのマージまでやレビューまでのリードタイムを見て、そこがボトルネックだったら改善を進めてきました。ただ、「Findy Team+」もSaaSなので常に進化していて、それに伴って使い方も少し変わってきたところがあります。

今はサイクルタイムという形で、全体のバリューストリームのなかでどこがボトルネックになっているのかわかるようになり、より俯瞰して見られるようになりました。なので、マネジメントする側の人に、もっと活用してもらえるようにしていきたいと思っています。

__――カスタマーサクセスのサポートは、どのように活用していただいていますか？__

__前島__：何か課題があって相談するというよりは、主に情報のキャッチアップですね。今後どういった方向性に「Findy Team+」が向かっていくのか、どのような機能が追加される予定なのか、といったお話を伺うことが多いです。

あとは、こちらからの要望も存分にお伝えさせていただいています。カスタマーサクセスの皆さんは話していてすごく楽しいですし、定例も楽しみながらできているので、そこがすごくいいなと思っています。

__――今後の「Findy Team+」の進化として、期待していることがあれば教えてください。__

__前島__：私や開発責任者が、事業本部会議や経営会議に持っていけるような、レポート機能ですね。もちろんそこは何を持っていくのかという部分もあって、事業報告としてのサマリーなのか、あるいは1人当たりの何々といったものなのかはわからないですが。

弊社では、あらゆるSaaS企業の1人当たりARRを分析していて、自分たちの1人当たりARR※（年間経常収益)が今いくつで、どこまで持っていくべきかを見ています。そこまで見ている開発組織がどのくらいあるかわからないですし、ビジネスモデルもそれぞれ違うなか一律のレポート機能も難しいと思うので、あくまで弊社のニーズかもしれません。

※「Annual Recurring Revenue」、毎年決まって獲得できる収益や売上のこと

__――1人当たりARRを重視するようになったのは、どういった理由からですか？__

__前島__：生産性を上げるとは何かと考えたとき、例として最終的な経営指標になるのは1人当たりARRだと考えています。人数が少なくて収益が上がればARRは伸びますが、当然それだけではないケースがあります。例えば人を大きく増やすとして、1人当たりARRを下げてもいいのか、といった議論も出てきます。

要するに、会社のリソース全体をマネジメントしていくにあたって、1人当たりARRを追っていかないと、事業計画や人員計画が立てられないんですよね。それに、エンジニアが書いた一つひとつのコードが、全体の生産性や会社の利益にちゃんとつながっていることを示すのは、エンジニアを守るためでもあります。

![hokan_interview_0613_4](//images.ctfassets.net/ngrpflsbp3rq/68wi3HtdSp0Pid8V7pTD72/1ebacc48d28dac1fdaa6e56219b48b1a/4__.jpg)

## 1人当たりの年間経常収益や開発生産性を一貫したデータとして見ていく

__――hokanは、入社された方の成長に対する思いが強い会社だと感じます。そういった点で、前島さんが意識していることはありますか？__

__前島__：やはり成長したいと強く思う人には、それだけのチャンスが必要だと考えています。成長するためには個々に合わせた重要な業務による一定の負荷やキャリアマップが必要だと思うので、経営陣とも話してサポートしながら、あえて個人に重たい開発を任せるタイミングもあったりします。ただ、それは一律の育成としてではなく、より挑戦したい人に対して、ファストトラック的に渡しているイメージです。

__――採用する際にも、そういった成長や挑戦への意識を重視して見ていますか？__

__前島__：少しずつ体制が整ってきたとはいえ、シリーズBのスタートアップです。何百万社とある会社のなかで、わざわざスタートアップを選ぶわけですから、一緒に成長していこう、そのために頑張っていこうと貪欲になれる方のほうが、フェーズとしてはマッチしています。

そういう貪欲に成長する気持ちを持つ人に、IPO後に見える景色を味わわせてあげたいという思いもあります。ただ、もちろん全員が全員そうである必要はないですし、そこは組織のバランスですね。成長したい人をちゃんと応援できる体制をつくりつつ、組織のバランスをしっかりと取りながら、選考を進めたりメッセージングしたりしています。

__――hokanの採用では、今ハイレイヤーの方を求めていると思います。そういった層の方々にとって、hokanの魅力はどんなところにあると考えていますか？__

__前島__：一口にハイレイヤーと言っても、組織によって経験できることはそれぞれ異なります。会社としての基盤が整いつつある中で、まだいろいろなことが整理されていませんが、事業がしっかり伸びているというこのフェーズで、マネジメントの経験を積むことはめったにありません。より高いレイヤーでバリューを発揮し、不確実性の高い中で成長していきたい方には、魅力的な環境だと思います。

__――開発生産性の計測に関して、今後のトライとして考えていることはありますか？__

__前島__：事業計画や人員計画としっかりアラインさせた状態での、1人当たりARRの予実管理と、そこから見える開発生産性との一致ですね。そうすることで、開発生産性のどの数値を見ていけばいいのかが、より具体的になってくると考えています。そこが揃っていなければ議論の意味がなくなってしまうので、今見えるデータをどう一貫させて価値を生み出していくのか。そこに尽きると思っています。

__――それでは最後に、御社の開発組織についてのアピールをお願いいたします。__

__前島__：これからは1つのプロダクトだけでなく、どんどんプロダクトを増やしていきます。プロダクトの大きさはそれぞれで、作ってすぐに運用フェーズに入るものもありますし、ゼロイチのものも生み出していきます。

成長中のスタートアップならではの環境も、新規事業もフルスタックで開発していく面白さも味わえる会社です。これから成長していく中で組織も変化していきますし、そういう状況もすごく楽しめると思います。

__――前島さん、ありがとうございました！__

![hokan_interview_0613_5](//images.ctfassets.net/ngrpflsbp3rq/49lgtKkt43TXNslbJt9fmW/20ef16c3757551cf6214e9bdf25eb0fe/5__.jpg)

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

[採用サイト　| hokan](https://recruit.hkn.jp/#375035ce4c594e2eb0860c50910290dd)

※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。

[https://findy-team.io/](https://findy-team.io/)


hokan_interview_0613_FV

適正な営業活動と組織の強固な監査体制を実現するクラウドサービス「hokan®」を提供する株式会社hokan。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用頂いています。  今回はhokanにて6月よりエンジニアリングマネージャーを務める前島治樹さんにインタビュー。「Findy Team+」の導入から2年が経ち、開発生産性の可視化やエンジニア組織の拡大によって、どのような変化があったのか今後のトライで考えている事も含めてお話を伺っていきます。

入社から3ヶ月で即戦力へ。開発生産性指標を活用するhokanの今後のオンボーディングの取り組みとは？

## VPoEとして、急拡大中の組織の成長を支える

__──高井さんのこれまでの主な経歴について教えてください。__

__高井__：私はずっとウェブエンジニアとしてキャリアを積んできました。前職のWebサービスベンチャーで、社内横断の技術部門長をはじめ、子会社のCTO、全社の技術部門の統括など組織方面の仕事へとだんだんとシフトしてきました。その後、より大きな組織に挑戦する機会が欲しいと考え、2021年の12月にマネーフォワードに参画しました。

__──現在の役割、ミッションについてもお話いただけますか。__

__高井__：はじめに会社の体制について簡潔にお話しさせてください。マネーフォワードは、事業部をカンパニーと位置付け、法人向け／個人向け／金融機関向けといった三つのサービスに分けて、それぞれカンパニー（事業部）ごとに開発を進める社内カンパニー制をとっています。各カンパニーのCxOが意思決定を行っており、会社が大きくなってもスタートアップの空気感を残したまま成長を続けられています。

そのなかで、私はエンジニア組織全体を牽引するエンジニアリング戦略室に所属しており、VPoEとしてエンジニア組織全体の課題解決を目指すことを主な役割としています。開発生産性の向上にも取り組んでいるほか、エンジニアの組織制度や評価制度のアップデート、公用語英語化の推進も私の役割です。

またマネーフォワードはここ数年でメンバーが倍増するなど、組織規模が急拡大しています。組織として成長し続けるためには、規模の拡大に合わせて変化を起こしていかなくてはいけません。想像以上のスピードで大きくなっていく組織に対して、必要な仕組みを用意して導入するのが私のミッションです。

![moneyfoward_interview_0603_1](//images.ctfassets.net/ngrpflsbp3rq/4NqoRsFB8MhS7HyALdHvNv/5bdb6b0de6c71a6a61df7132ec5dc514/1__.jpg)

## GitHub Copilotの効果検証に 「Findy Team+」を活用

__──貴社では開発生産性の向上に注力されていますね。そのきっかけはなんだったのでしょうか。__

__高井__：マネーフォワードはエンジニア組織に限らず、会社として成長のために積極的に投資しています。そういった背景があり、エンジニア組織についても投資に対して組織を健全に成長させられているか生産性を見ていきたいという考えがあり、Four Keysを生産性指標としながらさまざまな施策に取り組んでいるという流れですね。

__──「Findy Team+」を一部署から利用拡大されたきっかけについてもお話いただきたいです。__

__高井__：Four Keysはエンジニア組織の生産性を表す指標ではあるものの、エンジニアの活動をつぶさに反映するものでありません。ビルドパイプラインや開発プロセスの改善という一通りの施策が終わった段階で個々人の活動にフォーカスしたいと考えるようになり、[関西開発拠点での導入事例](https://blog.findy-team.io/posts/intereview_moneyforward/)を参考に「Findy Team+」の利用が拡大していきました。

__──ありがとうございます。今回は「Findy Team+」でGitHub Copilotの効果計測をされた事例についてお聞きしたいのですが、その前にGitHub Copilotを導入しようと思われた理由についてもお話いただけますか。__

__高井__：前述の通り、私たちは開発生産性の向上に取り組んでいます。新しいテクノロジーを活用することにも注力しており、その一環として2023年にトライアルとしてGitHub Copilotの利用を開始しました。

GitHub Copilotが開発者の業務効率化につながることは、[GitHub社の調査](https://github.blog/2022-09-07-research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/)や個人としての感想として聞いていていたものの、弊社の業務効率化に繋がるかは不明瞭でした。

また当初は明確なゴールを定めていたわけではなく、「試してみよう」という温度感だったため、いくつかのチームで限定的にトライアル導入をして効果検証を実施しました。

![moneyfoward_interview_0603_2](//images.ctfassets.net/ngrpflsbp3rq/2nkfk4lU5DDOBuFAl5dNDK/a8e4af83eb4b41c95ab3d7ef30e5a585/2__.jpg)

__──当初、GitHub Copilotの効果検証はどのように実施したのでしょうか？__

__高井__：最初はGitHub Copilot利用者にアンケートをとる形で効果検証を実施しました。ただ、アンケートをとっても「効果を感じる部分もあるけれど、おせっかいに感じる部分もある」という曖昧な返答が多く、効果があるのかどうか、アンケートだけでは判断できませんでした。

そこで、希望者に対してはGitHub Copilotを有効にして、利用者が増えた段階で再度アンケートをとりました。すると約42.5%は「明らかに生産性向上に効果がある」と回答し、約51.2%は「一部の用途では開発生産性の向上に効果がある」という回答でした。

![moneyfoward_interview_0603_3](//images.ctfassets.net/ngrpflsbp3rq/7JbN9P87fazMLi8weyIt2I/2309a4925505fe3ea6cc458021c2eaee/3__.png)

多くの人が効果を明らかに感じてはいるようですが、導入を決定するほどの説得力はありませんよね。組織全体の生産性が向上しているのかどうかも判断できず、費用対効果などの面でも依然として疑問が残っていました。

__──目に見えるデータがなければ、会社として投資判断するのは難しいですよね。__

__高井__：ええ。それでどうしたら良いかと考えているときに「Findy Team+」の存在を思い出したのです。利用者と非利用者の生産性を比較すれば、GitHub Copilotの効果を定量的に判断できるのではないかと考え、「Findy Team+」での効果検証に踏み切りました。

## GitHub Copilot導入後の改善効果を一目で可視化へ

__──「Findy Team+」でどのように検証されたのか、お話いただけますか。__

__高井__：最初に GitHub Copilot利用者と非利用者のグループをつくり、そのグループ同士を比較することで何か分からないかと考えました。全体アクティビティを見た瞬間に GitHub Copilot の効果が可視化されているのが、はっきりと分かりました。

![moneyfoward_interview_0603_4](//images.ctfassets.net/ngrpflsbp3rq/69ZitRKZ1jRU9i8fyhUeRR/bbfe41ae0a24579edbf8541aa94e4ac5/4__.png)

出典：[Money Forward Developers Blog「開発生産性が上がるって分かったので GitHub Copilot Business を積極活用しています」
](https://moneyforward-dev.jp/entry/2024/04/17/130000)
このグラフを見ると、GitHub Copilotを使用する前の両者には違いがないものの、トライアル開始後は利用者グループの活動量が増えていることがわかります。

詳細を更に細かく分析していくと、GitHub Copilotの利用者グループの方がプルリクエストの作成数が増加し、コミットからオープンまでの平均時間が短くなっていることもわかりました。つまり、非利用者グループと比べて利用者グループの方が、コードをより多く・早く書けるようになっています。

![moneyfoward_interview_0603_5](//images.ctfassets.net/ngrpflsbp3rq/6CkjiHXjef9m15Ly1IMu2q/a220b1c698be6b7c883917e19670d042/5__.png)

出典：[Money Forward Developers Blog「開発生産性が上がるって分かったので GitHub Copilot Business を積極活用しています」](https://moneyforward-dev.jp/entry/2024/04/17/130000)

Copilot 利用者は非利用者に対して約12%プルリクエスト作成数が多いことが分かり、「コミットからオープンまでの平均時間」、つまり機能開発を開始してからそれを完了させるまでの時間も約7時間ほど短くなっています。

オープンからレビューまで、レビューからアプルーブまでの平均時間は少し上がっていますが、これはプルリクエスト数の増加に伴いレビュー数も増えたことで、待ち時間が増えた形ですね。結果として、機能開発にかかる時間は短くなっていると推測できるので問題ないと考えています。

プルリクエスト数やレビュー数にも増加傾向があり、特にFour Keys に関する指標の一つである変更のリードタイムは大幅に短くなっています。デプロイ頻度が変化しないことについては、プロダクトのワークフローやプロセスによって決定されるものであり、個人の活動量が反映されにくい数値であるからだと解釈しています。

![moneyfoward_interview_0603_6](//images.ctfassets.net/ngrpflsbp3rq/2Rhvh6ssgQkQmVwVc2Y1is/5a63ded56ba5f457bd2aa81cb593715b/6__.png)

変更のリードタイムは、Copilot 非利用者に対して Copilot 利用者は約69.7%となっており、 Copilot を利用することで、より短いサイクルで機能をリリースできるようになっていることが分かります。これは主要指標で、Copilot 利用によって機能開発にかかる時間が短くなるだろうという推測とも一致します。

結論、「Findy Team+」で検証したことによって、 Copilot 利用によって、機能開発にかかる時間が短くなり、より多くの機能を開発できるようになることを強く示唆しています。 Copilot 利用によって、少なくともマネーフォワードでは約10%以上の開発生産性向上が見込めることがわかりました。

GitHub Copilotは個人のコードを書く能力をサポートしてくれるものなのだとわかりました。その結果、個人の主観だけでなく、開発組織全体の生産性の向上につながると確信できたため、現在は全社的にGitHub Copilotの活用を推進しています。

![moneyfoward_interview_0603_7](//images.ctfassets.net/ngrpflsbp3rq/tVFrjpAsoAx8ufAvgoG1Z/2fc6dd8a7bb291eccdbe005db80b2ed2/7__.jpg)

__──効果検証のお役に立ててよかったです。そのほかに「Findy Team+」を使っていて、何か気がついたことはありますか。__

__高井__：GitHub Copilotで改善できる部分とできない部分が可視化できたため、組織の改善部分が明確になりました。それにより、今後の施策を考えるきっかけにもつながりました。ただのアンケートでは、主観的な意見が入ってしまうため、施策が解決したい課題に対して本当に紐付いているのか不明な部分がありました。やはり、数値から分析をしなければわからない点もあるので、非常にありがたいなと感じています。

またデータをもとに費用対効果の算出ができるようになったのも良かったなと。やはり、全社導入するとなるとそれなりの費用がかかってくるため、経営層を説得する際の補助ツールとしても役立ちました。

そう考えると「Findy Team+」はビジュアライズツールとしても優れていると言えるのではないでしょうか。一目で全体の動向を捉えられるツールは他にないでしょうし、EMやマネジメント層の方も十分に活用できるサービスだと思います。

## 更なる事業拡大に向けた、マネーフォワードの挑戦

__──開発生産性の向上に関して、今後挑戦したいものがあれば教えてください。__

__高井__：最近は、生成AIを活用して何かできないかと考えています。GitHub Copilotはコードを書く部分をサポートしてくれるものです。しかし、プロダクトを開発するためにはコードを書くだけでなく、設計やレビュー、テストなど、さまざまな工程がありますよね。そういった分野についても、生成AIを活用して生産性を高めていきたいです。

__──Four Keysを成長指標としている、とお話されていましたね。Four Keys以外でいま注目されているフレームワークはありますか。__

__高井__：特定のものはありません。ただ個人的に一つ言いたいのは、開発生産性の向上を考えたときにアウトカムを追い求めがちですが、それは少し違うのではないかということ。開発の活動は多次元であり、簡単に計測できるものではなく、アウトカムだけを追い求めると本質を見誤る恐れがあると思います。

そもそも、全ての組織に当てはまるフレームワークはないと考えていて。「自分たちは何に困っているのか」「個人レベルの話なのか」「組織レベルで見るとどれほど影響してくるものなのか」「それを解決するためにはどうしたら良いのか」「解決できているか計測するためのフレームワークはどれか」といったことを一つひとつ突き詰めていって、自分たちの組織や課題にあわせて最適なものを選ぶ必要があるのではないでしょうか。

新しい指標が出てくると挑戦したくなることもあると思うのですが、ユーザーに価値を届けるため、組織を成長させるためには、冷静に見極めることが大切だと思います。

__──ありがとうございます。最後に、組織のアピールポイントや一緒に働きたいエンジニア像を教えてください。__

__高井__：マネーフォワードは「User Focus」をバリューとして、プロダクト開発に真摯に取り組んでいる組織です。ただ、事業領域の拡大とそれに伴う組織規模の成長が非常に早いため、組織として整えるべきところも少なくありません。2024年11月までに達成することを目標として英語化を進めているところでもあり、変化していく部分も多くあります。その分、一人ひとりが貢献できる機会が多いのも魅力ですし、組織づくりに携わりたい人にはとても面白い環境です。

また、今まではSaaS市場の成熟に合わせてプロダクトを数多くつくってきましたが、それらが軌道にのり規模が大きくなってきています。サービスの共通化や標準化を進めたいと考えているなかで、より生産性を向上するためにも“エンジニアのためのエンジニア”を必要としています。

「すべての人の、『お金のプラットフォーム』になる。」というビジョンに向けて、ともに挑戦を続けてくださる方にジョインしていただけることを願っています。

__──高井さん、ありがとうございました！__

![moneyfoward_interview_0603_8](//images.ctfassets.net/ngrpflsbp3rq/2BzBvz6GpHOoyhMKgqb3U6/a2b9cb3528107d8ac212911c84c79846/8____2_.jpg)

※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。

[https://findy-team.io/service_introduction](https://findy-team.io/service_introduction)


moneyfoward_interview_0603_fv

個人向けPFMサービスや法人向けバックオフィスSaaSなど、金融系サービスを幅広く開発・提供している株式会社マネーフォワードでは、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。  今回は、開発生産性の向上に関する取り組みを推進しているVPoEの高井さんにインタビュー。GitHub Copilotの効果検証としても「Findy Team+」を活用された事例について、お話をうかがいました。

GitHub Copilot導入効果をFindy Team+で定量的に可視化。 マネーフォワードの全社的な開発生産性向上に向けた取り組みとは？

icare_interview_0530_FV

クラウド型健康管理システム「Carely（ケアリィ）」の開発・運用を行う株式会社iCAREでは、個人の振り返りやエンジニア組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用頂いています。今回はiCAREにてCTO/Development部部長を務める工藤大弥さんと、クラウド産保(さんぽ)支援開発チームでリーダーを務める澁谷恭平さんにインタビュー。「Findy Team+」を導入した背景や、計測を浸透させるための取り組み、開発生産性の数値をOKRに組み込んだ結果等について伺いました。

リードタイムを60時間から3.7時間に短縮。働くひとの健康を創るiCAREが取り組む開発パフォーマンス改善の可視化とは？

## 世界中の産業のデジタルトランスフォーメーションを目指す「エムシーデジタル」

__――最初に、皆さんのこれまでのご経歴や現在のロールについて教えてください。__

__中田__：千葉大学大学院融合理工学府博士課程を修了後、2021年4月に新卒でエムシーデジタルに入社しました。現在はエンジニアリング部門長を務めております。

__伊藤__：東京工業大学情報理工学院情報工学コースの修士課程を修了後、2022年4月に新卒でエムシーデジタルに入社しました。エンジニアリング部門のメンバーとしてプロダクト開発に携わっています。

__江﨑__：東京大学大学院情報理工学系研究科の修士課程を修了して採用プラットフォームサービスの機能開発・運用に従事していました。その後、2023年8月にエムシーデジタルに入社し、エンジニアリング部門のメンバーとしてプロダクト開発に携わっています。

__――御社の組織規模や、開発チームの体制について教えていただけますか？__

__中田__：組織規模は、全体の従業員数が約80名で、従業員数の過半数はデータサイエンティストやソフトウェアエンジニアが占めています。設立が2019年と新しく、平均年齢は約30歳と若手が多いです。

![1枚目_エムシーデジタル](//images.ctfassets.net/ngrpflsbp3rq/hXfW6CijqFVJwcUEr4jee/be881e7b1f6214c1a9b05baf2bdc28bd/1____1_.jpg)

__――エムシーデジタルでは、どのようなミッションを掲げていますか？__

__中田__：エムシーデジタルは、三菱商事株式会社の100%出資により設立された会社で「テクノロジーでビジネスモデルをアップデートする」ことをミッションに掲げ、三菱商事グループをはじめとしたあらゆる産業のDXを推進しています。

三菱商事グループが蓄積してきた膨大なインダストリーナレッジを元にデジタル技術を活用し、世界規模での事業変革を目指すと共に、これらの知見を元にビジネスモデルを外部にも展開することができると考えています。

具体的には、AI・数理最適化を活用したシステムや BtoB SaaSを、三菱商事が手がける多様な業界および世界各地の企業へ提供し、DXを実現することを目指しています。

__――皆さんが所属されているチームについて、教えていただけますか？__

__江﨑__：私は製造業向けのサービスを開発するチームに所属しています。チームでは「属人性や人手不足の問題を抱える製造業において、業務効率化によるものづくりの品質改善やコスト削減を実現すること」を目指しています。製造業における工程の最適化モデルを構築し、業務を改善するためのプロダクトを提供しています。

__伊藤__：私は物流業界向けのプロダクトを開発するチームに所属しています。物流業界には、「2024年問題」と呼ばれるドライバーのリソースの制限から生じる課題があり、私たちのチームでは、この課題の解決に向けた最適化のためのアプリケーションの開発を進めています。

![mcdigital_interview_0527_2](//images.ctfassets.net/ngrpflsbp3rq/5BgjQFGZdWd8NUWo2m1aYo/4e51226d4fbc298140386b293be5e860/2____1_.jpg)

## 今後の事業成長を見据えた開発生産性の計測

__――会社として開発生産性の計測に取り組み始めた背景は何でしょうか？__

__中田__：今後チームが増えていくことを想定し、複数のチームの状況を簡単に把握できるようにしておきたいと考えたことが、開発生産性の計測に取り組み始めたきっかけです。

開発生産性を定量的に可視化し、チームで振り返るプロセスを浸透できれば、開発者体験や開発プロセスを各チームが自律的に改善できる組織にしていけるのではないかとも考えていました。

__――エンジニアとして、開発生産性の計測について興味を抱かれた背景と「Findy Team+」を導入されたきっかけと最終的な決め手を教えてください。__

__中田__：開発生産性に対する興味は以前からあり、GitHubインサイトは定期的にチェックしていました。また、先ほどお話ししたように弊社のチームが増えることによって、私が直接マネジメントしているチーム以外の状況も把握する必要もありました。
そのため、これまで行ってきている1on1やチームミーティングによる情報収集以外にも開発生産性を計測することによって、各チームの状態を定量的に把握したいと考えておりました。

そんな時に、Findyさんが主催する開発生産性に関するセミナーに参加し、エンジニア組織の開発生産性の計測ができるツールがあることを知り、本サービスに強い興味を抱きました。
Findyの担当者様と導入後の運用方針やモニタリングしていく指標について相談していく中で、利用できるイメージが掴めたことが最終的な決め手となりました。

__江﨑__：チームに「Findy Team+」を導入しようと思ったのは、チーム内で開発プロセスについて客観的な指標をもとに議論したかったからです。

現在関わっているプロジェクトでは、ユーザーのフィードバックを迅速にプロダクトに反映させるフェーズにあるため、開発生産性が重要となっています。生産性向上のために開発プロセスを改善するにはメンバーの協力が不可欠であり、納得して改善に取り組んでもらう必要があります。

そこで、数値に基づいたアプローチを取り入れたいと考え、開発生産性の計測に興味を持ちました。弊社はアルゴリズムや理数系に特化したメンバーが多いこともあり、チームメンバーから導入に対する抵抗はなく、興味を持って一緒に指標を追ってくれました。

__伊藤__： 江﨑が言うように、エムシーデジタルにはアルゴリズムに精通したメンバーや、高い技術力を持つメンバーが多数在籍しています。そういったメンバーが適切にパフォーマンスを発揮し、プロダクトの品質向上と価値提供に繋げるための仕組みづくりに関心がありました。

そのため、現状を定量的に分析する一つの方法として、開発生産性の計測に注目していました。

![mcdigital_interview_0527_3](//images.ctfassets.net/ngrpflsbp3rq/6PWlMEAKdgtwb1ezVjRa79/7327e4cc10ad82ca14ab43a40fe7ab25/3____1_.jpg)

## 「Findy Team+」導入後、サイクルタイムが20%近く改善

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

__伊藤__：定量的な開発の振り返りはほとんどしていませんでした。各メンバーがそれぞれ定性的に課題を感じていましたが、その原因を言語化し、具体的な改善に向けたアクションまで落とし込むことが難しかったです。社内の他のチームでも同じような課題を抱えていたように思います。

__江﨑__：私のチームでもまさにその課題感はありましたね。

__――「Findy Team+」導入後、チームの生産性に変化はありましたか？__

__江﨑__：私のチームではプルリクエスト（PR）がオープンされてからマージされるまでの時間が20%近く改善しました。
チーム全体のサイクルタイムが可視化されたことで、開発プロセス内での課題を見つけやすくなったことが改善の理由だと考えています。

具体的には、1週間のスプリントが終わった後に「Findy Team+」でPRの一覧を全員で確認し、特に「オープンからレビューまでに24時間以上かかったPR」や「レビューからマージまでに24時間以上かかったPR」に注目して、その時間を要した原因をディスカッション・分析したことが生産性の向上につながりました。

![mcdigital_interview_0527_4](//images.ctfassets.net/ngrpflsbp3rq/1pRvcLNEwmqRE9wyqEeTRK/37c2ab4b4569cb8979470891ef7fed63/4____1_.jpg)

__中田__： チームメンバーが改善したいポイントや改善に向けた行動を提案してくれる頻度が増えたと感じます。定量的な指標と改善の余地がある特定のPRについて振り返ることで、課題を深堀し改善案を考えやすくなったのではないかと推測しています。

## 「Findy Team+」の活用を広げながら、全社的な可視化へ

__――可視化の取り組みや「Findy Team+」の活用について、今後の展望を教えてください。__

__中田__：各チームが自律的に開発者体験やプロセスを改善できる組織にしていくために、可視化を活用できるチームを増やしたいと考えています。また、個々のチームの振り返りだけでなく、チーム間で学びを共有する際にも可視化を活用していきたいです。

__江﨑__：私のチームではサイクルタイムが安定した良い数値で推移できています。今後は他の指標にも目を向け、実際にアウトプットが増えているのかを定量的に追跡し、自分たちの成長を確認していきたいです。
また、他のチームにも再現性のある開発生産性向上のナレッジを共有できたらと考えています。

__伊藤__：私たちは、組織全体としてのプロセスの課題に取り組んでいきたいと考えています。そのためには、チームだけでなく組織全体で開発生産性を可視化し、データとして蓄積することが重要です。

まずは私たちのチームから取り組みの成果を出し、そのアプローチを他のチームでも活用できるように模索しながら広げていきます。
そして最終的には、開発組織の各チームの生産性をデータで確認できる状態を目指しています。

![mcdigital_interview_0527_5](//images.ctfassets.net/ngrpflsbp3rq/6iH6Xx7CX14Eaw3eElipis/bcf177e2c9c0651dc239803b78747aaf/5____1_.jpg)
__――それでは最後に、御社の組織のアピールポイントや、一緒に働きたいエンジニア像を教えてください。__

__中田__：エムシーデジタルには、優秀で学習意欲の高いエンジニアやデータサイエンティストが多く在籍しています。お互いに知見をシェアしたり、ほかのチームでも課題を解決するサポートをしたり、切磋琢磨しながらよりよいものを作ろうという姿勢の社員が多いと感じています。
実社会の産業に価値を提供することに関心を持って取り組めるエンジニアの方と一緒に働きたいと思っています。

__伊藤__：オフィスでは、技術の勉強会から、趣味の活動会、真面目な座談会からカジュアルな雑談まで、さまざまな催しが頻繁に開かれています。開発プロセスに関する座談会もその一つで、他にも例を挙げると、機械学習や数理最適化を専門とするメンバーが最新技術の勉強会やコンペ・コンテストの反省会を開催しています。
また、ビジネス職と技術職が一緒にプロダクト開発の方法論について学び、議論を深める機会もあります。

一方で、ボードゲームやボルダリングなどのアクティビティを通して社員同士の交流を図るZ活動と言われる部活動や、単にお酒を愉しむような緩い催しも定期的に開催されていて、とても賑やかな雰囲気だと感じています！

__江﨑__：弊社では、個人の力を発揮しつつチーム・組織全体で成長することを大切にしています。例えば、月に一度「ENジョイ技術の日」というイベントがあり、技術力向上を図るために普段手が付けられていないことや、やってみたかったことにも挑戦ができます。

また、自己研鑽やチームビルディングの一環として、有志で集まって行われる勉強会などの活動に対する補助制度も用意されています。個人としても、組織で働く上でも成長したいと考えている方と一緒に働けたらうれしいです。

__――皆さん、本日はありがとうございました！__

![mcdigital_interview_0527_6](//images.ctfassets.net/ngrpflsbp3rq/5UCyFrd39dz2K8z6YdybVG/230cc7b23e713bcadac478255ce10dff/6____1_.jpg)

__※エムシーデジタルでは、エンジニアを募集しています。__

[エムシーデジタル｜Careers](https://www.mcdigital.jp/careers/)

__※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。__

[https://findy-team.io/service_introduction](https://findy-team.io/service_introduction)


mcdigital_interview_0527_FV

最新のテクノロジーや高度なアルゴリズムを駆使して企業の課題解決に取り組むプロフェッショナル集団、エムシーデジタル株式会社。同社では、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。   今回は、エムシーデジタルでエンジニアリング部門長を務める中田さん、ソフトウェアエンジニアの伊藤さん、江﨑さんにインタビューを実施。開発生産性の計測に取り組んだ背景や、「Findy Team+」の活用方法などについてお話をうかがいました。

Findy Team+導入から半年でサイクルタイムが20%近く改善。全社的な開発生産性向上を目指すエムシーデジタルの取り組みとは？

## より良い振り返りや改善のため、開発生産性の計測を開始

__――最初に、お二人の主な経歴や現在の役割について教えてください。__

__すがわら__：新卒で入社したSIerに5年ほどいた後、toCサービスの会社に入り、サービスの立ち上げから運用まで10年ほど携わっていました。その後、SmartHRに入社しています。役割としては、「Findy Team+」の導入を最初に検討したときは、チーフをしていました。実際に導入したときはマネージャー、今はダイレクター（本部長）というポジションです。

__上月__：私も最初はSIerに10年ほどいて、その後はECのD2Cモデルの事業会社に5年務めていました。その後、SmartHRに入社して今に至ります。「Findy Team+」導入の検討当初はメンバー、導入時にはチーフをしていました。現在はマネージャーをしています。

![smarthr_interview_0507_1](//images.ctfassets.net/ngrpflsbp3rq/4U1drAnhctOxum5Cnkzmmg/ba6c45f858b358d834b3b4b8cc72a773/1__.jpg)

__――開発組織の規模や体制について教えていただけますか？__

__すがわら__：エンジニア組織全体としては、130人くらいの規模です。そのなかに、30人〜40人くらいの基本機能チームと、 そのほかにオプション機能チームなど10数チームがあり、「Findy Team+」の導入を最初に考えたのは基本機能チームでした。（※人数は2024年5月時点）さらに、オプション機能チームのなかにも、いくつか使ってみたいというチームがあったので、一緒に導入を進めてきました。

__――どのような背景から開発生産性の計測を始められたのでしょうか？__

__すがわら__：我々は普段スクラムで開発していて、振り返りなどを通じて改善をしていました。一方で、定量的に計測したものはあまりなく、必要であれば都度手で集めることが多かったんです。なので、定量的に見えるもの、かつ自動で集計できているものがあると、より良い振り返りや改善ができるのではないかと思っていました。

それから、世間一般のアベレージや、それと比べて自分たちがどうなのかを知りたい。より強い開発組織やチームを目指していくうえで、より多くの材料が欲しいといったところもモチベーションとしてありました。

より早く価値を提供していくために改善できることは何かと考えるとき、もちろん普段の振り返りやスクラムの各イベントも重要ですが、実際にコードを書くこともまた重要なポイントです。なので、そこも含めて定量的に見れたほうがいいだろうという考えがありました。

## 正確性や柔軟性の高さが「Findy Team+」導入の決め手に

__――SmartHRさんでは「Findy Team+」を一度検討いただいたあと、再検討のタイミングで導入いただきました。最終的には、どのようなところが決め手になりましたか？__

__すがわら__：最初に検討したときは、プルリクにラベルが付与されているものを計測対象とすることはできたのですが、特定のラベルがついているものを除外するということはできませんでした。我々としては特定のラベルがついているものを除外する仕組みがあるととても助かると思っていたのですが、それに関してはその時点で「近々開発予定です」という話を聞いていて、再検討したタイミングではもう使えるようになっていました。

それができると我々のスクラム開発で、1スプリントのなかで何が起こったかが精緻に取れるようになります。なので、そういった正確性や柔軟性の高さは、「Findy Team+」導入の決め手の1つになりました。

また、セールスやカスタマーサクセスの皆さんが、期待値の調整などを事前に丁寧にしてくださって、一緒にやっていけそうだと思ったことも大きいですね。

![smarthr_interview_0507_2](//images.ctfassets.net/ngrpflsbp3rq/4rt6YvSBEhzm0iNti0Fjfj/1a940697ade499d528756819e4249705/2__.jpg)

__――実際に現場で使っていく目線として、上月さんがトライアルで見ていただいた際はどのように感じられましたか？__

__上月__：私はもともと前職で「Findy Team+」を使っていたので、どういうものかわかっていました。前職では、経営層への説明などが主な導入の理由になっていたので、それとは少し異なりますが、弊社は組織が急成長しているフェーズなので、導入したほうがいいと思っていました。

急激なペースでメンバーが増えていくなかで、組織のパフォーマンスを維持できるのか、もしくは向上させていけるのかを、定常的にモニタリングしておきたい。それが拡大する組織のなかでも、パフォーマンスの維持や改善を続けていくケイパビリティを得る手段の1つなのではないかと考えていました。

アプリケーションのモニタリングでもオブザーバビリティという言葉がありますが、しっかりと見える状態にして、悪化したら手を打てるようにしておきたいというイメージですね。

__――「Findy Team+」の導入によって、どのようなことを実現したいと考えられていましたか？__

__上月__：バイタルチェック的な使い方は前提としてありつつ、そもそも導入した当初から、それなりにスコアは良かったんですね。ただ、伸びしろもあると感じていて、その伸びしろを差分として見ることができれば、そこにしっかり取り組んでいける組織だと思っていました。

それを言葉だけで伝えるよりも、定量的に共通して見られるものがあったほうが説明しやすくなります。なので、そうした部分をちゃんと見せて、取り組みに対するモメンタムを醸成していきたいという考えがありました。

__すがわら__：僕も同じですね。特に共通して見られるものがあると、各チームでお互いに参考にしやすくなります。また、似たような取り組みに対しても、それぞれのチームで違うことをやっているケースもあるので、そういった話ができるところがいいなと思っています。

## チームでの理解を深め、「Findy Team+」の導入と推進へ

__――「Findy Team+」の導入後、チームの理解をどのように得ていきましたか？__

__すがわら__：最初に検討したときに導入を辞めたのは、チームの理解を得なければ難しいと思ったことが、理由の1つとして大きくありました。なぜかというと、単に数字だけを見てしまうとハックできてしまい、それによって達成した数字にはあまり意味がないからです。

そのため、社内で『LeanとDevOpsの科学』という本の読書会を開催しました。そこで、Four Keysにはどういう意味があるのか、その数字が僕らエンジニアにどういう影響があるのかといったことを、まずインストールしていきました。今は実際に、その読書会に参加したメンバーが「Findy Team+」の導入を推進してくれています。

__――より「Findy Team+」の活用を定着させていくために、工夫されていることはありますか？__

__すがわら__：基本機能チームとオプション機能チーム、それぞれのなかで「Findy Team+」の利用を推進しているメンバーが集まる、隔週のミーティングを設けています。緩い社内コミュニティのようなイメージですね。そこでお互いのチームがやっていることや悩んでいることを話して、お互いの知見を共有したりしています。

Findy Team+の活用を定着させていくための取り組みは、チームのなかで誰か1人がやろうとしても、なかなか上手くまわらないものです。なので、どうやって進めていくかを話し合ったり、チーム内に興味がある人がいたら一緒にやっていきましょうと話したりなど、プロジェクトを進めるための相談をする場になっています。

__――上月さんがチームでの取り組みを進めるにあたって、意識されたことはありましたか？__

__上月__：チームの状況に合わせて伝えることを意識していました。チームではモブプロを中心に行っていて、チームレトロという週に1回の振り返りの時間で、「Findy Team+」のグラフを見せています。そこで、やみくもに「ここを改善しましょう」と言うのではなく、「今週はこういう活動が響きましたね」と伝えるようにしています。

そうやってチームの状況に合わせて、サブリミナル的に情報を入れていくような伝え方を意識していました。あとは、取り組みに興味がある新しいメンバーが入ってきてくれたので、そのメンバーを含めて推進をより強めていった形ですね。

![smarthr_interview_0507_3](//images.ctfassets.net/ngrpflsbp3rq/23leGTs8lXha9YkzN9YSJ3/e1f3ef55b7db2de7fb17f4de93625697/3__.jpg)

__――メンバーの方から、数字で見ることに対するネガティブな反応はありませんでしたか？__

__上月__：特になかったですね。モブプロで進めているので、もともとサイクルタイムを中心に見ていましたが、HighやEliteに近い数値が出ていたので、「悪くないね」といった感じで見ていました。

__――最近では、OKRやKPIとして定量的な数値目標も設定されていると伺いました。__

__上月__：プロダクトエンジニアのスローガンとして、デリバリーをより早めていくことを掲げていて、全社的なスローガンもそれに近いものが出されています。そこで今期は、プロダクトのOKRにもデリバリーの目標を設けることにしました。

それまではPdMを中心にOKRを行っていたのですが、そこにエンジニアも加わり、デリバリーの目標を持つ形で一気に進みました。積極的に個人ミッションにそれを入れる人も増えています。

## 協力体制をつくり、取り組みの事例化や体系化を狙っていく

__――開発生産性の計測に関して、今後のトライとして考えていることはありますか？__

__上月__：今回OKRのKey Resultに定量的な数値を置いたのですが、そもそも今の数値はそれほど悪くなく、かなりストレッチしてEliteを目標としています。ただ、それを目的にするというよりは、どちらかというと取り組みの事例化や体系化を狙っています。

今4チームで共同のOKRを持っていて、4チーム内で取り組みを共有する協力体制をつくっていこうとしているんですね。それが文化として根づけば数字は後からついてくると思っているので、社内の資産になるように、そういった取り組みを重要視したいと考えています。

__すがわら__：開発生産性をどう考えたらいいのかという、考え方のベースになるものを発信していく必要があると思っています。例えば、デュアルトラックアジャイルを行っていくにあたっては、ディスカバリーとデリバリーのどちらかだけが早くても仕方がなく、両方が早くなければなりません。

そのためには、どこが「Findy Team+」で見えて、どこが別のもので見えるのか。あるいは、結果として「Findy Team+」ではこういうふうに数字が出るはずだとか。そういう共通認識を持てるようにしていきたいと考えています。

![smarthr_interview_0507_4](//images.ctfassets.net/ngrpflsbp3rq/6twl4OER5qq5d6z65Zm8v8/dd18a3a9c45aa66ba72cc8eb6cd9d0a8/4__.jpg)

__――改めて、「Findy Team+」のおすすめポイントがあれば教えてください。__

__すがわら__：いくつかありますが、1つは簡単に計測できるところですね。もう1つは、欲しい機能が今なかったとしても、つくってもらえるという期待値。先ほどお話ししたラベル除外の話もそうですし、最近だと土日を省くことができるようにもなりました。

そういう機能は、なければないで仕方がないと思いつつ、あったらやはり嬉しいものなので、実装してもらえてすごくありがたいです。あとは、カスタマーサクセスの方々にも、いろいろとお世話になりながら何とか進めてこられているので、そういった点でも助かっています。

__上月__：自分も簡単に計測できるところですね。自前で計測しようとするといろいろ大変ですが、「Findy Team+」は導入にほぼ手間がかからず、すぐに見られるようになるところが大きいと思います。

あとは、最近新しく追加された機能も含め、チームのプロセス改善の機能も充実しています。レビュー分析などもそうですが、計測するだけでなく、それを振り返るプロセスも含めたプロダクトになっていくのかなと思うので、今後も期待しています。

![smarthr_interview_0507_5](//images.ctfassets.net/ngrpflsbp3rq/5cKcfKox51heQD4yV7hG2b/d8a1036c2e8e100c14447d506ceb6d33/5__.jpg)

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

__すがわら__：『LeanとDevOpsの科学』を読むと、組織文化が大事だということが書いてあります。実際にそうだと思うし、それを自分の会社に当てはめてみると、すでにそうなっていることがすごく多いんですよね。

なので、生産性を考えるにあたって組織文化から変えていく必要はなく、すでにもうできているので、あとはもっとエンジニアとしてやるべきことをやっていくという状況です。こうした組織文化の良さは、アピールポイントの1つだと思います。

__上月__：SmartHRはマルチプロダクトをやっていく方針なので、プロダクトのフェーズとしても、新規プロダクトから基本機能のように長く続いている大規模なものまで、さまざまあります。

なので、いろいろな人にとってやりたいフェーズや、やりたいことが当てはまるのではないかなと。そういったなかで開発していきたい人、開発生産性を高めていきたい人はマッチすると思います。

__――すがわらさん、上月さん、ありがとうございました！__

![smarthr_interview_0507_6](//images.ctfassets.net/ngrpflsbp3rq/2aibvB9p2wfB87MLAkgYsG/80415847f83786cbdc6d9e48d841e40d/________.jpg)

__※現在SmartHRでは、エンジニアを募集しています。__

[エンジニア採用  |  SmartHR](https://recruit.smarthr.co.jp/work/engineer/)

__※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。__

[https://findy-team.io/](https://findy-team.io/)


smarthr_interview_0507_FV

クラウド人事労務ソフト「SmartHR」を開発する株式会社SmartHRでは、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。  今回は、SmartHRでディレクターを務める菅原さんと、マネージャーの上月さんにインタビュー。開発生産性の計測を始めた背景や「Findy Team+」導入の決め手、チームで取り組みを推進するための工夫などについて伺いました。

エンジニア組織のパフォーマンスの健康診断に。「より強い組織」を目指すSmartHRの開発生産性向上に向けた取り組みとは？

## テクノロジーを駆使して生活者が主役となる医療体験の実現を目指すPharmaX

__――まず最初に、皆さまのこれまでの主な経歴や、現在の業務内容について教えてください。__

__上野__：大学・大学院在学中の頃は研究室やインターンなどに取り組んでいました。その過程でやりたいことを実現していくために、統計や機械学習、データ分析、アプリケーション開発を独学で習得しました。2018年に新卒でコンサルティングの会社に入社した後、同年にPharmaXを共同創業しました。立ち上げ初期から開発を担当してきて、今は2事業部のチームを統括する傍ら、生成AI/LLM（大規模言語モデル）を駆使した事業推進・情報発信にも取り組んでいます。

__古家__：新卒でニフティ株式会社に入社、新規事業開発部でのスタートアップ支援やベトナムでのオフショア組織立ち上げ・マネジメントなどを経験しました。退社後にフリーランスとして独立してITスタートアップのグロース支援に従事してから、PharmaXにジョインしています。PharmaXに入社してからはデータエンジニアとしてのダッシュボード整備・データ活用推進に始まり、スクラムマスターを経てエンジニアリングマネージャーを担当しています。

__江田__：趣味の延長でプログラミングをするようになったのがきっかけで、在学中からバックエンドエンジニアとしてPharmaXでインターンをしていました。率直な意見を言える社風だったり、ミッション・バリューへの共感もあって大学卒業後にそのまま入社しました。入社後は、創業事業である「YOJO」の唯一の専任者として従事し、現在はスクラムマスターなども担当しています。

__――PharmaXでは、どのようなミッションを掲げていますか？__

__上野__：「患者満足度世界一」をミッションに、生活者が主役となる医療体験の実現を目指しています。創業事業としてかかりつけ医療ブランド『YOJO』、2022年からは薬局DX事業も展開しています。2023年には専任チーム『PharmaX 生成AI Labs』を立ち上げて、生成AI/LLM（大規模言語モデル）による事業推進・情報発信にも取り組んでいます。

![PharmaX_interview_0508_1](//images.ctfassets.net/ngrpflsbp3rq/3I54YBAqAda8E8cu2VsQ4d/9db570d4341269501a783a13aad21aca/1__.jpg)

## 生産性の可視化を通じて、スピード感と魅力あるエンジニア組織を目指す

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

__古家__：PharmaXのミッションを実現するべく事業計画、さらには日々の施策を達成するためのスピードと質を向上させたいと考えていました。一方でプロジェクトが当初想定していた通りに進められず、期限のリスケや大きなリリースによるバグ発生といった問題が積み重なっていました。

そのため開発の正確な見通しやバグを減らすためにも適切な指標が欲しいと思ったのが、開発生産性の計測を検討し始めたきっかけです。

情報収集していく中で「DevOpsの科学」やt-wadaさんの資料にたどり着き、Four Keys（開発生産性の計測指標）の可視化に取り組むことを推進し始めました。

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

__古家__：オープンソースやGitHubで公開されているライブラリなどを駆使し、独自に内製で計測・可視化しようと試み、その結果リードタイムを改善することはできました。しかしさらに深掘りをするためにデータを取得していこうと考えると保守にかかる工数が大きかったため、最終的には内製で着手することを断念しました。

__上野__：社内には2つの事業部がありますが、エンジニアは事業部を横断するチーム構成の「テクノロジー本部」に在籍しています。エンジニアは業務時間の85%程度で事業部の仕事に着手している一方で、残りの15%程度は組織運営や開発チーム強化に関する取り組みに注力してもらうという体制をとっています。開発生産性についても開発チーム強化の文脈で取り組みを進められていたと思います。

![PharmaX_interview_0508_グラフ1](//images.ctfassets.net/ngrpflsbp3rq/5Izpf6SLSjEEKSG6peEq0J/aee91ee62caf9443f77fc4b3c385c6b7/__.png)

__――「Findy Team+」のことは、どのようなきっかけで知っていただきましたか？__

__古家__：開発生産性の可視化を内製で取り組む傍ら、開発生産性を計測するツールについて調査を進めていく中でFindy Team+のことを知りました。開発生産性を計測できるツールはいくつかありましたが、可視化できる指標・データが充実していて導入事例も多かった点で、Findy Team+の導入を前向きに考え始めました。

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

__古家__：経営陣に対しては、1on1で開発生産性について解説したり、今後の事業拡大に向けて会社として投資する価値を伝えるなどしていました。メンバー向けには指標のロジックについて説明しながら、Four Keysについて理解を得るよう進めていました。一方で、ROI観点での説得や理解を得るための資料作成、といったことはなかったです。開発チームで独自に設定されている「エゴから発展させよ」というバリューに基づいて、自身の実現したいことに周囲を巻き込んでいきました。

__江田__：古家さんが周囲を巻き込んで話を進めていく一方で、メンバー起点でも徐々に開発生産性への関心は高まっていたように思います。毎週個人的な取り組みを発表する場があったことで、生産性に興味をもったメンバーが積極的に可視化を行い、知見をシェアしていました。

__――最終的に「Findy Team+」のどういった部分が導入の決め手になりましたか？__

__上野__：経営観点で言えば、魅力的なエンジニア組織であることを外部に発信する指標・機会としてもFindy Team+を活用し、採用・広報にも活用できるのではないか、というのが導入の決め手となりました。

開発生産性の改善がビジネスの成果に影響を与えるようになるまでには時間がかかりますし、可視化するだけではエンジニア以外を説得するうえで限界があると感じていました。

一方で周囲のスタートアップを見ていると、エンジニアから魅力的な組織ほど開発生産性スコアを公開しているというトレンドがあり、着手しないことはむしろ自社にとってマイナスに影響するように思えました。

そして今の自社開発チームなら対外的に見ても良いスコアを目指せる、「Findy Team+ Award」の受賞も狙えるのではないかと考えました。

__――実際に、2023年1月に実施したアンケートによると、求人応募や転職を考える際に、8割弱の方が開発生産性を重視していると回答しています。__

![PharmaX_interview_0508_グラフ2](//images.ctfassets.net/ngrpflsbp3rq/NyyZINZCpNtTh5Lzypsi0/8e8046be2d60c070843819f1cda23861/__.png)

　　　　　　　　　　　　　　　　（Findy調査より抜粋）

## 数値の可視化で意識・行動が変わり、自信にもつながった

__ーFindy Team+を用いた日々の振り返り・分析などについてお伺いしたいです。__

__江田__：チームでの振り返りは1週間ごとに実施していて、全体の1週間前での数値と目標値とを比較しています。具体的には開発生産性スコアサマリ、デプロイ頻度とリードタイム、チーム内アクティビティ、最近だとレビューサマリも確認しています。

  - 開発生産性スコアサマリ
  - デプロイ頻度とリードタイム
  - チーム内アクティビティ
  - レビューサマリ（オープンからレビューまでの平均時間）

各メンバーとは1on1で個別の振り返りを実施しています。例えばDevOps分析のプルリク一覧をリードタイム順で並び替えてみて、相対的に多かったプルリクを見ながら、ユーザーストーリーを細かく切り分けることを一緒に考えてみたりしています。

__ー開発生産性を組織目標に紐づける中で工夫したポイントがあれば__

__古家__：組織目標として、事業の施策スピードを上げることを目指しているので、リードタイムとプルリク数を開発チームの目標としてます。、具体的にはリードタイム平均23時間以内、プルリク数は1人2件以上/日で設定しており、週次で実施しているスプリント振り返りの際にFindy Team+のダッシュボードを参照しながら振り返りを行っています。
振り返りをするだけでなく、具体的な改善タスクの設定とそれに着手する時間を設定して、個々のプルリク数増加を試みたりしています。

また、各メンバーのOKR目標の管理においても、Findy Team+を利用しています。例えばOKRにプルリク作成数が設定されているメンバーとは、チームコンディション画面などを見ながら1on1で一緒に振り返りをしています。

__ーその他にも開発チームやメンバーの意識・行動における変化などありましたでしょうか？__

__江田__：ちょっとしたコード改修でも数値に反映される体感があり、ゲーム感覚で楽しみながら改善・成功体験に繋げられているように感じます。結果としてチーム全体で前向きなスタンスになり、プルリクを適切なリードタイムで出すようになってきています。

__上野__：リリース速度に対してチームがフォーカスするようになったのは大きかったです。これまでにリリースの重要性を言葉で伝えても組織に浸透しなかったところが、数値として目標が設定されたことでチーム全体での達成意欲が醸成されてきました。

![PharmaX_interview_0508_2](//images.ctfassets.net/ngrpflsbp3rq/6GQOY7MSY00O1lvaofEosP/e12ac2013a8a9f8f8edce19fabc3fa55/4__.jpg)

__ー改善の成果を共有する機会などはありますでしょうか？__

__古家__：毎月末に全社で各チーム・メンバーの1ヶ月の成果を発表・賞賛し合うWin-Session（ウィンセッション）という場があります。先日も、リードタイムが1/10になって開発生産性が大幅に改善したことなどを発表しました。発表の際に使用するドキュメントでもFindy Team+ Labのダッシュボード画像などを引用したりしています。

これまで、最終的なアウトプットでしか経営陣の成果を伝えることしかできなかったのですが、開発プロセスの改善結果を数値で可視化ができるようになったことで、正確に開発組織の成果を伝えることができるようになりました。
その結果、開発生産性の数値改善を通じて経営陣からの信頼獲得につながっているように感じます。

__上野__：開発生産性改善のインパクトが数字として現れていることに対して、社内の開発組織以外でも一定の良い反応が得られていると感じます。

![PharmaX_interview_0508_グラフ3](//images.ctfassets.net/ngrpflsbp3rq/4WhuThOuqnIIOdhN8yu8lE/074d169c44ede52224c6ff0b24e43589/_2.png)

__ーTeam+のおすすめポイントについてもお伺いしてもよろしいでしょうか？__

__江田__：DevOps分析画面でのランク(*)、開発生産性スコアでの偏差値が表示されるのがすごくよいと思っています。開発組織の相対評価を見れるのは、自社開発や他ツールにはなかったTeam+独自の魅力だと感じます。

(*Findy Team+ の画面上に、DORAが開発のスピードと安定性を測る指標)

__古家__：レビュー分析はまさに数値として見たかった内容なのでとても重宝しています。自前で作ろうとした際にかなり困難だった部分でもあります。オープンからレビューまでの平均時間が可視化されたことによってチーム全体のレビューに対する意識が変わったのもよかったです。

__上野__：プロダクトだけでなく、カスタマーサクセスのサポート体制も魅力だと感じています。導入直後のオンボーディングで活用の相談をしていく際も、エンジニアでないとキャッチアップが難しいように思えるテーマも含めて対等に議論できたのは、思わずすごいなと感心してしまいました。

![PharmaX_interview_0508_3](//images.ctfassets.net/ngrpflsbp3rq/4LcsIxUM40C9F4DWyQ9CID/45668c8830412b9e2e056fb45c4697b4/6__.jpg)

## 全社で体感できるインパクトに繋げるべく開発生産性を次のレベルへ

__ー今後チームとしてどんなことにトライしていきたいでしょうか？__

__上野__：エンジニア以外のメンバーも開発生産性向上のインパクトを体感できるぐらいに、改善効果をビジネスにも反映していきたいです。そのためには開発生産性を開発組織だけでなく全社の生産性に紐づく状態まで引き上げていく、成長感の伝わる計測指標を設定する必要があると感じます。

__古家__：直近では開発組織の生産性向上を実現するべく動き始めています。Team+で計測できる指標に加えてテストカバレッジや品質向上なども数値で可視化しようとしています。開発チームの生産性が一定向上した段階であれば、ベロシティを計測しても良いかなと考えていたりします。

__ーチームのアピールポイントについてお伺いしてもよろしいでしょうか？__

__上野__：エンジニアとユーザーとの距離が近い環境です。エンジニアリングだけに閉じずユーザーへの価値提供やPS（薬剤師）チームと連携しながら仕事を進めています。また、技術的なチャレンジに積極的な土壌もあり、生成AIという最先端の技術に積極的に取り組んでいることも強みだと考えています。

__古家__：行動指針の「患者起点」を徹底しつつ、ビジネスのスケールと両立させることを追求している点でしょうか。医療や健康の領域で社会的意義があることを成し遂げたい、インパクトのあることをしたい人に向いていると感じます。

__ー今後一緒に働きたいエンジニア像についても教えてください。__

__上野__：エンジニアリングに閉じず、プロダクトやユーザー価値に意識を向けられる方とご一緒できると嬉しいな、と思っています。

__ー上野さん、古家さん、江田さん、ありがとうございました！__

![PharmaX_interview_0508_4](//images.ctfassets.net/ngrpflsbp3rq/3SJ63GQfOrob6SjO1ozNmO/b2e83e41891fe8b2f39fef809ac3a2f6/7__.jpg)

__※PharmaXでは、『患者満足度世界一』をミッションとして、価値観に共感するエンジニアを募集しています。__
[https://herp.careers/v1/yojo](https://herp.careers/v1/yojo)

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


PharmaX_interview_0508_FV

医療・医薬品領域で2つの事業を展開しているPharmaX株式会社では、2023年12月よりエンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。  今回はCTO上野さん、エンジニアリングマネージャー古家さん、エンジニアの江田さんにインタビュー。導入のきっかけや、リードタイムが1/10に改善するなど早くも成果が現れ始めている背景について、お話を伺いました。

開発生産性の高さを採用戦略の新たな切り口に。8名から開発者体験の向上を目指すPharmaXの取り組み	


## 社内の部門から会社へ。アジャイル開発でDXを推進

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

__岡澤__：ソフトウェアエンジニアを経てKDDIに入社し、認証系サービス、セキュリティサービス、IoTサービス、海外スタートアップ企業との新規事業立ち上げなどいろいろとプロジェクトをリードしました。KDDIでアジャイル開発の立ち上げをスクラムマスターとして行った後は、エンジニアリングマネージャーとしてエンジニア育成やビジネスモデル、プロセス、企業文化の変革などを推進してきました。

2022年7月からKDDIアジャイル開発センターの事業開始に伴い、VPoEと開発戦略本部長に就任しました。もともとKDDIのアジャイル推進をしてきた背景もあり、いろいろな役割を担っておりますが、社内の組織をどうしたらより良くしていけるかというところも担っています。まだできたばかりの会社なので、実際に各案件のコンサルにも入るなど、幅広く動いています。

今回の話題に関するところでは、組織をより良くしていき、いかにエンジニアが楽しく働けるかを、きちんと仕組みとして取り入れていくこと。これを振り返りも含めて進めていくところが大きいですね。

__吉村__：メーカーで新規事業担当としてB2Bサービスの開発を行い、企画から開発までの一連のプロセスを経験した後、KDDIアジャイル開発センターに転職しました。

現在は、スマートシティの開発で3つのスクラムチームがあり、その支援をしています。ロールはスクラムマスターですが、一般的に定義されている動き方とは少し違うかもしれません。具体的には、最初期のアーキテクチャを描いたり、先行的な調査をしたり、各チームで解決できない課題に対応したりしています。加えて、顧客との各種調整やエンジニアの採用など、幅広く行っています。

__――アジャイル開発センターの開発組織について教えていただけますか？__

__岡澤__：もともとアジャイル開発センターは、KDDI社内の1つの部門だったのですが、それがそのまま会社になった背景があります。開発組織は5部門あり、パートナーも含めると400人くらいの規模。さまざまなプロダクト、チーム規模のスクラムチームが、40チームほどあります。

そのなかに高輪ゲートウェイスマートシティ開発チームと、auでんきチームの2つがあり、まずはその2チームから「Findy Team+」を導入しています。

__――御社の開発組織では、どのようなミッションを掲げていますか？__

__岡澤__：我々がミッションとして掲げているのは、国内のお客様のDX推進です。そのなかでも大きく2つあって、この両方に取り組んでいます。

1つは内製支援のような形で、実際にアジャイル開発センターのメンバーがチームに入って、育成しながらサービスをつくり上げていく。それが終わったころには、お客様の中でエンジニア組織やアジャイルなマインドができあがっているという流れで、その企業のDXを推進していくものです。

もう1つは、今までウォーターフォールなどのやり方をされてきて、新しいサービスがつくれないお客様がいらっしゃるので、UXデザイナーを含めてビジネス変化に対応しながら開発を進めていくものです。

![kddiagile_interview_0507_1](//images.ctfassets.net/ngrpflsbp3rq/7LrsBcGnYSeGwBdaE6nh4w/2a0d21ff07ecf18704a35a14b32bb22a/1__.jpg)

## 2つの大規模プロジェクトで「Findy Team+」を導入

__――「Findy Team+」導入前にあった課題感や、開発生産性の計測に取り組まれた背景について教えてください。__

__岡澤__：いくつかありますが、エンジニアの働き方をより理解したうえで、1on1に取り組んだり、フォローしたりできるようにしたいというのが、まず1つ。なので、生産性を計測したいというよりは、見える化を進めたいというイメージですね。

また、スクラムは良くも悪くもスクラムのなかで完結してしまえば問題なく、40チームあるので各チームで最適化が進んでいます。ですが、より一層良くしていくために、横との比較ではなく、メンバー同士でお互いに気づきが得られるものがあるといいなと。実際に今、横のチームのベロシティなどは見れるのですが、それとはまた違う気づきが生まれるきっかけをつくりたいと考えていました。

それから、スクラムチームでは、メンバーが固定されてずっと同じチームでいることが理想ですが、実際にはそれは難しく、人が入れ替わるタイミングがきます。そのタイミングでより適切に、エンジニアが働きやすい状態のままメンバーを入れ替えたり、新しいチームをつくったりしたい。そういう場面で、定性的な情報だけでなく定量的な情報まで、今見えている観点以外にも見れたらいいなと思っていました。

__吉村__：「Findy Team+」導入に関しては、岡澤さんから話をもらったのが最初のきっかけでした。ただ、個人的にはもともと可視化にはすごく興味があって。製造業にいたときに、その会社で「測定なくしてコントロールなし」という標語があったんです。それがずっと頭に残っていて、生産性の可視化にはずっと興味を持っていました。

スクラムやアジャイルをやっていくなかで、お互いの不理解もあって、生産性という言葉を頭ごなしに使ってしまうケースがあると思います。生産性という言葉は、過剰に反応されたり嫌われたりしがちな面もありますが、それで終わらせてしまうと、ベロシティで一方的に評価される状況から次のステップに進まないと感じています。

以前はGitHubやJIRAのAPIからデータを取ってきて、ElasticSearchに入れてKibanaで見たりしていたのですが、各チームのブランチ戦略やチケットのワークフローの違いなどがあり、面倒な部分が多くありました。そこはあまり時間をかけるところではないと考えていたので、その部分をカバーしてくれるツールがあるなら、ぜひ入れてみたいと思っていました。

![kddiagile_interview_0507_2](//images.ctfassets.net/ngrpflsbp3rq/49rYcL6dbCgbaAfO2SFSNb/4f60330eb611c8d4254cd2926c2f5c84/2__.jpg)

__――現時点では、各チームで開発生産性をどのように可視化していますか？__

__岡澤__：「Findy Team+」を入れていないチームでは、ベロシティがメインで、リードタイムを取ったりしていることが多いですね。基本的には、JIRAやGitHubをベースに見ています。

__――「Findy Team+」を導入している2チームは、どういった理由から計測を始められたのでしょうか？__

__岡澤__：高輪ゲートウェイスマートシティ開発チームは、新しく立ち上がったチームで、まずはそこから計測を始めました。2つ目のauでんきチームは、電気自由化のタイミングで立ち上がった、2016年ごろから長く続いているチーム。連携チームは3〜4つほどあります。なので、新たに始める大規模プロジェクトと、もとからあった大規模プロジェクト、この2つに入れて進めてみようという考えですね。

それから、auでんきチームは安定してリリースしているチームでもあります。スクラムでは開発生産性のほかに、振り返りで幸福度を測ったりするんですね。生産性と幸福度はチームビルドにとても影響するものなので、単一なプロダクトで、チームがどういう状況であればベストなのかを知りたいというのが、大きな目的の1つでもありました。

## 定量面と定性面の両方を見ていくバランス感が重要

__――最近はFour Keysのほかに、SPACEなどのフレームワークも注目を集めています。御社としても定量面だけでなく、定性面も重視する意識が強いですか？__

__岡澤__：スクラムやアジャイルは、心理的安全性があるうえで、チームで働くことによって安定して開発ができるものです。なぜスクラムマスターがいるかというと、エンジニアが開発に集中できるように、障害物を取り除くため。つまり、エンジニアがエンジニアらしく働けるようにするためなんですよね。これは先ほどお話しした幸福度もそうですが、かなりSPACEの考えに近いところがあります。

ただ、そこってなかなか表現しにくい部分ではあると思うんですよ。チーム開発をしたことがない人は、個別に開発した方が速いと思うかもしれません。でも、もちろん不満やモヤモヤを抱えた状態だと仕事は進みませんが、そういったものがまったくない状態でチーム開発をしていくと、生産性は最も高くなると考えているんです。

「Findy Team+」は、そういったところの一部を見やすくできるものだと思っています。なので、一人ひとりのコミット量を見て、メンバーを監視するような使い方は、まったく想定していません。

__吉村__：幸福度などを測ることも重要な一方で、定性的な指標だけに偏ってしまうと、外から見たときに、ただ仲良くやっているだけに見えてしまう可能性もあります。なので、そういった定性的な指標を追う活動が、定量的にどう効いているのか、不確実性を下げるエンジニアリングにどう寄与しているのかは、開発者として責任を持つ必要がある。そこのバランスが重要だと思っています。

事業部では売り上げなどの数字を、責任を持って追っているじゃないですか。それに対して、開発は何を追っているのかというときに、一例として、我々は開発生産性やリードタイムなど、そういったところに責任を持っていると言えるといいのかなと考えています。

![kddiagile_interview_0507_3](//images.ctfassets.net/ngrpflsbp3rq/4Jy906nFFPJq5b1jxjuiXq/d9d454aa1cf66359ec9a3ab5a1b7eb73/3__.jpg)

__――今後OKRやKPIとして、定量的な数値を設定することは検討されていますか？__

__吉村__：高輪ゲートウェイスマートシティ開発チームでは、そういった目標の設定を目指したいと思っています。ただ、現状はようやく人が固定化してきて、やっとチームの型ができてきたところなので、各数値の定義はまだこれからですね。

例えばプルリク数などは、そこにコミットするというほどではなくとも、いったん目標を置いて振り返っていくことは、自分たちをコントロールする意味でもやっていきたいなと思っています。

__――現在は、新しくジョインした方がスムーズにオンボーディングできているかなどを、「Findy Team+」で追っていると伺いました。それ以外にも、何か活用されている例はありますか？__

__吉村__：それ以外では、主に1on1で活用しています。1on1をするときに、スクラムマスターとして定量的な情報を把握したうえで、メンバーと会話したりとか。メンバーによっては直接ダッシュボードを見せて、前週との違いを実感と合っているか確かめたりなど、1on1の話題として使っています。

## “チームの良い状態”をトータルで可視化することを目指す

__――今後「Findy Team+」をどのように活用していきたいと考えていますか？__

__岡澤__：アジャイル開発センターは、ずっとKDDIのなかでエンジニアを育成してきた背景があり、毎年グループ会社のエンジニアを受け入れて育成しています。そういった際に、メンバーがどれくらい成長したかを定量的に示してあげられると、本人自身が成長実感を得やすくなると考えています。

吉村さんのチームにも1年目のメンバーが入っていますが、そういうメンバーにとっては、自分がどれだけチームに貢献できているかわかりにくく、不安を感じやすいですよね。チームに貢献していることが見えれば、成長実感が得やすいと思うので、そういった教育的な観点での活用を進めていきたいと思っています。

__吉村__：直近は導入したばかりで、これからデータが溜まっていく段階です。理想を言えば、せっかく可視化できているので、今後はダッシュボードなどをもっとオープンにしていけるといいのかなと思います。ただ、そこは少し注意も必要なので、ゆっくりとやっていきたいですね。

まだまだ入口の段階なので、「自分たちの生産性って何だろう」とか、そういう会話をするきっかけにできたらいいなと思っています。今求められているのは、スループットなのか、リードタイムなのかとか。「Findy Team+」ではいろいろな数字が取れているので、「この期間はこれを追っていこう」といった、前向きな議論につなげていきたいです。

![kddiagile_interview_0507_4](//images.ctfassets.net/ngrpflsbp3rq/YfTJ4ZgDBHjqaZ1sZVqE3/1c29300c2e4e7559a4e849cfab7ad0fa/4__.jpg)

__――そのほかにも、開発生産性の計測に関して今後トライしていきたいことがあれば教えてください。__

__岡澤__：アジャイル開発センターでは今、生成AIをかなり活用しています。Copilotもそうですし、それ以外の開発ツールの導入も検証したり、いろいろな生成AIを活用したサービスもつくったりもしています。我々としては、ずっとスクラムやアジャイルをやってきたなかで、そこにAIが入ったらどうなるのかをすごく考えているんですね。Copilotを入れれば働き方が変わるし、それによってどう変わったのかを、定量的に見ていきたいと思っています。

エンジニアリングのなかで、例えばCursorを使ったり、もしくはSourceGraphを使ったり、Copilot以外を試してみたり、我々の組織、開発スタイルにフィットしたものを色々試している状況です。そういった開発ツールの導入を推進して開発が楽しくかつ先進的な働き方ができると、すごくいいなと思いますね。

ただ、やはり最も目指したいのは、チームの良い状態をトータルで可視化すること。例えば、切羽詰まって頑張っているチームは、一時期の生産性は高くても、メンバーは幸せではなくて、その後が続かないというケースがありますよね。社員エンゲージメントが低くなることは一番の問題で、成長実感があって楽しい状態が組織として健全だと考えています。

そして、我々は感覚として、アジャイルがすごく良い方法で、結果的にビジネスにも貢献できていると思っています。それはやってみればわかることなのですが、やったことがない人たちには伝わりにくい。そのあたりが可視化できて、今我々が進めていることの裏付けになると、お客様にとってもメリットがありそうだと感じています。

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

お客様と共に新たなビジネス創出に乗り出し、自らの専門知識をフルに活かして共に高みを目指す挑戦を楽しむ。そんな情熱を共有できる方と一緒に働けることを心から楽しみにしています！

__――岡澤さん、吉村さん、ありがとうございました！__

![kddiagile_interview_0507_5](//images.ctfassets.net/ngrpflsbp3rq/2mBSKMjqwCluVBX7j9UL0A/d28cc6663b4a914718bdbe8e2dfc363d/5__.jpg)

__※KDDIアジャイル開発センターでは、エンジニアを募集しています。__

[KDDIアジャイル開発センター株式会社 ｜求人](https://hrmos.co/pages/kddigroup/jobs?category=1900792379653292032)

__※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。__

[https://findy-team.io/service_introduction](https://findy-team.io/service_introduction)


kddiagile_interview_0507_FV

アジャイル開発でDX開発支援を行うKDDIアジャイル開発センター株式会社では、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。  今回は、開発戦略本部長でVPoEを務める岡澤さん、スクラムマスターの吉村さんにインタビュー。開発生産性の可視化への取り組みを始めた背景や、「Findy Team+」を今後どのように活用していきたいかなどについて、お話をうかがいました。

自律的な改善を促す組織文化の形成へ。生成AI時代を見据えたKDDIアジャイル開発センターの組織づくり

## 新サービスの開発を進めるため、組織改革を実施
__――まず最初に、皆さんのこれまでのご経歴や現在のロールについて教えてください。__

__佐々木__：AI系ベンチャーにてPaaS/SaaSの企画・開発・運用やR&D、組織運営をしていました。その後、PaaS/SaaSでAWSを利用したことを切っ掛けに外資系クラウドベンダーに参画し、Cloud Infrastructure Architectとしてコンサルティング業務に従事していました。その後縁あって弥生株式会社に入社し、2022年1月よりCTOとしてエンジニア採用/教育、全社的なアーキテクチャ検討やR&D支援などに従事しています。

__髙瀬__：前職はSIerで、受託のウォーターフォール開発をしていました。その会社には13年ほどいて、プレイングマネージャーを務めていました。弥生にジョインしたのは1年ほど前で、当初はプロジェクトマネージャーという立ち位置でした。途中からスクラム開発に移行し、現在はスクラムマスターをしています。

__水尻__：僕は前の会社が2020年に弥生と吸収合併し、弥生に転籍してきました。主な業務は、請求管理サービス「Misoca」の開発で、前の会社から合わせて5年ほど開発に携わっています。それと並行して、佐々木さんと一緒にCCoEとしてクラウド利用を推進する活動もしていて、その活動の一環として「Findy Team+」の導入を進めました。

__――弥生の開発組織では組織変革が行われたそうですが、その背景や経緯について教えていただけますか？__

__佐々木__：まず関連するプロダクトの歴史からお話ししますと、もともと弥生は会計領域のソフトを中心に、スモールビジネスのお客様のバックオフィス業務を便利にするソリューションを提供してきています。

大きく分けると業務支援サービスと事業支援サービスの2つの柱があり、業務支援サービスとしてバックオフィス業務に関連する会計や給与計算のソフト、事業支援サービスとして起業・開業を支援するサービスや、事業承継を支援するサービスなどを展開しています。このうち、主に業務支援サービスの方を内製で開発しています。

業務支援サービスには、昔からあるデスクトップソフトの製品と、クラウドサービスがあります。既存の製品は、機能アップデートや法令改正を中心に開発をするため、年1回の法令改正を中心に開発をします。そのため、ウォーターフォールで進めやすいです。一方で、新しいサービスもつくっていかなければなりません。新サービスがなかなか世に出せないことは、弥生の経営課題の1つになっていました。

お客様はそもそも会計がしたいのではなく、ビジネスがしたいわけなので、会計は意識せずとも終わっている方がいいですよね。それを今までのサービスで実現できるかというと、少しアプローチを変えなければいけない。では、具体的に何をつくればいいのかというのは、お客様の反応を見ながら開発していく必要があります。

今までのような年に1回の大きなリリース、四半期に1回のホットフィックスではなく、日常的なリリースをしていくためには、やはりアジャイルやスクラムが適しています。新サービス開発に着手したのは2019～2020年ごろで、最初は開発本部内のいち組織として始めたのですが、よりスピードを上げるアプローチの1つとして組織改革も行ってきました。

もともとは開発本部が他の部から依頼を受けて開発する、いわゆる社内受託のような体制でした。ですが、新サービスの開発をその体制でやっていると、すごく時間がかかってしまいます。なので、既存サービスを開発する開発本部とは別に、ビジネス側も同じ組織に入って一緒にものづくりしていく新部署をつくりました。それが、「弥生Next」という新サービスを開発する次世代本部です。

これによって現在は、機能ごとに切り分けた開発本部やマーケティング本部と、ビジネスと開発が一緒になった次世代本部、それぞれが混在する組織になっています。

![yayoi_intereview_240426_1](//images.ctfassets.net/ngrpflsbp3rq/2MJCpNbfJbGL3xfwkB3J3n/0826c02922f9bc936b9b25d2c3709b98/1__.jpg)

__――社内受託のような体制になっていたことは、以前から課題として認識されていたのでしょうか？__

__佐々木__：そうですね。実際に外部からの受託ほど縦割りだったわけではないのですが、部署をまたぐため形式に従って要件定義書を書き、開発側でもそれをきっちりチェックするような重いプロセスになっていたんです。そうしていくうちに、気軽に進めづらい雰囲気になってしまったのかなと。私がジョインする前のことなのですが、話を聞く限りではそのように感じます。

__――開発組織では、「1クリックであらゆるバックオフィス業務を完了させ、お客さまの1日の労働時間の100%を本業に費やすことができる状態にする」というミッションを掲げられているとうかがいました。__

__佐々木__：はい、開発本部ではそうしたミッションを掲げています。ただ、昨年10月の開発本部と次世代本部に分かれたタイミングで、本部ごとにミッションを作成しており、次世代本部の方がより自動化を意識したミッションになっています。

__髙瀬__：次世代本部は「弥生Next」という新ブランドの製品をつくるチームなので、その世界観として「日本全国のスモールビジネスと​そのステークホルダーが​最も頼る経営プラットフォーム」を目指しています。そのなかにバックオフィスの自動化やフロント業務のデータ利活用、経営状況の可視化などが入ってくるイメージです。

__――本部ごとにミッションをつくられたとのことですが、各部に共通する行動指針などはありますか？__

__佐々木__：共通しているのは、カスタマーオブセッションですね。先ほどお話した社内受託のような形でやっていると、社内で要求を出してくる人のほうを見ながら仕事をしてしまいがちです。しかし、その裏にいるお客様のことをしっかりと見なければなりません。

特に意思決定においては、先代の社長がお客様やその領域にくわしく、それに頼ってしまう雰囲気がありました。そうではなく、ちゃんと自分自身でお客様のことを見て、お客様のことを考えて行動する。そういった考え方が重視されています。

## 全社的なデータドリブン経営への移行が計測のきっかけに

__――どのような背景から、開発生産性の計測への取り組みを始められたのでしょうか？__

__佐々木__：しっかりとデータを取ってそれをもとに判断していく、データドリブン経営が必要だという話が、全社的に上がっていたことが背景にあります。というのも、歴史の長い会社ではよくあることかもしれませんが、勘で判断されることが多くあったんですね。

開発においても、これまで開発をより効率化するためにさまざまな施策を打ってきていましたが、それがどう効いたのか、どの施策が良かったのかなどを、定量的に見られておらず、勘に頼っているところが多く見受けられました。なので、しっかりと定量的なデータを取り、判断していこうという話になったんです。

また、ウォーターフォールで取っていた指標はあったものの、アジャイルに移行していくにあたって、どのような指標を取ればいいのかという疑問も出てきました。そこで、CCoEのミーティングで水尻さんに相談してみたところ、Four Keysという指標があり、それを計測できるツールがあることを教えてもらいました。

__――水尻さんがFour Keysに注目された背景や、「Findy Team+」を知ったきっかけを教えてください。__

__水尻__：Four Keysについては、多くの人がそうだと思うのですが、『LeanとDevOpsの科学』という本を読んで知ったのが最初です。そして、Four Keysを計測するにあたって自分で実装するか、「Findy Team+」のようなSaaSを使うか、この2つから考え始めました。

まずは一度自分で実装してみて、メトリクスが取れるところまでは実装できたのですが、これを自分以外のチームに展開するのは大変だなと思い、SaaSを検討し始めました。なかでも「Findy Team+」を選んだ理由は、もともと存在を知っていて、かつ「RubyKaigi 2023」のスポンサーブースで実際に動いている画面を見たことがあったから。そのおかげで、具体的に社内で使うイメージが湧いていたことが大きいです。

![yayoi_intereview_240426_2](//images.ctfassets.net/ngrpflsbp3rq/2OXhakxf0Mw13qXS6Z3aGe/40d43a059360caf900a8efcb01f15e11/2__.jpg)

__――開発生産性の計測を通じたゴールはどのように設定されていますか？__

__佐々木__：まず、「Findy Team+」で計測した数値を横並びにして、チームの良し悪しを比較することには使ってほしくないという思いがありました。というのも、各チームでやっていることもつくっている製品も違うので、一概に数値を高めることだけが正解とは思えないからです。なので、私から経営陣やマネージャーには、生産性の計測はするけれど、それを横並びにして評価しないでほしいと伝えています。

計測した数値は、自分自身のチームの振り返りに活かし、チームをより良くしていく改善サイクルをまわす目的で使ってもらいたいと思っています。改善サイクルがうまくまわれば、チームが強くなり、アウトプットされるプロダクトも良くなるはず。その結果としてお客様が増えて、弥生の売り上げが上がるとともに、弥生が提供しているサービスによって日本の生産性が上がるはずだと考えています。

__水尻__：僕はCCoEと「Misoca」の開発エンジニア、2つの立場でのゴールがあると思っています。まずCCoEの立場から言えば、「Findy Team+」というツールをさまざまなチームで使ってもらい、各チームでの開発生産性の可視化と向上のための改善を、もっと当たり前にできるように推進していきたいと考えています。

「Misoca」の開発メンバーの1人としては、こうした開発生産性への取り組みを通じて、開発チームのアウトプットを増やし、最終的には自身がつくっているプロダクトの価値を高め、アウトカムをより大きくしていくことがゴールだと思っています。

__髙瀬__：スクラムチームを見ている立場として、開発生産性というのは、どこまでいっても1つの視点でしかないと思っています。我々は開発生産性の計測を通じて、まだ試行錯誤をしている旅の途中なので、なかなか明示的なゴールを設定することは難しいなと。

ただ、開発生産性に限らず、プロダクトチームはプロダクトをリリースし、お客様からフィードバックをいただきながら、常に価値のあるプロダクトをつくることを考えるべきで、そこに向かっていることが大事だと思います。

ウォーターフォールを長く経験してきた僕からすると、デプロイ頻度のような指標は「そんな視点があるんだな」と感じる新鮮なものでした。開発生産性はエンジニアのためだけのものではなく、プロダクトチーム全体として考えていくべき議題の1つというイメージです。

![yayoi_intereview_240426_3](//images.ctfassets.net/ngrpflsbp3rq/6PihdUE993MER8PNRqlm1S/3977f6b8a8c51dc6f4e9e2166b4b8877/3__.jpg)

__――指標をOKRやKPIに紐づけることは、今のところは想定されていないでしょうか。__

__佐々木__：はい、Four Keysを直接紐づけることはしないと思います。ミッションを達成するために見ておいた方が良い指標というイメージですね。

## 活用のさらなる試行錯誤や、社内での導入チーム拡大へ

__――「Findy Team+」の導入にあたって、社内やチームの理解を得るのに苦労したことはありましたか？__

__佐々木__：社内では壁がなく、使ってみたいツールがあれば、「やってみて」と言われる環境があります。ただ、そのツールを入れた結果がどうなったかを聞くと、「そういえば最近あれ使ってないね」ということが多かったんですね。

それはつまりツールを入れた結果、数値が上がったのか下がったのかを見ていないということ。そういった結果をしっかり確認するためにも、可視化が必要だよねといった話をしていたら、特にどこからも反対の声はありませんでした。

__髙瀬__：導入してみて、チームが必要に駆られないところが最大の難所だと感じました。数値を出していても、それよりも自分にとってインパクトが大きい内容を振り返ることが多くなるんですね。振り返りのときに、事実ベースで話をしていこうとか、そういった地道なアプローチをしていくところは、今でも少し苦労しています。

__水尻__：「Findy Team+」の導入を提案した側としては、運が良かった部分もあったと思います。先ほど話題に上がった、全社的にデータを重視していく方針があったことが、まず追い風の1つになりました。さらに、佐々木さんが和田卓人さんの「質とスピード」の発表を聞いて、Four Keysの重要性について共感を得られていたこと。この2つの追い風があったから、スムーズに進んでいったのかなと感じます。

あとは、「Findy Team+」のトライアルのときに、髙瀬さんのチームにお願いしたのですが、データを見てチームの課題を見つけるなど、自分が思っていた以上にこのツールを活用してもらえていました。それを見て、「Findy Team+」を活用していく実感を得られたことも大きかったです。

![yayoi_intereview_240426_4](//images.ctfassets.net/ngrpflsbp3rq/20rSQ785Sl44hgNshtQNl9/3ff919fc9c9de39bb69a9806c700a1a9/4__.jpg)

__――開発生産性の計測に関して、今後のトライとして考えていることはありますか？__

__佐々木__：私の方では、今後1つ予定している取り組みがあります。御社のイベントでヤフーさんが、生産性が高い開発チームの習慣をアンケートで把握していたという発表をされていました。その後、懇親会でヤフーさんに直接お話をうかがいまして、その取り組みを参考に弊社でもやってみようと考えています。

__髙瀬__：ツールで計測するだけにとどまらず、スクラムのなかの活動について、どういう考え方やアプローチができるのかを、今後もチームと試行錯誤していきたいです。スクラムマスターとして、例えば「今回はこういうデータだったね」と事実ベースでチームに伝達するようなアプローチを少しずつ行い、それに対してチームがどう考えるのか、というステップを経ようと思っています。スクラムマスターから言われたから、とかそういうことではなく、チームメンバーが自分たちで発想したり、思考するというところにトライしていきたいと考えています。

__水尻__：僕としては、「Findy Team+」を社内のいろいろなチームで使っていくことを、今後のトライと考えています。なので、社内で使っていくにあたって、どんな良いところや課題があったかを調査し、他のチームで使ってもらうためのアプローチを探りながら、広げていきたいと思っています。そして最終的には、開発組織の各チームでの生産性を、しっかりとデータで見られる状態に持っていきたいです。

![yayoi_intereview_240426_5](//images.ctfassets.net/ngrpflsbp3rq/23bfczdlFxgrRFqF0h55pT/a7758038e9c134cf490648b5318667d9/5__.jpg)

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

スモールビジネスと呼ばれる中小企業・個人事業主は、日本全体の企業数の99%を占めています。
ベンチャー企業はもちろん、行きつけのカフェや美容室など、私たちの生活はスモールビジネスによって支えられています。
私たち弥生は、夢を実現しようとするスモールビジネスを応援すると同時に、彼らの事業に寄り添い、支える存在でありたいと考えています。

実際に、弥生ではお客様の業務を効率的に変えていくサービスの開発に関わることが出来ます。企画から開発、運用までを自社で行っているため、超上流工程から経験を積むことも可能です。色々と新しい事にチャレンジしているため様々な課題も見つかっていますが、日々楽しみながら組織や製品の課題を解決するために試行錯誤してくださるような方にJoinして頂けると嬉しいです。

__――皆さん、本日はありがとうございました！__

![yayoi_intereview_240426_6](//images.ctfassets.net/ngrpflsbp3rq/7JIjJZtTKgGYlnE6DAqxnx/4962905a20272401fa6235dc3462d2e8/6__.jpg)

__※弥生では、エンジニアを募集しています。__

[エンジニア採用サイト | 弥生](https://herp.careers/v1/yayoi/requisition-groups/2363876d-7695-46ea-9e6a-0bc64d11b6bc)

__※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。__

[https://findy-team.io/service_introduction](https://findy-team.io/service_introduction)


yayoi_intereview_240426_fv

バックオフィス業務の自動化を支援するソフトウェア「弥生シリーズ」を展開する弥生株式会社では、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用頂いています。今回は、弥生でCTOを務める佐々木さん、スクラムマスターの髙瀬さん、CCoEとしても活動するエンジニアの水尻さんにインタビュー。新サービス開発のために行われた組織改革や、開発生産性の計測への取り組みを始めた背景、「Findy Team+」の活用を含む今後のトライなどについてお話を伺いました。

アジャイルへの移行の結果を可視化へ。データ・ドリブン経営を目指す弥生株式会社の取り組みとは？

## 「NewsPicks」のコミュニティ施策を担うチームを新設
__――まず最初に、加藤さんのこれまでの主な経歴や、現在の業務内容について教えてください。__

__加藤__：私は20年ほど開発職を続けています。SESやSIer、自社開発などさまざまな企業を経験したのち、地方（新潟）に住みながら、2022年9月に株式会社ニューズピックス（2023年7月に株式会社ユーザベースに法人統合）にジョインしました。

最初に配属されたのは、トピックスという、専門家の方がコメントを書いて発信できるコンテンツの開発を行うチームでした。そのチームはコミュニティ施策も担当しているチームだったのですが、コミュニティ施策を専任で担うチームを新たに立ち上げ、今はそのチームのリーダーをしています。

![UZABASE_interview_0424_1](//images.ctfassets.net/ngrpflsbp3rq/C1hA7NEpt2oGWAgMMJZ8g/4cd09a7d17edc2f04b3c3f390f6b68c4/1__.jpg)

__――チームの立ち上げには、どのような背景があったのでしょうか？__

__加藤__：トピックスとコミュニティの2つの施策を行うにあたって、チーム全体で見たときに、キャッチアップやコンテキストスイッチにコストがかかっている課題感がありました。そのため、それぞれにチームを分けた方が効率が良いのではないかという話から、期が始まる昨年1月のタイミングで、実際にチームを立ち上げることになりました。

__――立ち上げ当初、チームは何名くらいの体制でしたか？__

__加藤__：当初は4名でしたが、その翌月に入社が決まっていた人が1名いたので、すぐに5名になりました。年度の途中で6人になった時期もありましたが、今年からはまた少し体制が変わっています。

__――チームで掲げているミッションについて教えてください。__

__加藤__：今は体制変更により若干変わっている部分もありますが、コメントを書いてくれる人の体験を良くすることや、アクションしてくれる人を増やすことをミッションとしていました。「NewsPicks」には、記事にコメントしたり、記事をおすすめ・保存したりする機能があり、アクションというのは、そうした部分の利用を指しています。

__――それに関して、OKRやKPIとして設定していた指標はありましたか？__

__加藤__：最初はコメント数にフォーカスしていましたが、年度末ごろには週に何人がアクションしてくれるかを指標としていました。最終的には数字というより、施策を完遂するところを目指していましたね。

## プルリクを通知する仕組みの見直しから取り組み開始

__――開発生産性の計測への取り組みを始めた背景について教えてください。__

__加藤__：チームの状況として、9月入社の私のほかに、11月入社のメンバーが1人、2月入社のメンバーが1名。あと2名は別チームから入ってもらっていたため、全員がドメインに関しての経験値が少ない状態から始まりました。チームも立ち上がったばかりで、チームとしての形がまだしっかりと定まっていなかったんです。

そうしたなかで開発を進めていると、やはり最初はしっくりきていない感じがあって。実際に、振り返りのなかでもレビューが遅いといった反省点などが出てきていました。なので、その課題に対する対応として、計測に取り組んでみようというのが最初のきっかけでした。

__――どのような経緯から、「Findy Team+」を導入いただきましたか？__

__加藤__：人が集まって雑談していたタイミングで、他チームが「Findy Team+」を使っているという話を聞き、見てみようという話になったのがきっかけです。

__――そのときのチームメンバーの皆さんの反応はいかがでしたか？__

__加藤__：おおむねポジティブな反応だったと思います。オンラインなので反応が見えづらい部分もありましたが、5人くらいで話していて「良さそうだね」という反応だったと記憶しています。

__――「Findy Team+」を導入した当初、設定されていたゴールや数値目標はありましたか？__

__加藤__：最初は何かを目指すというよりは、「ちょっと見てみようかな」という温度感で始めました。なので、レトロスペクティブのなかで数字を見てみて、例えばプルリクのオープンからレビューまでに少し時間がかかっているなとか、そういう見方をしていました。そのうちに、ただ見ているだけではなく目標を決めることになり、ひとまず組織の平均を目指してみようという話になりました。

__――目標を設定されてから、チームではどのように取り組みを進められましたか？__

__加藤__：もともとメンバーの体感として時間がかかっている感覚があり、それと一致していたので、何かできることはないかとメンバーのなかで話し合っていきました。そして、まずはプルリクが上がったら通知される仕組みなど、基本的なところから見直していきました。

取り組みとしては、例えばGitHubのTeam機能を使って、よく開発するいくつかのリポジトリにTeamを設定し、レビュアーにTeamを指定できるようにしました。ラベルもつけられるようにして、ラベルがついたプルリクで未レビューのものや、アプルーブされたのにマージされていないものが通知されるようにしています。

そのほかにも、プルリクに対するアクション、例えばコメントやレビュー依頼が来たときに、Slackで通知するとか。そういった、なるべく早く気づくための仕組みを少しずつ整えていきました。

![UZABASE_interview_0424_2](//images.ctfassets.net/ngrpflsbp3rq/4pcpGmbYZN1QLQos4CODFr/9d3ce3f315a42d72cb1082f3045072b0/2__.jpg)

__――仕組みの見直し以外にも、レビューの優先度を上げていく意識づくりとして工夫されたことはありましたか？__

__加藤__：朝会のアジェンダを見直して、上がっているプルリクについて確認するようにしました。Slackに通知が来ているので、何かリリースしていないものがないか、そこで確認するようにしています。

あと、レビューの時間を設ける取り組みも試してみたのですが、これはみんなそれぞれ好きな時間にやりたいということで、上手くいかなかったですね。最終的に、朝会後にレビューしようというゆるい感じがちょうど良くて、そこに落ち着きました。

それ以外には、メンバー個別に本人の成長も兼ねて、積極的にレビューしてみようと声掛けする取り組みもありました。やはりレビューをすることでコーディングのスキル向上につながります。

それだけでなく、みんなまだドメイン知識が不足している部分があったので、レビューすることによって、メンバーが何をやっているのか、どういう仕組みになっているかなどのキャッチアップにもつながります。複数人でレビューしたりするので、もちろん時間はかかるのですが、必要なことだと意識して取り組んでいました。

__――レビューへの意識が変化したことで、品質面などにも良い影響はありましたか？__

__加藤__：品質面で言うと、レビューを早くしようとすると、プルリクを細かくするところに行き着くと思うのですが、その結果として見やすくなりますよね。なので、それを目指すことによって、結果的にプルリクが小さくなり、品質向上につながる面はあると思います。

ある程度の開発経験があれば、プルリクのサイズを細かくすることに理解があると思いますが、それを経験が少ない人に伝えるのは難しい。なので、レビューに関する数値を目指した結果、品質向上につながるというのは、1つの良い方法かなと思っています。

## 「Findy Team+」のグラフで見る、チームやメンバーの成長

__――実際に「Findy Team+」で、取り組み開始前の2月から5月までのグラフを見てみると、3月前半ごろからリードタイムが落ち着き始め、プルリク作成数が増えています。このころのメンバーの皆さんの実感や反応はいかがでしたか？__

![UZABASE_interview_0424_4枚目グラフ１](//images.ctfassets.net/ngrpflsbp3rq/56UCe5pJhDezkTs19xdKQa/75be151440cb67f529ad1385b554c47d/UZABASE_interview_xx_4______.png)

__加藤__：そのころは、メンバーと1on1でもレトロスペクティブでも、良くなってきたという声が増えてきた感覚がありました。具体的には、例えば「レビューがやりやすくなった」とか、「早く見てもらえて助かる」とか。あとは、「指摘したあとの対応が早くなった」とか、そういった声が上がっていました。

__――組織の平均を目指すというお話もありましたが、こうした数字の変化をどのように捉えていましたか？__

__加藤__：良い意味で“良いとこ取り”というか、もし仮にあまり良くない数字が出ていたとしても、あまりネガティブに捉えすぎる必要はないと考えていました。良いところを見たほうが、気持ちも上向くので、そういう使い方もありなのかなと。数値を把握すること自体に一定の意味はあると思いますが、必ずしもそれがすべてではないとも思うので、ほどよく活用しています。

__――レビュー数のグラフを見ると、9月から12月にかけて大きく伸びているメンバーの方がいらっしゃいます。かなり意識して取り組まれたのかと思いますが、いかがでしょうか？__

![UZABASE_interview_0424_5枚目グラフ２](//images.ctfassets.net/ngrpflsbp3rq/3QvuYQjv1tOhdlwUuwHyMa/a832ba7a477fa739be74a64f649a3ee1/UZABASE_interview_xx_5______.png)

__加藤__：彼は私のあとに入社したメンバーなのですが、半年で大きく変わっていて、数字を見なくても明らかに変化していることがわかりました。

まず彼には、振り返りの習慣を大事にするために、日や週の単位での予実をつけてもらっていました。例えば、午前にレビューをして午後に開発するという予定を立て、実際にはどう時間がかかったかという実績をつける。それに対して、なぜ予定より延びてしまったのか、あるいはなぜ早く終わったのかを一緒に見ていました。

彼はドメイン知識も経験も多くなく、コーディングのスキルも必ずしも高くありませんでした。やはりコードを見るには、ドメイン知識やコーディングのスキルが必要だと考えられるので、彼はもともと自信のなさから、人のプルリクに対してレビューすることがなかったんです。

なので、まずは自分のコードを見たときに、他人がどう感じるかを考えて、コメントを入れてみるところから始めました。それが9～10月あたりですね。それができてきたら、次は人のプルリクに対してメモを書いてみるという段階を踏んでいき、着実にレビュー数が増えていきました。

![UZABASE_interview_0424_5](//images.ctfassets.net/ngrpflsbp3rq/6WopfnEwCZUu66Vg1s87u7/73326a87f6df236719f59e13a1a4a001/5__.jpg)

__――取り組みを経て、この変化をご本人はどのように実感されていましたか？__

__加藤__：1日1レビューを心がけてやってくれていたのですが、彼自身も成長を感じていました。また、弊社では半期に一度、一緒に仕事をしたメンバーからフィードバックをもらう360度評価を行っています。そのコメントを見ても、みんなからレビューについて高く評価されていて、そういったところからも明らかに変わったことがわかりました。

## 数字が良くなることをゲーミフィケーション的に楽しめる

![UZABASE_interview_0424_6](//images.ctfassets.net/ngrpflsbp3rq/NyneyKFJ2DWIQK7wJ18h8/ed04c6f5a4370ebb8b56f70eb8acc8b3/6__.jpg)

__――取り組みを通じて、開発生産性を可視化するベネフィットをどういったところに感じられていますか？__

__加藤__：意外と良かったなと思うのは、雑談のネタになることですね。弊社は基本フルリモート勤務ですが、チームには月1回の出社推奨日があり、みんなが集まる機会があります。そういう場での話題になるところが良いなと思っています。

それから、現状を知るという意味では、他チームとの比較ができるところ。弊社はチーム数が多く、13～14くらいの開発チームがあります。他チームの数字を見て、大きく違いがあれば、どんな違いがあるのか、それが合理的な理由によるものなのかを確かめられる。もし比較して数字が良いチームがあったら、「どんな取り組みをしていますか？」とコミュニケーションするきっかけにもなります。

あとは、やはり始めた当初は数字で見ても悪いことがわかったので、一定の現状把握ができるのは良いことだと思います。さらに、ゲーミフィケーション的な要素として、単純に数字が良くなっていると嬉しいという感覚があります。メンバーの特性にもよるとは思いますが、そこはみんな楽しんでやってくれていたので、私たちのチームには合っていたのかなと感じますね。

__――可視化の取り組みや「Findy Team+」の活用について、今後のトライとして考えられていることがあれば教えてください。__

__加藤__：「Findy Team+」は、私自身もまだ知らない機能があるなど、使いこなせていない部分があります。随時追加されていく機能のキャッチアップも含めて、しっかりと学んだうえで活かしていきたいと考えています。

ファインディさんとの「Findy Team+」活用法のミーティングで出てきたトピックをもとに、社内の他チームとも情報交換をしながら、さらなる活用の可能性を考えていけたらと思っています。

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

NewsPicks のエンジニアカルチャーとして、ユーザへの提供価値を最大化することを重視し、エンジニア自身もプロダクトの改善案を考え、実装していくという事業にコミットすることを重視したプロダクト志向のエンジニアが多い組織となっています。社内のコンテンツクリエイターやマーケターともフラットに意見交換できる組織で、普段から職種を超えて協力しながらプロダクト開発を推進しています。そのためエンジニア組織の構成も、モバイルやバックエンドなどの職能ごとではなく、サービスや機能単位でチームをつくる、ミッションベースの組織体制になっています。

また、私が所属するエンジニア部門ではエンジニアに対するサポート制度も充実しており、技術書などの購入サポートはもちろんのこと、入社後6カ月間にわたって毎月1回、CTOに1on1の時間を割いてもらう制度があったり、他部署の先輩に助言や指導をお願いできるメンター制度、コーポレート部門に日々の困りごとに対処してもらえる相談窓口があったりします。

リモートワークをサポートする制度も手厚くなってきているので、私自身を含め、地方在住のメンバーもいます。ここには、多様なバックグラウンドを持つ人たちを迎え入れる柔軟性に富んだカルチャーがあり、チャレンジを推奨する開発環境もあります。もしNewsPicksに少しでも関心があるなら、ぜひ気軽にカジュアル面談を受けてみてください。私のようにそれまで想像しなかった未来が開けるかも知れません。

__――加藤さん、ありがとうございました！__

![UZABASE_interview_0424_7](//images.ctfassets.net/ngrpflsbp3rq/5t4uhtuH9Uehm9NisIHI6N/e7c4e402db8b5f2946d167bffdd8b7d4/7__.jpg)

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


UZABASE_interview_0424_fv 

ソーシャル経済メディア「NewsPicks」などを提供する株式会社ユーザベースでは、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。  今回は、「NewsPicks」の開発に携わるエンジニアの加藤さんにインタビュー。開発生産性の可視化への取り組みを始めた背景やチームでの取り組みの内容について、「Findy Team+」での実際の数値を見ながら、お話をうかがいました。

開発生産性の可視化によりレビュー数が4倍に。メンバーの成長を促進させるユーザベースの組織づくり

## レビュー滞留による停滞感、結果指標のなさが課題に
__――まず最初に、お二人の主なご経歴や現在の業務について教えてください。__

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

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

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

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

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

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

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

![mento_intereview_2024/04/11_h2-1-1](//images.ctfassets.net/ngrpflsbp3rq/2W28atyS7JeDsS9KNK9YFZ/35b889985c118d84c8a159605080787e/unnamed__4_.jpg)

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

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

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

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

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

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

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

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

![mento_intereview_2024/04/11_h2-1-2](//images.ctfassets.net/ngrpflsbp3rq/1BLgqUluVH5RIwEOXtj2hy/95dcc10c2a921154669fa81f70dbbeaa/DSC03770__1_.jpg)

## 定義の議論に時間をかけずに済むことがメリットの1つ
__――「Findy Team+」を導入する前、開発生産性の計測に関する取り組みはされていましたか？__

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

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

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

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

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

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

![mento_intereview_2024/04/11_h2-2-1](//images.ctfassets.net/ngrpflsbp3rq/2lz1Dz3ke9fFifzRx8AWAr/9197ca2532ae56f0b0e0ae21fa5bff38/DSC03942__1_.jpg)

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

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

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

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

## 週2回のレビュー会を設け、全員のレビュー優先度をアップ
__――レビューの課題については、どのように改善を進めていきましたか？__

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

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

![mento_intereview_2024/04/11_h2-3-3](//images.ctfassets.net/ngrpflsbp3rq/5vwpGgdrmtrcIzxwVX6zRw/0890d11f8b85b3ec5c70718f2c693eb2/unnamed.jpg)
__――レビュー会を設けることに対して、ネガティブな反応などはありませんでしたか？__

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

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

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

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

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

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

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

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

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

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

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

![mento_intereview_2024/04/11_h2-4-1 ](//images.ctfassets.net/ngrpflsbp3rq/3PWM7EXxU7h69e9Yyed7hS/adcebf0635cdcf1a429816e7e60be050/__________2024-04-23_16.02.51.png)

![mento_intereview_2024/04/23_h2-4-2](//images.ctfassets.net/ngrpflsbp3rq/4Iz0LdYUfXW61X1OAB1dfn/eb45a62bc83a7cce1baa3a9184b2493d/__________2024-04-23_15.43.20.png)

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

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

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

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

![mento_intereview_2024/04/11_h2-4-2](//images.ctfassets.net/ngrpflsbp3rq/4LHJuYjQX9hPRc8HBS9cfb/7765be4533ab0348f8dc448930f60d78/unnamed__5_.jpg)

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

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

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

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

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

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

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

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

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

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

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

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

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

![mento_intereview_2024/04/19_h2-4-2](//images.ctfassets.net/ngrpflsbp3rq/MW2MR2NZn0CswoN5ApqJs/6374401ffda2495b68139edbdc5c27b5/DSC04122__1_.jpg)

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

※現在mentoでは、エンジニアを募集しています。
[エンジニア求人　| mento](https://herp.careers/v1/mento/bmLBljpda7kA)

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


mento_intereview_2024/04/23_fv

パーソナルコーチングサービス「mento（メント）」の開発・運営などを行う株式会社mentoでは、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。  今回は、mentoのCTOを務める松山さんと、エンジニアの吉谷さんにインタビュー。「Findy Team+」を導入する前にあった組織の課題や導入後の取り組み、開発生産性の計測のベネフィットをどのように感じているかなどについて伺っていきます。

インタビュー

入社から3ヶ月で即戦力へ。開発生産性指標を活用するhokanの今後のオンボーディングの取り組みとは？

GitHub Copilot導入効果をFindy Team+で定量的に可視化。マネーフォワードの全社的な開発生産性向上に向けた取り組みとは？

リードタイムを60時間から3.7時間に短縮。働くひとの健康を創るiCAREが取り組む開発パフォーマンス改善の可視化とは？

Findy Team+導入から半年でサイクルタイムが20%近く改善。全社的な開発生産性向上を目指すエムシーデジタルの取り組みとは？

エンジニア組織のパフォーマンスの健康診断に。「より強い組織」を目指すSmartHRの開発生産性向上に向けた取り組みとは？

開発生産性の高さを採用戦略の新たな切り口に。8名から開発者体験の向上を目指すPharmaXの取り組み

自律的な改善を促す組織文化の形成へ。生成AI時代を見据えたKDDIアジャイル開発センターの組織づくり

アジャイルへの移行の結果を可視化へ。データ・ドリブン経営を目指す弥生株式会社の取り組みとは？

開発生産性の可視化によりレビュー数が4倍に。メンバーの成長を促進させるユーザベースの組織づくり

「正社員2名」の開発組織からFourKeys向上へ。事業拡大を目指すmentoにおける開発組織の文化づくりとは？

.css-1uuptc0 svg{width:32px;height:32px;fill:#666666;stroke:#666666;}@media (max-width: 750px){.css-1uuptc0 svg{width:24px;height:24px;}}インタビュー

入社から3ヶ月で即戦力へ。開発生産性指標を活用するhokanの今後のオンボーディングの取り組みとは？

GitHub Copilot導入効果をFindy Team+で定量的に可視化。 マネーフォワードの全社的な開発生産性向上に向けた取り組みとは？

リードタイムを60時間から3.7時間に短縮。働くひとの健康を創るiCAREが取り組む開発パフォーマンス改善の可視化とは？

Findy Team+導入から半年でサイクルタイムが20%近く改善。全社的な開発生産性向上を目指すエムシーデジタルの取り組みとは？

エンジニア組織のパフォーマンスの健康診断に。「より強い組織」を目指すSmartHRの開発生産性向上に向けた取り組みとは？

開発生産性の高さを採用戦略の新たな切り口に。8名から開発者体験の向上を目指すPharmaXの取り組み

自律的な改善を促す組織文化の形成へ。生成AI時代を見据えたKDDIアジャイル開発センターの組織づくり

アジャイルへの移行の結果を可視化へ。データ・ドリブン経営を目指す弥生株式会社の取り組みとは？

開発生産性の可視化によりレビュー数が4倍に。メンバーの成長を促進させるユーザベースの組織づくり

「正社員2名」の開発組織からFourKeys向上へ。事業拡大を目指すmentoにおける開発組織の文化づくりとは？

インタビュー

GitHub Copilot導入効果をFindy Team+で定量的に可視化。マネーフォワードの全社的な開発生産性向上に向けた取り組みとは？