2025-08-07

開発生産性の指標を全員の共通言語に。Four Keysを通じた改善と信頼の循環を生み出すネクサスエージェントの取り組みとは?

開発生産性の指標を全員の共通言語に。Four Keysを通じた改善と信頼の循環を生み出すネクサスエージェントの取り組みとは?

目次

目次を読み込み中...

本記事のサマリ

導入前:解決したかった課題

割り込みタスクと長時間会議でデプロイ頻度・リードタイムが悪化し、手動集計のブレで客観指標を共有できず改善サイクルが停滞していた。

Findy Team+を導入した理由

GitHub連携だけでFour Keysを自動可視化でき、標準指標で社内外へ説明しやすく“監視”ではなく“改善”に集中できると判断したため。

導入の決め手

UIの分かりやすさと自動更新により現場〜経営層が同じデータで会話でき、レトロや報告資料に即活用できる点が決定打に。

導入後:成果

登記情報データサービスチームは会議短縮と割り込み制御でデプロイ頻度回復、イエリーチsalesチームはリリース枠拡張でリードタイム80%短縮し障害ゼロ継続へ。

不動産領域を中心とした資産の流通に、テクノロジーで革新を起こす株式会社ネクサスエージェント。同社の開発部隊は、「日本一の開発組織」を目指し、開発生産性の可視化と改善に向けた取り組みを推進しています。

今回は、プロダクト開発運用課の登記情報データサービスチームでスクラムマスター(以下、SM)を務める野藤力斗さんと、イエリーチsalesチームでSMを務めた後、イエリーチチームにSMとして参画した小笠原健太さんにインタビュー。Four Keysを軸に生産性向上へ挑む中での変化や成果、そしてチーム全体で育まれている改善文化について伺いました。

開発生産性の指標を全員の共通言語に。ネクサスエージェントの取り組みとは?

──御社について教えてください。

野藤:ネクサスエージェントは、「資産運用 × テクノロジー」で、新しい不動産流通の形を目指している会社です。中古不動産という資産の流通において、透明性とスピードを高め、より公正な取引を実現する仕組みをつくっています。

プロダクトとしては、自社の営業支援ツール、ユーザー向けのWebサービス、社内業務の基幹システムなど幅広く内製していて、技術の力で事業そのものを支えていくスタンスが特徴です。

小笠原:開発組織は約20名で、スクラムを採用しており、基本的にはプロダクトオーナー(以下、PO)/SM/開発者のシンプルなロールで構成されています。私はSMとして開発ロードマップの設計や、ユーザー価値を意識した優先順位付け、そして開発の進行管理などを担当しています。エンジニアと密にコミュニケーションをとりながら、機能開発だけでなく全体最適を意識したマネジメントを行っています。

──開発組織では、どのようなミッションを掲げていますか?

野藤:開発組織として掲げているのは、「日本一の開発組織をつくること」です。そのために必要なのは、単に技術力が高いことだけではなく、チームとして安定的に成果を出し続けること。どんなメンバーが加わっても、再現性のある価値提供ができる組織を目指しています。

また、その基盤となるのが「自律的な改善文化」です。スクラムやレトロスペクティブなどの仕組みを活用して、チーム全体で目的意識を持ちながら改善を進めていけるようにしています。

小笠原:「若手だから任せない」という文化はなく、チャレンジの機会は年次に関係なく平等にあります。むしろ若手メンバーの挑戦を応援する風土があり、メンバーが主体的に動ける状態を大切にしています。

“監視”ではなく“改善”のために。可視化の意義をチームで共有

──どのようなきっかけから「Findy Team+」に興味を持ったのでしょうか?

野藤:最初に注目したのは、GitHubと連携するだけでFour Keysを中心としたデータが可視化できるという手軽さでした。

もともとFour KeysはGoogleが提唱している信頼性の高い指標で、社内だけでなく社外への説明にも使いやすい。自分たちで指標を定義して管理するよりも、共通の指標で状況を客観視できることに価値を感じました。

小笠原:当初はスプレッドシートなどで手動集計も試していたのですが、数値のブレや分析の手間が大きく、継続的に運用するのは難しいと感じていました。Findy Team+を使えば、特別な準備をせずに日々の開発データを分析できる環境が整うと感じました。

──「Findy Team+」の活用について、難しかったポイントはありましたか?

野藤:最初は「指標をどう読み取ればいいのか」「何が良い状態なのか」がわかりにくい部分もありました。ただ、Four Keysに関してはGoogleの定義も明確ですし、Findy Team+のUIも洗練されているので、徐々に慣れてきました。

小笠原:あとは、数値が見えることで“評価されている感”が生まれてしまわないように気を配りました。これは監視ではなく、改善のために使うものだという認識を、チームで丁寧に共有することが大事だと思います。

──現場のメンバーに納得してもらうためにどのような工夫をされましたか?

野藤:ツールを使う前に、なぜ可視化をするのか、その目的や背景をしっかり説明しました。「指標のために開発しているわけではない」ということと、「課題を自分たちで見つけて改善できるようにするためのもの」という位置づけを明確にしました。

小笠原:また、メンバーに「この指標がどう変わったかを自分の目で見て考える」ことを促しました。納得感を持つには、自分で分析してみるのが一番です。Findy Team+の見やすいグラフは、その助けになったと思います。

──「Findy Team+」導入の取り組みを通じて、生産性はどのように変化したのでしょうか?

野藤:チームによってアプローチは違いますが、たとえば登記情報データサービスチームでは会議時間の削減や割り込みタスクのコントロールといった改善活動が、デプロイ頻度の回復という成果につながりました。

小笠原:イエリーチsalesチームでは、大型リリースの頻度やタイミングを見直すことで、リードタイムが短縮され、障害発生率もゼロを継続できています。数値で状況を把握し、それを元に具体的な施策につなげることができた好例だと思います。

少人数チームだからこそ見えた“時間”の課題。登記情報データサービスチームの改善アプローチ

──登記情報データサービスチームにおける取り組みについて教えてください。

野藤:登記情報データサービスチームは現在3名体制と少人数で、そのぶん1人の影響がデプロイ頻度などの指標に直結する構造でした。人数が減ったタイミングから徐々に生産性の低下が見られ、特にデプロイ頻度が課題として浮き彫りになっていました。

そこで私たちはまず、「会議時間の削減」と「割り込みタスクの制御」に着手しました。以前はデイリースクラムが平均で1時間かかっていて、開発時間の1割を費やしていたんです。人数が少ない状況ではこの非開発時間が大きなボトルネックになるため、「基本15分、長くても30分以内」とルールを明確化しました。会議には「全員に関係のある話」だけを持ってくるようにして、現在はそのルールを守る運用が定着しつつあります。

もうひとつの課題だった割り込みタスクに関しては、スプリントゴールを明確に定め、それよりも優先度が高いかをPOが判断するようにしました。割り込みタスクの優先度が高くないときはPBI(Product Backlog Item)に積んで次のスプリントに回すようにしています。レビューのない日でもスプリントゴールに対しての振り返りを行うなど、日常の中で意識を共有する機会も増やせるように取り組んでいます。

──少人数チームだからこその難しさと、どのように乗り越えたか教えてください。

野藤:少人数チームだと、ほんの些細な割り込みでもデプロイ頻度に影響が出てしまうという構造的な難しさがあります。たとえ「ちょっとだけだから」と対応しても、週のスプリントゴールが未達になってしまうこともある。だからこそ、メンバー自身が生産性向上の目的を本質的に理解しておく必要があると感じていました。

会議時間の削減については、私から指示を出すのではなく、あえてメンバーに委ねました。実際にメンバーが会議の録画を見返し、どこに時間がかかっているのかを分析してレトロの議題に持ってきてくれたんです。議論の際も「全員に関係のある内容かどうか?」という観点で話し合いが行われ、自然と改善が回り始めました。

また、割り込みタスクに関しても、他チームからの依頼なので早くしないといけない、という意識が働いていましたが、本当に優先度高いんだっけ?を判断するようになりました。若手メンバーが多い中で、1on1で生産性の目標を振り返る時間も取り、各自が自分の数字に意識を向けられるようにサポートしています。

リリース運用の見直しでリードタイムを80%短縮。イエリーチsalesチームの改善プロセスとは?

──イエリーチsalesチームにおける取り組みについて教えてください。

小笠原:イエリーチsalesチームは、技術力の高いメンバーが揃っていて、もともとデプロイ頻度は安定していました。ただ、その一方で、変更のリードタイムが課題となっていました。特にマイグレーションを含む大規模なリリースでは、プルリクエスト1本に100時間以上かかっているケースもありました。

Findy Team+のDevOps分析を通じてこの状況が明らかになったことで、「なぜリードタイムが長いのか」という視点でボトルネックの洗い出しを始めました。その結果、プロダクトのメンテナンス画面の仕様により、リリース可能な曜日が火曜・水曜の午前に限定されていたことが、ボトルネックの一因であることがわかりました。

──どのようにリリース頻度を改善されたのですか?

小笠原:もともとは、ユーザーへの影響を避けるため、火曜・水曜の限られた時間帯にしかリリースできない状態でした。結果として1回あたりのリリースが大規模化し、リスクが高まっていました。

そこで、数分のダウンタイムが発生する可能性とのリスクを比較検討した結果、木曜・金曜の朝にもリリースできるように運用を拡張することにしました。これはPOや責任者とも丁寧に議論を重ね、納得感を得たうえでの決断です。

その結果、施策前(11月1日〜12月3日)と比較して、施策後(12月4日以降)はリードタイムが平均19.8時間まで短縮。障害発生率も0%を維持することができました。データに基づいて改善できたことで、チーム内の信頼感や改善文化もより強固になったと思います。

改善を成果と捉える文化づくりにより、自律性の高いチームをつくりあげたイエリーチチームの取り組みとは?

──イエリーチチームが取り組んだ内容について教えてください。

小笠原:私がイエリーチチームに加わったのは2023年10月頃でした。それまでのチームにはすでに一定のカルチャーができあがっていて、そこに途中参加する難しさは正直ありました。その中で最初に取り組んだのが、変更のリードタイムが100時間を超えているプルリクの振り返りと原因分析でした。

主な原因として見えてきたのは、「ユーザーストーリーの区切り方」や「公開可能な機能範囲」の理解がチーム内で統一されていなかったことです。そこから、POに早めに相談する文化を意識的に作り、フィーチャーフラグを活用して、段階的にリリースする方針へと移行しました。

──チーム運営で工夫されたことがあれば教えてください。

小笠原:チームはPO・SM含めて8名体制で、かなり人数が多めです。そのため、情報の管理や共有にかかるコストが非常に高く、たとえばJiraやFigma、API仕様などがバラバラに管理されていて、「どこに何があるのかわからない」といった状態が発生していました。

そこで、Jiraに情報を集約することを徹底し、各種仕様や相談事項もすべてJiraに記録するようにしました。結果として、POに対して「これってどうなってましたっけ?」といった確認が減り、チームの自律性も高まりました。

また、レトロスペクティブでも、事前にメンバーの意見を回収して、1時間の中で必ず改善策を出せるような進行を工夫しています。これにより、MTGの効率も上がり、改善のPDCAがよりスムーズに回るようになりました。

──イエリーチチームで大切にしている価値観を教えてください。

