公開日
なぜベロシティを上げても顧客満足度が低い?アジャイルの盲点と改善策を解剖

アジャイルソフトウェア開発(ASD)が主流となった現代において、「ユーザー満足度の向上」は多くの開発チームにとって最重要課題の一つです。しかし、日々の開発業務の中で、具体的にどの活動がユーザーの満足度に結びついているのかを正確に把握し、改善に繋げるのは容易ではありません。果たして、開発スピードを上げることだけがユーザー満足度を高める唯一の道なのでしょうか?
本記事では、早稲田大学とAGEST Inc.の研究者らが発表した論文「Analysis System of Agile Software Development Process Metrics and User Satisfaction」(2025年)に基づき、アジャイル開発プロセスにおける各種指標と、実際のユーザー満足度との間にどのような関係があるのかを分析した興味深い研究結果をご紹介します。この研究は、特にオープンソースソフトウェア(OSS)開発のデータを活用し、具体的な数値データに基づいて「本当にユーザーのためになる開発とは何か」という問いに迫るものです。
なぜアジャイル開発で「ユーザー満足度」が最重要視されるのか?
現代のソフトウェア開発において、アジャイルなアプローチは迅速な市場投入や変化への柔軟な対応を可能にするものとして広く受け入れられています。その根底には、常にユーザーを念頭に置いた開発思想があります。
「アジャイルソフトウェア開発宣言」が示すユーザー中心の思想
2001年に発表された「アジャイルソフトウェア開発宣言」では、「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」という原則が筆頭に掲げられています。この宣言は、その後のアジャイル開発手法(スクラム、XP、カンバンなど)の発展に大きな影響を与え、開発プロセス全体を通してユーザーとの連携やフィードバックを重視する文化を育んできました。変化への対応、動くソフトウェア、個人と対話、そして顧客との協調といった価値観は、すべてユーザーに価値を届け、満足度を高めることを目指していると言えるでしょう。
従来の開発プロセス指標とユーザー満足度を結びつけることの難しさ
アジャイル開発では、スプリントごとのベロシティ(消化した作業量)やリードタイム(要求から完成までの時間)といったプロセス指標が用いられます。これらの指標はプロジェクトの進捗管理やチームの生産性評価に役立ちますが、それらが直接的に「ユーザー満足度」の向上にどう貢献しているのかを定量的に示すことは難しいという課題がありました。多くの現場では、ユーザーの声はアンケートやレビューという形で集められるものの、それが日々の開発プロセスのどの部分と強く関連しているのか、明確なデータに基づいて判断することは稀だったのではないでしょうか。今回の研究は、このギャップを埋める試みの一つと言えます。
開発プロセスとユーザー満足度の”つながり”を可視化する「AS-ASD」システム
ユーザー満足度という、ともすれば曖昧になりがちな指標を、具体的な開発活動と結びつけるためには、客観的なデータ分析が不可欠です。今回の研究では、そのための情報システム「AS-ASD (Analysis System of Agile Software Development)」が構築されました。
研究の核心:どの開発活動がユーザーの「うれしい!」に直結するのか?
AS-ASDの目的は、アジャイル開発のどのプロセスがユーザー満足度に影響を与えているのかを統計的に明らかにすることです。開発チームが日々行っているIssue(課題やバグ報告)への対応や、Pull Request(ソースコードの変更提案)の処理といった活動が、最終的にユーザーの製品に対する評価、つまり満足度にどう反映されるのか。それを定量的に捉えようというわけです。
AS-ASDの仕組み:GitHubの活動データとユーザーレビューをどう分析する?
AS-ASDは、主に二種類のデータソースから情報を収集し分析を行います。一つは、多くのOSSプロジェクトで利用されている開発プラットフォームGitHubから得られるIssue、Pull Request、リリースといった時系列の開発活動データです。もう一つは、Google Play Storeなどに投稿される実際のユーザーレビューです。
AS-ASDシステムの処理フロー概要
AS-ASDはまずGitHubから開発プロセスに関するデータを取得し、後述するような各種ASDプロセス指標を算出します。並行して、ユーザーレビューを収集し、VADERという感情分析ツールを用いてセンチメントスコア(ユーザー満足度を示す数値)を計算します。これらの時系列データを40週間の移動平均で平滑化した上で、ASDプロセス指標とユーザー満足度の間にどのような相関関係があるかを分析します。さらに、ユーザーレビューの内容をトピック分析やキーワード分析することで、相関関係の背景にあるユーザーの具体的な意見や感情を探ります。
ユーザー満足度との関連を探る:AS-ASDが分析した主要アジャイルプロセス指標
AS-ASDでは、アジャイル開発の文脈で広く用いられ、ユーザー満足度への影響が考えられる以下の5つの主要なプロセス指標を分析対象としました。
本研究で分析対象とした主要なASDプロセス指標
No. | 指標名 | 対象エンティティ | 手法 | 定義 |
---|---|---|---|---|
M0 | ベロシティ (Velocity) | 実装 | スクラム, XP, LeanSD | マージ日基準で、週ごとにマージされたプルリクエストの数。 |
M1 | リードタイム (Lead Time) | 開発サイクル全体 | カンバン | クローズ後のリリース日基準で、週ごとに、Issue作成からそのクローズ後の最新リリース日までの平均時間。該当Issueはリンクされたプルリクエストを持ち、そのプルリクエストによってクローズされる必要がある。 |
M2 | キュータイム (Queue Time) | 開発サイクル全体 | LeanSD | マージ日基準で、週ごとに、プルリクエストのレビュー依頼日からマージまでの平均時間。 |
M3 | プロセッシングタイム (Pull Request) | 開発サイクル全体 | LeanSD | 作成日基準で、週ごとに、プルリクエスト作成からマージまでの平均時間。 |
M4 | プロセッシングタイム (Issue) | 開発サイクル全体 | LeanSD | 作成日基準で、週ごとに、Issue作成からクローズまでの平均時間。該当Issueはリンクされたプルリクエストを持ち、そのプルリクエストによってクローズされる必要がある。 |
これらの指標の時系列変化と、ユーザーレビューから算出されるユーザー満足度の時系列変化を比較することで、両者の関係性が探られました。
分析結果:ユーザー満足度と本当に相関があった開発プロセス指標とは?
36のOSS Androidアプリケーションを対象に行われたAS-ASDによる分析は、いくつかの興味深い結果を明らかにしました。特に、どの開発プロセス指標がユーザー満足度と強く関連しているのか、そしてそれはどのような関係なのかが数値で示されました。
全体傾向:ユーザー満足度と最も強く関連していたのは「Issue処理の速さ」
全36アプリにおけるASDプロセス指標とユーザー満足度(センチメントスコア)の相関分析結果
No. | 指標名 | 正の相関 | 負の相関 | 相関なし |
---|---|---|---|---|
M0 | ベロシティ (Velocity) | 39% (57%) | 36% (36%) | 25% (7%) |
M1 | リードタイム (Lead Time) | 27% (23%) | 45% (62%) | 27% (15%) |
M2 | キュータイム (Queue Time) | 35% (25%) | 45% (58%) | 19% (17%) |
M3 | プロセッシングタイム (Pull Request) | 39% (33%) | 48% (58%) | 13% (8%) |
M4 | プロセッシングタイム (Issue) | 12% (0%) | 64% (85%) | 24% (15%) |
括弧内はユーザー満足度が低い傾向にあるアプリ(n=14)の結果
この表が示すように、分析対象となった全36アプリケーションのうち、実に64%で「M4: プロセッシングタイム」とユーザー満足度の間に統計的に有意な負の相関が見られました。これは、Issueの処理時間が短ければ短いほど、ユーザー満足度が高い傾向にあることを意味します。つまり、ユーザーが報告した問題やバグに迅速に対応することが、満足度向上に直接的に繋がっている可能性が高いと言えます。
特に満足度が低下しているアプリでは「Issue対応の遅れ」が悪影響
さらに注目すべきは、ユーザー満足度が全般的に低い傾向にある14のアプリケーションに絞って分析した場合です。このグループでは、「M4: プロセッシングタイム」とユーザー満足度の負の相関は85%のアプリで見られ、より顕著な関係が確認されました。 同様に、これらの低満足度アプリでは、「M1: リードタイム」も62%のアプリで、「M2: キュータイム」も58%のアプリで、それぞれユーザー満足度と負の相関を示しました。これは、ユーザーが問題を報告してから実際に解決されるまでの時間が長引いたり、開発内部の滞留時間が長くなったりすることが、特にユーザーの不満を増幅させる要因となっている可能性を示唆しています。
意外な結果:「開発スピード(ベロシティ)」とユーザー満足度には明確な相関なし
一方で、多くの開発チームが重視する「M0: ベロシティ」については、ユーザー満足度との間に明確な相関関係は見られませんでした。ベロシティが高い(開発スピードが速い)からといって必ずしもユーザー満足度が高いわけではなく、またその逆も然り、という結果です。このことは、単に開発量を増やしたり、リリース頻度を上げたりするだけでは、ユーザー満足度の向上に直結するとは限らないことを示唆しています。質を伴わない速度や、ユーザーが真に求めていない機能の追加は、むしろ満足度を低下させる可能性すらあるのかもしれません。
具体例で見るプロセス時間と満足度の関係:Wireアプリの場合
以下のグラフは、メッセージングアプリ「Wire」における「M2: キュータイム」とユーザー満足度の時系列変化を示したものです。上段のグラフでは、キュータイム(緑線)が上昇する期間と、ユーザー満足度(青線)が低下する期間が一部重なっている様子が見て取れます。下段のグラフは、ユーザー満足度の変化に対してキュータイムの変化をどれだけ遅延させると相関が強くなるかを示しており、このアプリでは満足度の変化に対してキュータイムが約20週早く変動した際に-0.3を下回る負の相関が確認されました。これは、レビュー待ち時間が長引くことが、少し遅れてユーザー満足度の低下に繋がっている可能性を示唆しています。論文ではM4(Issue処理時間)の重要性が強調されていますが、このような開発プロセスの遅延がユーザー満足度に影響を与える一例と言えるでしょう。
Wireアプリにおけるキュータイム(M2)とユーザー満足度の時系列変化
Wireアプリにおけるキュータイム(M2)とユーザー満足度の相関係数
定量データだけでは見えない本音:ユーザーレビュー分析が示す「不満の理由」と「改善のヒント」
プロセス指標とユーザー満足度の相関関係は数値データとして示されましたが、その背景にはどのようなユーザーの声があるのでしょうか? 本論文では、ユーザーレビューの内容を分析することで、この「なぜ?」にも迫ろうとしています。
ネガティブレビューに共通する不満点:「動かない」「使いにくい」具体的な問題
WordPressアプリのネガティブレビュー(満足度-0.05以下)におけるトピック分析結果(上位10件)
トピッククラスター | トピック名 | 代表的な文章 (和訳) | 割合 (%) |
---|---|---|---|
アプリ | 使えないアプリ | 使えない。 | 2.7 |
GUI | ブロックエディタの問題 | ブロックエディタとクラシックエディタの間に問題がある。 | 3.6 |
GUI | フラストレーションとナビゲーション | イライラを通り越している。 | 3.5 |
機能・機能性 | メディアアップロードエラー | 複数のメディアどころか、1つのメディアもアップロードできないようだ。 | 6.5 |
機能・機能性 | モバイルでのWordPressブログ | WordPressのモバイルアプリとしてがっかりした。 | 6.4 |
機能・機能性 | 下書き投稿の保存の問題 | 時々、下書きが保存されない。 | 6.0 |
機能・機能性 | コメントとスパム通知 | これでスパムコメントを削除したかったのに、できない。 | 3.1 |
機能・機能性 | コピー&ペーストとオフラインの問題 | さらに、全てがブロックになっているので、投稿をコピー&ペーストすることすらできない。 | 2.6 |
アップデート/バージョン | 新しいアップデートの問題 | あなたの新しいアップデートは最悪だ。 | 3.4 |
セキュリティ | ログインパスワードエラー | セルフホスト型のウェブサイトにログインできない :( | 9.4 |
この表は、WordPressアプリに寄せられたネガティブなレビュー(センチメントスコアが-0.05以下)をトピック分析した結果の一部です。「メディアアップロードエラー」「ログインパスワードエラー」「下書き保存の問題」「ブロックエディタの問題」といった、非常に具体的な機能不全や使いにくさに関する不満が上位を占めていることがわかります。これらの多くは、ユーザーがIssueとして報告する可能性のある内容であり、これらの問題が迅速に解決されない場合、ユーザー満足度が低下することは想像に難くありません。
ユーザー満足度が低い時期のレビューには「バグ修正」や「機能改善」を望む声が集中
ユーザー満足度が低い時期(L)と高い時期(H)における特定キーワードのレビュー内出現割合の比較
キーワード | WordPress (L/H比) | Wire (L/H比) | DuckDuckGo (L/H比) | 傾向 |
---|---|---|---|---|
bug | 2.3 | 1.9 | 2.1 | 満足度が低い時期に「バグ」に関する言及が増加 (2倍以上) |
fail | 1.4 | 2.2 | 5.3 | 満足度が低い時期に「失敗する・動かない」といった言及が増加 |
fix | 1.5 | 1.8 | 2.4 | 満足度が低い時期に「修正してほしい」という要望が増加 |
update | 3.1 | 5.4 | 2.6 | 満足度が低い時期に「アップデート」に関する言及が増加 (関連する問題を示唆) |
please | 3.8 | 1.3 | 4.4 | 満足度が低い時期に「お願いだから」といった懇願の言葉が増加 |
why | 2.6 | 3.4 | 4.6 | 満足度が低い時期に「なぜ」という疑問を呈する言葉が増加 |
L/H比は、ユーザー満足度が低い時期のレビューにおけるキーワード出現割合を、ユーザー満足度が高い時期のレビューにおけるキーワード出現割合で割ったものです。1より大きい場合、満足度が低い時期により多くそのキーワードが出現したことを示します。
さらに、ユーザー満足度が高い時期と低い時期で、レビュー内に含まれるキーワードの出現頻度にどのような違いがあるかも分析されました。その結果、満足度が低い時期には、「fix(修正して)」「bug(バグ)」「fail(失敗する、動かない)」といった直接的な問題点を指摘する言葉や、「update(アップデート後におかしくなった)」「please(お願いだから直して)」といった要望や懇願を示す言葉、「why(なぜこうなったの?)」といった疑問を呈する言葉の出現割合が、満足度が高い時期に比べて2倍以上に増加する傾向が見られました。このことからも、ユーザーが直面している問題への迅速かつ的確な対応が、満足度を維持・向上させる上で極めて重要であることが裏付けられます。
まとめ:アジャイル開発でユーザー満足度を高める秘訣は「Issueへの迅速な対応」
本研究から見えてきた、アジャイル開発でユーザー満足度を真に高めるための重要なポイントは以下の通りです。
- Issue(課題・バグ)への迅速な対応、特にプロセッシングタイム(Issue)の短縮が、ユーザー満足度向上と最も強く関連しています。
- 開発スピード(ベロシティ)自体は、必ずしもユーザー満足度に直結しません。 量よりも、ユーザーが価値を感じる変更を適切なタイミングで提供することが求められます。
- ユーザーレビューは、開発プロセス改善のための貴重なヒントの宝庫です。 ネガティブなレビューは具体的な問題点を、キーワードの増減はユーザーの関心事の変化を示唆しています。
これらの結果を踏まえ、アジャイル開発チームがユーザー満足度を向上させるためには、以下の点に注力することが推奨されます。
- ユーザーからのフィードバック(特にIssueやバグ報告)を積極的に収集し、迅速に処理する体制を構築・維持する。
- 単に開発量をこなすこと(ベロシティの向上)だけを目的とせず、ユーザーが直面している問題を解決し、価値を届けることを最優先する。
- ユーザーレビューを定期的に分析し、製品の問題点や改善要望を早期に把握する。
これらの提言は、アジャイルの本質である「顧客満足の最大化」に立ち返るものであり、日々の開発プロセスを見直すことで、真のユーザー満足度向上を目指しましょう。
開発生産性やチームビルディングにお困りですか? 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください!
参考資料: