# User feedback in continuous software engineering: revealing the state-of-practice > [!abstract] 概要 > **背景** 組織は不確実性に対処し無駄を最小化するため、インクリメンタルな更新の継続的デリバリを選ぶ。しかし継続的エンジニアリング(CSE)のプラクティスを適用するには、顧客とエンドユーザーからの入力を伴う継続的なフィードバックループが必要である。 > **課題** ソフトウェアのデリバリサイクルが短くなり続けるなかで、従来の要求獲得・妥当性確認の技法を適用することはますます難しくなる。同時に、頻繁なデリバリはエンドユーザーの振る舞いをエンジニアリングチームに知らせる利用データとテレメトリを大量に生み出す。実務者が CSE においてユーザーフィードバックをどう扱っているかを記述した文献は限られている。 > **目的** 我々は CSE におけるユーザーフィードバックの活用に関する実務の現状を探ることを目指す。具体的には、どのプラクティスが、どのように使われ、それらのプラクティスにどんな欠点があるかである。 > **方法** 我々は質的サーベイを実施し、13 の製品開発企業における 21 件のインタビューの分析を報告する。データの解釈にはテーマ分析とケース横断分析を適用する。 > **結果** 我々の先行研究に基づき、CSE においてユーザーフィードバックがどう活用されるかの概念モデルを提案する。さらに、ユーザーフィードバックの継続的な収集と分析に関して特定した課題を報告し、実務への含意を示す。 > **結論** 企業はエンドユーザーの選好を推定するため、質的手法と量的手法を組み合わせて使う。同時に、データの継続的な収集・分析・解釈と、意思決定での利用には問題がある。課題は、適切なメトリクスと分析技法の選択、リソース配分、そして定義のあいまいなユーザー群へのアクセスの難しさに関わる。CSE の実務者への我々の助言は、フィードバックの解釈に十分なリソースと労力を確保することであり、それはテレメトリダッシュボードによって促進できる。 ## 論文情報 - タイトル: User feedback in continuous software engineering: revealing the state-of-practice - 著者: [[Anastasiia Tkalich]] (SINTEF) / [[Eriks Klotins]] (Blekinge Institute of Technology, SERL) / [[Tor Sporsem]] (SINTEF) / [[Viktoria Stray]] (SINTEF, University of Oslo) / [[Nils Brede Moe]] (SINTEF, Blekinge Institute of Technology) / [[Astri Barbala]] (SINTEF) - 媒体: Empirical Software Engineering, 2025年, vol.30, article 79(52 ページ、オープンアクセス CC BY 4.0) - DOI: 10.1007/s10664-024-10557-2(Accepted 2024-09-30 / Published online 2025-03-07) - 補足資料(初期テーマとコード): https://zenodo.org/records/12544288 - 資金: ノルウェー研究評議会(10xTeams・TransformIT・Digital Class)、スウェーデン知識財団(KK-stiftelsen) ## 概要 ノルウェーに拠点を置く 13 製品(ケース)の実務者 19 人への 21 件の半構造化インタビューから、継続的ソフトウェアエンジニアリング(continuous software engineering, CSE)においてユーザーフィードバックがどう収集・分析・活用されているかを記述した質的サーベイである。技法を「明示的フィードバック収集」「暗黙的データ収集」「ユーザーサンプリング」「分析と提示」の 4 群に整理し、目的(G1〜G11)と課題 6 群を対応づけ、著者らの先行研究の CSE 概念モデル(Klotins et al. 2022)へ写像した概念モデルを提案する。中心的な主張は、収集は自動化できても解釈は自動化しにくく、分析の不足がフィードバックを製品計画から切り離すという点である。 ## 問題設定 - CSE は小さなインクリメントを短く頻繁なサイクルで届けるため、デリバリごとにユーザーフィードバックを集める機会が生まれる。ただしデリバリの頻度が上がれば、フィードバックの収集と分析にも同じだけの頻度が要る。 - インタビューなど利害関係者との会合は時間がかかり、頻繁なデリバリのボトルネックになりうる。利害関係者側も頻繁な要求獲得の会合に応じられないことがある。 - テレメトリや実験などの量的手法は素早く、ユーザーの負担も小さいが、ユーザーの動機や理由づけへの洞察は限られる。 - 本論文でのユーザーフィードバックは、製品開発のために現在・潜在のエンドユーザー、その代理(proxy)などから集めるフィードバックとデータの全体を緩く指す。 - 研究課題は 2 つである。 - RQ1: CSE においてユーザーフィードバックはどう収集・適用されるか。 - RQ2: CSE においてユーザーフィードバックを活用するうえでの課題は何か。 ### 背景: CSE の概念モデルと明示的・暗黙的フィードバック 著者らの先行研究(Klotins et al. 2022)の CSE 概念モデルは閉ループであり、上半分(製品計画、自動化による実装、デプロイ)がソフトウェアのデリバリを、下半分がユーザーフィードバックとテレメトリの収集・監視・解釈を扱う。先行研究では、企業はデリバリ速度を上げるために手近な改善に向かいがちであり、サイクル全体、特に直近にデリバリしたソフトウェアへのユーザー入力を収集・解釈する能力を考慮しないと、リソースを浪費しかねないと示した。 ![[_attachments/user-feedback-cse-state-of-practice/fig01-cse-conceptual-model.png]] (図1(Figure 1): CSE の概念モデル(Klotins et al. 2022 より)。Level I エンジニアリングから Level IV エンドユーザー/顧客までの層と、継続的利用・信頼・顧客フィードバックを含む閉ループ) - **明示的フィードバック(explicit feedback)**: ユーザーが製品を変える目的で開発者にフィードバックを共有していると自覚している技法から得られる。主観的な意見を表す(インタビュー、アンケート、サーベイなど)。 - **暗黙的フィードバック(implicit feedback)**: ユーザーがその自覚を持たない技法から得られる。実際の利用行動を反映する、自動収集された利用情報などである。先行研究では、暗黙的フィードバックの多くは新機能の発見ではなく問い合わせ対応とバグ修正に使われる(Johanssen et al. 2019)。 Fabijan et al.(2015)の一覧に基づき、ユーザー入力を捉える技法は表1の 15 種に整理される。 | # | 技法 | 種別 | 定義 | |---|---|---|---| | 1 | インタビュー | 明示的 | ユーザーが開発者の質問に対面で答える | | 2 | 製品内サーベイ | 明示的 | 現行製品へのユーザーの評価を測る | | 3 | 観察 | 明示的 | 開発者がユーザーを観察する | | 4 | シアターセッション | 明示的 | 複数のユーザーが機能要望と自分の文脈での使い方を述べる | | 5 | プロトタイプテスト | 明示的 | 部分的に開発したインターフェースと機能をユーザーと協働で評価する | | 6 | インシデントレポート | 明示的 | ユーザーが生成する問題記述(サポートデータ、トラブルチケット) | | 7 | 利用者としての開発者 | 明示的 | 開発者による製品の内部評価 | | 8 | ユーザーペアリング | 明示的 | 複数ユーザー間のファシリテートされた議論 | | 9 | ウォークスルー | 明示的 | 全ユーザーシナリオの動作を確かめる統合演習を顧客代表の前で示す | | 10 | オンライン広告 | 暗黙的 | 外部サイトに製品情報を掲示し潜在的な新製品への関心を評価する | | 11 | ベータテスト | 暗黙的 | 製品の初期版をユーザーの標本に渡す | | 12 | 運用・イベントデータ | 暗黙的 | ユーザーごとのオンライン収集データ(属性、行動)と製品性能データ(応答性、エラー) | | 13 | A/B テスト | 暗黙的 | 同じ機能の異なる版を見せ、望ましい反応を生む版を評価する | | 14 | ソーシャルネットワーク | 暗黙的 | ソーシャルメディア上での製品評価 | | 15 | クラウドファンディング | 暗黙的 | コミュニティの支持から製品の成功率を評価する | (表1(Table 1): ユーザー入力を捉える技法。Fabijan et al. 2015 に基づく) 著者らは、この分類が二値ではないことも指摘する。プロトタイプテストとベータテストは成果物と他の技法の組み合わせであり、利用者としての開発者は本質的にサンプリング技法、A/B テストはデータ分析に帰着する。 ## 提案手法 本論文の「手法」は研究方法と、結果から導いた概念モデルである。 ### 研究方法: 質的サーベイ - 設計: Jansen et al.(2010)の質的サーベイ。標本内の現象の多様性を探り、ケースごと・ケース横断の分析を行う。量的サーベイと違い一般化は狙わず、質的データの説明力に依拠する。分析単位は企業に埋め込まれたソフトウェア製品(ケース)である。 - 文脈: 3 つの研究プロジェクト(10xTeams・TransformIT・Digital Class)の参加企業から、偶発的サンプリングと雪だるま式サンプリングでケースを選んだ。全ケースがノルウェーに拠点を持つ。 - データ収集: 2022 年 9〜12 月に半構造化インタビューを実施した。毎回 2 人以上の著者が参加し、確証バイアスの低減を図った。平均 45 分(32〜63 分)、書き起こしは計 356 ページである。 | # | インタビューガイド項目 | 研究上の焦点 | |---|---|---| | 1 | 製品の話をしてください | 製品と市場の文脈 | | 2 | 製品開発にどんなユーザーデータを使うか。どう使うか。ユーザーデータに基づく変更の例は。エンドユーザーの洞察を確保するツール・プラクティスは | ユーザーフィードバックとデータ収集の技法(RQ1) | | 3 | なぜそのデータを使うのか(なぜその変更をしたのか) | 技法を適用する理由(RQ1) | | 4 | 何がうまくいき、何がうまくいかないか | ユーザーフィードバックの課題(RQ2) | (表2(Table 2): インタビューガイド) - 分析: NVivo 13 によるテーマ分析(Braun and Clarke 2006)で 766 件の初期コードを得て、テーマへまとめた。技法名は Fabijan et al.(2015)の一覧で統一し、一覧に合わないものは新しいテーマ名とした。続いて表計算でケース横断のパターンを比較し、技法を機能別(収集・サンプリング・分析と提示)にまとめた。最後に暫定結果を参加者に共有し、13 ケース中 9 ケースから返答を得た。 - 集計は面接単位ではなくケース単位で正規化し、ある現象を言及したケース数を数えた。 ### ケース概要 製品の成熟段階は、初期段階(最初のリリースからスケール準備まで)、成長段階(スケール準備が整い、ユーザーと収益を増やす段階)、成熟段階(市場シェアと顧客基盤が確立し、維持と運用最適化を目指す段階)の 3 つに分けた。 | ID | 製品(成熟段階) | ユーザー層(N=ニッチ / G=一般) | 市場 | 面接した役割(件数) | |---|---|---|---|---| | P1 (Vake) | AI による海上監視(初期) | 沿岸警備官 (N) | B2B | プロダクトマネージャー (1) | | P2 (Hjernelæring) | 親・教師向けオンラインのメンタルヘルスガイド(初期) | 親、教師、子ども (G) | B2B & B2C | プロダクトマネージャー (1) | | P3 (Unicad) | オンライン工学計算ツール(初期) | 建設エンジニア (N) | B2B & B2C | 開発者、プロダクトマネージャー (1) | | P4 (Byks) | オンラインスポーツコーチング(初期) | コーチ、アスリート (G) | B2B & B2C | プロダクトマネージャー (1) | | P5 (Flow Technologies AS) | オンラインリハビリ支援(成長) | 患者、リハビリ機関 (N) | B2B | データサイエンティスト、プロダクトマネージャー (2) | | P6 (Noba) | オンライン栄養支援(成長) | 過敏性腸症候群傾向の人 (N) | B2C | プロダクトマネージャー (1) | | P7 | オンラインバンキング(成熟) | 銀行顧客 (G) | B2C | テックリード、プロダクトオーナー (3) | | P8 | 公共サービスのオンライン案件処理(初期) | 公務員 (N) | N/A | プロダクトマネージャー、法律家、開発者 (3) | | P9 | オンライン採用プラットフォーム(成熟) | 採用担当者、候補者 (G) | N/A | チームリード、プロダクトオーナー (2) | | P10 (Emissions Insights) | 船舶の排出量トラッカー(初期) | 船舶運航者 (N) | B2B | プロダクトマネージャー (2) | | P11 | オンライン経路検索(成熟) | 旅行者 (G) | B2C | UX デザイナー (2) | | P12 (Sandstorm) | オンラインミームジェネレーター(成長) | ミーム利用者 (G) | B2C | プロダクトマネージャー (1) | | P13 | デザイナー向けオンラインマーケットプレイス(成長) | 建築デザイナー、デザインの消費者 (N) | B2B & B2C | プロダクトマネージャー (1) | (表3(Table 3): ケースの要約。合計 19 人・21 件。実名は判明分のみ括弧内) 付録 I によれば、企業は Iterate(80 人。P1〜P6)、SpareBank 1 Utvikling(6300 人。P7)、公的福祉組織(22000 人。P8・P9)、DNV(3700 人。P10)、公営の交通系デジタルサービス企業(250 人。P11)、Zedge(80 人。P12)、インテリアデザインの小企業(10 人。P13)である。 表4はテーマ分析のコーディング例を示す。 | インタビュー抜粋(要旨) | 初期コード | 初期テーマ | 見直し後のテーマ | |---|---|---|---| | 開発者はモバイルバンクを使いながらバグを見つけ、翌日直せる(P7) | ドッグフーディング | ユーザーフィードバックの種類 | 利用者としての開発者 | | 初日からメトリクスを持ち、洞察を生まないものは入れ替える。ダッシュボードは固定できない(P5) | 初日からメトリクスを確立し更新し続けた / 使われない機能は削除する | メトリクス | テレメトリダッシュボード | | データチームには聞けるが、何を誰に聞くかを知る必要がある(P11) | データチームから利用データを得る手間 | 他者からのデータ取得 | 課題 - メトリクス関連 | | 利用状況の数字を Amplitude にまとめたいが、今は無い(P4) | 利用データへの洞察が欲しい | ダッシュボード未整備 | 課題 - リソース関連、テレメトリダッシュボード | (表4(Table 4): テーマ分析のコーディング過程の例) ### 概念モデル ![[_attachments/user-feedback-cse-state-of-practice/fig02-user-feedback-in-cse-model.png]] (図2(Figure 2): 結果の全体像と先行モデルへの写像。薄い灰色が先行 CSE モデル、濃い灰色が本研究で加えた概念。プロダクト開発者の目的・フィードバック技法・分析技法・提示と利用が、継続的利用・監視・製品計画と結びつく。データリテラシーを横断的関心事として加える) 一般的な流れは次のとおりである。プロダクト開発者は達成すべき製品目的に基づいてフィードバック技法を選ぶ。技法を適用できるのは、エンドユーザーが製品を時間をかけて使い続ける継続的利用があるからである。技法で得たフィードバックは分析技法で解釈され、継続的な監視に使われる。さらに提示と利用を通じて継続的な製品計画に使われる。 ## 新規性 - Fabijan et al.(2015)の技法一覧に無い技法として、ユーザー要望・提案、セールスデータ、便宜的サンプリングを特定した。 - 利用者としての開発者と便宜的サンプリングを、収集技法ではなくユーザーのサンプリングの仕方で決まる技法として独立させた。 - A/B テストを収集技法ではなく分析技法に分類し直し、分析・提示技法(A/B テスト、テレメトリダッシュボード、明示的・暗黙的フィードバックの相互検証)を収集技法から区別した。 - 一部のフィードバックは別のフィードバック源を検証するために集められるという目的を新たに見いだした。 - 先行の CSE 概念モデルへ、目的・技法・分析・提示と利用・データリテラシーを写像した。 ## 実験設定 - 対象: 13 製品(初期段階 6、成長段階 4、成熟段階 3)、実務者 19 人、21 インタビュー - 役割: プロダクトマネージャー、プロダクトオーナー、テックリード、開発者、データサイエンティスト、UX デザイナー、法律家など - 市場: B2B、B2C、両方、公共部門(N/A) - ユーザー層: ニッチ(沿岸警備官、建設エンジニアなど)と一般(銀行顧客、旅行者など) - 補助資料: 可能な場合はアプリやサイトへのアクセス、ツール利用の録画、ホワイトボードの写真も集めた ## 実験結果 ### 明示的フィードバック収集技法(4.1.1) - **ユーザーインタビュー**は 11 ケースで言及され、最も多く使われた。目的はユーザーの文脈理解(G1)である。B2C では一般ユーザーのニーズと関心の引き金を理解するため(G7)に使い、P2 は AARRR(Acquisition, Activation, Retention, Referral, Revenue)の枠組みで質問を組み立てた。B2B では顧客側の担当者との関係構築(G4)が目的になることが多く、非公式な接点が率直なフィードバックを促した。暗黙的フィードバックの解釈(G2)にも使われた。 - インタビューのコスト認識は割れた。P6・P9 は資源を食い洞察が乏しいとし、P1〜P4・P10・P13 は製品コストを節約しつつ深い洞察を得る手段とした。著者らはこの差を、ソフトウェアエンジニアを確保できる度合いの違いで説明する。開発者が多く実験できるケースはインタビューを冗長と見なし、開発者が少ないケースはまずインタビューで選好を探って資源を節約した(G3)。 - **製品内サーベイ**は 3 ケースで、実装済み機能への反応把握(G5)の補助データとして使われた。P7 は親指アイコンで起動する自由記述欄、P4 は解約時のサーベイを用いた。 - **観察**は 6 ケースで使われた。非参与型(オフィスでの録画付き観察。P11 は準備に手間がかかり時代遅れと見る)、参与型(P8 は画面共有しながら質問)、エスノグラフィ型(P3・P8)がある。P8 はおよそ 2 週間に 5 回、数時間ずつ職場を訪ねた。エスノグラフィ型を使った 2 製品がいずれもニッチ層向けだったことから、著者らはニッチ製品で有益だと示唆する。 - **プロトタイプテスト**は 9 製品(P1〜P5、P7、P9〜P11)で好まれた。参与型観察と非公式インタビューの組み合わせが多く、思考発話法も使われた(P3、P9)。結果はフィールドノート程度にしか記録されないか、記録されないことが多く、スタンドアップなどの計画の入力に使われた(G11)。 - **インシデントレポート**は 6 ケースで、機能が意図どおり動くかの評価(G6)に使われた。自動生成のものは本論文ではイベントデータに分類する。同僚や製品スポンサーなど、ユーザー以外の内部関係者が報告する例もあった(P8、P10、P11)。 - **ユーザー要望・提案**(新規)は 5 ケースで言及された。他の技法と違ってユーザー側から始まり、メールやチャット、口頭で届く。非公式な関係を築いたときに現れ、思わぬ選好を明らかにした(G9)。 ### 暗黙的データ収集技法(4.1.2) - **オンライン広告**(P2、P4): P4 は Instagram 投稿で関心(G7)とトラフィック誘導を確かめた。 - **ベータテスト**(6 ケース): プロトタイプより成熟した版を、より大きな標本で試す。P7 は約 5000 人の銀行顧客に新しいネットバンキングの初期版を出した。P5 は特定顧客にベータ機能をオン・オフできる形で提供し、未完成コードを減らした。目的は G3・G5・G6 である。 - **イベントデータ**(9 ケース): 最も多い技法の 1 つである。利用可能なメトリクス数は、初期段階の数個から成熟製品の数十個まで幅があった。生のままではほとんど使えず、構造化・可視化・分析の追加作業を要した(P3 は変更ログを自前でデータベース化した)。 - **ソーシャルネットワーク**(P13): 写真あたりのいいね数を、各建築家のデザインへの評価の代理指標にした(G7)。 - **セールスデータ**(新規、5 ケース): ニュースレター登録数、サブスクリプション購入意向、Google Play ページ訪問者数、実売上などである。収益性の評価(G10)だけでなく人気の評価(G7)にも使われた。P2 と P4 は実コードを含まない Figma プロトタイプで複数の料金プランを提示し、支払意思を数えた。 ![[_attachments/user-feedback-cse-state-of-practice/table06-feedback-techniques-cases.png]] (表6(Table 6): ケースごとのフィードバック技法 T1〜T11。太字は Fabijan et al. 2015 に無い技法(ユーザー要望、セールスデータ)) ### ユーザーサンプリングを用いる技法(4.1.3) - **利用者としての開発者**(P3、P4、P6、P7、P10、P11、P12): 手早く低コストなフィードバック獲得として好意的に語られた。G1・G5・G6 に加え、ユーザー募集とテストの資源節約(G3)にも役立つ。領域経験を持つ開発者で特に有効だった(P3、P4、P6)。 - **便宜的サンプリング**(新規、P4、P6、P7、P10、P11、P12): 家族・友人・同僚から被験者を集める。無作為でないため社会的望ましさによる偏りの恐れがあるが、手早く安価である(G1、G3)。P11 の開発者は 14 歳の娘に新機能を見せた。低労力のテストで明白な欠点を潰した後(G6)、コードをリリースしてイベントデータで挙動を注視するのが典型的な流れだった。 ![[_attachments/user-feedback-cse-state-of-practice/table07-sampling.png]] (表7(Table 7): ケースごとのサンプリング技法) ### フィードバックの分析・提示技法(4.1.4) - **A/B テスト**(P7、P11、P12): 本質は 2 条件のイベントデータの統計的比較であり、収集ではないため分析技法に分類する。既存機能の小さな調整で、最もエンゲージメントの高い条件を探すとき(G8)に好まれた。十分なユーザー数が前提で、初期段階の製品では使われなかった。偏りが比較的小さく、他の関係者に伝えやすい。P7 は入口の文言を A/B テストで選び、セールスデータとの突き合わせで事業価値を算出した。ただし同じ情報提供者は、他の多くの A/B テストはそれほど解釈しやすくなかったとも述べた。 - **テレメトリダッシュボード**(P5〜P12): 暗黙的ユーザーデータを要約・可視化・分析する基盤で、G5・G6・G7 と製品計画(G11)に使われた。P5 は初日からメトリクスを持ち、機能の優先・廃止をダッシュボードで決め、洞察を生まないメトリクスは入れ替えた。既製品(P12 の Amplitude、P6 の Mixpanel)は初期製品の開発費を抑えるが、長期的には制約になりうる(P6 はスタートアップ向け割引の喪失を懸念)。自作(P5、P9)は複数ソースを統合でき継続的に調整できるが、初期段階の製品(P1〜P4)には高価すぎる。それでも可視化と構造化の需要は全ケースで高く、P2 は Excel で手作業監視していた。 - **明示的・暗黙的フィードバックの相互検証**(4 ケース): テレメトリだけでは行動の理由が分からないため、インタビューやプロトタイプテストと突き合わせる。P5 はインタビュー中にダッシュボードを見せ、ユーザーの振り返りを促した。 ![[_attachments/user-feedback-cse-state-of-practice/table08-analysis.png]] (表8(Table 8): ケースごとの分析技法) ### 目的と技法の対応 ![[_attachments/user-feedback-cse-state-of-practice/table05-goals-part1.png]] ![[_attachments/user-feedback-cse-state-of-practice/table05-goals-part2.png]] (表5(Table 5): 技法ごとの目的 G1〜G11。上が明示的技法など、下が続き(イベントデータ〜相互検証)) - 最も多い目的は G5(実装済み機能への反応把握)、G6(機能が期待どおり動くか)、G1(ユーザーの文脈理解)、G7(関心の把握)である。最も少ないのは G9(選好の顕在化)と G10(支払意思)だった。 - 同じ目的を多様な技法が支える(G1 にはインタビュー、観察、プロトタイプテスト、便宜的サンプリング、利用者としての開発者、相互検証)。著者らは、冗長性が目的達成の見込みを高めると示唆する。 - 1 つの技法が複数の目的に寄与する(ダッシュボードは G5・G6・G7・G11)。関連する目的が多いほど、その技法の導入コストを正当化しうる。 ### 課題(4.2) ![[_attachments/user-feedback-cse-state-of-practice/table09-challenges.png]] (表9(Table 9): ケースごとの課題 6 群。リソースとメトリクスが最も多い) - **ユーザー問題**(P1、P2、P8、P10): ユーザー問題やユーザー群が不確かだと、テストユーザーの募集そのものが難しい(P2)。B2B では複数の顧客企業に通用する汎用的な問題を見つける必要があった(P1、P10)。未成熟な製品では支払意思を測れないため、セールスデータで訴求を反復した。 - **データ取得と共有**(3 製品): 公共部門の P8・P9 では、どのデータを収集・共有・保存してよいかが不明確だった。規制が文脈に即しておらず、組織内外のデータ共有を妨げた。「安全第一」の姿勢で低いデータ品質を受け入れる例もあった(P9、P11)。P8 は法律専門家を常駐させ、データ管理の意思決定時間を大幅に短縮した。大企業では、どんなデータが社内にあるかを知ること自体が人脈に依存した(P11)。 - **メトリクス**: メトリクスの選択と優先づけを継続的に見直す必要があった(P5 は日次スタンドアップで議論)。P9 ではメトリクスが作成後数週間で壊れ、修復には開発者 1 日あたり 12,000 クローネ(約 1200 ユーロ)がかかったため、徐々に「消える」に任せた。解釈も難しく、P12 は大量のデータを「影しか見えない」と表現した。P11 はダウンロード数の増加をキャンペーン効果と解釈したが、実際はボットによるものだったとみられる。緩和策として、ダッシュボード、探索的統計分析(P7)、チームでの議論(P1、P2、P5、P8)、明示的フィードバックとの相互検証、成長分析(P12)が挙がった。 - **リソース**(8 ケース): 時間と開発能力を最も食わない技法を優先した結果、利用データの収集・監視が弱まった。開発者が不足するケース(P2、P3、P11)は監視よりインタビューとプロトタイプテストに寄った。逆に開発者を確保できるケース(P6、P9、P12)は、事前のユーザーテストを省いて先にデプロイし、テレメトリで検証した。 - **ユーザー満足**(P7): ネットバンキングのダッシュボード表示を A/B テストで変えたところ、ベータユーザーには好評だったが、中核顧客への公開後に不満が出た。チームは事業価値を理由に維持を説得し、満足度はやがて元に戻った。著者らはこれを、体験改善の試みが満足を脅かしうるという逆説とみる。 - **方法**(3 ケース): フィードバックの収集と分析の厳密さへの不満である。P9 は「メトリクスを設定し、クリックを見て、ユーザー洞察の欄にチェックを付けるだけ」と述べた。解釈しやすい一部のデータだけを拾う「つまみ食い」が起きており、当人たちは誤りを自覚しながら続けていた。 ## 考察 ### RQ1 への回答 | 概念モデルの要素 | 主要な知見 | 関連文献・概念 | |---|---|---| | フィードバック技法 | CSE の技法はソフトウェア工学一般とほぼ同じ | Fabijan et al. (2015) | | フィードバック技法 | 追加の技法としてユーザー要望とセールスデータを特定 | 継続的信頼、継続的利用(Klotins et al. 2022; Fitzgerald and Stol 2017) | | フィードバック技法 | テストユーザーのサンプリングの仕方で決まる技法(便宜的サンプリング、利用者としての開発者)が意外に多い | Fabijan et al. (2015)、ユーザー問題(Ros et al. 2024) | | 分析・提示技法 | 分析・提示技法を収集技法から区別することが重要 | Fabijan et al. (2015); Bajic and Lyons (2011) | | 分析・提示技法 | テレメトリダッシュボードが暗黙的フィードバックの分析手段としてよく挙がった | 継続的監視、継続的計画(Klotins et al. 2022) | | プロダクト開発者の目的 | 目的が技法の選択を左右する。一部のフィードバックは他のフィードバック源の検証のために集められる | Johanssen et al. (2019) | | プロダクト開発者の目的 | 目的の多くはユーザーとその反応の理解に関わる | ユーザー問題、プロダクトマーケットフィット(Ros et al. 2024) | (表10(Table 10): CSE におけるユーザーフィードバックの実務の要約) - Fabijan et al.(2015)の技法のうち、シアターセッション、ウォークスルー、クラウドファンディングは標本に現れなかった。標本が小さいためかもしれない。 - ユーザー要望は、ユーザーが自発的に出すため率直な意見を反映しやすく、使い続けたいという意思も示唆する。著者らはこれを継続的信頼の概念と結びつけ、CSE で特に重要になりうるとする。 - 利用者としての開発者は、Fabijan et al.(2015)では時間がかかる技法とされていたが、本研究では手軽で労力が少ないと語られた。便宜的サンプリングと利用者としての開発者が同じケースで報告されたことから、著者らは製品の文脈(文化、プラクティス、ユーザー種別)が影響すると考える。一般ユーザー向けの製品で特に有益だと推測するが、標本が小さく確かめられない。 - 分析技法は継続的監視に、提示と利用は継続的製品計画にそれぞれ寄与するため、図2では両者を分けた。自動化でユーザーデータが増えるほど解釈能力は落ちる。とりわけ相互検証は A/B テストのようには自動化できない。 - ユーザー問題の解決に関わる目的(G1、G5、G9)は明示的技法で、関心や支払意思の推定(G7、G10)は暗黙的技法(オンライン広告、ソーシャルネットワーク、セールスデータ)で達成される傾向があった。著者らは、明示的技法はユーザー問題の解決に、暗黙的技法はプロダクトマーケットフィットの探索に向くと予想し、より大きな標本での検証を求める。 ### RQ2 への回答 | # | 課題 | CSE モデルの関連要素 | 結果での課題ラベル | |---|---|---|---| | 1 | 継続的なユーザーフィードバックは継続的信頼を損ないうる | 信頼と満足 | ユーザー問題 | | 2 | 継続的フィードバックは、フィードバックの品質と取得コストのトレードオフを要する | リソース計画、監視、製品計画 | リソース | | 3 | 継続的コンプライアンスがユーザーフィードバックへのアクセスを妨げる | コンプライアンス | データ取得 | | 4 | 継続的監視には重要メトリクスの継続的な妥当性確認が要る | 監視 | メトリクス | | 5 | データリテラシーの不足は継続的フィードバックの価値を下げうる | データリテラシー | 方法 | (表11(Table 11): CSE における課題の要約) - **継続的信頼**: A/B テストなどでの小刻みな変更は満足度を下げうる。継続的利用は継続的フィードバックの前提であり、継続的利用の前提は継続的信頼(ベンダーが協調的に振る舞い、ユーザーの弱みにつけ込まないという期待)である。 - **品質とコストのトレードオフ**: 資源が乏しいと手近な手段(便宜的サンプリングなど)に頼り、一般化可能性が疑わしくなる。CSE のリソース配分は継続的でなく周期的であることが多い(Klotins et al. 2022)。リリース速度と自動収集データの量が時間圧力を生み、品質より取得を優先させる。全ケースが明示的と暗黙的の両方を集めていたが、相互検証は一部だけだった。分析が伴わないと、収集は続いていても監視と計画がフィードバックから切り離される。完全な分析欠如は観察されなかったが、解釈しやすいものだけを拾う傾向はあった。 - **継続的コンプライアンス**: GDPR などへの準拠は CSE 全体に関わる横断的関心事であり、法的・倫理的・技術基盤上の制約でデータにアクセスできなければ、ある種のフィードバックは収集も分析もできない。 - **メトリクスの継続的な妥当性確認**: 適切なメトリクスを見つけるには、無意味なものを除き有用なものを足す長期の試行が要る(P5)。ダッシュボードには、基盤と人材への投資、テレメトリへのアクセスという前提(初期製品では使えないか代表性が無い)、継続的保守の負担という 3 つの問題がある。既製品ツールが自作並みに柔軟かは不明である。著者らは、メトリクスの数より選び方が継続的監視の成否を決めると推測する。 - **データリテラシー**: 分析の手抜きは資源不足だけでは説明しきれない。分析の専門性不足も一因とされ(Lindgren and Münch 2016)、著者らはデータリテラシーを CSE の横断的関心事として提案する。 ### 実務への含意 1. **フィードバックをより徹底して分析し、製品計画につなげる**: 収集は自動化できても解釈は自動化しにくい。暗黙的フィードバックの自動分析は主に要求とバグ修正の妥当性確認に使われ、新機能の発見には使われないため、明示的フィードバックの解釈も重要になる。解釈を自動化できなければ、リリース速度か品質のどちらかが犠牲になる。対策として、分析の時間を確保し、日次ミーティングなどでフィードバックを議論し、プロダクトマネージャー自身がデータリテラシーを高め、分析の専門家を関与させる。データアナリストが活動していたケース(P5、P7)は、より体系的かつ継続的にフィードバックを扱っていた。 2. **テレメトリダッシュボードに投資し、製品のニーズに合わせて継続的に調整する**: ダッシュボードは継続的監視、継続的製品計画、継続的改善に寄与するが、体系的に使われていないか、優先されていないことが多い。自作はチームや製品に合わせやすい。コストや能力の不足には、上位の管理層が資源を用意すべきである。 ### 妥当性への脅威 - 構成概念妥当性: インタビューの冒頭で CSE の意味を説明し、CSE に依拠する製品を選び、暫定結果を参加者に確認した。 - 内的妥当性: CSE とフィードバックの実務・課題の関係についての示唆は、今後の検証を要する。 - 外的妥当性: 人脈経由の募集、ケースごとに 1〜3 人という不均衡、ノルウェーという単一の文化圏、19 人・13 ケースという小さな標本が一般化を制限する。 - 信頼性: 文脈は再現しにくい。インタビューガイド、分析の詳細、コーディングスキームを公開するが、生データは機密保持契約により公開しない。 ### 今後の課題 製品の文脈(ニッチか一般か、企業規模、文化、市場種別)の影響をより大きな標本で調べること、継続的フィードバックでのユーザーサンプリングのベストプラクティス、CSE におけるテレメトリダッシュボードの使われ方の 3 点を挙げる。 ## 強み / 弱点・課題 **強み** - 製品の成熟段階、市場種別、ユーザー層が異なる 13 ケースを横断し、技法・目的・課題をケース単位の行列(表5〜表9)として示し、どのケースに何が現れたかを追跡できる。 - 既存の技法一覧(Fabijan et al. 2015)を出発点に、一覧に無い技法と分類の組み替え(A/B テストを分析技法へ)を明示しており、先行研究との差分が読み取りやすい。 - 暫定結果を参加者に確認(9/13 ケースが返答)し、複数著者によるインタビューと分析で確証バイアスの低減を図った。 **弱点・課題** - 標本が小さく、ノルウェーの人脈経由の募集に偏る。著者ら自身が一般化を狙わないと明言しており、ニッチ製品とエスノグラフィ型観察、明示的技法とユーザー問題の対応などの推測は仮説にとどまる。 - 提案する概念モデル(図2)とデータリテラシーを横断的関心事とする主張は、インタビューからの解釈と先行研究に基づき、定量的な検証を経ていない。 - ケースごとの面接数が 1〜3 件と不均衡で、面接 1 件だけのケースが 7 つある。 - テレメトリダッシュボードへの投資の推奨は、P5 などの成功例に依拠しており、費用対効果は測っていない。 ## 関連 - ソース: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 8 製品開発のプラクティス]] / [[@2015__Onward!__Runtime Metric Meets Developer - Building Better Cloud Applications using Feedback]] - 概念: [[リーン製品開発]] / [[A-Bテスト]] / [[フィードバック駆動開発]] / [[継続的デリバリ]] / [[データのプライバシーと同意]] - エンティティ: [[Anastasiia Tkalich]] / [[Eriks Klotins]] / [[Tor Sporsem]] / [[Viktoria Stray]] / [[Nils Brede Moe]] / [[Astri Barbala]] / [[SINTEF]] ## 出典 - [[.raw/papers/User-feedback-in-continuous-software-engineering---revealing-the-state-of-practice.pdf]] - https://doi.org/10.1007/s10664-024-10557-2