小笠原:イエリーチチームでは、「改善はチーム全体の成果である」という価値観が強く根付いています。何か問題が起きたときも、「誰が悪いか」ではなく「どこにプロセスの問題があるか」という視点で議論されます。

たとえ改善施策がうまくいかなかったとしても、それは「学び」だと捉えられ、責められることはありません。このような前向きで心理的安全性の高い文化があるからこそ、各メンバーが積極的に提案・改善に向き合えるのだと思います。

目指すは“自然とAll Elite”。持続可能な改善文化づくりへの挑戦

──組織全体として、Findy Team+を通じてどのような変化が起きましたか?

野藤:まず大きな変化として、レトロスペクティブの質が変わったことがあります。以前は「個人の反省会」のようになっていた場が、いまではチームの生産性やボトルネックについて前向きに議論できる場になっています。

また、チームのSMと課長が毎週の進捗を報告し合う習慣ができたことで、「良い報告をしたいから、どう改善すればいいか」を考える文化も醸成されてきました。進捗が芳しくなかった週でも「なぜ達成できなかったのか」「どうすればよかったのか」と振り返ることができ、ポジティブな学びの機会になっています。

小笠原:他のチームの取り組みを参考にしながら、自分たちのチームにも取り入れていける横の連携も生まれました。Findy Team+の可視化データがあることで、指標や進捗が定量的にわかり、共通言語として会話できるのが大きいですね。

──今後、どのような開発生産性のトライを考えていますか?

野藤:まずはFour Keysの「All Elite」を継続的に達成できる状態にしていきたいです。現状では一時的に達成できるタイミングがあるものの、継続にはまだ課題があると感じています。目標は、特別な意識や努力をしなくても自然と達成できる状態までもっていくこと。そのために、各チームが自律的に改善し続けられるような文化と仕組みを整えていきたいです。

さらに、私たちの開発課としてのテーマに「AI拡張開発」を掲げていて、AIの力を活用しながら、エンジニアがより価値の高い業務に集中できる体制を目指しています。たとえば、コード生成やレビュー支援、テストの自動化など、AIの支援で開発の質とスピードを上げていきたいと考えています。

小笠原:開発生産性というと、どうしてもエンジニア中心の話に聞こえがちですが、今後はビジネスへの貢献やアウトカムの可視化も意識していきたいです。2024年度からはSLI(Service Level Indicator)の定量化を進めていて、そこからSLO(Service Level Objective)を設定して、プロダクトの信頼性や成果を数値で見える形にしていく計画です。

マネージャーだけでなく、エンジニアも“見てわかる”UI設計が魅力

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

小笠原:まずはやはり、GitHubと連携するだけで手軽にFour Keysの指標が可視化できる点ですね。生産性のデータを集めるのって、手作業だと非常に大変ですが、Findy Team+は導入してすぐにグラフが出てきて、チーム全体で共通の認識を持ちやすい。可視化の負担がとても軽いので、改善活動に集中できます。

野藤:もうひとつは、UIの見やすさと、データをメンバー全員で共有できる設計です。Findy Team+では、マネージャーだけでなく現場のエンジニアも自分の状況やチームの傾向を把握しやすい。だからこそ、チーム全体で振り返りがしやすくなって、個人ではなく組織で改善に取り組める土壌ができてくると思います。

──今後、一緒に働きたいエンジニア像を教えてください。

野藤:一言で言うと、「一緒により良くしていきたい」と思える人ですね。技術力ももちろん大切ですが、それ以上に「何が課題か?どう改善できるか?」を自分ごととして考えられるかどうかを大事にしています。

小笠原:イエリーチチームでは「失敗してもOK、改善はチームの成果」という文化があるので、挑戦して、振り返って、学びに変えられる人がフィットすると思います。技術的な成長はもちろん、チームでの学びや対話を楽しめる人と一緒に働きたいですね。

※ネクサスエージェントでは、エンジニアを募集しています。

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

本記事のサマリ

導入前:解決したかった課題

割り込みタスクと長時間会議でデプロイ頻度・リードタイムが悪化し、手動集計のブレで客観指標を共有できず改善サイクルが停滞していた。

Findy Team+を導入した理由

GitHub連携だけでFour Keysを自動可視化でき、標準指標で社内外へ説明しやすく“監視”ではなく“改善”に集中できると判断したため。

導入の決め手

UIの分かりやすさと自動更新により現場〜経営層が同じデータで会話でき、レトロや報告資料に即活用できる点が決定打に。

導入後:成果

登記情報データサービスチームは会議短縮と割り込み制御でデプロイ頻度回復、イエリーチsalesチームはリリース枠拡張でリードタイム80%短縮し障害ゼロ継続へ。

不動産領域を中心とした資産の流通に、テクノロジーで革新を起こす株式会社ネクサスエージェント。同社の開発部隊は、「日本一の開発組織」を目指し、開発生産性の可視化と改善に向けた取り組みを推進しています。

今回は、プロダクト開発運用課の登記情報データサービスチームでスクラムマスター(以下、SM)を務める野藤力斗さんと、イエリーチsalesチームでSMを務めた後、イエリーチチームにSMとして参画した小笠原健太さんにインタビュー。Four Keysを軸に生産性向上へ挑む中での変化や成果、そしてチーム全体で育まれている改善文化について伺いました。

開発生産性の指標を全員の共通言語に。ネクサスエージェントの取り組みとは?

──御社について教えてください。

野藤:ネクサスエージェントは、「資産運用 × テクノロジー」で、新しい不動産流通の形を目指している会社です。中古不動産という資産の流通において、透明性とスピードを高め、より公正な取引を実現する仕組みをつくっています。

プロダクトとしては、自社の営業支援ツール、ユーザー向けのWebサービス、社内業務の基幹システムなど幅広く内製していて、技術の力で事業そのものを支えていくスタンスが特徴です。

