この記事はアソビュー！ Advent Calendar 2025 の10日目(表面)です。
こんにちは、アソビューでSREエンジニアをしている長友です。 アソビューでは昨年より開発生産性向上にフォーカスしており、開発生産性委員会を組織してプロダクト組織の開発生産性向上について考えてきました。 昨年度の取り組みはこちらの記事からご参照ください。
今回は弊社の開発生産性向上委員会による2025年の取り組みを紹介していこうと思います。
先に結論を書くと、弊社の2025年の開発生産性向上の大きなテーマはアジャイル・スクラム改善にありました。
最近の弊社のtech blogでも、スクラムをテーマにしたものが増えつつあるのはそういった背景もあります。
- なんちゃってスクラムチームを改善した最初の一歩 - asoview! Tech Blog
- “わからない”を言えるチームは強い〜技術ではなく空気づくりで戦う新米スクラムマスター〜 - asoview! Tech Blog
- チームの振り返り活動をカイゼンしたら色々と盛り上がった話 - asoview! Tech Blog
本記事ではそこに辿り着いた経緯も含めて、改善のために委員会としてどのような取り組みをしてきたのかを以下の流れで紹介していきます。
- 2024年末〜2025年3月 数値改善疲れと今後の生産性向上の方向模索
- 2025年4月 アジャイル・スクラムの取り組み向上に舵を切る
- 2025年5月以降 アジャイル・スクラムの取り組みの質を高める施策
- 総括 ~ これからの展望
2024年末〜2025年3月 数値改善疲れと今後の生産性向上の方向模索
Findy Team+の導入と劇的数値改善
2025年の前に前提となる2024年の話を少しします。
2024年はFindy Team+を導入し、初めてPull Request周りの数値が見えるようになった年でした。
弊社のPullRequestのサイクルタイム*1はこうなっていたのか！ 変更のリードタイム*2は他社水準と比べてこんなに長いのか！など様々な感想が出ました。
指標の可視化によって改善余地が明確になったことから、まずは手をつけやすく効果が出しやすい領域を優先して取り組みました。
Pull Request の粒度改善や、Githubの共通通知機能の導入・デイリー後のレビュー会といったレビュー時間短縮につながる施策がその第一歩でした。
結果として、目標とした「2024年7月, 8月の自チームの変更のリードタイムを11月,12月時点で2/3とする」ことに概ね成功しました。これは元の数値と比較した際に劇的な改善だったと言えるでしょう。
しかし、目標を達成した後に各チームでの振り返りの共有会を行うと、そこではFour Keys疲れ・数値改善疲れが見られました。
数値改善疲れとグッドハートの法則
振り返りで出てきた意見によると以下のような症状が見られました。
- PullRequestの分割や即時レビュー・即時リリースをかなり徹底したことによる疲れ
- 一定数値に達した先からはタスクやPullRequestの粒度、レビュースピードに対する取り組みだけでは改善が難しく、CommitをするタイミングやPullRequestを出すタイミングを図るなどの“数字だけを良く見せるための工夫”に意識を傾けたくなる
これらは、開発生産性の文脈で警鐘を鳴らされているグッドハートの法則（「指標が目標になると良い指標ではなくなる」*3）の症状に当てはまるものもあるかと思います。
伸び代がある！改善できる！目標にしよう！というのは最初は推進剤になるかもしれないが、一定に達すると歪みを生じさせることを痛感しました。
Four Keysに対する納得感と他の指標を模索する時期
振り返りの中ではFour Keysの劇的な数値改善に反して実際に生産性が上がった実感が薄いといった意見も出ました。
PullRequestに関連する領域だけでなく、一つの価値を考えて届けるまでのスピードを早めることや、その価値自体を最大化することに関心があると、どうしても現状見えている範囲の数値と生産性向上に対する実感とのズレが生じます。
Four Keysは開発プロセスの一部分を切り取った指標であるため、「何を作るか」「どんな価値を届けるか」といった観点との距離があり、このギャップが納得感の薄さにつながっていました。
こうした状況から、より自分たちの関心に近い生産性指標を探りたいという問題意識が生まれました。
しかし同時に、Four Keys に関連する改善についても、DORAが示すケイパビリティに照らすと、まだ取り組める余地が十分に残っていることも明らかでした。
そのため、次のどういった取り組みを優先して行うべきか判断が難しい時期でした。
変更のリードタイムを目標にするのをやめたこともあり、ここから各チームでAI利用数、ベロシティ、自動テスト導入率などの新たに追いかける指標を模索する期間が始まりました。
2025年4月 アジャイル・スクラムの取り組み向上に舵を切る
各チームで指標を模索し悩む中、委員会としては結果的にスクラム・アジャイルの取り組み向上に舵を切ることに決めました。
これには以下の理由があります。
理由 アジャイル・スクラムは開発生産性のレベル2, 3の生産性と親和性が高く、そしてレベル1の生産性の効果も高める
開発生産性のレベルについては、こちらの記事で詳細に説明されていますが、改めてそれぞれ以下の通りです。
- レベル1の生産性 = 仕事量の生産性
- レベル2の生産性 = 期待付加価値の生産性
- レベル3の生産性 = 実現付加価値の生産性
アジャイル・スクラムによるチーム改善はプロダクトづくりの核心である「ユーザーにどんな価値を届けるべきか」という事業上の意思決定の質を高めます。
ステークホルダーと開発チームが早い段階から共通のテーブルに着き、価値仮説を共有し、検証に必要な最小限のプロダクトを素早く届ける。この一連のフィードバックサイクルが確立されることで、期待付加価値・実現付加価値の双方における生産性が向上します。
反対に、届ける価値についての検討・判断の精度が低いまま、レベル1の生産性（開発効率など）だけを追い求めても、ユーザーに届く価値は最適化されません。 まず意思決定の精度を高め、価値仮説の検証速度を上げることが、事業インパクトを最大化する最短経路と考えました。
取り組みを始める前のアジャイル・スクラムの現状
施策を進める前においても弊社の開発チームは長らくスクラムを採用しており、スプリントイベントが定期的に実施され、レトロスペクティブにより改善議論も行われていました。
しかし、以下のような観点での伸び代が多く残されていました。
- そもそもなぜスクラムでやるのかといった理由や、スクラムの思想に対する目線合わせ
- 状態: スクラムガイドあまり読んだことがない。透明性・検査・適用や各ロール・各イベントについての共通理解が定まっていない
- 全員がスクラムの思想を理解した状態での取り組み方の改善
- 状態: この状態でてくる改善には長期的な視点がなく場当たり的になりやすい
こうした状態から、スクラムの基本に立ち返るところから始めていくことになりました。
2025年5月以降 アジャイル・スクラムの取り組みの質を高める施策
アジャイル・スクラムの質を高めるために行った施策を、目的/やったこと/得られたことの3点から見ていきたいと思います。
アジャイル・スクラムに対する理解・状態の把握
まずチームごとに、アジャイル・スクラムに対する理解度と現在の状態について目線を揃えることから始めました。
- 目的: スクラムの思想や用語、各ロールの役割に対する前提認識を揃え、改善の起点となる「現在地」を共有すること
- やったこと: スクラムガイドを全員で読み込み、1文ごとに意味を議論しつつ、Scrum.org記載のスクラム成熟度の表*4を使って各ロールごとの成熟度レベルを話し合う
- 得られたこと: スクラムの根本的な考え方に対する共通理解が進み、自分たちの立ち位置と伸び代、今後の改善の方向性をチーム単位で認識できるようになった
スクラムガイドを読むワーク例
各チームの運営・取り組みの共有
スクラム改善のギアが上がったタイミングで、各チームの運営スタイルや取り組み・課題を共有し合う場を設けました。
目的: 他チームの工夫や悩みを知ることで、良い実践を横展開しつつ、客観的な視点を取り入れながら改善のアイデアを広げること
やったこと: 各スクラムマスターが「プロダクトビジョン」「プロダクトゴール」「メンバー」「スプリントの過ごし方」「取り組みや課題」を共通アジェンダでスライド化し、隔週の共有会で交代で発表・ファシリテーションを担当。miro上にスライドを展開し、参加者がリアルタイムで感想や質問の付箋を貼りながら議論。
得られたこと: チームごとの違いや共通の課題が見えるようになり、スクラムマスター同士がファシリテーションスキルを磨く場にもなった。
miroによるスライド共有 この取り組みは11月末まで続きましたが、各チームの状態や抱えている課題もある程度把握できたため、チームごとに次にどういった改善の選択肢・方向性があるのかも考えやすくなりました。
アジャイル・スクラムアンケートの実施
これは直近の施策となりますが、アジャイル・スクラムの理解度や取り組み状況を定期的に可視化するために毎月アンケートを配信することにしました。
目的: 各チームのスクラム改善を継続的に推進する仕組みをつくり、スクラムマスターだけでなくメンバー全体の意識を高めること
やったこと: コインチェックさんのスクラム成熟度のセルフチェックの取り組みを参考に、AIで設問候補を生成しつつ、GASとスプレッドシートで自動集計できる形のアンケートを設計・配布.
得られたこと（想定）: 定量・定性の両面からチームの状態を把握し、アンケート結果を起点に次の改善を議論しやすくなることを期待
GASによって自動集計できる設問リストのスプシを用意 このように、始めたばかりの施策も含めて、開発生産性委員会の定例ミーティング（以下、開発生産性定例）としてはアジャイル・スクラムの推進を継続していきます。
総括 ~ これからの展望
アジャイル・スクラム改善の効果
これまで見てきたように、2025年はアジャイル・スクラム改善に向けて複数の施策を進めてきました。 改善の取り組み自体はまだ開始から約5カ月ですが、その期間でも各チームにおいて以下のような変化が見られています。
- 完成の定義に対する意識が高まり、チームとして明文化・運用を行うようになった
- スプリントレビューに営業・制作など社内ステークホルダーを積極的に招くようになった
- スプリントレビューで「実際に動くもの」を見せることへの意識が高まり、本番を想定したデモデータ作りや事前のリハーサルを行うようになった
- メンバーが意見を出しやすいレトロスペクティブへ向けた場づくりの改善が進んだ
総じて、スクラムガイドの読み込みを通じて全員の理解が深まったことが、こうした取り組みの変化に大きく寄与していると感じています。
ここで挙げた内容は一部に過ぎませんが、各チームのスクラムマスターによる取り組みの詳細記事で紹介されることもあるので、是非そちらもご覧ください。
Four Keysってどうなったの？
さて、ここまでアジャイル・スクラム改善の推進に舵を切ってからの取り組みを見てきましたが、この間「元から見ていたFour Keysってどうなったの？ 」という疑問が出てくることでしょう。 結論として、5月あたりから徐々に意識は薄れ、順調にデプロイ頻度は下がり、変更のリードタイムも伸びていきました！
まさにあちらを立てればこちらが立たずといった状態です。しかし、この推移に対して実感値としては生産性が下がっている感覚はあまりないという声も挙がっています。 この辺りは昨年主にPullRequestの周辺範囲での改善に注力していたことも影響しているのかもしれません。
改めて、Four Keys の前提となる DORAのケイパビリティに代表される、実証研究に基づいた改善施策を学び直し、現場で確かな効果を伴う改善を積み上げていくことが重要だと考えています。
また、アジャイル・スクラムに取り組んできた結果、プロダクト開発そのものの進め方に良い変化が生まれ始めている現在の状況を踏まえると、当初掲げていたレベル1の生産性に改めてフォーカスする意義も高まってきたように感じています。
2026年の抱負〜定性的な改善の深化と、定量指標に基づく改善の再強化
2025年は、アジャイル・スクラムの改善に本格的に取り組んだ一年でした。
その結果、チームの意識や働き方に明確な変化が生まれ、改善前よりも確実に前進している手応えがあります。
このポジティブな流れを止めず、さらに大きく育てていくことが、2026年の開発組織に求められています。
同時に、Four Keys をはじめとした定量的な指標を再び重視するタイミングが来ていると感じます。
チーム内外に対して一定の説得力を持つ指標を明確にし、効果的なプラクティスによって実感を伴いながら改善していくスタートラインに立った気持ちです。
2026年は定性的な取り組みと定量的な指標の双方を掛け合わせ、より価値提供力を高める一年を目指せたら、、といった抱負でこの記事を締めたいと思います。
アソビューではより良いプロダクトを素早く世の中に届けられるよう、開発生産性向上の取り組みを強化しています。 我々と一緒に働くエンジニアも募集していますので、興味のある方はぜひお気軽にエントリーください！
*1:レビュー期間、レビュー後からリリースまでの時間などの総称
*2:DORAが提唱したソフトウェア開発チームのパフォーマンスを測る4つの指標であるFour Keysの1つ。1つの変更(Commit)がmaster/mainブランチにマージされるまでのリードタイム
*3:開発生産性カンファレンスでケント・ベック氏も直近強く警鐘を鳴らしています。https://tech.findy.co.jp/entry/2025/10/20/070000
*4:https://www.ryuzee.com/contents/blog/14555で紹介されていたところから着想を得ました