小笠原:開発組織は約20名で、スクラムを採用しており、基本的にはプロダクトオーナー(以下、PO)/SM/開発者のシンプルなロールで構成されています。私はSMとして開発ロードマップの設計や、ユーザー価値を意識した優先順位付け、そして開発の進行管理などを担当しています。エンジニアと密にコミュニケーションをとりながら、機能開発だけでなく全体最適を意識したマネジメントを行っています。

──開発組織では、どのようなミッションを掲げていますか?

野藤:開発組織として掲げているのは、「日本一の開発組織をつくること」です。そのために必要なのは、単に技術力が高いことだけではなく、チームとして安定的に成果を出し続けること。どんなメンバーが加わっても、再現性のある価値提供ができる組織を目指しています。

また、その基盤となるのが「自律的な改善文化」です。スクラムやレトロスペクティブなどの仕組みを活用して、チーム全体で目的意識を持ちながら改善を進めていけるようにしています。

小笠原:「若手だから任せない」という文化はなく、チャレンジの機会は年次に関係なく平等にあります。むしろ若手メンバーの挑戦を応援する風土があり、メンバーが主体的に動ける状態を大切にしています。

“監視”ではなく“改善”のために。可視化の意義をチームで共有

──どのようなきっかけから「Findy Team+」に興味を持ったのでしょうか?

野藤:最初に注目したのは、GitHubと連携するだけでFour Keysを中心としたデータが可視化できるという手軽さでした。

もともとFour KeysはGoogleが提唱している信頼性の高い指標で、社内だけでなく社外への説明にも使いやすい。自分たちで指標を定義して管理するよりも、共通の指標で状況を客観視できることに価値を感じました。

小笠原:当初はスプレッドシートなどで手動集計も試していたのですが、数値のブレや分析の手間が大きく、継続的に運用するのは難しいと感じていました。Findy Team+を使えば、特別な準備をせずに日々の開発データを分析できる環境が整うと感じました。

──「Findy Team+」の活用について、難しかったポイントはありましたか?

野藤:最初は「指標をどう読み取ればいいのか」「何が良い状態なのか」がわかりにくい部分もありました。ただ、Four Keysに関してはGoogleの定義も明確ですし、Findy Team+のUIも洗練されているので、徐々に慣れてきました。

小笠原:あとは、数値が見えることで“評価されている感”が生まれてしまわないように気を配りました。これは監視ではなく、改善のために使うものだという認識を、チームで丁寧に共有することが大事だと思います。

──現場のメンバーに納得してもらうためにどのような工夫をされましたか?

野藤:ツールを使う前に、なぜ可視化をするのか、その目的や背景をしっかり説明しました。「指標のために開発しているわけではない」ということと、「課題を自分たちで見つけて改善できるようにするためのもの」という位置づけを明確にしました。

小笠原:また、メンバーに「この指標がどう変わったかを自分の目で見て考える」ことを促しました。納得感を持つには、自分で分析してみるのが一番です。Findy Team+の見やすいグラフは、その助けになったと思います。

──「Findy Team+」導入の取り組みを通じて、生産性はどのように変化したのでしょうか?

野藤:チームによってアプローチは違いますが、たとえば登記情報データサービスチームでは会議時間の削減や割り込みタスクのコントロールといった改善活動が、デプロイ頻度の回復という成果につながりました。

小笠原:イエリーチsalesチームでは、大型リリースの頻度やタイミングを見直すことで、リードタイムが短縮され、障害発生率もゼロを継続できています。数値で状況を把握し、それを元に具体的な施策につなげることができた好例だと思います。

少人数チームだからこそ見えた“時間”の課題。登記情報データサービスチームの改善アプローチ

──登記情報データサービスチームにおける取り組みについて教えてください。

野藤:登記情報データサービスチームは現在3名体制と少人数で、そのぶん1人の影響がデプロイ頻度などの指標に直結する構造でした。人数が減ったタイミングから徐々に生産性の低下が見られ、特にデプロイ頻度が課題として浮き彫りになっていました。

そこで私たちはまず、「会議時間の削減」と「割り込みタスクの制御」に着手しました。以前はデイリースクラムが平均で1時間かかっていて、開発時間の1割を費やしていたんです。人数が少ない状況ではこの非開発時間が大きなボトルネックになるため、「基本15分、長くても30分以内」とルールを明確化しました。会議には「全員に関係のある話」だけを持ってくるようにして、現在はそのルールを守る運用が定着しつつあります。

もうひとつの課題だった割り込みタスクに関しては、スプリントゴールを明確に定め、それよりも優先度が高いかをPOが判断するようにしました。割り込みタスクの優先度が高くないときはPBI(Product Backlog Item)に積んで次のスプリントに回すようにしています。レビューのない日でもスプリントゴールに対しての振り返りを行うなど、日常の中で意識を共有する機会も増やせるように取り組んでいます。

──少人数チームだからこその難しさと、どのように乗り越えたか教えてください。

野藤:少人数チームだと、ほんの些細な割り込みでもデプロイ頻度に影響が出てしまうという構造的な難しさがあります。たとえ「ちょっとだけだから」と対応しても、週のスプリントゴールが未達になってしまうこともある。だからこそ、メンバー自身が生産性向上の目的を本質的に理解しておく必要があると感じていました。

会議時間の削減については、私から指示を出すのではなく、あえてメンバーに委ねました。実際にメンバーが会議の録画を見返し、どこに時間がかかっているのかを分析してレトロの議題に持ってきてくれたんです。議論の際も「全員に関係のある内容かどうか?」という観点で話し合いが行われ、自然と改善が回り始めました。

また、割り込みタスクに関しても、他チームからの依頼なので早くしないといけない、という意識が働いていましたが、本当に優先度高いんだっけ?を判断するようになりました。若手メンバーが多い中で、1on1で生産性の目標を振り返る時間も取り、各自が自分の数字に意識を向けられるようにサポートしています。

リリース運用の見直しでリードタイムを80%短縮。イエリーチsalesチームの改善プロセスとは?

──イエリーチsalesチームにおける取り組みについて教えてください。

小笠原:イエリーチsalesチームは、技術力の高いメンバーが揃っていて、もともとデプロイ頻度は安定していました。ただ、その一方で、変更のリードタイムが課題となっていました。特にマイグレーションを含む大規模なリリースでは、プルリクエスト1本に100時間以上かかっているケースもありました。

Findy Team+のDevOps分析を通じてこの状況が明らかになったことで、「なぜリードタイムが長いのか」という視点でボトルネックの洗い出しを始めました。その結果、プロダクトのメンテナンス画面の仕様により、リリース可能な曜日が火曜・水曜の午前に限定されていたことが、ボトルネックの一因であることがわかりました。

──どのようにリリース頻度を改善されたのですか?

小笠原:もともとは、ユーザーへの影響を避けるため、火曜・水曜の限られた時間帯にしかリリースできない状態でした。結果として1回あたりのリリースが大規模化し、リスクが高まっていました。

そこで、数分のダウンタイムが発生する可能性とのリスクを比較検討した結果、木曜・金曜の朝にもリリースできるように運用を拡張することにしました。これはPOや責任者とも丁寧に議論を重ね、納得感を得たうえでの決断です。

その結果、施策前(11月1日〜12月3日)と比較して、施策後(12月4日以降)はリードタイムが平均19.8時間まで短縮。障害発生率も0%を維持することができました。データに基づいて改善できたことで、チーム内の信頼感や改善文化もより強固になったと思います。

改善を成果と捉える文化づくりにより、自律性の高いチームをつくりあげたイエリーチチームの取り組みとは?

──イエリーチチームが取り組んだ内容について教えてください。

小笠原:私がイエリーチチームに加わったのは2023年10月頃でした。それまでのチームにはすでに一定のカルチャーができあがっていて、そこに途中参加する難しさは正直ありました。その中で最初に取り組んだのが、変更のリードタイムが100時間を超えているプルリクの振り返りと原因分析でした。

主な原因として見えてきたのは、「ユーザーストーリーの区切り方」や「公開可能な機能範囲」の理解がチーム内で統一されていなかったことです。そこから、POに早めに相談する文化を意識的に作り、フィーチャーフラグを活用して、段階的にリリースする方針へと移行しました。

──チーム運営で工夫されたことがあれば教えてください。

小笠原:チームはPO・SM含めて8名体制で、かなり人数が多めです。そのため、情報の管理や共有にかかるコストが非常に高く、たとえばJiraやFigma、API仕様などがバラバラに管理されていて、「どこに何があるのかわからない」といった状態が発生していました。

そこで、Jiraに情報を集約することを徹底し、各種仕様や相談事項もすべてJiraに記録するようにしました。結果として、POに対して「これってどうなってましたっけ?」といった確認が減り、チームの自律性も高まりました。

また、レトロスペクティブでも、事前にメンバーの意見を回収して、1時間の中で必ず改善策を出せるような進行を工夫しています。これにより、MTGの効率も上がり、改善のPDCAがよりスムーズに回るようになりました。

──イエリーチチームで大切にしている価値観を教えてください。

小笠原:イエリーチチームでは、「改善はチーム全体の成果である」という価値観が強く根付いています。何か問題が起きたときも、「誰が悪いか」ではなく「どこにプロセスの問題があるか」という視点で議論されます。

たとえ改善施策がうまくいかなかったとしても、それは「学び」だと捉えられ、責められることはありません。このような前向きで心理的安全性の高い文化があるからこそ、各メンバーが積極的に提案・改善に向き合えるのだと思います。

目指すは“自然とAll Elite”。持続可能な改善文化づくりへの挑戦

──組織全体として、Findy Team+を通じてどのような変化が起きましたか?

野藤:まず大きな変化として、レトロスペクティブの質が変わったことがあります。以前は「個人の反省会」のようになっていた場が、いまではチームの生産性やボトルネックについて前向きに議論できる場になっています。

また、チームのSMと課長が毎週の進捗を報告し合う習慣ができたことで、「良い報告をしたいから、どう改善すればいいか」を考える文化も醸成されてきました。進捗が芳しくなかった週でも「なぜ達成できなかったのか」「どうすればよかったのか」と振り返ることができ、ポジティブな学びの機会になっています。

小笠原:他のチームの取り組みを参考にしながら、自分たちのチームにも取り入れていける横の連携も生まれました。Findy Team+の可視化データがあることで、指標や進捗が定量的にわかり、共通言語として会話できるのが大きいですね。

──今後、どのような開発生産性のトライを考えていますか?

野藤:まずはFour Keysの「All Elite」を継続的に達成できる状態にしていきたいです。現状では一時的に達成できるタイミングがあるものの、継続にはまだ課題があると感じています。目標は、特別な意識や努力をしなくても自然と達成できる状態までもっていくこと。そのために、各チームが自律的に改善し続けられるような文化と仕組みを整えていきたいです。

さらに、私たちの開発課としてのテーマに「AI拡張開発」を掲げていて、AIの力を活用しながら、エンジニアがより価値の高い業務に集中できる体制を目指しています。たとえば、コード生成やレビュー支援、テストの自動化など、AIの支援で開発の質とスピードを上げていきたいと考えています。

小笠原:開発生産性というと、どうしてもエンジニア中心の話に聞こえがちですが、今後はビジネスへの貢献やアウトカムの可視化も意識していきたいです。2024年度からはSLI(Service Level Indicator)の定量化を進めていて、そこからSLO(Service Level Objective)を設定して、プロダクトの信頼性や成果を数値で見える形にしていく計画です。

マネージャーだけでなく、エンジニアも“見てわかる”UI設計が魅力

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

小笠原:まずはやはり、GitHubと連携するだけで手軽にFour Keysの指標が可視化できる点ですね。生産性のデータを集めるのって、手作業だと非常に大変ですが、Findy Team+は導入してすぐにグラフが出てきて、チーム全体で共通の認識を持ちやすい。可視化の負担がとても軽いので、改善活動に集中できます。

野藤:もうひとつは、UIの見やすさと、データをメンバー全員で共有できる設計です。Findy Team+では、マネージャーだけでなく現場のエンジニアも自分の状況やチームの傾向を把握しやすい。だからこそ、チーム全体で振り返りがしやすくなって、個人ではなく組織で改善に取り組める土壌ができてくると思います。

──今後、一緒に働きたいエンジニア像を教えてください。

野藤:一言で言うと、「一緒により良くしていきたい」と思える人ですね。技術力ももちろん大切ですが、それ以上に「何が課題か?どう改善できるか?」を自分ごととして考えられるかどうかを大事にしています。

小笠原:イエリーチチームでは「失敗してもOK、改善はチームの成果」という文化があるので、挑戦して、振り返って、学びに変えられる人がフィットすると思います。技術的な成長はもちろん、チームでの学びや対話を楽しめる人と一緒に働きたいですね。

※ネクサスエージェントでは、エンジニアを募集しています。

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

\ 3分でわかる /
資料ダウンロード
Findy Team+のサービス資料は、
こちらからダウンロードできます。
資料をダウンロードする
Findy Team+サービス資料

開発生産性の指標を全員の共通言語に。Four Keysを通じた改善と信頼の循環を生み出すネクサスエージェントの取り組みとは?

本記事のサマリ

導入前:解決したかった課題

割り込みタスクと長時間会議でデプロイ頻度・リードタイムが悪化し、手動集計のブレで客観指標を共有できず改善サイクルが停滞していた。

Findy Team+を導入した理由

GitHub連携だけでFour Keysを自動可視化でき、標準指標で社内外へ説明しやすく“監視”ではなく“改善”に集中できると判断したため。

導入の決め手

UIの分かりやすさと自動更新により現場〜経営層が同じデータで会話でき、レトロや報告資料に即活用できる点が決定打に。

導入後:成果

登記情報データサービスチームは会議短縮と割り込み制御でデプロイ頻度回復、イエリーチsalesチームはリリース枠拡張でリードタイム80%短縮し障害ゼロ継続へ。

不動産領域を中心とした資産の流通に、テクノロジーで革新を起こす株式会社ネクサスエージェント。同社の開発部隊は、「日本一の開発組織」を目指し、開発生産性の可視化と改善に向けた取り組みを推進しています。

今回は、プロダクト開発運用課の登記情報データサービスチームでスクラムマスター(以下、SM)を務める野藤力斗さんと、イエリーチsalesチームでSMを務めた後、イエリーチチームにSMとして参画した小笠原健太さんにインタビュー。Four Keysを軸に生産性向上へ挑む中での変化や成果、そしてチーム全体で育まれている改善文化について伺いました。

開発生産性の指標を全員の共通言語に。ネクサスエージェントの取り組みとは?

──御社について教えてください。

野藤:ネクサスエージェントは、「資産運用 × テクノロジー」で、新しい不動産流通の形を目指している会社です。中古不動産という資産の流通において、透明性とスピードを高め、より公正な取引を実現する仕組みをつくっています。

プロダクトとしては、自社の営業支援ツール、ユーザー向けのWebサービス、社内業務の基幹システムなど幅広く内製していて、技術の力で事業そのものを支えていくスタンスが特徴です。

小笠原:開発組織は約20名で、スクラムを採用しており、基本的にはプロダクトオーナー(以下、PO)/SM/開発者のシンプルなロールで構成されています。私はSMとして開発ロードマップの設計や、ユーザー価値を意識した優先順位付け、そして開発の進行管理などを担当しています。エンジニアと密にコミュニケーションをとりながら、機能開発だけでなく全体最適を意識したマネジメントを行っています。

──開発組織では、どのようなミッションを掲げていますか?

野藤:開発組織として掲げているのは、「日本一の開発組織をつくること」です。そのために必要なのは、単に技術力が高いことだけではなく、チームとして安定的に成果を出し続けること。どんなメンバーが加わっても、再現性のある価値提供ができる組織を目指しています。

また、その基盤となるのが「自律的な改善文化」です。スクラムやレトロスペクティブなどの仕組みを活用して、チーム全体で目的意識を持ちながら改善を進めていけるようにしています。

小笠原:「若手だから任せない」という文化はなく、チャレンジの機会は年次に関係なく平等にあります。むしろ若手メンバーの挑戦を応援する風土があり、メンバーが主体的に動ける状態を大切にしています。

“監視”ではなく“改善”のために。可視化の意義をチームで共有

──どのようなきっかけから「Findy Team+」に興味を持ったのでしょうか?

野藤:最初に注目したのは、GitHubと連携するだけでFour Keysを中心としたデータが可視化できるという手軽さでした。

もともとFour KeysはGoogleが提唱している信頼性の高い指標で、社内だけでなく社外への説明にも使いやすい。自分たちで指標を定義して管理するよりも、共通の指標で状況を客観視できることに価値を感じました。

小笠原:当初はスプレッドシートなどで手動集計も試していたのですが、数値のブレや分析の手間が大きく、継続的に運用するのは難しいと感じていました。Findy Team+を使えば、特別な準備をせずに日々の開発データを分析できる環境が整うと感じました。

──「Findy Team+」の活用について、難しかったポイントはありましたか?

野藤:最初は「指標をどう読み取ればいいのか」「何が良い状態なのか」がわかりにくい部分もありました。ただ、Four Keysに関してはGoogleの定義も明確ですし、Findy Team+のUIも洗練されているので、徐々に慣れてきました。

小笠原:あとは、数値が見えることで“評価されている感”が生まれてしまわないように気を配りました。これは監視ではなく、改善のために使うものだという認識を、チームで丁寧に共有することが大事だと思います。

──現場のメンバーに納得してもらうためにどのような工夫をされましたか?

野藤:ツールを使う前に、なぜ可視化をするのか、その目的や背景をしっかり説明しました。「指標のために開発しているわけではない」ということと、「課題を自分たちで見つけて改善できるようにするためのもの」という位置づけを明確にしました。

小笠原:また、メンバーに「この指標がどう変わったかを自分の目で見て考える」ことを促しました。納得感を持つには、自分で分析してみるのが一番です。Findy Team+の見やすいグラフは、その助けになったと思います。

──「Findy Team+」導入の取り組みを通じて、生産性はどのように変化したのでしょうか?

野藤:チームによってアプローチは違いますが、たとえば登記情報データサービスチームでは会議時間の削減や割り込みタスクのコントロールといった改善活動が、デプロイ頻度の回復という成果につながりました。

小笠原:イエリーチsalesチームでは、大型リリースの頻度やタイミングを見直すことで、リードタイムが短縮され、障害発生率もゼロを継続できています。数値で状況を把握し、それを元に具体的な施策につなげることができた好例だと思います。

少人数チームだからこそ見えた“時間”の課題。登記情報データサービスチームの改善アプローチ

──登記情報データサービスチームにおける取り組みについて教えてください。

野藤:登記情報データサービスチームは現在3名体制と少人数で、そのぶん1人の影響がデプロイ頻度などの指標に直結する構造でした。人数が減ったタイミングから徐々に生産性の低下が見られ、特にデプロイ頻度が課題として浮き彫りになっていました。

そこで私たちはまず、「会議時間の削減」と「割り込みタスクの制御」に着手しました。以前はデイリースクラムが平均で1時間かかっていて、開発時間の1割を費やしていたんです。人数が少ない状況ではこの非開発時間が大きなボトルネックになるため、「基本15分、長くても30分以内」とルールを明確化しました。会議には「全員に関係のある話」だけを持ってくるようにして、現在はそのルールを守る運用が定着しつつあります。

もうひとつの課題だった割り込みタスクに関しては、スプリントゴールを明確に定め、それよりも優先度が高いかをPOが判断するようにしました。割り込みタスクの優先度が高くないときはPBI(Product Backlog Item)に積んで次のスプリントに回すようにしています。レビューのない日でもスプリントゴールに対しての振り返りを行うなど、日常の中で意識を共有する機会も増やせるように取り組んでいます。

──少人数チームだからこその難しさと、どのように乗り越えたか教えてください。

野藤:少人数チームだと、ほんの些細な割り込みでもデプロイ頻度に影響が出てしまうという構造的な難しさがあります。たとえ「ちょっとだけだから」と対応しても、週のスプリントゴールが未達になってしまうこともある。だからこそ、メンバー自身が生産性向上の目的を本質的に理解しておく必要があると感じていました。

会議時間の削減については、私から指示を出すのではなく、あえてメンバーに委ねました。実際にメンバーが会議の録画を見返し、どこに時間がかかっているのかを分析してレトロの議題に持ってきてくれたんです。議論の際も「全員に関係のある内容かどうか?」という観点で話し合いが行われ、自然と改善が回り始めました。

また、割り込みタスクに関しても、他チームからの依頼なので早くしないといけない、という意識が働いていましたが、本当に優先度高いんだっけ?を判断するようになりました。若手メンバーが多い中で、1on1で生産性の目標を振り返る時間も取り、各自が自分の数字に意識を向けられるようにサポートしています。

リリース運用の見直しでリードタイムを80%短縮。イエリーチsalesチームの改善プロセスとは?

──イエリーチsalesチームにおける取り組みについて教えてください。

小笠原:イエリーチsalesチームは、技術力の高いメンバーが揃っていて、もともとデプロイ頻度は安定していました。ただ、その一方で、変更のリードタイムが課題となっていました。特にマイグレーションを含む大規模なリリースでは、プルリクエスト1本に100時間以上かかっているケースもありました。

Findy Team+のDevOps分析を通じてこの状況が明らかになったことで、「なぜリードタイムが長いのか」という視点でボトルネックの洗い出しを始めました。その結果、プロダクトのメンテナンス画面の仕様により、リリース可能な曜日が火曜・水曜の午前に限定されていたことが、ボトルネックの一因であることがわかりました。

──どのようにリリース頻度を改善されたのですか?

小笠原:もともとは、ユーザーへの影響を避けるため、火曜・水曜の限られた時間帯にしかリリースできない状態でした。結果として1回あたりのリリースが大規模化し、リスクが高まっていました。

そこで、数分のダウンタイムが発生する可能性とのリスクを比較検討した結果、木曜・金曜の朝にもリリースできるように運用を拡張することにしました。これはPOや責任者とも丁寧に議論を重ね、納得感を得たうえでの決断です。

その結果、施策前(11月1日〜12月3日)と比較して、施策後(12月4日以降)はリードタイムが平均19.8時間まで短縮。障害発生率も0%を維持することができました。データに基づいて改善できたことで、チーム内の信頼感や改善文化もより強固になったと思います。

改善を成果と捉える文化づくりにより、自律性の高いチームをつくりあげたイエリーチチームの取り組みとは?

──イエリーチチームが取り組んだ内容について教えてください。

小笠原:私がイエリーチチームに加わったのは2023年10月頃でした。それまでのチームにはすでに一定のカルチャーができあがっていて、そこに途中参加する難しさは正直ありました。その中で最初に取り組んだのが、変更のリードタイムが100時間を超えているプルリクの振り返りと原因分析でした。

主な原因として見えてきたのは、「ユーザーストーリーの区切り方」や「公開可能な機能範囲」の理解がチーム内で統一されていなかったことです。そこから、POに早めに相談する文化を意識的に作り、フィーチャーフラグを活用して、段階的にリリースする方針へと移行しました。

──チーム運営で工夫されたことがあれば教えてください。

小笠原:チームはPO・SM含めて8名体制で、かなり人数が多めです。そのため、情報の管理や共有にかかるコストが非常に高く、たとえばJiraやFigma、API仕様などがバラバラに管理されていて、「どこに何があるのかわからない」といった状態が発生していました。

そこで、Jiraに情報を集約することを徹底し、各種仕様や相談事項もすべてJiraに記録するようにしました。結果として、POに対して「これってどうなってましたっけ?」といった確認が減り、チームの自律性も高まりました。

また、レトロスペクティブでも、事前にメンバーの意見を回収して、1時間の中で必ず改善策を出せるような進行を工夫しています。これにより、MTGの効率も上がり、改善のPDCAがよりスムーズに回るようになりました。

──イエリーチチームで大切にしている価値観を教えてください。

小笠原:イエリーチチームでは、「改善はチーム全体の成果である」という価値観が強く根付いています。何か問題が起きたときも、「誰が悪いか」ではなく「どこにプロセスの問題があるか」という視点で議論されます。

たとえ改善施策がうまくいかなかったとしても、それは「学び」だと捉えられ、責められることはありません。このような前向きで心理的安全性の高い文化があるからこそ、各メンバーが積極的に提案・改善に向き合えるのだと思います。

目指すは“自然とAll Elite”。持続可能な改善文化づくりへの挑戦

──組織全体として、Findy Team+を通じてどのような変化が起きましたか?

野藤:まず大きな変化として、レトロスペクティブの質が変わったことがあります。以前は「個人の反省会」のようになっていた場が、いまではチームの生産性やボトルネックについて前向きに議論できる場になっています。

また、チームのSMと課長が毎週の進捗を報告し合う習慣ができたことで、「良い報告をしたいから、どう改善すればいいか」を考える文化も醸成されてきました。進捗が芳しくなかった週でも「なぜ達成できなかったのか」「どうすればよかったのか」と振り返ることができ、ポジティブな学びの機会になっています。

小笠原:他のチームの取り組みを参考にしながら、自分たちのチームにも取り入れていける横の連携も生まれました。Findy Team+の可視化データがあることで、指標や進捗が定量的にわかり、共通言語として会話できるのが大きいですね。

──今後、どのような開発生産性のトライを考えていますか?

野藤:まずはFour Keysの「All Elite」を継続的に達成できる状態にしていきたいです。現状では一時的に達成できるタイミングがあるものの、継続にはまだ課題があると感じています。目標は、特別な意識や努力をしなくても自然と達成できる状態までもっていくこと。そのために、各チームが自律的に改善し続けられるような文化と仕組みを整えていきたいです。

さらに、私たちの開発課としてのテーマに「AI拡張開発」を掲げていて、AIの力を活用しながら、エンジニアがより価値の高い業務に集中できる体制を目指しています。たとえば、コード生成やレビュー支援、テストの自動化など、AIの支援で開発の質とスピードを上げていきたいと考えています。

小笠原:開発生産性というと、どうしてもエンジニア中心の話に聞こえがちですが、今後はビジネスへの貢献やアウトカムの可視化も意識していきたいです。2024年度からはSLI(Service Level Indicator)の定量化を進めていて、そこからSLO(Service Level Objective)を設定して、プロダクトの信頼性や成果を数値で見える形にしていく計画です。

マネージャーだけでなく、エンジニアも“見てわかる”UI設計が魅力

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

小笠原:まずはやはり、GitHubと連携するだけで手軽にFour Keysの指標が可視化できる点ですね。生産性のデータを集めるのって、手作業だと非常に大変ですが、Findy Team+は導入してすぐにグラフが出てきて、チーム全体で共通の認識を持ちやすい。可視化の負担がとても軽いので、改善活動に集中できます。

野藤:もうひとつは、UIの見やすさと、データをメンバー全員で共有できる設計です。Findy Team+では、マネージャーだけでなく現場のエンジニアも自分の状況やチームの傾向を把握しやすい。だからこそ、チーム全体で振り返りがしやすくなって、個人ではなく組織で改善に取り組める土壌ができてくると思います。

──今後、一緒に働きたいエンジニア像を教えてください。

野藤:一言で言うと、「一緒により良くしていきたい」と思える人ですね。技術力ももちろん大切ですが、それ以上に「何が課題か?どう改善できるか?」を自分ごととして考えられるかどうかを大事にしています。

小笠原:イエリーチチームでは「失敗してもOK、改善はチームの成果」という文化があるので、挑戦して、振り返って、学びに変えられる人がフィットすると思います。技術的な成長はもちろん、チームでの学びや対話を楽しめる人と一緒に働きたいですね。

※ネクサスエージェントでは、エンジニアを募集しています。

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

\ 3分でわかる /
資料ダウンロード
Findy Team+のサービス資料は、
こちらからダウンロードできます。
資料をダウンロードする
Findy Team+サービス資料

おすすめ記事

記事一覧